Introduction to Android Encryption: FDE vs. FBE

Android’s approach to data security has evolved significantly, particularly in its disk encryption methodologies. Initially, Android devices relied on Full Disk Encryption (FDE), a robust security measure that encrypted the entire userdata partition. While FDE provided strong protection, it came with notable limitations, primarily the inability to boot the device fully without user interaction to decrypt the partition. This hindered crucial functionalities like scheduled alarms, incoming calls, and accessibility services before the user entered their credentials.

To overcome these challenges, Google introduced File-Based Encryption (FBE) starting with Android 7.0 (Nougat). FBE offers a more granular encryption scheme, where individual files can be encrypted with distinct keys. This allows the system to operate in a ‘Direct Boot’ mode, enabling essential functionalities to work even before the user unlocks the device for the first time after a reboot. From a forensic perspective, FBE presents a significantly more complex landscape compared to the all-or-nothing nature of FDE.

This article delves into the forensic analysis techniques required to identify and differentiate between encrypted and unencrypted data blocks within an Android device utilizing FBE. We will explore the underlying mechanisms of FBE, discuss practical methodologies, and highlight the challenges faced by forensic investigators.

Understanding Android File-Based Encryption (FBE) Internals

FBE leverages the fscrypt kernel API, which integrates with modern filesystems like ext4 and f2fs. Instead of a single master key encrypting an entire partition, FBE employs a hierarchical key management system:

• Device Encryption Key: Used to encrypt specific files or directories that must be accessible during Direct Boot (e.g., system files, basic app data).
• Credential Encryption Key: Derived from the user’s lock screen credentials (PIN, pattern, password). This key is used to encrypt user-specific data, making it accessible only after the user unlocks the device.
• Per-File Encryption: Each file or directory under FBE is encrypted with its own unique key, which is then wrapped by either the Device Encryption Key or the Credential Encryption Key. This granular approach is critical for Direct Boot.

On-disk, FBE doesn’t just encrypt file contents; it also encrypts metadata such as filenames and directory names (metadata encryption was introduced in Android 10). This makes traditional string searches for filenames ineffective on encrypted partitions. File attributes (like permissions and timestamps) might still be visible, but their association with a meaningful filename becomes obscured.

FBE Key Components and Interaction

• Key Derivation Function (KDF): Used to derive specific keys from master keys.
• Policy XATTRs: `fscrypt` stores encryption policies as extended attributes (xattrs) associated with inodes. These policies dictate how a file or directory is encrypted.
• Filesystem Integration: `fscrypt` hooks into filesystem operations (read, write, lookup) to transparently encrypt and decrypt data.

FBE vs. FDE: A Forensic Paradigm Shift

In FDE, a forensic image of the userdata partition is either entirely encrypted (appearing as random data) or entirely unencrypted (readable plaintext). The task for an investigator is to decrypt the whole partition using the correct key. With FBE, the scenario is fundamentally different:

• The same `userdata` partition can contain a mix of unencrypted (or device-encrypted and thus potentially decrypted at boot-time) and user-credential-encrypted data blocks.
• Identifying which blocks belong to which encryption state becomes crucial.
• The presence of `fscrypt` metadata and policy information embedded within the filesystem structure adds another layer of complexity.

Methodology for Identifying Encrypted vs. Unencrypted Data Blocks

The core challenge is distinguishing between truly random, encrypted data and structured, unencrypted data. Entropy analysis is a primary tool for this.

1. Acquire the Forensic Image

First, obtain a raw image of the `userdata` partition. This typically requires a rooted device or a specialized forensic tool capable of bypassing Android’s security measures. For a rooted device, an `adb shell` command can be used:

adb shell
su -c 'dd if=/dev/block/by-name/userdata of=/sdcard/userdata.img bs=4M status=progress'
adb pull /sdcard/userdata.img .

Replace `/dev/block/by-name/userdata` with the correct path for your device if it differs.

2. Initial Inspection and Filesystem Analysis

Mounting the image directly will likely fail or show errors if significant portions are encrypted. However, basic filesystem utilities can still reveal unencrypted metadata or structures:

file userdata.img
mkdir mount_point
sudo mount -o ro,loop -t ext4 userdata.img mount_point

If the mount fails, it indicates encryption or corruption. Even if it mounts, many files will be unreadable or show as garbage.

3. Entropy Analysis for Data Block Classification

Entropy is a measure of randomness. Encrypted data typically exhibits high entropy (close to 8 bits per byte), while unencrypted, structured data (text, images, executables) tends to have lower entropy. Tools like `ent` or custom Python scripts can be used.

Using `ent` for Entropy Measurement:

You can analyze segments of your `userdata.img` for entropy. High entropy values (e.g., > 7.5 bits/byte) are strong indicators of encryption.

# Install ent if not already present: sudo apt-get install ent

# Analyze a 1MB block (e.g., at offset 1GB) for entropy
dd if=userdata.img bs=1M count=1 skip=1024 | ent

# Example output for an encrypted block:
# Entropy = 7.999995 bits per byte.
# Chisquare = 247.46, with 255 degrees of freedom -- raw data.

Automating this across the entire image involves scripting to read blocks, calculate entropy, and map regions. A common approach is to slide a window across the image and plot entropy levels to visualize encrypted vs. unencrypted regions.

4. Identifying Known Plaintext Signatures

While file content is encrypted, some structures might remain unencrypted or contain recognizable patterns. For example:

• Filesystem Headers: Superblocks, inode tables, and block bitmaps of the underlying filesystem (ext4/f2fs) are often not encrypted by `fscrypt` directly, allowing forensic tools to parse the filesystem structure, even if file contents are opaque.
• Known Application Data: Some applications might store configuration files or small databases in areas not covered by FBE, or within device-encrypted partitions, making them accessible. Searching for specific string patterns can sometimes reveal these.

# Search for ext4 superblock magic number (0xEF53 at offset 0x438) if it's an ext4 filesystem
hexdump -C userdata.img | grep "ef 53" # This is a very rough approach, better to use fs analysis tools

# Use 'strings' with care, as it will primarily find unencrypted ASCII/UTF-8 strings
strings -n 8 userdata.img | less

5. Examining `fscrypt` Metadata

Advanced analysis involves parsing the filesystem structures to identify extended attributes (`xattrs`) associated with inodes. `fscrypt` stores encryption policy information in `security.fscrypt.policy` xattrs. Locating these xattrs can directly point to files and directories that are managed by FBE.

This often requires specialized filesystem parsing tools (e.g., `debugfs` for ext4, or custom scripts/plugins for forensic suites) capable of interpreting the raw block data and inode structures. For example, using `debugfs` on an unencrypted or partially decrypted image, you might query an inode:

sudo debugfs -R "stat " userdata.img

The output would show extended attributes, including potential `security.fscrypt.policy` if present.

6. Challenges and Limitations

• Metadata Encryption: Android 10+ encrypts filenames and directory names, making it impossible to identify specific files through traditional filename searches, even if you can identify an encrypted block.
• Fragmentation: Files can be fragmented across the disk, making contiguous entropy analysis less precise for individual files.
• TRIM/Wipe: Blocks that have been trimmed or securely wiped will appear as all zeros, which also exhibit low entropy, potentially confusing them with unencrypted data.
• Small Files: Very small encrypted files may not exhibit perfect high entropy due to statistical variations.

Conclusion

Forensic analysis of Android FBE devices demands a nuanced approach, moving beyond the simple ‘all or nothing’ paradigm of FDE. By leveraging entropy analysis, careful examination of filesystem metadata, and understanding the intricate workings of `fscrypt`, investigators can identify regions containing encrypted data and distinguish them from unencrypted portions. However, the continuous evolution of FBE, particularly with metadata encryption, presents ongoing challenges, requiring forensic tools and methodologies to constantly adapt. The ability to identify encrypted blocks is the crucial first step towards targeted decryption efforts, even if the content remains inaccessible without the correct keys.