本文介绍了PKCS#11。在硬件中执行加密/解密的可能性的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

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我已经 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:

选项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。在硬件中执行加密/解密的可能性的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

07-09 07:11