原标题：汽车信息安全--芯片厂、OEM安全启动汇总

目录

1.芯驰E3安全启动

2.STM32 X-CUBE-SBSFU

3.小米澎湃OS安全启动

4.小结

我在前篇文章里详细记录了车规MCU信息安全设计过程关于网络安全架构的思考过程，从芯片原厂、供应商、OEM等角度思考如何建立起完备的信任链；

不过这思考过程仅仅只是一家之言，因此我又对比了国内外芯片厂、OEM等对于安全启动的方案设计，并进行总结。

首先回顾一下安全启动的定义：

• 安全启动是在系统启动过程中，验证程序或数据的签名，确保程序数据的完整和可信，以防止在启动过程中加载并运行了未经授权的程序。

• 在安全启动机制下，所有启动文件（如：启动引导程序、内核镜像、固件）均需先通过签名校验才被允许加载运行。

• 在启动的任何阶段，如果签名验证失败，则启动过程会被终止

接下来看下几家比较典型的MCU安全启动方案。

1. 芯驰E3安全启动

芯驰是国内车规MCU发展势头最猛的芯片厂之一，分析并跟随头部是快速提高的方法之一。

芯片E3系列是满足ASIL-D的高性能车规MCU，可用于汽车中央网关、域控、BMS等领域；它不仅有最高等级的功能安全，还在信息安全方面也提供了完整的软硬件解决方案。

下图为E3的信息安全硬件框架：

可以看到，从硬件层面上，E3已经考虑到了信息安全当前比较主流的功能：

• BootRom：实现部分安全启动功能；

• HSM：MCU内置硬件安全模块，提供加解密服务、物理主动防护和传感器模块，可有效防止硬件攻击；

• eFuse Ctrl：OTP，控制敏感信息的访问权限；

• LifeCycle Management：产品信息安全生命周期管理，涵盖从出厂到报废；

• Secure Debug：在产品量产后可被安全调试的接口管理；

• Secure Storage：提供片内隐私数据、敏感数据等临时存储；

• IDS：硬件入侵检测机制

从软件上，E3也提供了相应的配套解决方案，如下：

我们知道由于芯驰本身的公司属性，量产MCU目前还是不带eFlash，所以常见的启动方式就与需要外挂Flash的MPU、SoC等类似，主要分为XSPI NOR/Hyper/NAND Flash、SD、eMMC、USB等方式，具体整理如下：

而这种外挂Flash更容易受到信息安全威胁，因此为了提高MCU的信息安全，在启动阶段实现安全启动是十分必要的。

芯驰E3采用了目前SoC常见的安全启动流程，如下图：

需要明确的是，一个安全启动系统必须首先建立信任根；

• BootRom因其难以被篡改的属性通常会被作为信任根的一部分，它主要对接下来要运行的images做验签、解压（如有）和加载运行；

• 信任根的完备也需要根密钥对来补充；

• 一般来讲，芯片厂会在一个可信安全环境里(例如芯片厂发布的可信网站、exe等)生成根密钥对，并将公钥固化到密码加速引擎或者OTP；

• 私钥用于签名，公钥被BootRom用于验签，具体如下：

那么具体到E3，它是如何设计安全启动流程的呢？

这里先澄清几个E3芯片独有的概念：

1.程序烧录

编译的.bin文件通过芯驰独有签名工具签名后形成BootPackage，打包PAC文件后烧录

2.Boot Package格式：BPT + Images

BPT：Boot Package Table，它包括Boot Package的签名信息，各个镜像在Images中的相对位置，镜像load地址，entry地址，hash校验信息，PSN(Package序列号)等信息;

Images：各内核镜像、SF核Bootloader镜像等，根据启动介质不同，BootPackage个数也不同，最多可以支持3个。

其格式简图如下：

E3具体启动流程如下：

1. 量产时，先对images取Hash，再用私钥签名；签名结果、images以及公钥打包成pac烧写进Flash；此外还需要把公钥取Hash，并把Hash烧录到eFuse中的ROTPK1(Root Of Trust Public Key)；最后把芯片的生命周期烧写至PD阶段；

2. 启动时BootROM首先计算 BPT中的公钥哈希值，与eFuse中的ROTPK1 Hash进行比对，验证公钥的合法性，如果不一致则启动失败；

3. 公钥验证通过后，使用BPT中存储的公钥验证BPT中的签名(Sign)，验签不通过则启动失败；

4. 计算各个镜像文件的哈希值(Image Hash)，如果一致则启动对应的镜像，不一致则启动失败；

5. 如果Image是被加密的，通常还需要使用对称算法进行解密。

2. STM32 X-CUBE-SBSFU

该产品全称Secure Boot and Secure Firmware Update Solution，主要用于STM32相关控制器的安全启动、安全更新和安全密钥管理。

其中安全启动用于程序镜像运行前校验合法性；安全更新用于固件的OTA或者本地升级，可防回滚和分区升级；安全密钥管理通过PKCS#11 API提供各种密码密钥服务。

经过总结，我发现该产品的安全启动过程大同小异，具体如下：

可以看到，该安全启动框架依旧采用公钥验签机制， 只是新增了许多加密机制，具体如下：

我们以非对称验签+对称解密为例，详细阐述其安全启动机制：

1. 在工具端(通常为PC)，首先在可信环境下随机生成对称密钥和非对称密钥对；

2. 对固件Firmware使用对称算法(如AES128-CBC)进行加密，

3. 对FW使用Hash算法(如SHA256)对固件取摘要值，得到Fw Header；

4. 使用非对称私钥对Header进行签名，得到最终产物FW Header+Header Sign+Encrypted_FW_BIN；

5. 通过调试接口、串口等方式将最终产物、对称密钥、非对称公钥存入设备端(MCU)的Flash、OTP中；

6. 在设备端，上电后首先运行BootRom，在ROM中使用对称密钥对Encrypted_FW_BIN进行解密，得到FW BIN；

7. 使用相同Hash对FW BIN取摘要值，并与FW Header进行对比，对比失败则中止启动；

8. 使用公钥对FW Header进行验签，对比失败则中止启动

3. 小米澎湃OS安全启动

在小米澎湃OS技术白皮书中，在小米澎湃OS安全子系统章节找到了关于安全启动相关描述。

值得注意是，在该白皮书中提出的网络安全架构，汽车作为终端设备仅仅只是小米生态的一小部分。因此我理解，它对于系统安全的认知和理解是站在更高维度、更广应用场景。

白皮书对于安全启动描述如下：

1. 设备上电后，BootROM完成基本的初始化后，从存储芯片中加密Level 1 Bootloader，使用Fuse只读空间的公钥进行验签，验签成功后执行Level 1 Bootloader；

2. Level 1 BL校验安全OS成功后，与安全OS共同校验 Level 2 BL；

3. 以此类推，保证了启动过程信任链的构建，从而防止未经授权程序的恶意运行。

根据以上描述，我们发现安全启动方案其实从技术手段上来讲是非常定式化且容易理解的，但在车规MCU领域由于OEM有启动时间要求，因此会对上述启动方案做不同程度的优化，从而提出了顺序、并行、混合启动。

另一方面，安全启动流程较为固定，因此侧重点就来到了芯片对不同类型密钥保护，毕竟钥匙丢了，我家大门就常打开了。

一台汽车的量产，往往需要多个供应商合作开发才能完成，对于不同的件有不同的信息安全要求，因此密钥管理策略是需要芯片厂来考虑的。

通常来讲，芯片出厂后会有根密钥的部署，例如芯驰E3支持公钥类型RSA2048\3072\4096、ECDSA256等，英飞凌支持AES Key等等，此时芯片生命周期应该为Chip Manufacture，开放大部分芯片资源给Tier 1；

当供应商拿到芯片开始做ECU级别开发时，会根据芯片自身BootRom描述来设计安全启动流程，例如一些SoC需要逐级校验完成启动，就需要供应商根据芯片厂规定的文件格式来构建加密签名后的文件包，根据根密钥或者自研算法来生成Tier 1 Key，或者Tire 2 Key；完成ECU开发后，生命周期就应该单向跳转到Delivery，此时应该有安全机制用于保护Tier FW和Key。

最终OEM拿到供应商的件进行组装，构建自己的网络安全体系，因此还需要OEM Key，芯片生命周期来到Production，开启所有的资源保护机制。

以上就是我近期对于安全启动的一些整理和理解，分享给大家 。