汽车软件的安全启动

作者 | Neo

出品 | 汽车电子与软件

首语

随着软件定义汽车（Software Defined Vehicles, SDV）的概念的提出，汽车软件发展迅速，其功能越来越多，也变得越来越智能，汽车在为人们更好服务的同时，许多安全问题也随之出现。汽车安全主要分为功能安全和信息安全，功能安全主要是要求降低汽车硬件的随机失效概率，信息安全则主要保证汽车软件安全运行、正常升级。怎样保证软件能够安全运行，让汽车ECU只运行完整的、可信的软件？这种要求可以让汽车的安全启动（Secure Boot）来做到。

一、安全启动了什么

当驾驶者准备启动汽车时，汽车中各种各样的软件便会被加载，完成各种各样的服务。这些软件是汽车厂商设计并经过验证的，汽车厂商保证了他们的软件可行性和安全性，并把这些软件在汽车卖给消费者之前就安装在汽车中，并在后期对软件维护和优化升级，通过在线升级（On The Air, OTA）技术对汽车软件进行远程升级。消费者能持续获得可靠的优质软件服务。

这些看起来都没什么问题，但如果在消费者使用过程，这些配套软件被恶意替换，那么不但软件可能无法提供相应的服务和安全性，还极有可能对人和汽车本身造成严重伤害。所以汽车厂商在设计之初，就考虑到这一问题，实现了安全启动来应对，安全启动是一段在启动引导程序（Bootloader）中的程序，在实现汽车各项功能的软件（App）启动之前，Bootloader会首先启动，对App进行校验，主要检查App的两项指标：完整性（Integrity）、可信度（Authentication），如果检查不通过，则不会启动App。完整性指软件二进制可执行文件是否保持原样，有没有被篡改；可信度指软件的来源是否可靠，在汽车软件中，指是否是汽车厂商提供的。这两项指标确保了汽车运行的软件是来自汽车厂商有安全保证的软件，并且没有被篡改，从而保护了人和汽车的安全。

二、怎样保证安全

怎么在汽车上实现对App的完整性和可信度的检查呢？这里就需要一些密码学（Cryptography）技术。

先来了解一些名词：

哈希函数（Hash Function）：可将任意长度数据转化为指定长度摘要（e.g. SHA2安全哈希函数，MD5）
对称加密（Symmetric Encryption）：用同一把密钥对数据进行加解密（e.g. DES，AES高级加密标准）
非对称加密（Asymmetric Encryption）：使用公钥和私钥对数据加解密（e.g. RSA，ECC）

完整性验证

App可执行文件是一个二进制文件，可以把App的可执行文件作为哈希函数的输入，会得到一个固定长度的哈希值（Hash Value），这里就不得不提到哈希函数的一个特点，哈希函数的输入值改变会影响输出值，而且是极大的改变，哪怕是输入值的一位（Bit）数据被改变。设想，使用哈希函数把汽车厂商的正版软件作为输入得到一个哈希值，并把其保存起来，黑客得到了汽车厂商的App并对其修改，然后想让汽车运行他修改过的软件，Bootloader在启动安全启动时，对修改后的App的再做一次哈希，发现与先前的值截然不同，也就不会启动带有风险的App。这就保证了软件的整体性。

但这还不够，哈希函数的实现方式是公开的，汽车厂商可以正常的App生成一个哈希值H1存放起来，那么黑客也可以生产一份经过修改的App的哈希值H2替换之前的H1，并把修改后的App刷入汽车中，这样Bootloader启动时发现保存的哈希值H2和即将要运行的App（经过修改的）一致，则会正常运行。就可以骗过安全启动的验证，达到运行修改后App的目的。解决这一问题，这就要提到另一个技术——一次性可编程（One Time Programmable， OTP），这是单片机的一种存储器类型，其作用是程序烧入单片机后，将不可再次更改和清除，汽车厂商可以将自己App所生成的哈希值存储到这样的存储器中，就可以保证经过安全启动验证的App一定是汽车厂商所提供的，这块区域也不可能被篡改。

可信度验证

但接下来还有一个问题需要解决，前面我们提到过OTA技术，汽车厂商会在消费者使用汽车过程中，持续对汽车软件进行维护和升级，如果汽车厂商把最初那一版App的哈希值放到了OTP存储器中，那么结果就是，汽车厂商对App升级后，由于这块区域的内容无法被更改（汽车厂商也无法修改），结果就是升级App后，由于安全启动校验不通过，导致软件无法启动。所以我们得采取其他的解决方案。

这里可以使用数字签名（Digital Signature）技术，可以采用非对称加密算法，利用私钥（Private Key）对汽车厂商App的哈希值进行加密生成一个签名保存起来，签名只能用公钥（Public Key）才能解密，签名解密后是一串哈希值，我们就可以用这个哈希值和即将要启动的App的哈希值进行比较。这样看起来就好了很多，在OTA升级时，利于数字签名技术对将要升级的App进行完整性和可信度验证，确保将要升级的App没有被篡改并且确实来自于汽车厂商（汽车厂商利用私钥加密，汽车软件升级验证时用公钥解密），然后将签名写入FLASH某个区域（不需要OTP特性）。那么公钥放在那里呢？前面提到的OTP又派上用场了，这块区域就可用来存储和汽车厂商成对的公钥。

当然也有采用基于分组密码的消息认证码算法（Cipher-based Message Authentication Code，CMAC）的方案进行安全启动的验证，其目的是相似的，只不过使用的方法不同。

如何实现加解密

有了解决方案，如何实现这些复杂的算法呢？这里就要讲一讲车规级MCU的发展历史了，在一开始， MCU的芯片厂商并没有集成硬件来完成加密算法（Cryptographic Algorithm），加解密过程基本都是软件来实现的，其实软件加解密这一块离大家都很近，比如，熟悉Linux的同学知道，两个客户端要进行SSH通信前，需要提前生成SSH钥匙，这里的SSH钥匙就是上面提到的非对称加密算法中的公钥和私钥。这样实现加密算法的方法就是软件实现，所以早期汽车实现这些加密算法也都是通过软件层面实现的。这种方式有一定缺陷，比如加解密过程中，需要MCU中主核（一般是M4或M7）来完成整个算法，期间也不能做其他的事，主核在设计之初也没有考虑对加解密算法进行优化，结果就是实际效率会差很多。

目前，主流的方法是通过硬件实现加密算法，例如硬件安全模块（HSM，Hardware Security Modules）和安全硬件拓展（SHE，Secure Hardware Extension）。

SHE顾名思义，是对MCU的扩展，它主要提供类似于OTP的存储空间，并不能为主核提供硬件加速，结构图如下：

HSM就强大得多，拥有自己的CPU，并且有类似OTP的安全存储区域，其结构如下：

目前，大多数高端车规级芯片都会集成SHE和HSM，国外芯片厂商有ST、NXP、infineon等，国内芯片厂商有芯驰、地平线、黑芝麻等，比较常见内嵌HSM模块的芯片有意法半导体的SPC58、英飞凌的Trave系列、芯驰的G9X。

三、安全启动流程

上述的这些解决方法和工具已经可以实现完整的安全启动过程，这里要介绍一个安全启动的概念——信任锚（Trust Anchor），大家可以把它理解为运动会中接力赛的接力棒，其实仔细想想就会发现，上面讲的很多安全启动的内容都是Bootloader来完成的，那么Bootloader的完整性和可信度又该怎么保证呢？其实就是靠这个信任锚，BootRom（是一段固化在芯片Rom中的程序）它先检查Bootloader的完整性和可信度，确保没有问题后，将信任锚传递给Bootloader，然后Bootloader进行密钥的检查、签名验证等操作，确保App是正确的，然后才启动App完成各种服务。

四、发展与挑战

汽车软件发展迅速，它给人民生活带来极大的便利，但机会和风险是并存的，汽车软件的信息安全问题也不容小觑，以UNECE/WP. 29 (R155、R156) 和 ISO/SAE 21434 为代表的汽车信息安全的国际法规与标准已经发布与实施，我国也早已将发展智能网联汽车上升到国家战略高度，国家各部委根据在车联网关键部件和生命周期各环节的职责划分，制定相关政策及执行监管，包括网信办、工信部、交通运输部、公安部、国标委等，共同推动建立健全智能网联汽车信息安全管理机制。例如，市场监管总局分别在2020年11月和2021年6月发布文件，规范了 OTA 技术在召回工作中的应用，明确要求生产者采用 OTA 方式消除汽车产品缺陷、实施召回的，须向市场监管总局备案。要求车企在使用 OTA 开展技术服务活动时，需向市场监管总局质量发展局备案；车企如果使用 OTA 消除车辆缺陷、实施召回的，也需要向市场监管总局质量发展局备案。

汽车信息安全技术也在不断进步，国内外汽车厂商都在努力做出安全可靠的汽车软件。相关外企研发出HSM模块，并嵌入加密算法、访问控制、完整性检查等技术到汽车控制系统，但是目前HSM仍然不支持国密算法，存在技术壁垒，未能实现国产自主可控。国内对于芯片集成安全硬件还不完备，此种情况下能有一款支持国密标准的国产汽车硬件安全模块对国内汽车行业十分重要。国密算法是我国自主研发创新的一套数据加密处理系列算法，随着我国智能汽车信息安全的要求，需要将国密算法嵌入到硬件加密芯片中结合使用。

最好的情况就是，能在芯片层面保证安全启动的方案和App软件都是自主可控，这样就可以最大程度的保证人和汽车的安全。