Slashdot Mirror
Details of iOS and Android Device Encryption
swillden writes: There's been a lot of discussion of what, exactly, is meant by the Apple announcement about iOS8 device encryption, and the subsequent announcement by Google that Android L will enable encryption by default. Two security researchers tackled these questions in blog posts:
Matthew Green tackled iOS encryption, concluding that the change really boils down to applying the existing iOS encryption methods to more data. He also reviews the iOS approach, which uses Apple's "Secure Enclave" chip as the basis for the encryption and guesses at how it is that Apple can say it's unable to decrypt the devices. He concludes, with some clarification from a commenter, that Apple really can't (unless you use a weak password which can be brute-forced, and even then it's hard).
Nikolay Elenkov looks into the preview release of Android "L." He finds that not only has Google turned encryption on by default, but appears to have incorporated hardware-based security as well, to make it impossible (or at least much more difficult) to perform brute force password searches off-device.
Matthew Green tackled iOS encryption, concluding that the change really boils down to applying the existing iOS encryption methods to more data. He also reviews the iOS approach, which uses Apple's "Secure Enclave" chip as the basis for the encryption and guesses at how it is that Apple can say it's unable to decrypt the devices. He concludes, with some clarification from a commenter, that Apple really can't (unless you use a weak password which can be brute-forced, and even then it's hard).
Nikolay Elenkov looks into the preview release of Android "L." He finds that not only has Google turned encryption on by default, but appears to have incorporated hardware-based security as well, to make it impossible (or at least much more difficult) to perform brute force password searches off-device.
STOP THE VIDEO ADS SLASHDOT!
THEY EAT ALL MY (meager) BANDWIDTH AND RELOAD CONSTANTLY!
I CANT LEAVE A SLASHDOT TAB OPEN WITHOUT HEARING RANDOM SOUND 15 MINUTES LATER!
THIS SITE IS BECOMING UNUSABLE.
IVE NEVER NEED THE REMOVE ADS FEATURE AND NOW THAT I NEED IT I CANT FIND IT. HAS IT BEEN REMOVED?
IVE NEVER USED ADBLOCK IN MY LIFE AND IM GOING TO HAVE TO DOWNLOAD IT FOR SLASHDOT! NEWS FOR NERDS INDEED. MORE LIKELY ILL JUST STICK TO REDDIT, I SEE THE SAME STORIES ON THERE DAYS EARLIER.
sTop it sTop IT stOP IT stOP it StOp iT STOp It stoP IT sTop iT SToP it sTOP it stOp iT stop iT stop IT Stop iT stOp IT StOP it stOp iT sToP IT sToP It StOp iT StOP It sToP iT StoP it STOP it sTop iT STOp It sToP IT stoP It STOP it STop It stoP IT sToP It stoP It STOp It StoP IT sTop It StOp IT stOp It Stop IT SToP It STOp IT stOp IT STop iT SToP It SToP iT SToP IT SToP IT sToP IT stoP it sTOp IT STOP IT StOP IT Stop IT StOp It stOP iT SToP IT stop it StOP it StOp iT StOp iT StOp IT stOP it STOp iT SToP it sTOP it StoP IT sTOp It StOp It sTop it StoP iT StOP iT StoP it SToP it StOP it sTOP iT stop It STOp It sToP it sToP IT sToP IT
random capitalization courtesy of: rANdoM cAPiTalIZATIon GeneraToR
OK, I TFTA. It says that the only reason Apple could "access" the device before is that only certain things on the device were actually encrypted, like mail. Other items like text messages and photos weren't, so simply bypassing the passcode request through custom firmware was all they could do. Now Apple's OS is encrypting the text messages, photos, and so forth, so it really does require cracking the passcode to get in. Offline cracking won't work since part of the key is the device UID and it is loaded into a special part of processor that is hardware designed to not allow it to be extracted. This means you have to use the phone itself to try and crack the passcode, and again the hardware is built to enforce minimum timings on password tries thereby limiting how fast a brute force can happen.
So again, where does this article say that the NSA still has a backdoor?
I can't confirm that L is using hardware security for disk encryption. Elenkov decided that we are in his analysis, but you'll have to read his words to decide if you believe it.
However, I can definitely confirm that there is a hardware-backed crypto service in most of the better Android devices. It's called keymaster. Google creates the API and the code that uses it, and device makers have to implement it, or not. To see if your device has it, go to Settings->Security->Credential Storage->Storage type and see if it says "Hardware-backed".
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
a couple corrections to your inaccuracies (intentional?):
* iphones back up automatically to icloud.
* the exploit in #celebgate #thefappening was taking advantage of weak passwords and/or reset questions. it's not that the infrastructure was insecure, it was user error in selecting weak passwords / reset questions.
* in response apple has widely rolled out two-factor. some people will always set their passwords to be '12345', but at least with 2FA being very easily accessible then people have less and less of an excuse.
Are we good now? kthx.
Based on the articles and other published documentation, the Android "hardware backed" key stores are in fact not hardware backed at all, but rather based on the ARM chips TrustZone technology.
Yes, this is correct. The Android crypto HAL (keymaster) can be provided by any "secure" device, but at present I believe all of them use TrustZone, at least on ARM devices (Intel has something similar, but it's not the same).
But this comes with a huge caveat. This "secure world" is in fact just the same CPU running a program written in C. Such programs can of course have exploits.
Sure they can. The benefit, though, is that the secure world code can and should be dramatically smaller and simpler than the non-secure world, and therefore amenable to much deeper security auditing. This is actually no different from what Apple does with their security chip... which still runs software written by people and can have exploits. There are some security benefits to being on a truly separate CPU, but that doesn't change the fundamental fact that exploits are always possible.
What's more, I think it's deeply uncertain how exposed programs running in this secure space are to side channel attacks e.g. via timing or cache line games.
The same issue applies to separate CPUs, and the same countermeasures apply as well, though I'll absolutely grant that it's a harder problem on a virtual secure CPU.
And where does this secure program get its entropy from? A hardware RNG? Maybe, but as far as I can tell that's entirely up to the phone manufacturer, and in a competitive environment where everyone is trying to get costs down I suspect some manufacturers would choose to save money by skipping it.
All the devices I'm aware of provide a real hardware RNG. The cost is negligible, in fact it would probably cost more to remove it from the SoC designs than to leave it in. However, that still leaves open the question of how good the hardware RNG is. For the next generation of keymaster I'm trying to define some requirements around how it's used that should mitigate many possible weaknesses, and I'm also defining a mechanism that apps can use to inject some entropy of their own, in case they don't trust the RNG (assuming they have a place to get entropy). Note that injected entropy is required to be securely mixed into HW-generated entropy, so it should not be possible to inject data that actually decreases the available randomness, nor to manipulate the outputs, unless the attacker can also manipulate/predict the HW RNG.
The Apple implementation, in contrast, appears to have the per-device key blown into the chip at manufacturing time, and then hard-wired to the AES circuitry. That is, it's actually hardware based and there are no chances for a "VeriLog overflow" bug or equivalent breaking the security of the system.
TrustZone-based devices also have fused per-device keys which act as the root of trust. The devices that I'm familiar with also have a hardware AES coprocessor which can load and use these per-device keys but will not reveal the actual key bits, not even to secure world code. Secure world code can request operations be performed with the keys, but not see them. Non-secure world code can't do anything except make requests of the secure world code.
Anyway, I'd like to give kudos to swillden here for taking part in the discussion and being honest about how his work on Android currently stacks up with Apple.
Thanks for the insightful response.
Also, there's more to security than disk encryption.
Vastly, vastly more. It's one very small piece of a large, complex and ever-shifting puzzle. With respect to mobile device security I think it's actually one of the less-important pieces, because the set of problems it solves is pretty narrow. It gets a lot of press and discussion because it's easy to understand.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Android's, even without the upgrades in L, is strong enough in many contexts and it'll be even better after L, but still not as strong as iOS.
Could you expand on that? FDE with a hardware keystore is pretty decent. What more is iOS doing?
Unfortunately, I can't expand on it, not until L is actually released. Once the code is available I'll be happy to talk about the pros and cons, but it's not my place to reveal details of unreleased Android code, and I can't usefully discuss the differences without getting into the details. Ideally, a real discussion would be based a deep understanding of the details of both. We'll probably never have that deep insight into iOS, but once L is released we can at least compare known details of L with good guesses about iOS.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.