PKCS#11中BCryptSecretAgreement/BCryptDeriveKey等效实现及ECDH密钥派生问题

问题描述 #

我有一个Linux应用，需要通过ECDH生成派生密钥。目前拿到了临时公钥和KDF参数，要求生成的派生密钥必须和Windows服务器端的结果一致——Windows端是用临时私钥、智能卡公钥加上相同KDF参数，通过BCryptSecretAgreement和BCryptDeriveKey API生成的，但现在两端结果不匹配。

我在Linux端用PKCS#11的C_DeriveKey API，结合智能卡存储的私钥、对等方公钥和KDF参数，一步生成CKO_SECRET_KEY类型的派生数据，代码如下：

CK_ECDH1_DERIVE_PARAMS ecdh_parms;
memset(&ecdh_parms, 0, sizeof(ecdh_parms));
ecdh_parms.kdf = CKD_SHA256_KDF;
ecdh_parms.ulSharedDataLen = 0;
ecdh_parms.pSharedData = NULL;
ecdh_parms.ulPublicDataLen = buf_size;//peer public key size
ecdh_parms.pPublicData = buf; // peer public key

mech.pParameter = &ecdh_parms;
mech.ulParameterLen = sizeof(ecdh_parms);

rv = p11->C_DeriveKey(session, &mech, privateKey, newkey_template, n_attrs, &newkey);

但派生数据和Windows端不匹配。另外，我尝试设置ecdh_parms.kdf = NULL先派生共享密钥，再用这个共享密钥调用C_DeriveKey时，会抛出CKR_KEY_HANDLE_INVALID错误。

想请教：PKCS#11中与BCryptSecretAgreement和BCryptDeriveKey等效的接口是什么？我原本以为C_DeriveKey能同时实现两者的功能，但实际没成功。

解答 #

等效接口说明 #

PKCS#11里，C_DeriveKey确实可以同时完成ECDH密钥协商（对应Windows的BCryptSecretAgreement）和密钥派生（对应BCryptDeriveKey）的功能，但需要严格匹配两端的参数细节和流程规范，尤其是KDF的实现逻辑差异。

两端不匹配的排查与解决步骤 #

1. KDF参数的细节对齐
   Windows的BCryptDeriveKey使用SHA256 KDF时，可能传入了额外的pbLabel或pbContext参数，而你当前的PKCS#11代码将pSharedData设为NULL。需要确认Windows端的KDF参数：如果有这些额外数据，必须对应传入PKCS#11的pSharedData中，且要注意数据的拼接顺序（通常是label在前、context在后，具体遵循BCrypt的KDF规范）。

2. 共享密钥的属性配置
   当设置kdf = NULL生成共享密钥后，这个密钥默认可能不支持作为KDF的输入。多数PKCS#11设备要求KDF输入密钥必须是CKK_GENERIC_SECRET类型，且需开启可导出属性。你可以在生成共享密钥的模板中添加以下属性：

{CKA_KEY_TYPE, &CKK_GENERIC_SECRET, sizeof(CKK_GENERIC_SECRET)},
{CKA_EXTRACTABLE, &CK_TRUE, sizeof(CK_TRUE)}

添加后再尝试用该密钥调用C_DeriveKey执行KDF运算。

3. 公钥编码格式验证
   ECDH公钥存在未压缩（65字节X9.62格式）和压缩（33字节）两种编码格式，如果两端公钥格式不一致，协商出的共享密钥会完全不同，直接导致派生结果不匹配。请检查你传入PKCS#11的公钥buf，确认其编码和Windows端的临时公钥完全一致。

4. PKCS#11驱动的KDF实现差异
   部分智能卡的PKCS#11驱动对CKD_SHA256_KDF的实现可能和BCrypt的规范存在细微差异（比如是否添加固定前缀）。如果上述步骤都无法解决问题，可以拆分流程手动验证：

   • 先用kdf = NULL生成共享密钥，通过C_GetAttributeValue获取其原始字节值（CKA_VALUE属性）
   • 按照NIST SP 800-56A或BCrypt的SHA256 KDF规范手动实现派生逻辑，用导出的共享密钥作为输入，搭配对应KDF参数生成结果，再和Windows端对比。

总结 #

PKCS#11的C_DeriveKey本身就是BCryptSecretAgreement + BCryptDeriveKey的等效接口，但必须保证两端的KDF参数、公钥格式、密钥属性完全对齐。如果一步式派生不匹配，拆分流程先导出共享密钥再手动实现KDF，是排查问题的有效手段。

内容的提问来源于stack exchange，提问作者chailatte