📚 课程目录第2章密码学基础回顾

密码学基础回顾：对称加密与非对称加密、哈希函数与数字签名、密钥交换协议

各位同学，欢迎来到第二章。说实话，每次讲密码学基础，我都觉得像是在给车队铺地基。地基不牢，后面什么密钥轮换、HSM 部署全是空中楼阁。今天咱们就把这四块基石——对称加密、非对称加密、哈希函数、密钥交换——掰开揉碎了讲清楚。

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

对称加密，说白了就是加密和解密用同一把密钥。你想想看，车队里两辆 ECU 通信，事先约定好一个密钥，A 用这个密钥加密数据发出去，B 收到后用同样的密钥解密。简单、快，这是它的优点。

但问题也出在这里——密钥怎么安全地分发给对方？我在项目里遇到过，某 OEM 直接把预置密钥写在固件里，结果被逆向工程扒了个精光。嗯，这就是对称加密的命门：密钥分发。

常见的对称加密算法，我列个表，大家对比着看：

算法	密钥长度	分组大小	典型场景
AES	128 / 192 / 256 bit	128 bit	车载总线加密、固件加密
SM4	128 bit	128 bit	国密合规场景
ChaCha20	256 bit	流式	资源受限的 MCU

我的建议：车队场景下，优先选 AES-128 或 AES-256。别为了省那几 KB 的代码空间去用 DES 或 3DES，那些算法已经过时了。我曾经在某个 T-Box 项目里看到还在用 DES，当时就建议客户立刻升级——不是能不能破解的问题，而是合规审计都过不了。

2.2 非对称加密：公钥私钥，各司其职

非对称加密就聪明多了。它有一对密钥：公钥公开，私钥自己藏着。公钥加密的数据只有私钥能解，私钥签名的数据公钥能验。这样一来，密钥分发问题就解决了——你不需要偷偷摸摸传递密钥，直接把公钥扔到网上都行。

但代价是什么？慢。非常慢。RSA 加密 1KB 数据，比 AES 慢几百倍。所以实际工程里，我们从来不用非对称加密去加密大量数据。怎么做？我后面会讲混合加密方案。

车队里最常见的非对称算法：

RSA：2048 bit 起步，用于数字证书、TLS 握手
ECC（椭圆曲线）：256 bit 就能达到 RSA 3072 的安全强度，适合车载芯片
SM2：国密标准，基于 ECC，国内车厂必选

避坑指南：我曾经见过一个项目，在 MCU 上用软件实现 RSA 4096 签名，每次签名耗时 2 秒多。ECU 启动流程直接卡死。后来换成 ECC P-256，签名时间降到 50 毫秒。所以选算法一定要看硬件加速支持，别光看安全强度。

2.3 哈希函数：数据的指纹

哈希函数，你可以把它理解成数据的「指纹」。不管输入多大，输出固定长度。而且只要输入变一点点，输出就面目全非。这个特性在车队里太有用了——固件完整性校验、密码存储、消息认证码，全得靠它。

常见的哈希算法：

SHA-256：输出 256 bit，目前最通用
SHA-3：新一代标准，抗量子攻击潜力更好
SM3：国密哈希，输出 256 bit

这里我要强调一个坑：不要用 MD5 和 SHA-1。MD5 已经被彻底攻破，SHA-1 也在 2017 年被 Google 实现了碰撞攻击。我去年审计一个供应商的 OTA 方案，他们还在用 SHA-1 校验固件签名。我当时就说了，这跟没校验差不多。

  哈希在车队里的典型用途：
  固件完整性校验：刷写前算哈希，跟签名里的哈希对比
密码存储：存哈希值，不存明文密码
HMAC：用密钥+哈希做消息认证，防止数据被篡改

2.4 数字签名：谁签的？改没改？

数字签名 = 哈希 + 非对称加密。先对数据算哈希，再用私钥加密这个哈希。验证时，用公钥解密哈希，再跟数据的哈希对比。两个问题一次解决：身份认证（谁签的）和完整性校验（改没改）。

车队里数字签名无处不在：

ECU 固件签名：防止刷入恶意固件
V2X 消息签名：确保消息来自可信车辆
诊断命令签名：防止非法诊断操作

我记得有一次，客户问能不能用 HMAC 代替数字签名做固件校验。我说不行，HMAC 是对称的，谁有密钥谁就能签名。数字签名是非对称的，私钥只有签名方有，公钥可以公开。这个区别在车队里至关重要——你不可能让每辆车的 ECU 都存同一个对称密钥来做校验，泄露一个就全完了。

2.5 密钥交换协议：Diffie-Hellman

好，前面说了对称加密快但密钥分发难，非对称加密解决了分发问题但慢。那有没有办法让双方在不安全的信道上安全地协商出一个对称密钥？有，Diffie-Hellman 密钥交换协议（简称 DH）。

DH 的原理，我用一个简化版来说明：

双方公开约定一个大素数 p 和一个生成元 g
Alice 选一个随机数 a，计算 A = g^a mod p，发给 Bob
Bob 选一个随机数 b，计算 B = g^b mod p，发给 Alice
Alice 计算 K = B^a mod p
Bob 计算 K = A^b mod p
两人得到相同的 K，这就是共享密钥

为什么安全？因为攻击者只能看到 p、g、A、B，但无法从 A 反推出 a（离散对数问题）。说白了，就是数学上算不出来。

实战经验：DH 协议本身不提供身份认证，容易遭受中间人攻击。我在做 T-Box 和云端密钥协商时，用的是 ECDHE——基于椭圆曲线的 DH 加上证书认证。这样既保证了前向安全性，又防了中间人。前向安全性什么意思？就是即使长期私钥泄露，之前协商的会话密钥也不会被破解。这个特性在车队里特别重要，因为车辆生命周期长达 10 年。

下面这张图展示了 DH 密钥交换的核心流程：

2.6 混合加密：取长补短

讲到这里，你应该能看出来，没有一种加密方案是万能的。实际工程里怎么做？混合加密。

流程很简单：

用 DH 或 ECDHE 协商出一个临时对称密钥（会话密钥）
用这个对称密钥加密实际数据（AES 或 SM4）
会话用完就销毁，下次重新协商

这样做的好处：非对称加密解决了密钥分发问题，对称加密保证了加解密速度，临时密钥保证了前向安全性。我在设计车云通信协议时，用的就是这套方案——ECDHE 握手 + AES-GCM 加密。GCM 模式还带了认证，能同时检测数据是否被篡改，一举两得。

  本章核心要点：
  对称加密：快，但密钥分发难。车队里用 AES-128/256
非对称加密：解决了分发问题，但慢。车队里用 ECC 或 SM2
哈希函数：数据指纹，用于完整性校验。别用 MD5/SHA-1
数字签名：哈希 + 非对称，解决身份认证和完整性
DH 协议：在不安全信道上安全协商密钥。实战用 ECDHE
混合加密：取长补短，车队通信的标准做法

这些基础概念，后面每一章都会用到。尤其是密钥生命周期管理、HSM 使用、安全启动这些实战内容，全都建立在这四块基石之上。建议大家把这张图存下来，后面忘了随时回来看。