Well hold on.. there are several issues. One is that there is an exploit allowing arbitrary code execution in the trustzone. This immediate problem should be fixed.
The second is that allowing a firmware updates to trustzone code means that Google could push an update which allows them to retrieve keys. Such updates should only be allowed if the user accepts them. How the user is supposed to know the difference between a security fix vs. Google trying to break into their phone is the real issue.
But IOS has this same issue. If you accept a firmware update from Apple, maybe it includes a pin logger.
You're right. Let's take a second to go over the issues:
1. The arbitrary code-execution in TZ has already been privately disclosed and fixed.
2. As for the second issue - I would argue that it's not an issue at all. TZ should be updated (otherwise how would they fix the TZ code-exec vulnerabilities?).
However, in this case gaining code execution in the TZ kernel directly leads to the disclosure of the keys which are meant to bind the KDF to your device. This is in direct contract with Apple's KDF. The key here is that software shouldn't be trusted, by design.
3. As for the last issue, I would argue that this is just a clever form of social-engineering. After all, who's to say they didn't just swap the phone with a dummy phone to make you insert the correct password?
However, in Android's case, you wouldn't even need to cooperate. OEMs could simply flash the new TZ code, extract the KeyMaster keys, and bruteforce the key. All without having any help from you.
The section on extracting the key mentions the "Widevine DRM application" and "privilege escalation from QSEE"
Could the problem be fixed if the manufacturer used TrustZone exclusively for store key/encrypt/decrypt operations, eliminating the support for DRM and Trustlets?
I'll definitely try and get around to it sometime soon. However, I wouldn't be surprised if the situation is the same... After all, the KeyMaster module was initially only meant to keep encryption keys on the device, not to safeguard FDE.
Sorry for an extremely nooby question, but your comment makes me wonder:
Are Snapdragon and Exynos architectures that alike? I mean, do you have any preliminary idea how easy it would be to apply your Snapdragon method to an Exynos SoC?
Actually, I would imagine they are nothing like one another.
However, Exynos uses a TrustZone TEE implementation to implement the KeyMaster module, just like Qualcomm's Snapdragon. This means that unless that TEE implementation uses a hardware key which is not software accessible, the same issue would be present. Of course, reverse-engineering a new TEE implementation would take a long time... But it sounds like it could be fun.
You should be aware that people like you are unsung heroes and I'd like you to know that many of us who are busy struggling to stay afloat are feeling better knowing that people like you are doing the work you do.
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.
Widevine DRM is integrated into virtually all Android phones. If you're building your own ROM, you could remove the widevine.bXX files from the ROM image itself - I've never tested it, but it could probably soft-fail. There's no other way to remove it.
Anyway, this specific issue has already been fixed (but there are probably more bugs lurking either there on in other trustlets).
People are trusting their phones to keep their business and private data safe. It is unacceptable to expose 2 billion devices to extra-privileged vulnerabilities to appease some MPAA executives in their completely ineffectual schemes to control how the world consumes content.
But you'll either need a version old enough to be vulnerable to this TrustZone exploit, or you can wait a couple of weeks until I release a new exploit (which also works on the Turbo).
Thanks! I'm also on twitter in case that helps (@laginimaineb).
As for Sunshine - I'm publishing a new (even broader) zero-to-TZ saga, complete with exploits, but I'm not going to create a product out of it. So ultimately, as long as there are people behind Sunshine who are willing to make it work with relative ease, I'm sure most people won't mind spending a few dollars to unlock their device.
As for the more tech-savvy crowd; I hope they choose to do it themselves with the exploits provided - it is much more fun that way, IMHO.
AFAIK it's unknown - there's a controller on the SoC which is responsible for reading/writing the fuses, but its firmware is in mask ROM and isn't available. Perhaps it's a real chemical reaction? Maybe it's just emulated in firmware? Your guess is as good as mine.
Is there a reason you didn't publicly disclose after 90 days? (I'd argue that the criticality of the vulnerability would justify a 7-day timeframe). The one problem with the way the security community deals with large vulnerabilities is that the researchers don't stick to their guns regarding responsible disclosure. I would prefer to know that I have to do <XYZ> to minimise the impact rather than find out that I was vulnerable for more than 5 months. Hell, I'd be happy to stop using my smartphone for a week if it meant the problem would be solved faster.
That's a great question! I didn't cover this in the blog post, but there is a primitive identical to the increment-by-one presented there, which allows me to decrement-by-one as well (I've gone into more detail in the exploit code: https://github.com/laginimaineb/cve-2014-7920-7921)
