汽车网络安全--ECU的安全更新
目前，汽车ECU的软件更新可以总结分成三大类：
工厂刷写模式：工厂大批量刷写或者升级，一般在出厂用；
工程模式：4S店、工厂等专业人员进行的ECU固件更新，通常是动力、转向、车控等；
车主模式：车主根据云端推送信息，通过IVI进行应用软件更新；目前也有趋势通过这种方式刷新ECU固件。
但是一谈到软件或者固件的更新，不可避免地就会讨论到待更新软件的可信度，即信息安全问题；而今天要聊到的就是ECU如何实现安全更新，即防止ECU被恶意/无意更新到错误的软件版本，从而威胁到汽车驾驶人员的人身财产安全。
那么今天我就从技术角度出发，看看ECU内部是如何保证软件的安全更新，主要从以下几个方面来进行
安全更新的基本要求
安全更新的文件格式
安全更新的基本流程
安全更新实现的工具要求
1.安全更新的基本要求
所谓安全更新，即保证待更新的软件是目标ECU所需要的软件版本，从信息安全角度来说，就是要保证软件的完整性和真实性。
完整性是指待更新的软件没有被破坏或者被篡改；
真实性是指待更新的软件是由确定的提供方授权；
这些数据特性需要由对应的密码技术支撑，这里将信息安全威胁和对应的密码技术总结如下：
从上图我们就可以看到，真实性和完整性是需要用数字签名、摘要算法、消息认证码这类的密码技术所保证。
结合国产替代背景，因此我认为密码算法库的需求如下：
算法类型 | 国家商用密码 | 国际密码 |
摘要算法 | SM3 | SHA256\512等 |
公钥算法 | SM2DSA | ECDSA等 |
2.安全更新的文件格式
汽车ECU软件常见的Flash Layout如下：
在更新阶段，通常做法是将BootManager中的Updater（对称加密后的密文）解密并搬至RAM中执行程序更新动作。
那么既然要保证待更新的软件真实性和完整性，就需要给App、标定数据等分区增加签名段。因此可以在上述分区增加签名段，如下：
那么这个签名段里具体包含了哪些内容呢？我们以App为例，具体来分析一下，个人认为应分为两类：
对签名段本身的签名信息
对元数据(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算法本身的抗碰撞性。
就酱，结束！