The Brick Before Authentication
Imagine an over-the-air update runs overnight on an older Android device. The system reboots, arrives at the lock screen, and waits for a PIN. Your morning alarm never rings because the device cannot access its own storage. Early Android releases used Full Disk Encryption (FDE), which created this exact problem.
Under FDE, the operating system encrypted the entire /data partition using a single key. The kernel could not mount the filesystem until the user provided their credential. The device acted like a brick until authenticated. The phone could not receive calls, trigger alarms, or run accessibility services.
Android 7.0 introduced File-Based Encryption (FBE) to solve this boot limitation. FBE encrypts individual files and directories with distinct keys instead of encrypting the block device as a monolithic chunk. This architectural shift allows the kernel to mount the filesystem and run basic operating system services before the user touches the device.
This granularity keeps the phone functional after a reboot. The system now makes strict decisions about which files are safe to read at boot and which must remain locked. This decision requires splitting storage into two distinct worlds.
The Two Tiers of Storage
The operating system needs immediate access to your custom ringtone and alarm schedule during boot. However, the system absolutely must not expose your private messages or photos until you authenticate. FBE splits application data into two tiers protected by different key hierarchies to balance system functionality with user privacy.
Device Encrypted (DE) storage uses a key tied exclusively to the physical device hardware. The operating system decrypts this storage automatically during the boot sequence. Applications use this space for critical early boot tasks. The system provides the path /data/user_de/0/ for this tier.
Credential Encrypted (CE) storage uses a key mathematically derived from both the hardware secret and the user PIN, pattern, or password. This storage tier remains inaccessible until the user explicitly provides their credential. By default, applications store their data here at /data/user/0/.
This separation ensures the phone can receive calls while keeping personal data mathematically sealed. Developers must explicitly choose where to put their data based on when it needs to be available. Enforcing this mathematical seal against determined attackers requires specialized hardware.
The Hardware Root of Trust
If an attacker extracts the flash memory chip from the phone, they could brute-force a four-digit PIN in seconds if the encryption relied purely on software. The decryption process must be tied to a secure piece of silicon that limits guess attempts and enforces hardware bindings. Android achieves this using a Trusted Execution Environment (TEE).
The sequence diagram below visualizes the key derivation process. The flow shows how the user PIN travels from the application space into the secure hardware layer. Pay attention to how the TEE acts as the ultimate gatekeeper for the encryption keys.
When you enter your PIN, the Volume Daemon (vold) and gatekeeperd securely hash the input. They pass this hash into the Keymaster or KeyMint hardware abstraction layer running inside the TEE. The TEE combines the PIN hash with a hardware-bound secret to generate a Key Encryption Key (KEK).
Each file in CE storage gets a unique File Encryption Key (FEK). The KEK encrypts every individual FEK. Without the user PIN, the TEE refuses to generate the KEK. Without the KEK, the kernel cannot decrypt the FEKs, and the filesystem returns garbage.
Interview Note: A common question in platform interviews is how Android protects data even if an attacker bypasses the software operating system completely. The answer is always the TEE and hardware-bound keys.
The hardware enforces a strict boundary that prevents offline attacks. Even the main Android operating system cannot access CE files without permission from the TEE. This locked state creates a challenge for application developers who need their apps to run immediately after a reboot.
Surviving the Locked State
Because the operating system locks CE storage at boot, standard applications crash with an input/output error if they try to access their databases before the user provides a PIN. Applications that provide critical services, like alarms or SMS reception, must be designed to survive in this restricted environment. Android calls this Direct Boot mode.
Developers opt in by declaring android:directBootAware="true" in their application manifest. When running in this mode, the application must restrict its file operations strictly to the DE storage context. If the application attempts to open a database in CE storage, the operation fails instantly.
Once the user enters their PIN, the system broadcasts the ACTION_USER_UNLOCKED intent. Direct Boot aware applications listen for this broadcast to know when they can safely access CE storage and resume normal functionality.
File-Based Encryption ensures user data remains secure at rest while keeping the device functional. The platform architecture forces developers to think carefully about data lifecycle and encryption states. Understanding this storage separation prepares you to look at how Android secures data while it is actively moving between processes in memory.