Protecting user data at rest is a mandatory requirement for modern Android devices. If a device is lost or stolen, the data on the flash storage must remain inaccessible without the user's explicit credential. Android achieves this through robust filesystem encryption.
FBE vs FDE
Historically, Android used Full Disk Encryption (FDE). In FDE, the entire /data partition was encrypted with a single key. The user had to enter their PIN/password during the boot sequence before the partition could be mounted. Until the device was unlocked, it was essentially a brick; it could not receive calls, alarms would not sound, and accessibility services were unavailable.
Android 7.0 introduced File-Based Encryption (FBE), which is the standard today. In FBE, different files and directories are encrypted with different keys. This granularity allows the OS to boot completely and perform basic functions before the user unlocks the device.
Credential Encrypted (CE) and Device Encrypted (DE) Storage
FBE relies on separating application data into two distinct storage areas, protected by different key hierarchies.
Device Encrypted (DE) Storage:
- Data in this area is encrypted with a key tied to the device's hardware, but it does NOT require the user's PIN/password to decrypt.
- The DE key is available as soon as the OS boots.
- Location:
/data/user_de/0/ - Use cases: Storing the ringtone preference, alarm clock schedules, and components necessary to show the lock screen and receive phone calls.
Credential Encrypted (CE) Storage:
- Data in this area is encrypted with a key that is mathematically derived from both the hardware secret AND the user's PIN/pattern/password.
- The CE key is NOT available until the user explicitly unlocks the device.
- Location:
/data/user/0/(which is typically what apps see as their internal storage). - Use cases: All sensitive user data, messages, photos, and standard application databases.
Key Derivation
The process of deriving the CE key is complex to resist offline attacks. When a user sets a PIN, the OS uses the vold (Volume Daemon) and gatekeeperd to securely hash the PIN. This hash is passed to the Keymaster/KeyMint HAL in the TEE. The TEE combines it with a hardware-bound key to create a Key Encryption Key (KEK).
Each file in the CE storage area is encrypted with a unique File Encryption Key (FEK). These FEKs are then encrypted by the KEK. Therefore, without the user's PIN to regenerate the KEK in the TEE, the filesystem cannot decrypt the individual FEKs, rendering the data inaccessible.
Direct Boot Mode
Because CE storage is unavailable before the first unlock, applications must be explicitly designed to function in this state. This is known as Direct Boot mode.
Apps that need to run before unlock (like SMS apps or alarm clocks) must declare android:directBootAware="true" in their manifest. When running in this mode, the app must carefully ensure it only attempts to access data stored in its DE storage directory, as attempting to read from CE storage will result in an I/O error or a crash. Once the ACTION_USER_UNLOCKED broadcast is received, the app knows CE storage is available and can resume full functionality.