This recently released research paper: Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions by Matthew Green and his team which is also covered by WIRED talks about design flaw in data encryption of android and iOS. Wired brushes off most of the technical details and the paper didn’t cover android’s File Based Encryption very well which I think needs some clarity on it. The paper draws the correct conclusion though and what should be improved in successor android versions.
In android 7+,
/datapartition is encrypted by File Based Encryption (FBE) on first boot by default. FBE keys are generated in hardware-backed keystore. FBE keys are encrypted in keystore with the key derived from user’s screen lock password. So unless you enter correct password, keystore cannot decrypt FBE keys. When you reboot your device, it is in Before First Unlock (BFU) state which means the user has yet to unlock screen first time since reboot. In this state, if someone calls you or messages you, their name won’t show up unless you unlock your screen. That’s because the device is waiting for your lock screen password which is to be used to decrypt FBE keys and FBE keys are encrypting your contact names.
Once you unlock your screen first time since reboot, it goes to After First Unlock (AFU) state which means the user has unlocked the device first time since reboot. Further locking and unlocking won’t revert the state unless you reboot again which throws you back on BFU.
Temporary per-boot key: In AFU state, FBE keys are decrypted by the keystore and are immediately re-encrypted again by a temporary per-boot key. Per-boot key is generated & stored by keystore and its validity is until next reboot. Encrypted FBE keys blob is then cached in
/system/vold. This ensures that FBE keys are never in plain text when cached by the OS.
As FBE keys are cached though encrypted, you can now use your biometric to unlock screen and kernel can request keystore to decrypt FBE keys on demand means whenever an application wants to read and write, kernel will load FBE keys in memory and they will remain in memory until next reboot. That’s because running apps need them for read and write even if you lock your screen. E.g. To display contacts on lock screen, sharing live location, listening to music, sync services, etc. they need those keys in memory else they won’t work on locked screen.
This opens a security hole. Users don’t often reboot their devices for months so it is in AFU state. The intruder and law enforcement can extract those keys from memory to decrypt sensitive data of running applications without knowing your screen lock. This procedure requires carefully exposing the SoC without disconnecting the battery.
iOS encrypts personal data with keys that are evicted from memory 10 seconds after locking the screen. When it is in BFU state, iPhone needs password to derive a Class key. At this time, biometric won’t work. When it is in AFU state, it caches Class key in Secure Enclave. Now user can use biometric and cached Class key is used to re-derive those evicted keys again when screen is locked and unlocked.
This keys eviction feature is what android also needs otherwise if the intruder is able to decrypt whole
/datapartition, he can own that data in it or if he wants to own the stolen device and doesn’t care about the data, he could be able to set
enablebit for OEM unlocking. Thent he can go to bootloader mode and unlock the bootloader.
In most cases, 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.
If FBE keys are compromised, so will sub-keys so this derivation step doesn’t add much protection even if sub-keys are evicted in newer versions. Android should keep FBE key bundle in keystore itself and load sub-keys in memory some of which can be evicted after screen lock.
Law enforcement can just force your fingerprint to unlock your device and can lie about that in court that it was already unlocked at the time of arrest so no kind of device security can stop them. Locks deter only honest people.
Most common questions:
- Why biometric doesn’t work after reboot?
- After reboot, the device is in BFU state and waiting for you to enter PIN/password which can be used to derive key that decrypts FBE keys.
- How does biometric decrypt FBE keys again when the user locks and unlocks the screen second time (or Nth time)?
- It doesn’t. FBE keys were already decrypted by the keystore when the screen was unlocked first time since reboot (They are re-encrypted by a different key and cached, see temporary per-boot key section). When you unlock using biometric, keystore lets the OS know that the user is verified and should be allowed access. This is enforced by SELinux policy.
- I forgot my PIN/password, why do I need to factory reset the device to use my phone? That would erase all my data.
- Your PIN/password is used to derive key that encrypts and decrypts FBE keys as explained in the post. If you have forgotten your PIN/password, your data cannot be decrypted anyway so even if there was a feature to reset PIN without factory reset, it would be useless. Instead it would allow thieves to reset PIN and reuse your device.
- If data partition is not decrypted until you enter your password, where does the phone store things like language, wallpaper, wifi logins, Bluetooth pairings that are visible right after the phone boots?
- I intentionally left out this part that FBE has 2 types of storage:Device Encrypted Storage: This is directly encrypted by keystore and do not require your password for decryption.Credentials Encrypted Storage: This is encrypted with a key derived from your password.The most basic functionalities are encrypted under device encrypted storage so that your phone will be still usable for taking calls and receiving messages even if you don’t unlock it.
- While in lockdown mode, my contact names are still showing up on call
- I checked in settings and it says that it turns off smart lock, fingerprint and notifications on lock screen. So it doesn’t clear keys in memory probably because Google wants to ensure usability of background apps like listening to music. This means it may disable biometric for law enforcement but won’t put your phone back in BFU state.Android apps process cycle isn’t designed to adapt if FBE keys are suddenly cleared from memory without letting the apps know. It would instantly crash most of the system apps and services because of I/O error when they couldn’t find keys. In iOS, apps are alerted that the user has locked the device.
- Why can’t biometric be used as a key to decrypt FBE keys?
- Because you always put your finger slightly differently on the sensor. Keystore approves authentication if enough of the mathematical values match. To use something as a key or to derive a key from something, you need something that doesn’t change and always produces the same output.
- What about multi-user phones? I have a dummy profile set up and if I never unlocked my main profile after reboot I can’t see it’s files from it. But if I have unlocked previously I see them.
- If multi-user profiles are set up, keys can be recovered for currently running user only. When you switch user, keys for earlier user are cleared from memory. That’s another good way to stay safe without rebooting the device.
- Wait, why is only
/datapartiton encrypted, but system partitons are not?
- You don’t need encryption for system partitions. Other partitions are already public images. What you need is their integrity protection. All system partitions are protected by android verified boot 2.0