新能源汽车上云安全：车规MCU内置HSM的可行性分析

新能源汽车上云安全：车规MCU内置HSM的可行性分析

一句话总结

当车规MCU内置的HSM已通过商用密码产品认证，GB/T 32960上云签名这一任务，可以由MCU兼任——在满足认证与项目要求的前提下，无需额外配置独立安全芯片。

  
三个关键支撑点：✅ 商用密码二级认证 ✅ 国密SM2/3/4/9硬件加速 ✅ 私钥始终保留在HSM内部

  
新能源汽车每日向云端上传运行状态、动力电池、位置及报警等数据。这些数据是否能被可信识别、是否在传输前被篡改、签名私钥是否真正受到保护，已不仅是云平台的问题，更是车端电子电气架构必须面对的挑战。

  
在典型的座舱或融合平台中，系统通常由高性能应用SoC、通信模组和一颗车规MCU组成。为满足上云数据的安全要求，部分方案会额外引入独立安全芯片。

  
但如果MCU本身已集成HSM，具备硬件密码加速、唯一标识和安全密钥存储能力，并符合商用密码产品认证要求，是否可以由MCU承担上云数据的安全处理任务，从而省去额外的安全芯片？

  
芯驰科技的答案是：可以评估，并提供了两种可行的技术路径。

标准解读：关注的是安全能力，而非芯片形态

GB/T 32960是一组面向电动汽车远程服务与管理系统的标准体系。其中，GB/T 32960.2-2025针对车载终端，要求其配备具备硬件安全保护机制的汽车芯片。

  
具体要求包括：

• 具备唯一的芯片标识ID；
• 能够安全存储芯片ID和密钥，芯片ID与公钥可读取，私钥不可读、不可改；
• 安全等级满足GM/T 0008二级要求，或产品安全保证级别不低于EAL4+，或符合汽车芯片信息安全相关国家标准；
• 密钥长度不低于256 bit；
• 具备安全策略和漏洞处置能力，保障数据存储安全。

  
GB/T 32960.3-2025则聚焦通信协议和数据格式，新增了平台间、车载终端与平台间的通信安全要求，以及签名信息、数据单元加密密钥交换等内容。

  
标准强调的是“唯一身份、密钥保护、密码运算和签名验证”构成的能力链，而非强制要求使用独立安全芯片。

  
这为整车电子架构提供了优化空间：当MCU已具备合格的硬件安全能力时，可将其从单纯的控制单元升级为上云链路的可信根。

外挂安全芯片的成本不止于芯片本身

典型座舱或融合控制器通常采用“应用SoC + 车规MCU”的架构：

• 应用SoC或5G模组负责数据汇聚、协议封装、通信连接和云端交互；
• MCU负责电源管理、状态监控和高可靠实时控制；
• 独立安全芯片负责设备身份、密钥保存和签名运算。

  
独立安全芯片虽功能明确，但也会带来一系列额外成本：

• 直接BOM成本：安全芯片本体及其电源、时钟、阻容等外围器件；
• PCB资源：器件面积、接口走线和布局约束；
• 软件开发：驱动、协议适配、异常恢复和诊断接口；
• 生产部署：密钥注入、证书绑定、工装改造和产线测试；
• 供应链管理：新增物料、交期、版本和生命周期管理；
• 安全边界：SoC、MCU、安全芯片之间每增加一条接口，就增加一处需要认证、防重放和故障处理的边界。

  
因此，“省去一颗芯片”的价值远不止降低器件成本。它还可能减少外围物料、PCB面积、软件适配工作、生产工位和系统故障点。

芯驰方案：E3 MCU内置HSM承担安全服务

芯驰E3高性能车规MCU内置独立的信息安全处理能力和高性能HSM，支持SM2、SM3、SM4、SM9等国密算法硬件加速，并兼容RSA、SHA、AES、ECC等主流密码算法。E3 MCU已通过商用密码产品二级认证。

  
在上云系统中，各芯片可按如下方式分工：

• 应用SoC / 5G模组：采集车辆数据，完成业务逻辑、报文封装、网络协议和云端通信；
• E3 MCU主核：负责车身控制、系统管理、诊断、通信及安全服务调度；
• E3 MCU HSM：负责设备唯一身份、密钥生成与保护、摘要计算、签名和安全状态管理；
• 云端平台：根据芯片ID和公钥完成身份识别、验签和数据可信性判断。

  
核心在于：不是“让MCU替代SoC上云”，而是让MCU成为SoC可调用的车规级安全服务节点：复杂网络协议仍由SoC或通信模组处理，最敏感的私钥和签名运算则保留在MCU的硬件安全边界内。

方案一：完整报文进入MCU，HSM完成摘要与签名

方案优势

• 摘要和签名均在MCU安全边界内完成，信任链更直观；
• 外部SoC无需管理复杂的密码计算细节；
• HSM可直接控制“哪些数据可被签名”；
• 便于实现统一的访问控制、调用审计、频率限制和错误处理；
• 适用于新平台、报文长度可控、对安全边界要求较高的项目。

运行流程

1. 设备初始化

• MCU读取硬件UID；
• HSM生成设备密钥对；
• 公钥可导出并在T-Box或云端备案；
• 私钥始终处于HSM保护链路中，不以明文形式离开安全边界。

2. 业务数据生成

• 应用SoC或T-Box采集车辆运行数据；
• 按GB/T 32960协议要求完成业务报文组包。

3. 数据送入MCU

• SoC/T-Box通过SPI等车内接口将待签名数据发送给MCU；
• MCU对接口命令、数据长度、会话状态和超时进行校验。

4. HSM完成密码运算

• HSM对报文执行SHA-256等选定的摘要算法；
• 使用RSA或SM2私钥完成签名；
• 私钥仅在HSM内部调用，外部SoC无法读取。

5. 签名结果回传

• MCU返回签名值、签名长度和对应芯片身份信息；
• T-Box将原始业务数据与签名信息一起上传；
• 云平台使用备案公钥进行验签。

工程注意点

完整报文需在SoC/T-Box与MCU之间传输，需提前评估：

• SPI等接口带宽与峰值负载；
• 报文分片、重组和长度校验；
• MCU重启或掉电时的事务恢复。

方案二：SoC/5G模组预计算摘要，MCU HSM专注签名

方案优势

• MCU接收的数据量从完整报文缩减为固定长度摘要；
• 显著降低SoC/5G模组与MCU之间的通信占用；
• HSM专注密钥保护和签名运算，适合高频数据上报；
• 对既有T-Box软件改造相对集中，便于复用SoC侧数据处理能力；
• 更适用于报文较大、带宽敏感或多业务共享HSM的融合平台。

当上云报文较大、上传频率较高，或SoC与MCU之间通信带宽有限时，可将摘要计算放在应用SoC或5G模组中，仅将固定长度的摘要发送给MCU签名。

设备初始化与信息备案

• MCU获取硬件UID，并按项目规则映射或组合成标准要求的芯片ID；
• HSM生成公私钥对；
• 公钥可读取并交由T-Box、5G模组或云平台备案；
• 私钥由HSM的设备根密钥和密钥保护链进行封装，仅以密文形式存储；
• MCU根据项目定义的用户标识计算签名所需的身份摘要ZA，并将ZA提供给5G模组缓存。

需特别注意：MCU的硬件UID与GB/T 32960定义的芯片ID并非天然等同。前者可作为唯一身份根，最终芯片ID的编码、长度和映射方式仍需依据标准及整车企业规则确定。

运行阶段

• 5G模组获取待上传消息MSG；
• 模组只需将摘要e和必要的业务上下文发送给MCU；
• MCU校验命令、业务类型、流水号和新鲜度信息；
• HSM使用受保护的私钥对摘要执行签名；
• MCU将签名值返回5G模组；
• 模组将消息、签名和芯片ID上传至云端；
• 云平台根据芯片ID找到公钥，重新计算消息摘要，完成验签。

两种方案如何选择？

真正的难点在于密钥的全生命周期管理

上云安全方案能否量产，关键往往不在于“芯片是否支持SM2或RSA”，而在于密钥从生成到销毁的全过程是否可信。芯驰E3 MCU可通过HSM建立分层密钥保护链：

• 设备根密钥固化在OTP/eFuse等受保护区域；
• 存储保护密钥由设备根密钥保护，用于封装业务密钥；
• 业务私钥在HSM内生成，经过保护后支持以密文形式存储在NVM；
• 设备启动后，密钥密文只在HSM内部解封并参与运算；
• 主核、应用SoC、调试接口和普通软件均不接触私钥明文。

  
在量产阶段，还需同步设计：

• 每车一密或每控制器一密的密钥策略；
• 产线安全工位和烧录授权；
• 芯片ID、公钥、VIN与云端账户的绑定；
• 调试口关闭及生命周期状态切换；
• 密钥更新、吊销、换件和售后维修流程；
• 掉电、回滚、刷写失败及异常恢复策略。

只有将芯片、固件、产线、云平台和售后流程串联起来，HSM的硬件能力才能真正转化为整车可验证的安全能力。

从“多一颗安全芯片”到“复用一颗可信MCU”

采用带HSM的车规MCU承担GB/T 32960上云安全服务，可将原本分散在多个器件中的能力收敛到一个可信节点：

• 更低BOM：在满足认证和项目要求的前提下，可评估取消独立安全芯片；
• 更小面积：减少芯片、外围器件和接口走线；
• 更少适配：复用MCU既有通信、诊断、MCAL和安全软件体系；
• 更短链路：减少密钥、摘要和签名在多个器件间流转；
• 更易量产：统一UID、密钥部署、EOL测试和故障诊断；
• 更清晰的安全边界：私钥不离开HSM，SoC只调用受控安全服务。

这正是面向新一代融合电子电气架构，更高集成度所带来的价值：安全能力不再依赖器件堆叠，而是成为系统架构的一部分。

  
芯驰科技面向智能汽车电子电气架构提供车规级SoC与高性能MCU产品，覆盖智能座舱、智能网关和核心车控等应用场景。E3高性能MCU面向新一代智能车核心应用，集成高性能HSM，支持多种国密和国际主流密码算法硬件加速，并提供车规级软件开发套件、MCAL和参考方案支持。