汽车信息安全--常见车规MCU安全启动方案
目录
01.概述
02.安全启动目标
03.安全启动方式
04.小结
我个人理解，讲清楚方案能更好地做红蓝对抗或者模糊测试，从而进一步保证安全启动。（如各位觉得不妥，请联系我删除）。
从嵌入式角度出发，安全启动最早应用在linux系统上，全称叫secure boot；它是一种逐级验证镜像，从而实现固件可信运行。
以常见的uboot启动为例，通常要经过BootRom -> SPL -> uboot三个大阶段（其中BootRom出厂时掩膜在ROM介质中，不可更改，SPL(Secondaty Program Loader)用于初始化C语言环境等）；BootRom作为信任根，会首先验证SPL代码（这里不讨论具体算法），确认SPL无误后，加载SPL代码到DDR或者SRAM；然后由SPL对uboot进行校验；方式同上，最后验证无误完成启动。
图片来源:Intel AN759
上述简述中各位发现问题没？
在传统汽车控制类ECU上，很少有加载镜像运行的方式，因为大部分程序（非座舱类）都放在Flash中，属于XIP(execute in place)范畴，同时在汽车MCU中，系统启动时间对OEM来说是一个比较严苛条件，通常要求50ms内具备接收和处理NM报文、100ms内具备外发报文的能力，所以如果沿用uboot的安全启动流程，从时间维度是完全无法满足要求。
因此针对汽车MCU的安全启动，大家有了不同方案。02.安全启动目标
基于上述目标，我们来依次拆解出策略：
保证代码可信且完整，常见方式有签名验证、HASH、CMAC等，因此需要HSM外设以提供上述服务；
加快安全启动速度和每次复位都要验证目标代码，因此需要高效的代码、加密引擎的硬件加速能力、可信的启动引导程序。
所以想要做好安全启动，首先有MCU中最好自带符合EVITA的HSM模块，其次在MCU内部最好有属于自己的信任根，最后在硬件上需要设计高效的host和hsm核之间交互策略，从而给软件提供了实现不同启动方式的平台。
进一步的，从产品维度来看，根据我们之前汽车ECU的开发经验，安全启动需要保护的内容如下：（1）用户的bootloader程序不被篡改或者破坏；
（2）用户的app程序不被篡改或者破坏；（3）用户的敏感信息（例如VIN、整车通信密钥、里程数据等）不被篡改或者破坏；（4）用户的ram区不执行恶意代码；（5）HSM内部的固件不被篡改或者破坏。 同时，安全启动的需求包括：（1）HSM固件、用户代码执行前均需要被验证；
（2）系统上电之后50-100ms内需接收NM报文和发送报文(普通报文或NM报文)。基于上述需求和目标，我们来分析不同启动方式对系统启动效率的影响。
03.安全启动方式
根据Intel的安全启动流程，我们可以很清晰地看到它是属于一个逐级验证的过程，因此车规MCU可不可以借鉴这种启动方式呢？当然可以。3.1 逐级验证启动逐级验证启动，我一般叫它顺序启动，顾名思义，即按顺序验证Flash中的代码，验证成功方可进行运行代码。那么要验证哪些代码呢？首先确定信任根--HSM 的bootrom，这个不用校验。那么需要校验的内容就有：HSM的bootloader、HSM的App程序、应用程序的bootloader、app程序、data数据等。
具体流程示例如下：
这里面就出现了一个很矛盾的点，HSM BootRom是如何知道HSM固件、用户程序存放的位置以及对应签名或者MAC值的呢？BootRom不能改，是不是提前就得定好程序、签名、MAC存放位置？那这样风险不就又增加了，虽说大家都要签NDA。
所以，我很少看到有在BootRom里就做安全启动的；那不在BootROM里做校验，这种情况信任根和信任锚点就出现了转移。这是后话，扯远了。
回到正题，很明显，顺序启动需要将flash所有程序和数据验证完毕后，HSM才会通知Host代码运行，HSM如何快捷通知？神奇的HSM_Ready，我竟在不同芯片上都看到了，到底谁是幕后黑手？3.2 并行启动方式并行启动就很好描述了，Host启动HSM之后，继续运行其App代码，HSM自行启动，去验证HSM固件、HOST App代码，一旦验证不通过，HSM有权限将整个系统重启，并在一个可行环境中运行（这里其实也有绕开的办法）。
其流程如下：
这种方式启动速度很快，但是缺点也很明显，一旦运行被篡改的程序，不知道会发生什么样的危险事件，未知的才是恐惧的。
3.2 混合启动
基于上述顺序和并行启动方式的优缺点，目前还有一个启动方式，即混合启动。
混合启动的出现兼顾效率和信息安全，比如说，要快速发报文，那我就先校验通信栈，先发再说，应用程序等HSM校验完成后再运行。当然这也是一种投机倒把的技巧。
那么我们可以怎么做呢？
从配置工具上提供校验程序的配置（我这里称之为group），例如group的起始位置和大小，group的分类、group是按照顺序启动校验还是并行启动检验；同时提供了link的配置，从根本上解决了配置困难这个问题，但是callout和callback还是需要自己定义，不过这已经是大大的进步了。
3.4 安全启动常见验证方式
上面三个小章节介绍了启动的方式，下面解析下安全启动中使用的验证方式（我也很容易搞混淆）：
MAC
具体做法为： 发送方将发送消息和密钥进行MAC运算，得到MAC值，并把MAC值与消息一同发送给接收方。接收方接收到消息后，将消息部分与事先共享的密钥进行MAC运算，得到MAC值，将MAC值与发送方发送的MAC值进行比较，如果一致，证明消息是来自发送方。
这样，即使密钥泄露，由于有MAC（Hash单向性），对于同一条消息，攻击者基本无法伪造出相同的MAC，从而保证该消息是正确且没有被篡改。
常见的算法有：AES-CMAC\SHA-HMAC。而随着加密引擎的硬件化，上述算法效率大大提升。
HASH
既然上面提到的MAC属于Hash，我们来讲下Hash。
Hash就是将任意数据转换成一个固定长度的字符串，很明显，这个字符串无法反向推导出原文，因此不可逆。常见为SHA-2-256（目前 MD5 和 SHA1 已经被破解，一般推荐至少使用 SHA2-256 算法。）
Signature
04.小结
上文，我们详解了安全启动方式（顺序、并行、混合），分析了不同启动的优劣势；梳理了安全验证的三种不同方式：签名、Hash、MAC。有了基础概念，我们接下来就可以分析安全启动加密算法的具体细节。
往期回顾：
1.汽车标定合集
汽车标定文章合集汽车标定技术--A2L格式分析
汽车标定技术--XCP协议如何支持测量功能
硬核:汽车标定--多周期测量显示异常汽车标定技术--MPC57xx是如何支持标定的页切换
2.AUTOSAR合集
AUTOSAR OS概述（一）AUTOSAR OS概述(二)
AUTOSAR 通信栈分析(一)
AUTOSAR 通信栈分析(二)
AUTOSAR中的Crypto Stack(1)--概述
AUTOSAR文章合集
Flash模拟EEPROM原理浅析
3.汽车网络安全合集
汽车网络安全方案产品交付形态的思考汽车网络安全方案需求分析
车载信息安全场景概述
汽车网络安全渗透测试概述
汽车网络安全文章合集
4.汽车功能安全合集
5.汽车虚拟化合集
6.杂七杂八