Introduction to File-Based Encryption (FBE) on Android

File-Based Encryption (FBE) is a cornerstone of modern Android security, providing granular encryption of individual files and directories. Unlike full-disk encryption (FDE), FBE allows different files to be encrypted with different keys, enabling features like Direct Boot (where core system components can start before user authentication). Understanding FBE’s internals, especially its reliance on the Android Keymaster Hardware Abstraction Layer (HAL) and on-disk metadata structures, is crucial for security researchers and reverse engineers aiming to assess device security or analyze forensic data. This guide will delve into the mechanisms behind FBE, focusing on the Keymaster’s role and the structure of encryption metadata.

Android’s FBE Architecture and Key Management

At its core, Android’s FBE leverages the Linux kernel’s fscrypt framework. Instead of encrypting an entire block device, fscrypt encrypts individual files at the filesystem level, typically on ext4 or f2fs. Each user profile on an Android device is associated with a unique FBE master key. This master key is not directly stored on disk in plaintext; instead, it’s securely managed by the Keymaster.

The lifecycle of an FBE master key involves several components:

1. Key Generation: When a user profile is created, the vold daemon requests the Keymaster to generate a new FBE master key. This key is returned by Keymaster in a “wrapped” (encrypted and authenticated) form, often referred to as a key blob.
2. Key Storage: The wrapped FBE master key blob is stored on the unencrypted portion of the filesystem, typically within /data/misc/vold/user_keys/. These blobs are opaque to vold and cannot be used without Keymaster’s intervention.
3. Key Unwrapping and Provisioning: When a user unlocks their device (or after Direct Boot completes for the system user), vold retrieves the wrapped key blob and presents it to the Keymaster. Keymaster, after verifying authentication (e.g., via Gatekeeper for PIN/password), unwraps the blob and returns the raw FBE master key. vold then securely provisions this raw key to the Linux kernel’s fscrypt module, making it available for file encryption/decryption.
4. Key Derivation: The fscrypt module uses this raw FBE master key, combined with file-specific metadata (like a nonce), to derive unique per-file encryption keys.

The Keymaster’s Pivotal Role

The Android Keymaster HAL provides cryptographic primitives for key generation, storage, and authorization. It is designed to operate within a Trusted Execution Environment (TEE) or a dedicated secure element, making it highly resistant to software-only attacks. For FBE, Keymaster performs these critical functions:

• Generates strong, random FBE master keys.
• Securely wraps and unwraps these keys, often binding them to specific authorization conditions (e.g., user authentication, boot state).
• Protects against unauthorized key use, even if the wrapped key blob is exfiltrated.

Reverse engineering Keymaster involves analyzing its HAL implementation (e.g., [email protected]) and how vold interacts with it via Binder calls. Tools like lshal can list active HAL services, and static analysis of the Keymaster HAL source code (or binary) can reveal specific key properties and authorization tags it supports.

# On an Android device via adb shell
lshal | grep -i keymaster
# Expected output might look like:
# [email protected]::IKeymasterDevice/default
# [email protected]::IKeymasterDevice/default

Dissecting FBE Encryption Metadata

While the FBE master key is managed by Keymaster, the kernel’s fscrypt module needs metadata stored alongside each file to derive its unique encryption key. This metadata is typically stored in extended attributes (xattrs) on the inode for encrypted files/directories.

The primary structure governing FBE encryption policy is fscrypt_info, defined in the Linux kernel source (e.g., fs/fscrypt/fscrypt.h). It contains vital information:

• ci_enc_type: The encryption algorithm and mode (e.g., AES-256-XTS).
• ci_master_key_descriptor: A unique identifier (typically a 16-byte hash) that links to the specific FBE master key managed by vold and Keymaster. This is NOT the master key itself, but a pointer to it.
• ci_nonce: A per-file random value used in conjunction with the FBE master key to derive the unique file encryption key, ensuring different files encrypted with the same master key have different actual encryption keys.

Locating Wrapped FBE Keys and Descriptors

To reverse engineer, you’ll need a rooted Android device or an emulator with root access.

1. Identify the User Key Directories: The wrapped FBE master keys are stored by vold.

adb shell
su
ls -l /data/misc/vold/user_keys/
# You'll likely see directories for different users, e.g., '0' for the primary user.
# Inside, you'll find key blobs like 'key_0'.
hexdump -C /data/misc/vold/user_keys/0/key_0
# This output shows the raw bytes of the Keymaster-wrapped FBE master key blob.
# This blob is opaque and can only be unwrapped by the Keymaster it was generated with.

2. Inspect File Encryption Metadata: Identifying the fscrypt_info on a specific file can be done by examining the `security.fscrypt` extended attribute. While direct `getfattr` may not always work easily for kernel-level `fscrypt` attributes, understanding the structure from kernel source is key.

In a forensic scenario with a raw image, you might use tools like `debugfs` on the `userdata` partition to examine inodes directly. For example, to find the inode number of an encrypted file:

adb shell
ls -li /data/data/com.example.app/files/secret.txt
# Example output: 123456 /data/data/com.example.app/files/secret.txt

# Then, on a host with debugfs-tools and a pulled userdata image:
debugfs -R "stat <inode_number>" /path/to/userdata.img
# Look for 'Extended attributes' or 'security.fscrypt' if your debugfs supports direct parsing, 
# or rely on kernel source to interpret raw inode data.

The `ci_master_key_descriptor` found within the `fscrypt` metadata is a critical link. It’s often a short identifier (e.g., 16 bytes) that `vold` uses to reference the corresponding wrapped master key blob stored in `/data/misc/vold/user_keys/`. By matching this descriptor, `vold` can retrieve the correct wrapped key to send to Keymaster for unwrapping.

Vulnerability Analysis and Exploitation Pathways

Reverse engineering FBE and Keymaster often aims to identify potential weaknesses:

• Keymaster Bypass: Flaws in the Keymaster implementation itself (especially in non-TEE environments) could allow an attacker to bypass authentication requirements and force key unwrapping.
• Metadata Tampering: If the fscrypt metadata (especially the ci_nonce or ci_master_key_descriptor) can be tampered with without detection, it might lead to incorrect key derivation or denial-of-service. Integrity protection of xattrs is crucial here.
• Side-Channel Attacks: Keymaster operations, particularly key unwrapping, might be susceptible to side-channel attacks (e.g., timing, power analysis) if the TEE implementation is flawed.
• Vold/Kernel Interface Exploits: Vulnerabilities in how vold communicates the raw master key to the kernel’s fscrypt module, or within the fscrypt module itself, could lead to key exposure or decryption bypasses.
• Insecure Key Descriptors: If the master_key_descriptor can be trivially guessed or enumerated, it might make it easier for an attacker to target specific key blobs, even if Keymaster still protects the unwrapping process.

Understanding these intricate relationships between user-space daemons (vold), secure hardware (Keymaster), and kernel modules (fscrypt) is paramount for robust Android security assessment.

Conclusion

Android’s File-Based Encryption, powered by the Linux fscrypt framework and secured by the Keymaster HAL, represents a significant leap in mobile device security. Reverse engineering this complex interplay requires a deep understanding of kernel internals, secure hardware interfaces, and user-space daemon logic. By meticulously analyzing wrapped key blobs, on-disk metadata, and the Keymaster’s role in the cryptographic lifecycle, security researchers can identify and mitigate potential vulnerabilities, ensuring the integrity and confidentiality of user data on Android devices. Further research can focus on advanced tracing techniques for Keymaster operations and fuzzing the interfaces between vold and fscrypt for novel attack vectors.