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.
Devil's advocate (and I could be wrong on this count.) Part of the TLA groups function is not just spying, but the other element. Preventing that country's interests from getting snooped. This is why NIST has guidelines [1] as well as info on the latest exploits that are around.
With the possibility that the other guys may have just the backdoors as the NSA does, it makes upping the ante logical. Better nobody be able to read info than just your enemies. Again, this is pure conjecture, but the NSA/NIST has done a lot of work with security in operating systems and it has helped greatly with security over time, be it the sandbox in OS X, SELinux, OS hardening in Windows so the two main vectors are Dancing Bunnies and browser add-ons.
Android's FDE is woefully inadequate, unless you have root and use an app like EncPassChanger or perform the changes in bash. Then, after you set a real passphrase on boot, the device will be secure (without needing to retype the long passphrase every time.) Apple places all their bets on the magic chip, and who knows if there is a backdoor in that. The chips are fabbed in China, and it would be trivial to add extra functionality to the mask. In fact, since the entire chip is designed in China, baking in added, undocumented "features" like password recovery or even a vector for bypassing signed code is entirely possible, and likely in place.
[1]: Basic stuff, but worth going through on various operating systems and devices to make sure nothing is missed.
The NSA (and other agencies) have noticed a significant drop in data, and an increase in the use of encryption/VPN/proxies/TOR since Snowden went public.
They realized more people were starting to take care with their data, so how to fix (read stop) it?
OK, first we have the NSA complaint corps (Apple, Google, Facebook, Twitter) code some "encryption" made out of tissue paper, then they send out the FBI (and other agencies) talking heads to publicly denounce this "encryption" as though they were seriously concerned.
Now people thinking they have encrypted their devices and are safe will once again become complacent.
But the real story is even more absurd, the fact that the average person believes they are of any interest to anyone but marketers.
"If any question why we died, Tell them because our fathers lied."
Just get Adblock already. It will spare you bandwidth, and increase your security (and your sanity).
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
There are a handful of companies able to do this, and a handful of well-funded amateurs with the capability to do this for 80's video game chips that everyone is desperate to pay £10k just to acquire (let alone emulate).
If you keep up with any of the MAME scene, the decapping projects are few and far between and pretty much one guy rules them all and it can take YEARS to decap a chip, and years more to understand what it does. On commercially available stuff from the 80's.
Security chips, etc. generally fall to statistical analysis and modern computing power, not someone looking inside the chip. And the keys in a TPM chip won't be stored where they can be "seen" while decapping - that reveals only the structure and to find out where to hook into in a complex encryption chip is quite a skill. To do so without disrupting the chip's operation (even if it has no security) is difficult. To extract actual useful data, even more so.
I'm not saying it couldn't happen, if a case came up with the military or NSA needed to get access to something stored on a TPM chip. But it's not something they'll be doing routinely. And you can "force" chip manufacturers all you like - most of the stuff we use does NOT originally come from the USA or from US-influenced countries. I'm not saying they're not compromised too, in some fashion, but it's not as easy as saying "We are the NSA, put in a backdoor". Most countries will tell you where to go, and get you into the international press for even trying (could even be considered an act of war if you tried that on the Chinese, for example).
Things aren't as simple as "everything is backdoored", "acres of supercomputers", "listening to every phone call", etc. That's all hyperbole. And it works on exactly the people it's intended to - the general public who have nothing of import to hide, and thus feel reassured that they're safe from nasties / scared that shouldn't become a nasty in case they get caught.
Any encryption you might use as a consumer is NOT intended to defeat a well-funded military adversary with reason to decrypt it. That might be possible, it might even be what encryption was invented for, but that's NOT the use-case of 99% of encryption out there. Don't think it is. Hell, we had the world's most popular SSL library have a flaw it in for 10 years and NOBODY NOTICED.
If anything, elliptic-curve cryptography is the weak-link. We're being forced onto it by being told everything else is weak. It's not as well-researched or understood as the algorithms that have been attacked for nearly 40 years. Implementations are few and based on published curves. And there's NOTHING being said about our move to it.
If anything, when you think the trick is happening, it's already been done.
If you search YouTube for "Black Hat DC 2010: Hacking the Smartcard Chip", you'll see a series of eight videos where a guy shows how he spent six MONTHS decapping TPM chips, finding ways around their layers of security, and eventually gaining access to the core's memory pins where everything is unencrypted. He was eventually able to come up with a process that takes only hours to tap a few pins into the TPM and dump everything.
The kind of backdoor I think is built into these chips is secret undocumented instructions that don't require decapping the chip and microscopes. Cut the pins of the chip and remove it from the board, then connect what's remaining of the pins to some device that allows you to control it according to the documented specs. Use a secret sequence of commands to dump all the keys.
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.
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.