Recovery methodsTechnical

Android FBE, Keystore and Hardware-Bound Recovery

Modern Android recovery can require two independent cryptographic layers: filesystem decryption through File-Based Encryption's Credential and Device Encrypted storage, and application-key access through Android Keystore — recovering one layer does not guarantee the other.

File-Based Encryption replaced one disk-wide key

Android moved from legacy full-disk encryption to File-Based Encryption (FBE), and every new device launching with Android 10 or later is required to use it. That shift matters for recovery because FBE doesn't protect the whole storage volume under one key the way older full-disk encryption did — it distinguishes storage classes with different availability rules.

Device Encrypted and Credential Encrypted storage are different domains

Device Encrypted (DE) storage is available after boot, before the user unlocks, to support Direct Boot-aware functionality. Credential Encrypted (CE) storage — where user applications normally keep the sensitive parts of their data — only becomes available once the user authenticates. A booting Android phone can therefore expose some system-level data while the main user dataset stays cryptographically locked, a state broadly analogous to Apple's BFU/AFU distinction even though the underlying implementations differ.

CE keys depend on the credential and the hardware root of trust

Android's security documentation ties Credential Encrypted storage to the user's lock-screen credential together with hardware-backed security state and Verified Boot/root-of-trust guarantees. That combination is why raw UFS or NAND acquisition doesn't automatically hand over CE plaintext — chip-off alone is no more sufficient here than it is on a modern iPhone.

Android Keystore is a separate layer from FBE entirely

This is the distinction worth being precise about: FBE protects data at the filesystem level, while Android Keystore (with KeyMint/Keymaster underneath) separately protects application-level cryptographic keys. An app can perfectly well store an encrypted database on the filesystem while keeping that database's own decryption key inside Keystore — which means decrypting the filesystem doesn't automatically unlock the application data sitting on top of it.

TEE and StrongBox: two levels of hardware isolation

Keystore keys can be enforced by a Trusted Execution Environment (TEE) or, on devices that support it, dedicated StrongBox secure hardware, and attestation can identify which level actually backs a given key. For recovery purposes, the attestation protocol itself is beside the point — what matters is that some application keys are deliberately bound to hardware that's difficult or impossible to reproduce on a different board.

Hardware-backed keys can be intentionally non-exportable

KeyMint/Keymaster can enforce which operations a key may be used for, what authentication it requires, and its hardware security level, and a key can be built so it simply cannot be extracted in usable form. This is especially relevant for password managers, banking apps, secure messengers, crypto apps and enterprise apps — recovering an app's files intact can still be insufficient if the key that protects them was created this way.

Hardware-assisted rate limiting closes the offline-guessing shortcut

Modern Android enforces lock-screen credential rate limiting through TEE or Secure Element mechanisms, which means trying a credential offline against a raw flash image is not equivalent to trying it through the device's own security path. That's another reason raw-storage acquisition doesn't bypass modern mobile security the way it might have on much older hardware.

Board replacement breaks the same root of trust it would on an iPhone

Where FBE and Keystore keys are hardware-bound, pairing the original UFS chip with a replacement motherboard does not reproduce the original hardware root of trust or key hierarchy. That's why mobile recovery on a damaged Android device often prioritizes board-level repair and preserving the original SoC and security components over swapping in working replacement electronics.

Practical rule

Android device and OEM diversity is real — version, SoC vendor, FBE generation, TEE/StrongBox support and app-specific encryption all vary. There's no single universal extraction recipe; the useful question for any given case is which of these layers is actually in play.