软件定义汽车浪潮下，中央计算平台如何借安当CAS实现密钥集中治理与OTA协同

过去十年，整车电子电气架构经历了从分布式 ECU 到域控制器、再到中央计算平台的演进。当软件定义汽车（SDV）成为行业共识，原本散落在动力、底盘、车身、座舱、智驾各域里的加密密钥、证书与签名私钥，被迫面对一个全新的命题：在算力集中、功能融合、迭代频繁的车端环境里，密钥到底该由谁生成、在哪里存储、被谁调用、如何被审计。本文不谈概念营销，只从工程落地的角度，把这条链路拆开来讲清楚。

一、域融合之后，密钥为什么必须集中管

在分布式架构时代，每个 ECU 各管各的密钥，只要保证单点不泄露即可。但中央计算平台把几十个 ECU 的功能收敛到几颗 SoC 上，物理边界被打破，原来的"各自为政"暴露出三类典型问题。

第一类是密钥来源不可信。分散的烧录工具、各供应商自带的签名脚本，根密钥往往来自工程笔记本甚至测试机，无法证明根信任来自一个受保护的环境。一旦某家 Tier-2 的签名私钥泄露，整条供应链的固件完整性就崩塌。更麻烦的是，这类泄露通常很长时间都不会被发现，因为没有任何地方记录"这把私钥被谁导出过"。

第二类是生命周期脱节。车型、平台、软件版本三层维度叠加，密钥本应随项目隔离，但实际中常常混用同一把测试密钥跨项目签名，导致一个项目被攻破，其余项目连带失守。在 SDV 模式下软件版本迭代以周计，密钥和版本的绑定关系一旦混乱，OTA 回滚、合规举证都会变成不可能完成的任务。

第三类是审计断点。OTA 升级、诊断接入、产线烧录各自写日志，格式不同、时间不同步，出事之后无法还原"是谁、在哪个环节、用哪把密钥签了什么"，自然也就无法满足汽车网络安全监管对可追溯性的要求。监管检查要的不是一份报告，而是一串能被独立验证的操作证据。

中央计算平台的答案是把密钥从"算力资源"里剥离出来，交给独立的硬件信任根与集中的密钥服务去托管，让业务只调用接口、不接触明文密钥。这也就是汽车密钥管理在 SDV 时代的核心变化：密钥不再是某个团队的私有资产，而是平台级的共享基础设施。

需要补充一点：中央计算平台普遍采用虚拟化把多个域合并到同一颗 SoC，于是信任边界从"物理板卡"变成了"虚拟机与容器"。这意味着密钥服务不能只保护硬件那一层，还要在虚拟化层做隔离——不同安全等级的域（如智驾域与座舱域）即使跑在同一芯片上，其签名密钥与会话密钥也必须通过 hypervisor 的访问控制严格分开，不能因为算力共享就共享密钥。否则一个座舱应用的漏洞就可能横向移动到智驾域的密钥材料上。把硬件信任根、虚拟化隔离、集中密钥服务三者串起来，才是域融合后真正成立的密钥治理底座。

二、中央计算平台的密钥治理模型

集中治理的第一步，是建立一棵清晰的密钥层级，而不是把一堆私钥平铺在文件系统里。

这里的关键词是项目隔离。中央计算平台往往要同时承载多个车型、多个软件平台，密钥必须按"车型/平台"维度物理或逻辑隔离，避免一把密钥跨项目复用。HSM 负责密钥的生成、存储与运算，明文私钥不落盘、不进内存镜像，所有签名动作都在硬件内完成，这是固件安全的前提。

以安当CAS为例，其密钥生成、存储与运算全部下沉到对接的 HSM 内，并通过项目隔离把不同车型、不同平台的密钥划分到独立空间，业务系统只拿到签名接口和公钥，拿不到任何明文私钥。这种"密钥不离开硬件"的约束，正好对应了中央计算平台对根信任集中化的工程诉求。

除了层级与隔离，密钥治理还要回答三个运维问题。其一是密钥轮换：项目级密钥应有预设生命周期，到期或疑似泄露时在 HSM 内生成新密钥并保留旧公钥一段时间以兼容存量固件验签。其二是密钥撤销与废止列表：当某张 CA 证书或某把业务密钥失效，要有机制让车端在验签时拒绝它，而不是永远信任。其三是备份与恢复：根密钥不能只有一份，但备份本身也必须受 HSM 与三员分离保护，否则备份就成了新的泄露面。

三、安全启动链：从 BootROM 到应用的逐级验签

固件完整性是汽车网络安全的第一道防线。安全启动链（Secure Boot）的本质，是让每一级加载代码在交付控制权之前，先用上一级的公钥验证下一级的签名。

BootROM(固化公钥) └─ 验签 ─> BL1 (厂商密钥签名) └─ 验签 ─> BL2 (项目密钥签名) └─ 验签 ─> 操作系统/ hypervisor └─ 验签 ─> 应用容器 / 服务镜像

实现这条链有几个工程要点。其一，根公钥必须固化在不可篡改的存储区（eFuse/OTP），且烧录环节本身要受控。其二，每一级镜像都要带签名头，含镜像哈希、签名值、版本号、防回滚计数器。其三，验签失败要有确定性的处置策略，不是静默跳过，而是进入安全状态或仅允许授权回退。其四，中央计算平台普遍引入 hypervisor 与容器，验签边界要从裸机延伸到虚拟机镜像与服务包，否则"上面一层不验签"就会成为绕过整条链的缺口。

对于 ECU 固件签名，签名算法需要覆盖国际算法与国密算法两套体系：RSA、ECDSA 用于满足 UNECE R155 等海外法规的互认，SM2 则用于满足国内 GB 44495 及信创合规。一个合格的密钥服务应当同时暴露这几类签名接口，由车端验签端按区域与法规选择对应公钥。值得强调的是，算法可切换不代表流程可放松——无论用哪种算法，根信任、密钥隔离与审计这三件事都不能省。

四、OTA 协同：签名与分发的解耦

传统产线烧录里，签名和刷写是同一个工具顺手完成，到了 OTA 阶段就暴露出问题：升级包由云端打包、车端刷写，签名动作如果不独立，就会出现"谁能打包谁就能签名"的越权风险。

OTA 协同的正确姿态是签名与分发解耦。云端构建出升级包后，把待签名固件摘要送密钥服务做签名，密钥服务在 HSM 内用项目级密钥完成 ECU固件签名，只回传签名值与证书链；升级包本身与签名分开传输，车端在刷写前用本地固化公钥独立完成验签。这样即便分发通道被劫持，攻击者也无法伪造一个能被车端接受的签名。

以安当CAS为例，其固件签名 API 同时支持 RSA、ECDSA 与 SM2 三种算法，CA 证书体系基于 SM2 构建，云端流水线只需传入待签名摘要与项目标识，即可在硬件内拿到合规签名，无需在构建节点上保存任何签名私钥。对中央计算平台而言，这意味着 OTA 的"签名信任"可以独立于"分发网络"存在，二者互不绑架。

下表对比了耦合式与解耦式 OTA 签名的差异：

解耦之后还有两个延伸问题。一是差分升级包的签名：差分补丁同样要带签名，因为攻击者可以用伪造补丁把合法旧版本改成恶意新版本。二是A/B 分区的原子切换：验签通过才能置位激活标记，刷写中断不能让半签名镜像进入运行态。这两点都应写进 OTA 流水线的门禁里。

五、诊断接入认证与调试端口保护

车辆下线后，诊断仪、产线设备、售后工具都要通过诊断协议接入。诊断接入认证（Secure Access，对应 UDS 0x27 服务）的目的是防止未授权设备读写关键 ECU。典型做法是挑战-应答：诊断仪先请求种子（Seed），用本地持有的密钥计算出应答（Key），车端用对称或基于证书的非对称方式校验，通过才开放会话权限。在中央计算平台上，多个域被虚拟到同一颗芯片，诊断授权要精确到"哪个服务、哪个域"，不能因为打通了中央计算就给了全域钥匙。

调试端口（如 JTAG、SWD、USB DBG）则是另一类高风险面。调试端口保护要求在正常量产前熔断或锁定物理调试接口，且仅在安全启动链完整、持有授权凭证的前提下才允许临时开启。否则，攻击者只要能接触到电路板，就能绕过所有软件层防护直接读取固件与密钥。对中央计算平台来说，调试口一旦开放，就能直接触碰全部域的密钥材料，因此临时开启必须带时效、带审批、带审计。

这两类场景共用同一套密钥治理底座：诊断会话密钥与调试授权凭证，都应由集中密钥服务按项目维度签发，并在审计里留痕。把诊断接入认证和调试端口保护纳入统一的汽车密钥管理体系，而不是各写一套临时逻辑，是中央计算平台降复杂度、堵审计断点的务实做法。

从攻击者视角看，调试端口与诊断接口往往是成本最低的入侵路径，因为不需要破解复杂加密，只要拿到物理接触或一台授权设备即可。把这两类入口收归到集中密钥服务统一管理后，安全团队能在一个面板里看到"今天哪些设备开了调试、哪些诊断会话在跑、用的哪把密钥"，异常行为才会从日志噪声里浮现出来，而不是散落在十几套互不相通的工具里无人过问。

六、审计与合规：GB 44495、R155/R156 的落地抓手

监管不是事后补材料，而是把可追溯性设计进系统。国内 GB 44495《汽车整车信息安全技术要求》与联合国法规 UNECE R155（网络安全管理体系/CSMS）、R156（软件更新管理体系/SUMS），共同指向三件事：你有体系、你能举证、你能更新。

• 全链路审计：从密钥生成、签名请求、证书签发到诊断/调试授权，每一笔操作都要带操作者、时间、项目、用途、结果，且日志本身防篡改。
• 三员分离：系统管理员、安全管理员、审计员三者权限互斥，任何人不能既签名又审自己签的名，从制度上杜绝"一人包办"的越权。
• CA 证书可追溯：基于 SM2 的 CA 体系要能回溯某张证书由哪个根、哪次操作签发，支撑 R155 对供应链信任链的证明。

把审计做成"默认开启、不可绕过、独立存储"的能力，是应对 R155合规 与 GB 44495 现场检查的关键。下面的日志结构是实践中常用的最小字段集合：

{ "ts": "2026-05-27T09:36:14Z", "actor": "sign_svc_ci", "role": "security_admin", "project": "plat-X / model-Y", "action": "fw_sign", "algo": "SM2", "target": "ecu_zygote_v3.2.1", "result": "ok", "cert_sn": "0x8F3C..." }

独立的含义是：审计日志的写入权限不能和被审计的操作权限归一。也就是说，负责签名的账号不能去改写审计库，否则审计就成了自己证明自己。三员分离正是为此而设——安全管理员做签名，审计员只读日志，系统管理员管配置但动不了密钥与日志。

七、密钥服务的接口设计与调用范式

集中密钥服务对外暴露的接口，决定了业务接入的成本与安全水位。实践中建议把接口收敛成三类的精简集合，避免业务方直接碰 HSM 的复杂指令。

第一类是签名类接口：入参为项目标识、算法类型、待签名摘要，出参为签名值与证书序列号。业务方永远传摘要、不传明文私钥，密钥不出硬件。第二类是证书类接口：用于签发、查询、吊销 CA 体系下的业务证书，支持 SM2 证书链回溯。第三类是审计与授权类接口：记录并查询操作日志，提供诊断会话密钥、调试授权凭证的按项目签发能力。

调用范式上有两个工程约定。一是短生命周期凭证：诊断会话密钥、调试授权凭证不应长期有效，而应带有效期与单次用途，用完即废，降低泄露后被盗用的窗口。二是请求绑定上下文：每次签名请求都要带项目、版本、用途字段，密钥服务据此选择对应隔离域的密钥并写入审计，杜绝"同一把接口被借去签别的项目的固件"。对中央计算平台的多车型共线生产而言，这条上下文绑定是防止密钥串用的关键护栏。

八、一个落地案例：零部件厂商的供应链安全审核

某汽车电子零部件厂商需要向 OEM 交付带签名的 ECU 固件，并要通过 OEM 的供应链安全审核。原先他们的签名私钥放在工程服务器上，审核时被指出"根信任来源不明、无独立审计、跨项目共用密钥"三项缺陷。

改造路径是：引入 HSM 作为密钥根，按 OEM 项目维度做项目隔离；ECU 烧录环节改为先由密钥服务做 ECU固件签名，烧录工具只拉取已签名镜像与证书链；所有签名、烧录、诊断授权动作进入全链路审计，并按三员分离重新划分内部权限。最终该厂商以可举证的密钥治理链路通过了 OEM 的供应链安全审核，也顺带满足了出口车型的 R155 合规前置条件。

这个案例说明，汽车密钥管理的价值不在"多了个签名按钮"，而在把分散、不可证、易越权的密钥操作，变成集中、可审计、权责分离的工程能力。对中小零部件厂商而言，不必自建整套 HSM 与 CA 体系，关键是把"密钥来源可信、操作可审计、权责能分离"这三件事落到流程里，让 OEM 审核时能拿到一条连续可信的证据链。

需要提醒的是，通过一次审核不等于一劳永逸。车型量产后还会持续面临密钥轮换、证书续期、疑似泄露应急三件常态事务。建议在项目上线时就约定好轮换周期与应急断点：一旦某把业务密钥疑似泄露，能快速在密钥服务侧吊销并让车端验签拒绝，同时用新密钥重签存量固件下发。把"出事后的处置路径"预先写成可执行的流程，比事后手忙脚乱地补措施要稳妥得多，这也是 R155 对网络安全管理体系"持续改进"要求的实际落点。

方案参考

对于正在做 SDV 与中央计算平台落地的团队，密钥治理可以按以下顺序推进，不必一步到位：

1. 先立信任根，再做集中。优先把根密钥迁入 FIPS 140-2/3 认证的 HSM，明确"明文私钥不出硬件"的红线，再谈集中服务化。没有硬件信任根，集中只是把风险搬了个位置。
2. 按车型/平台做项目隔离。密钥从第一天就按项目维度隔离，杜绝测试密钥跨项目签名。这是成本低、收益高的基础动作。
3. 把安全启动链固化进开发流程。根公钥烧录、各级镜像签名头、防回滚计数器，要作为构建流水线的强制门禁，而不是实验室里的可选项。
4. OTA 签名与分发解耦。云端只送摘要、密钥服务回签名，升级包与签名分开传输，车端独立验签。即便分发通道被控，也无法伪造可信固件。差分包与 A/B 切换同样要纳入验签门禁。
5. 诊断接入认证与调试端口保护统一纳管。诊断会话密钥、调试授权凭证都走同一套集中密钥服务，量产前锁定物理调试口，授权开启留痕可追溯；诊断授权要精确到域与服务，避免全域钥匙。
6. 审计默认开启且独立。全链路审计覆盖密钥、签名、证书、诊断、调试五类动作，日志防篡改、独立存储；同步落实三员分离，让"谁签的、谁审的"经得起监管现场检查。
7. 以法规倒推设计。把 GB 44495、UNECE R155/R156 的条款映射到具体字段与流程，确保 CSMS、SUMS 的举证材料来自系统本身，而非事后补单。
8. 预留轮换与撤销能力。项目级密钥预设生命周期，配套密钥撤销与证书废止机制，让车端验签能拒绝失效密钥，支撑长期运维中的安全演进。

密钥治理不是 SDV 的附属品，而是中央计算平台能安全迭代的前提。把分散的密钥收拢到受硬件保护的集中服务里，让业务只调用、不持有，再配以可追溯的审计与权责分离，汽车网络安全与合规才真正有了落脚点。