Are there actually any advantages to Android full-disk encryption?

Question

So, since Android 3, devices can perform boot-time, on-the-fly encryption/decryption of the application storage area (NOT the SDcard/removable storage) - essentially full-disk encryption. This requires a password/passphrase/PIN to be set as the screen unlock code and decryption key, unlock patterns cannot be used.

I have a suspicion that there is actually no benefit to enabling encryption, mainly because the memory chips that serve as the "hard drive" can't be easily removed like real hard drives in computers. I'm wondering if others can comment on my reasoning.

Scenario 1: Device is lost, or stolen by an opportunistic thief (i.e. unsophisticated)
With encryption -> Finder/thief can't gain access
With no encryption but with screen lock -> Finder/thief can't gain access

Scenario 2: Device is stolen by a sophisticated attacker, but they must leave no trace of the attack (therefore chip-off methods are excluded and the phone must be returned before the loss is discovered)
With encryption -> Finder/thief can't gain access
With no encryption but with screen lock -> Finder/thief can't gain access

Scenario 3: Device is stolen by a determined attacker, and the owner made to reveal the passcode under duress. Android doesn't have Truecrypts plausible deniability features.
With encryption -> Attacker gains access
With no encryption but with screen lock -> Attacker gains access

Are there any scenarios I've missed? So my conclusion is that there is no point to enabling full device encryption on Android - a screen lock will do. Discuss! (I am quite happy to be proven wrong, I just can't see how there is a benefit to it)

Answer 1

The advantages are limited, but there are nonetheless scenarios where encryption helps.

In any scenario where the attacker obtains the password¹ (with lead pipe cryptography, or far more realistically by reading the unlock pattern on the screen or brute force on the PIN), there is clearly no advantage to full disk encryption. So how could the attacker obtain the data without obtaining the password?

The attacker might use a software vulnerability to bypass the login screen. A buffer overflow in adbd, say.

The attacker may be able to access the built-in flash memory without booting the device. Perhaps through a software attack (can the device be tricked into booting from the SD card? Is a debug port left open?); perhaps through a hardware attack (you postulate a thief with a lead pipe, I postulate a thief with a soldering iron).

Another use case for full-disk encryption is when the attacker does not have the password yet. The password serves to unlock a unique key which can't be brute-forced. If the thief unwittingly lets the device connect to the network before unlocking it, and you have noticed the theft, you may be able to trigger a fast remote wipe — just wipe the key, no need to wipe the whole device. (I know this feature exists on recent iPhones and Blackberries; presumably it also exists or will soon exist on Android devices with full-disk encryption.)

If you're paranoid, you might even trigger a key wipe after too many authencation failures. If that was you fumbling, you'd just restore the key from backup (you back up your key, right? That's availability 101). But the thief is a lot less likely to have access to your backup than to your phone.

¹ _{Password, passphrase, PIN, passgesture, whatever.}

Answer 2

For the determined attacker setup:

The encryption technology used in Android 3 is dm-crypt. The relevant part here is the following: encryption uses a symmetric key, which is derived from the password/PIN typed by the user; the derivation parameters are stored in a LUKS-formatted block on the device itself. Password derivation is salted and uses many iteration, with PBKDF2. The consequence is that an attacker can do an offline dictionary attack: when he gets the device, he does a raw dump of the partition into a PC, then "tries" passwords. The LUKS block contains enough information to verify whether a potential password is correct or not.

PBKDF2 uses salts and iterations to make the search less efficient, but there are limitations to what PBKDF2 can achieve. PBKDF2 makes key derivation (from the password) slow for the attacker and for the mobile phone itself alike. It must not use too many iterations, because the user is not ready to wait more than, say 3 or 4 extra seconds upon boot. The attacker has more computing power (he has one or a few multicore PC, each core having more raw power than the phone CPU, and he could use a GPU to boost things up) and more patience (if the data is valuable, the attacker is ready to invest one hour or two of computation). Therefore, a 4-digit PIN will not last long in that situation. On the other hand, are you ready to type in a long, high-entropy password on your phone at each boot ?

(Your are probably ready to do that if you boot the phone only once in a great while -- i.e. only when you forgot to recharge the battery. On the other hand, if you have a high-entropy password and do not type it often, you are likely to forget it, which is inconvenient.)

This scenario assumes that the attacker can dump the raw device contents, which entails opening it and accessing the chip; or somehow booting the phone in recovery mode, enough to support ADB -- this can apparently be done with some phones with minimal hardware tinkering, so this may even be a stealth attack (attacker gets hold of the phone, does the dump, and puts back the phone in your pocket with an empty battery, so that you do not get suspicious about reboot; you just say yourself "dammit, forgot to recharge the bloody thing again" along with a few generic curses about the low charge life of smartphones and how in older times mobile phones could last 10 days on a single charge).

Answer 3

One benefit of full-disk encryption is that it makes wiping the flash storage very fast.

All of the data stored on the device is stored encrypted under a particular encryption key K. The system also stores an encryption of K under the user's PIN.

To wipe the entire drive, all you have to do is wipe the spot that stores the encryption of K (which is just one block). Once that block is gone, there is no way to decrypt the data on the drive (since K cannot be recovered), so the entire drive is as good as wiped. The wiping process can be done very quickly, since it only has to erase one block. This means that security / anti-theft apps can wipe your device if it gets stolen and you detect that it was stolen, and the wipe will take effect almost immediately. Without full-disk encryption, wiping the device might take a lot longer.

Answer 4

Are there any scenarios I've missed? So my conclusion is that there is no point to enabling full device encryption on Android - a screen lock will do. Discuss! (I am quite happy to be proven wrong, I just can't see how there is a benefit to it)

You forgot the possibility that the government can dump the contents of you storage/sim card/sd-card. this is done without a warrant at least in the UK, probably, but still denied by the government in germany.

In this case, you will want your data fully encrypted, and at least in germany they still cannot force you to reveal your secret(pin). so, in general its a feature that might prove useful, if it some day includes the sd-card area and offers a way to keep data in the phone and off the SIM. It's just a matter of whether your constitutional rights are important to you or not.

Answer 5

If you live in the US and have access to PII (personally identifiable information), PHI (protected health information), or confidential data covered by contract NDA. Federal/state regulation, as well as insurer or business associate agreements may require encryption of an endpoint devices even in cases where they don't directly contain pertinent data. Compliance with such strict guidelines is necessary in a world where improper information disclosure is a increasingly common and expensive occurrence.

If you read the news, nearly every information disclosure is the result of a disconnect between accepted or assumed risk and what could have been cheaply mitigated.

Individual entities often write off the risk by transferring to an insurer. But believe me we all pay the cost for inadequate security.

I for one am glad for this feature and with the speed of today's processors would like to see consumer device manufacturers implement secure by default methodology ... despite the objections of law enforcement. You're still required to disclose keys with a court order or when crossing borders. I'm not convinced the value of easily accessed data by law enforcement is more than the intangible but great cost we're all paying due to financial fraud.

Answer 6

Here's what I see:

Scenerio 1: You're right. They'll boot to recovery and factory reset, at best.

Scenerio 2: If your phone is rooted and booted, they'll use adb to copy your unencrypted data. If it's not booted, they're stuck.

Scenario 3: Finder/theif holds keys and boots to boot loader/recovery mode. From there they flash a custom recovery or custom kernel (rooted) image. Custom recovery allows root ADB even though phone is not rooted. Rooted kernel image will allow them to bypass lockscreen if you have ADB enabled.

In Scenario 3, an encrypted device can't be accessed by the custom recovery. At least on my Galaxy Nexus, on top of being encrypted, the flash chips won't even talk to the system until they're unlocked with the pin/password. From custom recovery, choosing "factory reset" has no effect. Flashing kernels has no effect. One can restore the original boot loader, but that only provides factory reset as an option, which wipes the entire phone.

So if you want a secure phone that nobody can access, you need encryption, ADB disabled (or at least phone unrooted), and a strong password to unlock the device.

Answer 7

I don't get your reasoning at all. Why would a user reveal the passcode? The most likely scenario is that the phone is stolen and it's not very likely (to say the least) that the thief will look up the owner and hold a gun to his head over the passcode. The second most likely scenario is probably some nosey government official asking for the passcode and then you can simply decline that request if you don't feel like it, or just say you don't remember and that's the end of that (if you live in a somewhat free and democratic country).

Use of force means all bets are off. But it has no bearing on a discussion regarding encryption unless you live under a undemocratic regime or in a very violent country with no means to protect yourself.