信息安全：软件认证知识点梳理

lixinfu

随着信息安全越来越被重视，汽车软件开发中，信息安全相关知识已然在成为工程师的“标配”技能。如果说，Application程序中，接触到的信息安全需求不多，那么，在Bootloader程序开发中，信息安全的相关需求则见怪不怪。毕竟牵扯到程序升级的话题，或多或少会牵扯到OTA（Over The Air）技术。而OTA技术，又需要车辆联网，既然车辆联网，就存在信息泄露和攻击的风险。本文，聚焦软件升级过程中，软件认证（Software Authentication）的相关知识点梳理。
1、VBT（Verification Block Table）

如果开发过Geely 2.0 BaseTec的小伙伴，对于VBT（Verification Block Table）应该不陌生。什么是VBT呢？它的作用是什么呢？搞软件开发的小伙伴应该清楚，软件程序分为多个部分，eg：Bootloader、Application、Calibration等。当编译器（Compiler）编译程序时，由于程序的不连续性，会使得每个部分包含多个Data Block。为了记录这些Data Block的location（包括数据块的起始地址和长度）以及hash values信息，设计了VBT，示意如下：



所以，VBT就像一个清单（manifest），用于记录每个Data Block的location和hash values，以便于快速验证每个数据块的数据完整性。

（一）VBT的生成阶段

VBT在哪个阶段生成呢？这里需要说明一下，大家在解读需求的时候，可能注意到：每个Data Block的hash values生成是针对原始数据（Raw Data），而不是经过压缩（Compression）或者加密（Encryption）处理后的数据。所以，当软件开发完成后，对原始的每个Data Block进行Hash计算，之后将每个Data Block信息存入VBT，如下所示：



（二）VBT格式

既然VBT用于记录每个Data Block的信息，是以怎样的格式记录信息呢？格式如下所示：

VBT Format Identifier ：表示选用的Hash算法，eg：0x00表示SHA256；

Number of Data Blocks：数据块个数;

Start Address：数据块起始地址；

Length：数据块长度；

Hash Value：数据块对应的Hash值。

（三）VBT对齐问题

VBT一般存储在Flash空间，而Flash的擦除和写操作都有最小限制。所以，这就会涉及到内存对齐（Align）的问题。由于内存对齐问题，VBT存储的信息不足最小对齐空间时，可以对剩余空间进行填充（Padding），示意如下所示：



如上图，VBT填充值会一同发送给ECU。
2、Root hash加密与验证

（一）什么是Root Hash?

如上，我们已经知道，VBT会存储每个Data Block的hash values。这样，虽然可以快速验证每个Data Block的完整性，但是，有一个前提：VBT记录的信息是完整且有效的。只有VBT记录的信息是完整的、有效的，再进行每个Data Block的完整性验证才是有意义的。所以，需要先对VBT也进行一次hash计算（eg：使用SHA256计算），生成的hash values称为Root Hash Values。

（二）如何加密和验证Root Hash Values

为了确保VBT的数据完整性，使用Hash算法（eg：SHA256）计算出Root Hash Values。同时，为了确保Root Hash Values不被外部截获，信任中心（Trust Centre）通过私钥（Private Key），使用非对称加密算法（eg：RSA-2048，适用于小数据加密）对Root Hash Values进行加密处理，生成对应的签名信息（Signature Info），当ECU收到签名信息以后，使用Private Key配对的Public Key对签名信息进行解密，得到Root Hash Values #1，同时，对刷写进ECU的VBT内容进行hash计算（eg：使用同样的SHA256算法），算出Root Hash Values#2，通过对比Root Hash Values #1与Root Hash Values #2即可知道VBT的完整性，如果VBT完整，即可进行后续的Data Block完整性验证，示意如下所示：



3、软件验签

（一）验签次数

软件验签（Software Signature）也称为内存检查（Check Memory），在工程中，会使用诊断的$31 01服务（Routine Control service，0x01代表start Routine）进行内存检查。为了提高刷写成功率，需求中可能会要求：如果第一次Verification失败，可以重试一次，但是，如果两次验证均失败，则验签不过，即：数据可能被篡改。

提示：一般需求中，Check Memory Result = 0x00，表示检查通过。

（二）验签时间

既然验签使用诊断指令，就会牵扯到P4_Server_Max时间，由于验签过程需要用到Hash算法、解密算法，需要消耗一定时间，因此，需求中会放宽此例程的诊断响应时间，eg：P4_Server_Max = 2000ms。也就意味着：Server收到Check Memory的$31服务后，可以先回复一个NRC0x78，争取额外的2000ms，但是，最终响应时间不能超过2000ms，否则，Tester（上位机）认为ECU（Server）响应超时，进而导致刷写失败。

关于P2和P4参数的理解，可以参考前文《Uds诊断：P2server与P4server时间，说点你不知道的》。

4、ESS（ECU Software Struct）

ESS（ECU Software Struct），如字面意思：ECU的软件结构，主要用于存储ECU的软件块信息，以便于Bootloader可以快速查找每个软件块信息。在Geely 2.0的规范中，ESS并没有做强制性的细节描述（除了包含一些必要的约束信息，其它信息可以自行定义），在实现上，供应商（Supplier）具有一定的自由度。

ESS的定义示例，如下所示：



如上图，强制包含的信息有：Logical Block的起始地址、长度，VBT位置，验证状态信息位置，擦除状态信息；非强制（可选）信息有：兼容性信息位置，VBT签名信息位置等。

ESS既然包含如此重要的软件结构信息，也意味着其本身的重要性。所以，在软件的刷写流程中，刷写SBL以后，第一个需要刷写的就是ESS。当然，验证时，也会第一个验证ESS的有效性。一般来说，软件开发到后期，逐渐趋于稳定，ESS架构一般不会改变，如果ESS没有改变，可以不用刷写ESS，如果软件块新增、合并程序或者软件模块超出了原有的Logical Block，即：改变了ESS结构时，需要重新更新ESS，并验证。

同时，在软件启动时，进行兼容性检查时，对比的兼容性信息即存储在ESS。

（一）ESS存储位置

在需求中，会明确要求：ESS应当存储在指定的Flash区域，这块区域可以是Bootloader所在的内存区。ESS所在的位置，只应PBL（Primary Bootloader）知道。

如果在指定Location，PBL没有获取到有效的ESS信息，则其它软件块不能被更新到ECU中，如下所示：



（二）本文的Logical Block与Data Block关系

一个Logical Block可以包含多个Data Block，示意如下：



提示：如上的Logical Block不要与芯片手册中的Logical Sector混淆。

话外音：当你觉得Geely2.0还未嚼透的时候，Geely3.0正在来的路上......