PKCS＃11。在硬件中执行加密/解密的可能性 [英] PKCS#11. Possibility of performing Ecryption/Decryption in hardware

问题描述

干杯。这是我的问题在加密货币堆栈交换上的副本。

Cheers. This is a copy of my question on crypto stack exchange.

我正在通过 PKCS＃11 C / Python接口处理 HSM 。我想知道是否可以在硬件中执行一些 C_Encrypt / C_Decrypt 。说在硬件中 是指加密/解密而不将结果暴露给调用者空间。这主要是解密操作，因为我想调用 C_Decrypt 并将结果作为任意数据保留在HSM中，以便稍后对该数据进行其他一些转换，然后说将其重新加密。其他一些键。

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不提供此类方法，但是某些HSM模型允许您使用自己的固件扩展其固件。自己的算法/机制，甚至在设备内部运行自己的应用程序，因此肯定有一种方法可以实现所需的功能。只是不使用PKCS＃11 API。

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我已经在 OASIS PKCS＃的noreferrer> pkcs11评论邮件列表 11技术委员会早在2013年。可惜我没有收到任何反馈 ¯\_（ツ）_ // ，但是后来我想加入技术委员会负责该提案的委员会，我收到了含会员费的价格表 ：D 。

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.

我从2013年以来的邮件：

My mail from 2013:

我想公开有关安全数据重新加密以及使用PKCS＃11 API进行处理的方式的讨论。假设有一些数据用对称密钥 A 进行了加密，并且出于某种原因（即密钥生命周期结束，加密算法不再被认为是安全的，等等），有必要用密钥 B 重新加密数据。 PKCS＃11 API提供哪些选项？

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?

选项1：使用密钥 A 和 C_DecryptInit / C_Decrypt / C_DecryptUpdate / C_DecryptFinal 函数，然后使用密钥 B 和<$ c $加密数据c> C_EncryptInit / C_Encrypt / C_DecryptUpdate / C_DecryptFinal 函数。

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.

优点：

• 使用当前众所周知的PKCS＃11 API

缺点：

• 可能的安全性问题-明文不必要地暴露给主机内存


• 通信开销-明文需要在cryptoki应用程序和cryptoki模块之间交换两次

选项2：假设用于数据重新加密的新PKCS＃11函数将被介绍。它应该使用以键 A 创建的密文作为输入，并提供以键 B 创建的密文作为输出。换句话说，它应该在一个调用中解密然后加密数据。例如，可以通过引入 C_DecryptEncryptUpdate 函数来实现此功能，该函数的行为类似于 C_DecryptVerifyUpdate （它很可能具有类似的流水线问题）

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).

优点：

• 消除了OPTION＃的缺点1：

• Eliminates disadvantages of OPTION #1:

• 解密后的明文不需要暴露给主机内存，因为实现明文永远不会离开安全设备的可能性


• 性能应提高，因为cryptoki应用程序与cryptoki模块/设备之间需要交换的数据减少了50％

缺点：

• PKCS＃11中需要引入新方法API

我个人绝对希望看到用于安全日期重新加密的API。您对此有何看法？还有其他人会错过用于安全数据重新加密的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?

这篇关于PKCS＃11。在硬件中执行加密/解密的可能性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！