Qualcomm KeyMaster keys extracted directly from TrustZone | Hacker News Reader

Qualcomm KeyMaster keys extracted directly from TrustZone

mobile.twitter.com

165 pointsmarksamman62 comments

Open articleView on HN

What would the implications of this be?

Does it just mean that people can root all devices using this chipset? Or something worse?

(sorry if this is obvious, I'm just not in the know)

This breaks the security model of all affected devices using this chip.

Including all iPhones sold today. Bye bye secure enclave. Bye bye full disk encryption.

No it doesn't, the secure enclave is a separate chip, it doesn't uses ARM trustzone, infact AFAIK Apple never implemented trustzone in any of their SOC's.

Considering the previous publications by this author the issue is most likely within the TZ Kernel that QM uses not in the hardware itself, previous vulnerabilities that were disclosed by the same guy/gal/singular or plural sentient entity were patched.

To be clear, Secure Enclave is a coprocessor on Apple's A7 and later SoCs, it's not a physically separate chip from the main processor. But you are correct it's different from TrustZone.

Thanks for the correction, I've read that it was a separate die but you are correct it's in the same package.

Just picking some nits..., but being on a separate die still can mean that it's in the same package.

https://www.google.de/search?q=multi+chip+package&tbm=isch

Early, iOS 7-era articles on the ARM chips used in the 5S imply Apple based their work on TrustZone, do we have any citations to definitively say either way? I suppose all this speculation will have to wait until more details are released or discovered.

More like bye bye Android Pay, didn't take much for the weakest link to break.

I’ve said this before (and got heavily downvoted) that the concept of Android Pay is stupid anyway.

Even worse than their version that works with a hardware secure enclave is the version which works without one.

How does that one work? By ensuring that the user didn’t modify the OS image.

That’s literally all security there is.

It’d be a lot better if they’d just build a security model that doesn’t have to rely on the device being secure, but instead rely on the banks’ servers being secure.

You can thank your bank for this :)

Well, my bank certainly has no involvement in this, and the banks I own shares of neither.

I can thank some US banks that I, as German Android user, get locked down by Google. I get all the issues, none of the benefits.

iPhones do not use Qualcomm chipsets, so you're wrong.

Depends on your definition of chipsets, but iPhones do use a significant amount of Qualcomm chips.

One source of many: https://www.ifixit.com/Teardown/iPhone+6s+Teardown/48170

KeyMaster is a KMS that QM uses as such it holds (or well manages) access to encryption keys.

I'm not 100% sure if KM is only used to store "user" keys such as encryption keys for FDE or does it also has access to other keys stored on the hardware key storage such as the ones used to verify the firmware and OS images allowing you to bypass vendor restrictions that prevent running unsigned bootloaders, firmware, and OS images on the device.

That said QM's TrustZone kernel AFAIK pretty much runs as root (and somewhat even higher) so ACE vulnerabilities in it can be effectively used to execute any command with root or higher privileges regardless if you can fully "root" the phone or not.

Trustzone runs an RTOS-like kernel, he likely hacked Qualcomm's implementation of this kernel to gain access.

In particular this line in the screenshot hints at what he did: "Overwriting syscall_table_5 pointer"

The issue is likely applicable on particular qualcomm devices, and a software patch should be possible.

Trustzone adds an additional protected mode to the cpu. IMO it complicates the CPU and adds no additional security - it's not like other protected modes in the cpu are less secure, or more hackable.

The assumption is that yes, other modes are more hackable because they're running much larger kernels. The code inside TrustZone is supposed to be much smaller, more focused and thus more easily auditable.

Unfortunately the constant stream of hacks of TrustZone applets that amount to "I smashed a buffer on the stack and got access" make me think that too often people forget the "more auditable" part.

And then you have on x86 the Intel Management Engine, running a whole graphics, audio and network stack, and a full JVM, and you notice that the promise of "more auditable" was just a smokescreen, and it really is just about DRM and backdoors.

Granted that details are not there yet (but from previous work done by the author one can guess), would a formally proven OS like seL4 have prevented this? seL4 is somewhat weak on HW support but the functionality required in the secure domain doesn't do much I/O anyway.

FWIW, formal verification requires a complete and exact spec - the TZ kernel is very complex and interacts with nearly all the peripherals on the SoC, it doesn't just manage QSEE applications. I think creating a spec for something like that would be really hard.

The whole point of using seL4 is that you can use it to provide guaranteed isolation. If you were to use seL4 it would be so that you could write those drivers in user mode and so that a bug in one would not let you extract crypto keys in another.

I hope there is a way to patch this remotely. TrustZone is on quite a few devices today.[1]

If it's not, well, uhh, yeah this is kind of a problem.

1. http://www.arm.com/products/processors/technologies/trustzon...

Keymaster is a Key Management application that runs "ontop" of TrustZone this doesn't mean that TrustZone or even QM's (hardware) implementation of TrustZone is flawed.

It's more likely than not just a flaw within Keymaster itself, or within the Trustzone Kernel which means that this can effectively be patched, this isn't the first time vulnerabilities like this have been identified[0] (same author) and previous issues have been patched.

For anyone who wonders TrustZone is a Trusted Execution Environment (TEE) technology for ARM CPU's the more known equivalent is probably Intel's TXT, it's not something QM has (solely) developed internally and an underlying issue with TZ can affect many more SOC's than just QM's (since AMD also uses TrustZone[1] this could potentially also affect desktop/server CPU's).

My personal bet would be that this is an issue with Keymaster, or the TZ Kernel that QM has built not with TZ itself on a hardware or even microcode level and most likely very possible to be patched.

[0]http://bits-please.blogspot.co.uk/2015/08/exploring-qualcomm... [1]http://www.amd.com/en-us/innovations/software-technologies/s...

What is TrustZone being used for in practice?

it's used for stuff like trusted firmware, and easily leads to devices being bricked

iPhones secure enclave, full disk encryption, Touch ID, etc. likewise on android.

Source?

He's a troll.

iPhones don't use it. They don't use Qualcomm SOC's.

Note that TrustZone is not a Qualcomm technology, but rather an ARM technology. Apple could have gone with TrustZone in their SOC.

(But yes, he is a troll and this whole case has nothing to do with Apple).

Nit: TrustZone isn't a Qualcomm technology, but KeyMaster is Qualcomm software built on top of it (and that appears to be where this break lies).

>iPhones

nah

Apologies to the uninformed downvoters :(

TrustZone is an ARM thing, and the iPhone Secure Enclave is indeed built on TrustZone.

Apple do not use Qualcomm and this a Qualcomm-specific bug. But Apple do use their own modded TrustZone.

http://www.apple.com/business/docs/iOS_Security_Guide.pdf page 7.

Despite widespread rumour to the contrary, the secure enclave on iPhones is a separate core, not just TrustZone on the main CPU.

Apologies, I stand corrected. All I've ever heard is it being explained as Apple's implementation of TrustZone, which conceivably could be modded so far as to be put on a separate coprocessor.

DRM for example, see this older post where a bug in Qualcomm's DRM software enabled full system compromise: http://bits-please.blogspot.com/2016/05/qsee-privilege-escal...

To provide the Android hardware-backed keystore [1]

If it's present, this is used by apps like 'Google Authenticator' and 'Symantec Vip access' to store credentials in such a way that they can't be copied off the device or backed up.

When this technology works perfectly, the idea is if you have a short passcode and someone steals your phone, they can't extract the encrypted data and brute-force the passcode without an electron microscope and a team of engineers.

Unfortunately, it can also be used for user-hostile applications like providing DRM and preventing backups and rooting.

[1] https://source.android.com/security/keystore/

Do you have a link documenting that Google Authenticator (or Symantec) uses it?

I'm reasonably certain about Symantec Vip Access, because I've decompiled it (download apk 3.1.3 -> dex2jar -> jd-gui). Class named ṝ method named ˎ make calls that look like calls to the android key store. Hard to be 100% certain because the code is obfuscated though.

I was wrong about Google Authenticator. I assumed it was the same as Symantec because of all the people online complaining about being unable to back up their credentials.

This is not used by Google Authenticator. GA just keeps the parameters in an sqlite database. It doesn't do much to protect them.

How would this be patched? I'm assuming that this will require ucode/hardware patching as trustzone is implemented in hardware?

My understanding was that there's a signed TrustZone binary that's more or less an ELF that runs in secure mode.

If TrustZone itself has a bug, that would require a hardware patch. Luckily it seems that this bug was an issue with the code running on the chip.

With TrustZone, some code is running in the secure domain and can read or write to both secure and non-secure memory. You need to find some bug in the secure code to "trick" the secure code into copying data from secure memory to non-secure memory.

you dont post about this on twitter you wait

When someone asks if you're a (security) god, say NO!

(... unless you are one)

See, this is why Twitter is a terrible news medium. TrustZone is the company I buy SSL certificates from, so what do you think people like me assume has happened?

A little context wouldn't have hurt anyone.

> QualComm ... TrustZone

I think to most people following him, it's clear this is about ARM TrustZone.

I think this was a joke, before it got downvoted into oblivion.

So now we know how the fbi got into the shooters phone :)

It was an iPhone. Not Qualcomm.

Maybe read a little bit before down voting ? Quallcom is a chipset manufacturer Iphone is a device, has it occured to you that iphone might have quallcom tech in it ?

Maybe you should read? The secure enclave is completely separate to TrustZone on an iPhone and has nothing to do with Qualcomm.

"Inside, the 5c packs the same Apple A6 processor featured in the iPhone 5, a Qualcomm MDM9615M LTE modem, and a Qualcomm WTR1605L LTE/HSPA+/CDMA2K/TDSCDMA/EDGE/GPS transceiver. The back of the logic board features assorted power management, flash, and controller components from Toshiba, Qualcomm, and Broadcom, as well as a Murata Wi-Fi module. "

Iphone 5c has qualcomm stuff in it.

:facepalm:

TrustZone is an ARM thing for the general-purpose computer on the device. The modem and radio are not relevant to discussions on TrustZone.

You're trying too hard.

Repeated from above: The iPhone 5C predated the introduction of the secure enclave. The 5C contains an A6 chip; according to page 7 of https://www.apple.com/business/docs/iOS_Security_Guide.pdf, the secure enclave is only available with A7-based devices or newer.

The phone the FBI got into have a secure enclave though, IIRC.

You aren't talking about the San Bernardino iPhone 5c that had a A6 series CPU which predated the introduction of secure enclave are you?

We aren't in a thread about the FBI getting into a "shooter's" iPhone...aren't we?

E: ah, my original post is missing a negation. Too late to edit.

Is it not true that you did not intend to answer a rhetorical question with a rhetorical question as a negative confirmation, is it?

I assumed my prior posting was correct and that you had somehow missed critical context.

Edit: many in this thread appear to be missing critical context, as the secure enclave is not in play.

The iPhone 5C predated the introduction of the secure enclave. The 5C contains an A6 chip; according to page 7 of https://www.apple.com/business/docs/iOS_Security_Guide.pdf, the secure enclave is only available with A7-based devices or newer.

Reply on news.ycombinator.com