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.
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...
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?
for me, and I think for a lot of /. readers, the biggest issue is comparing a solution that currently exists to vaporware that may exist in the future. The iOS solution is already implemented in the new OS which is on 50%+ of all iDevices after just one week. In contrast, 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.
As a community we've always been skeptical of vaporware, especially when a lagging company announces vaporware in response to an innovator releasing a tangible product. Can we hold android to this standard?
Presumably, the apps on the phone have access to the encrypted data on the phone, right? So there's a simple solution. The user is happily using their iWhatever. The government sends a Nation Security letter to Apple forcing them to put a backdoor into the phone of the target, such that this app can read whatever data it wants on the phone. So when the user boots up his/her phone, and enters the password, the rougue app should be able to read all the data on the phone.
Can anyone tell me why this WOULDN'T work?
Because National Security Letters cannot be used for that. They can only be used by the FBI to demand the handing over of data in the possession of or passing through the control of the receiver, not the performance of actions (and how the data is produced is up to the company receiving the NSL, not the FBI).
Now what is in the Cloud is a different matter since Apple would have access to that, though again it may be encrypted with a key only the iDevice possesses so Apple wouldn't be able to decrypt it for the FBI.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Thank you for your open response. A Q that you may have addressed elsewhere in the thread: How can Google put out a security solution that relies on a hardware feature, when it has minimal influence on the hardware designs? Does this mean that encryption will work *if* compatible hardware is provided, and if it's not provided the coverage is much weaker? Will the user be informed of this? On what percentage of devices is it expected to have the needed hardware?
kthx.
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.
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.
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.