目录

1. 安全启动流程回顾

1.1 TC3xx的安全启动

1.2 RH850的安全启动

1.3 NXP S32K3的安全启动

1.4 小结

2.信任链的问题

3.国产HSM IP的拓展

---

今天接着 汽车信息安全 -- 存到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个步骤：

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

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

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

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

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

HSM内部包含自己Code、Data Flash，可以存储HSW_FW、密钥、车辆\车主敏感信息。

因此理论上，把HSM和ECU主密钥组合共同作为系统信任根是可行的。

3.国产HSM IP的拓展

正是基于这点，目前有很多国产HSM IP进行完善。

例如芯来科技的HSM IP提供了完整的安全启动流程，它们的安全启动中包含两级验证和加载启动，分别为芯片级和系统级两个层级，对应芯片厂商和系统厂商。并且每一级厂商都可以拥有自己的密钥对。

芯片厂商提供BootROM和一级Loader(NSBS固件)，处于HSM系统中。

芯片厂商的公钥用于验签一级Loader(NSBS固件)，系统厂商的公钥用于验签HOST系统的固件程序。整体安全启动流程如下图所示：

BootRom验签NSBS，NSBS验签Host App1、2等，这样看起来很美好，芯片原厂提供整套信息安全解决方案，但是不知道HSM固件供应商如何看待这一块，毕竟“NSBS”才是它们的核心价值所在。

纽创、安谋科技 HSM IP对于安全启动的思路和芯来类似，个人感觉理念大都源于以前IoT的安全启动概念：

做法没有对错，归根结底还是在于整车系统网络安全架构要实现的网络\信息安全目标，通过合理的TARA分析来选择系统的信任根。