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.

Comments

Re:So what you're telling me

[x0ra]

What did you believe ? Who's enough of a fool to believe acronyms agencies will let Apple, Google or Microsoft decide on their own ? Not at this scale. Agencies won't mind if a tech entrepreneur try to get his share of the pie, but he will forever be insignificant. Once he become big enough, he'll join the group as everybody else, just to stay in business because the feds will certainly have found a non-compliance from a dusty law book.

This whole thing is just a marketing show to re-gain the average customer not-so lost trust...

Re:So what you're telling me

[swillden]

Google's solution is promised for the next version of Android which will be released on TBD. This version will be used by new devices but likely trickle back to just a small percentage of old devices.

This is true, of course, but it should also be remembered (as Elenkov explains in detail) that Android's encryption features aren't new, they exist in hundreds of millions of devices already deployed. And, L isn't really "vaporware". If you want you can go download it now, though not in its final form. Elenkov's evaluation was based on real code running on his device.

I should make clear where I stand here: I'm an Android security engineer. I work on the hardware-backed crypto infrastructure (the infrastructure that Elenkov says is used in disk encryption for L).

If you'd like me to compare Android and iOS encryption, I'm glad to: Apple's is better. 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. One thing Android has done better is to encrypt the entire user data partition. With iOS8, Apple has (probably) addressed the issues it had there. I can't talk about future plans, but I will say that I'm not yet satisfied with Android's disk encryption. It's good, but it can and should be better. I'm not sure we can ever match Apple in this area, since Apple has the luxury of focusing on a single device and has complete control of the hardware. But we can get closer.

Can we hold android to this standard?

I would hope so. I do.

Re:So what you're telling me

[IamTheRealMike]

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

I think it's worth noting something here about the Android implementations. 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. This creates a secure world inside the CPU which is isolated from the main operating system. The secure world can store data and do computation on the main CPU without being exposed to viruses or root level access from Android itself.

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. And in the past this is exactly what has happened, I believe some Motorola device was rooted in this way in fact, because the TrustZone protected program had some kind of overflow bug in it and that was enough to take control of the secure space.

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. People keep discovering clever ways to recover secret keys when running on the same physical CPU that shouldn't be possible according to the rules of the sandbox. 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. After all bad randomness looks the same as good randomness.

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.

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. That takes some bravery. Also, there's more to security than disk encryption. The Apple celebs drama wasn't caused by the NSA breaking disk encryption, it was a bunch of pimply 4-channers phishing or guessing account recovery details on the cloud service. Whilst Apple has historically been ahead of Android in on-device security, they have been behind Google on cloud account security and this is in many ways equally as important.