5

In the code of KeyStoreUsage from the android developer samples I see the following snippet:

            KeyStore ks = KeyStore.getInstance("AndroidKeyStore");
            ks.load(null);
            KeyStore.Entry entry = ks.getEntry(alias, null);
            if (!(entry instanceof PrivateKeyEntry)) {
                Log.w(TAG, "Not an instance of a PrivateKeyEntry");
                return null;
            }
            Signature s = Signature.getInstance("SHA256withECDSA");
            s.initSign(((PrivateKeyEntry) entry).getPrivateKey());
            s.update(data);
            byte[] signature = s.sign();

What is the benefit of storing keys in hardware, when all the crypto operations take place in normal memory? As I understand the architecture of android the apps are sandboxed so it would be secure, if the device is not rooted. But if it is rooted the unencrypted private key could be extracted from memory, right?

Is there any possibility in android devices (besides using UICC or dedicated microSD-HSM) to do all the crypto operations in the same hardware where the keys are stored, so the private key remains save even if the device is rooted?

EDIT

As it seems there's a little misunderstanding regarding my question, I'll try to clarify it a little bit. I'm well aware that normally hardware-backed keys are not exportable, I've already been working with HSM-Appliances from Utimaco and Luna. I just wondered about key-security in Android, because the documentation is not clear to me. On the one hand it states that keys are safe and hardware-backed (which means not extractable to me), on the other I find code-snippets like the one above which clearly indicate that the keys are extractable. So I wondered if I got things completely wrong and there is a standard way (not SEEK) in newer android versions to store keys in hardware in a way that they are not extractable and let the hardware do all the crypto-operations.

EDIT 2

Well, I feel a little silly now. After doing more research I found that I had a really narrow understanding how things work (and some misunderstandings due to the fact I'm no native speaker). As Steve already said the PrivateKey-objects are only handles, not the keys themselves. The JCE-provider is responsible how to deal with the keys referenced by these handles. In case of hardware-backed keys the keys will stay in hardware and all the operations that look like they are done in memory (on the first look) will be delegated to the hardware. So Steve's answer is right. Please bear with me for making things a little complicated...

Improve this question

1 Answer 1

Reset to default
6

There might be a critical misunderstanding here...

when all the crypto operations take place in normal memory

Normally when the key is stored in hardware it can never be removed from the hardware, and as such it actually cannot be used in normal memory. The actual crypto operations take place in dedicated crypto hardware.

HAL implementations must not perform any sensitive operations in user space, or even in kernel space. Sensitive operations are delegated to a secure processor reached through some kernel interface. Source

What the code offers is simply an abstract interface to interact with the key. What's actually going on is the system is handing off the requests to the crypto hardware and then just waits for a response.

With that said, the whole system offers no protection at all if the key is moved into memory for crypto operations.

Improve this answer
4
  • Thanks for the explanation. So I can assume that my keys are save, if I use "AndroidKeyStore"? One more question: If the code is simply an abstract interface, why can I print the key that I retrieve fom PrivateKeyEntry to System.out for example?
    – Frank
    Commented Nov 15, 2016 at 10:23
  • I don't know if it's secure or not. All I know is it may be backed by a hardware store. You'd have to threat model the entire thing to figure out if it's secure for your needs. It also defeats the purpose of storing the key in hardware if you're dumping the key to System.out because if you can do it now, an attacker can do it at runtime.
    – Steve
    Commented Nov 15, 2016 at 15:29
  • I'm afraid that I'm still confused. Of course I do not want to dump the keys to System.out, but after all it seems that it is possible, so the sentence "Normally when the key is stored in hardware it can never be removed from the hardware, and as such it actually cannot be used in normal memory" is still not clear to me. If I use the "AndroidKeyStore" and call isInsideSecureHardware() on the KeyInfo it returns true. On the other hand I can interact with the key in a way that leaves it exposed outside the hardware?! How save can that be?
    – Frank
    Commented Nov 15, 2016 at 15:38
  • I can't speak to specifics about how this behaves. I was referring to hardware-based key systems generically. Some times you can extract the key, but its usually opt-in during key generation (that can't be changed later) giving a secure-by-default posture. Additionally, being able use the key is the nature of the game, so protecting it is just about setting authorization rules. In the case of Android, everyone runs as the same user so you're kind of limited in locking it down. The practical security here is preventing offline extraction.
    – Steve
    Commented Nov 15, 2016 at 16:02

You must log in to answer this question.

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