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

与世无争的帅哥 提交于 2019-12-05 12:43:56

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!