Holy crap, that was brutal. I don't think you can get any closer to accusing someone of incompetence without actually coming out and saying so directly. If Samsung et al are this cavalier about the trust zone, what is the state of the rest of their systems, which presumably have orders of magnitude more code? Suddenly, all the reports about the thousands of bugs in tizen don't seem like exaggerations anymore.
On a different note, how does the iPhone's trust zone implementation compare? Does anyone know if it is vulnerable to similar issues?
The secure enclave processor is isolated in silicon (even the memory controller enforces access control through encryption), and Apple doesn't have to support unlocked bootloaders. SEPOS isn't simply a TEE.
There was a nice in-depth analysis of the SEE at [0]. Furthermore, Apple has been very fast in fixing security issues, and rolling out updates to all of their user base, as opposed to the "These issues probably will never be fixed, buy an S8 instead" mentality shown from the Android vendors.
Google pay 97$ per hour my last pay check was $8500 working 1o hours a week online. My younger brother friend has been averaging 12k for months now and he works about 22 hours a week. I cant believe how easy it was once I tried it outit!...http://www.smartfinancemedia.com/?682
Since the “Secure World” just runs a different stack of memory-unsafe software, it’s not cool that Android’s UI characterizes TEE-based FDE key derivation as “hardware-based” “credential storage” giving the user the incorrect impression that it’s based on dedicated hardware, when, in fact, the setup is much weaker than an Apple-style Security Enclave design for FDE key derivation.
Although I was prepared to be impressed by project zero's work here I find that I'm not.
There's an efuse based revocation mechanism. It isn't used for every vulnerability. That's unfortunate but understandable-- fuses are a scarce resource. Given that, signers should be more careful about the code they sign in the first place to avoid stressing that resource.
Having said that, at the end of the day this is still just a security feature that is painful to use. That doesn't make it a vulnerability in and of itself, and dressing it up as one feels like a stretch.
I'm not sure why not. Some of the same groups that sign this code also do formal verification of other codebases, for instance FSBLs. It seems reasonable that they would try similar approaches on TZ code given the scarcity of fuses.
"Intel did it" is a pretty horrible argument, historically.
Especially with things like higher-than-OS trust levels where there are limited ABI guarantees to begin with, it might be better to redo things incompatibly if that provides a better solution than "this newly introduced mechanism of unknown quality asserts that this other mechanism of known-bad quality won't mess things up".
Intel TXT is one such "guard" mechanism. It tore larger holes in the security fabric than the mechanisms it was supposed to keep watch over.
To some extent that's how Intel SGX works, since code in an enclave (SGX name for a TEE) only executes with user level privileges and can't e.g. execute system calls.
On a different note, how does the iPhone's trust zone implementation compare? Does anyone know if it is vulnerable to similar issues?
[0] https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De...
[0]: https://xerub.github.io/ios/kpp/2017/04/13/tick-tock.html
There's an efuse based revocation mechanism. It isn't used for every vulnerability. That's unfortunate but understandable-- fuses are a scarce resource. Given that, signers should be more careful about the code they sign in the first place to avoid stressing that resource.
Having said that, at the end of the day this is still just a security feature that is painful to use. That doesn't make it a vulnerability in and of itself, and dressing it up as one feels like a stretch.
I agree with your sentiment, but that's not going to happen.
Even an automated exhaustive verifier can be buggy... oot more importantly incomplete if parallelism is considered.
(Don't laugh: Intel's been adding extra security layers for years)
Especially with things like higher-than-OS trust levels where there are limited ABI guarantees to begin with, it might be better to redo things incompatibly if that provides a better solution than "this newly introduced mechanism of unknown quality asserts that this other mechanism of known-bad quality won't mess things up".
Intel TXT is one such "guard" mechanism. It tore larger holes in the security fabric than the mechanisms it was supposed to keep watch over.