8

I am trying to piece together some information about the security system in Android. Particularly about how user's password/PIN is connected with encryption keys in file-based encryption mode. I'm doing this for my university project. I've found a lot of useful information on the Android source site. But some things are still unclear to me.

  1. How is passwords/PIN information connected with keys, which are used to encrypt files?

The stretched credential is the user credential after salting and stretching with the scrypt algorithm. The credential is actually hashed once in the lock settings service before being passed to vold for passing to scrypt. This is cryptographically bound to the key in the TEE with all the guarantees that apply to KM_TAG_APPLICATION_ID.

  1. Where does Android store this key: in hardware or some not accessible memory?

The secdiscardable hash is a 512-bit hash of a random 16 KB file stored alongside other information used to reconstruct the key, such as the seed

  1. What algorithm does Android use for reconstruction the key?

1 Answer 1

12

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 handled by Trusted Execution Environment (TEE) or by a Secure Element (SE). These are separate secure environment that run independently of android OS. A device can have either one or both.

TEE and SE have 3 components:

TEE SE
Gatekeeper Weaver They enroll new lock screen credentials and authenticate the existing user.
Biometrics Biometrics They enroll and authenticate biometrics.
Keymaster Strongbox They handle cryptographic operations for the device.

Stretching Lock Screen Knowledge Factor

LockSettingsService first stretches the Lock Screen Knowledge Factor (LSKF) by passing it through scrypt, targeting a time of about 25 ms and a memory usage of about 2MB.

Stretched LSKF

Lock Screen Knowledge Factor Enrollment

When the user registers LSKF on a new device or after factory reset of the device, it is called untrusted enroll. If the user changes existing LSKF, it is called trusted enroll. The difference between the two is trusted enroll requires existing LSKF to enroll new LSKF. In both cases, the Gatekeeper generates an HMAC on the stretched LSKF and serializes it with the metadata to create a Password Handle. The HMAC key used to enroll and verify passwords is derived and kept solely in GateKeeper.

LSKF Enrollment


Authentication

Invalid frequent password attempts are throttled by exponential timeout by the Gatekeeper. Each attempt takes 100ms for verification so brute forcing a strong password is not feasible. After 5th and 10th incorrect 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.

Authentication With Gatekeeper

Authentication With Gatekeeper Start point is PIN pad.

Authentication With Weaver

Authentication With Weaver


FBE Keys Decryption

There are 2 types of FBE keys:

  1. Credential Encrypted (CE) keys which are only available after the user has unlocked the device.

  2. Device Encrypted (DE) keys which are automatically derived when booting the device.

Before First Unlock

Biometric authentication does not work in BFU state.

Synthetic Password Decryption With TEE

On successful user authentication in Before First Unlock (BFU) state, the Gatekeeper sends an Auth Token which notifies the Keymaster to release an Auth-Bound Keystore Key. If the device has a TEE, then LockSettingsService encrypts the synthetic password twice: first with the stretched LSKF and secure discardable hash, and second with an auth-bound Keystore key.

spblob Decryption with TEE

Synthetic Password Decryption With SE

If the device has an SE, then LockSettingsService encrypts the synthetic password twice: first with the stretched LSKF and the Weaver secret, and second with a non-auth-bound Keystore key.

spblob Decryption with SE

DE & CE Keys Decryption

Synthetic Password is used to decrypt CE keys. The decryption of DE keys does not depend on the Synthetic Password so they are directly decrypted without authenticating the user.

FBE Keys Decryption

After First Unlock

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.

Cached FBE Keys

Now the user can use biometrics to unlock screen.


How Secure This Design Is From Forensic Extraction

It is secure when the device is in Before First Unlock state. When 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 holding 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 of the apps and exfiltrate it from the device.


Resume On Reboot

Android applies over-the-air (OTA) updates to the OS on an inactive slot while the device is running the OS on an 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. This means 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 & Synthetic Password Decryption sections.

Re-encrypting Synthetic Password & Storing Receipt

After Reboot

Once the Synthetic password is decrypted at the end, it is used to decrypt CE keys as shown in DE & CE Keys Decryption section.

Synthetic Password Decryption & CE Keys Decryption


References

Android Data Encryption in depth

File Based Encryption

Authentication

Hardware-Wrapped Keys

Resume-on-Reboot

Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions

Qualcomm File Based Encryption (pdf)

Sources

Gatekeeper.cpp

LockSettingsService.java

SyntheticPasswordManager.java

SyntheticPasswordCrypto.java

Fscrypt.cpp

KeyStorage.cpp

keyblob.rs

Cryptographic relation between Verified Boot State & FBE keys

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .