title: Usage of software/hardware-backed Android Keystore and possible security/usability drawbacks
body: <p>I'm currently looking at the possibilities of storing/using secrets keys in an Android application. I've found <a href="http://nelenkov.blogspot.com">Nikolay Elenkov's blog</a> very helpful regarding this topic and I've learnt a lot of things about the Android keystore and some hardware-based implementations.</p>
  
  <p>Still I've got some questions about security and user experience aspects.</p>
  
  <h2>Software keystore</h2>
  
  <p>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.</p>
  
  <p>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).</p>
  
  <p>But there are still some details I couldn't figure out :</p>
  
  <ul>
  <li>Does using the keystore enforce the use of a password-protected lock screen ?</li>
  <li>Does the user have to input his/her password every time an access to the encrypted keys is required ?</li>
  <li>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 ?</li>
  </ul>
  
  <h2>Hardware-based keystore</h2>
  
  <p>As for the hardware-based implementation, it seems that SoC manufacturers provide solutions compliant to <code>[Global Platform TEE][2]</code> (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.</p>
  
  <p>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.</p>
  
  <p>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 ?</p>
  
  <p>Thanks for your time!</p>