汽车信息安全 -- 再谈车规MCU的安全启动
目录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的关照，具体流程如下图所示：
https://i-blog.csdnimg.cn/direct/287d6a47d6084f7490a9929808cf58ad.png
进一步讲，当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品级，如下所示：
https://i-blog.csdnimg.cn/direct/344abc0901b04f18823a35059dbe97a3.png
由于其设计雏形源于HIS SHE，因此安全启动逻辑也根本相似。在ICU-M内部有一个Secure Boot Key 用于校验Host Application。
上电后，ICUP率先复位释放，完成一系列初始化后，进入到ICU Firmware，由该Firmware的安全启动程序对Host Application举行校验，校验完成后有ICUP释放Host Core，逻辑如下图：
https://i-blog.csdnimg.cn/direct/11fc211f370d49fea4d83252cda4458c.png
值得一提的是，在瑞萨提供的示例中，Program B是由Program A请求ICU-M举行校验。信托链从这个意义上也串了起来。
1.3 NXP S32K3的安全启动
在S32K3的启动流程，硬件复位后同样只有HSE(也就是HSM)子体系可以运行，起首运行sBAF()代码，完成根本环境设置，然后根据IVT(Image Vector table)中BOOT_SEQ来决定是否执行安全启动，如下图：
https://i-blog.csdnimg.cn/direct/5e3f5bd13b3147c88d9367d8824c986a.png
[*]当BOOT_SEQ = 0时，SBAF忽略掉HSE是否完成校验，直接运行Host App；
[*]当BOOT_SEQ = 1时，SBAF只运行HSE_Firmware，由HSE FW来选择什么时候释放Host Application
根本流程如下图所示：
https://i-blog.csdnimg.cn/direct/84511de1bf884c6da3dd29aae4db1cff.png
1.4 小结
可以看到，上述MCU均在自己的信息安全解决方案里考虑了安全启动，可以通过不同设置来选择是否启用安全启动，但是决定权还是在于HSM Firmware在什么时候复位Host软件。
因此，这也给了HSM固件供应商更大的舞台来设计安全启动流程。
比方，我们可以将用户Host Application按用途分成不同类别，比如说Group BootManager、Group AppA、Group AppB；然后在类别里根据启动时序要求拆分成不同的块，对这些块设置不同的启动模式，如下图：
https://i-blog.csdnimg.cn/direct/863d4dbe8abb4dfeb32c52ff75da611d.png
如许就能够分身信息安全和OEM启动时间要求。
2.信托链的问题
我们仔细分析上述MCU的启动流程，会发现一个现象：除了S32K3在SBAF里有对HSE_FW举行验证，别的方案均默认HSM FW可信。
但我遇到很多人问过如许一个问题：那你这个启动流程的信托链就是断裂的，从芯片厂商 -> Tier 1 -> OEM这个信托过程没有建立起来。
有朋友以Inter Arria 10 SoC Secure Boot过程为例：
https://i-blog.csdnimg.cn/direct/e2fd3f1d5398466a9b92df6ff8e8878e.png
它统共历经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分别为安全域和非安全域，
https://i-blog.csdnimg.cn/direct/e8657ed848514f10a711f7a5205846ce.png
HSM内部包含自己Code、Data Flash，可以存储HSW_FW、密钥、车辆\车主敏感信息。
因此理论上，把HSM和ECU主密钥组合共同作为体系信托根是可行的。
3.国产HSM IP的拓展
正是基于这点，现在有很多国产HSM IP举行美满。
比方芯来科技的HSM IP提供了完备的安全启动流程，它们的安全启动中包含两级验证和加载启动，分别为芯片级和体系级两个层级，对应芯片厂商和体系厂商。并且每一级厂商都可以拥有自己的密钥对。
芯片厂商提供BootROM和一级Loader(NSBS固件)，处于HSM体系中。
芯片厂商的公钥用于验签一级Loader(NSBS固件)，体系厂商的公钥用于验签HOST体系的固件程序。整体安全启动流程如下图所示：
https://i-blog.csdnimg.cn/direct/f0397e73387c4dffac955e9676f7ce0b.png
BootRom验签NSBS，NSBS验签Host App1、2等，如许看起来很美好，芯片原厂提供整套信息安全解决方案，但是不知道HSM固件供应商如何对待这一块，毕竟“NSBS”才是它们的焦点价值所在。
纽创、安谋科技 HSM IP对于安全启动的思绪和芯来类似，个人感觉理念大都源于从前IoT的安全启动概念：
https://i-blog.csdnimg.cn/direct/3dc275ffbfb5499e801d8bd4e27c81d2.png
做法没有对错，归根结底还是在于整车体系网络安全架构要实现的网络\信息安全目标，通过合理的TARA分析来选择体系的信托根。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]