汽车信息安全 -- 再谈车规MCU的安全启动

最新推荐文章于 2025-05-08 21:44:45 发布

CyberSecurity_zhang

最新推荐文章于 2025-05-08 21:44:45 发布

阅读量4.6k

点赞数 26

CC 4.0 BY-SA版权

分类专栏：汽车网络安全管理体系文章标签：汽车网络安全信息安全安全启动

本文链接：https://blog.csdn.net/djkeyzx/article/details/142630563

汽车网络安全管理体系专栏收录该内容

6 篇文章

订阅专栏

今天接着汽车信息安全 -- 存到HSM中的密钥还需包裹吗？-CSDN博客这篇文章深究另一个重要功能-- 安全启动。

该文章的前提是假设有工具能够Dump出所有Flash数据（包含HSM），意味着逆向整个Code就不再那么困难（虽然个人对这个假设还是存疑：毕竟理论上HSM在防篡改上至少可以提供篡改抵抗和篡改留凭这两项基础功能的一个）。

而以目前我们常见的安全启动方式，大都将HSM作为信任锚，由HSM来保证Host侧所有运行软件授信，探测在运行时Host侧软件是否被篡改。

因此，我们首先回顾一下目前市面上常见的HSM固件的安全启动流程。

1. 安全启动流程回顾

不管是ETAS还是VECTOR，在安全启动上均提供了顺序安全启动、并行认证启动、混合启动方式（注意，上述启动流程两家实现基本一致，只是命名不同，这里统一成上述表达）。

顺序启动：又称Secure Boot，它是指上电后HSM成功校验所有Host App后再释放Host内核，很明显这种方式会造成启动变慢；
并行启动：又称Paraller Authenticated Boot，它是指上电后硬件同时释放Host和HSM内核，当HSM在校验Host App时，Host App也在并行运行，当校验失败时，由HSM来决定是否复位整个系统。这种方式虽然提高了系统启动性能，但存在一定的信息安全风险。
混合启动：HSM固件对Host APP不同模块使用顺序\并行启动，这兼顾了启动时间和信息安全。

有趣的是，虽然说HSM在什么时候释放Host基本是由软件策略来决定，但是我们仍然可以从国外MCU大厂对安全启动方式的理解和设计。

1.1 TC3xx的安全启动

TC3xx上电后首先释放TriCore 0，执行它自己的Startup Software(SSW)。

SSW根据HSMBOOTEN是否置位来使能HSM内核，根据SSWWAIT是否置位来决定是否等待HSM Firmware的通知，具体流程如下图所示：

进一步讲，当SSWWAIT这一位使能后，芯片硬件认为安全启动相应地开启，需要等待HSM固件对Host软件校验结果。

由于SSW本身在ROM里，基本不会被篡改，因此这部分代码逻辑默认可信；HSM Firmware可以在任意时刻通知SSW，假设HSM Firmware开始运行就通知，这就是典型的并行启动；如果HSM Firmware将Host所有软件校验完成再通知SSW，这就是严格的顺序安全启动；如果HSM在校验部分Host App模块后通知SSW，这就是混合启动。

因此理论上讲，TC3xx从硬件层面就支持所谓的顺序、并行、混合启动。

1.2 RH850的安全启动

RH850 MCU型号太多了，因此咱们主要以ICU-M（即HSM）来看安全启动。

瑞萨的ICU全称Intelligent Cryptographic Unit，-M代表满足EVITA Medium等级，如下所示：

由于其设计雏形源于HIS SHE，因此安全启动逻辑也基本相似。在ICU-M内部有一个Secure Boot Key 用于校验Host Application。

上电后，ICUP率先复位释放，完成一系列初始化后，进入到ICU Firmware，由该Firmware的安全启动程序对Host Application进行校验，校验完成后有ICUP释放Host Core，逻辑如下图：

值得一提的是，在瑞萨提供的示例中，Program B是由Program A请求ICU-M进行校验。信任链从这个意义上也串了起来。

1.3 NXP S32K3的安全启动

在S32K3的启动流程，硬件复位后同样只有HSE(也就是HSM)子系统可以运行，首先运行sBAF()代码，完成基本环境配置，然后根据IVT(Image Vector table)中BOOT_SEQ来决定是否执行安全启动，如下图：

当BOOT_SEQ = 0时，SBAF忽略掉HSE是否完成校验，直接运行Host App；
当BOOT_SEQ = 1时，SBAF只运行HSE_Firmware，由HSE FW来选择什么时候释放Host Application

基本流程如下图所示：

1.4 小结

可以看到，上述MCU均在自己的信息安全解决方案里考虑了安全启动，可以通过不同配置来选择是否启用安全启动，但是决定权还是在于HSM Firmware在什么时候复位Host软件。

因此，这也给了HSM固件供应商更大的舞台来设计安全启动流程。

例如，我们可以将用户Host Application按用途分成不同类别，比如说Group BootManager、Group AppA、Group AppB；然后在类别里根据启动时序要求拆分成不同的块，对这些块设置不同的启动模式，如下图：

这样就能够兼顾信息安全和OEM启动时间要求。

2.信任链的问题

我们仔细分析上述MCU的启动流程，会发现一个现象：除了S32K3在SBAF里有对HSE_FW进行验证，其余方案均默认HSM FW可信。

但我遇到很多人问过这样一个问题：那你这个启动流程的信任链就是断裂的，从芯片厂商 -> Tier 1 -> OEM这个信任过程没有建立起来。

有朋友以Inter Arria 10 SoC Secure Boot过程为例：

它总共历经3个步骤：

BootRom作为信任根，用于解密、验证BootLoader。验签公钥、对称加密密钥预先存在设备中，完成解密和验证后加载Bootloader运行；
Bootloader主要用于OS运行前的环境配置，包括访问文件系统、外设初始化、配置I\O等等，验签OS作为可选项；
OS运行或者是Bare Metal运行后，特别是需要从Flash copy至ram运行的应用程序，是必须进行验签。

该SoC的安全启动信任链就以上述方式完成。

最初我还是认为这个很有道理，但是仔细分析下来，这个过程通篇没有提到安全隔离，也没有提到任何关于HSM的信息；

再仔细思考，一般这种SoC是不带eFlash(Embedded Flash)，大部分程序都是需要从不同存储介质加载到RAM中运行，因此这些程序是必须要保证完整可信；

但我们现在讨论的车规MCU，都带有内置HSM，天然地从架构上就将MCU划分为安全域和非安全域，