Why does an encryption key derived from your lock screen password give you stronger protection (in Android 11)?

Question

Why does an encryption key derived from your lock screen password give you "stronger protection" than a key chosen by the machine (or at any rate not derived from your lock screen password)?

The context in which the above generic question arises for me is a Samsung mobile phone running on Android 11. So a more specific question (if that is preferable) would be: Why the above is the case for that particular device.

In what follows, I will describe the context in more detail. If the question as stated above is already answerable, you may not have to read any further.

Context

As far as I can make out, this is what happens with an Android 11 Samsung phone.

• Encryption, in the sense of the machine's jumbling the data in storage, is always on (with no option to turn it off), but it may or may not give you any protection depending on which of the three cases below applies.

• Case 1. There is no lock screen password (where 'password' is a term of convenience that includes PIN, pattern etc. as well): You get no protection. The data may be encrypted, but anyone can get them decrypted without having to enter a password.

• Case 2. A lock screen password is set, but the "Strong protection" is off: You get protection. The machine chooses the encryption key.

• Case 3. A lock screen password is set and the "Strong protection" is on: You get more protection. The encryption key is derived from your lock screen password.

Note. On the device, "Strong protection" is in Settings > Biometrics and security > Other security settings > "Strong protection." The blurb for it says, "Encrypt your phone using your secure lock type (pattern, PIN, or password)."

If my understanding so far is wrong, please tell me so. The question may not even arise then, and I may have to delete it.

Assuming then that the understanding is correct, the question is why derivation of the encryption key from something you chose gives you stronger protection? I would have thought the machine could do without your help (which may be 1234) to choose a strong encryption key.

By the way, are there technical terms for encryption (in the sense of data jumbling whether or not it gives you any protection) vs. protection?

Correction

Case 3, as stated above, is wrong because of the way the term 'password' was defined (to include biometrics through 'etc.').

To get the benefit of an encryption key that is itself encrypted (with something you chose), you need to use the following:

• Case 3b. A lock screen pattern, PIN, or alphanumeric password is set and the "Strong protection" is on.

For why this is so, see A. Hersean's answer.

(I did not want anyone, having read only the question, to go away with the wrong information. I choose this manner of correcting the post, rather than striking out 'etc.', because the exclusion of biometrics is made more prominent and I don't want to appear to have got the thing right at the outset.)

Answer 1

In all cases, the encryption key is chosen at random by the device (your mobile phone).

When biometrics are used to unlock the phone, they are checked by a mostly secure module (a TEE, in your case the Knox™ version of ARM TrustZone™). If the check says that the presented biometrics are close enough to those stored in the device, then the encryption key is read to decrypt the device. That means that the encryption key is stored as-is somewhere, and its access is only protected by an access control mechanism. Someone with physical access to the mobile phone could open it, read the key and decrypt the device, bypassing the access control.

When a PIN, pattern, password or passphrase is used, the process can be made safer. Notice that a pattern is just a PIN with digits that cannot be repeated (instead of drawing it you could type it on a number pad). So a pattern is a weak PIN (because some combinations are impossible), and a PIN is a weak password (because only digits are allowed) which is a weak passphrase. So, I'll simplify this answer by only referring to passphrases.

When a passphrase is used, the encryption key is not stored directly in the device. It is first encrypted by a key encryption key (KEK). This KEK is derived by the passphrase and never stored anywhere. When a user tries to authenticate, its passphrase is derived into a KEK, then the mobile check if this KEK decrypts properly a test value. If the check fails, it means the passphrase is wrong. If the check pass, the newly derived KEK is used to decrypt the encryption key, which in turn can be used to decrypt the device. Thus if someone gains physical access to the device, they cannot read the key. They can only try to guess the passphrase until they find the correct one. Because the derivation process takes some time (on purpose), trying every passphrase can be a very long process if the passphrase is long enough.

When using biometrics, each reading differs, so no unique value can be used to derive a KEK. The encryption key must be stored somewhere in the device and accessible without a KEK derived from some data provided by the user. Previously I simplified when writing that in this case the encryption key is written as-is: for Android versions 7 to 9, it was in fact encrypted too, and the passphrase used to derive the KEK was "default_password". This was done to simplify the overall unlocking process by having only one way to do it. This offer no more protection than storing directly the encryption key, because the passphrase is public knowledge. In new versions of Android, file-based encryption is used, and there is no more only one single encryption key, but many keys for different files. However, the overall mechanism remains the same, but with more keys and thus more complexity. Explaining it would be too complex for the level of technical details expected here. However, if you want more details, you can refer to the official documentation here and there, or refer to defalt's answers here and there. Just keep in mind that authenticating with biometrics can only deliver an authentication token, but it cannot be used to derive a KEK.

That's why Samsung says that patterns, PINs and passphrases are strong methods: in those cases attackers with physical access will have a harder time to decrypt the device because they will have to guess the passphrase. However, please note that trying every pattern and PIN is still very fast, so those two methods are not so much more secure than using biometrics against this kind of attacker. For a strong encryption, the user must use a strong passphrase.

Side note, answering a comment: The delay to limit guessing only applies to someone trying every possibility using the graphical interface, maybe with a robot typing on the screen. For someone who opened the phone and copied its (mostly encrypted) data by accessing it directly, no such limitation applies. By the way, copying this data requires specialized skills and hardware. The time it takes to derive the KEK is due to the huge number of operations needed to make the computation. However, someone who managed to copy the data can rent thousands of computers in the cloud to try all the combinations even faster, working in parallel with each computer trying a different set of combinations, and without delay limits enforced by the platform.

Second side note: You also asked about technical terms for encryption (or "data jumbling") versus protection. "Data jumbling" is technically called obfuscation when it does not provide any substantial protection. Encryption is the technical term for when this jumbling is done depending only on a secret key, implying that everything else is considered public knowledge. Encryption is a mechanism to protect the confidentiality of data, but it does not ensure its authenticity (in some cases, an attacker could blindly alter the encrypted data with success without being detected). For this, other cryptographic mechanisms are needed, such as authentication codes or signatures. To summarize, there is no "encryption versus protection". Encryption is a mechanism offering one kind of protection. Like a lock. And like a lock, it does not protect against everything, but only against some attacks.

Third side note, for clarification: In this answer, I try to explain in simple terms the fundamental difference between encryption on mobile devices (specifically Android) using only biometrics or using passphrases. It is a simplification, and shortcuts where made while explaining. Reality is more complex and other issues arise, such as "What happens when someone copies my fingerprint? I cannot change it, unlike a passphrase.".

Answer 2

By design, File Based Encryption (FBE) keys are cryptographically bound to Lock Screen Knowledge Factor (LSKF). This prevents an adversary to decrypt Credential Encrypted storage by extracting FBE keys from TEE with physical intrusion. FBE has two types of encrypted storage:

1. Device Encrypted (DE) storage: DE is not bound to LSKF and encrypts basic functionalities, settings, emergency info, lock screen wallpaper, wifi passwords, alarms, reminder notes, etc. so that the device can still be usable in Before First Unlock (BFU) state.

2. Credential Encrypted (CE) storage: All user data and app data personal to the user are encrypted under CE storage which is bound to LSKF. CE can be decrypted only in After First Unlock (AFU) state.

LSKF is not stored by TEE so it cannot be extracted. To verify LSKF, TEE derives a HMAC key that produces a HMAC on password handle and compares it with stored HMAC. See, Connection between PIN/password and encryption keys in Android for more details. LSKF is hashed by lockscreen service in host OS before the input is sent to TEE. This prevents TEE to learn LSKF and at all time only the user knows about LSKF.

Without LSKF, it's not possible to decrypt FBE keys because Key Encryption Key (KEK) is derived from LSKF that participates in decryption of FBE keys. It's uncommon for an OEM to offer opt out option to unbind FBE keys with LSKF. FBE is implemented by the vendor so it seems Samsung has customized it. You won't find this option in other OEMs.

Strong Protection is just a buzzword. Disabling it will weaken your device encryption and keeping it enabled is the standard design of FBE. Strong Protection is not providing any new feature on top of FBE that other OEMs don't have.

---

What prevents OEMs to deliver a signed update for the TEE firmware of the seized device in order to disable screen lock timeout?

At least in Pixel devices, Titan M TEE chip is known to have so called Insider Attack Resistance (IAR). This puts the updated firmware image on hold state unless successful user authentication is done when the update is applied. IAR is extended to android OS also. From android 12, android UpdateManager first checks Google Binary Transparency (GBT) logs to verify that what is published is the same as what is on the device when the update is about to be applied.

---

Pixel 6: Setting a new standard for mobile security

Before First Unlock: Device has not been unlocked once since last reboot

After First Unlock: Device has been unlocked once since last reboot