HSM 硬件安全模块
CRA、ISO/SAE 21434 与 UN R155 合规解读
面向 HSM 产品分类、密码边界、车端部署、验证与 CSMS 证据的实施路线
适用对象 |
HSM 产品团队、芯片/ECU 团队、车企网络安全团队、PKI/OTA 团队、制造安全团队、法规与质量负责人。 |
封面图：HSM 作为车端—云端密钥体系的硬件信任锚点
编制日期：2026 年 10 月 12 日
管理层摘要 HSM 是密码信任锚点，但不是整体合规的替身
HSM 是保护和管理加密密钥、并提供密码处理的物理计算设备。NIST 的定义还强调其可提供防篡改证据与入侵抵抗。[6] 在汽车系统中，HSM 常被用于保护根信任、代码签名、设备身份、证书私钥、对称密钥和安全启动/OTA 的关键密码操作。其核心价值是让高价值私钥不必暴露给通用操作系统、应用进程、开发工作站或普通数据库。
但 HSM 不能单独“满足” CRA、ISO/SAE 21434 或 UN R155。CRA 关注进入其范围产品的安全设计、技术文件、支持期和漏洞处理；ISO/SAE 21434 要求以生命周期工程管理车辆 E/E 网络安全风险；UN R155 则要求制造商建立 CSMS 并证明整车型式的风险、缓解、测试和持续监测。HSM 是这些体系的重要安全控制与证据来源，而不是把责任转移给模块供应商的工具。
关键结论 |
单独投放欧盟市场、且核心功能符合“Hardware Devices with Security Boxes”技术描述的 HSM，应按 CRA 关键产品路径规划；嵌入车端的 HSM 则应作为整车 TARA、CSMS、供应链和验证的一部分接受评估。 |
一 HSM 的 CRA 定位与产品边界
Commission Implementing Regulation (EU) 2025/2392 的附件 II 将“Hardware Devices with Security Boxes”描述为：安全存储、处理或管理敏感数据或执行密码运算的硬件产品，包含多个离散组件，并通过物理封装提供防篡改证据、抵抗或响应。该描述明确列举“生成和管理加密要素的 HSM”。[2] 因而，对于在欧盟单独投放且具备该核心功能的 HSM，项目计划应预设 CRA 关键产品的严格合格评定需求，并确认适用的第三方评定或欧盟网络安全认证路径。
在车辆项目中还需要区分：受 Regulation (EU) 2019/2144 规管的车辆/系统可能不适用 CRA；但这不意味着 HSM 的安全性不再重要。其物理保护、固件、管理接口、密钥保护、日志、供应链与漏洞响应会直接影响 UN R155 的车型风险评估、缓解措施、测试与持续监测。
图 1 HSM 的单独投放与车端集成决定 CRA、ISO/SAE 21434、UN R155 的适用组合
二 HSM 安全边界：把密钥、固件、接口和物理保障放进同一模型
评估 HSM 不应只看“是否支持某种算法”或“是否有防拆外壳”。必须同时审视外部调用面、管理平面、业务平面、角色权限、固件信任链、敏感安全参数、备份恢复、异常处置和证据输出。特别是远程管理接口、初始化/密钥仪式、管理员令牌、分区配置和固件升级，通常具有比单次密码运算更高的系统性风险。
图 2 HSM 的调用、授权、密码执行、物理保障与证据边界
层面 |
必须评估的关键问题 |
典型证据 |
密码与密钥 |
私钥是否在 HSM 中生成/受控导入？是否不可导出？密钥用途是否隔离？ |
密钥策略、分区配置、密钥仪式、调用审计、导出禁止测试。 |
固件与平台 |
固件是否签名验证？是否可防回滚？自检、零化和异常状态如何处理？ |
固件信任链、版本清单、升级记录、自检结果、故障注入测试。 |
接口与权限 |
管理接口与业务接口是否隔离？是否有强认证、最小权限、双人控制？ |
角色矩阵、访问策略、管理日志、权限复核、越权负向测试。 |
物理与运维 |
物理篡改、维修、返厂、备份/恢复、报废和更换如何受控？ |
现场流程、封存/交接记录、恢复演练、报废零化证明。 |
供应链与支持 |
固件/驱动/中间件依赖是否透明？漏洞通知和支持期是否明确？ |
SBOM、供应商 SLA、CVE 处置记录、支持期与补丁记录。 |
三 HSM 如何服务 ISO/SAE 21434 与 UN R155
ISO/SAE 21434 覆盖道路车辆 E/E 系统从概念、开发到生产、运行、维护和退役的网络安全风险管理。[4] HSM 需求应源自整车或 ECU 的 TARA，例如：攻击者伪造 OTA 更新、提取 ECU 身份私钥、绕过安全启动、滥用诊断授权，或通过供应链固件更新引入后门。每个 HSM 功能都应链接到相应威胁、网络安全目标、需求、实现、测试和残余风险。
UN R155 规定 CSMS 应覆盖开发、生产和后生产阶段，并要求制造商管理供应商相关风险，识别关键元素，进行全面风险评估，实施相称缓解并在型式批准前验证安全措施有效。R155 还要求密码模块符合共识标准；若不符合，制造商需要为其使用提供理由。[3] 因此，HSM 供应商资料必须被整车团队吸收为可审核的车型证据，而不是停留在供应商证书或营销资料。
图 3 HSM 在离线根信任、在线签名、工厂注入和车端 ECU 中的分层部署
四 HSM 的 CRA、ISO/SAE 21434、UN R155 控制映射
控制主题 |
CRA 侧重点 |
汽车工程与 R155 落地 |
HSM 实施与证据 |
产品分类与评定 |
单独投放 HSM 可能为关键产品；需要严谨分类、合格评定和技术文件。 |
嵌入车端时，纳入 ECU/整车产品范围和供应链风险。 |
技术描述匹配、产品架构、评定计划、配置/版本控制。 |
安全设计 |
风险驱动的产品属性安全要求；漏洞处理覆盖支持期。 |
TARA 驱动安全目标；验证 HSM 是否降低具体攻击路径。 |
不可导出、密钥用途隔离、固件签名、自检、最小接口。 |
供应链 |
集成组件尽职调查，技术文件持续更新。 |
R155 管理供应商依赖和车型供应商风险。 |
HSM/驱动/中间件 SBOM、SLA、变更/漏洞通知、源代码或补丁保障。 |
测试与有效性 |
符合性证据应可复核。 |
R155 要求批准前充分测试和安全措施有效性验证。 |
篡改/越权/导出/回滚/故障恢复测试、渗透测试、修复复测。 |
运行与响应 |
支持期漏洞处置和适用报告。 |
持续监测、检测、响应、有效性复评与报告。 |
管理与业务审计、告警、固件补丁、密钥吊销/轮换、事件剧本。 |
五 模块选择与验证：认证可作为证据，不能代替整机/整车论证
FIPS 140-3 覆盖密码模块规格、接口、角色/服务/认证、软件/固件安全、物理安全、敏感安全参数管理、自检、生命周期保证以及其他攻击缓解等安全要求领域，并定义递增的安全级别。[7] 因此，FIPS 140-3 验证或类似独立评估可作为 HSM 选型和模块保证的有力证据。它仍不能代替实际产品的接口配置、固件版本、部署环境、KMS 策略、整车 TARA、供应链和运行响应的验证。
测试层次 |
测试要点 |
期望证据 |
模块与固件 |
安全启动、签名校验、自检、错误状态、零化、固件回滚/升级。 |
版本清单、供应商报告、负向测试、固件升级与回滚记录。 |
密钥与密码操作 |
生成、导入、包装、不可导出、用途隔离、算法与密钥长度策略。 |
密钥策略、功能用例、导出失败证据、配置快照。 |
权限与接口 |
管理员角色、双人控制、管理/业务接口隔离、会话/令牌、速率限制。 |
权限矩阵、渗透测试、越权测试、审计日志样本。 |
物理与运维 |
机房/工厂/车端环境、维修更换、备份恢复、失效模式和报废。 |
运维规程、交接记录、灾备/恢复演练、零化证明。 |
系统与整车 |
安全启动、OTA、设备身份、诊断、车云认证以及异常检测联动。 |
TARA 追溯、集成测试、攻击场景测试、CSMS 运行记录。 |
六 HSM 产品与车端部署的实施路线
阶段 |
主要动作 |
成果 |
0—30 天 |
确定 HSM 是独立投放产品还是车端组件；盘点接口、固件、驱动、密钥类型和供应商。 |
范围/分类结论、系统边界、HSM 资产清单、初步风险与差距。 |
31—60 天 |
定义产品安全需求与硬件/固件信任链；建立角色、密钥、更新、备份和物理运维控制。 |
HSM 安全架构、配置基线、密钥仪式、供应商安全条款。 |
61—90 天 |
将 HSM 接入安全启动、OTA、设备身份或工厂注入试点；开展负向与故障测试。 |
端到端测试、攻击测试、恢复演练、修复记录。 |
91—120 天 |
准备 CRA 技术文件或整车 CSMS 工作产品；建立漏洞、固件、供应商与支持期运行机制。 |
可审计证据包、发布门禁、监测/响应剧本、运营 KPI。 |
审核提示 |
审核者会问：“为什么这个 HSM 的防护级别适合该车型风险？”“HSM 固件 CVE 出现后，哪些车型/ECU 受影响？”“根密钥或代码签名密钥失陷时如何阻断？”准备答案的关键是可追溯 TARA、配置、测试、日志和响应证据。 |
使用边界 HSM 认证、HSM 采购与法规符合性之间不能画等号
HSM 的独立认证、FIPS 140-3 证书、Common Criteria 评估、供应商合规承诺或芯片安全白皮书都只能作为一部分证据。对于 CRA，需要面向具体 HSM 产品判断范围、分类和合格评定；对于 ISO/SAE 21434 与 UN R155，需要证明 HSM 控制在整车风险、CSMS、供应商管理、测试和持续运行中真实有效。
