4

I am using a Safenet HSM (Hardware Security Module) to store my cryptographic keys, and I am trying to unwrap a secret key (AES/DES) encrypted with RSA using Java APIs and SunPKCS11. I would like to do this securely, so that unwrapped AES/DES key cannot be extracted from the HSM (like the RSA private key value is invisible). However, after unwrapping the value of the unwrapped key is visible in the key object outside the HSM.

Here is my code:

Key privateKey = keyStore.getKey("MyKeyId", keyStorePassword);

Cipher cipher = Cipher.getInstance("RSA", "SunPKCS11-Safenet");
cipher.init(Cipher.UNWRAP_MODE, privateKey);
Key unwrappedKey = cipher.unwrap(wrappedKey, "AES", Cipher.SECRET_KEY);
// At this point the unwrapped key is visible in the unwrappedKey object!

How I can tell the code not to reveal the unwrapped key? Do I have to add something in the PKCS11 config file? I've tried adding the options below into the config file, but it doesn't seem to help:

attributes(*,CKO_SECRET_KEY,*) = {
  CKA_SENSITIVE=true
}

I am not sure if revealing keys during unwrapping is expected from the API. If so, how I can import such keys securely into the HSM so that they cannot be extracted from it?

I've tried asking the Safenet support team, but they could not answer why this is happening. So, after lots of trying and searching the Internet, I have asked this question here.

snesh
  • 71
  • 7
  • Well you if you need your private key somewhere, then @ some point it will be in memory thus will be vulnerable to readout. No miracles there - since you are doing that in plain code... Using java makes it easier as we can all debug the code right? – Antoniossss Sep 12 '18 at 12:17
  • 1
    @Antoniossss: I'm not familiar with either the HSM not the API that the OP is using, but in general the point of using a HSM as a crypto provider is that you can let it do crypto operations for you without any sensitive key material ever leaving the HSM's secure storage. Basically, the way this *should* work is so that the Java crypto API implementation isn't directly storing any keys or carrying out any crypto operations; it should just be storing opaque key identifiers and translating the Java API operations into instructions for the HSM to "decrypt this data with key #1234" or whatever. – Ilmari Karonen Sep 12 '18 at 13:13
  • @IlmariKaronen *a crypto provider is that you can let it do crypto operations for you without any sensitive key material ever leaving the HSM's secure storage.* I stopped reading there - yes that is the point of using hardware crypto setups, but the thing is, that OP is decrypting it on CLIENT APPLICATION SIDE, not on device side thus it is not using it as it is designed to be used. He literally retrieves private key from crypto storage and he is surprised it is on JVM. – Antoniossss Sep 12 '18 at 13:47
  • @Antoniossss When I am retrieving private key I just get a reference to this but not actual value of key. Same behaviour I am expecting for unwrapped key too. Sorry but I did not get your statement _OP is decrypting it on CLIENT APPLICATION SIDE, not on device side thus it is not using it as it is designed to be used_. Please explain or provide some link. – snesh Sep 12 '18 at 14:37
  • Have you tried adding `CKA_EXTRACTABLE = false` attribute? – always_a_rookie Sep 13 '18 at 13:43
  • Yes, I tried that too but didn't worked. – snesh Sep 13 '18 at 16:05
  • When you wrap a key, the only reason you would do that is to move it someplace where it will then be unwrapped for use. I'm siding with @Antoniossss here -- we don't have enough info, and from what we do have, yeah, you've got exactly what you asked for -- the key, after you've unwrapped it. 1) Where did the wrapped key come from? It's suddenly there in your extract. 2) Did you apply the CKA_ attributes on the 'wrappedKey' on creation? when you wrapped it? – rip... Sep 16 '18 at 00:33
  • We have exactly same use case as you described, our customer will share his secrete key and we will unwrap it in our server for use. So yes I want a key after unwrapping but without value. Regarding your questions - 1) I have generated a random key (without HSM) and wrapped it to test my code. 2) to check this, I have created a new SecreteKey key in HSM with CKA_SENSITIVE = true and CKA_EXPORTABLE = true (I have to set it true otherwise key wrapping is not possible), but still see the key after unwrapping. Are these attributes part of key value and HSM can understand after unwrapping? – snesh Sep 17 '18 at 11:50
  • @snesh if you just want the key to perform cipher operations, you should just be doing `getKey`, like you did for thr private key. I'm not sure why you need to unwrap it. The HSM's dont support straight import/extract of the objects. But there is a secure way of doing it, aka, wrapping/unwrapping. But if your usecase is to retrieve the key that is shared on to your application, yes, you need to do this one time thing of unwrapping it, aka, extracting it. But if your case is to perform cipher operations, just use the key in the `ciper` instance with the provider parameter. – always_a_rookie Sep 19 '18 at 11:28
  • @always_a_rookie_to_learn We are unwrappin key because of flow due to business requirement. Flow is like we need to import wrapped keys received from customer into our HSM and after import use them for cipher operation. During key import we unwrap them and store in key store (and hence we need unwrap). For cipher operation we retrieve key using `getKey` function which does not reveal actual value of key. Do you mean that unwrapping will always expose the actual key value? – snesh Sep 20 '18 at 08:34
  • 2
    Yes, unwrapping the key exposes the key value. Consider now you need to do this _inside_ the HSM. The "unwrap" and "import" steps should be an atomic operation, which requires either that the HSM firmware supports this out of the box (limitations will apply), or you will need to code up the operation, and then run it on the HSM as custom firmware. – rip... Sep 22 '18 at 18:38
  • @rip... This answers my question. Although JCA/JCE should work on this to make it secure because SunPKCS#11 alone is not sufficient to make code vendor independent. Isn't it :) – snesh Sep 25 '18 at 11:29

1 Answers1

0

If you unwrap the key... you get back the key. ie, unwrapping a key exposes the key. If you are asking the HSM to unwrap the key, it is doing what you told it to do.

Maybe you want to import the key instead, if the HSM supports this operation. The assumption on key import is that the HSM understands the format in which the key has been wrapped for security/protection/transport.

It will then do the unwrap for you, and save the unwrapped key in its database. Maybe it then hands you back the key as a handle, or as a differently wrapped key (ie, wrapped using its internal master key).

Moving a key between comparable HSMs is export/import or backup/restore, depending on the device and the devices' understanding of those verbs.

Moving a key between different vendor's HSMs or different cryptosystems, without exposing the secrets is an interesting exercise.

rip...
  • 996
  • 5
  • 20