Usage of software/hardware-backed Android Keystore and possible security/usability drawbacks

Question

I'm currently looking at the possibilities of storing/using secrets keys in an Android application. I've found Nikolay Elenkov's blog very helpful regarding this topic and I've learnt a lot of things about the Android keystore and some hardware-based implementations.

Still I've got some questions about security and user experience aspects.

Software keystore

For what I understood, in this configuration a masterkey is derived (using PBKDF2) from a user password (plus a salt to prevent rainbow tables attacks) and used to encrypt secrets. As far as I know, the password is the one used for the lock screen.

On a non-rooted phone, only the user 'keystore' is able to read/write the encrypted files and whenever an application want to access a file, it has to call the keystore daemon which checks if its UID is authorized to access this file (the authorizations are stored in a sqlite database).

But there are still some details I couldn't figure out :

• Does using the keystore enforce the use of a password-protected lock screen ?
• Does the user have to input his/her password every time an access to the encrypted keys is required ?
• Given it's a software-only mechanism, I think a secret key will always end up decrypted in RAM whenever it's used for cryptographic operations, right ?

Hardware-based keystore

As for the hardware-based implementation, it seems that SoC manufacturers provide solutions compliant to [Global Platform TEE][2] (Trusted Execution Environment) with embedded Trusted Applications and APIs that enable Google to provide an hardware-backed implementation of its keystore. It's thus possible to store secret keys in the TEE, ask for RSA key pair creation inside the TEE and sign or check data using secret keys stored inside the TEE. This way, one can use secret keys for basic cryptographic operations without them ever leaving the TEE.

If I got it right, access control to those keys is provided by the Google keystore daemon using the same mechanism as in the software implementation. The only difference is that references to the keys stored in the TEE are used instead of the encrypted keys themselves.

If everything stated before is correct, I guess it would be possible on a rooted phone to modify the permissions database so that an application with an arbitrary UID can have data signed with any key stored in the TEE. Am I right ?

Thanks for your time!

Templas

Worth noting that there are related changes in M nelenkov.blogspot.co.uk/2015/06/… – Trevor

Answer 1

• Does using the keystore enforce the use of a password-protected lock screen ?

Yes, user is forced to use lock screen, protected with password, pin, or pattern.

• Does the user have to input his/her password every time an access to the encrypted keys is required ?

No, once the device is unloked, KeyStore becomes unlocked as well and there's no need to enter additional passwords. However, application should check if the KeyStore is unlocked, because user could disable the lock screen protection in Settings. Once key locked is disabled, KeyStore becomes uninitialized and must be unlocked again.

Several times I faced a strange behavior, when the KeyStore was locked, but I didn't have lock screen protection set up. I was prompted to enter a password or pin code to enter the KeyStore. However, it was not possible, since I didn't have any passwords. I assume some system apps were locking the KeyStore. I had to reset it to re-initialize.

• Given it's a software-only mechanism, I think a secret key will always end up decrypted in RAM whenever it's used for cryptographic operations, right ?

Yes, all keys retrieved from the KeyStore will reside in RAM until garbage-collected or deinitialized. But you can obtain the key each time you need it, not keeping it in some long-living variable.

Unfortunately, I'm not familiar with HW-backed KeyStore. Cannot say anything about it.

Leanaleanard

Is a pattern authorized ? I think the search space would be too small to resist a brute-force attack. And regarding the keystore unlocking, I may miss something here but it involves that somehow the masterkey resides unencrypted in RAM as long as the device is unlocked, isn't it ? – Templas

you are incorrect, using the KeyStore does not enforce use of a lock screen unless setEncryptionRequired() is used. See doridori.github.io/android-security-the%20forgetful-keystore – Trevor

The above link (provided by Dori) did not work for me. Here is a revised link. Nice article, by the way. doridori.github.io/android-security-the-forgetful-keystore – Trodden

@Trevor things change over time and if something works now, it doesn't mean it always worked that way. – Leanaleanard

@AlexanderZhak yes I understand APIs change over time. Not sure if you read the article I linked to, which shows how this specific API has changed since its inception. – Trevor

Answer 2

Your analysis of the TEE-based hardware-backed scenario is correct. The private key bits generated in the TEE (which isn't necessarily compliant with the Global Platform specs) never leave the TEE and private key operations are performed inside it.

You're also correct that the handles to the TEE-based keys are stored in Keystore, so it's possible for root to access and use any of them, or to move them around so any app can use them.

Luca