Private Key Extraction from Qualcomm Hardware-Backed Keystores(nccgroup.trust) |
Private Key Extraction from Qualcomm Hardware-Backed Keystores(nccgroup.trust) |
That's pretty much all the snapdragons in modern Android phones (page is not letting me copy+paste them here).
Has QC put out a patch yet?
EDIT: The April security patch looks like it took care of it:
https://source.android.com/security/bulletin/2019-04-01
EDIT 2: And of course, my Samsung Galaxy S8+, despite having received an update in April, is only at the March 1st security patch level. So I'm likely vulnerable until Samsung's next update.
> Recommendation
> Qualcomm has already designed and distributed a patch to address this issue. Ensure that your devices are running the most recent firmware version.
Also, here's the list from that page: IPQ8074, MDM9150, MDM9206, MDM9607, MDM9650, MDM9655, MSM8909W, MSM8996AU, QCA8081, QCS605, Qualcomm 215, SD 210/SD 212/SD 205, SD 410/12, SD 425, SD 427, SD 430, SD 435, SD 439 / SD 429, SD 450, SD 615/16/SD 415, SD 625, SD 632, SD 636, SD 650/52, SD 712 / SD 710 / SD 670, SD 820, SD 820A, SD 835, SD 845 / SD 850, SD 8CX, SDA660, SDM439, SDM630, SDM660, Snapdragon_High_Med_2016, SXR1130
`user-select: none` in the `.slick-slider` CSS rule. User-hostility at its finest. Sigh...
Considering how Samsung is focused on security, I wouldn't be suprised if they'd use external security element like Google does on Pixel 3.
> March 19, 2018: Contact Qualcomm Product Security with issue; receive confirmation of receipt
> April, 2018: Request update on analysis of issue
> May, 2018: Qualcomm confirms the issue and begins working on a fix
I moved from an iPhone to a Galaxy S9 about a year ago because I was getting fed up with Apple's hardware problems, and wanted try Android again.
I convinced myself that I was able to secure the Android phone as long as I always bought the newest one and kept it up to date.
But decryption after loss is an untenable scenario for me. I had read that qualcomm's trustzone has had software exploits in the past, but I didn't think it would happen again.
Is there any way to trust that the data on my Android device is safe? If I lost it today, someone could keep it around for a while until the next exploit drops. Has Apple ever had an exploit of this nature?
It's not actually faster if you have to try all of them :)
In other words, the nonce bits leak information about the private key bits. You can't magically create this information by trying all possible values.
E.g. if you’ve figured out 255 of the 256 bits, don’t keep running through more signatures because you’re likely to get bits you already know.
I'll avoid updating until I know more.
Did the fixes make it to nexus 5x ? It has been EOL since December 2018. The cve date is CVE-2018-11976 though.
Yet they struggled to get headcount for people to respond to security researchers, and despite having seemingly trained the executives there was a regular "Oh man I contacted legal we should sue this guy!" type email every few months.
Meanwhile they had a separate technical support team who knew how to respond to customers in a timely fashion, make people feel like they're being listened to, but for some reasons they had to reinvent the wheel / fail repeatedly at dealing with security researchers as if nobody had ever done basic customer service before. I was on the support team and I sat next to the security guy(s) and I would show them what to do and how to keep a customer or security researcher on track. It wasn't rocket science, but nobody thought to teach them that.
And that was beyond training engineering to stop with the "well you're using it wrong" type responses.
The scale of, incompetence in the security field is astounding as a lot of folks with security written all over their resume don't know jack squat. And the scale of incompetence just DEALING with security researchers is also bizzaro world terrible, even among companies that should know better.
While working in a F500, I found on github the company credentials of a security consultant coming from Thales ... hem
If their customers (which are not u) and them feel like security is only a cost and not a selling point then they won't work much on it. After all they already sold those products and have orders for more.
March 20: Confirmation of receipt of issue, boilerplate response detailing expected next steps
And as far as we know, this might have actually happened! Maybe it wasn’t deemed interesting enough to include on that timeline.
Of course it's going to happen again, given the abysmal state of security in QSEE, Qualcom's implementation of Trust Zone. I used to do software/firmware security reviews at Google, and let me tell you that what Gal found at [1] would have never passed my reviews had Qualcomm had a similar internal security process in place. This is one of the many reasons Google realized they couldn't trust vendors, so they rolled out their own security chip Titan M: https://www.blog.google/products/pixel/titan-m-makes-pixel-3... So, if you want a secure phone, buy a Pixel 3 or later.
[1] http://bits-please.blogspot.com/ : there are so many WTF moments, like Qualcomm not revoking trustlets, never sanitizing arguments passed to QSEE syscalls, etc, etc
Longer answer: This article mentions how to leak the key, but it assumes that you can generate many signatures successfully. But to successfully use the key (thus sign with the key), you need to provide the password to the TEE, else it will refuse any operation on the key. If the TEE is properly written (I'd say Qualcomm's is), the key in keymaster (which encrypts the key for the storage) itself is encrypted based on the password, so it can't leak anything since it's not decrypted even for the TEE itself.
Also, unless you unlocked your bootloader, the attacker would need to be able to launch its own software while the device is on the boot lockscreen. That requires to find an additional security flaw in the bootloader and/or early Android boot.
Forgive my ignorance, but I don't believe it's secure to use TrueCrypt anymore, and I didn't even think it was possible to use a volume on Android, let alone an automatically encrypted volume.
I'm worried about thugs blackmailing me, not state actors.
Qualcomm patches are not distributed as part of AOSP security patches, and is not tested for Google certification, so there is really no reason for it to be accurate, except possibly for Pixels.
In other settings, yes you can still gather leaked bits and use them to reduce the search space until it is small enough to brute force. I've had my own elliptic curve implementation broken through differential power analysis from a leakage due to a conditional branch just like the one in this paper. It leaked only a single bit and it was leaking a bit of the key or a nonce but the least significant bit of an intermediate value in the same way that the LSB was leaked in this paper. All I did was select one of two results, both of which were computed using the same number of operations every time and discarded the other based on whether a result was odd or even. Simply branching is generally enough to leak. After running many operations using the same key on different data you could reduce the search space down to one which could be brute forced in a few minutes. Both the OP's implementation and mine also tried to use some side channel countermeasures, but leaking this single bit was enough. You simply cannot use any conditional branching or memory addressing based on secret information [4-5]. Even being aware of this, it was not obvious how to avoid this conditional branch while implementing the algorithm (the math can be reformulated to avoid it).
We did find that randomized projective coordinates[6] significantly helped in our case (we had already implemented this but was disabled by default). This probably only makes it more difficult to extract the secret but it should be implemented in constant time.
[1] https://www.nccgroup.trust/globalassets/our-research/us/whit...
[2] https://www.youtube.com/watch?v=QCsvBFFLsqE
[3] https://www.nccgroup.trust/us/our-research/return-of-the-hid...
[4] https://cr.yp.to/highspeed/coolnacl-20120725.pdf
[5] https://www.bearssl.org/constanttime.html
[6] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1.5...
Having said that the suits have to be in the loop to some extent, they just need to be able to control those "I don't like this sue them" instincts and understand how to better channel that energy.
Security needs an executive level person to be able to directly work with the other executives to push things if only because the inclination to hide or not fix things is so common. Security just isn't a part of a lot of engineering teams mindset / time budget.
It's a cultural thing that just hasn't taken hold (normally I hate using "cultural" but it seems to fit here).
The best you can hope for is they likely use Signal, good luck getting their contact details or verifying keys with them though!
Old people can certainly keep up! But corporate climbers often can't (I do know of exceptions)
My software FDE does not keep my password in it. There is nothing to extract after stealing. I will happily stipulate though that this requires a solid password and key stretching.
A DIY mitigation might be to convert a phone to having only an external battery on a long cable, which stays in your other pocket.
Philosophically I do agree with where you're coming from with contemporary devices insisting on baking in privileged keys. It's unfortunate that we're forced to choose between the two models.