汽车网络安全--ECU的安全更新

目前，汽车ECU的软件更新可以总结分成三大类：

• 工厂刷写模式：工厂大批量刷写或者升级，一般在出厂用；

• 工程模式：4S店、工厂等专业人员进行的ECU固件更新，通常是动力、转向、车控等；

• 车主模式：车主根据云端推送信息，通过IVI进行应用软件更新；目前也有趋势通过这种方式刷新ECU固件。

但是一谈到软件或者固件的更新，不可避免地就会讨论到待更新软件的可信度，即信息安全问题；而今天要聊到的就是ECU如何实现安全更新，即防止ECU被恶意/无意更新到错误的软件版本，从而威胁到汽车驾驶人员的人身财产安全。

那么今天我就从技术角度出发，看看ECU内部是如何保证软件的安全更新，主要从以下几个方面来进行

1. 安全更新的基本要求

2. 安全更新的文件格式

3. 安全更新的基本流程

4. 安全更新实现的工具要求

1.安全更新的基本要求

所谓安全更新，即保证待更新的软件是目标ECU所需要的软件版本，从信息安全角度来说，就是要保证软件的完整性和真实性。

完整性是指待更新的软件没有被破坏或者被篡改；

真实性是指待更新的软件是由确定的提供方授权；

这些数据特性需要由对应的密码技术支撑，这里将信息安全威胁和对应的密码技术总结如下：

从上图我们就可以看到，真实性和完整性是需要用数字签名、摘要算法、消息认证码这类的密码技术所保证。

结合国产替代背景，因此我认为密码算法库的需求如下：

算法类型	国家商用密码	国际密码
摘要算法	SM3	SHA256\512等
公钥算法	SM2DSA	ECDSA等

---

2.安全更新的文件格式

汽车ECU软件常见的Flash Layout如下：

在更新阶段，通常做法是将BootManager中的Updater（对称加密后的密文）解密并搬至RAM中执行程序更新动作。

那么既然要保证待更新的软件真实性和完整性，就需要给App、标定数据等分区增加签名段。因此可以在上述分区增加签名段，如下：

那么这个签名段里具体包含了哪些内容呢？我们以App为例，具体来分析一下，个人认为应分为两类：

1. 对签名段本身的签名信息

2. 对元数据(App数据)的签名信息

签名段主要是为Updater提供必要的密码服务支撑，APP元数据以明文的形式被刷进ECU。

需要注意的是，这里讨论的是工程模式刷写，与TBox作为OTA Master场景不同；限于当前MCU的RAM容量限制，没有办法先将APP元数据接收到RAM，待验签后再刷。因此首先会先验证签名段的真实性和完整性；完成签名段验签后，再请求APP元数据的传输，直接刷进Flash目标位置，最后使用摘要计算和公钥算法完成APP的完整性和真实性验证。

那么我们具体来描述下该更新流程。

---

3.安全更新的基本流程

安全更新的基本流程示例如下：

这里就和常规的UDS刷写没有太多差异，需要着重讨论的就是验签的过程。

以签名段验签为例，签名段首先由签发工具使用特定Hash算法进行摘要计算，然后用签名私钥对摘要进行签名，然后将签名段、签名后的摘要与公钥一同下发给ECU；ECU将上述数据全部获取完毕后，首先根据预置在Updater中的特定Hash算法（应该与签发工具一致）对签名段进行摘要计算，然后使用公钥对签名后的摘要进行解密，最后比对两者摘要，如一致则进入下一步。

---

4.安全更新实现的工具要求

通过上面的粗略分析，我们可以大概总结出安全刷新工具主要分成两大类：

• 更新文件签发工具：必须具备特定权限的人员使用

• 更新流程上位机工具：用于安全更新的上位机工具

更新文件签发工具，主要是根据待更新的APP、标定数据等生成签名段，然后合并成一个完成的Hex或者S19文件；

更新流程上位机工具主要是需要根据格式要求，将HEX或者S19文件解析成签名段和元数据，执行更新时先传输签名段，待ECU完成验签后再传输元数据；其次，还需要对ECU的验签错误结果进行解析，这个功能一般放在0x37服务中做，如果验签失败，则返回NRC，具体定义可以自己设置。

---

小结

上面简单聊了下安全更新的流程，其实就是在以前的诊断更新流程上添加了信息安全相关的一些流程，主要掌握非对称、Hash等算法在信息安全威胁的不同安全机制，通常非对称是用来验证真实性，毕竟密钥对是独有的，Hash用于验证完整性，因为Hash算法本身的抗碰撞性。