PKCS#11。在硬件中执行 Ecryption/Decryption 的可能性

PKCS#11. Possibility of performing Ecryption/Decryption in hardware

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

我正在通过 PKCS#11 C/Python 接口处理 HSM。我想知道是否可以在硬件中做一些 C_Encrypt/C_Decrypt。通过说 "in hardware" 我的意思是 encryption/decryption 没有将结果暴露给调用者 space。这主要是关于解密，因为我想调用 C_Decrypt 并将结果作为任意数据保留在 HSM 中，以便稍后对该数据进行一些其他转换，比如用其他密钥重新加密它。提前谢谢你。

不，PKCS#11 不支持您所需要的。

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

PKCS#11 不提供此类方法，但某些 HSM 模型允许您使用自己的 algorithms/mechanisms 甚至 运行 设备内部的应用程序扩展其固件，因此肯定有办法实现你想要的。只是不使用 PKCS#11 API.

顺便说一句，我 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 年的邮件：

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?

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

请参阅 示例代码。

有一些 PKCS#11 机制允许基本的明文密钥数据操作——如串联、异或、范围提取（参见“Miscellaneous simple key derivation mechanisms' in the PKCS#11 specification), but they are usually disabled by HSM policy because they can be used for key-extraction attacks (see e.g. here”部分）。

从技术上讲，您可以将它们组合起来以执行各种移位、交换等。

如果上述方法不适合您的场景，则可以在 HSM 中使用自定义代码 运行（正如 jariq 在他的 ). See here and here 中针对某些选项所写。