干杯。这是我在加密堆栈交换上的question的副本。
我正在通过 PKCS＃11 C / Python接口处理 HSM 。我想知道是否可以在硬件中进行一些C_Encrypt / C_Decrypt的操作。说“在硬件中” 的意思是加密/解密而不将结果暴露给调用者空间。这主要是解密，因为我想调用C_Decrypt并将结果作为任意数据保留在HSM中，以便稍后对该数据进行其他一些转换，例如，将其用其他密钥重新加密。预先谢谢你。
答案 0 :(得分：3)
否，PKCS#11不满足您的需求。
您需要的最近操作是C_UnwrapKey，该操作用于通过使用另一个密钥解密发送的数据在HSM中创建密钥对象。但是我认为它不能满足您的需求。
答案 1 :(得分：3)
PKCS＃11没有提供这种方法，但是某些HSM模型允许您使用自己的算法/机制扩展其固件，甚至在设备内部运行自己的应用程序，因此肯定有一种方法可以实现所需的功能。只是不使用PKCS＃11 API。
顺便说一句，我在discussed exactly this scenario中的pkcs11-comment mailing list中OASIS PKCS#11 Technical Committee是pricelist with membership dues。可惜我没有收到任何反馈¯\_(ツ)_/¯，但后来我想加入技术委员会为了处理此提案，我收到了playground :D。
我2013年的邮件：
我想打开有关安全数据重新加密以及使用PKCS＃11 API进行处理的方式的讨论。假设有一些数据是用对称密钥
A加密的，并且由于某种原因（例如，密钥生命周期已结束，加密算法不再被认为是安全的，等等），有必要使用密钥{{ 1}}。 PKCS＃11 API提供哪些选项？选项1：：使用密钥
B和A函数解密数据，然后使用密钥C_DecryptInit/C_Decrypt/C_DecryptUpdate/C_DecryptFinal和B函数加密数据。< / p>优势：
- 使用当前众所周知的PKCS＃11 API
缺点：
- 可能的安全性问题-纯文本不必要地暴露给主机内存
- 通信开销-纯文本需要在cryptoki应用程序和cryptoki模块之间交换两次
选项2：：假设将引入用于数据重新加密的新PKCS＃11函数。它应将使用密钥
C_EncryptInit/C_Encrypt/C_DecryptUpdate/C_DecryptFinal创建的密文作为输入，并提供使用密钥A创建的密文作为输出。换句话说，它应该在一个调用中解密然后加密数据。例如，可以通过引入行为类似于B的{{1}}函数来实现此目的（它很可能也具有类似的流水线问题）。优势：
消除了选项1的缺点：
- 解密后的纯文本不需要暴露给主机内存，因为实现纯文本永不离开安全设备的实现是可能的
- 应提高性能，因为在cryptoki应用程序与cryptoki模块/设备之间需要交换的数据减少了50％
缺点：
- PKCS＃11 API中需要引入新方法
我个人绝对希望看到引入用于安全日期重新加密的API。您对此有何看法？还有其他人会错过用于安全数据重新加密的API吗？
答案 2 :(得分：0)
如果您需要稍后在另一个密钥下重新加密数据，您可以将其存储（使用 C_UnwrapKey）作为 HSM 中的敏感通用密钥。然后您可以稍后使用带有不同包装密钥的 C_WrapKey 重新加密它。
请参阅 this answer 以获取示例代码。
有一些 PKCS#11 机制允许基本的明文密钥数据操作——比如连接、异或、范围提取（参见 PKCS#11 规范中的“Miscellaneous simple key derivation mechanisms”部分），但它们通常被禁用HSM 策略，因为它们可用于密钥提取攻击（参见例如 here）。
从技术上讲，您可以将它们组合起来执行各种轮班、交换等。
如果上述方法在您的场景中不可用，则可以使用在 HSM 内运行的自定义代码（正如 jariq 在他的 answer 中所写）。有关某些选项，请参阅 here 和 here。