jce - nCipher HSM 重定向 JCE key

Question

是否可以将通过 ncipher JCE API 生成的 key “重定向”到 pkcs11？我知道您可以通过 generatekey 命令重新定位，但我不知道如何对现有的 JCE key 执行此操作。第一个提示是针对“源应用程序”和 options don't seem to include JCE .它是否支持此处列出的选项之外的其他选项，还是我应该寻找一种不同的重定向方式？

这里的最终目标是导出通过 nCipher 的 JCE API 生成的一对 key (非对称和对称)(是的，我知道 HSM 的工作是保护 key ，导出通常不是一个好主意，但它是这里的要求)。我们能够导出通过 PKCS11 接口(interface)生成的 key ，但不能导出通过 JCE 生成的 key ，因此我们的想法是，如果我们可以将其从 JCE 重定向到 PKCS11，我们也可以导出这些 key 。如果有其他方法可以做到这一点，我们也愿意接受。

最后，JCE key 在对它们执行 nfkminfo 时显示为“已启用恢复”。这是否意味着它们可以导出，或者这里的恢复是否意味着其他含义？

Answer 1

免责声明:我为 Thales e-Security 工作，但不代表公司发言。

是的，您可以将 jcecsp key 重定向到 pkcs11。如果您的 kmdata/local 中有任何 jcecsp key ，/opt/nfast/bin/generatekey 将提供 jcecsp 作为源选项。如果您没有类似的 key ，它会悄悄地从源列表中忽略该选项。 但是，此重定向过程可能不会按照您的想法进行。所有重定向所做的只是更改应用程序类型和潜在的关联元数据:它不会更改 key 的基本功能，因为这些功能在生成时被烘焙到 protected key blob 中并且无法更改。

安全世界使用 nShield key ACL 来限制 key 的功能(签名、验证、加密、解密、包装、包装等)。 PKCS#11 直接从 key ACL 中提取其参数(CKA_SIGN 等)，并且在通过 API 生成 key 时，保存在 key blob 中的 ACL 直接从 key 模板中的参数派生而来。如果您将 CKA_SENSITIVE 设置为 FALSE，并且您的安全世界允许它，您可以生成并保存一个可导出 key 。 JCE 没有那么复杂:它根本没有 key 功能的概念，因此提供者必须使用 key 猜测用户的意图，并且它默认为一个相当大的集合。但是，由于您指出 HSM 的整个想法是保护 key 位而不是让您拥有它们，因此导出不是默认设置之一。当您创建 key 文件时，没有包含在 key 文件中的内容，您无法通过重新定位 key 来获得。

如果您想使用 JCE，您可以做的一件事是使用不同的提供程序生成 key ，然后使用 nCipherKM 提供程序将其存储在 nCipher.sworld KeyStore 中:这将导入 key 进入安全世界(如果您的世界允许)并将其保存为 key_jcecsp_* 文件。然而，这与 key 安全无关，因此从 HSM 的角度来看，不推荐这样做。您可以做的另一件事是下拉到 native nCore API，使用您需要的 ACL 条目生成 key ，然后将其变形为 JCE key 对象并将其保存在 HSM 支持的 keystore 中。使用您创建的 key 上的 ACL，您可以多次搬起石头砸自己的脚。多态性的记录非常少:询问 Thales Support，他们可以指导您。

最后，恢复能力意味着除了可以由运算符(operator)卡组保护的工作 key blob 之外， key 文件还有一个恢复 Blob。这是为了防止运算符(operator)卡组丢失:安全世界的管理员卡组可以使用 rocs 实用程序(替换运算符(operator)卡组)打开恢复 Blob，这将在新的 OCS 下写入新的 key 文件。不，这并不意味着 key 可以导出。这只是意味着您不会丢失 OCS。当然，失去 ACS 是不可能的，因为那是您的信任根。