📚 课程目录第3章密钥分发机制

3、密钥分发机制：从工厂到设备的信任链路

密钥分发，说白了就是解决一个问题——怎么把一把安全的钥匙，安全地交到设备手里。我见过不少团队，密钥算法选得挺强，结果分发环节出了漏洞，整个安全体系直接归零。这章咱们就把四种主流分发机制掰开揉碎讲清楚。

3.1 预置分发（工厂烧录）

这是最传统、也最直接的方式。设备还在产线上，就把密钥写进去。我个人习惯叫它“物理信任根”——因为密钥从未离开过硬件边界。

核心原则：烧录环境必须物理隔离，烧录完成后密钥立即从烧录工具中擦除。

3.1.1 烧录流程

密钥生成：在安全环境中生成设备唯一密钥对或对称密钥。
加密传输：密钥通过加密通道（如HSM对HSM）发送到烧录工位。
物理烧录：写入设备安全元件（SE）或eFuse区域。
验证回读：读取哈希校验，确认写入正确。
销毁源数据：烧录工具中的密钥副本立即清零。

我曾经踩过一个坑：某次产线审计发现，烧录工位的日志文件里竟然明文记录了密钥哈希。虽然哈希不是密钥本身，但攻击者可以用它做离线字典攻击。从那以后，我要求所有烧录日志必须过滤掉任何密钥相关字段。

3.1.2 工厂烧录的优缺点

维度	说明
优点	离线操作，无网络暴露面；密钥与硬件强绑定；适合大规模量产
缺点	密钥更新困难；产线安全管控成本高；一旦泄露影响整批次

3.2 在线分发（PKI/证书）

设备联网后，通过公钥基础设施（PKI）来获取身份证书和密钥。你想想看，这就像设备去“公安局”办身份证——CA就是那个发证机关。

3.2.1 PKI分发流程

设备注册：设备用预置的“初始凭证”（如烧录的对称密钥）向注册中心证明身份。
CSR生成：设备本地生成密钥对，将公钥放入证书签名请求（CSR）。
CA签发：CA验证设备身份后，签发设备证书。
证书安装：设备下载并安装证书，私钥始终不出设备。

我建议：CSR生成这一步一定要在设备安全元件内部完成。私钥如果暴露在CPU内存里，那PKI就白做了。我在一个智能门锁项目里见过，厂商用软件库生成密钥对，结果私钥被调试接口读出来了——嗯，那批锁全部召回。

3.2.2 证书生命周期管理

阶段	操作	注意事项
颁发	CA签发证书	设置合理的有效期（建议1-3年）
使用	TLS握手时出示	定期检查是否被吊销
续期	证书到期前重新签发	提前30天启动续期流程
吊销	设备退役或密钥泄露时	维护CRL或OCSP响应器

3.3 密钥协商协议（Diffie-Hellman）

DH协议解决的是：在不安全的信道上，双方如何安全地算出同一个共享密钥。说白了，就是“公开交换颜料，各自调出相同颜色”的数学魔法。

3.3.1 DH核心步骤

双方各自生成私钥（随机数）和公钥（私钥的数学变换结果）。
交换公钥（可以明文传输，因为从公钥推不出私钥）。
各自用对方的公钥和自己的私钥计算共享密钥。
结果相同——这就是后续通信的对称密钥。

注意：经典DH协议不具备身份认证能力。中间人攻击是它最大的软肋。我在一个车联网项目里就遇到过——攻击者伪造了ECU的公钥，结果TBox和攻击者建立了共享密钥，而ECU被晾在一边。

3.3.2 椭圆曲线DH（ECDH）

相比经典DH，ECDH用更短的密钥长度提供相同安全强度。我个人习惯在IoT设备上优先选ECDH，尤其是曲线P-256或Curve25519。原因很简单——设备算力有限，256位的ECDH比2048位的经典DH快了一个数量级。

// ECDH密钥协商示例（伪代码）
// 设备A
privateKeyA = generatePrivateKey(Curve25519)
publicKeyA = derivePublicKey(privateKeyA)
send(publicKeyA)

// 设备B
privateKeyB = generatePrivateKey(Curve25519)
publicKeyB = derivePublicKey(privateKeyB)
send(publicKeyB)

// 双方计算共享密钥
sharedSecretA = ecdh(privateKeyA, publicKeyB)
sharedSecretB = ecdh(privateKeyB, publicKeyA)
// sharedSecretA == sharedSecretB

3.4 安全传输通道（TLS）

TLS是上面三种分发机制的“运输车”。不管是PKI证书分发，还是DH密钥协商，最终都要靠TLS来保护传输过程。你想想看，如果传输通道本身是裸奔的，那密钥分发做得再好也没用。

3.4.1 TLS握手中的密钥分发

证书验证：服务端出示证书，客户端验证CA签名。
密钥交换：通过DH/ECDH协商会话密钥。
会话密钥生成：双方用协商出的预主密钥派生加密密钥和MAC密钥。
安全通信：后续数据用会话密钥加密传输。

我曾经在项目中遇到过：某厂商为了“省流量”，把TLS的证书验证阶段跳过了，只用了加密。结果攻击者用自签名证书就能冒充服务器，所有设备都连到了钓鱼服务器上。记住——TLS的加密如果没有身份验证做前提，那就是个空壳子。

3.4.2 IoT场景下的TLS优化

优化项	做法	效果
会话复用	缓存会话ID或使用会话票据	减少握手次数，降低延迟
OCSP Stapling	服务端主动附带证书状态	设备无需额外请求OCSP服务器
精简密码套件	只保留TLS 1.3和AEAD套件	减少握手体积，提升兼容性

3.5 四种分发机制对比

机制	适用场景	安全强度	运维成本
预置分发	离线设备、高安全要求	高（物理隔离）	中（产线管控）
PKI/证书	联网设备、大规模部署	高（依赖CA安全）	高（需维护PKI体系）
DH/ECDH	临时会话、前向安全性	中（需结合认证）	低（无中心化依赖）
TLS	通用安全传输	高（综合保护）	中（需管理证书）

3.6 密钥分发机制选型框架

下面这张图是我自己总结的选型逻辑，帮你快速判断该用哪种方式。

我的个人经验：没有银弹。预置分发适合高安全离线场景，PKI适合大规模联网设备，DH适合临时会话，TLS是所有在线分发的基础通道。实际项目中，我通常会用“预置根证书 + 在线PKI续期 + TLS 1.3”的组合——既保证了初始信任，又降低了运维成本。