File Based Encryption (FBE) keys are cryptographically bound to lock screen authentication. Without lock screen credentials, keys that decrypt FBE keys cannot be derived. Lock screen authentication and key derivation are executed inside Trusted Execution Environment (TEE) which is a separate secure environment that runs independently of android OS.
TEE has 3 components:
Gatekeeper - It enrolls new screen lock password and authenticates the existing user.
Biometric - It enrolls and authenticates biometrics.
Keymaster - It handles cryptographic operations for the device.
Lockscreen Knowledge Factor Enrollment
It happens only when the user registers Lockscreen Knowledge Factor (LSKF) on a new device or after factory reset. This is called untrusted enroll and if the user is changing existing LSKF, it is called trusted enroll. The difference between them is trusted enroll requires existing LSKF to enroll new LSKF. In both cases, HMAC on Password Handle is generated & stored by the Gatekeeper.
Authentication & FBE Keys Decryption In Before First Unlock State
Biometric authentication doesn't work in this state.
Start point is PIN pad.
Invalid frequent password attempts are throttled by exponential timeout by Gatekeeper. Each attempt takes 100ms for verification so brute forcing a strong password is not feasible.
After 5th and 10th incorrect authentication attempt, there is a timeout of 30 seconds. Every successive attempt up to the 30th gets the same timeout. Between 30 and 140 attempts, the timeout grows in an exponential manner from 32 seconds to 17 hours 4 minutes. After 140 attempts the timeout for each incorrect attempt is 1 day. In the worst case, a brute force attack against a 4 digit PIN would take around 27 years to complete.
FBE Keys Decryption
There are 2 types of FBE keys:
Credential Encrypted (CE) keys which are only available after the user has unlocked the device.
Device Encrypted (DE) keys which are automatically derived when booting the device.
After First Unlock State
FBE keys are re-encrypted by Keymaster using Ephemeral Key which is valid until next reboot. Re-encrypted FBE keys are then cached in
vold and in the Linux kernel keyring. These are called Wrapped Keys. When the Linux kernel requires this key to read or write a file, it calls into the secure environment which decrypts (unwraps) FBE keys, derives a
64-byte AES-256-XTS key and programs it in into the Inline Crypto Engine. This ensures that FBE keys are never stored in plain-text when they are cached in the device storage. FBE keys also undergo an additional key derivation step in the kernel in order to generate the subkeys actually used to do the encryption, for example per-file or per-mode keys.
Now user can use biometric to unlock screen.
Is This Design Secure From Forensic Extraction?
It is secure when the device has not been unlocked after reboot. This is called Before First Unlock state. Once the device is unlocked at least once after reboot, the device goes to After First Unlock state and at some point FBE keys will have to come in memory for reading and writing data. Background apps like messages, emails, contacts, notes, reminders etc. can keep them in memory indefinitely from where they can be extracted.
That's how FBI might be Hacking Into Private Signal Messages
Hardware Wrapped Keys
FBE keys are vulnerable to memory attacks if the kernel is using them in memory. To solve this problem, Android 11 introduced support for a dedicated hardware backed Inline Crypto Engine that stores wrapped FBE keys during the runtime of the OS. During I/O, TEE unwraps FBE keys in that hardware which encrypts & decrypts data for the kernel. This means that even the compromised kernel cannot see those keys in plain-text. But that does not mean that the data is now immune from extraction. A compromised kernel can still request inline crypto engine to decrypt data for the apps which can be then exfiltrated from the device.
Resume On Reboot
Android applies over-the-air (OTA) updates to the OS on inactive slot while the device is running the OS on the active slot. This scheme is called A/B system updates. In order to switch to the updated slot, a reboot is required which sets updated slot to active and boots it. But after the reboot, the device goes to before first unlock state which means the attendance of the device owner is required to unlock the device in order for apps awaiting decryption of credentials encrypted data to work. As the attendance of the owner is required to put the device in after first unlock state, it is not possible to schedule the reboot and resume the device activity automatically while the owner is inactive.
Resume-on-reboot allows the user to authorize scheduling of reboot during inactive hours and automatically puts the device back to after first unlock state. Here's how android protects FBE keys before and after the reboot.
Scheduling Reboot & Just Before Reboot
Lock screen credentials are required to authorize the schedule and to decrypt the synthetic password as shown in Authentication & FBE Keys Decryption.
Once the synthetic password is decrypted at the end, it is used to decrypt CE keys as shown in FBE Keys Decryption.
Qualcomm File Based Encryption (pdf)
File Based Encryption
Android 7 File Based Encryption and the Attacks Against It
Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions
Cryptographic relation between Verified Boot State & FBE keys