问题标签 [cryptoki]

我正在使用带有 NCryptoki dll 的 Pkcs#11 来使用我们的 HSM 并管理密钥。

为什么这段代码有时会给我错误 145 (CKR_OPERATION_NOT_INITIALIZED)？我试图避免它，但我仍然错过了一些东西......这个错误在调用 session.Encrypt() 时随机发生。

openSessionTupla 在哪里

我有一个简单的方法来使用 Pkcs11Interop 访问我的 HSM。

这是功能：

当它收到来自客户端的调用时，我在套接字服务器中调用了这个方法。

为了测试它，我创建了一个带有循环的小程序。在这个循环中，它每秒向使用 Pkcs11Interop 的服务器发送大约 3 个请求。

我们称这个测试程序为 tester.exe。如果我运行 tester.exe，一切似乎都正常。但是，当第一个 tester.exe 正在运行时，我尝试执行 tester.exe 的另一个实例，我得到了错误

Net.Pkcs11Interop.Common.Pkcs11Exception：方法 C_Initialize 返回 2147483907

在这个特定的行代码中：

为什么？哪个是问题？

更新：

应用类型是

并且设置初始化是：

更新2：

每次调用时，服务器实例上面的类并调用findTargetKeySValue方法。如果服务器收到并发请求，则 HSM 交互失败......但我快疯了，会话每次都不同，就像规范所说的那样。

更新3

我创建了这个简单的片段来测试多线程（findTargetKeySValue 在上面定义）并且它崩溃并显示消息“方法 C_Initialize 返回 2147483907”。此代码是供应商定义的，并且是CKR_CRYPTOKI_UNUSABLE。我将在接下来的测试中使用它。

更新4：

我更改了代码

我用 UPDATE3 中的代码调用它。当代码调用时，我得到 方法 C_FindObjectsFinal 返回 CKR_OPERATION_NOT_INITIALIZED

在我有开发人员的库中，将源密钥和CK_INVALID_HANDLE（而不是包装密钥）传递给C_wrapKeyAPI，作为回报，我得到了成功。

我怀疑这种行为。这是正确的返回码吗？

我使用 pkcs11 库在 c# 中使用 hsm 设备进行密封过程（不使用任何其他库）。错误消息是 Message ="CKR_USER_PIN_NOT_INITIALIZED " 怎么了？谢谢

我试图对此链接发表评论https://stackoverflow.com/a/39798597/448266，但由于声誉#而无法评论。

我已经尝试了示例并且运行良好，但是当我更改为任意值时，它返回异常消息：Net.Pkcs11Interop.Common.Pkcs11Exception：方法 C_CreateObject 返回 2147483968

我正在使用安全网 HSM SW。

下面是代码快照，我对键值稍作改动（如上）。

我创建了一个 web 服务 isAlive 来检查我是否可以使用 Cryptoki 创建与 HSM 软件的会话，我使用 SoapUI 自动执行我的 web 服务，所以我每 40 秒循环执行一次我的服务，它运行良好但经过一个数字在我重新启动我的应用程序之前，我无法连接到我的 HSM：这是我用来连接到 HSM 的代码部分

在执行我的服务期间，我查看日志，我发现 session.longValue() 每次调用都会增加：

这是日志：

我问是否有人知道 Cryptoki.C_OpenSession 的工作原理以及为什么我从 HSM 断开连接

需要使用已知值 HSM“slot #”、“key label”查询 HSM（在 Python 中）以获得（未知值）“key handle”。

有什么建议么？

我正在使用C_Decrypt该CKM_AES_CBC_PAD机制。我知道我的 272 字节长的密文实际上应该解密为 256 字节，这意味着添加了一个完整的填充块。

我知道根据标准，在使用 NULL 输出缓冲区调用时C_Decrypt，函数可能会返回比实际所需长度稍长的输出长度，特别是在使用填充时，这是可以理解的，因为函数不知道有多少填充字节位于最终块中，而不执行实际解密。

所以问题是，如果我知道我应该得到准确的 256 字节，例如在我上面解释的场景中CKR_BUFFER_TOO_SMALL，尽管传递了 256 字节的缓冲区，我仍然得到错误是否有意义？（说清楚：我是在相应的输出缓冲区长度参数中表示这是输出缓冲区的长度，看C_Decrypt的参数来观察我的意思）

我在使用 Safenet Luna 设备时遇到了这种行为，但不知道该怎么做。是我的代码没有通过在输出缓冲区中传递 NULL 来首先查询长度的错误，还是 HSM/PKCS11 库端的错误？

我也许应该提到的另一件事是，当我提供 272 (256+16) 字节的输出缓冲区时，调用成功，我注意到我正在取回我预期的明文，还有填充块，这意味着 16 个最终字节值 0x10。但是，输出长度正确更新为 256，而不是272 - 这也证明我没有意外使用 CKM_AES_CBC 而不是 CKM_AES_CBC_PAD，我也怀疑过 :)

我有一个主密钥，并希望将其多样化/派生为其他密钥（在 HSM 内）。遵循此答案后，我有以下代码：

如您所见，我正在使用 PKCS#11 包装器 (IAIK)。问题是生成具有相同推导数据的不同密钥的推导。这是预期的行为吗？

我认为派生密钥每次都不同，因为我用这个密钥加密一个已知值，结果每次都不同：

第一次运行密钥推导和值加密

第二轮密钥推导和值加密

第三轮密钥推导和值加密

据我所知，推导是使用基本密钥对数据（推导数据）进行加密。然后将此加密值转换为另一个密钥（派生密钥），因此如果派生数据和基本密钥相同，则该值应该相同，此答案解释了此步骤。

PKCS#11 是否打算CK_CHAR并CK_BYTE具有相同的语义，或者CK_CHAR旨在暗示可印刷性？

标准 PKCS#11 类型标头CK_CHAR根据CK_BYTE“字符”而不是“值”进行定义：

这是否保证每个CK_CHAR（和CK_CHARs 数组）都在可打印范围内？