第一章：密码学基础——对称加密与非对称加密、哈希函数与数字签名、密钥管理基础概念
各位同学，大家好。我是你们这堂课的主讲人。咱们今天聊的，是ADAS系统安全里最底层的砖瓦——密码学基础。
说实话，很多做嵌入式开发的兄弟，一听到“密码学”三个字就头大。觉得那是数学博士干的事。我当年也这么想。直到有一次，我在一个T-Box项目里，因为密钥硬编码被白帽子直接拿下了root权限……嗯，从那以后，我再也不敢小看这些基础概念了。
今天这堂课，我不跟你扯那些复杂的数论公式。咱们就聊聊，在ADAS这种实时性要求极高、算力又受限的嵌入式环境里，到底该怎么选加密算法，怎么管好密钥。
1.1 对称加密：又快又稳，但有个致命弱点
对称加密，说白了就是“一把钥匙开一把锁”。加密和解密，用的是同一个密钥。
你想想看，这多方便。在ADAS的CAN FD总线或者以太网通信里，如果我们要加密一条“前方障碍物距离5米”的报文，用对称加密，几微秒就搞定了。
常见的对称加密算法：
| 算法 | 密钥长度 | 特点 | ADAS适用场景 |
|---|---|---|---|
| AES | 128/192/256位 | 硬件加速支持好，速度快 | 传感器数据加密、固件加密 |
| SM4 | 128位 | 国密标准，国内车厂必用 | 国内ADAS法规合规场景 |
| ChaCha20 | 256位 | 软件实现效率高，无硬件加速也快 | 低算力MCU上的轻量加密 |
核心要点：在ADAS系统里，我个人习惯首选AES-128。为什么？因为大多数车规级芯片（比如NXP的S32K系列、Infineon的TC3xx系列）都内置了AES硬件加速模块。你用AES-128加密一条64字节的报文，硬件算下来也就几十个时钟周期。这在毫秒级响应的ADAS里，太关键了。
但对称加密有个致命弱点——密钥分发。你想想，如果每辆车的每个ECU都要共享同一个密钥，那一旦有一台车被破解，整个车队都完蛋。我在一个V2X项目里就遇到过这个问题，后来不得不引入密钥协商机制。
1.2 非对称加密：安全但慢，用在刀刃上
非对称加密，就是“公钥加密，私钥解密”。公钥随便发，私钥自己藏。
这玩意儿在ADAS里，主要用来做两件事：身份认证和密钥协商。你想想，如果一辆车要跟路侧单元（RSU）通信，总得先确认对方不是冒牌货吧？这时候非对称加密就派上用场了。
常见的非对称加密算法：
- RSA：老牌算法，但密钥太长（2048位起步），在嵌入式里算起来太慢。我建议只在OTA升级签名这种非实时场景用。
- ECC（椭圆曲线）：256位的ECC，安全强度相当于3072位的RSA。而且计算量小很多。ADAS里做身份认证，我强烈推荐ECC。
- SM2：国密椭圆曲线算法。国内主机厂现在都在推，如果你做的是面向国内市场的ADAS，这个绕不开。
我的经验：在ADAS的V2X通信里，我一般这样搭配——用ECC做握手阶段的身份认证，然后协商出一个临时的AES会话密钥。后续的实时数据，全部用AES加密。这样既保证了安全性，又兼顾了实时性。说白了，就是“非对称用来握手，对称用来干活”。
1.3 哈希函数与数字签名：防篡改的利器
哈希函数，就是把任意长度的数据，压缩成固定长度的“指纹”。这个指纹，理论上不可逆。
在ADAS里，哈希函数最常见的用途有两个：完整性校验和数字签名。
你想想，如果攻击者在CAN总线上篡改了一条“刹车距离”的报文，你怎么发现？很简单，发送方在报文末尾附上哈希值。接收方收到后，自己算一遍哈希。对不上？说明报文被篡改了。
常用的哈希算法：
| 算法 | 输出长度 | 安全性 | ADAS适用场景 |
|---|---|---|---|
| SHA-256 | 256位 | 高，目前无有效碰撞攻击 | 固件完整性校验、数字签名 |
| SM3 | 256位 | 国密标准，安全性等同SHA-256 | 国内法规合规场景 |
| BLAKE2 | 可变 | 比SHA-256更快 | 资源受限的MCU上做哈希校验 |
数字签名，就是哈希函数+非对称加密的组合。发送方用自己的私钥对哈希值加密，接收方用发送方的公钥解密验证。这样既能保证数据没被篡改，又能确认发送方的身份。
避坑指南：我曾经在一个ADAS项目中，看到有人直接用MD5做固件完整性校验。MD5已经被证明存在碰撞攻击，攻击者完全可以构造出两个不同固件但MD5值相同的文件。嗯，这要是用在ADAS的固件升级上，后果不堪设想。所以，我建议至少用SHA-256起步。
1.4 密钥管理：整个安全体系的命门
说实话，算法选得再好，密钥管不好，一切都是白搭。密钥管理，是ADAS系统安全里最容易被忽视、也最容易出问题的一环。
密钥管理的几个核心原则：
- 密钥分层：不要所有场景用同一个密钥。我一般分三层——根密钥（存储在HSM里）、设备密钥（每个ECU唯一）、会话密钥（每次通信临时生成）。
- 安全存储：密钥必须放在硬件安全模块（HSM）或安全元件（SE）里。绝对不能明文存在Flash里。我曾经见过一个项目，密钥直接写在代码的全局变量里……嗯，那基本等于没设防。
- 密钥生命周期管理：从生成、分发、使用、更新到销毁，每个环节都要有记录。特别是在ADAS的OTA升级场景里，密钥更新机制必须设计好。
- 密钥协商：在V2X通信中，不要预置长期密钥。用ECDH（椭圆曲线Diffie-Hellman）协议，每次通信前协商一个临时会话密钥。这样即使某次通信被破解，也不会影响其他通信。
我的建议：在ADAS系统设计初期，就要把密钥管理方案写进架构文档里。不要等到开发完了再补安全。我见过太多项目，因为前期没考虑密钥管理，后期不得不打补丁，结果补丁越打越乱，反而引入了更多漏洞。
1.5 小结：在ADAS里怎么选？
好了，咱们今天把对称加密、非对称加密、哈希函数、数字签名和密钥管理都过了一遍。你可能会问：这么多东西，在ADAS里到底怎么选？
我个人习惯，给你一个简单的决策思路：
- 实时数据加密：用AES-128（硬件加速）或ChaCha20（无硬件加速）
- 身份认证：用ECC（256位）或SM2
- 完整性校验：用SHA-256或SM3
- 数字签名：用ECC+SHA-256
- 密钥存储：必须用HSM
- 密钥协商：用ECDH
记住，没有银弹。每种算法都有它的适用场景。关键是要理解它们的优缺点，然后根据ADAS系统的实时性、算力、功耗和法规要求，做出合理的选择。
下一章，咱们会深入聊聊ADAS系统里具体的通信协议安全设计。到时候，这些密码学基础就会派上大用场了。