from the someone-left-their-nonce-outside dept.
Submitted via IRC for Antidisestablishment
Security flaw lets attackers recover private keys from Qualcomm chips
Devices using Qualcomm chipsets, and especially smartphones and tablets, are vulnerable to a new security bug that can let attackers retrieve private data and encryption keys that are stored in a secure area of the chipset known as the Qualcomm Secure Execution Environment (QSEE).
Qualcomm has deployed patches for this bug (CVE-2018-11976) earlier this month; however, knowing the sad state of Android OS updates, this will most likely leave many smartphones and tablets vulnerable for years to come.
The vulnerability impacts how the Qualcomm chips (used in hundreds of millions of Android devices) handles data processed inside the QSEE.
The QSEE is a Trusted Execution Environment (TEE), similar to Intel's SGX.
It's a hardware-isolated area on Qualcomm chips where the Android OS and app developers can send data to be processed in a safe and secure environment, where the Android OS and no other app can reach and access the sensitive data, except the application that placed the data there, in the first place.
Data processed inside the QSEE usually includes private encryption keys and passwords, but the QSEE can handle anything an app wants to hide from prying eyes.
In March last year, Keegan Ryan, a security researcher with the NCC Group, discovered that Qualcomm's implementation of the ECDSA cryptographic signing algorithm allowed for the retrieval of data processed inside the QSEE secure area of Qualcomm processors.
Further, Ryan also points out that the QSEE was designed to prevent situations where attackers had full control over the device, meaning that the QSEE was failing at the primary function it was designed for.
"This should not be possible, since the hardware-backed keystore is supposed to prevent any sort of key extraction, even against an attacker who has fully compromised the Android OS," Ryan said.
(Score: 2) by c0lo on Friday April 26 2019, @10:49AM (1 child)
Over 50 years of serious computing and they still didn't get their heads around write-only-memory.
As fast as it may be, /dev/null is still an emulator.
https://www.youtube.com/@ProfSteveKeen https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by pkrasimirov on Friday April 26 2019, @12:01PM
> Over 50 years of serious computing and they still didn't get their heads around write-only-memory.
It's different heads, you see. 50 years ago "write-only-memory" means nobody can read the memory. Today it means nobody but us* can read the memory.
* Our company, our partner companies**, and law authorities***
** Anyone who pays us enough
*** Anyone arrogant enough
(Score: 1, Interesting) by Anonymous Coward on Friday April 26 2019, @11:15AM (4 children)
I'm ignorant of the implementation and the interface, so this might be stupid question, but can someone explain how that is possible? If an app on a fully compromised system has access to the memory and I manipulate the process that owns the memory how does it prevent access?
(Score: 3, Interesting) by aiwarrior on Friday April 26 2019, @11:37AM
I also am not sure I understand. Even if a token is passed or received on secure storage, this token needs to exist somewhere.
The only way I imagine is that there is privileged code that is executed, not only storage. This way the transaction and it's processing is done in a secure context and communicating with the main application with simple return values.
(Score: 4, Interesting) by zocalo on Friday April 26 2019, @12:09PM (1 child)
Anyone more familiar with low-level programming of Qualcomm chips able to explain what's actually going on?
UNIX? They're not even circumcised! Savages!
(Score: 2, Informative) by Anonymous Coward on Friday April 26 2019, @03:08PM
It's a classic side channel information leakage : from the tfa
It doesn't look like a voluntary ECDSA backdoor
(Score: 2) by rigrig on Saturday April 27 2019, @03:02PM
That description seems a bit inaccurate.
So the idea is you put some code+data in it, which you can never get back, but you can ask it to perform some operation.
You could for example set up a private inside the trusted area, and have expose some function that decrypts things using that key.
This way if the OS is compromised, the attacker would be able to decrypt random messages, but not have access to the private key itself.
(Or you could even setup a PIN in the trusted area, and have the decryption only work if that same PIN is provided)
No one remembers the singer.
(Score: 0) by Anonymous Coward on Friday April 26 2019, @02:01PM (1 child)
Does this mean more free movies for the people?
(Score: 0) by Anonymous Coward on Friday April 26 2019, @05:35PM
Yes.
(Score: 2) by Bot on Friday April 26 2019, @10:28PM
Qualcomm: putting the SNAP! in Snapdragon.
Account abandoned.