9 ms·

Private Key Extraction from Qualcomm Hardware-Backed Keystores

305 points by griffinmb 7y ago

nayuki 7y ago
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_ 7y ago
  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.
dlgeek 7y ago
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 7y ago
  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.
  - dboreham 7y ago
    One solution to this problem is to post a PGP key on your security response web page. Then, whoever reports problems will encrypt the message such that it is only readable by the proper people inside your organization (because they control that PGP key and regular support, suits etc don't)
    - duxup 7y ago
      Certainly for communication that is the right way to go. 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.
  - mickael-kerjean 7y ago
    > security written all over their resume don't know jack squat. While working in a F500, I found on github the company credentials of a security consultant coming from Thales ... hem
    - duxup 7y ago
      The head of security for Panera Bread seemed to become upset / confused when a security researcher asked about exchanging pgp keys... he worked at Equifax previously.
      - metildaa 7y ago
        Par for the course, "security" industry people, especially the higher ups rarely make an effort to secure their communication. The best you can hope for is they likely use Signal, good luck getting their contact details or verifying keys with them though!
  - ChrisCinelli 7y ago
- dmtroyer 7y ago
  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.
  - nertzy 7y ago
    Here’s what could have happened: 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.
    - shawnz 7y ago
      It actually does say confirmation of receipt, on March 19 (the same day it was submitted)
Sahhaese 7y ago
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"?
- MrXOR 7y ago
  "Only a few bits of each nonce are known for around 100 signatures", This is the challenge that we can't.
- remcob 7y ago
  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 7y ago
    store something known in the secure storage...
- djhaskin987 7y ago
  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.
- wbl 7y ago
  It's a few bits over many signatures then fed into a lattice reduction algorithm.
  - Scoundreller 7y ago
    Cool, so I guess at some point, you should just brute force the rest of the unknown bits. 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.
AdmiralAsshat 7y ago
https://www.qualcomm.com/company/product-security/bulletins#_CVE-2018-11976 https://www.qualcomm.com/company/product-security/bulletins#... 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 7y ago
  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
  - Ajedi32 7y ago
    Do firmware updates typically get distributed along with OS updates on Android, or is there some other process you'd need to use to patch those device?
    - zifnab06 7y ago
      They're delivered along with normal updates.
  - AdmiralAsshat 7y ago
    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
wemdyjreichert 7y ago
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 7y ago
  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.
fulafel 7y ago
Are there any interesting practical consequences from this in common apps?
- deleted 7y ago
  [deleted]
garrywang57 7y ago
Grab it: ZetPDF.com
ndiscussion 7y ago
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 7y ago
  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.
  - ndiscussion 7y ago
    Uhhh... what about when I take a photo with my Android phone? 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.
    - unnouinceput 7y ago
      Don't have cloud enabled and sharing by default. Also use strip tags software to erase your geolocations from the pictures you take. And if take sensitive pictures (children in your house, sexy time with SO, police doing a crime, etc) definitely move them to an encrypted container and use a wiper too to get rid of them from your normal storage.
bubblethink 7y ago
>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.
VeninVidiaVicii 7y ago
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.

305 points by griffinmb 7y ago

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_ 7y ago
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.

dlgeek 7y ago

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 7y ago
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.
- dboreham 7y ago
  One solution to this problem is to post a PGP key on your security response web page. Then, whoever reports problems will encrypt the message such that it is only readable by the proper people inside your organization (because they control that PGP key and regular support, suits etc don't)
  - duxup 7y ago
    Certainly for communication that is the right way to go. 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.
- mickael-kerjean 7y ago
  > security written all over their resume don't know jack squat. While working in a F500, I found on github the company credentials of a security consultant coming from Thales ... hem
  - duxup 7y ago
    The head of security for Panera Bread seemed to become upset / confused when a security researcher asked about exchanging pgp keys... he worked at Equifax previously.
    - metildaa 7y ago
      Par for the course, "security" industry people, especially the higher ups rarely make an effort to secure their communication. The best you can hope for is they likely use Signal, good luck getting their contact details or verifying keys with them though!
- ChrisCinelli 7y ago
dmtroyer 7y ago
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.
- nertzy 7y ago
  Here’s what could have happened: 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.
  - shawnz 7y ago
    It actually does say confirmation of receipt, on March 19 (the same day it was submitted)

Sahhaese 7y ago

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"?

MrXOR 7y ago
"Only a few bits of each nonce are known for around 100 signatures", This is the challenge that we can't.
remcob 7y ago
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 7y ago
  store something known in the secure storage...
djhaskin987 7y ago
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.
wbl 7y ago
It's a few bits over many signatures then fed into a lattice reduction algorithm.
- Scoundreller 7y ago
  Cool, so I guess at some point, you should just brute force the rest of the unknown bits. 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.

AdmiralAsshat 7y ago

https://www.qualcomm.com/company/product-security/bulletins#_CVE-2018-11976 https://www.qualcomm.com/company/product-security/bulletins#... 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 7y ago
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
- Ajedi32 7y ago
  Do firmware updates typically get distributed along with OS updates on Android, or is there some other process you'd need to use to patch those device?
  - zifnab06 7y ago
    They're delivered along with normal updates.
- AdmiralAsshat 7y ago
  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

wemdyjreichert 7y ago

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 7y ago
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.

fulafel 7y ago

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

deleted 7y ago
[deleted]

garrywang57 7y ago

Grab it: ZetPDF.com

ndiscussion 7y ago

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 7y ago
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.
- ndiscussion 7y ago
  Uhhh... what about when I take a photo with my Android phone? 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.
  - unnouinceput 7y ago
    Don't have cloud enabled and sharing by default. Also use strip tags software to erase your geolocations from the pictures you take. And if take sensitive pictures (children in your house, sexy time with SO, police doing a crime, etc) definitely move them to an encrypted container and use a wiper too to get rid of them from your normal storage.

bubblethink 7y ago

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

VeninVidiaVicii 7y ago

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.