Private Key Extraction from Qualcomm Hardware-Backed Keystores (opens in new tab)

Yes. From the article:

> 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

>(page is not letting me copy+paste them here)

`user-select: none` in the `.slick-slider` CSS rule. User-hostility at its finest. Sigh...

That's assuming Galaxy S8+ is using Qualcomm's keymaster, I'm not too sure.

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.

I worked for a big company that made some really popular networking equipment. Of all people you would expect them to handle security ... fairly ok.

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.

I mean, this seems realistic. Product Security is contacted, the issue goes into some queue somewhere. Eventually it becomes a priority and the correct engineers have to be found to understand the researcher's paper and replicate the issue to their satisfaction.

"I had read that qualcomm's trustzone has had software exploits in the past, but I didn't think it would happen again"

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

Short answer: no

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.

Don't ever trust anyone to keep your sensitive data encrypted by default. Make sure you get something like TrueCrypt (open source, tested by a large segment of population, security experts from open source segment, etc) that is truly secured and don't have any backdoors, and use that to lock-up your data in a encrypted container. Make backups in cloud of those containers and sleep like a baby.

One of the main assumptions in cryptography is "if I can recover one bit of the private key, I can probably recover all of them." This is just a manifestation of that well-founded assumption.

The relevant paper here is: https://www.hpl.hp.com/techreports/1999/HPL-1999-90.pdf

It's not actually faster if you have to try all of them :)

Likely they can recover something like `private_key XOR nonce`. If you know a few bits of the nonce, you can reveal bits of the private key. But this is not something you can brute-force.

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.

It's a few bits over many signatures then fed into a lattice reduction algorithm.

"Only a few bits of each nonce are known for around 100 signatures", This is the challenge that we can't.

I guess it depends which public key the device is willing to accept updates from. This exploit gets you the per-device keystore private key, which is not going to be being used by vendors to sign builds. But perhaps there's an option somewhere to allow running firmware updates if the payload is signed by the device's keystore key, I don't know.

The BearSSL link is the important one. For one, because they could literally have copy-pasted the code from there and would have avoided the issue outright. And second, because it demonstrates how useless the Qualcomm approach of throwing an entire Indian city worth of developers at a problem is when it comes to security. It just takes one.