自研FIDO2认证器固件assertions.get API无响应排查求助

• CBOR结构合法性问题
  Chrome日志明确提到CBOR结构被拒绝，这是核心排查点：

  • 核对authenticatorGetAssertion响应的所有必填字段类型、顺序是否严格符合FIDO2规范，比如authData、signature必须是字节串，userHandle可选但类型需匹配规范要求
  • 重点检查扩展字段（0x04）的CBOR编码：自研设备的扩展数据可能存在类型错误（比如误用数组替代映射类型，或字段值类型不匹配），对比YubiKey的扩展CBOR序列化细节，确认编码逻辑差异
  • 验证CBOR标签（Tag）的使用是否合规，比如authData内嵌的扩展数据是否按规范编码

• 签名有效性验证失败
  浏览器会在本地先验证签名，失败则静默丢弃响应：

  • 确认签名算法与凭证创建阶段协商的一致（如ES256/RS256），检查签名生成时的哈希算法、签名格式是否完全符合FIDO2要求
  • 校验签名的原始数据：签名是对clientDataHash + authData的组合哈希进行签名的，确保两部分拼接顺序、哈希计算完全正确
  • 检查authData中的signatureCounter是否正常递增，若出现重复、倒退等异常值，浏览器会直接拒绝

• 扩展字段（0x04）的兼容性问题
  0x04对应hmac-secret扩展，若响应不符合Chrome预期会触发静默失败：

  • 确认该扩展是否在凭证创建阶段已被浏览器和服务器启用，断言阶段的扩展响应需与创建阶段的约定一致
  • 检查hmac-secret返回数据的格式：是否生成了符合要求的32字节HMAC密钥，CBOR编码是否为标准字节串类型
  • 若无需该扩展，可临时关闭设备端的hmac-secret支持，测试断言流程是否恢复正常

• Chrome特定校验逻辑触发拦截
  Chrome对FIDO2响应有额外的细节校验：

  • 核对authData中的userPresent、userVerified标志位是否与浏览器请求的要求匹配（比如请求要求用户验证，但设备返回标志位未设置）
  • 确认userHandle与凭证创建阶段的返回值完全一致，若存在差异浏览器会静默过滤
  • 检查设备的CTAP2版本标识，Chrome对CTAP2.1的部分特性有特定要求，对比YubiKey的版本实现调整自研设备的版本参数

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