In PKCS#11 documentation § 2.1.23 is described how to wrap and unwrap a target asymmetric key of any length and type using an RSA key, called CKM_RSA_AES_KEY_WRAP. This mechanism could be easily implemented by hand in case it is not available in HSM.

The counterpart exists for EC, CKM_EC_AES_KEY_WRAP can wrap and unwrap an asymmetric target key of any length and type using an EC key. Unfortunately, the description of the wrapping mechanism only refers to EC wrapping key:

  • Generates a temporary random EC key (transport key) having the same parameters as the wrapping EC key (and domain parameters). Saves the transport key public key material.
  • Performs ECDH operation using CKM_ECDH1_DERIVE with parameters of kdf, ulSharedDataLen and pSharedData using the private key of the transport EC key and the public key of wrapping EC key and gets the first ulAESKeyBits bits of the derived key to be the temporary AES key.

Could someone explain to me and describe precisely how to wrap an RSA asymmetric target key using an EC key?

Obviously, if this is not recommended or not possible, I would also like to have an explanation of why.

  • $\begingroup$ ... does CKM_EC_AES_KEY_WRAP not do this? The quoted text says it generates a temporary key, encrypts the temporary key, and encrypts the wrapped key with the temporary key. $\endgroup$
    – user253751
    Apr 26 at 20:26
  • $\begingroup$ Yes, indeed, it does. Unfortunately it is not implemented in HSM very often, so we have to do it by hands... $\endgroup$
    – 3ric-T
    Apr 27 at 7:21

1 Answer 1


What you are asking is exactly what is being explained by the text you are quoting. The specification uses ECIES, a form of a hybrid cryptosystem using both asymmetric and symmetric cryptography.

That consists of ECDH with an ephemeral key pair specifically created for the wrapped key, which PKCS#11 seems to call the transport key. With the static wrapping public key and the ephemeral private key you can derive an AES key. That AES key can then be used to encrypt (wrap) the RSA key.

The ephemeral public key is stored with the ciphertext so you can use the static private unwrapping key to derive the same AES key to decrypt (unwrap).

Of course the devil is in the details, I haven't talked about the ciphertext format, the key derivation method used, the mode of operation used for AES (+ IV & possible authentication tag usage) nor the encoding of the RSA private key. I would have to look those up.

Unfortunately (EC)IES is in my opinion very underspecified. It should require parameterization, but I don't think the parameter format is specified anywhere. At least the above does show that the used KDF can be parameterized for CKM_ECDH1_DERIVE .

But above should give a good birds eye view for what is happening anyway.

  • $\begingroup$ If I understand it well, there is no link between the target key and the ephemeral transport EC key? Is there some advices to generate it having the same parameters as the wrapping EC key (and domain parameters)? $\endgroup$
    – 3ric-T
    Apr 26 at 14:28
  • $\begingroup$ What is the target key? The wrapping key or the key being wrapped? The ephemeral / transport key and the wrapping key need to use the same domain parameters. The wrapped key itself is unrelated. It is or gets encoded to bytes and then restored once it is unwrapped (possibly flipping some flags in the process, exporting a private key comes with some risk). $\endgroup$
    – Maarten Bodewes
    Apr 26 at 15:03
  • $\begingroup$ OK, got it :) I mistakenly believed that there was a link between the wrapped key and the ephemeral transport key. Your explanations were very useful. $\endgroup$
    – 3ric-T
    Apr 27 at 6:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.