为什么需要有车载信息安全？车载信息安全之Secure Boot实现策略

正文

在开始讲解安全启动(Secure Boot)之前，我们首先来简单认识下为什么需要有车载信息安全？

为什么要有车载信息安全？

随着智能驾驶，智能座舱的不断发展，车内ECU也越来越集中化，网络化，ECU之间不单单可以直接通过以太网通信，同时也可以通过V2X技术与车外进行通信，车与车之间，车与外界之间联系越来越紧密，如此一来便无形之中给外界开了诸多与车辆通信的渠道。

比如我们最为常见的整车OTA技术，如果在行车过程中，ECU中运行的软件突然被黑客进行篡改或者控制，将会大大影响到行车安全，随着未来整车自动驾驶技术的不断发展，从L3到L4甚至到L5，人在驾驶方面起到的作用将会越来越小，此时整车的信息安全将会显得至关重要。

而整车信息安全的就在于整车各个智能控制ECU在启动阶段就做好相关的安全确认与校验，才能将风险及时控制住，如果在Runtime时候去检测，则可能会造成更大的行车安全问题。

因此，在车载信息安全领域，在各个智能ECU节点的启动阶段做好相应的安全检查技术，也就是我们所说的安全启动技术，即Secure Boot技术，毫无疑问便可以将各种黑客造成的篡改早早的扼杀在摇篮之中，从而保证最终各ECU中程序Runtime中的行车安全。

Secure Boot简介

应用背景

在芯片上运行的代码一般来说可能会面临两大类信息安全攻击风险：

代码被恶意更改或者攻击；

代码IP被非法读取或获取；

对于第一类风险，我们需要采用某种安全机制来确保芯片运行用户指定的程序，防止代码被恶意篡改；对于第二类风险，为了防止代码被盗，需要针对代码原文进行加密存储，在芯片启动过程中再进行解密后启动。

由于上述代码加密或者启动代码验证等方面都需要花费更多的CPU资源来完成这些工作，因此仅仅依靠传统CPU可能无法高效完成此类工作，需要引入与安全加密有关的单独硬件来做这方面工作，比如我们常说的HSM或者HSE等。

HSM或者SHE模块本质上来讲就是一种硬件加解密引擎，将这些特别耗时的任务交给专门的硬件模块来处理，一方面能够实现Secure boot需求，另一方面也能够提高程序启动效率。

一般来说，支持安全启动的芯片一般都会存在OTP区域（one time programable），其工作原理与保险丝一致，芯片再出厂后，该区域内所有的bit均为1，如果某个bit被烧写为0，就会彻底熔断该bit，再也无法改变该值，也就是再也无法更改为1了，一般该OTP区域用于存储用户的密钥信息。

当然有些芯片可能实现OTP的方式是通过某些控制寄存器来控制某些内存区域，通过控制这些控制寄存器无法被再次改写，从而间接完成被控制的内存区域具备OTP区域特性。

实现目标

具备安全特性如HSM的芯片加入到Secure boot功能之后，便会利用OTP区域内存储的用户密钥信息对即将加载的软件进行多级安全验证，从而最终建立起可靠的安全信任链，通过该安全启动信任链便可以完成软件信息安全的五大特性指标：

真实性：即软件版本未经过篡改；

完整性：软件版本包含了开发者发布的所有内容，没有发生任何变化；

时效性：软件版本是有效期间内的版本；

不可抵赖性：软件发布后，发布者不能否认版本的所有权；

机密性：软件版本不泄露给未授权的个人或实体，不能被非法盗取或者读取；

Secure Boot 相关密码学方法总结

在讲解Secure Boot实现策略之前，小T有必要跟大家一起先来了解下与Secure Boot有关的相关密码学基本方法，这样才能够更为彻底的理解为什么Secure Boot实现策略要这么来做才更加安全。

代码明文加密与对称加密算法

为了保护软件版本IP，防止代码被恶意篡改，因此有必要针对软件版本进行加密处理，即针对代码明文进行加密处理。

AES作为一种较为常见的对称加密算法，具备应用范围广，相对容易隐藏，吞吐量高等优点，通常便可以用来做代码加密处理。

所谓对称加密算法就是加密，解密都是用的同一个密钥，如下图1所示，代码释放者可以将如下代码明文用AES加密算法加密成密文，然后将代码密文烧写到对应的存储芯片中，安全芯片HSM或HSE在启动过程中将加密后的代码密文加载到内存中，同时利用OTP区域中事先烧录的密钥进行代码解密，此时便可以发现整个解密过程用到了相同的密钥及相同算法的逆算法，从而通过解密将代码密文恢复成明文。

该AES对称加密技术的显著优势就是加解密速度快，特别适用于大数据量的加密存储。

图1-1 代码明文对称加密过程

图1-2 代码密文对称解密过程

信息摘要与哈希函数

哈希函数又称为哈希算法，是一种可以将任意长度的一组数据创建为定长的小的数字指纹的方法，该数字指纹也被称作为信息摘要，为了便于理解，后续统一以这种数字指纹称呼为信息摘要。

哈希函数用到的就是哈希变换，哈希变换具备如下两个典型的特征：

加密过程不可逆：也就意味着任何人都无法根据信息摘要推算出加密前的明文到底是什么？

一一对应性：输入的明文与信息摘要一一对应，绝对不会存在不同的明文哈希变换之后得到的信息摘要一样的情况。

在Secure Boot中，一般采用SHA哈希函数来实现哈希变换，来完成最终的信息摘要生成，比如最为常见的SHA256，即生成的信息摘要为4个Byte（Hash Value），以便用来校验代码的完整性，如下图2所示。

图2 哈希算法过程

信任链与非对称加密算法

在整个Secure Boot的过程中除了解决防止代码IP被意外获取之外，最为关键的还是要解决一个信任问题，所谓信任问题就是CPU加载的软件版本是软件发布者A发布的软件版本，而不是别人的非法软件版本。

要解决这类信任问题，就需要使用到非对称加密算法，所谓非对称加密算法就是该算法中存在两个密钥，一个是公钥，一个是私钥。它们是一对，如果用公钥进行加密，只有用对应的私钥才能进行解密，如果用私钥进行加密，也只有使用对应的公钥进行解密才行。

一般来说，密钥的长度越长，算法便会越安全，一般来说会使用非对称加密算法来解决上述信任问题，如RSA非对称加密算法。它是一种公开的、基于数学理论的加密算法，不依赖于任何机构或个人，也不容易被破解，可以实现数字签名与认证工作。

如下图3-1所示，在如下的安全启动过程中软件版本发布者A可以使用RSA私钥来实现对代码的信息摘要进行加密处理，生成数字签名；然后芯片端则可以使用对应的公钥来对数字签名进行解密，从而来完成版本的真实性，同时一旦验证成功，则也具备不可抵赖性，因为只有软件版本发布者A才具有私钥，如图3-2所示：

图3-1 私钥加密生成数字签名过程

 

图3-2 公钥解密还原信息摘要过程

公钥信息交互与数字证书

除了上述解释软件版本自身的信任问题，还需要确保密钥信息自身传输过程的安全性与保密性，此时就需要建立一套完备的信任机制来完传递密钥。

数字证书就是一种权威性的文档，由证书签发机关(CA)签发的对用户公钥的认证,也就是我们常说的"根证书"。 证书一般包含如下几个方面的内容：

电子签证机关的信息；

公钥用户信息；

公钥；

有效期和数字签名等；

一般来说，该数字证书的格式跟验证方法需遵循X.509国际标准。

Secure Boot实现策略

至此，与车载信息安全Secure Boot有关的密码学方法到此基本就介绍完毕了，想必大家应该对secure boot为什么要使用这些密码学方法有了更为清晰的认识，接下来我们将重点来讲解Secure Boot如何利用上述密钥学方法实现如下两个方面的内容：

安全镜像生成流程：该流程主要介绍通过密码学相关方法能够生成供芯片端正确识别的合法软件版本，防止非法软件被意外启动；

安全镜像启动流程：该流程主要介绍通过密码学相关方法来完成针对软件版本的多层安全校验机制如何进行实施；

整个安全启动版本需要校验的文件主要包含如下两个部分：

符合X.509格式的数字证书或根证书；

用户软件版本；

安全镜像生成流程

如下图4所示，整个安全镜像文件生成包含如下几个基本步骤：

S1：用户使用AES加密算法来实现将代码明文转换为密文，同时用户也需要提前在芯片端OTP区域烧录该AES密钥；

S2：用户需采用SHA256哈希函数来对代码密文进行哈希运算，最终得到该软件版本密文的信息摘要；

S3：用户需生成符合X.509国际标准的数字证书或者根证书文件，该文件中需包含上述软件版本密文的信息摘要与RSA公钥信息；

S4：用户需采用SHA256哈希函数来对上述数字证书做哈希运算，得到数字证书的信息摘要，同时用户使用RSA私钥对该信息摘要进行加密处理，最终得到该用户的数字签名。

图4 安全镜像生成全流程

安全镜像启动流程

如下图5所示，较为详细地展示了安全启动流程中的多级安全校验机制，从而保证最终的软件的安全性，合法性与完整性。

S1：芯片复位启动后，通过硬件加密模块如HSM或者HSE先对烧录在Flash中的X.509标准数字证书公钥信息进行哈希运算，并与提前烧录到芯片OTP区域的公钥哈希值进行比对，如果结果一致，那么则可以确认公钥的合法性，这个就是整个信息安全信任链的第一个环节，也是十分重要的环节；

S2：公钥合法性确认后，硬件加密模块如HSM或HSE再利用数字证书的数字签名进行用户合法性鉴权。具体操作步骤就是通过上述确认的公钥对数字签名进行解密处理得到证书的哈希值，同时针对存储在Flash芯片上的证书重新进行哈希运算，对比两个哈希值是否一致，如果一致，则鉴权成功，合法性得到了保障；

S3：然后再利用硬件加密模块如HSM或HSE来重新计算Flash芯片上存储的软件版本的哈希值，即信息摘要，并与数字证书的信息摘要进行比对确认是否一致，如果匹配则说明代码没有被恶意篡改， 用户软件版本的完整性与安全性得到了保障；

S4：芯片硬件加密模块如HSM或HSE最终利用OTP区域提前存储的AES对代码进行解密处理，从而得到代码明文，最终便可以正常加载到CPU中启动运行。

注意：上述任意一个流程没有通过，将不会进行后续流程的校验，则停留在当前的Boot中。

图5 安全镜像启动全流程

由于Secure Boot相比传统的Boot而言，增加了多重安全校验机制，毫无疑问会增加代码启动时间，从而因此第一帧报文发出过晚，因此需要权衡并优化。针对这类问题在具体项目实施过程中与上述流程可能允许存在些许差异，常见的一些差异表现如下：

比如数字证书的公钥信息提取在上位机已成功提取，无需软件来做，减少启动时间；

软件代码的AES加解密措施有些项目考虑到启动时间问题可能也会省略，这个具体还是要看项目端具体需求；

不同供应商使用的Secure Boot流程与上述流程可能均存在差异，这个依照各个项目而定，本文只是提供了一般性的Secure Boot实现策略。

   




审核编辑：刘清