Introduction to Android Full Disk Encryption (FDE)

Android’s Full Disk Encryption (FDE) has been a cornerstone of mobile security, designed to protect user data at rest. Introduced in Android 3.0 Honeycomb and made mandatory for many devices starting with Android 5.0 Lollipop, FDE encrypts the entire user data partition. While newer Android versions (7.0+) have largely transitioned to File-Based Encryption (FBE), understanding FDE remains crucial for forensic analysis of legacy devices and for comprehending the foundational security principles that informed FBE’s development. This article will dissect the intricate mechanisms of Android FDE, exploring its key derivation processes, storage methodologies, and inherent vulnerabilities.

The Android FDE Architecture

Android FDE leverages the Linux device-mapper crypt (dm-crypt) subsystem to perform block-level encryption. When FDE is enabled, the /data partition is treated as a single encrypted block device. The Android framework component responsible for managing this is vold (Volume Daemon), which interacts with cryptfs, a command-line utility used for managing encrypted filesystems.

Upon boot, the system needs to decrypt the /data partition before mounting it. This process typically involves the following steps:

1. The bootloader loads the kernel and initial ramdisk (initramfs).
2. init starts vold.
3. vold reads the FDE metadata from the /data partition footer.
4. vold prompts the user for their lock screen PIN, pattern, or password.
5. This user credential is used to derive a key, which then decrypts the master key.
6. The decrypted master key is passed to the kernel’s dm-crypt module, allowing the /data partition to be mounted.

Key Derivation and Management in FDE

The security of FDE hinges on its key derivation function (KDF) and secure storage of the encrypted master key. Historically, Android FDE used PBKDF2 (Password-Based Key Derivation Function 2) to derive the encryption key from the user’s lock screen credential. Later versions adopted scrypt, a more memory-hard KDF, to increase resistance against brute-force attacks.

Here’s a simplified look at the derivation process:

1. The user enters their PIN/Pattern/Password (UPPP).
2. A KDF (PBKDF2 or scrypt) is applied to the UPPP, often combined with a device-specific salt.
3. This derived key, let’s call it the Key Derivation Key (KDK), is used to decrypt a Master Key (MK). The MK is the actual symmetric key used by dm-crypt to encrypt and decrypt the entire /data partition.
4. To enhance security, the KDK and MK operations are often offloaded to a Hardware Security Module (HSM) like the Keymaster TEE (Trusted Execution Environment). The Keymaster ensures that cryptographic operations are performed in a secure, isolated environment, making it extremely difficult to extract the keys even if the main Android OS is compromised.

Example: KDF Parameters (Conceptual)

While the exact parameters are device-specific and not easily accessible without root, conceptually, cryptfs uses parameters stored in its metadata:

cryptfs cryptfs create_key_new 
 --encryption_key_size=128 --hash_algorithm=sha1 
 --kdf=scrypt --scrypt_N=16384 --scrypt_r=8 --scrypt_p=1 
 --salt=<device_specific_salt>

This command snippet illustrates the types of parameters that define the KDF strength. The scrypt_N, scrypt_r, and scrypt_p values significantly impact the computational cost of brute-forcing.

FDE Key Storage on Disk

The encrypted Master Key (MK) and associated metadata are stored directly on the /data partition, typically in a dedicated footer or header region. This metadata, often referred to as the cryptfs footer, contains critical information:

• Magic number to identify the FDE structure.
• Version information.
• Encryption algorithm and mode (e.g., AES-256-XTS).
• The encrypted Master Key blob.
• KDF parameters (salt, iterations, scrypt N/r/p values).
• Keymaster-specific blobs (if hardware-backed).

On devices using Keymaster, the actual Master Key is