ISO/SAE 21434 — 汽车网络安全深度

下表把两套标准的"对手 / 风险评估 / 输出"3 个维度并排:

协同方法学:学术界已有 ISO 26262 + 21434 co-analysis 框架,在 concept 阶段把 HARA + TARA 一起做,避免后期 conflict。

ISO 21434:2021 共 15 个 clause,核心 work product 聚集在 Clause 5–11:

5 个术语必须先弄清楚,后续 TARA / CAL / SecOC 讨论都建立在其上:

• CSMS(Cybersecurity Management System):organization-level 治理框架,UN R155 强制审计对象;ISO 21434 Clause 5 + 6 是 CSMS 的实现
• CAL(Cybersecurity Assurance Level):1–4,数值越大要求越严;concept 阶段由 TARA 决定后冻结,贯穿整个 V-cycle
• TARA(Threat Analysis and Risk Assessment):Clause 15 详细方法
• Risk Treatment:4 种处理方式 — Avoid / Reduce / Transfer / Retain(accept)
• EoCSS(End of Cybersecurity Support):车型生命周期结束日期,Clause 8 持续活动持续到此日

R155 是审计型法规(audit-based regulation):

• 强制要求:乘用车 / 轻商 / 部分重商必须建立 CSMS 才能获得 type approval
• CSMS 必须由独立认证机构审计后取得 CoC(Certificate of Compliance)
• ISO/SAE 21434 是事实上"满足 R155 CSMS 要求"的工程证据
• 审计基础:Annex 5 = 7 类高层威胁 + ~30 子类描述 + 69 个攻击向量(Part A),对应 Part B/C 的 mitigation 表(vehicle 级 + 车外环境级)

R156 把 software update 从 OEM 内部流程拉到法规约束:

• OEM 必须运营 SUMS(Software Update Management System),覆盖 OTA + 经销商更新两条通路
• RXSWIN(Regulation X Software Identification Number):每次 OTA 必须维护映射,做版本可追溯
• 每个 ECU 必须拒绝未签名 / 验证失败的代码 → secure boot + 数字签名是直接对应措施

下表是 R155/R156 + 中国 GB 的全球时间锚点,2024-07 与 2026-01 是两个最关键节点:

中国对标 R155/R156 但本土化更细:

• GB 44495-2024 — Vehicle Cybersecurity,对标 UN R155 + ISO/SAE 21434
• GB 44496-2024 — Software Update General Technical Requirements,对标 UN R156
• 适用对象:M / N / O 三类至少含 1 个 ECU 的车辆
• 强化项:国密 SM2 / SM3 / SM4 + anti-replay 物理测试
• 认证机构:CATARC(中汽研)是事实上唯一本土认证机构

TARA 5 步严格按顺序走,每步输出是下一步的输入:

Impact 不是单维 — 必须从 4 个独立角度评估:

每维 4 级:Negligible / Moderate / Major / Severe。

3 种主流评估法各有适用场景,业界通用做法是先 STRIDE 列威胁 → Attack tree 展开 → CVSS / EVITA 评分:

• CVSS(Common Vulnerability Scoring System):IT 通用,base score 0-10;偏离汽车特性但接受
• EVITA attack potential:基于 EVITA EU 项目,5 维评分(Elapsed time / Specialist expertise / Knowledge / Window of opportunity / Equipment);汽车场景最贴合
• STRIDE(Spoofing / Tampering / Repudiation / Information disclosure / DoS / Elevation):微软经典,做 threat enumeration 阶段用

CAL 由 ISO 21434 informative Annex E 给出(非强制——标准正文不要求 CAL,是 Annex E 提供的可选沟通尺度),在 concept 阶段按(impact rating × attack vector:Physical / Local / Adjacent / Network)查表得到。刻意用静态的 attack vector 而非会随防护迭代变化的 attack feasibility,正是为了让 CAL 冻结后能稳定贯穿整个 V-cycle。下图按业界工具常见的 impact × feasibility 近似呈现该查表(各 OEM 略有差异):

• CAL1:低保证,基本审查 → 满足通用安全实践
• CAL2:中等,需要结构化设计 + 单元 / 集成测试
• CAL3:高,需要形式化方法 / 独立 V&V / 渗透测试
• CAL4:极高,完整独立网络安全评估 + HSM CAL4 ITSEF 测试

SecOC 防总线注入 / replay 攻击,AUTOSAR Classic R22-11 SWS 标准化:

• 核心机制:Sender 给 I-PDU 附加 Truncated MAC + Freshness Value,Receiver 校验
• MAC:AES-128 CMAC 是默认算法,截断到 64 / 32 bit 适配 CAN 带宽
• Freshness Value:单调计数器 / 时间戳,防 replay attack;由 Freshness Manager 模块管理,sender / receiver 同步
• 集成栈:Application → PduR → SecOC → Crypto Service Manager(CSM)→ Crypto Driver → HSM
• 实战漏洞:2024-03 I CAN Hack 公开从 2021 Toyota RAV4 Prime 的电动助力转向(EPS)ECU(Renesas RH850/P1M-E)提取 SecOC 密钥——根因是 AES 全在软件里算(密钥驻留 host RAM 可被 dump)+ bootloader 只做 CRC32/CMAC 校验、无数字签名(voltage FI 绕过 debug lock 后上传 shellcode 经 CAN dump 内存)。教训:密钥必须锁进 HSM、bootloader 必须验签,SecOC 的 truncated MAC 再强也救不了泄露的密钥

Secure Boot 对应 R155 Annex 5 的软件完整性缓解(mitigation 表:signed image / secure boot / anti-rollback)+ R156 对更新包真实性/完整性的验证要求——法规技术中立,但 type approval 卷宗里 secure boot 就是"每个 ECU 拒绝未签名 / 验证失败代码"这条威胁的主流缓解实现(注:R155 7.3.7 讲的是攻击检测/监控/取证能力,并非 secure boot,常被误引):

• Chain of Trust:Stage 0(ROM / fixed key)→ Stage 1(HSM firmware)→ Stage 2(Host BL)→ Stage 3(Application)→ Stage 4(Calibration data)
• 算法选择:ECDSA P-256 / RSA-2048 用于签名,SHA-256 用于摘要(部分新设计转 Ed25519)
• 关键认知:Root of Trust 必须不可改写(masked ROM 或 OTP),否则攻击者可以替换 Stage 0 公钥

OTA 完整流程必须 6 步闭环:

1. OEM 后台签名
2. CDN 分发
3. 车端验证签名
4. A/B partition 写入
5. 失败回滚
6. 上报 SUMS

关键控制点:RXSWIN 版本号绑定 + 增量(delta)更新 + power-loss safe + 用户 informed consent。2026 起讨论 post-quantum OTA 签名(Dilithium / SPHINCS+ 候选)。

下表是 2026 主流 HSM 硬件 + 等级:

按资源 + 加密能力 + 用途分:

ETAS ESCRYPT CycurHSM:全球第一款 获得 ISO/SAE 21434:2021 CAL4 三方认证的 HSM firmware:

• 运行在 AURIX TC4x 等平台
• Tier-1 部署 > 100 个量产项目
• 支持中国国密 SM2 / SM3 / SM4 算法
• 跨三家硬件部署(Infineon / NXP / Renesas)

标准化加密栈:

• 对称:AES-128 / AES-256(CMAC / GCM / CTR)
• 非对称:ECDSA P-256(首选,签名短适合 CAN)/ RSA-2048(legacy)
• Hash:SHA-256(主流)/ SHA-3(规划)
• KDF / KE:HKDF + ECDH P-256
• PQC 候选:CRYSTALS-Dilithium(签名)/ Kyber(KEM),Infineon AURIX TC4xx 已加 PQC-ready 特性

CAL4 要求 HSM 通过 ITSEF SCA / FI 实验室测试:

• 威胁:Power-based SCA 可在 1000 traces 内提取 AES key;FI 可在 SubBytes 阶段翻 8 bit
• 对抗手段:Masking(布尔/算术)/ Hiding(dummy ops)/ Redundant computation + comparison / Voltage glitch detector / Light sensor / Memory ECC

R156 软件可追溯 + ISO 21434 lifecycle vulnerability mgmt 直接驱动 SBOM 成为必需:

• CycloneDX:更适合安全,原生支持 VEX(Vulnerability Exploitability eXchange)
• SPDX:license 合规 + 已是 ISO 标准
• 扩展概念:HBOM(硬件 BoM)+ CBOM(密码学 BoM)— VicOne xZETA 已支持
• Auto-ISAC 2025:行业层面统一 SBOM informational report,标准化 OEM-supplier 流通

下表是 2026 主流 ISO 21434 兼容工具:

方法论:fuzz testing 用畸形输入暴露未知漏洞,pentest 用真实攻击场景验证防御。ISO 21434 Clause 11 cybersecurity validation 通常两者结合。

中国本土网络安全生态 4 类玩家 — 认证 + HSM 软件 + Pentest + 培训:

• CATARC(中汽研):GB 44495 主要测试 + 认证机构,运营 10 大业务线
• ETAS ESCRYPT:支持 SM2/SM3/SM4 国密算法,Tier-1 中国项目部署密集
• Onward Security(台资):做汽车 + IoT pentest + 21434 顾问
• dissecto / Breachlabz:做 GB 44495 testing 培训

行业里程碑事件:

• 2024-07 ETAS ESCRYPT CycurHSM 全球首张 ISO 21434 CAL4 认证(HSM 软件)
• 2024-07 Synopsys IP 业界首个 IP 核通过第三方 ISO/SAE 21434 认证
• 2024+ Infineon AURIX TC397 首批拿到中汽研 CATARC GB 44495 认证的 MCU
• 2025 Intellias 把 ISO/SAE 21434 认证扩展到全部 mobility 工程中心
• 2025+ PlaxidityX × Continental — Continental SDV 战略将 PlaxidityX 作为 security-by-design 关键支柱

2026-01 GB 44495 新车强制 → 2028-01 全车型强制,窗口期工程师必做 3 件事:

• CSMS 建设 + ISO 21434 vocabulary 训练
• 关键 ECU 渗透测试 + Fuzzing 体系建设
• SBOM(CycloneDX 优先)+ HBOM + CBOM 工作流落地

先定资产与威胁再评分。核心资产是转向力矩指令报文(要 integrity + authenticity),一行 TARA 走完 15.2–15.8:

CAL 定级:Annex E 查表——Severe impact × attack vector = Network(经 telematics 可远程触及)→ CAL4。网络安全目标(15.8 输出):① 力矩指令必须可认证/防篡改;② EPS 只运行签名固件。

CAL4 + Severe safety 决定了实现档位,三件套逐项落地:

• HSM 档位:转向属安全关键 + 需非对称验签 + 抗 SCA → EVITA Full,AURIX TC397 内建 HSM 直接满足(密钥进 HSM secure flash,不进 host RAM——这一条正是 RAV4 的死因)
• SecOC:AES-128 CMAC,CAN-FD 64 B 报文里放 32-bit truncated MAC + freshness value;截到 32 bit 的盲伪造成功率 $2^{-32}\approx 2.3\times 10^{-10}$/次,总线盲猜不可行;若为省带宽截到 24 bit 则升到 $2^{-24}\approx 6\times 10^{-8}$,安全关键报文不建议
• Secure Boot:ECDSA P-256 签名 + SHA-256 摘要,root 公钥哈希烧进 HSM OTP(不可改写),链 Stage0(OTP)→ HSM FW → Host BL → App;TC397 HSM 的 PKC 模块做 ECC 验签,启动期一次
• Key mgmt:每 ECU 唯一密钥,EOL 产线注入,存 HSM secure flash;对照 RAV4 的"软件 AES + RAM 密钥 + 无签名 bootloader",这里三处全反着做

一句话:同样的 EPS ECU,把密钥关进 HSM、给 bootloader 加 ECDSA 验签、MAC 不低于 32 bit,I CAN Hack 那条链就断在第一步。

以下 7 条是审计与渗透测试里高频翻车点:

• 密钥必须留在 HSM,不能进 host RAM — RAV4 教训:软件 AES → 密钥可从 RAM dump;truncated MAC 再强,密钥泄了全盘皆输
• truncated MAC 长度是安全/带宽权衡 — 截 24 bit 省总线但盲伪造概率升到 $2^{-24}\approx 6\times 10^{-8}$;安全关键报文别低于 32 bit——"用了 CMAC"不等于安全,截断长度才是实际强度
• Freshness Value 同步是 SecOC 最脆的环 — sender/receiver freshness 计数器失步(掉电、总线重启、gateway 转发)→ 合法帧被丢或 replay 窗口打开;Freshness Manager 的 trip/reset counter 管理是常见实现 bug 源
• Root of Trust 必须不可改写 — Stage 0 公钥若落在可重写 flash,攻击者换公钥即绕过整条链,必须 masked ROM 或 OTP;只做 CRC32/CMAC 校验、无签名 ≠ secure boot
• CAL ≠ ASIL,不能直接换算 — CAL 由(impact × attack vector)定、ASIL 由(S/E/C)定;高 ASIL 不自动等于高 CAL(可能无攻击面),反之亦然,别拿 ASIL D "折算" CAL4
• 21434 认流程,不认产品 — CAL4 认证(如 CycurHSM)指该 firmware 的开发过程达 CAL4 保证等级,不等于"装上即合规";整车侧的 TARA / 集成 / Clause 11 validation 仍要自己做
• R155 是 audit-based,补测来不及 — work product 必须开发期同步产出;拖到 type approval 阶段才补 TARA / 渗透报告,证据链和时间都不够

三类边角场景值得在 concept 阶段就显式接受或设计:

• Legacy CAN(非 FD)带宽逼近极限 — 经典 CAN 8 B 塞不下 full MAC + freshness,只能截到 24–28 bit 或用 external freshness(不随帧传、双方各自维护)→ 安全边际下降,须在 TARA 里显式接受残余风险
• EoCSS 之后的活车 — 车型过了 End of Cybersecurity Support 仍在路上跑,新漏洞(如 PQC 迁移前 RSA-2048 被攻破)无人再打补丁 → Clause 8 continual activities 的责任边界与召回风险
• 国密 + 国际算法双栈 — 出口中国的车既要 SM2/SM3/SM4(GB 44495)又要 ECDSA/SHA-256(R155/欧盟),HSM 要同时跑两套 → 密钥空间/存储/性能预算翻倍,ETAS CycurHSM 支持双栈正为此

ISO 正本 / UN 法规 / 中国 GB 三条主线:

• ISO/SAE 21434:2021:https://www.iso.org/standard/70918.html
• UN R155 Cybersecurity:https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-uniform-provisions-concerning-approval
• UN R156 Software Update:https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update
• GB 44495-2024 全文:https://www.codeofchina.com/standard/GB44495-2024.html
• TÜV SÜD 中国实施时间表:https://www.tuvsud.com/en/knowledge-hub/technical-updates/consumer-products-and-retail-essentials/china-implements-vehicle-cybersecurity-technical-requirements

TARA 方法学权威源:

• uraeus TARA Guide:https://uraeus.io/resources/iso-21434-tara-guide/
• itemis TARA:https://www.itemis.com/en/cybersecurity/tara
• Block Harbor CAL Blog:https://www.blockharbor.io/blog/cybersecurity-assurance-levels-in-product-development-lifecycle
• EVITA HSM PQC paper:https://eprint.iacr.org/2020/026.pdf

工程实现的 vendor + 学术来源:

• AUTOSAR SecOC R22-11 SWS:https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_SWS_SecureOnboardCommunication.pdf
• Renesas Secure Boot RH850 / R-Car:https://www.renesas.com/en/blogs/achieving-root-trust-secure-boot-automotive-rh850-and-r-car-devices-part-2
• SecOC 实战漏洞(RAV4 key extraction):https://icanhack.nl/blog/secoc-key-extraction/
• Promwad Secure OTA Boot Chains:https://promwad.com/news/secure-ota-boot-chains-firmware-verification

HSM 三家 + ETAS 软件栈:

• Infineon AURIX TC3xx HSM:https://www.infineon.com/dgdl/Infineon-AURIX_TC3xx_Hardware_Security_Module_Quick-Training-v01_00-EN.pdf
• ETAS ESCRYPT CycurHSM CAL4:https://www.etas.com/ww/en/products-services/cybersecurity-products/escrypt-cycurhsm/
• Synopsys IP first ISO 21434 cert:https://news.synopsys.com/2024-07-17-Synopsys-Advances-Automotive-Security-with-Industrys-First-IP-Product-to-Achieve-Third-Party-Certification-for-ISO-SAE-21434-Cybersecurity-Compliance
• Infineon CATARC + PQC:https://www.eejournal.com/industry_news/infineon-strengthens-automotive-microcontroller-portfolio-with-iso-sae-21434-compliance-catarc-certification-and-pqc-ready-features/

SBOM + Fuzzing + Pentest 链:

• VicOne xZETA SBOM:https://vicone.com/products/xzeta
• Cybellum platform:https://cybellum.com/platform/
• PlaxidityX Security Autotester:https://plaxidityx.com/security-engines/security-autotester/
• Block Harbor Fuzz vs Pentest:https://www.blockharbor.io/blog/fuzz-testing-vs-penetration-testing-in-automotive-cybersecurity