密钥分发与协商
我一直觉得，密钥分发是整个加密系统里最容易被低估的一环。你写了个再强的算法，如果密钥分发环节出了纰漏，那等于把保险柜钥匙放在门口脚垫下面。说白了，我们聊的这套边界系统，核心问题就是：两边的密钥是怎么安全地到对方手里的？
这个问题的答案，基本分成三条路：Diffie-Hellman 密钥协商、公钥基础设施（PKI） 和 预共享密钥（PSK）。每条路都有它适用场景，也各有各的坑。下面我一个个说。
Diffie-Hellman 密钥协商
Diffie-Hellman 这东西，我特别喜欢它的优雅之处。它允许两方在不安全的信道上，通过交换一些公开信息，各自算出一个相同的共享密钥。整个过程，任何人都能监听你交换的数据，但他就是推不出最终的密钥。
基本原理是这样的：
- 双方约定一个大素数 p 和一个底数 g。
- 甲方选一个秘密数 a，计算 A = g^a mod p，发给乙方。
- 乙方选一个秘密数 b，计算 B = g^b mod p，发给甲方。
- 甲方用收到的乙方公值和自己的秘密数算：K = B^a mod p。
- 乙方用收到的甲方公值和自己的秘密数算：K = A^b mod p。
- 两边算出来的 K 是同一个值！
数学上有个难点：已知 g、p、A，想从中反推出 a，这叫离散对数问题，计算难度非常大。大到你等不起，所以它安全。
解决方案： 必须结合签名（比如 ECDSA）或使用认证过的密钥交换协议（比如 SIGMA 族协议）来绑定身份。不要只用裸 DH。
为什么现在更推荐 ECDH 而不是传统 DH？我在项目中验证过，椭圆曲线版本的 DH 可以在同样安全强度下使用更短的密钥，通信量和计算量都小很多。对于移动设备或 IoT 节点来说，性能和带宽都很宝贵。建议直接用 ECDHE（临时 ECDH），它的前向安全性比静态 DH 好——万一长期密钥泄露了，之前会话的密钥不会跟着被破解。
prime256v1（也叫 secp256r1）或 X25519。X25519 在软件实现上速度更快、更不容易被侧信道攻击。我自己最近做的几个项目，基本上都迁移到了 X25519。
公钥基础设施（PKI）
PKI 这一套，说白了就是解决谁信谁的问题。你想确认对方公钥是不是真的，就得靠一个大家信任的第三方来担保。这个第三方就是证书颁发机构（CA）。
我遇到过很多开发者把 PKI 和 HTTPS 画等号，但 PKI 应用远比这个广。你想想，你车上的芯片固件更新、智能门锁的蓝牙配对、企业 VPN 客户端认证，底层都可能是 PKI。
PKI 的典型工作流程是这样：
- 注册： 客户端生成密钥对，把公钥和身份信息提交给 CA。
- 签发： CA 对信息做签名，生成数字证书（X.509 格式）。
- 验证： 对端拿到证书后，用 CA 的公钥验证签名。验证通过说明公钥有效、身份可信。
- 吊销： 证书泄露或失效时，CA 可以把它标记为吊销，可通过 CRL（证书吊销列表）或 OCSP 查询。
但是 PKI 也不是银弹。有些场景下，PKI 的证书管理变得非常复杂。比如说，IoT 设备可能数量巨大且分散，你让它们都定时去 CA 续签证书？网络不稳定怎么办？证书轮换失败怎么办？这些都会造成业务中断。
我的建议： IoT 环境尽量使用短生命周期证书，并配合 OCSP 装订（OCSP Stapling）降低验证延迟。如果设备资源受限，可以考虑使用预共享密钥来简化。
预共享密钥（PSK）
PSK 是什么？简单说，就是通信双方在建立安全通道之前，已经提前共同拥有一个秘密密钥。
这看起来最直接，但很多团队用错了地方。PSK 的典型用法包括：
- Wi-Fi 网络中的 WPA2/WPA3 预共享密钥。
- TLS-PSK 模式：直接在 TLS 握手时用 PSK 做身份验证和密钥导出。
- VPN 连接中的静态密钥认证。
PSK 的优势：实现简单、部署快、无需在线 CA、适合嵌入式设备。但它的劣势也很明显：
- 扩展性差。 如果网络里有上百个节点，每两个节点之间都要共享一对密钥，那密钥量就是 O(n²)。管理不过来。
- 更换成本高。 密钥一旦泄露，所有共享该密钥的设备都得重新部署。
- 缺乏前向安全性。 长期密钥若泄露，历史上所有加密通信都可能被解密。
避坑指南： 我曾经在评估一个嵌入式系统时发现，开发团队将 PSK 硬编码在固件里，且所有设备共享同一个 PSK。一旦有攻击者提取了某台设备的固件，整个系统的通信密钥全被破解了。所以，PSK 绝不能是固定值，最好每个设备一个独立 PSK，并且不能明文存储在非安全区。
三种分发方式的对比
下面这个表格我自己在决策时经常会翻出来看，选型时按照这个思路走基本不会出大错：
| 特性 | Diffie-Hellman (DH/ECDHE) | 公钥基础设施 (PKI) | 预共享密钥 (PSK) |
|---|---|---|---|
| 密钥管理复杂度 | 中等 | 较高（需管理CA、CRL、OCSP） | 较低（但大规模扩展难） |
| 身份认证支持 | 需额外签名或证书 | 原生支持（证书+CA签名） | 通过共享秘密隐式认证 |
| 前向安全性 | 立即支持（临时DH） | 需要协议配合 | 不支持（PSK为长期密钥） |
| 防中间人攻击 | 弱（裸DH无认证） | 强（有CA签名链验证） | 中等（PSK本身可信） |
| 性能开销 | 计算量大（DH/ECDHE指数运算） | 证书验证、CRL/OCSP处理 | 极低（对称操作） |
| 离线工作能力 | 需双方都在线 | 依赖CA在线 | 完全离线可用 |
| 典型适用场景 | TLS 握手、VPN 密钥协商 | 浏览器、企业设备认证、代码签名 | 嵌入设备、WPA2网络、少量节点场景 |
关于选型，我的经验是：不要迷恋某一种方案。 很多边界系统设计的失败，正是因为团队想用一个方案解决所有场景。你想想看，企业内部服务器之间通信，肯定是自建 PKI 最稳妥；但如果只是一对蓝牙锁和车主手机配对，你搞个复杂的 PKI 流程用户早疯了，直接 PSK 加临时 DH 就很好。