ASPICE汽车软件开发流程学习基地

2026-09-21

导读：合规导向的车载密钥管理与证书系统GB 44495-2024、UN R155、UN R156 与 EU CRA

合规导向的车载密钥管理与证书系统

GB 44495-2024、UN R155、UN R156 与 EU CRA 的要求映射、目标架构与选型路径

文件定位	法规映射与选型决策支持，不构成认证、型式批准或法律意见。
对象	车载 KMS、PKI/证书系统、代码签名、OTA 发布与合规证据链。
版本基准	2026 年 9 月；实际申报、采购或测试时，应核对适用法规版本、修改单和主管机关要求。
编制人	Manus AI

核心结论	建议以“离线根信任 + HSM 保护的签名与密钥域 + 可扩展的证书生命周期服务 + OTA 签名/验证证据链 + 集中审计”为目标架构。选型不应从单一 CA 或单一 KMS 产品开始，而应先完成适用范围、证书规模、密钥保证级别和运维责任边界的判定。

执行摘要

对面向中国与欧洲市场的智能网联车辆，密钥管理系统与证书系统应被视为信息安全管理体系、软件更新管理体系和整车通信安全的共同控制面。GB 44495-2024 直接提出密码算法、密码模块、远程控制、外部接口、车端通信和软件升级相关要求。UN R155 通过 CSMS 要求制造商持续管理风险、供应链、监测与取证；UN R156 则要求软件更新的真实性、完整性、版本保护、失败恢复与受控证据。 [1] [3] [4]

推荐的落地方式是将根信任、业务签发、代码签名、数据加密和设备身份分成独立但可追溯的密钥域。根 CA 与 OTA 生产签名私钥应由专用 HSM 和双人双控程序保护。设备、服务、诊断与供应商工作负载的证书应由高可用 Issuing CA、RA 和证书生命周期管理服务进行自动化签发、轮换、吊销与状态发布。云 KMS 可以承担应用和数据加密域，但不应在没有补偿控制的情况下替代离线根信任。

适用边界	本报告将“R155156 CRA”解释为 UN R155、UN R156 和 Regulation (EU) 2024/2847（CRA）。CRA Article 2(2)(c) 排除适用 Regulation (EU) 2019/2144 的数字元素产品。因此，投放欧盟且受整车型式批准覆盖的车辆，应以 R155/R156 为主线；独立投放的数字产品、软件、设备或远程处理方案，才需逐项开展 CRA 范围判定。

1. 法规范围与对 KMS/PKI 的直接影响

法规 / 适用边界	对系统的核心要求	应形成的系统能力与证据
GB 44495-2024 中国 M/N 类及配备 ECU 的 O 类车辆	6.8 要求使用公开、已发布、有效的密码算法，并按算法与业务场景选择适当参数和选项。6.9 要求采用符合国际、国家或行业标准的密码模块，或说明未采用的合理性。远程控制、第三方应用、外部接口和车端通信要求真实性、完整性、访问控制和日志。	算法/参数基线；密码模块合规或合理性说明；HSM/TEE 接口说明；远程控制与通信证书策略；授权、日志和测试报告。
UN R155 车辆型式、CSMS	持续风险管理、供应商依赖、监测响应、测试与取证。车辆型式须实施适当缓解措施；所用密码模块应符合共识标准，非符合时由制造商说明。附录 5 明确覆盖提取密码密钥、弱/过期密码、开发证书残留、身份欺诈与未授权修改。	密钥台账、生命周期策略、供应商安全条款、TARA 关联、日志监测、取证导出、密码模块证据和例外审批。
UN R156 允许软件更新的车辆	软件更新真实性和完整性须受保护；RXSWIN/软件版本须唯一、可读且防止未授权修改；OTA 需具备失败/中断的回滚或安全状态，以及更新前置条件与用户告知。	代码签名链、发布审批、证书状态验证、包哈希、目标适配、回滚记录、版本台账、更新回执与长期留存。
EU CRA 适用范围内的独立数字产品	Annex I 要求认证/访问控制、保密性、完整性、secure-by-default、日志监测、安全更新和漏洞处理。Article 13 规定支持期内漏洞处理，通常不短于五年，除非预期产品寿命较短。	产品范围判定、SBOM、漏洞披露、补丁发布机制、支持期声明、产品技术文档与事件报告流程。

GB 44495 的 6.8 与 6.9 不等同于指定某一家 HSM、KMS 或 CA 产品。它们要求制造商形成可解释的算法、参数和密码模块选择，并将其与业务场景、TARA 结论和测试证据关联。对高价值私钥，最稳健的工程解释是使用不可导出的硬件保护、双人双控、密钥仪式、定期轮换和可验证备份。 [1]

2. 推荐的目标架构：控制面、信任面与证据面分离

目标架构将根信任与高风险私钥置于受控密钥域，将设备身份与证书生命周期置于高可用业务服务，将 OTA 发布与车端验签置于可复核的软件供应链中，并将台账、审计和监测汇集为合规证据面。这样既可支撑中国市场的密码模块与通信安全要求，也可支撑 R155 的全生命周期风险管理与 R156 的更新完整性要求。

图 1　建议的车载 KMS / PKI / OTA 目标架构（示意）

能力域	建议最小能力	不应妥协的控制
根信任与签名	离线根 CA；生产签名 HSM；密钥仪式；双人双控；可验证备份。	根私钥和 OTA 生产签名私钥不可导出；审批人与操作者职责分离。
设备身份与 PKI	Issuing CA；RA；证书生命周期服务；CRL/OCSP/黑名单；标准化注册接口。	设备、诊断工具、服务与供应商身份区分证书策略；吊销状态可用且可审计。
KMS 与数据加密	密钥分层；策略与租户隔离；密钥版本、轮换、封装与审计；多云适配。	不将根信任与普通应用数据密钥混用；不以共享账号承载密钥管理权限。
OTA 与软件供应链	构建签名、发布审批、目标控制、版本/哈希证据、车端验签、回滚与回执。	发布服务不直接持有可导出的生产签名私钥；车端拒绝失效或未授权证书链。
证据与监测	密钥/证书/算法台账；操作日志；SIEM；TARA 与 SBOM 关联。	审计日志防篡改、可导出且覆盖管理员与自动化身份；留存期与法规/合同对齐。

3. 按法规拆解的关键设计要求

3.1 GB 44495：密码、通信和远程控制应由同一身份体系支撑

第 6.8 要求使用公开、已发布、有效的密码算法，并针对不同密码算法和业务场景选择适当参数和选项。第 6.9 要求制造商采用符合国际、国家或行业标准要求的密码模块，或说明未采用此类密码模块的合理性。该要求应落实为算法和参数基线、密码模块清单、场景适配记录和例外审批，而不是仅以产品规格书代替。 [1]

第 7 章对外部连接、远程控制、第三方应用、车端外部接口、车端与云平台/车端/路侧单元等通信提出安全要求。证书系统应能够证明指令发起者、设备和服务端的身份，并支持授权、撤销、状态校验和日志关联。远程控制命令应具备真实性和完整性保护，安全日志应覆盖命令、身份、时间、发送主体与结果。 [1]

3.2 UN R155：将密钥与证书控制纳入 CSMS 的生命周期治理

UN R155 的重点不是规定单一 PKI 形态，而是要求制造商通过 CSMS 管理全生命周期网络安全风险。CSMS 应覆盖风险识别、评估、分类和处置，测试，攻击/威胁/漏洞监测与响应，以及供应商和服务提供商依赖关系。该法规要求监测持续进行，并具备从车辆数据与日志分析、检测威胁、漏洞和攻击的能力。 [3]

对 KMS/PKI 选型而言，R155 的关键是证据可用性：系统必须能关联“密钥/证书—车辆或 ECU—供应商—用途—算法—有效期—审批—状态—操作日志”。附录 5 直接列出密码密钥提取、短密钥与长有效期组合、密码算法不足或弃用、开发证书或口令残留、身份欺诈和未授权修改等威胁。选型应对这些风险给出控制而非仅提供加密功能。 [3]

3.3 UN R156：把代码签名、版本保护与失败恢复串成闭环

UN R156 要求软件更新的真实性和完整性受到保护，以合理防止更新被攻破或无效更新。RXSWIN 或软件版本应唯一可识别、可标准化读取并防止未授权修改。OTA 还应处理更新中断或失败时的回滚或安全状态、足够供电、执行前置条件以及用户告知。

因此，生产代码签名私钥应驻留 HSM；签名调用应受发布审批和用途限制；OTA 平台应在分发前校验发布者证书、状态和目标策略；车辆应验证签名、信任链、包摘要、版本、目标 ECU 和前置条件。更新结果、回滚和异常原因应回传至证据面。

图 2　OTA 更新的签名、验证与证据链（示意）

3.4 CRA：先完成范围判定，再导入产品与漏洞处理要求

CRA 的横向要求包括风险驱动安全、默认安全配置、认证/身份或访问管理、静态和传输数据保密性、数据/命令/程序/配置完整性、最小攻击面和安全相关活动记录。其漏洞处理部分还要求识别漏洞与组件、SBOM、及时修复、安全更新、定期测试、协调漏洞披露以及安全分发更新机制。 [5]

但 CRA Article 2(2)(c) 对适用 Regulation (EU) 2019/2144 的数字元素产品设有排除。因而整车项目不应把 CRA 误作为 R155/R156 的重复型式批准清单。独立售卖的诊断设备、后装设备、独立软件或远程处理组件则应建立逐项范围判定档案。CRA 的整体适用自 2027 年 12 月 11 日开始，Article 14 的有关义务自 2026 年 9 月 11 日开始适用。 [5]

4. 选型路径：先定控制边界，再选产品形态

推荐的选型路径从范围和监管判定开始，而不是从厂商功能清单开始。第一步应确定车型、目标市场、是否涉及独立数字产品、软件支持期和供应链责任。第二步将 GB 44495、R155、R156 及适用时的 CRA 要求收敛为统一控制基线。第三步依据根信任强度、设备身份规模和多云/数据加密需要，将能力拆分为根 CA/HSM、证书生命周期服务和企业 KMS 三条选型轨道。

图 3　KMS / PKI 选型路径与 POC 定标流程（示意）

决策问题	推荐路径	典型采购/建设边界
是否承载根 CA、OTA 生产签名或高危诊断授权？	选择离线根 CA、专用 HSM、双人双控和密钥仪式。	可采购 HSM、CA/签名服务与托管实施，但根密钥治理、仪式、审批策略和备份演练责任应保留在 OEM/受控主体。
是否需要百万级设备身份、频繁轮换或多品牌隔离？	选择高可用 Issuing CA、RA、CLM 与状态服务，并以 API 自动化接入制造、云、售后和车辆。	优先验证批量注册、证书策略隔离、短生命周期证书、吊销传播和故障切换。
是否需要多云密钥、数据加密和应用工作负载密钥？	选择企业 KMS 作为策略、审计、轮换与密钥版本控制面；云 KMS 作为受控密钥域。	避免将每一个云服务的默认 KMS 直接当作集团根信任；预留跨云密钥治理和迁移接口。
是否需要 OTA 和软件供应链闭环？	将代码签名服务、证书状态校验、OTA 编排和车端验签纳入同一发布控制面。	验证 HSM 签名接口、签名并发、发布审批、离线恢复、版本/哈希证据与回滚语义。

5. 评估框架与 POC 验收门槛

建议采用“硬性门槛 + 加权评分”的方式进行定标。未满足硬性门槛的候选方案不进入商业评分。加权评分用于比较满足门槛后的差异，而不应掩盖关键控制缺失。

维度	权重	验收关注点
硬性门槛（不计分）	淘汰制	生产签名/根密钥 HSM 保护；私钥不可导出；职责分离与双人双控；全量审计；API 集成；HA/DR；支持证书吊销与状态；可导出证据。
密钥保证与信任治理	30%	HSM 认证/接口、密钥层级、M of N、备份恢复、密钥仪式、权限模型和异常访问检测。
证书与身份生命周期	20%	设备/ECU/服务/诊断身份模型、RA、自动签发、轮换、吊销、状态服务、证书模板和多租户隔离。
OTA 与软件供应链集成	15%	代码签名、发布审批、版本/哈希绑定、车端验签、回滚证据、CI/CD 与 OTA 接口。
合规证据与运营韧性	20%	审计导出、保留策略、SIEM、TARA/SBOM 关联、供应商审计、HA/DR 演练与可观测性。
集成与商业可持续性	15%	本地化部署、接口兼容、迁移工具、退出机制、专业服务能力、三年 TCO 与支持期。

POC 应覆盖的最小闭环

·在 HSM 中生成并保护一把生产签名私钥，确认私钥不可导出，且签名调用必须经过审批与角色分离。

·为模拟车辆、ECU、诊断工具和云服务签发不同策略证书，验证注册、自动轮换、吊销、CRL/OCSP 或替代状态机制。

·执行一次带有版本、摘要和目标 ECU 约束的 OTA 发布，并验证车端验签、证书状态、前置条件、失败回滚或安全状态。

·导出密钥生命周期、证书生命周期、管理员操作、签名、发布和车端回执日志，验证可以按车辆、ECU、供应商和版本进行关联。

·演练 HSM 节点、CA 节点或状态服务故障，以及证书批量吊销、密钥轮换和恢复，记录 RTO/RPO 与残余风险。

6. 推荐的分阶段实施路线图

阶段	主要工作	关键交付物
0–8 周：范围与基线	法规适用清单、TARA 对齐、资产与身份盘点、算法/参数基线、供应商责任矩阵。	控制矩阵；密钥/证书/算法台账初版；CRA 范围判定；目标架构与 RACI。
9–16 周：核心能力与 POC	HSM、根 CA、代码签名、Issuing CA/RA/CLM、KMS 策略域与审计接口的 POC。	POC 结果；硬性门槛验收；性能/HA/DR 结果；候选方案评分表。
17–24 周：产品化集成	制造注册、车端信任锚、ECU/网关验签、OTA、诊断、云服务和 SIEM 集成。	证书策略；签名策略；接口规范；运行手册；监测规则；培训记录。
25–36 周：试运行与评估	轮换/吊销、故障恢复、密钥仪式、供应商审计、型式批准证据包与持续改进。	演练报告；合规证据包；供应商评估；残余风险接受记录；上线准入意见。

7. 落地治理要点

系统能力必须对应明确的责任主体。OEM 或其受控实体应拥有根信任、生产签名政策、证书策略、TARA 风险接受、供应商准入、密钥仪式和异常处置的最终决策权。平台供应商可承担软件、基础设施或运维服务，但不应在没有独立监督的情况下同时拥有密钥管理、发布审批和审计删除权限。

证书策略应区分车辆身份、ECU/组件身份、OTA 发布身份、诊断工具身份、云服务身份和供应商工作负载身份。每类身份应定义唯一主体标识、密钥生成位置、算法与曲线/位长、有效期、轮换触发、吊销条件、状态检查方式、日志字段和数据保留要求。对于开发证书、调试接口和测试密钥，应建立到期清理与生产准入检查，以回应 R155 附录 5 的开发残留风险。 [3]

采购条款建议

合同应明确：密钥/证书/日志的归属与可导出性；HSM 固件与补丁责任；安全事件通知时限；状态服务 SLA；备份/恢复演练；接口与数据迁移；第三方组件和漏洞披露；供应商退出时的密钥销毁、证书迁移与审计留存。

结论

面向 GB 44495、UN R155 和 UN R156 的合规选型，最重要的不是单纯“部署一套 CA”或“购买一套 KMS”，而是建立可验证的信任、签名、身份、更新和证据闭环。推荐将离线根 CA、HSM、Issuing CA/RA/CLM、企业 KMS、代码签名、OTA 验签与集中审计作为分层控制面建设。CRA 应在独立数字产品或不受车辆专项法规覆盖的组件上进行范围判定和补充控制，而不应造成对整车型式批准要求的重复解读。