汽车MCU基于非对称算法的伪安全启动方案

一、概述

随着软件定义汽车理念的普及，汽车上代码量不断膨胀，功能不断智能化，用户体验不断升级。从传统汽车不需要联网，到职能汽车具有联网功能已是标配，汽车触网必将带来更多信息安全问题。汽车的信息安全问题比IT领域更加重要，因为可能危及生命安全。故国家也出台强标《汽车整车信息安全技术要求》（目前还处于征求意见稿），在强标的的9.1.1条提出

“车载软件升级系统应具备安全启动的功能，应保护车载软件升级系统的可信根、引导加载程序、系统固件不被篡改，或被篡改后无法正常启动”

故安全启动功能后续将成为强标的一部分，具有OTA功能的ECU都必须配备。但目前，MCU普遍未实用HSM功能，国内MPU总体支持安全启动。MCU未使用HSM，主要还是出于成本考量，实用HSM将带来物料成本和HSM协议栈成本。因此综合考量后，可以先解决有无问题，后续再解决好坏问题。在不增加额外成本的场景下，先解决有无问题，故提出一个基于非对称加密算法、信任链不完整的安全启动方案。

二、安全启动概念

安全启动是通过一项技术，确保按照固定顺序，运行经过验证后的代码，确保不会存在模块被绕过以及不会运行不合法的代码。通过此技术，可确保攻击者篡改任何ECU代码或者重新刷入非法代码都会被识别，且可以直接限制ECU启动。
安全启动涉及如下概念：

1. 验证：一个检查过程，检查即将运行的代码是否为官方发布。为实现验证过程，需引入密码学算法，当官方发布软件包时，通过该算法计算出当前软件包的一个特定值，并将该特定值和软件包一起写入到ECU FLASH中。启动时，实时计算出软件包特征值，并和已写入FLASH的特征值对比。若两者一致，则软件包合法，否则不合法安全启动。
2. 信任根：上述认证过程同样需通过代码实现，若攻击者可修改验证过程代码，则依然可绕过验证过程或篡改验证结果。故此时需要有一个攻击者完全无法修改的代码，来验证上述的认证代码，确保上述验证代码无法被修改。这个攻击者完全无法修改的代码即可理解为信任根，信任根是一致认为无法被篡改的一段代码，通常通过硬件实现，例如芯片的bootROM，bootROM是固化在芯片内的一段代码，芯片一旦制造完成，bootROM就用于无法被更改。
3. 信任链：一个ECU的软件基本会分为多个部分，例如bootloader，app等，以信任根为起点，通过不断实现一级一级的验证，从而形成信任链，确保各模块认证的有效性。例如bootROM认证bootloader，bootloader认证app。

三、安全启动方案

3.1 根证书

安全启动采用非对称算法，可使用RS或ECC算法，生成一对公私钥。公私钥用途如下：

• 私钥：用于签名，在刷写前，对即将发布的镜像计算HASH值，并通过私钥对HASH值进行签名，得到签名信息。
• 公钥：用于验签，当安全启动工作时，通过对签名信息使用公钥验签，还原出发布时镜像的HASH值，用于后续比对HASH值是否正确。

3.2 存储空间

假定一个ECU软件包包括三部分，分别为BootLoader、APP1、APP2，则该软件包刷写到ECU FLASH中应是如下示例：

在原始镜像基础上，增加针对该镜像的签名信息，并将原始镜像和签名信息一同刷写到FLASH中。

3.3 刷写前准备

当进行软件刷写前，需先计算各模块的签名信息。计算签名信息流程如下：

1. 基于原始镜像，使用HASH算法（例如SHA-256），得到该镜像的HASH值。
2. 使用之前生成的私钥对HASH值进行签名，输出即为原始镜像的签名信息。 当进行刷写时，需将原始镜像和签名信息一并刷写到FLASH中。例如参考3.2中示例，将BootLoader原始镜像和Bootloader签名信息刷写到BootLoader区域，将APP1原始镜像和APP1签名信息刷写到APP1区域。签名信息在各自区域存放的位置，可由开发人员自行定义，只需保障启动时，可准确读取到签名信息即可。 将安全启动证书/公钥刷写到FLASH中，且将证书/公钥的HASH值保存到OTP中。

3.4 安全启动流程

3.4.1 总体安全启动流程

1. bootrom后跳转到Bootloader，在Bootloader中验证根证书、bootloader自身、下一个启动模块的合法性。
2. 启动bootloader下一个模块（例如APP1），在此模块中，验证后续启动模块的合法性。按照在当前模块中验证下一模块合法性，验证通过后，则继续启动下一模块的链路验证下去，直到所有模块都验证结束。
3. 若验证失败，则跳转到启动失败处理流程：记录失败原因和失败次数到FLASH中，进行软件reset。

3.4.2 安全启动流程实例

假定一个ECU软件包包括三部分，分别为BootLoader、APP1、APP2。则启动过程如上图所示，具体流程如下：

1. 上电后，执行芯片bootrom后，跳转到bootloader。首先读取DFLASH中失败次数，若失败次数大于N此（通常为3），则启动失败，停留在PBL中或提供有限功能（具体应依据项目需求设计）。若小于N，则继续启动流程；
2. 读取安全启动根证书/公钥，计算HASH值（称为CERT-HASH-1），并读取OTP中保存的HASH值（称为CERT-HASH-2），比较CERT-HASH-1和CERT-HASH-2值是否相等，若相等，则根证书/公钥未被篡改，继续启动流程。若不相等，则启动失败，记录失败原因和次数到FLASH中，并进行reset，跳转到步骤1中；
3. 随后读取Bootloader镜像并计算镜像的HASH值（称为BOOTLOADER-HASH-1）。读取bootloader的签名信息，并通过根证书/公钥验签bootloader的签名信息，得到签名信息中包含的HASH值（称为BOOTLOADER-HASH-2）。比较BOOTLOADER-HASH-1和BOOTLOADER-HASH-2值是否相等，若相等，则证明Bootloader未被篡改，继续启动流程。若不相等，则启动失败，记录失败原因和次数到FLASH中，并进行reset，跳转到步骤1中；
4. 读取APP1镜像并计算镜像的HASH值（称为APP1-HASH-1）。读取APP1的签名信息，并通过根证书/公钥验签APP1的签名信息，得到签名信息中包含的HASH值（称为APP1-HASH-2）。比较APP1-HASH-1和APP1-HASH-2值是否相等，若相等，则证明APP1未被篡改，继续启动流程。若不相等，则启动失败，记录失败原因和次数到FLASH中，并进行reset，跳转到步骤1中；
5. 跳转到APP1中。读取APP2镜像并计算镜像的HASH值（称为APP2-HASH-1）。读取APP2的签名信息，并通过根证书/公钥验签APP2的签名信息，得到签名信息中包含的HASH值（称为APP2-HASH-2）。比较APP2-HASH-1和APP2-HASH-2值是否相等，若相等，则证明APP2未被篡改，继续启动流程。若不相等，则启动失败，记录失败原因和次数到FLASH中，并进行reset，跳转到步骤1中；
6. 跳转到APP2中。若有其他模块启动，则继续按照信任链一步一步进行验证。若无其他模块，则安全启动完成。

3.5 安全启动耗时

安全启动相较于普通启动，增加相应的流程，必然会带来安全启动时间的增加。基于在infineon TC377和TI AWR 2944经验，不借助硬件加速，耗时估算如下：

• HASH使用SHA256：4K/1ms
• 签名验签：9ms 总体来说，耗时主要在对各模块计算HASH中，如APP有4M，则耗时将达到1S。

3.5.1 优化

针对HASH耗时较大，若芯片支持硬件CRC加速，可先计算镜像的CRC，然后对CRC进行签名。基于目前经验，硬件CRC速度约为70K/s，速度提升快20倍。以4M模块计算，使用硬件CRC耗时约58ms，使用软件HASH则耗时1000ms。
使用CRC碰撞概率远大于HASH（SHA-256）碰撞概率，故使用CRC可提升安全启动速度，但同步会带来安全性减弱。

四、方案总结

4.1 优点

在不大量增加成本的情况下，实现安全启动从无到有。使用当前方案，不需要使用支持HSM的芯片，不需要额外购买HSM协议栈，即可实现具有安全启动。

4.2 缺点

不是完整的安全启动。当前方案以BootLoader为信任根，而不是以不可更改代码为信任根。导致攻击者可修改BootLoader即可绕过安全启动的验证过程。

4.2.1 缺点完善

当前缺点为bootloader不是不可更改的区域，作为信任根强度不够。为提升强度，可限制对Bootloader的修改，例如：不允许刷写bootloader、禁用JTAG等调试口等措施。

五、思考

以上方案因缺少一个不可更改的信任根，总体上仍存在安全缺陷。但有些芯片支持将code Flash的部分区域整个设置成OTP，例如infineon的TC3XX、瑞萨的RH850等。若芯片支持设置code flash为OTP，理论上可以不适用HSM实现一个不可更改的信任根。思路如下：
将Bootloader拆分为2段PBL1和PBL2。其中PBL1校验PBL2，并将PBL1设置为OTP。PBL1验证PBL2通过后，启动PBL2，在PBL2中校验后续APP。因PBL1所在的code Flash在产线会设置成OTP，故PBL1可当做一个不可更改的信任根使用，达到类似Bootrom的效果