Vfrdtyky

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.

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?

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.