开源之夏06：SKF接口与智能密码钥匙
8 月底，项目必须开始 SKF（Smart Key Function Interface，智能密码钥匙功能接口）部分。和 SDF 不同，SKF 面向的是完全不同的硬件形态和应用场景。
SKF vs SDF：
SDF 面向”机房里的高速密码模块”，SKF 面向”每个人手里的 U-key/USBKey”。
| 维度 | SKF（GM/T 0016） | SDF（GM/T 0018） |
|---|---|---|
| 面向场景 | 个人终端、PC、移动设备 | 服务器、数据中心、网关、云 |
| 典型硬件 | USBKey / U-key / 蓝牙 Key / NFC Key | PCI-E 密码卡 / 服务器密码机 / HSM |
| 性能要求 | 低并发、低功耗、便携 | 高并发、高速、7×24 连续 |
| 接口使用者 | 浏览器、VPN 客户端、桌面应用 | 操作系统、中间件、数据库 |
| 设备管理 | 需要枚举、热插拔、事件通知 | 不需要：系统启动时由驱动加载 |
为什么 SKF 走 Engine，SDF 不用？
根本原因在于部署模型不同：
**SKF 设备”长在应用旁边”**：U-key 插在终端上，进程一启动就要枚举、认证、打开。认证口令和 PIN 码都在应用进程内部流转。用 ENGINE 把整条流程封装成 OpenSSL/GmSSL 的 EVP 钩子最省事。
**SDF 设备”长在系统深处”**：密码卡在机房，系统启动时由 root 做一次初始化，之后普通业务进程通过内核驱动或独立守护进程拿到会话句柄。调用链是：业务 → GmSSL → 内核 ioctl/Unix Socket/RPC → 硬件。这跟 ENGINE 的”把算法钩子直接指向用户态 so”不匹配。
SDF 可以走 Provider 吗？
技术上完全可以，但要分清”能不能”和”应不应该”。OpenSSL 3.x 的 Provider 体系允许把任何算法/设备接入，国内几家 HSM 厂商已经提供了 SDF-provider 原型。但真正的坑在于：
- 会话生命周期管理：provider 里要自己维护”设备句柄池”，不能简单地把
SDF_OpenSession直接映射成EVP_PKEY_CTX_new() - 跨进程/线程安全：密码卡驱动通常只允许一个进程打开有限个设备句柄，需要引用计数和死锁检测
- 配置/部署复杂度：provider 仍需要 root 权限做设备初始化
目前主流做法：个人 USBKey → SKF-provider（已有，简单易用）；机房密码卡 → 继续用独立 SDK、内核驱动或 RPC 服务。
智能密码钥匙的硬件架构
SKF 的”智能”不是会认人，而是自带一整套国密算法的安全 SoC（System on Chip）——把以下所有东西做到同一块芯片里：
- CPU：32 位 RISC 安全核，运行 COS（Chip Operating System）
- 存储器：ROM（固化算法）、RAM（运行时内存）、EEPROM/Flash（存证书、私钥、文件系统）
- 国密算法加速器：SM2、SM3、SM4、RSA 硬件协处理器
- 真随机数发生器（TRNG）：用于密钥生成
- 接口控制器：USB、ISO7816（智能卡）、SPI 等
- 安全传感器：电压、温度、光检测，防物理攻击
这张卡看起来只是”U 盘”，实际上是一台完整的微型计算机。
正因为卡内有完整密码协处理器，所以接口里必须包含全部密码服务。私钥一旦离开卡体，安全性就降到软件级；加密、签名、协商会话密钥都要在卡内完成。
U 盾与 SKF 的关系
市面买到的 U 盾（USBKey），90% 以上内部就是 SKF 芯片。U 盾 ≈ 商业品牌/场景包装，SKF = 技术规范 + 合规认证（通过国家密码管理局 SKF 检测、拿型号证书）。
为什么 SKF 有细化的设备管理函数而 SDF 没有？
SKF 需要 SKF_WaitForDevEvent、SKF_EnumDev、SKF_ConnectDev 等函数，SDF 不需要。原因在于 SDF 的设计假设设备一直在线、固定不动，设备管理下沉到驱动/操作系统/厂商工具，标准本身不再重复定义。
接口数据格式层：GM/T 0017
SKF 有两层规范：
- GM/T 0016（SKF 接口规范）：定义 C 函数接口
- GM/T 0017（接口数据格式）：定义 C 函数 ↔ 字节流协议的映射
这一层是”翻译官”——应用层只认识 C 函数 SKF_Encrypt(...)，USB/蓝牙链路只认字节流（APDU、TLV），接口数据格式层负责：序列化（C 参数→ APDU 报文）、分片/重组、错误码映射、重试/超时、多设备并发区分。
SKF 协议栈的完整结构：
1 | |