ISO/SAE 21434 — 汽车网络安全工程

识别什么有价值:

• ECU 内的固件 / 标定数据
• 加密密钥 / 证书
• CAN bus / Ethernet 数据流
• OTA 通道
• 诊断接口(OBD-II / DoIP)
• 用户隐私数据(GPS / 行为)

每个 asset 关联攻击场景。常用 STRIDE 框架:

威胁实现后果分级:

• Severe:致命 / 重伤 / 大规模隐私泄露
• Major:操作障碍 / 财产损失
• Moderate:不便 / 小影响
• Negligible:几乎无影响

攻击难度(常用 CVSS 或自定义):

• High:工具简单 / 远程 / 不需特殊知识(OBD-II 物理接入但工具廉价)
• Medium:需工具 + 中等技能
• Low:需 OEM 内部知识 + 特殊设备
• Very Low:需大量资源 + 长期渗透

Risk = Impact × Feasibility,得到 Cybersecurity Goal(类比 Safety Goal)+ 风险可接受性判断。注意:CAL 等级不由此式导出 —— CAL 由 Impact × Attack Vector 在概念阶段冻结(Annex E,见 §8.5 与 §9 G1);Risk Value = Impact × Feasibility 只用于判断风险是否可接受,不直接产生 CAL(类比 ASIL,但赋值维度不同)。

UNECE 2021 通过,2024-07 起欧盟新车型 type approval 强制。要求 OEM 证明:

• 整个 vehicle lifecycle 有 cybersecurity 管理流程(类比 26262 Part 2 安全文化)
• 7 类 threat 清单(攻击通过 backend / 通信 / 升级 / 用户 / 外部连接 / 数据存储 / 传感)
• 每个 threat 有相应控制(mitigation)
• 持续监控 + 事件响应能力

姊妹法规,管 OTA:

• 软件更新过程必须可追溯
• 更新版本 + 兼容性记录
• 更新失败回滚机制
• 用户被告知

实务:OEM 拿不到 R155 + R156 证书 → 整车型在欧盟卖不了。这就是 21434 不是"建议",是法规驱动的事实强制。

对 CAN / Ethernet 报文加 MAC(Message Authentication Code)+ Freshness Counter,防止篡改 + 重放。AUTOSAR 标准化。

双重角色:

• 26262 SM:防伪造扭矩命令 → 等价于 ASIL D 端到端通信完整性 SM
• 21434 控制:防中间人攻击 → CAL 2-3 通信完整性

详见 CAN E2E + SecOC。

启动时校验固件签名 + 完整性,防恶意固件:

• 硬件 root of trust(HSM / TPM / OTP)
• 多级签名链(bootloader → firmware → application)
• 启动失败时回滚到 known-good

外部接口(OTA / V2X / 4G)必须 TLS 1.3+。CAN/LIN 内部经常加 SecOC,以太网内部加 IPsec / MACsec。

监控 CAN 总线 anomalous behavior:

• 新出现的 CAN ID(没在白名单)
• 频率异常(典型周期性的报文不规律)
• 同一 ID 多 source(伪造)

PKI / 证书 / 对称密钥 lifecycle:

• 工厂阶段烧入 device certificate
• OTA 加密密钥定期轮换
• HSM 硬件保护私钥不出芯片

TC397 主驱 ECU 在本 TARA 中识别出三个关键资产。

1. OTA 签名私钥:存储于 HSM DFLASH1(128KB,R4 区域主机不可读),用于 ECDSA P-256 固件签名验证。
2. 电机转矩标定表:存储于 NVM(DFLASH0),控制最大输出扭矩与效率 MAP,篡改可导致异常加速或制动失效。
3. DoIP 诊断接口:OBD-II 物理端口 + Ethernet DoIP,用于读诊断码与刷写 ECU;攻击者可通过车底物理接入进入。

每个资产至少对应一个 STRIDE 威胁场景,说明攻击目标与手段。

影响类别与等级决定 TARA 的 Risk 上限。

攻击向量(Physical / Local / Adjacent / Network)是 Annex E 确定 CAL 的关键输入。

依据 Annex E 信息性矩阵,CAL 由 Impact × Attack Vector 在概念阶段冻结。

三个 CAL 等级对应的控制措施必须写入 Cybersecurity Concept 并在 System Design 阶段分配到各 ECU。

CAL 3(OTA 通道):TLS 1.3 双向认证 + ECDSA P-256 固件签名(在 HSM 内验证,私钥不出芯片)+ RXSWIN 版本绑定 + A/B 分区防降级(抗回滚计数器写入 HSM OTP)。

CAL 2(转矩标定表):UDS Security Access(0x27 服务)编程会话锁 + 标定数据 CRC 校验 + Secure Boot Stage 4 对标定分区完整性签名验证。

CAL 1(DoIP 接口):DoIP tester authentication(ISO 13400 扩展)+ 诊断会话超时 + CAN bus 防火墙限制诊断命令下行范围。

Annex E 的 CAL 矩阵使用 Attack Vector(Physical / Local / Adjacent / Network)作为横轴,而非 §15.6 的 Attack Feasibility(High / Medium / Low / Very Low)。两者是独立维度:Attack Feasibility 影响 Risk Value,但 CAL 由 Impact × Attack Vector 在概念阶段冻结,随后整个 V-cycle 不再更改。混淆两者会导致 CAL 随攻击难度评估结果漂移,失去设计稳定性。

标准正文 §15.2–§15.8 规定了 TARA 步骤,但 CAL 本身定义在 Annex E(信息性,非强制)。部分 OEM 自建 CAL 矩阵而不采用 Annex E——这是允许的,但必须在 Cybersecurity Plan 中明确声明所用 CAL 确定方法;审计时 "我们按 21434 做的" 不等同于 "按 Annex E 做的"。

AUTOSAR SecOC 默认 Freshness Counter 为 32-bit。在 100 Hz 报文频率下,$2^{32}/100\approx 4.295\times 10^7\text{s}$,约 1.36 年,整车寿命(10–15 年)内计数器可多次翻转。翻转前后存在重放攻击窗口。缓解:扩展至 64-bit Counter,或在 Freshness Value Manager 中引入基于行程周期(trip cycle)的 epoch 高位,确保每次上下电后 FV 单调递增。

21434 §13(Cybersecurity monitoring, evaluation and incident response)要求 OEM 在量产后持续监控威胁情报并评估已部署车辆的风险。工程实务中,开发阶段 TARA 做得严格,但 §13 的 VSOC(Vehicle Security Operations Center)投入常严重不足——而这是 UN R155 CSMS 认证机构实地考查的重点之一。

R155 Annex 5 §7.3.7 要求 OEM 有机制"检测并防御未授权的软件修改",经常被误读为"必须实现 Secure Boot"。R155 只规定结果而非手段——Secure Boot 是满足该要求的典型方案,但 IDS + 软件完整性哈希 + OTA 强制更新的组合同样可满足,前提是 CSMS 文档证明其等效覆盖。

OTA A/B 分区切换时,若抗回滚计数器(Anti-Rollback Counter)存储在可重写的 NVM 而非 HSM OTP,攻击者可清零 NVM 后重装旧固件(包含已知漏洞)。TC397 HSM DFLASH1(R4 区域)具备主机 CPU 不可写的硬件保护——正确做法是将 ARC 写入 DFLASH1 R4 区,由 HSM 固件维护单调递增性。

26262 HARA 识别的 Safety Goal(如"防止非预期加速")通常不反查其网络安全触发源;21434 TARA 识别的攻击路径(如 OTA 注入恶意扭矩命令)通常不反向标注为 HARA 的触发 Hazard。这使得"攻击导致的 ASIL D 失效"既不在 HARA 覆盖内(认为不是 malfunction),也不在 TARA 控制内(只分析到 CAL,未和 ASIL 联动)。三标准协同项目必须显式建立 Cybersecurity Goal → Safety Goal 的双向映射,写入 Cybersecurity Concept 与 Functional Safety Concept 的共同管辖说明。

SecOC Freshness Value 因丢包或上下电需要重同步时,Freshness Manager 多播 + ECU 确认协议需 5–30 ms 恢复窗口。EPS 方向盘转矩命令的 ASIL D FTTI 通常为 50 ms。若 EPS ECU 因 SecOC 验证失败(FV 不同步)持续拒绝转矩命令并超过 FTTI,则驾驶员失去助力转向——Cyber 验证逻辑直接触发 Safety 失效。工程缓解:SecOC 验证失败时 EPS 切换至 Fallback Mode(限幅无保护输出),Fallback 持续时长写入 Cybersecurity Concept,同时列为 FuSa / Cyber 共同工件。

ECDSA P-256 签名证书商业 PKI 有效期通常 10–15 年;车辆生命周期 12–20 年(出行运营车辆可达 25 年)。证书到期前若无 OTA 续签机制,车辆将无法验证任何后续固件更新。正确做法:在 CSMS 中规划车载证书 OTA 续签流程,包括跨根 CA 迁移路径——旧根 CA 签发过渡证书授权新根 CA,在车辆仍可信任旧证书期间完成迁移。

AUTOSAR UCM 对多个域控推送 OTA 时,目标 ECU 在验证 / Flash 写入期间可能重启或不响应网络请求——此时整车 E/E 架构的 Safety 冗余度下降。ADAS L2+ 场景下,若 ADAS ECU 与主驱 ECU 同时处于 OTA 更新态,两个 ASIL D 功能同时离线。OTA 系统必须在 Cybersecurity Concept 中声明"OTA 期间安全状态"(Safe State During Update),并与 FuSa Concept 中的最大降级持续时间对齐——通常要求 OTA 仅在车辆停驻且 EV 下电状态下执行。