第1章：对称加密算法在ADAS中的应用

1.1 为什么ADAS需要加密？

说实话，我刚入行做ADAS那会儿，也觉得加密这事儿离我挺远的。那时候想的是——车上的传感器数据，谁没事儿来偷啊？直到有一次，我们做渗透测试，一个同事用CAN总线注入了一个伪造的刹车信号...嗯，车差点撞墙。

从那以后我就明白了。ADAS系统里，传感器数据、控制指令、V2X通信，每一条消息都可能是「生死攸关」的。你想想看，如果攻击者篡改了摄像头的数据，让系统以为前面有障碍物，结果来个急刹车——这可不是闹着玩的。

所以，加密和身份认证，说白了就是给ADAS系统穿上防弹衣。而对称加密算法，就是这件防弹衣的核心材料。

核心观点：ADAS通信中，加密不是为了防「偷看」，而是为了防「篡改」和「伪造」。这是本质区别。

1.2 AES算法原理——我习惯这么讲

AES，高级加密标准。这玩意儿现在几乎是嵌入式加密的标配了。我个人习惯把它理解成一个「多层搅拌机」——数据进去，经过好几轮混乱和扩散，出来就面目全非了。

AES的核心操作其实就四个：

  • SubBytes（字节代换）——用一个S盒把每个字节替换成另一个。有点像查字典，但这个字典是精心设计的。
  • ShiftRows（行移位）——把状态矩阵的行循环移位。说白了就是打乱顺序。
  • MixColumns（列混合）——对每一列做矩阵乘法。这是扩散的关键，让一个字节的变化影响到整列。
  • AddRoundKey（轮密钥加）——把当前数据和轮密钥做异或。密钥就是这时候掺进来的。

我记得第一次在MCU上实现AES时，踩过一个坑——S盒查表用了全局数组，结果放在Flash里，每次查表都要等好几个周期。后来改成查表+预计算，速度才上去。

小技巧：在嵌入式环境里，AES的S盒可以预计算成查找表，但要注意Flash访问速度。如果RAM够用，可以加载到RAM里跑。

AES支持三种密钥长度：128位、192位、256位。在ADAS场景里，我建议用AES-128就够了。为什么？因为128位的安全强度已经足够，而且硬件加速器通常对128位支持最好。256位虽然更安全，但计算开销大，实时性要求高的场景不划算。

3 GCM模式——认证加密，一步到位

光有AES还不够。你想想，如果只加密不认证，攻击者虽然看不懂数据，但可以乱改啊。比如把刹车指令里的「0x00（不刹车）」改成「0xFF（全力刹车）」——加密了又怎样？解密后照样执行。

所以我们需要认证加密。GCM模式（Galois/Counter Mode）就是干这个的。它把加密和认证合二为一，一步到位。

GCM的工作原理，我简单拆解一下：

  1. 计数器模式加密——用AES加密一个递增的计数器，生成密钥流，然后和明文异或得到密文。这步保证机密性。
  2. GMAC认证——用GHASH函数对密文和附加数据做哈希，生成一个认证标签。这步保证完整性。

说白了，GCM就是「加密+签名」的打包服务。你给它明文和密钥，它给你密文和一个认证标签。接收方用同样的密钥验证标签，如果对不上，说明数据被篡改了。

注意：GCM模式有一个致命弱点——nonce（一次性随机数）绝对不能重复使用。我曾经见过一个项目，因为nonce生成逻辑写错了，导致两次通信用了同一个nonce，结果密钥流被还原，整个加密形同虚设。嗯，那哥们后来改了一周的bug。

在ADAS里，GCM的附加数据（AAD）可以用来携带一些不加密但需要认证的信息，比如消息类型、时间戳、发送方ID。这样接收方可以验证「这条消息是不是来自合法的传感器」。

1.4 硬件加速实现——别让加密拖了实时性的后腿

软件实现AES，在普通MCU上大概要几十微秒到几百微秒。听起来不多，但在ADAS里，一条控制指令的延迟要求可能只有几毫秒。如果加密占了十分之一，那就不太妙了。

所以，我强烈建议用硬件加速器。现在主流的车规级MCU，比如Infineon TC3xx、NXP S32K3、Renesas RH850，都内置了AES硬件加速模块。

硬件加速的好处很明显：

  • 速度快——AES-128加密一个块（16字节），硬件只需要几个时钟周期。软件可能要几百个。
  • 不占CPU——加密过程可以DMA传输，CPU该干嘛干嘛。
  • 抗侧信道攻击——硬件实现通常有防护措施，比如功耗均衡、时序恒定。软件实现很容易被时序分析攻击。

下面是一个典型的硬件AES加速器配置流程（伪代码）：

// 初始化AES硬件模块
void aes_hw_init(void) {
    // 1. 使能时钟
    AES->CR |= AES_CR_EN;
    // 2. 配置模式：GCM
    AES->CR |= AES_CR_MODE_GCM;
    // 3. 设置密钥长度：128位
    AES->CR |= AES_CR_KEYSIZE_128;
}

// 执行GCM加密
void aes_gcm_encrypt(uint8_t *plaintext, uint8_t *ciphertext, 
                     uint8_t *key, uint8_t *nonce, uint8_t *aad) {
    // 1. 加载密钥
    AES->KEYR = key;
    // 2. 加载nonce
    AES->IVR = nonce;
    // 3. 写入附加数据（AAD）
    AES->DIN = aad;
    // 4. 写入明文数据
    AES->DIN = plaintext;
    // 5. 等待加密完成
    while(!(AES->SR & AES_SR_CCF));
    // 6. 读取密文
    ciphertext = AES->DOUT;
    // 7. 读取认证标签
    tag = AES->TAGR;
}

经验之谈：用硬件加速器时，别忘了检查DMA传输的字节对齐。很多硬件模块要求数据地址是4字节对齐的，否则会触发总线错误。我因为这个原因debug了整整两天...

1.5 避坑指南——我踩过的那些坑

做ADAS加密，有几个坑我替你们踩过了：

  • nonce管理——前面说了，GCM的nonce不能重复。在ADAS里，可以用时间戳+设备ID组合成nonce，保证唯一性。
  • 密钥存储——密钥不能明文存在Flash里。要用HSM（硬件安全模块）或eFuse存储。我曾经见过一个方案，密钥直接写在代码里...嗯，那叫「掩耳盗铃」。
  • 实时性预算——加密操作要算进任务的执行时间里。别等到系统跑起来才发现加密占了50%的CPU。
  • 认证标签长度——GCM的认证标签可以截断，但别截太短。我建议至少用96位（12字节），否则碰撞概率太高。

总结一下：AES-GCM是ADAS通信加密的黄金组合。硬件加速是必须的，nonce管理是命门，密钥保护是底线。这三条做好了，你的ADAS系统就穿上了一件靠谱的防弹衣。

下一章，我会讲非对称加密在ADAS身份认证中的应用。到时候聊聊ECDSA签名和密钥交换，那又是另一番天地了。

← 上一章 📖 返回目录 下一章 →