Encryption

A thief who steals a phone gets a device that is, in principle, a brick. Making that true for the data as well as the hardware took Android from 2011 to 2019, and the intermediate designs explain a lot about how the platform boots.

TL;DR#

encrypted the whole userdata partition with one key, unlocked at boot. Nothing worked until the user entered their credential.
(API 24Android 7.0) encrypts files with per-file keys, split into device encrypted (DE) and credential encrypted (CE) storage.
DE is available in ; CE is available only after the user unlocks. That is why alarms and calls work before unlock.
Metadata encryption protects the filesystem's structure (names, sizes, permissions) while leaving the file contents to FBE.
API 29Android 10: devices launching with Android 10 or later must use FBE.

Mental model#

Think of a house with two kinds of room.

The utility rooms — the boiler, the alarm panel, the entry phone — must work before anyone is home. They have their own lock, and the key is on the keyring the house keeps by the door.

The private rooms — the study, the bedroom — have locks keyed to the owner's fingerprint or PIN. They cannot be opened until the owner is in the house, and they lock again when the owner leaves.

FBE is that house. The DE partition is the utility rooms: available from the moment the system boots. The CE partition is the private rooms: available only after the credential is verified.

Where the analogy breaks#

A house's boiler does not contain a copy of the bedroom's key. In FBE, the CE keys are protected by a key derived from the user's credential, which in turn is protected by hardware rate-limiting. The security does not come from the lock's mechanism alone but from the fact that guessing the credential is slow in hardware, not just in software.

The big picture#

Loading diagram…

Text description of this diagram

A state machine for storage availability under File-Based Encryption. Powered off: nothing readable. Bootloader: verified boot checks the images; no userdata yet. Direct Boot: device-encrypted storage is mounted and usable, so alarms, telephony and the lock-screen input method run; credential-encrypted storage does not exist yet. CE unlocked: the correct credential unwraps the synthetic password and installs the CE keys, so app private data is readable. Locked (keys evicted): the CE keys are dropped and CE data becomes unreadable again while DE stays available. Shut down: keys are gone. Transitions are labelled with the credential check, the lock timeout, and the reboot.

Deep dive#

FDE: one key, one unlock#

Full-disk encryption encrypted the entire userdata partition with a single key, derived from the user's credential and protected by hardware.

The consequence was simple and severe: nothing was available until the user unlocked. The framework could not start, alarms could not fire, and an incoming call could not ring, because everything the framework needed — settings, accounts, app data — was on an encrypted partition that was not mounted yet.

For a phone that was off, that was fine. For a phone that was on and in a pocket, it meant the platform had to choose between security and functioning. It chose security, and the device was unusable until unlock.

FBE: two storage classes, per-file keys#

FBE encrypts different files with different keys that can be unlocked independently.¹ In practice there are two classes:

Credential Encrypted (CE) — available only after the user unlocks. This is the default and where sensitive data belongs.
Device Encrypted (DE) — available during Direct Boot and after unlock.

The directories are split accordingly:

Storage	Paths
User CE	`/data/data`, `/data/user/<user_id>`, `/data/media/<user_id>`
User DE	`/data/user_de/<user_id>`, `/data/misc_de/<user_id>`, `/data/system_de/<user_id>`, `/data/vendor_de/<user_id>`
CE (other)	`/data/media/<user_id>`, `/data/misc_ce/<user_id>`, `/data/system_ce/<user_id>`
System DE	`/data/apex/decompressed`, `/data/app`, `/data/misc`, `/data/system`, `/data/vendor`
Key storage	`/data/misc/vold/user_keys/ce/<user_id>`, `/data/misc/vold/user_keys/de/<user_id>`

The rule of thumb: a _de suffix means device-encrypted; everything under user/ and media/ for a user is credential-encrypted unless it is explicitly in a _de directory.

Direct Boot#

Direct Boot is the boot state where DE storage is available and CE is not. In that state:

Apps that declare directBootAware can run, but only against DE storage.
The telephony stack, the alarm manager and the lock-screen IME must work.
The rest of the system waits.

This is why a phone can ring before you unlock it, and why your alarm still goes off after a reboot. It is also why an app that needs to work before unlock has to be careful about what it stores where: a SharedPreferences file in CE storage is simply not readable in Direct Boot.

Key derivation: the synthetic password#

The most interesting part of FBE is how the user's credential becomes a key without the credential itself being the key.

A synthetic password is generated randomly for each user. It is high-entropy and immutable.
The synthetic password is encrypted with a key derived from the user's Lock Screen Knowledge Factor (LSKF) — a PIN, pattern or password — plus material held in the secure environment.
vold encrypts each CE key with an AES-256-GCM key derived from the synthetic password.
On unlock, the LSKF is verified, the synthetic password is decrypted, and the CE keys are installed.

The LSKF is stretched with scrypt, targeting roughly 25 ms and about 2 MiB of memory.¹ That is deliberately modest, because the real protection is not the KDF: it is hardware rate-limiting. A short PIN has too little entropy to resist an offline attack no matter how it is stretched. The secure environment enforces an increasing delay between attempts, and that is what makes a 4-digit PIN adequate.

Metadata encryption#

FBE encrypts file contents. It leaves the filesystem's structure — directory names, file sizes, permissions, timestamps — readable, because the filesystem driver has to walk that structure before it can find the file whose key it needs.

Metadata encryption closes that gap by encrypting the block device underneath the filesystem, with a single key held in the TEE. The filesystem sees a normal block device; the storage sees ciphertext.

The two layers are complementary: metadata encryption hides the shape of the data, FBE provides per-file keys and the CE/DE split. That is why the combination gives both structural privacy and per-user, per-lock-state access.

What the encryption does not protect#

A running, unlocked device. If the phone is unlocked, the keys are installed. That is why screen lock timeouts matter.
Data the app exports. A backup, a shared file or a screenshot is outside the encryption.
A compromised TEE. The CE keys are protected by hardware; if the hardware's implementation is broken, so is the protection.
The user's cloud account. Much of the data on a phone also exists in a backup that is protected by different mechanisms entirely.

How it evolved#

Storage changes10 releases

API	Version	What changed
3	1.5 Cupcake	android.widget video and media improvements
12	3.1 Honeycomb	ParcelFileDescriptor improvements
15	4.0.3 Ice Cream Sandwich	New calendar and media provider APIs
19	4.4 KitKat	Storage Access Framework
24	7.0 Nougat	FileProvider and StrictMode for file URLs
29	10	Scoped storage with requestLegacyExternalStorage opt-out
30	11	Scoped storage enforced for targeting apps
33	13 Tiramisu	READ_MEDIA_IMAGES/VIDEO/AUDIO replace storage reads
34	14 Upside Down Cake	READ_MEDIA_VISUAL_USER_SELECTED
37	17 Cinnamon Bun	ACTION_PICK_CONTACTS gives session-scoped contact field access

The arc: FDE (Android 4.4 onward), FBE (7.0), metadata encryption (9), FBE mandatory for new devices (10). Each step narrowed what was exposed at a given moment: first the disk, then the boot, then the filesystem structure.

Under the hood#

the volume daemon: mounts, FBE key management, and the synthetic password flow
the userspace library for the kernel's fscrypt layer
LockSettingsService, which coordinates credential verification and key derivation
the filesystem implementations vold drives

Curiosity corner#

The phone can ring before you unlock it because telephony runs in Direct Boot. That is not a special case; it is the reason Direct Boot exists.
A work profile has its own CE and DE keys. It is a separate user, and its data is separately encrypted even though it lives on the same physical storage.
Changing the PIN re-wraps the synthetic password; it does not re-encrypt the data. That is why changing a credential is fast, and why losing the credential is unrecoverable.

Why can't apps be root?Because the platform's security model depends on each app having a distinct, unprivileged identity. Root would collapse the sandbo…Open card →How can a phone ring before you unlock it, if storage is encrypted?File-Based Encryption splits storage into a device-encrypted area, available during Direct Boot, and a credential-encrypted area, …Open card →What is an isolated process used for?Running code that should not be trusted with app data or permissions, such as some WebView renderers and untrusted effects. It has…Open card →

Try it#

See the storage classes on a device

$ adb shell ls /data/user_de/0 | head
adb shell ls /data/user/0 | head
adb shell getprop ro.crypto.type
adb shell getprop ro.crypto.state

ro.crypto.type reports file on an FBE device and block on an FDE one. The two ls outputs show the DE and CE directory trees for user zero.