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

If you can't crack the password, then don't.

[Vellmont]

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?

Re:If you can't crack the password, then don't.

[dunkindave]

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.

Re:So what you're telling me

[Noah Haders]

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?

Re:So what you're telling me

[Noah Haders]

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.

Re:So what you're telling me

[Anonymous Coward]

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.

Here's how it works

[koan]

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.

Re:Backdoor in TPM chips?

[ledow]

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.

Re:Backdoor in TPM chips?

[Anonymous Coward]

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.