HSM - cryptoki - 打开会话开销答案

【问题标题】：HSM - cryptoki - opening sessions overheadHSM - cryptoki - 打开会话开销
【发布时间】：2014-06-06 19:10:30
【问题描述】：

我有一个关于 HSM 会话的问题。

我知道，如果您为要加密/解密的每个文件初始化和最终确定 cryptoki api，则会产生开销。

我的问题是，

谢谢

【问题讨论】：

【解决方案1】：

首先，PKCS#11 spec 在有关线程、应用程序和会话的一般概述下拥有相当广泛的文档。

其次，这取决于您的 HSM 硬件和 PKCS#11 模块实现。您的 PKCS#11 提供商如何表示插槽？您是否一直使用相同的密钥？密钥的认证机制是什么？

尝试单个会话。你确定你的瓶颈是会话处理吗？

【讨论】：

我正在使用 C_Initialize((CK_VOID_PTR)&vInitArgs) 进行初始化，其中 vInitArgs.flags = CKF_OS_LOCKING_OK 其余为 NULL;CK_TOKEN_INFO -> ulMaxSessionCount =CK_UNAVAILABLE_INFORMATION 我的供应商没有共享此信息。我将使用不同的键（混合方法）。 CKM_SHA256_RSA_PKCS 用于签名/验证和 AES 用于加密和解密。我会随机遇到大约 50,000 个文件，每个文件大小约为 2 mb。需要验证签名，获取aes密钥和解密数据。由于我们已经投入生产，我想在进行任何重大更改（例如会话处理）之前确保。谢谢

【解决方案2】：

最好的方法绝对是在每次应用程序启动时打开一次会话。 IE。在您的应用程序工作时没有理由关闭会话 - 会话对您的应用程序是私有的，如果您打开会话，其他应用程序无法使用它来访问和使用设备。

【讨论】：

我的应用程序在多线程中运行，因此我需要打开多个会话，因为多线程不应该在单个会话中工作。在这些情况下，您是否认为频繁地打开和关闭会话会是一种开销？
打开会话总是有开销的，因此缓存会话并尽可能在线程之间重用它们是有意义的。
当你说缓存时，我怎样才能安全地实现这样的缓存？
使用一些多线程池类。我没有确切的参考资料来说明我编写这样的游泳池课程需要 15 到 20 分钟的工作。
这里的讨论变得非常有趣。我所有的应用程序都调用一个 web 服务（它通过我的 api 与 cryptokivia 交互）来自动管理我的线程。因此，除非我打开会话、处理并关闭会话，否则我无法控制哪个应用程序可以共享哪个会话句柄。如果我每次都为新线程打开一个新会话，我认为会打开太多会话，因为我无法控制线程的创建。有什么想法吗？

【解决方案3】：

打开和关闭会话有开销（来自我的实验）。最好不要为每个文件打开单独的会话。

更新：来自我的供应商：

您可以在令牌上打开的会话没有限制或指定数量，但它可能是数千个。

这取决于您在做什么以及它如何消耗设备的 RAM。打开太多会话并创建太多会话对象，达到 RAM 可以容纳的限制，肯定会影响设备的性能。

谢谢

【讨论】：