Python PKCS11是否总是以相同的顺序查找对象？

我注意到bash命令和Python PyKCS11库中可能对应的方法似乎总是以相同的顺序查找对象。我的代码依赖于这是真实的，但没有在任何地方读过它，只是观察到了它

在终端中：

$ pkcs11-tool --list-objects 
Using slot 0 with a present token (0x0)
Public Key Object; RSA 2048 bits
  label:      bob_key
  ID:         afe438bbe0e0c2784c5385b8fbaa9146c75d704a
  Usage:      encrypt, verify, wrap
Public Key Object; RSA 2048 bits
  label:      alice_key
  ID:         b03a4f6c375e8a8a53bd7a35947511e25cbdc34b
  Usage:      encrypt, verify, wrap

使用Python：

objects = session.findObjects([(CKA_CLASS, CKO_PUBLIC_KEY)])
for i, object in enumerate(objects):
    d = object.to_dict()
    print(d['CKA_LABEL'])

输出：

bob_key
alice_key

对象

属于

列表

类型，而

对象

中的每个元素都属于

当从登录会话运行时，

session.findObjects（[（CKA_类，CKO_私钥）]）

是否也始终是一个与上述表达式顺序完全相同的列表？在这个有两个键的例子中，我永远都不想看到Alice出现在Bob之前。

（我想写一条评论，但它太长了…）

不保证返回对象句柄的任何特定顺序，因此由特定实现决定

尽管您的实现似乎始终提供相同的对象顺序，但在某些情况下，这可能会发生意外变化：

• 密钥续订（密钥不会永远有效。将来需要生成一些新密钥）

• 中间件升级（较新的实现可能会以不同的顺序返回对象）

• HSM固件升级（主要升级可能会更改对象的存储方式并更改对象枚举顺序）

• 从备份恢复HSM（在HSM恢复后，对象顺序可能会更改）

• 主机操作系统数据恢复（某些实现将加密的HSM对象存储在外部文件夹中，对象搜索顺序可能与目录列表顺序相同，可以在没有警告的情况下更改）

• HSM更改（您确定在应用程序的整个生命周期内使用相同的设备吗）

一般来说，依赖未定义的行为是一种不好的做法。特别是在安全方面，你应该非常谨慎

为了安全起见，这绝对值得花时间

---

我建议对每个必需的对象执行单独的搜索（使用一些强标识符——例如label）——这样您就可以执行额外的检查（例如强制执行预期的对象类型，确保对象是唯一的等等）

---

类似的例子是Cryptoki对象句柄的重用。PKCS#11声明对象句柄绑定到特定会话（即，如果在会话A中获得对象句柄，则不应在会话B中使用它——即使两个会话都在同一应用程序中运行）

有些实现在会话之间为同一对象保留对象句柄。甚至有一些实现在不同的应用程序中保留相同的对象句柄（即，如果在应用程序A中获得对象句柄123，则在应用程序B中获得相同对象的对象句柄123）

这种行为甚至在相应的开发人员手册中有描述。但是如果你问供应商你是否可以信赖它，你会被告知某些设置有一些极端情况，你必须进行额外的检查，以100%确保它能按预期工作

祝你的项目好运

PKCS#11是一个API，因此您总是至少有两个不同的软件组件：API用户和API实现。假设类似于和对象顺序，则不推荐这种情况。因此，我的建议是：如果您需要特定的顺序，请根据条目的标签或其他属性定义您自己的顺序。