
Private Key Extraction from Qualcomm Hardware-Backed Keystores - griffinmb
https://www.nccgroup.trust/us/our-research/private-key-extraction-qualcomm-keystore/?research=Technical+advisories
======
AdmiralAsshat
[https://www.qualcomm.com/company/product-
security/bulletins#...](https://www.qualcomm.com/company/product-
security/bulletins#_CVE-2018-11976)

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](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.

~~~
wyldfire
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

~~~
AdmiralAsshat
Thanks, I was hoping to figure out _when_ it was distributed. But your comment
encouraged me to search for the CVE, and it looks like it was fixed in the
Android 04-05 security patch:

[https://source.android.com/security/bulletin/2019-04-01](https://source.android.com/security/bulletin/2019-04-01)

~~~
phh
For vendor patches, you really can't trust that value in any way... I'm afraid
there is no real way to check, except for trying the attack.

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.

------
dlgeek
Not the best response from the vendor:

> 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

~~~
duxup
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.

~~~
ChrisCinelli
I think it would take at least another 20 years to have people that are really
security expert in most of the big companies!

~~~
ci5er
Stuff changes. Today's young Turks, when factoring in the time and energy to
get to the point they would be listened to, will have antiquated skills too.

Old people can certainly keep up! But corporate climbers often can't (I do
know of exceptions)

------
ndiscussion
Does this allow someone to decrypt a stolen device?

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?

~~~
unnouinceput
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.

~~~
tptacek
The idea that it's safer to trust Truecrypt than the platform's enclave secret
system because enclaves sometimes have vulnerabilities strikes me as pretty
weird, since the big difference between Truecrypt and an enclave-based system
is that Truecrypt doesn't have an enclave to begin with.

~~~
tedunangst
Doesn't seem that weird. The enclave has your secret in it, and comes attached
to the storage it's protecting. Steal storage, extract key, done.

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.

~~~
mindslight
... if and only if it is off. Which is probably not a great assumption with a
phone.

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.

~~~
tedunangst
Good point. Didn't really consider live or "cold boot" attacks.

------
Sahhaese
Possibly stupid question: If only a few _bits_ of nonce are needed to recover
the key, what's preventing iteration of all possible values of those "few
bits"?

~~~
remcob
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.

~~~
tracker1
store something known in the secure storage...

------
wemdyjreichert
Could this allow bootloader unlocking, custom roms, etc. on an otherwise
locked device (e.g. S7)? Tried the engineering bootloader, but horrible
battery management.

I'll avoid updating until I know more.

~~~
cjbprime
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.

------
bubblethink
>We demonstrate this by extracting an ECDSA P-256 private key from the
hardware-backed keystore on the Nexus 5X.

Did the fixes make it to nexus 5x ? It has been EOL since December 2018. The
cve date is CVE-2018-11976 though.

------
nayuki
Related topics:

* [https://jochen-hoenicke.de/crypto/trezor-power-analysis/](https://jochen-hoenicke.de/crypto/trezor-power-analysis/)

* [https://www.bearssl.org/constanttime.html](https://www.bearssl.org/constanttime.html)

~~~
stefan_
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.

------
fulafel
Are there any interesting practical consequences from this in common apps?

------
VeninVidiaVicii
Considering how some carriers refuse to unlock bootloaders, this may well be
the only option some of us have to restore bricked phones. Other than paying
Google 250 bucks to reflash them.

