3.6 CRC与密码学完整性——消息的基因指纹

你是一辆电动汽车的动力域主控，面前摆着一个严峻的问题：你刚刚通过CAN总线下发了一个256字节的BMS（电池管理系统）固件升级块给电池包MCU。这256字节中包含了对过充保护阈值（4.25V→4.20V）的关键修改，如果这个值在传输中发生变化，电池包可能在下次快充时直接热失控。

电池包MCU收到数据后，需要验证这段数据是否完整。它能做的第一件事是：计算一个校验和（Checksum）。最简单的算法：把所有256个字节加起来，对256取模，把结果附在数据末尾一起发送。接收方重新计算，如果一致就认为数据完整。

这个方案有一个致命缺陷。考虑以下两个70字节的数据块：

数据块A: [0x12, 0x34, 0x56, ..., 0x78] → 所有字节和 = 0x5A40 → 模256 = 0x40
数据块B: [0x34, 0x12, 0x56, ..., 0x78] → 所有字节和 = 0x5A40 → 模256 = 0x40

前两个字节交换了位置，但简单校验和完全无法检测，因为加法是可交换的。更糟糕的是：任意两个字节同时翻转，只要它们的和不变（例如0x12→0x13和0x34→0x33），校验和也检测不到。

你把目光投向ISO 26262-6:2018 Annex D中推荐的校验方法：CRC。CRC不是将字节相加，而是将整个消息视为一个巨型二进制多项式，除以一个精心挑选的“生成多项式“，取余数作为校验值。这个余数对数据模式高度敏感，翻转一个比特、交换两个字节、增加一个零字节，都会产生完全不同的余数。

CRC与普通校验和的本质区别在于：校验和是可加的线性运算（sum(A+B) = sum(A) + sum(B)），CRC是多项式除法（CRC(A+B) ≠ CRC(A) + CRC(B)）。线性运算意味着错误模式可能与运算空间正交而检测不到，多项式除法的非线性保证了错误模式的均匀分布。

GF(2)上的多项式运算：CRC的数学基础

理解CRC，需要进入伽罗瓦域GF(2)的世界。在GF(2)中：

• 加法是异或（XOR）：1+1=0, 1+0=1, 0+0=0
• 乘法是逻辑与（AND）：1×1=1, 1×0=0, 0×0=0
• 减法等于加法：a-b = a+b（因为每个元素是自己的加法逆元）

一个二进制序列可以表示为GF(2)上的多项式。例如，10110011 对应多项式：

x⁷ + x⁵ + x⁴ + x¹ + x⁰

CRC计算的过程是：将消息多项式M(x)左移n位（n是CRC的位数），然后除以生成多项式G(x)，取余数R(x)。这个R(x)就是CRC值。

M(x) × xⁿ ÷ G(x) → 商Q(x) + 余数R(x)
CRC = R(x)

在接收方，将收到的消息多项式（M’(x) = M(x) × xⁿ + R(x)）除以同样的G(x)。如果传输无错，余数应该为零，因为M(x) × xⁿ + R(x)在加法（XOR）意义上等于Q(x) × G(x) + R(x) + R(x) = Q(x) × G(x)，恰好能被G(x)整除。

如果传输中发生错误E(x)（错误多项式），收到的多项式变为：

M'(x) + E(x) = Q(x) × G(x) + R(x) + E(x) + R(x) = Q(x) × G(x) + E(x)

除以G(x)后的余数就是E(x) mod G(x)。如果E(x)恰好是G(x)的倍数，CRC漏检。这就是为什么G(x)的选择如此重要。

CRC的本质是将无限多的错误模式映射到有限多的CRC值上。CRC-N只有2ᴺ种可能的CRC值，但错误模式有无穷多种。漏检在数学上是不可避免的：CRC的设计目标不是“绝不漏检“，而是让漏检的概率在所有实际可能发生的错误模式上均匀分布，且概率足够低。

AUTOSAR的四种CRC多项式

AUTOSAR规范（SWS_Crc）定义了四种CRC多项式，每一种都是为了不同的硬件约束和错误检测需求而精选的：

CRC8 — SAE J1850（0x1D）

多项式：x⁸ + x⁴ + x³ + x² + 1

8位CRC，计算速度快（查表法只需一次256字节表的索引），适合对字节或短消息（<16字节）进行校验。汉明距离为4（对于消息长度≤119位），意味着能检测所有1位、2位、3位错误。

CRC8在AUTOSAR中的典型应用：

• E2E Profile 1/2的消息校验
• I2C通信的地址和数据校验
• SBC（系统基础芯片）的SPI通信校验

CRC8H2F（0x2F）

多项式：x⁸ + x⁵ + x³ + x² + x + 1

虽然也是8位CRC，但使用不同的多项式，使得它与CRC8(0x1D)没有相同的“漏洞“，两者都在同一消息上的漏检概率乘积为1/65536，极大地降低了两个CRC同时漏检的概率。这在安全架构中，当一个消息同时受两层CRC保护时很有用（例如CAN帧CRC + E2E CRC）。

CRC16 — CCITT（0x1021）

多项式：x¹⁶ + x¹² + x⁵ + 1

16位CRC，是汽车行业使用最广泛的校验算法。汉明距离为4（对于消息长度≤2048位），能检测：

• 所有奇数个比特错误
• 所有1位和2位错误
• 所有长度≤16的突发错误（99.9984%概率检测长度≥17的突发错误）
• 所有长度为17的突发错误的99.9969%

CRC16在AUTOSAR中用于E2E Profile 5和6，保护大多数ASIL B/C级别的控制指令。

CRC32 — IEEE 802.3（0x04C11DB7）

多项式：x³² + x²⁶ + x²³ + x²² + x¹⁶ + x¹² + x¹¹ + x¹⁰ + x⁸ + x⁷ + x⁵ + x⁴ + x² + x¹ + 1

这是以太网、gzip、PNG等协议使用的标准CRC32。汉明距离为4（对于消息长度≤91639位，几乎是11.5KB）。未检测率约1/2³² ≈ 2.3 × 10⁻¹⁰。

CRC32P4 — AUTOSAR Profile 4（0xF4ACFB13）

多项式：x³² + x³¹ + x³⁰ + x²⁹ + x²⁷ + x²⁵ + x²³ + x²² + x²⁰ + x¹⁹ + x¹⁷ + x¹⁶ + x¹⁴ + x¹³ + x¹² + x¹⁰ + x⁹ + x⁸ + x⁵ + x⁴ + x² + x¹ + 1

这是AUTOSAR特有的多项式，与标准CRC32不同。为什么不用标准的0x04C11DB7？因为标准CRC32为以太网设计，以太网的错误模式（突发噪声、碰撞碎片）与CAN总线完全不同。CAN总线的典型错误是脉冲噪声和比特填充错误，而非长突发错误。AUTOSAR委员会经过大量仿真验证，选出了对CAN特定错误模式检测效果最优的这个多项式。

CRC32P4的汉明距离至少为6（对于长度≤268位），这意味着它能100%检测任意5位错误，为ASIL D级别的安全关键控制指令提供了坚实的数学基础。

多项式的质量由三个指标衡量：汉明距离（对任意≤k位错误的100%检测能力）、突发错误保护长度（能100%检测的连续错误位最大长度）、对特定通信介质错误模式的检测率。0xF4ACFB13被选为P04的多项式，不是因为“更大“或“更复杂“，而是因为它对CAN总线故障模式的检测性能在65536个候选32位多项式中排第一。

查表法 vs 运行时计算：速度与空间的较量

CRC的数学定义是优雅的：逐位多项式除法。但在实际的嵌入式实现中（Cortex-M/R、TriCore、RH850），逐位计算太慢了。

一个256字节的消息用逐位法计算CRC32需要 256 × 8 = 2048次迭代，每次迭代包括一次条件判断、两次XOR和一次移位。在200MHz的Cortex-R5上，大约需要50微秒。对于10ms周期的EPS控制循环，50微秒仅占0.5%，似乎可以接受。但考虑到一个ECU上可能有几十条安全消息需要保护，累积开销可能达到毫秒级。

查表法将CRC计算加速了近一个数量级。原理是预先计算所有256个字节值对应的CRC中间结果（256 × 4字节 = 1KB表）。每次计算时，用当前CRC的高字节作为索引查表，三个XOR操作后即完成一个字节的处理。

/* CRC32查表法的核心循环 */
uint32 Crc_CalculateCRC32(const uint8 *data, uint32 length, uint32 startValue, boolean isFinal) {
    uint32 crc = startValue;
    for (uint32 i = 0; i < length; i++) {
        crc = (crc >> 8) ^ crc32_table[(crc ^ data[i]) & 0xFF];
    }
    if (isFinal) {
        crc ^= 0xFFFFFFFF;  /* 最终XOR */
    }
    return crc;
}

AUTOSAR的Crc模块（SWS_Crc）要求至少支持运行时计算（对所有多项式）和查表加速（建议但非强制）。

硬件CRC引擎：硅基免疫细胞

现代汽车MCU已经将CRC计算下沉到硬件中。以下是主流平台的硬件CRC能力：

NXP SPC58x (PowerPC e200z4)：

• 专用CRC计算单元（CCU）
• 支持CRC8、CRC16、CRC32、CRC32P4
• 计算速度：1字节/时钟周期（在80MHz下为80MB/s）
• 支持DMA链接触发，可以在数据到达时自动启动CRC计算

Infineon AURIX TC3xx (TriCore)：

• CRC外设（CRC）
• 支持多种多项式配置（包括自定义多项式）
• 与DMA模块深度集成
• 特殊模式：内存CRC扫描（后台自动校验Flash完整性）

Renesas RH850：

• 数据CRC计算器（DCC）
• 支持8/16/32位CRC
• 硬件支持比特反转和字节反转（适配不同字节序）

使用硬件CRC引擎时，一个256字节块的CRC32计算可以降到256个时钟周期（加上配置和启动开销，总共约3微秒），比软件查表法快约3倍，比逐位法快约16倍。

CRC的检测能力量化

CRC不是魔法，它的检测能力有严格的数学上限。以CRC16（0x1021）为例：

“100%检测所有奇数个位错误“的证明很简单：如果G(x)包含(x+1)因子，那么任何奇数项错误多项式都能被(x+1)整除。0x1021 = x¹⁶ + x¹² + x⁵ + 1 包含(x+1)因子（验证方法：将x=1代入多项式，结果为0则包含该因子），所以CRC16能检测所有奇数个位错误。

“100%检测所有长度≤16的突发错误“的证明：任何一个长度k≤16的突发错误可以表示为多项式E(x) = xⁱ × (xᵏ⁻¹ + … + 1)，其中i是突发起始位置。E(x)能被16次多项式整除，当且仅当xᵏ⁻¹ + … + 1能被16次多项式整除。但16次多项式不可能整除一个次数小于16的多项式。因此E(x) mod G(x) ≠ 0。

CRC vs 密码学哈希：为什么不是SHA-256

你可能会问：既然SHA-256提供了2¹²⁸的碰撞抗性，为什么不直接用SHA-256代替CRC32P4？

答案是三个字：实时性、资源、确定性。

在CAN通信中（500kbps），一个8字节的CAN帧传输需要约200微秒。如果接收方需要50微秒来计算SHA-256（即便使用硬件加速），那软件栈的延迟就增加了25%。对于10ms周期的EPS控制，这个开销累积起来可能导致控制环路抖动。

更重要的是，嵌入式系统的Flash和RAM是稀缺资源。SHA-256的软件实现需要约2KB代码和256字节工作内存。而CRC16只需约50字节代码（或1KB查表，但表可以放在ROM中）。

最关键的区别在于确定性。CRC是确定性的多项式运算，给定相同的输入和初始值，输出永远相同（跨编译器、跨平台、跨字节序都一致）。SHA-256在理论上是确定性的，但在不同平台上实现时需要仔细处理字节序和填充规范，否则会出现“同一个数据，不同平台算出不同哈希值“的噩梦场景。

免疫系统隐喻：基因指纹

每一个生物个体都拥有独一无二的DNA序列。DNA指纹技术（PCR扩增+电泳）可以在百万个样本中精确识别出一个特定个体的DNA。DNA上特定区域的短串联重复序列（STR）就是天然的“生物CRC“，它在复制过程中任何微小的变化（一个重复单元的增减）都会完全改变指纹图谱。

CRC充当的是消息的“基因指纹“，不是消息本身，而是一个从消息基因中提取出来的、高度敏感的、独一无二的短序列。一旦消息“基因“中的任何一个碱基对（比特）发生突变，指纹图谱就会完全改变。

AUTOSAR的四条CRC多项式就像四种不同的DNA指纹探针：CRC8覆盖短序列的粗粒度识别，CRC32P4提供超精细的个体鉴定。在免疫系统中，MHC分子的多态性（HLA-A、HLA-B、HLA-C）提供了不同粒度的抗原识别能力，CRC多项式的多样性提供了完全一致的分层保护。

CRC是在伽罗瓦域GF(2)上的多项式除法，从CRC8的1/256漏检率到CRC32P4的1/42亿漏检率，提供了从ASIL A到ASIL D的完整检测能力链路。选择CRC不是“越安全越好“，要与故障后果严格匹配。

硬件CRC引擎让CRC计算从软件负担变成了硬件特性，一个256字节块的CRC32计算可以降到3微秒。

本篇小结

1. CRC的本质是在伽罗瓦域GF(2)上的多项式除法，将消息多项式除以生成多项式取余数；与普通校验和（加法可交换）不同，CRC对数据模式高度敏感。
2. AUTOSAR定义了五种CRC多项式：CRC8(0x1D)用于E2E P01、CRC8H2F(0x2F)用于双重校验避免共用漏洞、CRC16(0x1021)用于P05/P06、CRC32(0x04C11DB7)为以太网标准、CRC32P4(0xF4ACFB13)专为CAN总线脉冲噪声优化。
3. CRC32P4在65536个候选多项式中对CAN总线故障模式的检测率排第一，汉明距离≥6（100%检测任意5位错误），是ASIL D转向/制动的数学基石。
4. 硬件CRC引擎可将256字节CRC32计算降至3微秒，比软件查表法快约3倍、比逐位法快约16倍，现代汽车MCU均已集成。
5. SHA-256在嵌入式实时系统中不适合替代CRC：2KB代码体积、10MB/s软件速度、字节序兼容性问题，在10ms控制环中不可接受。

【下集预告】： CRC保证了消息在路上的完整性，但有一个更隐蔽的威胁它完全看不见：程序本身的执行路径是否正确。一个栈溢出把返回地址改成了OutputCommand的入口，CPU跳过了限幅计算，电机收到未经处理的扭矩指令——CRC检查全部通过，因为数据本身没有被破坏，是CPU算错了该算的东西。程序流监控用Checkpoint和转移表定义了一条“只允许这么走“的执行路径，任何偏离都在WdgM的非法转移表中被捕获。但你能想象一个带循环和分支的制动算法要在转移表里画出所有合法路径有多复杂吗？