PKCS#11. Possibility of performing Ecryption/Decryption in hardware

Question

Cheers. This is a copy of my question on crypto stack exchange.

I'm dealing with HSM via PKCS#11 C/Python interface. I'm wondering is it possible to do some C_Encrypt/C_Decrypt in hardware. By saying "in hardware" I mean encryption/decryption without exposing the result to the caller space. This is mostly aboud decryption as I want to call C_Decrypt and leave the result inside the HSM as arbitrary data to do some other transformations on that data later, saying re-encrypting it on some other key. Thank you in advance.

Trailblazer

Answer 1

PKCS#11 does not provide such methods but certain HSM models allow you to extend their firmware with your own algorithms/mechanisms or even run your own application inside the device so there surely is a way to achieve what you want. Just not with PKCS#11 API.

BTW I've discussed exactly this scenario in pkcs11-comment mailing list of OASIS PKCS#11 Technical Committee back in 2013. Sadly I didn't receive any feedback ¯\_(ツ)_/¯ but later when I wanted to join technical committee to work on this proposal I received pricelist with membership dues :D.

My mail from 2013:

I would like to open discussion about secure data re-encryption and the ways it can be handled with PKCS#11 API. Let's say there are some data encrypted with symmetric key A and for some reason (i.e. key life-time ended, encryption algorithm is not considered secure anymore etc.) there is a need to re-encrypt data with key B. What options does PKCS#11 API provide?

OPTION #1: Decrypt data with key A and C_DecryptInit/C_Decrypt/C_DecryptUpdate/C_DecryptFinal functions and then encrypt data with key B and C_EncryptInit/C_Encrypt/C_DecryptUpdate/C_DecryptFinal functions.

Advantages:

• uses current well known PKCS#11 API

Disadvantages:

• possible security issues - plaintext is unnecessarily exposed to the host memory
• communication overhead - plaintext needs to be exchanged twice between cryptoki app and cryptoki module

OPTION #2: Let's say new PKCS#11 function(s) for data re-encryption would be introduced. It should take ciphertext created with key A as an input and provide ciphertext created with key B as an output. In other words it should decrypt and then encrypt data in one call. This can be achieved for example by introducing C_DecryptEncryptUpdate function with behavior similar to C_DecryptVerifyUpdate (it would most likely have similar pipelining issues too).

Advantages:

• Eliminates disadvantages of OPTION #1:

  • decrypted plaintext does not need to be exposed to the host memory because implementation where plaintext never leaves secure device is possible
  • performance should be increased because 50% less data needs to be exchanged between cryptoki app and cryptoki module/device

Disadvantages:

• new method(s) need to be introduced in PKCS#11 API

Personaly I would definitely like to see API for secure date re-encryption introduced. What are your opinions? Does anyone else miss API for secure data re-encryption?

Shaker

Wow. Thanks for your feedback. I hope they will introduce this king of scenario someday :) – Trailblazer

As it looks like a pretty common case. – Trailblazer

Answer 2

No, PKCS#11 does not support what you need.

Nearest operation to your requirement is C_UnwrapKey, which is used for creating a key object inside HSM using decrypting sent data using another key. But I don't think it satisfy your needs.

Tricycle

Yeah, I was looking about playing around with C_Unwrap. And I'ts the only option I have for now. – Trailblazer

Answer 3

If all you need is to re-encrypt the data later under another key you may store it (using C_UnwrapKey) as a sensitive generic secret key inside HSM. Then you can later re-encrypt it using C_WrapKey with a different wrapping key.

See this answer for example code.

---

There are some PKCS#11 mechanisms that allow basic plaintext key data manipulation -- like concatenation, XOR, range extraction (see section 'Miscellaneous simple key derivation mechanisms' in the PKCS#11 specification), but they are usually disabled by HSM policy because they can be used for key-extraction attacks (see e.g. here).

Technically you can combine them to perform various shifts, swaps, etc.

---

If methods above are not an option in your scenario then using a custom code running inside HSM is possible (as jariq writes in his answer). See here and here for some options.

Resent