3、密钥分发安全：传输协议、封装机制与协商协议
密钥分发，说白了就是解决一个核心问题：怎么把密钥安全地送到对方手里。你想想看，如果密钥在传输过程中被截获，那后续所有加密工作都白做了。我在做安全审计时，见过不少系统在密钥分发环节出问题，结果整个加密体系形同虚设。
这一章，我们重点看三个层面：密钥传输协议、密钥封装机制（KEM）、密钥协商协议。它们各自解决不同场景下的密钥分发问题。
3.1 密钥传输协议：TLS、SSH、IPsec
密钥传输协议，就是通过安全通道把密钥送过去。常见的三个协议：TLS、SSH、IPsec。它们虽然用途不同，但核心思路类似——先用非对称加密协商一个临时密钥，再用这个临时密钥加密后续通信。
3.1.1 TLS（传输层安全协议）
TLS 是 Web 安全的基础。我建议你重点关注它的握手过程，尤其是密钥交换部分。
TLS 1.3 密钥交换核心流程：
- 客户端发送支持的密码套件和随机数
- 服务器选择密码套件，发送证书和公钥
- 客户端验证证书，生成预主密钥（Pre-Master Secret）
- 双方通过密钥派生函数（KDF）生成会话密钥
- 后续通信使用对称加密
我个人习惯在审计时重点检查两点：一是证书链是否完整，二是是否使用了弱密码套件。我曾经遇到一个项目，TLS 配置里居然还开着 RC4 和 3DES，这简直是给攻击者留后门。
⚠️ 合规要点：根据 PCI DSS 和 NIST SP 800-52，TLS 1.0 和 1.1 已被禁用。必须使用 TLS 1.2 或 1.3，且禁止使用弱密码套件（如 RC4、3DES、CBC 模式）。
3.1.2 SSH（安全外壳协议）
SSH 主要用于远程管理。它的密钥交换过程与 TLS 类似，但有个关键区别——SSH 使用主机密钥（Host Key）来验证服务器身份。
我记得有一次审计，发现某团队把 SSH 主机密钥直接硬编码在脚本里。嗯，这其实很常见，但风险极大。主机密钥泄露意味着中间人攻击成为可能。
| 协议 | 主要用途 | 密钥交换方式 | 常见风险 |
|---|---|---|---|
| TLS | Web 通信、API 调用 | ECDHE、DHE | 证书验证不严、弱密码套件 |
| SSH | 远程管理、文件传输 | Diffie-Hellman、ECDH | 主机密钥泄露、弱算法 |
| IPsec | VPN、站点间通信 | IKE（基于 DH） | 配置复杂、IKE 版本兼容 |
3.1.3 IPsec（互联网协议安全）
IPsec 工作在网络层，比 TLS 和 SSH 更底层。它的密钥交换通过 IKE（Internet Key Exchange）协议完成，核心还是 Diffie-Hellman。
IPsec 的审计难点在于配置项太多。我曾经审计过一个跨国企业的 VPN 部署，发现 IKE 使用了 1024 位的 DH 组。这在 2024 年已经不够安全了，我建议至少使用 2048 位或椭圆曲线版本。
3.2 密钥封装机制（KEM）
KEM 是近年来比较热门的话题，尤其是在后量子密码领域。它的思路很简单：用接收方的公钥加密一个随机生成的密钥，然后发送过去。接收方用自己的私钥解密，就能得到这个密钥。
说白了，KEM 就是「公钥加密 + 密钥派生」的组合。但与传统 RSA 加密不同，KEM 更安全，因为它避免了直接使用 RSA 加密带来的填充问题。
💡 实际应用：NIST 在 2024 年选定的后量子密码标准中，KEM 方案（如 Kyber）是核心组件。如果你现在开始设计新系统，我建议考虑支持混合 KEM（传统 + 后量子），为未来做准备。
KEM 的合规审计要点：
- 检查是否使用了经过认证的 KEM 实现（如 NIST 标准）
- 确认密钥派生函数（KDF）是否安全（推荐 HKDF）
- 验证封装和解封装过程是否一致
3.3 密钥协商协议：Diffie-Hellman 与 ECDH
密钥协商协议，让双方在不安全的信道上共同生成一个共享密钥。最经典的就是 Diffie-Hellman（DH）协议。
3.3.1 Diffie-Hellman 协议
DH 协议的核心思想：双方各自生成私钥，计算公钥并交换，然后各自用对方的公钥和自己的私钥计算出相同的共享密钥。
数学原理其实不复杂：
Alice 生成：私钥 a，公钥 A = g^a mod p
Bob 生成：私钥 b，公钥 B = g^b mod p
Alice 计算：共享密钥 = B^a mod p = g^(ab) mod p
Bob 计算：共享密钥 = A^b mod p = g^(ab) mod p我在项目中遇到过一个问题：有人直接使用了 512 位的 DH 素数。这在 2024 年基本等于没加密。我建议 DH 素数至少 2048 位，最好 3072 位或更高。
⚠️ 避坑指南：我曾经审计过一个金融系统，发现 DH 参数使用了固定的「标准素数」。虽然素数本身没问题，但攻击者可以预先计算针对该素数的离散对数表。我建议使用 RFC 7919 推荐的命名组（Named Groups），或者每次生成新的素数。
3.3.2 ECDH（椭圆曲线 Diffie-Hellman）
ECDH 是 DH 的椭圆曲线版本。它用更短的密钥长度提供相同级别的安全性。比如，256 位的 ECDH 安全性相当于 3072 位的传统 DH。
我个人习惯优先推荐 ECDH，原因有三：
- 性能更好：计算量小，适合移动设备和 IoT
- 密钥更短：减少存储和传输开销
- 安全性更高：同等安全强度下，椭圆曲线离散对数问题更难破解
但 ECDH 也有坑。我记得有一次审计，发现某系统使用了 secp256r1 曲线，但实现中未验证公钥是否在曲线上。这会导致无效曲线攻击（Invalid Curve Attack）。嗯，这里要注意：ECDH 实现必须验证对方公钥是否在指定曲线上。
3.4 知识体系总览
下面这张图，把本章的核心知识点串起来了。你可以把它当作一个快速参考。
3.5 合规审计要点总结
做密钥分发安全审计时，我通常会按以下清单逐项检查：
- 协议版本：是否使用最新稳定版本（TLS 1.3、SSH-2、IKEv2）
- 算法强度：DH 素数 ≥ 2048 位，ECDH 曲线 ≥ P-256，禁止使用 RSA 加密直接传输密钥
- 前向安全性：必须支持 PFS（Perfect Forward Secrecy），推荐 ECDHE
- 证书管理：证书链完整，CRL/OCSP 配置正确，私钥保护到位
- 实现验证：检查公钥验证、曲线点验证、随机数生成等实现细节
💡 我的经验：审计时最容易忽略的是「降级攻击」防护。比如，攻击者可以强制客户端使用弱 DH 组。我建议在服务器端禁用所有弱算法，并启用 HSTS（TLS）或严格主机密钥检查（SSH）。