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