AUTOSAR E2E + SecOC 通信安全（CAN E2E and SecOC）

选择看总线类型 + 消息长度 + ASIL 等级三个维度:总线决定带宽预算(CAN classic 8 字节紧、CAN-FD 64 字节宽、Ethernet 几乎不限),消息定长还是变长决定要不要 Length 字段(P05 vs P06、P04 的 4 KB vs P44 的 64 KB),ASIL 等级决定 CRC 强度与 Counter 宽度的下限。

CAN-FD 上的 ASIL D 定长消息默认 P05:16-bit CRC + 8-bit Counter,DataID 隐式不占线上字节,每帧只花 3 字节(隐式/显式 DataID 的机制与取舍见 §5)。CAN classic 新项目选 P11 而非 P01——两者线上布局兼容,但 P11 的接收端行为对齐 P04-P07 系的"新式" check 语义,且砍掉了 P01 已废弃的 DATAID_LOW/ALT 模式。

E2E 各 Profile 用的 CRC 例程全部来自 AUTOSAR CRC Library(CP SWS CRC Routines),多项式是有出处的选型而不是随手挑的:

三个值得记住的细节:

• 0x2F 就是 Koopman 记法的 0x97——Koopman & Chakravarty 2004 的结论是它在 ≤ 119 bit 数据上做到 HD=4 的最优 8-bit 多项式,完整覆盖 8 字节 CAN 帧(64 bit)。
• 0xF4ACFB13(CRC-32P4)是专门为 E2E P04 选的:CRC Library 规范(SWS_Crc_00083)明写它对比 Ethernet CRC(0x04C11DB7)的优势是"HD=6 up to 4 kB"——这正好是 P04 的 MaxDataLength 上限(4096 字节),多项式与 Profile 数据上限是配套设计的。
• P01 的 CRC-8 用 start=XOR=0x00,而 CRC Library 的 SAE8 例程用 0xFF/0xFF——E2E 库内部做两次额外 XOR 0xFF 来补偿。这是刻意的:让 E2E CRC 与链路层/其他用户的同多项式 CRC 结果不同,避免"两层 CRC 恰好都算对了错误数据"的共因。

HD=N 的含义:任意 N-1 个 bit 翻转 100% 检出。超出 HD 覆盖后,随机错误漏检概率趋近 $2^{-k}$(k 为 CRC 位宽)——16-bit CRC 约 $1.5\times 10^{-5}$,这个残余概率会进 FMEDA 的通信 fault DC 论证。

CRC 只对数据内容的随机损坏有效,三类 fault 它天然放过:重放(旧帧的 CRC 依然自洽)、错发(错误发送端把格式算对)、系统性同位错(每帧同一 bit 错,CRC 每次都"验证通过"错的数据)。前两类靠 Counter 和 DataID 兜(§4/§5),最后一类靠应用层 plausibility(如扭矩指令与车速的合理性交叉核验,见 转矩安全)。

不同 Profile 的 DataID 处理方式不同,这决定带宽开销与故障表现:

旧口径"ASIL D 一律显式"不成立——P05 的隐式 DataID 正是 CAN-FD ASIL D 的主流配置,安全强度上两者等价(都进 CRC,masquerade 检出率相同)。真正的差别在工程性:

• 隐式省带宽但故障表现隐蔽:两端 DataID 配置不一致(信号数据库版本漂移、ECU 升级后 ID 重分配)时,不会有"DataID mismatch"这种明确报错,而是 100% CRC fail——现象和总线损坏一模一样,排障时容易往硬件方向跑偏(见 §10 G2)。
• 显式占 4 字节但 debug 友好:总线 trace 里直接可读,Ethernet 带宽也不心疼,所以 P04/P07/P08/P44 全是显式。

发送路径六步(SWS_SecOC_00031):准备缓冲 → 构造认证输入 → 算 Authenticator → 拼 Secured I-PDU → Freshness 计数递增 → 发送。其中两步是理解 SecOC 的关键:

• 认证输入 DataToAuthenticator = SecOC DataId(16-bit)‖ Authentic I-PDU ‖ 完整 Freshness Value(SWS_SecOC_00034,DataId 与 FV 按 Big Endian 编码)。注意进 MAC 的是完整 FV(如 64-bit),不是线上截断值——这是防重放强度的来源。
• 截断(SWS_SecOC_00036):算出的 MAC(如 CMAC 的 128-bit 输出)截取最高若干位随帧传输。截断不削弱密钥安全性,只把"单帧盲猜成功率"从 $2^{-128}$ 放宽到 $2^{-n}$(n 为截断位数,见 §11 C2 的数字)。

算法与截断长度不是自由发挥,规范给了三个标准配置(SWS_SecOC_00192/00193/00194),MAC 算法统一是 AES-128 CMAC(NIST SP 800-38B)——不是 HMAC-SHA-256;车规选 CMAC 是因为 HSM 的 AES 硬件引擎可以直接复用,单帧延迟和面积都占优:

MAC 本身是成熟密码学,SecOC 项目翻车几乎都翻在 freshness 同步上。规范采纳的 JASPAR 方案把 64-bit FV 拆成四段拼接:Trip Counter(点火周期计数,≤ 24 bit)‖ Reset Counter(周期性递增,≤ 24 bit)‖ Message Counter(每帧 +1,≤ 48 bit)‖ Reset Flag(≤ 2 bit,取 Reset Counter 低位),四段总长 ≤ 64 bit。FV 管理由 Freshness Value Manager(FvM)承担,master ECU 通过同步消息广播 TripCnt/ResetCnt,各节点本地维护 MsgCnt。

线上只传 FV 的低几位(Profile 1 是 8 bit),接收端用本地计数器重建完整 FV:取"比本地值大的最小候选"代入 MAC 验证,失败则在 SecOCAuthenticationVerifyAttempts 配置的次数内尝试相邻候选——验证失败递增的 verify attempt counter 正是 SecOC_GetRxFreshness 的入参,FvM 据它给出下一个 FV 候选,达上限才丢帧(SWS_SecOC_00239/00241);SecOCAuthenticationBuildAttempts 管的是 freshness 查询、CSM 返回 E_BUSY 这类可恢复错误的重建重试,两个参数配混,FV 失步容忍行为就偏离设计预期。这个设计的隐含约束:接收端失步超过截断窗口(8 bit → 256 帧)就再也重建不出正确 FV,合法帧全部验证失败,必须靠同步消息恢复(§10 G5)。

SecOC 自己不碰密钥,MAC 计算逐层下沉:

ASIL/CAL 项目的密钥纪律:per-vehicle(至少 per-ECU-pair)密钥,产线 EOL 经安全通道注入 HSM 密钥槽(Infineon AURIX HSM、NXP S32K3 HSE,均 EVITA Full 级)。反面教材是 Toyota RAV4 Prime 的 SecOC 密钥提取(icanhack.nl 公开分析,详见 ISO/SAE 21434 深度):key provisioning 实施缺陷让攻击者从量产 ECU 拿到了密钥——SecOC 的强度上限永远是密钥管理,不是 MAC 位数。

E2E 看 ASIL,SecOC 看攻击面(TARA 结论,ISO/SAE 21434 风险评估 + UN R155 威胁目录):

场景:VCU 每 10 ms 向主驱逆变器发扭矩指令。Safety Goal 为"避免意外扭矩"(ASIL D),整车 FTTI 50-100 ms(与 转矩安全 口径一致),本例给通信链分配 tFD + 反应 ≤ 100 ms。TARA 判定该消息经蜂窝-网关路径可达,SecOC 必配。平台:两端 MCU 均为 Infineon AURIX TC397(HSM 为 EVITA Full 级,AES-128 硬件引擎),CAN-FD 仲裁段 500 kbit/s、数据段 2 Mbit/s。

E2E 选 P05(定长消息、3 字节开销),SecOC 选 Profile 1(24-bit CMAC + 8-bit 截断 FV,4 字节开销),应用数据 8 字节,合计 15 字节,取 CAN-FD DLC=16:

CAN-FD frame, DLC = 16, ID 0x105 (示例)
  [0..1]   E2E CRC-16 (0x1021, 小端, 覆盖 payload + 隐式 DataID 0x0C05)
  [2]      E2E Counter (8-bit, 每帧 +1, 0xFF 后绕回)
  [3..4]   TorqueReq   (int16, 0.1 Nm/LSB → ±3276 Nm 量程)
  [5..6]   TorqueGradLimit (int16, 0.1 Nm/ms/LSB)
  [7]      DriveMode + 状态位
  [8..10]  应用保留
  [11]     SecOC truncated FV  (64-bit FV 的低 8 bit)
  [12..14] SecOC truncated MAC (AES-128 CMAC 的高 24 bit)
  [15]     pad

发送端顺序: E2E_P05Protect() → SecOC (CMAC over DataId|bytes[0..10]|FV64) → CanIf
接收端顺序: SecOC 验证(重建 FV, 失败丢帧) → E2E_P05Check() → E2E_SM → 应用

单帧线上时间估算:仲裁段约 30 bit @ 500 kbit/s = 60 μs,数据段(16 字节数据 + CRC 场 + 控制位,含填充)约 160 bit @ 2 Mbit/s = 80 μs,ACK/EOF 约 30 μs——合计 ≈ 170 μs,100 Hz 下占总线 ≈ 1.7%。对比:同样的保护若留在 CAN classic(8 字节),E2E+SecOC 的 7 字节开销只给应用剩 1 字节,这条消息根本装不下——见 §11 C1。

E2E 配置:DataID = 0x0C05(隐式),MaxDeltaCounter = 2(容忍单帧丢失);E2E_SM 配置 WindowSizeValid = 10、MinOkStateValid = 7、MaxErrorStateValid = 2。套 §6 的规范公式:

发送端停发(NONEWDATA 路径)的检出由同一窗口覆盖,但走的是另一条转移条件:NONEWDATA 不计入 E2E_SM 的错误计数——PRS_E2E_00466 规定 ErrorCount 只统计 ERROR、OkCount 只统计 OK,其余状态两边都不进。10 ms 周期任务连续读不到新数据时,是窗口里的 OK 帧被 NONEWDATA 挤出、OkCount 跌破 MinOkStateValid 才触发 INVALID:本配置下需 WindowSizeValid − MinOkStateValid + 1 = 4 帧 NONEWDATA(规范时长口径 (10 − 7 + 1) × 10 ms = 40 ms)。所以控制 timeout 检出延迟的参数是 MinOkStateValid 而非 MaxErrorStateValid——想压缩停发检出时间去调 MaxErrorStateValid 是无效的。不需要单独的 timeout 定时器,但周期任务必须无条件调 check(§10 G4)。

FV 64-bit 按 JASPAR 四段划分(一种典型配置,各段长度项目可调):TripCnt 16 bit ‖ ResetCnt 22 bit ‖ MsgCnt 24 bit ‖ ResetFlag 2 bit。截断 FV 8 bit 意味着接收端可容忍 < 256 帧的失步窗口(2.56 s @ 100 Hz),超出必须等 FvM 同步消息(TripCnt/ResetCnt 广播,典型 1 s 周期)恢复;SecOCAuthenticationVerifyAttempts = 2,验证失败帧丢弃并向 IdsM 上报计数。密钥:per-vehicle 128-bit,EOL 注入 TC397 HSM 密钥槽,诊断读不出、软件摸不到。

十类 fault 每类都要有注入用例(restbus 仿真,如 CANoe 故障注入):篡改 payload 单 bit(corruption)、重发旧帧(repetition/replay)、按周期删帧(loss)、换 ID 发同格式帧(masquerade)、Counter 跳变(sequence)、停发(blocking)。验收判据统一:每类 fault 被检出 + 逆变器进入降扭/安全态的总时间 < 100 ms,并留 trace 作为 safety case 的验证证据(ISO 26262-4/-6 验证条款对接)。