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.
Is that the NSA still has their backdoor.
Encryption can be rock solid -- still the pass phrase be sniffed
Anything typed into a device that has connectivity is floating out there.
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.
It's impossible to cut a hardware vendor out of the trust system, unless you audit the hardware of your device. But set this aside.
This won't work because apps never see your password or have access to the decryption keys. The CPU itself doesn't have access to the decryption keys and doesn't even do the crypto algorithms. When the CPU needs to access some data that's encrypted in memory or on the Flash drive, it tells the secure enclave and writes the data to its input. The enclave then decrypts the data, with keys it keeps in its own non-volatile storage, and writes the decrypted data back to the CPU. In the case of the fulll-disk encryption or the fingerprint encryption, at no time do any keys pass into the CPU, let alone get written to RAM. The CPU can order the enclave to create new keys or keypairs, it can enumerate and name them, and associate them with metadata outside the enclave, but it can't actually read the keys themselves.
Don't blame me, I voted for Baltar.
I think you may have missed GP's point. The key protects the data. When the user enters the passphrase, the data is decrypted and apps can access all the data. Therefore, you don't NEED the key if you can put an app on the phone, then the user uses their phone. The encryption is useful only on a stolen or seized phone.
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.