2026-11-13 10:49:20 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

密钥落地（二）：从注入产线到售后换件—HSM / SHE 与整车密钥生命周期

谈思实验室

2026年11月11日 17:56
上海

去阅读

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

上期我们拆了 SecOC：它用 MAC 和 Freshness Value 回答「这条报文是不是可信的」。但 MAC 凭什么可信？密钥从哪来、是否唯一、能不能轮换、ECU 换件之后怎么办——这些问题不解决，认证机制只是看起来完整。本期按上期预告，把密钥从产线到报废的全生命周期走一遍。

一、先给密钥分层：信任域决定爆炸半径

车载密钥不是一个「密钥库」，而是按用途切开的多个信任域。先把这张表放进方案评审：

一个常被忽略的取舍：群组密钥分发与同步成本低，但单点失陷会扩大到批次；设备唯一密钥把爆炸半径压到一件，却对注入、吊销、换件流程提出更高要求。不要只按成本选，要在 TARA 里量化「密钥影响范围、可替代性、恢复时间、换件频率」再定。

二、注入产线：CMD\_LOAD\_KEY 的 M1—M5 到底在证明什么

很多人把密钥注入理解成「往芯片里写一组数」。SHE 的 CMD\_LOAD\_KEY 协议其实是一套双向证明，值得逐字段看：

M1（16 字节）

= UID ｜ LoadKey ID ｜ AuthKey ID。上位机事先要知道：往哪颗芯片（唯一 UID）的哪个密钥槽写、用哪个槽里的密钥来加密保护这次写入。
* K1 / K2

由 AuthKey 分别与 KEY\_UPDATE\_ENC\_C、KEY\_UPDATE\_MAC\_C 经 AES-MP（Miyaguchi-Preneel 压缩）KDF 派生；M2 是用 K1、IV=0 对「CID（28 bit）＋ FID（5 bit）＋ 95 bit 0 ＋ 128 bit 待注入密钥」做 AES-128-CBC 得到的 32 字节密文；M3 是用 K2 对 M1‖M2 计算的 CMAC。
* 下位机（SHE）解析 M1、校验 UID 与写保护标志、用 AuthKey 复算 K1/K2 验证 M3、解密 M2 得到 CID / FID / LoadKey；仅当新 CID 大于当前值时才落盘——这就是防回滚。
* M4 / M5

是下位机回给上位机的证明，上位机用 K3/K4 复算比对，确认「密钥确实按预期写入了这颗芯片的指定槽」。

图 1｜产线安全烧录与密钥注入方案架构

所以一条最小证据链应该是：芯片 UID 可读取 → 派生根可复算 → 使用边界明确（FID/写保护）→ 写入结果可证明（M4/M5）→ 生命周期状态受控（CID 单调）→ 审计记录不可抵赖（芯片序列号、批次、工位、时间、操作员、算法版本、结果与失败处置）。

「首次烧录完成」远不是终点。密钥从这一刻才开始被备份、托管、派生、复制、换件或吊销。若回答不了「哪把密钥在哪颗芯片、哪台设备、哪一版固件、何时有效、由谁批准」，即便芯片内部有安全存储，也不能证明整车具备密钥治理。用于灾难恢复的长期根材料、日常签发的 HSM 密钥、售后配对的设备密钥，不应共用同一备份域；生产主根绝不能落到工站镜像、日志、调试脚本或售后便携设备里。

本刊既往文章《汽车电子信息安全 CMD\_LOAD\_KEY 密钥注入详解》对 M1—M5 与 KDF 有逐字节推导，可作为本期延伸阅读。

三、SHE、EVITA HSM、TEE：三种东西别混着写

SHE（Secure Hardware Extension）

是 HIS 规范定义的片上安全扩展，给 MCU 提供受保护的密钥槽、AES-128 / CMAC、真随机数、计数器、安全启动与软件完整性证明；功能上近似 EVITA Light，范围比 Medium 窄。它是供应商实现规范，不是 UN R155、GB 44495 或 ISO/SAE 21434 的替代文本。
* EVITA

是欧盟 FP7 研究项目（2008—2011）提出的车载 HSM 架构，D2.3 / D3.2 交付物留下了 Light / Medium / Full 的能力分级：Light 偏传感器与执行器，提供对称加密引擎与基础硬件接口；Medium 增加独立 CPU、内部 SRAM、单调计数器与 TRNG，非对称与哈希可软件实现；Full 再覆盖非对称与哈希硬件加速、V2X 级吞吐，面向网关与中央计算。这是设计分类，不是某一国家或地区的型式批准门槛。
* TEE

（如 Arm TrustZone 安全世界）擅长富执行环境里的隔离服务、可信 UI 与复杂协议，但它不等价于「带独立 CPU、独立 ROM、私有总线与熔断密钥存储的 HSM 核」，也不天然满足车规实时性与可靠性。

图 2｜EVITA Full / Medium / Light HSM 结构对比

在 AUTOSAR 侧，密码能力由 Crypto Stack 分层承载：Csm（服务调用）→ CryIf（接口抽象与作业排队）→ Crypto Driver（厂商驱动）→ HSM / SHE 硬件；KeyM 负责密钥与证书全生命周期。这里有个很隐蔽的坑：如果配置错层，一个「本该跑在 HSM 里」的作业会落到软件驱动上，功能输出完全正确，但基于硬件隔离的全部安全论证同时失效。集成阶段务必核对 job 的 Crypto Driver Object 与密钥引用，而不是只测功能是否通过。

图 3｜EVITA 面向车载 HSM 的通用结构

四、安全启动、固件签名、吊销：三个不同控制

安全启动验证的是信任链每一步的授权与完整性，不是「能启动就安全」。 典型链路：不可变 BootROM → OTP/efuse 中的根公钥或公钥哈希 → 验证 Bootloader 签名 → 验证 Application 固件 → 运行时再叠加调试/诊断/远程命令的控制面。固件签名回答「这份镜像是否由授权者签发、是否被改」；安全启动回答「设备是否只执行经授权且完整的镜像」；两者都不替代运行期授权。

图 4｜Secure Boot 逐级信任链（BootROM → Bootloader → Application）

以 NXP HSE 的公开文档为例，可以更具体地看到「验证失败之后做什么」：主机可定义最多 8 个安全存储区（SMR），每个 SMR 绑定起始地址、大小与认证凭据（MAC 或 RSA/ECC 签名）；HSE 在复位后与运行期都可校验，验证结果通过 Core Reset（CR）表转化为制裁——让选定子系统保持在复位状态，或按 SMR 验证映射使指定密钥不可用。SMR #0 是唯一可绑定 SHE BOOT\_MAC\_KEY 的区域，参考认证标签 BOOT\_MAC 通过 SHE 密钥更新协议初始化与更新。

图 5｜NXP HSE 基于 SMR / CR 表的内存验证流程

吊销不是发一份 CRL 就结束。 签名根失效后，设备可能仍信任已缓存证书；时钟漂移、分区损坏、离线维护与长库存周期都会让吊销状态不一致。项目里必须预先写清：根密钥轮换周期、中间签名密钥层级、吊销列表发布与同步、设备端验证时间窗、未知状态是否拒绝启动、恢复是否需要售后凭证、旧版本是否允许安全回退。

五、从「首次烧录」到报废：九个状态与三个高危场景

量产密钥生命周期通常被拆成九段：生成（HSM TRNG 或 KDF，明文不出 HSM）→ 分发（产线注入 / OTA 加密包）→ 预激活（已注入未启用）→ 激活 → 使用 → 暂停（安全事件）→ 轮换 → 归档（仅验证历史数据）→ 销毁（不可恢复）。

存储也应分层：OTP/efuse 放 HUK、RoT 公钥哈希与 Secure Boot 公钥哈希；HSM 加密 Flash 放不可导出的主密钥 / KEK；NvM 放经 KEK 加密的业务密钥（SecOC、TLS）；RAM 只放用完即清零的会话密钥。禁止明文长期存储。

三个最容易出事故的场景：

其一，轮换。 不能「一刀切换密钥」，标准做法是新旧共存过渡：新密钥注入但不激活 → 发送用新、接收同时验新与旧 → 全网同步切换 → 旧密钥仅用于验证历史数据 → 归档期满销毁。少一步就可能让一部分 ECU 在升级窗口里集体失联。

其二，售后换件。 旧 ECU 的密钥要吊销并从群组移除；新 ECU 要完成身份绑定、密钥注入或派生、安全启动状态验证，以及与收发端对齐的 Freshness Value 基线；诊断仪、云端记录与售后工单要关联新序列号。直接把旧密钥复制到新件虽然能立刻恢复通信，却留下克隆、无法单独吊销、追溯断链三个后患。对共享 SecOC 网络密钥的场景，还要评估新件加入是否触发整个信任域重新分发。

其三，断电。 承接上期：Freshness Value 与单调计数器若只放在易失内存，蓄电池断电重启后接收端可能拒绝合法报文，或让重放窗口异常扩大。工程上通常把受保护计数器、Trip/Reset Counter 与必要同步状态写入受断电保护的持久存储，并保证写操作前后的一致性——但用哪种存储、是否加密、多久同步，属于工程实现，不是 AUTOSAR 对所有 ECU 的统一强制。

六、两个公开案例：调试口与物理攻击的前提要写全

特斯拉 TCU 调试接口。 公开技术转述记载：物理接触的攻击者在绕过安全措施后可取得 TCU 的 root 级代码执行；特斯拉于 2025 年 3 月 3 日收到报告、次日确认，2025 年 4 月 24 日在 2025.14 固件版本中推送补丁，修复方式是禁用量产车 Micro USB 接口的 ADB；NCC Group 在补丁广泛部署后于 2025 年 9 月 29 日发布公开通告。限定必须保留：需要物理接触，不是远程攻破整车。

Black Hat USA 2024 的 JTAG 研究。 公开摘要称，研究者分析车规级 IC 的 JTAG 接口，通过电压故障注入绕过密码验证的冗余检查。它适合用来讨论测试接口在研发、产线、返修与报废各阶段的「最小开启原则」，但研究对象不是完整量产车辆，不能推导为某家车企的安全事故。

写公开案例有三个不能省的前提：攻击者是否需要物理接触或实验室条件、厂商是否确认与影响范围、修复版本是否已发布并验证。缺一条，就只能写「研究发现」。

七、与 TARA、GB 44495、R155 的证据衔接

ISO/SAE 21434:2021 是覆盖概念、开发、生产、运行、维护与销毁的网络安全工程过程标准，不规定某一种 HSM 必须有哪些密钥槽。国内采标项目《道路车辆信息安全工程》（计划号 20230389-T-339）等同采用 ISO/SAE 21434:2021；截至本期截点，未确认其已发布为正式标准号，故只称「采标项目」。顺带纠一个常见错：GB/T 41871-2022 的正式名称是《信息安全技术汽车数据处理安全要求》，是汽车数据处理的推荐性国标，不是网络安全工程采标文本。

UN R155 要求 OEM 取得 CSMS 合规证书并完成车型 VTA，同时管理供应商相关的网络安全活动；GB 44495—2024 要求的是整车层面可复现的验证证据。两者都不能被扩大解释成「对所有 HSM / SE / TEE 的一一强制」。TARA 该做的是把密钥生命周期风险落到资产、攻击路径与残余风险上——而不是在控制措施栏里只写一句「采用 HSM」。