1

I am trying to understand the FBE Key generation and verification process at every boot. My device is going to be handled without a lock screen (Android 11 with FBE + Metadata Encryption Enabled), so we do not have any password associated with the device for stronger data protection. I went through the post: Connection between PIN/password and encryption keys in Android

I am not able to understand below points from the code flow:

  1. How is a Key generated when there is no Pin/Password provided by the User.
  2. How does the derivation works here without Pin/Password
  3. What happens on a Factory reset.
  4. How do you verify that each file is having a separate key for encryption

Would appreciate if anyone has any clues

Improve this question

1 Answer 1

Reset to default
2

Android File Based Encryption specification allows encryption without user enrolled password. Full Disk Encryption which is a predecessor (and deprecated) of file based encryption used to have default_password as the password to encrypt storage when the user did not enroll custom full disk encryption password from settings. This was a major inconvenience for the user because custom password used to be separate from the lock screen password if the user is using lock screen pattern. It was required only once after every reboot so it could be easily forgotten. It was a security issue as well because most users would not bother going through settings to set custom password for full disk encryption. Spyware agencies took advantage of this by creating exploits for Trusted Execution Environment (TEE) that could extract its secret key and together with default_password, they were able to decrypt the whole storage.

File based encryption cryptographically ties user enrolled lock screen password with file based encryption keys which makes it infeasible to crack even if the secret key of TEE is known to the attacker. The current implementation supports null bytes to use if the user does not enroll password. This eliminated hardcoding of default_password string as input to the Key Derivation Function. The keys that decrypt file based encryption keys are still derived by the key derivation function because key derivation will still output the key even if null bytes are used.

File based encryption optionally uses these inputs to derive keys:

  1. Auth Token
  2. Stretched Credential

If the user password is not enrolled, the authentication is skipped. TEE does not await for the user input and proceed to derive keys with non-user elements. Both of these optional elements are skipped during key derivation.

On factory reset, TEE clears existing file based encryption keys and regenerates them. The user is re-prompted to enroll password which can be skipped.

Every file stores a unique IV that is used to derive a sub-key which encrypts & decrypts the file.

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.

TrustyOS

Android File Based Encryption

Improve this answer
2
  • thank you for providing the github link for the "null bytes" implementation. I truly appreciate the efforts you spent answering. Could you please help me understand if there is any way we can identify the keys on bootup, where they are stored Also do you know what is the concept of "per boot key", are the keys different every boot?
    – Sneha Sharma
    Nov 30, 2022 at 12:32
  • The entire process happens inside TEE and in Inline Crypto Engine hardware, you won't see those keys in plain-text in android 11+ devices. You can find some keying material in /data/system_de/0/spblob that is used in key derivation. Per-boot is the key that TEE generates to wrap FBE keys so that they can be cached in /data/misc/vold/user_keys/ce/0/current/encrypted_key after first unlock.
    – defalt
    Nov 30, 2022 at 15:35

You must log in to answer this question.

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