I was reading this documentation and saw this part;

When an application performs cryptographic operations using an Android Keystore key, behind the scenes plaintext, ciphertext, and messages to be signed or verified are fed to a system process which carries out the cryptographic operations. If the app's process is compromised, the attacker may be able to use the app's keys but cannot extract their key material (for example, to be used outside of the Android device).

It makes me a bit confused as I don't quite get how being able to access app keys but not the "keying material" is still safe (or secure). I mean if the key is the ultimate output of a KDF, does it make any difference not being able to access the corresponding keying material? I can still use the keys, for example, to decrypt messages, right?

1 Answer 1


... use the app's keys

This means perform cryptographic operations using the key, like signing or decrypting something.

... cannot extract their key material (for example, to be used outside of the Android device)

This means the attacker cannot extract the keys from the device, i.e. he must always have access to the device for doing operations with the keys. This is possible if the attacker has stolen the device or has a remote backdoor to it - but ultimately the owner will know that the device could be compromised and can make the appropriate mitigations, like revoking the keys so that no new messages will be encrypted for the owner using this compromised key.

If instead the attacker would be able to extract the keys from the device than a short access to the device might be enough and the owner of the device might not realize that the keys are compromised since the device is still there and it does not look compromised either. Thus the keys will not be revoked and the attacker might be able to decrypt future messages too or impersonate the owner of the keys.

  • I don't think I made my point that clear. Let me retry. If the app process is compromised via a backdoor and the attacker can "use the app's keys" to decrypt, encrypt, sign etc., why would I bother accessing the keying material (IV, some other parameters etc.)?
    – zgulser
    Commented Jun 24, 2019 at 11:08
  • 1
    @zgulser: "use of keys" is not "possession of keys". The attacker needs to have access to the device in order to decrypt or sign something. This means the attacker needs to steal the device or have some backdoor in it - which means that the owner will eventually realize that the keys are compromised and mitigate the attack. If the attacker could instead steal the keys he could use these without having access to the device which makes it much less likely that the owner will notice and mitigate the compromise. Commented Jun 24, 2019 at 11:22
  • "use of keys" is not "possession of keys" -> this was what I was looking. thanks.
    – zgulser
    Commented Jun 24, 2019 at 11:41
  • One more thing. For instance, if KeyStore.getPrivateKey(...) returns the key "in bytes" and the app process is compromised, then the attacker can send the key to itself over the network. Can't this be thought of extracting the keys off the device? I was thinking that those functions return some sort of a file descriptor and never exposes the actual bytes.
    – zgulser
    Commented Oct 25, 2019 at 11:47
  • 1
    @zgulser: If the key is backed by hardware (TEE, SE) then getPrivateKey will fail. If it is not backed by hardware then a compromised process might be used to steal the key. Commented Oct 25, 2019 at 11:47

You must log in to answer this question.

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