4

Android provides FDE, but it uses lockscreen pin, which is (at least in my case) fairly weak (like a 4-digit PIN). Does it mean that my FDE could be easily broken by offline attack?

Or maybe master key is stored on TPM and all the crypto is done there? In that case it could rate-limit trials or even shut down itself after certain number of those.

I found this piece on source.android.com (emphasis mine):

The encrypted key is stored in the crypto metadata. Hardware backing is implemented by using Trusted Execution Environment’s (TEE) signing capability. Previously, we encrypted the master key with a key generated by applying scrypt to the user's password and the stored salt. In order to make the key resilient against off-box attacks, we extend this algorithm by signing the resultant key with a stored TEE key. The resultant signature is then turned into an appropriate length key by one more application of scrypt. This key is then used to encrypt and decrypt the master key. To store this key:

However they don't explain if this signing process is somehow rate-limited or protected by other means.

5

The important thing to keep in mind is that the actual encryption keys for the volume are stored in the Trusted Execution Environment (TEE) chip, which is designed to provide secure key storage. The goal of the device is to act as an encryption oracle: you give it some data, it encrypts or decrypts it, then gives you the result. This means that if you take the flash chip out and try to read it directly, you'll just get encrypted data.

By default, there's no direct authentication from the user to the TEE that protects against an attacker just asking to have the data decrypted. This is where adding a PIN or passphrase to your phone helps - it acts as an authentication mechanism to the TEE to ensure that you can't just ask to have data decrypted without "proving" who you are.

The key phrase around rate limiting is this:

The resultant signature is then turned into an appropriate length key by one more application of scrypt.

The scrypt KDF is designed to be slow and sufficiently memory-hard to make it difficult to parallelise on common compute platforms (e.g. CUDA). Also notice that they said "one more application of scrypt"; the DEK is already transformed via scrypt, hence it is made infeasible to try to "crack" the DEK by deriving it repeatedly against candidate passwords.

0

The passage you cite explains how the FDE key is protected against offline attacks: it's derived from a secret component (the signature key) which is stored in a TEE. A TEE (Trusted Execution Environment)¹ is a secure coprocessor (usually a virtual one, but nonetheless protected from access by the normal operating system) which has exclusive access to some secret keys. While the Android storage can be cloned by copying the flash memory, the TEE keys are stored in a separate memory inside the chip which cannot be copied off-device (at least not without physical attacks on the processor).

Thus, in an Android installation where the encryption key is TEE-backed (many aren't!), you can't decrypt the data even if you know the PIN, unless you have access to the original device (or you've somehow managed to extract the keys from the TEE).

Protection against online attacks are a different matter. With a 4-digit PIN, even throttling isn't enough; you need to lock down the device (and typically require a longer security code to unlock it). This is what happens with (chip-based) credit cards and phone SIMs, for instance. As far as I know, Android does not require any specific throttling or lockdown mechanism, so it's up to individual TEE implementations (each manufacturer have their own) whether the encryption key remains vulnerable to online attacks.

¹ Which, by the way, is not the same thing as a TPM.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.