车载网络安全与 ISO/SAE 21434

引言

车载网络安全与 IT 安全的根本差别在于「后果的物理性」。企业网络被入侵，损失是数据与金钱；车被入侵，损失可能是人的生命。攻击者可以通过 OBD 口、T-Box 的蜂窝链路、蓝牙、WiFi、USB、甚至 V2X 消息进入车内网络，一旦拿到 CAN 总线上的写权限，就能伪造刹车指令或刷入恶意固件。

第二个差别是「攻击面与生命周期」。一辆车有上百个 ECU、几十个网段、上百个软件版本，且要在路上跑 10 到 15 年。这意味着攻击面巨大且长期暴露，任何一个供应商的漏洞都可能成为整车级入口，而补丁的分发依赖 OTA 通道——安全机制与更新机制互相依赖，形成闭环。

第三个差别是「法规强制」。UN R155 自 2024 年 7 月起对所有新车型强制，要求车厂建立 CSMS（网络安全管理体系）并通过车型认证；ISO/SAE 21434 则是把「安全工程」写进开发流程的技术标准。安全从「加分项」变成了「上市门槛」。

本文按「标准与流程 → 威胁分析 → 攻击面 → 报文认证 → 硬件信任根 → 安全启动 → 密钥与鉴权 → 法规落地」的顺序展开。功能安全的边界见 功能安全 ISO 26262 工程实践 ：26262 管「东西坏了怎么办」，本篇管「被黑了怎么办」，两者在同一 ECU 上并存且证据要能互相引用。诊断侧的安全访问机制见 诊断协议 UDS 与 OBD 。

目录

1. 车载安全与 IT 安全的差异
2. ISO/SAE 21434 生命周期与组织要求
3. TARA 威胁分析与攻击树
4. 攻击面梳理：从 OBD 到 T-Box
5. SecOC 报文认证与新鲜度管理
6. HSM 与 SHE：硬件信任基础
7. 安全启动与信任链
8. 密钥管理与刷写鉴权
9. UN R155/R156 与 CSMS 落地

1. 车载安全与 IT 安全的差异

车载安全的约束条件与 IT 完全不同，这决定了不能照搬 IT 的安全方案：

维度对比：
  IT 安全                  车载安全
  ────────────────────────────────────────────
  资产：数据与算力          资产：人的生命 + 车辆控制权
  后果：泄密、勒索          后果：失控、召回、伤亡
  生命周期：3~5 年          生命周期：10~15 年
  更新：随时打补丁          更新：OTA 需驻车、需法规备案
  节点数：几十到几百台      节点数：单车 100+ ECU
  网络：通用 IP 协议        网络：CAN/LIN/以太网异构混合
  算力：充足                算力：MCU 受限，密码运算吃力
  物理接触：几乎不可能      物理接触：OBD 口、USB 口随时可插

三条推论直接决定了技术选型。第一，资源受限：一颗 200 MHz 的 MCU 上跑 AES-128-CMAC 已经占了可观的 CPU 时间，所以不能在每个报文上做 TLS，只能用截断的 MAC（SecOC），把开销压到每帧几微秒。

第二，物理接触容易：OBD 口就在驾驶位下方，攻击者可以插上设备直接读写总线。这意味着「物理边界即信任边界」的假设不成立，密钥必须放在防提取的硬件里（HSM/SHE），调试口必须在量产版本关闭。

第三，长生命周期：10 年后量子计算机可能威胁 RSA 与 ECC，所以密钥体系与签名算法要预留迁移空间（如多公钥槽、算法可协商）。这与 IT 侧「每 3 年换一代基础设施」的假设差异很大——车上的密码算法一旦冻结，可能要用到车辆报废。

2. ISO/SAE 21434 生命周期与组织要求

ISO/SAE 21434 于 2021 年发布，取代了 SAE J3061，是汽车网络安全的工程标准。它的核心是把「安全活动」嵌进 V 模型的每个阶段，并要求全生命周期的风险管理：

21434 的阶段与活动：
  概念阶段
    - 定义 Item 与边界（哪些 ECU、哪些接口）
    - 初步 TARA（威胁场景识别）
    - 定义网络安全目标（Cybersecurity Goals）
  开发阶段
    - 细化 TARA，评估攻击路径可行性
    - 安全需求（CSR）分配到组件与接口
    - 安全机制设计与验证（SecOC、HSM、防火墙）
  生产阶段
    - 密钥注入、产线安全、调试口管控
  运行与维护
    - 漏洞监控与 VDP（漏洞披露流程）
    - 事件响应、补丁发布、TARA 复审
  退役阶段
    - 密钥吊销、数据清除

组织层面的关键产出有四份：Cybersecurity Plan（安全计划，定义活动与责任人）、TARA 报告、Cybersecurity Case（安全案例，论证风险已降到可接受）、以及 CIA（Cybersecurity Interface Agreement，网络安全接口协议）。

CIA 是供应链协作的抓手。OEM 与 Tier1 之间必须明确「谁负责哪一部分的安全需求、谁提供哪些证据、漏洞由谁响应」。现实中大量风险出在边界模糊处：OEM 以为 Tier1 做了网关防火墙，Tier1 以为 OEM 负责整车网络隔离，结果两边都没做。21434 还引入 CAL（Cybersecurity Assurance Level） 概念，类似功能安全的 ASIL，用来表达「这个组件需要多强的安全保证」，但 CAL 目前没有 26262 那样严格的强制分级表。

流程复用是降本的关键。21434 的活动（需求管理、变更管理、配置管理、追溯矩阵、独立评估）与 ISO 26262 高度重合，与 ASPICE 的过程要求也几乎一致。成熟团队不会为网络安全单独建一套工具链，而是在既有的需求管理（DOORS/Polarion）、缺陷管理、评审流程里增加「安全」属性字段，把 TARA 的条目挂到需求树上。这样做的额外收益是：一份需求追溯矩阵能同时支撑功能安全与网络安全两个体系的审计，工作量不会翻倍。

3. TARA 威胁分析与攻击树

TARA（Threat Analysis and Risk Assessment）是 21434 的核心方法论，与功能安全的 HARA 是一对镜像：HARA 评估「非恶意失效」的风险，TARA 评估「恶意攻击」的风险。

TARA 步骤：
  1. 资产识别（Asset Identification）
     要保护的资产：制动控制权、密钥、个人数据、固件
     属性：机密性（C）、完整性（I）、可用性（A）
  2. 威胁场景识别（Threat Scenario）
     如「攻击者伪造制动 CAN 报文」
  3. 攻击路径分析（Attack Path Analysis）
     用攻击树把威胁拆成可执行的步骤
  4. 攻击可行性评级（Attack Feasibility）
     基于耗时、专业度、知识、机会窗口四因素
  5. 影响评级（Impact）
     Severe / Major / Moderate / Negligible
  6. 风险值 = 可行性 × 影响 → 决定处置
  7. 输出网络安全目标与声明（Claims）

攻击树把「目标」逐层拆成「子目标」，用 AND/OR 门表达逻辑关系：

攻击树（目标：伪造制动报文触发制动）：
  [根] 伪造制动 CAN 报文（AND）
    ├─ [1] 获得车内网络访问（OR）
    │    ├─ 利用 T-Box 远程漏洞
    │    ├─ OBD 口物理接入
    │    └─ 投递恶意 OTA 包
    ├─ [2] 绕过 SecOC 认证（OR）
    │    ├─ 从固件中提取密钥
    │    └─ 重放未被保护的报文
    └─ [3] 触发执行（AND）
         ├─ 报文 ID 与周期匹配
         └─ 目标 ECU 处于接收状态

攻击可行性评级沿用 ISO 18045 的四因素法，取值离散化后映射为 High / Medium / Low：

四因素组合后映射为可行性等级，再与影响等级交叉得到风险值：

风险矩阵（攻击可行性 × 影响）：
  影响 \ 可行性    High      Medium    Low
  Severe           极高       高        中
  Major            高         中        低
  Moderate         中         低        低
  Negligible       低         低        可接受

  处置优先级：
    极高 / 高 → 必须缓解，不可接受
    中        → 需论证，说明为何不可进一步缓解
    低        → 可接受，但需安全经理批准并记录

风险处置有四种：规避（去掉功能）、缓解（加安全机制，最常用）、转移（靠保险或合同）、接受（记录理由）。21434 要求每条「接受」都必须有明确的批准记录，否则审计不通过。攻击树的价值在于「可复用」：一个威胁场景的攻击树往往能覆盖多个相似的攻击路径，且当某条路径被缓解后，树上对应的叶子节点被剪掉，剩余风险一目了然。

4. 攻击面梳理：从 OBD 到 T-Box

攻击面梳理是 TARA 的输入。车载攻击面按「距离」分为远程、短距、物理三类：

三类攻击面中，远程攻击面的风险值最高，因为攻击者可规模化利用（一份 exploit 打穿所有同款车），而物理攻击面虽然容易实施，但难以规模化。这与 IT 安全的直觉一致：远程 + 可复制 = 最高优先级。

无钥匙进入的中继攻击是经典案例：两个攻击者各持一个中继器，一个在车旁放大车发出的低频信号，另一个在屋外车主钥匙附近放大钥匙响应，车辆误以为钥匙就在附近而解锁。缓解手段是引入 UWB（超宽带）测距，用飞行时间验证物理距离。

V2X 的攻击面比较特殊：它必须接收陌生车辆的消息，所以不能靠身份白名单，只能靠车路协同与 V2X 里的 SCMS 证书体系——每辆车用短周期轮换的假名证书签名，接收方验签并检查证书状态。

运行阶段的监控靠 IDPS（Intrusion Detection and Prevention System）。它部署在网关或中央计算单元上，用规则与基线检测异常流量：某个 ID 的报文频率突然升高（可能是重放或刷写攻击）、出现不该出现的诊断请求、某个 ECU 的报文突然消失、MAC 校验失败率陡增。第一代 IDPS 只做「检测并上报」，第二代开始做「主动阻断」，例如直接切断可疑节点的报文转发。R155 明确要求运行阶段具备检测能力，所以 IDPS 已是新车型的标配，而它的误报率与规则维护成本是实际落地的主要痛点——规则太严会误伤正常通信，太松则形同虚设。

5. SecOC 报文认证与新鲜度管理

SecOC（Secure Onboard Communication）是 AUTOSAR 定义的车内报文认证机制，解决「CAN 报文没有来源认证」的问题。它的思路是在原始 PDU 上追加一个截断的 MAC 和一个新鲜度值（Freshness Value）：

SecOC PDU 结构（以 CAN FD 为例）：
  ┌────────────┬──────────────┬─────────────┐
  │ Payload    │ Freshness    │ MAC         │
  │ 原始数据    │ 截断计数器    │ 截断 CMAC    │
  │ 0~52 字节   │ 2~8 字节      │ 3~8 字节     │
  └────────────┴──────────────┴─────────────┘

发送端：
  1. FV = FreshnessValueManager 取当前计数器
  2. MAC_full = AES-128-CMAC(K_auth, Payload || FV || DataID)
  3. 发送 Payload || FV[截断] || MAC_full[截断]

接收端：
  1. 用本地 FV 重算 CMAC
  2. 比对截断 MAC
  3. 校验 FV 在允许窗口内（防重放）
  4. 失败则丢弃并计数上报

截断（truncation）是 SecOC 的关键取舍。完整 CMAC 是 16 字节，CAN 帧根本放不下，所以截断到 3 到 8 字节。24 bit 的截断 MAC 意味着攻击者盲猜的成功率是 1/2^24，对车内攻击足够；但如果攻击者能大量发送尝试，就要靠接收端的失败计数与限流兜底。因此 SecOC 通常配合 CAN FD 使用——经典 CAN 一帧 8 字节，扣掉 3 字节 MAC 和 2 字节 FV 后有效载荷只剩 3 字节，几乎不可用。

新鲜度管理是 SecOC 最容易出错的部分。Freshness Value 必须收发双方同步，且接收端要容忍一定的窗口（因为报文可能乱序或丢失）。AUTOSAR 定义了 Freshness Value Manager（FVM）与 Freshness Value Master 的角色，同步策略有三种：隐式同步（用报文计数器）、显式同步（周期性发同步报文）、以及丢失后重同步。计数器不同步会导致接收端持续报 MAC 失败，表现为「上了 SecOC 后通信全断」——这是台架调试最常见的坑。

SecOC 保护的是「完整性 + 真实性」，不提供机密性（报文内容仍明文可见）。若需要机密性，要在 SecOC 之上再做加密，但车内大多只关心「别被伪造」。

SecOC 与 E2E 保护的区别

两者常被混为一谈，但目标完全不同。E2E 保护（AUTOSAR E2E Profile）防的是非恶意的通信故障——CRC 检测数据损坏，计数器检测丢失与乱序，它是功能安全机制（服务于 ASIL）。SecOC 防的是恶意伪造——用密钥认证来源，是网络安全机制。

工程上两者可以叠加，且常常必须叠加：SecOC 保证「这条报文不是伪造的」，E2E 保证「这条报文没传错」。只做 E2E 时，攻击者可以按完全正确的格式重放一条旧报文，E2E 检查不出来；只做 SecOC 时，总线干扰导致的数据位翻转不会被检测。代价是每条报文要同时携带 MAC、新鲜度、CRC 与 E2E 计数器，字节开销叠加，所以设计时要按报文的实际风险决定组合。

6. HSM 与 SHE：硬件信任基础

密码运算的密钥如果存在普通 Flash 里，攻击者拆机读 Flash 就能拿到，整个信任链归零。所以密钥必须存在硬件安全模块里：

SHE（Secure Hardware Extension）：
  定位：轻量级规范，面向 MCU
  能力：AES-128 加解密 + CMAC + 密钥槽管理
  密钥槽：通常 10 个，每个有权限位（读/写/导出/使用）
  用途：SecOC 的 CMAC 计算、安全启动的哈希校验
  代表：NXP CSEc（S32K）、Infineon 部分型号

HSM（Hardware Security Module）：
  定位：独立安全核 + 独立存储
  能力：AES、ECC、RSA、SHA、TRNG、单调计数器
  密钥槽：几十到几百个，支持密钥派生
  用途：安全启动验签、TLS、OTA 验签、密钥存储
  代表：Infineon AURIX HSM、NXP HSE
  认证：常按 EVITA Full / Medium / Light 分级

两者的分工很清晰：SHE 便宜、够用于对称运算；HSM 强、能跑非对称运算与完整协议栈。EVITA（欧洲项目）定义了 Full / Medium / Light 三档，Full 支持高速非对称运算（TLS 握手），Light 只支持对称。

硬件安全模块必须考虑物理攻击：侧信道分析（通过功耗或电磁辐射推断密钥）、故障注入（用激光或电压毛刺让校验跳过）。车规 HSM 通常带侧信道防护与传感器（电压、时钟、温度异常检测），异常时清除密钥。这也意味着 HSM 的认证等级（如 Common Criteria EAL）是选型的重要指标，不能只看功能列表。

密钥槽的权限位是容易忽视的细节。SHE 的每个密钥槽都带一组标志位：可写（WRITE）、可读（BOOT_PROTECTION）、可用于加密（ENC）、可用于 MAC（MAC）、可导出（KEY_USAGE）等。设计原则是「一次写入、永不导出」：产线注入后立刻把 WRITE 置零，把 KEY_USAGE 设为不可导出，这样即使应用软件被攻破，也无法把密钥读出来带走。很多安全事件的根因就是某个槽被配成了可导出，或产线工具留下了后门接口。

7. 安全启动与信任链

安全启动（Secure Boot）保证「上电后执行的每一段代码都是被授权的」。它的实现是逐级验签的信任链：

信任链（Root of Trust → Application）：
  BootROM（固化在芯片，不可修改，信任根）
    │ 验签
    ▼
  Bootloader / 二级引导（验签 + 防回滚检查）
    │ 验签
    ▼
  OS 内核 / Hypervisor
    │ 验签
    ▼
  RootFS / 应用 / Adaptive 应用包

两种校验方式的选择很关键：

工程上常见组合：用签名校验保证可更新性（公钥固定在 HSM，签名可随固件更新），用 HSM 内的单调计数器做防回滚——记录「最低允许版本」，拒绝刷入有已知漏洞的旧固件。防回滚是容易被忽略的一环：没有它，攻击者可以把车刷回一个有漏洞的版本，绕过所有后续补丁。

验签的性能要算进启动时间预算：RSA-2048 验签约 5 到 15 ms，ECDSA P-256 约 3 到 8 ms，若用软件实现会慢一个数量级。所以安全启动普遍用 HSM 硬件加速，且只对关键镜像做验签，非关键分区可延迟校验。

失败处理同样重要：验签失败时不能启动，但要进入一个可恢复的兜底通道（恢复模式或 A/B 分区回滚），否则一次签名错误就变砖。

安全启动会显著拉长启动时间，必须做预算管理。以一颗中端 MCU 为例：BootROM 校验 Bootloader（RSA-2048，约 10 ms）、Bootloader 校验 OS（约 10 ms）、OS 校验应用（约 10 ms），加上 Flash 读取与哈希计算，总开销 50 到 100 ms。对座舱域控这种要求「上车 2 秒点亮仪表」的场景，这个数字是可接受的；但对要求「10 ms 内响应刹车」的底盘 ECU，安全启动只在冷启动时发生，运行时的完整性靠周期性自检（如 CRC 巡检关键代码段）而不是每次执行都验签。

8. 密钥管理与刷写鉴权

密钥管理是车载安全中最难「做对」的部分，因为它跨越了云端、产线、车端三个环境：

密钥生命周期：
  1. 生成：在 HSM 或 TRNG 中生成，私钥永不离开安全环境
  2. 分发：加密传输到签名服务器与产线注入设备
  3. 注入：产线安全工位写入 ECU 的 HSM/SHE 密钥槽
  4. 使用：签名（云端）、验签（车端）、会话（诊断）
  5. 轮换：预留多个公钥槽，通过 OTA 更新公钥
  6. 吊销：泄露后加入黑名单，靠 OTA 下发

密钥体系应分层：根密钥（出厂固化，寿命最长）→ 签名密钥（用于固件与升级包签名）→ 会话密钥（诊断或 TLS 会话，短周期）。分层的好处是某一层泄露时只需轮换该层，不必重刷全部设备。

刷写鉴权是攻击者最感兴趣的目标，它由三道锁组成：

• 升级包签名：升级包必须由私钥签名，车端用公钥验签（见车载 OTA 升级与安全 ）。
• 诊断安全访问：UDS 的 0x27 服务用种子-密钥挑战应答解锁刷写权限，算法必须足够强且密钥不可从固件提取。
• 网关鉴权：诊断路由必须限定来源，禁止外部设备通过 T-Box 直接访问车内诊断网段。

密钥管理最常见的三个错误：私钥硬编码在固件里（反编译即可得）、密钥明文存 Flash（拆机可读）、量产版本未关闭调试口（JTAG 直接读内存）。这三点在 TARA 里几乎总是被列为高可行性攻击路径。

9. UN R155/R156 与 CSMS 落地

UN R155 是联合国法规，把网络安全从「最佳实践」变成「准入门槛」：

UN R155（Cybersecurity Management System，CSMS）：
  两层要求：
    1. 体系认证：车厂必须建立并证明 CSMS 有效运行
    2. 车型认证（VTA）：每款车必须证明风险已被处置
  附录 5：列出威胁、脆弱性与缓解措施清单（作为检查表）
  时间线：
    2022 年 7 月：新车型强制
    2024 年 7 月：所有新车强制

UN R156（Software Update Management System，SUMS）：
  与 R155 配套，管软件更新体系
  要求记录 RXSWIN、证明更新安全性、保证可恢复

ISO/SAE 21434：满足 R155/R156 的技术标准依据

CSMS 落地要回答四个问题：谁负责（组织与角色）、怎么识别风险（TARA 流程）、怎么监控（漏洞情报订阅、车辆侧入侵检测 IDPS）、怎么响应（事件响应流程与补丁发布 SLA）。其中「漏洞监控」是最容易流于形式的环节——很多车厂建立了流程但没有真正订阅 CVE 与车联网威胁情报，导致已知漏洞在车上长期存在。

认证的流程分两步走：先由认证机构审核 CSMS 体系（文件、流程、责任人、记录），通过后颁发体系证书；再针对每个车型做 VTA（Vehicle Type Approval），提交该车型的 TARA、缓解措施与验证证据。体系证书有效期通常三年，且每年需要监督审核，这意味着安全活动不能「认证前突击」，必须常态化运行。

R155 附录 5 是一份「威胁清单」，列出约 70 条已知威胁与对应的缓解措施，覆盖后端、通信信道、更新流程、人为因素、外部接口、车辆数据与代码等类别。实操中它被当作检查表使用：逐条评估「这条威胁对我的车型是否适用、若不适用理由是什么、若适用缓解措施在哪」。附录 5 不是穷举，但它能防止团队只盯着自己熟悉的那几类攻击而漏掉整个类别。

供应链是另一个难点。R155 要求车厂对整车的风险负责，但大量 ECU 由 Tier1 提供。落地方式是：在采购合同中要求 Tier1 提供 TARA 证据与漏洞响应承诺，OEM 侧建立统一的漏洞库与补丁编排平台。这与功能安全里「安全案例要能追溯到供应商证据」的逻辑完全一致。

CSMS 与功能安全管理体系的协同是审计常问的问题。两个体系可以共用同一套需求管理、变更管理与追溯工具，但关注点不同：功能安全关注「非恶意失效」，网络安全关注「恶意攻击」，同一个风险可能同时触发两套流程——例如刹车 ECU 的软件缺陷，既可以被 SOTIF 分析为性能局限，也可以被 TARA 分析为可被远程利用的漏洞。成熟做法是建立统一的「风险登记册」，两个体系各自引用同一条目，避免重复分析与证据冲突。审计时，评估员会检查你能否说清「这条风险属于哪一类、由谁负责、证据在哪」。

权衡取舍

常见坑清单

1. 密钥硬编码在固件：反编译即可提取，TARA 直接判为高可行性，必须放 HSM/SHE。
2. 量产版本未关调试口：JTAG/SWD 可直读内存与密钥，产线流程必须包含关闭步骤。
3. SecOC 新鲜度不同步：计数器不同步导致接收端持续 MAC 失败，上保护后通信全断。
4. MAC 截断过短：8 bit 截断可被暴力盲猜，建议不低于 24 bit 并配失败限流。
5. 只做报文认证不做防重放：攻击者重放旧报文仍可触发动作，必须有新鲜度窗口。
6. 无防回滚机制：可刷入有漏洞的旧版本绕过补丁，必须用单调计数器记最低版本。
7. TARA 只做一次：开发完就归档，新接口与第三方库引入的新威胁无人跟踪。
8. CIA 责任不清：OEM 与 Tier1 互相假设对方做了防护，边界处出现真空。
9. 漏洞监控流于形式：订阅了威胁情报但无人处理，补丁 SLA 形同虚设。
10. 忽视物理攻击：HSM 无侧信道与故障注入防护，拆机即可提取密钥。

小结

车载网络安全的本质是「在资源受限、物理可达、生命周期极长的环境里建立信任」。三条主线撑起整套体系：流程（ISO/SAE 21434 的生命周期活动与 TARA）、机制（SecOC 报文认证、HSM/SHE 硬件信任根、安全启动、密钥管理）、法规（UN R155/R156 与 CSMS 认证）。

对软件工程师而言，最该先掌握的是 TARA 的思维方式——从资产出发，用攻击树拆解路径，按可行性 × 影响排序，再选安全机制。机制本身（SecOC 的截断与新鲜度、安全启动的信任链、密钥的分层）都不复杂，难的是把它们在全生命周期里持续维护。

继续深入的建议：先读 功能安全 ISO 26262 工程实践 理解安全与功能安全的边界，再结合 诊断协议 UDS 与 OBD 掌握刷写鉴权，然后通过 车载 OTA 升级与安全 理解补丁分发，最后看 V2X 车路协同与车联网通信 里的证书体系——那是车载安全里最接近 IT 侧 PKI 的部分。