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

  • 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)

    Since you brought it up...

    I don't have Android 3.0 or later so I have this question: Is the encryption password that you type when you boot your phone different than the unlock password? It make sense to choose a 20+ characters password for the disk encryption, and a short pattern password for the unlock.

    Can anyone comment on whether the UFED would be halted by Android encryption? Or would it simply get the screen lock password, which also happens to be the decryption key, and enable the UFED operator to thereby decrypt whichever of `/data` and `/sdcard` had been encrypted by the device owner?

    @user11820, as of kitkat, you cannot have different boot and screen-unlock passwords. There is a popular bug asking for it.

    ... however, see also the comment below about an adb command to change it.

    How about: Device is stolen by sophisticated attacker, doesn't care if he leaves a trace of his attack?

    I'd say "How often has my phone been stolen", but the answer would be zero times. So...How many people _do I know_ who had their phone stolen? Two, one of them twice. That makes 3 incidents total (not a great sample size, but what can I do). At how many occasions were the owners tortured to reveal the password? Zero. So that's zero out of three, encryption is definitively a win situation.

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

    Thank you for the comments. I have also stumbled across a bug report of unknown accuracy claiming that encrypted devices with USB Debugging enabled are vulnerable via ADB even with the screen locked (but after the decryption key has been unlocked on first boot)

    In my day job, I work at the Infosec office at an .edu - may I paraphrase and incorporate your comments into an article for our blog? Happy to give attribution (let me know what your preference is)

    @scuzzy-delta As it says on the footer of the page, our contributions are licensed under CC BY-SA with attribution requirements. Thanks for asking, but you already have permission to do this as long as you give proper attribution.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM