JCA/JCE和PKCS#11如何（共同）工作？

Question

我想使用HSM（硬件安全模块）对XML文件创建签名。我进行了一些研究，但现在有点困惑。

请您解答以下问题：

1. JCE中的“密钥处理句柄”是什么意思？据我所知，它只是一个句柄，而密钥存储在其他地方。这是怎么回事？按照我的理解，我要么将密钥加载到内存中并使用它，要么使用HSM完全完成签名，然后我只会得到结果，对吧？
2. PKCS#11标准是否定义了一种方法，使得签名在HSM中生成？我已经读过“令牌”的相关内容，但对签名不确定。
3. 我的HSM功能列表单独列出了JCE和PKCS#11。这是什么意思？
4. 我认为PKCS#11是一个标准，而JCE定义了使用该标准的类。JCE是否指定自己的协议？

- Andy

Answer 1

1. 什么是JCE中的密钥句柄(key handle)？
   密钥句柄(key handle)（在JCE、PKCS#11或其他大多数密码学API中）只是一个引用，使您能够使用密钥而不看到其实际值。这是很好的：您可以将密钥永久存储在安全位置（例如HSM）中，并确保没有人能够复制它并带走它 - 如果密钥在应用程序空间中，可能会发生这种情况。不像实体保险箱，您仍然可以执行加密操作，而不会有密钥泄漏的安全风险。

2. PKCS#11标准是否定义了一种在HSM中生成签名的方法？
   PKCS#11是用于加密令牌(cryptographic tokens)的C API。令牌(token)是PKCS#11抽象，用于描述提供由此类API描述的服务的任何设备或程序。该API定义了您可以使用PKCS#11令牌内部的对象执行哪些操作：其中一些对象是非敏感的，可以被提取(例如公共密钥)。其他一些对象是敏感的，只能通过句柄使用。
   如果您拥有支持签名的对象的句柄，则可以使用C函数C_Sign，请求令牌对您的应用程序提供的某些数据进行身份验证。密钥不会离开HSM。

3. 我的HSM功能列表中分别列出了JCE和PKCS#11。这是什么意思？
   您的HSM支持JCE，因为它配备了一个符合加密服务提供者(CSP)的原生库。
   它支持PKCS#11，因为它配备了一个提供C PKCS#11 API的本地库。

我认为PKCS#11是一个标准，而JCE定义了使用该标准的类。JCE是否规定了自己的协议呢？

实际上，PKCS#11是一个标准；但它不能直接被其他语言使用，需要一个映射层将其转换为与所使用语言兼容的内容。PKCS#11库（以及它抽象的物理令牌）可以映射到JCE提供程序。

然而，JCE提供程序可能与PKCS#11无关。

- SquareRootOfTwentyThree

---

请提供更多关于1的信息！我使用的API（XAdES4J，Java）使用“PrivateKey”创建签名。那是一个真正加载到RAM中的密钥，还是只是一个句柄？作为用户，我怎么知道？（我目前仅使用密钥库，因此无法调试它） - Andy

这取决于你的 KeyStore 是由什么支持的。如果它是 PKCS#11，并且您的提供商是您的 HSM，则密钥不会加载到 RAM 中，而是留在 HSM 内部。您只需处理其句柄。 - SquareRootOfTwentyThree

我仍然不清楚那个句柄的话题。 假设我在HSM插槽7中存储一个私钥"abcde"，这给了我一个ID为7的句柄。 现在我想使用该私钥创建签名。 我只看到两个选项：a）获取与句柄7相关联的私钥并自己创建签名（这意味着知道密钥“abcde”），或者b）将签名内容转移到HSM中，并告诉它使用插槽7，HSM会返回生成的签名。 对吗？我有遗漏什么吗？ - Andy

B选项是正确的情况。如果密钥正确生成，HSM在正常情况下不会释放私钥。 - SquareRootOfTwentyThree