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.
STOP THE VIDEO ADS SLASHDOT!
THEY EAT ALL MY (meager) BANDWIDTH AND RELOAD CONSTANTLY!
I CANT LEAVE A SLASHDOT TAB OPEN WITHOUT HEARING RANDOM SOUND 15 MINUTES LATER!
THIS SITE IS BECOMING UNUSABLE.
IVE NEVER NEED THE REMOVE ADS FEATURE AND NOW THAT I NEED IT I CANT FIND IT. HAS IT BEEN REMOVED?
IVE NEVER USED ADBLOCK IN MY LIFE AND IM GOING TO HAVE TO DOWNLOAD IT FOR SLASHDOT! NEWS FOR NERDS INDEED. MORE LIKELY ILL JUST STICK TO REDDIT, I SEE THE SAME STORIES ON THERE DAYS EARLIER.
sTop it sTop IT stOP IT stOP it StOp iT STOp It stoP IT sTop iT SToP it sTOP it stOp iT stop iT stop IT Stop iT stOp IT StOP it stOp iT sToP IT sToP It StOp iT StOP It sToP iT StoP it STOP it sTop iT STOp It sToP IT stoP It STOP it STop It stoP IT sToP It stoP It STOp It StoP IT sTop It StOp IT stOp It Stop IT SToP It STOp IT stOp IT STop iT SToP It SToP iT SToP IT SToP IT sToP IT stoP it sTOp IT STOP IT StOP IT Stop IT StOp It stOP iT SToP IT stop it StOP it StOp iT StOp iT StOp IT stOP it STOp iT SToP it sTOP it StoP IT sTOp It StOp It sTop it StoP iT StOP iT StoP it SToP it StOP it sTOP iT stop It STOp It sToP it sToP IT sToP IT
random capitalization courtesy of: rANdoM cAPiTalIZATIon GeneraToR
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?
AccountKiller
Is iCloud encrypted under the consumer's key? That seems like the smart thing to do, though I imagine it could make sharing folders across devices a bit tricky.
Plus solving the brute-force problem, of course.
Encryption can be rock solid -- still the pass phrase be sniffed
Anything typed into a device that has connectivity is floating out there.
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."
There have been backdoors in consumer electronics since the 90's.
TPM is no exception.
"If any question why we died, Tell them because our fathers lied."
Comment removed based on user account deletion
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 want to address this statement here, because I feel it's misleading.
Elliptic curve cryptography has been researched since the 1980's. It is not at all crazy or new. It is the current state of the art, RSA is obsolete and learning-with-errors is the current best candidate for a next-gen post quantum crypto system, as far as I can tell.
Nobody is being "forced" onto ECC by being told other things are weak. To the best of anyone's knowledge, RSA is not weak given big enough key sizes. However, ECC is just as strong when used with much smaller keys and signatures, and can be much faster. Basically you halve the key size with ECC to get the security level. So a 256 bit key gives 128 bits of security, i.e. you would need to try 2^128 times to cover the entire key space, which is physically infeasible. Whereas you need perhaps a 2048 bit RSA key to get gold standard security. Additionally ECC has various other nice features that can be useful in certain contexts.
Implementations of ECC are widespread. Every OS comes with one out of the box and implementations are available for every reasonable language and platform.
Finally "based on published curves". Yes, ECC requires people standardise on some public parameters to use it. That's no different to HTML or TCP or any other standard. The one caveat that exists here is that for the secp256r1 curve (which is widely used in ECC based SSL) the curve parameters were chosen by the NSA. However, (a) nobody knows any way that this could introduce a weakness despite decades of research into ECC and (b) there are many other curves where the parameters were not chosen by the NSA, for example Curve25591 where the parameters were not only chosen by djb but every parameter has an explanation for why it's the best value that could be chosen. There's no flexibility or magic numbers in its design at all, but it's still ECC.
The good news is that the secp256r1 curve has basically no redeeming qualities at all, except that it's one of the oldest and so support is widespread. All new applications that get a free choice of curve are being based on a modern modern one like Curve25591 or secp256k1 (bitcoin), where the parameters are much more rigid and there are no ways to insert back doors.
Though I agree with your post, and am aware of the majority of it but maybe couldn't reel off the exact curve names, there are problems here.
There are a number of areas where EC is being "forced".
Perfect Forward Secrecy is one (one that you hadn't heard mention of in general IT circles). Yes, there is a non-EC way to do it, but it's horrendously slow compared to the alternative. The only way to get PFS is to use EC. We're being told to abandon RSA and move to EC, in no uncertain terms in other areas. But, as you point out, RSA is still viable. Which raises more questions.
EC curve choices are things that should not come down to "one person / organisation" - no matter how much you trust djb (and he gets a certain level of respect because every bit of his software is pretty damn good on the security front), it should not be a question of trust in an individual to form a curve.
Public Key Encryption, in general, requires no magic numbers, fixed initialisation vectors, "parameters" or similar. Hashes, possibly, but PKE, not. You choose two huge primes that only you know and that's the end of it. To have to resort to "picking" a particular curve *is* akin to placing some magic number and mixing it with the primes in question - this is territory that's not to be trusted if it's to form the basis of the world's encryption standards.
For a start, as you show, the NSA curve was chosen and got into widespread circulation before anyone really noticed. If nobody knows any way it could be a weakness, do we know any way that it's a strength? And the answer is no. Which is questioning the entire use of such a chosen curve.
The parameters that need to be agreed were obviously agreed on by the NSA for some reason - hostile or not. That reasoning is different to other curves and other people's choices which, in itself, is a weakness on one side. Either we're choosing curves that the NSA is avoiding, or they're choosing curves that we're avoiding. And that's just a mess for an algorithm that needs to take over the world's data security.
I'm a mathematician, but I have to say that the exact mathematics is beyond me nowadays. However, as "suspicious IT guy" with no reason to believe in conspiracy theories, government collusion or any other crackpot schemes, it worries me that we can't agree on curves and that such agreement is even necessary.
The wonderful things about standards is that there are so many of them to choose from. But the wonderful things about security is we need one well-defined way, and to constantly work on a single replacement for it. EC, in that regard, is suspiciously popular and dangerously configurable without explanation.
Encryption is only one part of the announcement. Apple also said that they're not going to sell your data, for the most part. What did google say about that?
Google is an advertising company. Of course their going to sell your "anonymous" data.
Here's how I do it:
http://osxdaily.com/2014/02/16...
Timtowtdi of course
I'm about to go into a meeting where we're going to design a security architecture for a government agency involved in cybersecurity. While designing it, I'm going to watch out for the error GP made by implication, which is:
Today's topic is encryption of data on mobile devices.
A method of bypassing the encryption was suggested.
Gp (and you) essentially argue that the encryption doesn't need to be solid because sandboxing.
Next week, the same logic would argue that sandboxing doesn't need to be strong because encryption.
Result: Neither sandboxing nor encryption are as strong as they could be.
That's depths of weakness, not depths of defense.
One answer that adds a layer of security would be to encrypt application- private data with an application- specific key. That way, the encryption prevents an app from accessing app-private data, providing a second layer on top of the sandboxing.
What's now required in laptops and mobile phones is a "dead-man" switch where if the user stops doing something after a certain period of time, the device switches off and all crypto keys in memory are lost. That may not be convenient for mobile phones, but if you look at how the Dread Pirate Roberts was caught - in a library by FBI determined to not let him turn off the laptop - then a dead man switch (software or hardware) could have shut his laptop down before they had time to dump its RAM to disk or similar.
the other day. Here's what happened:
1) Performance sucked ass, despite reports to the contrary (i9300 -- I know it's no G3, but hey, it should damn well be enough, at quad-1.2 gHz with a gig of RAM)
2) My TWRP restore didn't include my home partition so I lost all data on there. Sucks to be me.
I'd welcome this if it didn't come at the massive lag that I experienced on a device which is normally quite spritely. I get that encryption doesn't come for free, but adding 1-3 seconds lag to every tap is not, in my book, worth it. I'd rather just use the android device manager to remote wipe if I lose my phone.
Try to change it with vpc. You are NOT asked for your old password.
With for example LUKS this is not possible, as the linux kernel does not give you the password of the unlocked device, which is needed to encrypt it with the new key.
AC asked: How would apple or said letter agency install ...
Plumpaquatsch replied:
a way that doesn't require access to the Apple-ID account sure would be better
I'm fairly sure that Apple already has access to your Apple account, and the NSA or other three-letter agency can get access whenever they feel like it. Heck, I only work for a FOUR-letter agency, and I can personally access most Apple accounts.
Google's security isn't awesome. Therefore, you reason, Apple's must be perfect, because you're a fan. Do you throw your panties on stage at Apple events?
When you grow up a little bit, you'll come to understand that a) fanatacism toward a company like Apple (or Google) just means you're easily manipulated by marketing and b) all companies, all products, and all services have limitations - especially security limitations. The fact that users routinely forget their passwords makes it extremely difficult to secure mass-market services like iCloud, Gmail, Facebook, etc. When you have millions of users, tens of thousands of those will forget their passwords each year. Therefore, you _must_ make it possible to access the account without knowing the password. Because many of the users who forgot their passwords are technically unsophisticated, you must make it _easy_ to access the account without knowing the password.
If you'd like further details on exactly how it's done, refer to any of my earlier posts or posts by swillden.