encryption - PKCS#11。在硬件中执行加密/解密的可能性

Question

干杯。这是我的 question 的副本关于加密堆栈交换。

我正在处理 高铁通过 PKCS#11 C/Python 接口(interface)。我想知道是否可以做一些 C_Encrypt/C_Decrypt在硬件中。通过说“在硬件中”，我的意思是加密/解密而不将结果暴露给调用者空间。这主要是关于解密，因为我想调用 C_Decrypt并将结果作为任意数据留在 HSM 中，以便稍后对该数据进行一些其他转换，例如在其他 key 上重新加密它。先感谢您。

Answer 1

PKCS#11 不提供此类方法，但某些 HSM 模型允许您使用自己的算法/机制扩展其固件，甚至在设备内运行您自己的应用程序，因此肯定有一种方法可以实现您想要的。只是不使用 PKCS#11 API。

顺便说一句，我有 discussed exactly this scenario在 pkcs11-comment mailing list的 OASIS PKCS#11 Technical Committee早在 2013 年。遗憾的是，我没有收到任何反馈 ¯\_(ツ)_/¯但后来当我想加入技术委员会来处理这个提案时，我收到了pricelist with membership dues :D .

我 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?