2025-12-22 04:21:41 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 文档介绍了汽车MCU基于非对称算法的伪安全启动方案，旨在满足国家强标要求且不增加成本。方案使用公私钥对实现代码签名验证，通过Bootloader验证后续模块的合法性形成信任链。该方案优点是低成本实现安全启动从无到有，缺点是信任根强度不够，非完整安全启动。文章提出可通过将部分Bootloader设置为OTP区域来增强安全性。 综合评分： 88 文章分类： IoT安全,安全建设,解决方案,漏洞分析,安全开发

cover_image

汽车MCU基于非对称算法的伪安全启动方案

谈思实验室

2025年12月15日 18:05 上海

点击上方蓝字谈思实验室

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

概述

随着软件定义汽车理念的普及，汽车上代码量不断膨胀，功能不断智能化，用户体验不断升级。从传统汽车不需要联网，到职能汽车具有联网功能已是标配，汽车触网必将带来更多信息安全问题。汽车的信息安全问题比IT领域更加重要，因为可能危及生命安全。故国家也出台强标《汽车整车信息安全技术要求》（目前还处于征求意见稿），在强标的的9.1.1条提出“车载软件升级系统应具备安全启动的功能，应保护车载软件升级系统的可信根、引导加载程序、系统固件不被篡改，或被篡改后无法正常启动”。

故安全启动功能后续将成为强标的一部分，具有OTA功能的ECU都必须配备。但目前，MCU普遍未实用HSM功能，国内MPU总体支持安全启动。MCU未使用HSM，主要还是出于成本考量，实用HSM将带来物料成本和HSM协议栈成本。因此综合考量后，可以先解决有无问题，后续再解决好坏问题。在不增加额外成本的场景下，先解决有无问题，故提出一个基于非对称加密算法、信任链不完整的安全启动方案。

安全启动概念

安全启动是通过一项技术，确保按照固定顺序，运行经过验证后的代码，确保不会存在模块被绕过以及不会运行不合法的代码。通过此技术，可确保攻击者篡改任何ECU代码或者重新刷入非法代码都会被识别，且可以直接限制ECU启动。安全启动涉及如下概念：

验证：一个检查过程，检查即将运行的代码是否为官方发布。为实现验证过程，需引入密码学算法，当官方发布软件包时，通过该算法计算出当前软件包的一个特定值，并将该特定值和软件包一起写入到ECU FLASH中。启动时，实时计算出软件包特征值，并和已写入FLASH的特征值对比。若两者一致，则软件包合法，否则不合法安全启动。
信任根：上述认证过程同样需通过代码实现，若攻击者可修改验证过程代码，则依然可绕过验证过程或篡改验证结果。故此时需要有一个攻击者完全无法修改的代码，来验证上述的认证代码，确保上述验证代码无法被修改。这个攻击者完全无法修改的代码即可理解为信任根，信任根是一致认为无法被篡改的一段代码，通常通过硬件实现，例如芯片的bootROM，bootROM是固化在芯片内的一段代码，芯片一旦制造完成，bootROM就用于无法被更改。
信任链：一个ECU的软件基本会分为多个部分，例如bootloader，app等，以信任根为起点，通过不断实现一级一级的验证，从而形成信任链，确保各模块认证的有效性。例如bootROM认证bootloader，bootloader认证app。

安全启动方案

3.1 根证书

安全启动采用非对称算法，可使用RS或ECC算法，生成一对公私钥。公私钥用途如下：

私钥：用于签名，在刷写前，对即将发布的镜像计算HASH值，并通过私钥对HASH值进行签名，得到签名信息。
公钥：用于验签，当安全启动工作时，通过对签名信息使用公钥验签，还原出发布时镜像的HASH值，用于后续比对HASH值是否正确。

3.2 存储空间

假定一个ECU软件包包括三部分，分别为BootLoader、APP1、APP2，则该软件包刷写到ECU FLASH中应是如下示例：

在原始镜像基础上，增加针对该镜像的签名信息，并将原始镜像和签名信息一同刷写到FLASH中。

3.3 刷写前准备

当进行软件刷写前，需先计算各模块的签名信息。计算签名信息流程如下：

基于原始镜像，使用HASH算法（例如SHA-256），得到该镜像的HASH值。
使用之前生成的私钥对HASH值进行签名，输出即为原始镜像的签名信息。

当进行刷写时，需将原始镜像和签名信息一并刷写到FLASH中。例如参考3.2中示例，将BootLoader原始镜像和Bootloader签名信息刷写到BootLoader区域，将APP1原始镜像和APP1签名信息刷写到APP1区域。签名信息在各自区域存放的位置，可由开发人员自行定义，只需保障启动时，可准确读取到签名信息即可。

将安全启动证书/公钥刷写到FLASH中，且将证书/公钥的HASH值保存到OTP中。

3.4 安全启动流程

3.4.1 总体安全启动流程

bootrom后跳转到Bootloader，在Bootloader中验证根证书、bootloader自身、下一个启动模块的合法性。
启动bootloader下一个模块（例如APP1），在此模块中，验证后续启动模块的合法性。按照在当前模块中验证下一模块合法性，验证通过后，则继续启动下一模块的链路验证下去，直到所有模块都验证结束。
若验证失败，则跳转到启动失败处理流程：记录失败原因和失败次数到FLASH中，进行软件reset。

3.4.2 安全启动流程实例

假定一个ECU软件包包括三部分，分别为BootLoader、APP1、APP2。则启动过程如上图所示，具体流程如下：

上电后，执行芯片bootrom后，跳转到bootloader。首先读取DFLASH中失败次数，若失败次数大于N此（通常为3），则启动失败，停留在PBL中或提供有限功能（具体应依据项目需求设计）。若小于N，则继续启动流程；
读取安全启动根证书/公钥，计算HASH值（称为CERT-HASH-1），并读取OTP中保存的HASH值（称为CERT-HASH-2），比较CERT-HASH-1和CERT-HASH-2值是否相等，若相等，则根证书/公钥未被篡改，继续启动流程。若不相等，则启动失败，记录失败原因和次数到FLASH中，并进行reset，跳转到步骤1中；
随后读取Bootloader镜像并计算镜像的HASH值（称为BOOTLOADER-HASH-1）。读取bootloader的签名信息，并通过根证书/公钥验签bootloader的签名信息，得到签名信息中包含的HASH值（称为BOOTLOADER-HASH-2）。比较BOOTLOADER-HASH-1和BOOTLOADER-HASH-2值是否相等，若相等，则证明Bootloader未被篡改，继续启动流程。若不相等，则启动失败，记录失败原因和次数到FLASH中，并进行reset，跳转到步骤1中；
读取APP1镜像并计算镜像的HASH值（称为APP1-HASH-1）。读取APP1的签名信息，并通过根证书/公钥验签APP1的签名信息，得到签名信息中包含的HASH值（称为APP1-HASH-2）。比较APP1-HASH-1和APP1-HASH-2值是否相等，若相等，则证明APP1未被篡改，继续启动流程。若不相等，则启动失败，记录失败原因和次数到FLASH中，并进行reset，跳转到步骤1中；
跳转到APP1中。读取APP2镜像并计算镜像的HASH值（称为APP2-HASH-1）。读取APP2的签名信息，并通过根证书/公钥验签APP2的签名信息，得到签名信息中包含的HASH值（称为APP2-HASH-2）。比较APP2-HASH-1和APP2-HASH-2值是否相等，若相等，则证明APP2未被篡改，继续启动流程。若不相等，则启动失败，记录失败原因和次数到FLASH中，并进行reset，跳转到步骤1中；
跳转到APP2中。若有其他模块启动，则继续按照信任链一步一步进行验证。若无其他模块，则安全启动完成。

3.5 安全启动耗时

安全启动相较于普通启动，增加相应的流程，必然会带来安全启动时间的增加。基于在infineon TC377和TI AWR 2944经验，不借助硬件加速，耗时估算如下：

HASH使用SHA256：4K/1ms
签名验签：9ms 总体来说，耗时主要在对各模块计算HASH中，如APP有4M，则耗时将达到1S。

3.5.1 优化

针对HASH耗时较大，若芯片支持硬件CRC加速，可先计算镜像的CRC，然后对CRC进行签名。基于目前经验，硬件CRC速度约为70K/s，速度提升快20倍。以4M模块计算，使用硬件CRC耗时约58ms，使用软件HASH则耗时1000ms。

使用CRC碰撞概率远大于HASH（SHA-256）碰撞概率，故使用CRC可提升安全启动速度，但同步会带来安全性减弱。

方案总结

4.1 优点

在不大量增加成本的情况下，实现安全启动从无到有。使用当前方案，不需要使用支持HSM的芯片，不需要额外购买HSM协议栈，即可实现具有安全启动。

4.2 缺点

不是完整的安全启动。当前方案以BootLoader为信任根，而不是以不可更改代码为信任根。导致攻击者可修改BootLoader即可绕过安全启动的验证过程。

4.2.1 缺点完善

当前缺点为bootloader不是不可更改的区域，作为信任根强度不够。为提升强度，可限制对Bootloader的修改，例如：不允许刷写bootloader、禁用JTAG等调试口等措施。

思考

以上方案因缺少一个不可更改的信任根，总体上仍存在安全缺陷。但有些芯片支持将code Flash的部分区域整个设置成OTP，例如infineon的TC3XX、瑞萨的RH850等。若芯片支持设置code flash为OTP，理论上可以不适用HSM实现一个不可更改的信任根。思路如下：

将Bootloader拆分为2段PBL1和PBL2。其中PBL1校验PBL2，并将PBL1设置为OTP。PBL1验证PBL2通过后，启动PBL2，在PBL2中校验后续APP。因PBL1所在的code Flash在产线会设置成OTP，故PBL1可当做一个不可更改的信任根使用，达到类似Bootrom的效果

来源：CSDN@辛勤搬砖的门卫

https://blog.csdn.net/anjiyufei/article/details/135285857

谈思-汽车出海安全合规（欧洲）

交流群

谈思 AutoSec Europe 峰会旨在搭建一个能融汇全球视野与中国实践、连接技术前沿与落地应用的国际性专业平台，以助力中国汽车应对在出海过程中面临的网络与数据安全合规痛点。从前沿技术研讨、合规要点解析到经验交流，都将通过本平台为您提供持续支持。社群已超过200人，需邀请加入，如需入群，欢迎添加社群小助手微信taaslabs01。