Android File‑Based Encryption (FBE) Key Management and Architecture Overview

User data encryption is a critical function on mobile devices. This article, the second in an Android system security series, focuses on file‑based encryption (FBE) and its key‑management framework, covering the roles of HAL, the Linux kernel, TEE, and hardware.

Android protects user privacy data through three schemes: Full‑Disk Encryption (FDE), File‑Based Encryption (FBE), and Metadata Encryption (ME). FDE encrypts the entire userdata partition, FBE encrypts individual files with separate keys, and ME encrypts filesystem metadata.

Full‑Disk Encryption (FDE) : From Android 4.4 to 9, FDE uses a randomly generated Disk Encryption Key (DEK) protected by user credentials. The DEK is decrypted at boot after the user enters credentials, which prevents early‑boot services from accessing data.

File‑Based Encryption (FBE) : Supported from Android 7.0 onward, FBE allows different keys for different files and enables system services (e.g., alarm, accessibility) to run before the user unlocks the device. Storage is divided into Uncrypted Storage, System DE Storage, User DE Storage, and User CE Storage, each protected by distinct keys (SYSTEM_DE_KEY, USER_DE_KEY, USER_CE_KEY).

Metadata Encryption (ME) : Introduced in Android 9, ME encrypts directory layout, file sizes, permissions, and timestamps using a key protected by Keymaster.

FBE Key Framework – Hardware Architecture : FBE relies on UFS and a Trusted Execution Environment (TEE). When the chipset supports an Inline Crypto Engine (ICE) or a secure subsystem, these components provide a hardware‑based Key Management Service (KMS) for key creation, derivation, and programming.

FBE Key Framework – Software Architecture : The software stack includes HAL, the Linux kernel, REE‑TEE communication, and the Keymaster HAL. Key handling traverses VOLD, the kernel keyring, and fscrypt. The mount file (fstab) defines encryption options such as fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] , where the content mode can be "aes-256-xts" or "adiantum" and the filename mode can be "aes-256-cts", "aes-256-heh" or "adiantum".

VOLD Key Processing consists of four steps: (1) mounting the userdata partition, (2) retrieving or generating the FBE Class Key and KEK, (3) installing the key into the Linux kernel keyring via an IOCTL command, and (4) applying the encryption policy to directories/files.

Linux Kernel Handling uses fscrypt to manage per‑file encryption keys and policies. The kernel keyring stores the encrypted FBE Class Key Identifier. The KeySlot Manager (KSM) programs hardware keyslots in ICE and performs key derivation. Functions such as keyslot_program and keyslot_evict handle programming and evicting keys from hardware slots.

TEE (Trusty) Processing involves the Keymaster Trusted Application (TA). The Keymaster HAL exposes cryptographic primitives to the Android Keystore service, while the TA performs sensitive operations. Keymaster requires key characteristics (algorithm, size), purpose (encryption/decryption), client binding (APP_ID or ADD_DATA), root‑of‑trust binding, and version binding.

The FBE key hierarchy includes a File‑Contents Encryption Key, a File‑Name Encryption Key, and a Key Identifier. These keys are derived by the Keymaster TA and programmed into ICE via KSM.

Summary : The article outlines Android’s privacy‑protection schemes (FDE, FBE, ME), details the end‑to‑end key‑management flow across VOLD, the Linux kernel, and TEE, and introduces the role of the Inline Crypto Engine. Readers gain a comprehensive view of Android’s file‑based encryption architecture.