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

Question

干杯。这是我在密码栈交换上的问题的副本。

我正在通过PKCS#11 C/Python接口来处理。我想知道是否有可能在硬件上做一些C_Encrypt/C_Decrypt。我所说的“在硬件中”是指不向调用方空间公开结果的加密/解密。这主要是aboud解密，因为我想调用C_Decrypt，并将结果作为任意数据留在HSM中，以便稍后对该数据进行其他转换，并表示在其他密钥上对其进行重新加密。提前谢谢你。

Answer 1

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

顺便说一句，我早在2013年就读过“纽约时报”( 讨论了这个场景 in pkcs11 11-评论邮件列表 of 绿洲PKCS#11技术委员会 )。遗憾的是，我没有收到任何反馈¯\_(ツ)_/¯，但后来，当我想加入技术委员会就这个提议工作时，我收到了会费价格表 :D。

我2013年的邮件：

我想开始讨论安全数据再加密以及如何使用PKCS#11 API来处理它。假设有一些用对称密钥A加密的数据，并且由于某种原因(即密钥生命周期结束，加密算法不再被认为是安全的等等)。需要用密钥B重新加密数据.PKCS#11 API提供了哪些选项？ 选项1：用密钥A和C_DecryptInit/C_Decrypt/C_DecryptUpdate/C_DecryptFinal函数解密数据，然后用密钥B和C_EncryptInit/C_Encrypt/C_DecryptUpdate/C_DecryptFinal函数加密数据。 优势：

• 使用当前著名的PKCS#11 API

缺点：

• 可能的安全问题-明文不必要地暴露在主机内存中。
• 通信开销-明文需要在加密应用程序和加密模块之间进行两次交换。

选项2:将引入用于数据重新加密的新PKCS#11函数，比如。它应该以键A创建的密文作为输入，并提供以键B创建的密文作为输出。换句话说，它应该在一个调用中解密并加密数据。例如，通过引入行为类似于C_DecryptEncryptUpdate的C_DecryptVerifyUpdate函数(很可能也会出现类似的流水线问题)，就可以实现这一点。

优势：

• 消除备选案文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

​

缺点：

• 需要在PKCS#11 API中引入新的方法

就个人而言，我绝对希望看到API为安全日期重新加密引入。你有什么意见？其他人会错过API来进行安全的数据再加密吗？

Answer 2

不，PKCS#11不支持你需要的东西。

与您的需求最近的操作是C_UnwrapKey，它用于使用另一个密钥解密发送的数据，在高速加工中创建密钥对象。但我不认为它能满足你的需要。

Answer 3

如果您所需要的只是稍后在另一个密钥下重新加密数据，则可以将其存储(使用C_UnwrapKey)作为HSM中敏感的通用密钥。然后，您可以使用带有不同包装密钥的C_WrapKey重新加密它。

例如，请参阅这个答案代码。

有些PKCS#11机制允许基本的明文密钥数据操作--比如连接、异或、范围提取(参见PKCS#11规范中的'各种简单的密钥派生机制‘部分)，但它们通常被HSM策略禁用，因为它们可以用于密钥提取攻击(参见这里)。

从技术上讲，您可以将它们组合起来执行各种轮班、互换等操作。

如果以上方法在您的场景中不是一个选项，那么使用在HSM中运行的自定义代码是可能的(正如jariq在他的回答中所写的)。有关一些选项，请参见这里和这里。