.@dangoodin001 In regards to http://arstechnica.com/security/2016/07/androids-full-disk-encryption-just-got-much-weaker-heres-why/ …, it's only the OEM / OS vendor with the signing keys. Google only has those for Nexus.
-
-
Is this Android's choice or Qualcomm's choice? It's probably not done the same way by Exynos (Samsung), Tegra and MTK.
-
It's a fairly safe assumption that Intel > Samsung > Qualcomm/NVIDIA > MTK when it comes to security/robustness.
-
Tweet unavailable
-
Simply have a very dim view of the ability of Qualcomm and NVIDIA to design/implement low-level components.
-
Samsung's low-level code doesn't seem to be particularly bad. Leaning towards Tegra being saner than MSM too.
-
In CopperheadOS it has proven to be a very safe assumption that problems are caused by broken Qualcomm code.
-
Whether it's their camera driver, WiFi driver, graphics driver, radio services or all of their kernel holes.
-
No faith in a bunch of low-level code that is not even Valgrind / ASan clean in the non-exceptional paths...
- 3 more replies
New conversation -
-
-
As far as I understand it, you even saw the risk of that approach and changed it in Copperhead, right?
-
CopperheadOS allows and encourages using a separate disk encryption passphrase instead of relying on obfuscation.
-
Since the TEE/SE stuff is exactly that: obfuscation with a lot more sophistication assumed than it has in reality.
-
you're dancing around the issue. Apple UID key is kept in hardware. Android FDE kept in software.
-
Apple's interface to the SEP which brokers UID key is simplified, unlike QSEE etc which gets 0day dropped on it
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.