密钥管理基础：对称与非对称密钥

说到密钥管理，我刚开始做安全项目那会儿，也被对称和非对称搞得有点晕。说白了，这两兄弟是加密世界的两根柱子。你选错了，后面系统设计会很难受。咱们今天就把它们掰开揉碎了讲。

对称加密：一把钥匙开一把锁

对称加密，你可以想象成你和室友合租一个快递箱。你放了个锁，把钥匙给了他一把。他拿钥匙开锁取件，就这么简单。加密和解密用的是同一把密钥。

具体到算法，目前用得最多的就是 AES。我接触过的项目中，八成以上都在用 AES-256。为什么？

• 速度快：特别适合大量数据的批量加密。
• 硬件友好：很多 CPU 甚至集成了 AES-NI 指令集，加密时基本不占 CPU。
• 安全性高：目前没有有效的攻击方法。

但对称加密也有个老生常谈的问题——密钥分发。钥匙怎么给到对方？

我在项目中遇到过这样的尴尬：一个数据交换平台，A 和 B 共享同一个密钥。A 把密钥通过微信发给了 B…… 嗯，大家应该知道问题在哪了。密钥一旦泄露，整个系统就形同虚设。

非对称加密：两把钥匙，一个公开一个藏好

非对称加密怎么解决密钥分发？思路很简单——制造一对密钥。公钥公开出去，谁都可以拿，私钥自己死死守住。

举个例子。我把我的公钥贴在公司论坛上。你要给我发个加密文件，拿我的公钥加密后发给我。只有我手里的私钥能解开它。别人即使截获了密文，没有私钥也是白搭。

最经典的算法是 RSA 和 ECC。我个人习惯在需要兼容老旧系统的场景用 RSA，新项目则优先考虑 ECC。

对比维度	对称加密（AES-256）	非对称加密（RSA-2048）
密钥数量	1 个（共享）	2 个（公钥 + 私钥）
性能	极高（~1 GB/s）	较低（~1 MB/s）
密钥分发	困难	容易（公钥公开）
典型用途	数据加密、磁盘加密	数字签名、密钥协商
抗量子攻击	部分受影响	RSA/ECC 均受影响

综合混用：让它们各司其职

既然对称加密快但分发难，非对称加密分发易但慢，那么把它们合在一起不就完美了吗？

这叫混合加密方案。最常见的实现就是 TLS/SSL。

1. 客户端和服务端先通过非对称加密算法（比如 ECDHE）协商出一个临时对称密钥。
2. 这个对称密钥只用于当前会话。
3. 之后所有传输数据都用这个对称密钥进行 AES 加密。

我曾经接手过一个内部会议系统，原来就是纯 RSA 加密每一条消息。延迟高得吓人。后来改成混合加密，握手用 RSA，数据传输用 AES。延迟直接降了一个数量级。

密钥的生命周期管理

有了密钥还不够，还得管理好它们。密钥从生到死，需要经历这么几个阶段：

• 生成：用安全的随机数生成器。
• 存储：私钥不能明文存。使用 HSM、KMS 或 TPM。
• 分发：对称密钥用密钥协商协议；公钥可以通过证书链分发。
• 使用：避免密钥被滥用，设定使用权限。
• 轮换：定期的更换密钥。我习惯设 90 天自动轮换一次。
• 吊销：密钥泄露时的紧急措施。证书吊销列表（CRL）或 OCSP 可以派上用场。
• 销毁：彻底清除密钥，防止恢复。

说到轮换，我记得有一个云存储项目，当初没设密钥自动轮换。结果不小心泄露了密钥，所有历史文件都无法安全保留。从那以后，我无论如何都会加上密钥的定期轮换机制。

对称加密流程解析

下面这张图可以帮助你理解对称加密的整个流程——从明文到密文再到明文，中间涉及加密算法、密钥和初始化向量。

从图中可以看到，对称加密的核心就三个东西：明文、密钥、加密算法。整个过程加起来就是：用同一把密钥把明文进行加密运算，产生密文；再拿同样的密钥对密文做解密运算，还原出明文来。

混合加密的实际案例

最后分享一个我经手的实际案例。我们当时要给一台嵌入式设备做远程固件更新。设备性能差，只有 1MB 内存。硬件上跑不了完整的 TLS。

怎么办？

• 第一步：设备启动时，发送自己的公钥到后台（公钥在出厂时就预置并烧录在设备中）。
• 第二步：服务端接收到公钥后，生成一个临时对称密钥（AES-128）。
• 第三步：服务端用设备的公钥（RSA）加密这个临时对称密钥，发送给设备。
• 第四步：设备用自己的私钥解密，拿到对称密钥。
• 第五步：后续所有固件数据块都用 AES-128 加密传输。

这样做，既省掉了 CPU 大开销的 RSA 解密操作（只做一次），又保证了密钥分发的安全性。设备完美跑起来了，而且每次升级只需要 30 秒。