File Based Encryption (FBE) keys are cryptographically bound to screen lock authentication. Unless user enters screen lock code, keys that decrypt FBE keys cannot be derived. Screen lock 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 existing user.
Biometric - It enrolls new biometrics like fingerprint, face ID and Iris and authenticates enrolled 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) which is called untrusted enroll or changing LSKF for the existing user which is called trusted enroll. The difference between them is trusted enroll requires existing LSKF to enroll new LSKF. In both cases, Password Handle is stored by the Gatekeeper.
Authentication Followed By FBE Keys Decryption During First Unlock After Reboot:
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. A brute force attack against a 4 digit PIN would take around 27 years to complete.
FBE Keys Decryption
Start point is User Root Key.
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. When the Linux kernel requires this key to read or write a file, it calls into the secure environment which decrypts 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 outside of TEE. 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 enough from forensic extraction?
It's secure when the device hasn't been unlocked once after reboot. This is called Before First Unlock state. Once the device has been unlocked atleast 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
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