blocks|key|588013|text|在PKCS#11中，所有对象都使用用户PIN进行保护。他们没有自己的PIN。因此，没有标准的方法为特定的对象请求不同的PIN。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|588014|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

In PKCS#11 all objects are protected with a User PIN. They don't have their own PINs. So there's no standard way to ask for a different PIN for the particular object.

blocks|key|359289|text|PKCS#11的思想是有一个密码(PIN)来保护整个令牌。对位于同一令牌上的密钥的二次身份验证已完全排除在协议之外。如2.01规范所述：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|359290|使用由二级身份验证保护的私钥使用相同的进程和调用序列，就像使用仅受登录PIN保护的私钥一样。实际上，为Cryptoki版本2.01编写的应用程序将不加修改地使用二级身份验证。|blockquote|359291|这意味着：“二级认证不是我们的问题，这些机制必须在我们的协议之外实现”。|359292|但是，当密钥实际上位于相同的令牌这里上时，它们描述了公开几个PIN的技巧。|offset|length|359293|指向2.11规范的链接：这里|359294|entityMap|0|LINK|mutability|MUTABLE|url|http://interop.cryptsoft.com/pkcs11doc/v211/group__SEC__17__1__VIRTUAL__SLOTS__AND__TOKENS.html|1|http://interop.cryptsoft.com/pkcs11doc/v211/^0|0|0|0|G|2|0|0|C|2|1|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|Y|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|Z|8|@]|9|@$I|10|J|11|1|12]]|A|$]]|$1|K|3|L|5|6|7|13|8|@]|9|@$I|14|J|15|1|16]]|A|$]]|$1|M|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]|U|$5|P|Q|R|A|$S|V]]]]

The idea of PKCS#11 is to have 1 password (PIN) to protect the whole token. Secondary authentication on keys located on the same token has been completly left out of the protocol. As stated in the 2.01 specification :

<blockquote>
 Using a private key protected by secondary authentication uses the same process, and call sequence, as using a private key that is only protected by the login PIN. In fact, applications written for Cryptoki Version 2.01 will use secondary authentication without modification.
</blockquote>

Which translates into: "secondary authentication is not our problem. Such mechanisms must be implemented OUTSIDE of our protocol". 

However, they describe a trick to expose several PINs when the keys are actually located on the same token <a href="http://interop.cryptsoft.com/pkcs11doc/v211/group__SEC__17__1__VIRTUAL__SLOTS__AND__TOKENS.html" rel="nofollow">here</a>

Link to 2.11 specification: <a href="http://interop.cryptsoft.com/pkcs11doc/v211/" rel="nofollow">here</a>

blocks|key|585469|text|如果将保护.pfx或.pvk文件中私钥的密码称为“次要密码”，则错误。这些密码用于保护那些文件(.pfx或.pvk+)中的私钥，而不是HSM。在HSM中没有其他密码来保护密钥。如果您想调用api函数，您必须使用用户或管理PIN登录。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|585470|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you call password that protect private keys in .pfx or .pvk files as "secondary password" you are wrong. Those password is used to protect private keys in those files(.pfx or .pvk ) not the HSM one. There is no another password to protect keys in HSM. If you want to call api functions you have to login with user or admin PIN.

blocks|key|359219|text|作为尤金·梅耶夫斯基(+Eugene+Mayevski+写入+)，在PKCS#11中没有“对象PIN”这样的概念。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|359220|您可以实现以下模式的某些变体以获得类似的访问控制模型：|359221|注册一对密钥：|359222|通过C_GenerateKeyPair生成密钥对，并确保将私钥生成为仅会话对象(即使用CKA_TOKEN==FALSE)。另一种方法是以某种方式导入密钥对(此处不讨论)。|ordered-list-item|style|CODE|359223|生成一个强密码(或使用用户提供的密码)，并通过一些KDF运行它以获得“解锁密钥”。将这个“解锁键”保存在应用程序内存中。|359224|生成一个新的持久化对称“派生密钥”，它只允许使用例如CKA_TOKEN==TRUE和CKA_DERIVE==TRUE派生密钥(例如CKM_AES_KEY_GEN+)。|359225|使用例如，以“解锁键”字节作为输入多样化数据的CKM_AES_CBC_ENCRYPT_DATA和以“派生键”作为主键的“派生键”作为主键，派生出一个新的“包键”会话密钥对象。新键应该是只会话对象，并且应该只允许键包装(即CKA_TOKEN==FALSE和CKA_WRAP==TRUE)。|359226|使用“包键”将步骤1中的私钥对象包装为"key+blob“。|359227|存储"key“(在令牌内或它的外部)。|359228|从步骤1中删除私钥和“包键”。核弹密码和“解锁钥匙”。(即使前面的一些步骤失败，也要执行此步骤)|359229|在不知道密码的情况下，不能访问私钥。|359230|使用一对密钥：|359231|通过相同的KDF运行输入密码以获得“解锁密钥”。|359232|以与键注册期间相同的方式派生“环绕键”，但这次仅用于展开(即CKA_TOKEN==FALSE和CKA_UNWRAP==TRUE)。|359233|将"key+blob“解压缩到一个仅用于会话的私有密钥对象中。|359234|删除“包装键”。核弹密码和“解锁钥匙”。(即使前面的一些步骤失败，也要执行此步骤)|359235|请随意使用这对钥匙。|359236|删除私钥。(即使前面的一些步骤失败，也要执行此步骤)|359237|擦钥匙对：|359238|删除相关的“派生键”和“键blob”。|359239|一些额外的(随机)注释：|359240|使用的AES机制只是一些例子。如果使用CKM_AES_CBC_ENCRYPT_DATA，则必须将使用的IV与"key+blob“一起存储。|unordered-list-item|359241|注意所有的对象属性值(即拒绝所有不需要的东西)。如果您的设备支持某些供应商定义的扩展来控制对象的使用，那么一定要使用它们(例如，强制使用包装/解封/派生机制)。|359242|记住从内存/会话中删除/删除密码和临时密钥。|359243|使用特定于供应商的包装机制，因为它们可能提供更好的保护(如果可能)。|359244|删除会话对象的一种方便方法是关闭会话。|359245|如果包装机制没有提供“密钥blob”，您可能希望保护它的完整性。|359246|祝好运!|359247|声明:我不是密码专家，所以请验证我的想法。|359248|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/36445748/5128464|1|https://en.wikipedia.org/wiki/Key_derivation_function^0|S|2|0|0|0|0|2|H|17|G|0|P|3|1|0|Q|F|16|G|1T|F|0|N|O|32|G|3J|E|0|0|0|0|0|0|0|U|G|1B|G|0|0|0|0|0|0|0|0|J|O|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|2B|8|@]|9|@$A|2C|B|2D|1|2E]]|C|$]]|$1|D|3|E|5|6|7|2F|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|2G|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|2H|8|@$A|2I|B|2J|K|L]|$A|2K|B|2L|K|L]]|9|@]|C|$]]|$1|M|3|N|5|J|7|2M|8|@]|9|@$A|2N|B|2O|1|2P]]|C|$]]|$1|O|3|P|5|J|7|2Q|8|@$A|2R|B|2S|K|L]|$A|2T|B|2U|K|L]|$A|2V|B|2W|K|L]]|9|@]|C|$]]|$1|Q|3|R|5|J|7|2X|8|@$A|2Y|B|2Z|K|L]|$A|30|B|31|K|L]|$A|32|B|33|K|L]]|9|@]|C|$]]|$1|S|3|T|5|J|7|34|8|@]|9|@]|C|$]]|$1|U|3|V|5|J|7|35|8|@]|9|@]|C|$]]|$1|W|3|X|5|J|7|36|8|@]|9|@]|C|$]]|$1|Y|3|Z|5|J|7|37|8|@]|9|@]|C|$]]|$1|10|3|11|5|6|7|38|8|@]|9|@]|C|$]]|$1|12|3|13|5|J|7|39|8|@]|9|@]|C|$]]|$1|14|3|15|5|J|7|3A|8|@$A|3B|B|3C|K|L]|$A|3D|B|3E|K|L]]|9|@]|C|$]]|$1|16|3|17|5|J|7|3F|8|@]|9|@]|C|$]]|$1|18|3|19|5|J|7|3G|8|@]|9|@]|C|$]]|$1|1A|3|1B|5|J|7|3H|8|@]|9|@]|C|$]]|$1|1C|3|1D|5|J|7|3I|8|@]|9|@]|C|$]]|$1|1E|3|1F|5|6|7|3J|8|@]|9|@]|C|$]]|$1|1G|3|1H|5|J|7|3K|8|@]|9|@]|C|$]]|$1|1I|3|1J|5|6|7|3L|8|@]|9|@]|C|$]]|$1|1K|3|1L|5|1M|7|3M|8|@$A|3N|B|3O|K|L]]|9|@]|C|$]]|$1|1N|3|1O|5|1M|7|3P|8|@]|9|@]|C|$]]|$1|1P|3|1Q|5|1M|7|3Q|8|@]|9|@]|C|$]]|$1|1R|3|1S|5|1M|7|3R|8|@]|9|@]|C|$]]|$1|1T|3|1U|5|1M|7|3S|8|@]|9|@]|C|$]]|$1|1V|3|1W|5|1M|7|3T|8|@]|9|@]|C|$]]|$1|1X|3|1Y|5|6|7|3U|8|@]|9|@]|C|$]]|$1|1Z|3|20|5|6|7|3V|8|@]|9|@]|C|$]]|$1|21|3|-4|5|6|7|3W|8|@]|9|@]|C|$]]]|22|$23|$5|24|25|26|C|$27|28]]|29|$5|24|25|26|C|$27|2A]]]]

As Eugene Mayevski <a href="https://stackoverflow.com/a/36445748/5128464">writes</a> there is no such concept as "object PIN" in PKCS#11.

You may implement some variant of the following schema to get similar access control model:

Enrolling a key-pair:

<ol>
<li>Generate a key-pair via <code>C_GenerateKeyPair</code> and ensure the private key is generated as a session-only object (i.e. with <code>CKA_TOKEN==FALSE</code>). An alternative is to import the key pair somehow (not to be discussed here).</li>
<li>Generate a strong password (or use a user supplied one) and run it through some <a href="https://en.wikipedia.org/wiki/Key_derivation_function" rel="nofollow noreferrer">KDF</a> to get "unlocking key". Keep this "unlocking key" in your application memory.</li>
<li>Generate a new persistent symmetric "derivation key" which allows key derivation only (i.e. <code>CKA_TOKEN==TRUE</code> and <code>CKA_DERIVE==TRUE</code>) using e.g. <code>CKM_AES_KEY_GEN</code>.</li>
<li>Derive a new "wrap key" session-only key object using e.g. <code>CKM_AES_CBC_ENCRYPT_DATA</code> with the "unblocking key" bytes as input diversification data and using the "derivation key" as a master key. The new key should be a session-only object and should allow only key wrapping (i.e. <code>CKA_TOKEN==FALSE</code> and <code>CKA_WRAP==TRUE</code>).</li>
<li>Wrap the private key object from step 1 using the "wrap key" into "key blob".</li>
<li>Store the "key blob" (inside token or outside of it).</li>
<li>Delete the private key from step 1 and the "wrap key". Nuke password and "unlocking key". (Do this step even if some of the previous steps fail)</li>
<li>The private key should not be accessible without knowing the password.</li>
</ol>

Using a key-pair:

<ol>
<li>Run the input password through the same KDF to get the "unlocking key".</li>
<li>Derive the "wrap key" in the same way as during the key enrollment but this time for unwrapping only (i.e. <code>CKA_TOKEN==FALSE</code> and <code>CKA_UNWRAP==TRUE</code>).</li>
<li>Unwrap the "key blob" into a new session-only private key object.</li>
<li>Delete the "wrap key". Nuke password and "unlocking key". (Do this step even if some of the previous steps fail)</li>
<li>Use the key-pair at your will.</li>
<li>Delete the private key. (Do this step even if some of the previous steps fail)</li>
</ol>

Wiping the key-pair:

<ol>
<li>Delete the associated "derivation key" and "key blob".</li>
</ol>

Some additional (random) notes:

<ul>
<li>The used AES mechanisms are just examples. You would have to store the used IV together with "key blob" if using <code>CKM_AES_CBC_ENCRYPT_DATA</code>.</li>
<li>Pay a lot of attention to all object attribute values (i.e. deny everything what is not needed). If your device supports some vendor defined extensions to control object usage then do use them (e.g. to enforce wrap/unwrap/derive mechanisms allowed).</li>
<li>Remember to wipe/delete passwords and temporary keys from memory/session.</li>
<li>Use vendor specific wrapping mechanisms as they probably provide better protection (if possible).</li>
<li>A convenient way to delete session objects is to close the session.</li>
<li>You may want to protect the integrity of the "key blob" if it is not provided by the wrapping mechanism.</li>
</ul>

Good luck!

Desclaimer: I am no crypto expert, so please do validate my thoughts.

I'm making pkcs11 module for web app. It's remote storage for certificates and it provides API for signing data. API for signing looks like this:
sign(int CertificateId, char* Password, void* data, int lenght)

In pkcs11 module, the whole storage is represented by one single token. In the C_Initialize section, I authenticate to the server. I find objects with another API call and everything is fine. The problem is, when I call C_SignInit or C_Sign function, I dont know how to get secondary password for my object. 
Can anyone help me?

PKCS11, OBJECT PIN

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我正在为web应用程序制作pkcs11模块。它是证书的远程存储，并为数据签名提供API。用于签名的API如下所示:符号( int CertificateId，char*密码，void* data，int lenght)在pkcs11模块中，整个存储由一个令牌表示。在C_Initialize部分中，我向服务器进行身份验证。我使用另一个API调用找到对象，一切都很好。问题是，当我调用C_SignIni

问PKCS11，对象PIN
EN

回答 4

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问PKCS11，对象PINEN

回答 4

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问PKCS11，对象PIN
EN