
Revisiting Android disk encryption - silenteh
http://nelenkov.blogspot.com/2014/10/revisiting-android-disk-encryption.html
======
aw3c2
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.

~~~
philjohn
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...](http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html)

~~~
kaoD
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.

~~~
comex
But why do they only apply to password storage? In both use cases cracking
proceeds by running a lot of possible passwords through the algorithm and
doing a cheap verification operation at the end - "does using this hash as a
decryption key produce something that looks like ext4" is more expensive than
"is this hash equal to the one I have on file", but not by that much. I don't
see why a way to compute the hash more efficiently on some class of device
would not be a concern for use as a KDF.

------
jareds
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.

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

~~~
jareds
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.

------
zxcvgm
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...](https://source.android.com/devices/tech/encryption/android_crypto_implementation.html)

[2]
[https://www.apple.com/privacy/docs/iOS_Security_Guide_Sept_2...](https://www.apple.com/privacy/docs/iOS_Security_Guide_Sept_2014.pdf)

~~~
mbq
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.

------
csirac2
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).

~~~
JshWright
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...

~~~
higherpurpose
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/](http://www.getnymi.com/)

~~~
jonknee
Touch ID still requires you to type in your password after you boot the phone.
Still quite handy, but not a password replacement by any means.

~~~
comex
I think the idea is that the password (which can be made complex if you don't
have to enter it that often) is analogous to the "passphrase for the key",
while Touch ID serves as the normal "passcode to unlock the device".

------
giovannibajo1
> 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.

------
mentat
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.

------
kabdib
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).

------
blueskin_
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.

