Revisiting Android disk encryption

http://nelenkov.blogspot.com/2014/10/revisiting-android-disk-encryption.html

by silenteh • 12 years ago

93 30 12 years ago

nelenkov.blogspot.com

aw3c2• 12 years ago

The dreadful "you must enable Javascript for this plain website" layout strikes again. So here is the summary of the article for the fellow plain HTML lovers:

Android has included full disk encryption (FDE) support since version 3.0, but versions prior to 4.4 used a fairly easy to bruteforce key derivation function (PBKDF2 with 2000 iterations). Additionally, because the disk encryption password is the same as the lockscreen one, most users tend to use simple PINs or passwords (unless a device administrator enforces password complexity rules), which further facilitates bruteforcing. Android 4.4 replaced the disk encryption KDF with scrypt, which is much harder to crack and cannot be implemented efficiently on off-the-shelf GPU hardware. In addition to enabling FDE out of the box, Android L is expected to include hardware protection for disk encryption keys, as well as hardware acceleration for encrypted disk access. These two features should make FDE on Android both more secure and much faster.

hhjj• 12 years ago

blogspot is really annoying about that. Adding ?m=1 works here: http://nelenkov.blogspot.fr/2014/10/revisiting-android-disk-...

philjohn• 12 years ago

Thing is, scrypt isn't a panacea - there are ways to make it CPU hard instead of memory hard - http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scryp...

kaoD• 12 years ago

Your link repeats again and again (and again) that his criticisms only apply to password storage. In his own words "as a Key Derivation Function, it is still very much useful and secure".

As GP said, Android uses it as a disk encryption KDF.

TheLoneWolfling• 12 years ago

Thank you.

blueskin_3• 12 years ago

Thank you for the sanity.

giovannibajo1• 12 years ago

In iOS 8, Apple has expanded the scope of data encryption and now mixes in the user's passcode when deriving an encryption key, making it harder to extract data from iOS 8 devices.

Not fully correct. In iOS8, the scope of DP (data protection) was enhanced to cover additional data with specific respect to the builtin Apple applications (SMS, photos, call logs, etc.). DP, since its introduction in iOS4, has always used the user's passcode as part of the encryption secret, and there are APIs available to create files and/or keychain items with data protection on.

Notice that there is an interaction between the multitasking/background system and data protection, as applications running background services will need access to a (part of) filesystem and (part of) keychain to operate. This is why the APIs have a very granular set of ACLs.

csirac22• 12 years ago

Obviously, a strong passcode is a must.

But that's a big ask not just for the obvious reason, but also because the Nexus 5 is the first phone I've ever owned which demands that I unlock it first before I can access the UI to cancel an alarm.

And even then, it's a game of chance (especially when the phone is upside down while you're asleep) whether your swipe is in the correct direction (apparently UI designs actually removed the visual cues which would normally guide the user toward the correct action).

wtbob• 12 years ago

But that's a big ask not just for the obvious reason, but also because the Nexus 5 is the first phone I've ever owned which demands that I unlock it first before I can access the UI to cancel an alarm.

Do you mean a firing alarm, or a pending alarm? One can cancel a firing alarm just by swiping, no passcode needed.

I would prefer to have to enter my code in order to cancel a pending alarm. Otherwise I can imagine practical jokers cancelling an alarm if they have the chance.

csirac22• 12 years ago

Not all the time, I must admit - but when I'm blindly poking my phone or it's just grabbed out of my pocket, some part of the screen (that for me is the most likely part) makes the swipe prompt disappear and is replaced with the passcode entry.

Given that I have my N5 in a case, perhaps it's an inadvertent button press. Still, the UI should always provide swipe access to disable an alarm while the device is blaring at me.

JshWright2• 12 years ago

I wish it was easier to decouple the passphrase for the key and the passcode to unlock the device...

They have _very_ different security properties. Offline brute forcing the unlock passcode is far harder (presumably it's stored in the encrypted fs), so a shorter code is fine. Offline brute forcing of the encryption key passphrase is much easier (as TFA explains), but I'm never going to use a 'good' passphrase there, as it would be far too annoying to have to type it every time I unlock the phone...

higherpurpose2• 12 years ago

Google needs to solve that part of the problem. Apple has already solved it with TouchID.

Google needs to do the same and mandate all OEMs must certify for fingerprint scanning technology (that has a high-standard of accuracy and security, not the gimmicks HTC and Samsung have tried before), or at least incorporate the same kind of technology Nymi uses in all Android Wear watches, so you can unlock the phones with that. Google should either acquire or replicate what these guys are doing:

http://www.getnymi.com/

ancientworldnow2• 12 years ago

It requires root, but Cryptfs (available in the play store and f-droid) enables just such a feature. In fact, it's written by this blog post's author.

http://nelenkov.blogspot.com/2012/08/changing-androids-disk-...

https://play.google.com/store/apps/details?id=org.nick.crypt...

mbq2• 12 years ago

That is a very good feature because forcing user to perform mentally demanding operation to dismiss the alarm decreases the risk of falling back to sleep (;

kabdib• 12 years ago

Hadn't internalized how essentially trivial it was to brute-force a PIN once you'd copied off the file system blocks.

With Android-L moving key material to trusted execution environments, expect interesting attacks on those. I am curious about state-mandated security holes in TEEs as well, since it's much easier to hide backdoors in chips than in publically reviewable software (I would much prefer to see a dedicated security processor than a "secure mode" of what is essentially the whole SOC).

jareds2• 12 years ago

I wonder if full disk encryption by default will render Android unusable to blind people such as my self? When I encrypted my Nexus 7 2012 running 4.4 it turns out that you are prompted to enter your password before the talkback screen reader starts talking. Needless to say this is a major issue and no one from Google appears to be interested in fixing it as far as I can tell. With my iPhone Voiceover comes up talking and allows me to enter my password while still having the device encrypted.

higherpurpose2• 12 years ago

The article seems to say that it won't require a password unlock again, after the boot one.

jareds2• 12 years ago

I can enter a normal pin or password if the device is encrypted since the operating system is completely loaded and along with that Talkback is. It's the boot password I can not enter because not enough of the operating system is loaded for Talkback to speak.

blueskin_3• 12 years ago

Default still implies it can be disabled. As it is, I'd guess it wouldn't be that hard to store the TTS somewhere unencrypted and load that first, perhaps as part of the bootloader.

zxcvgm• 12 years ago

Coming from iOS, one thing that I didn't really like about Android was how clumsy the decryption process was. The process is detailed here [1] and it involves the framework being put in a special mode that only handles password entry. In this mode, none of the regular services are running, so I'm not sure how incoming calls & SMSes are handled (or if they are even handled). It's like getting stuck at the boot screen with a password prompt.

In iOS, encryption is not performed at the block layer but at the filesystem level, and some files are encrypted with hardware-derived keys (thanks to a unique 256-bit AES key burned into the processor), allowing the OS to be booted normally, but not having access to certain files until the user enters his/her passcode (full details here [2]). Even if you don't immediately enter the passcode after boot, the phone is still in a somewhat functional state.

I'm glad that Android is taking steps to at least implement by-default disk encryption by relying on a hardware-backed key store.

[1] https://source.android.com/devices/tech/encryption/android_c...

[2] https://www.apple.com/privacy/docs/iOS_Security_Guide_Sept_2...

mbq2• 12 years ago

On the other hand, the more system is loaded without user input the greater chance that it can be exploited; also filesystem-level encryption leaks some meta information.

mentat• 12 years ago

If you don't have a hardware bound key as part of the KDF then you will be subject to extraction and parallel breaking. It may take more computing power with scrypt but it will be doable. KDFs enforce round constraints relative to the hardware they run on. Being able to extract from that hardware means being able to apply orders of magnitude greater processing and parallelization of that process. Hardware keys like Apple's are the only way to go.

blueskin_3• 12 years ago

Very interesting. I've always been wary of PBKDF2 for these applications simply because most people will have a 4 digit PIN (although I don't), which is essentially useless against an offline brute force attack, and possibly worse than useless if it gives people a false sense of security.

At least CM11 allows a dedicated FDE password though - Google is really doing its users a disservice by not implementing this in stock Android.

Revisiting Android disk encryption

Related Stories