GB 44495 - 7.3 软件升级安全要求

7.3.1 通用安全要求

7.3.1.1 车载软件升级系统应通过安全保护机制,保护车载软件升级系统的可信根、引导加载程序、系统固件不被篡改,或在被篡改后,通过安全保护机制使其无法正常启动。
测试方法：
测试人员应依据车辆制造商提供的车载软件升级系统的可信根、引导加载程序、系统固件的安全保
护机制的安全证明文件,判定车辆是否满足7.3.1.1的要求
剖析：
在GB44496中，车载软件升级系统的定义为，安装在车端并具备直接继承，分发和校验来自车外升级包等用于实现软件升级功能的软件和硬件。一样平常情况下，在设计OTA架构时，会选择一个OTA master，行业内通常选用车机IVI,中央网关大概T-box作为OTA master，OTA master会与云端举行控制指令的交互，比犹如步车云信息，看看是否有新的升级包发布，另外，OTA master还会承担车内部分ECU的升级包的下载和校验以及分发，但是，像ADAS这种升级包比较大的ECU，通常会自己去云端下载升级包，而不经过OTA master下载后再分发。当然，未来智驾座舱和T-BOX融为一个ECU的时间，有可能就是一个完整的OTA master了，承担所有ECU的升级包下载，校验和分发的任务。
但是，7.3.1.1提到的是支持车载升级系统的ECU要有安全启动的能力，防止篡改，目前，车载的嵌入式系统无论是linux/QNX/安卓/RTOS,安全启动功能根本上是标配，由于测试安全启动功能相对比较复杂，所以检测机构要求整车厂提供设计或内测文档即可。

7.3.1.2 车载软件升级系统不应存在由汽车行业权势巨子毛病平台6个月前公布且未经处置惩罚的高危及以上
的安全毛病。
注1:汽车行业权势巨子毛病平台如车联网产物专用毛病库NVDB-CAVD等当局主管部门承认的其他毛病平台。
注2:处置惩罚包罗消除毛病、订定减缓措施等方式。
测试方法：
测试人员应使用毛病扫描工具对车载软件升级系统举行毛病扫描,并将测试结果与汽车行业权势巨子毛病平台6个月前公布的高危及以上的安全毛病清单和车辆制造商提供的车载软件升级系统毛病处置惩罚方案举行比对,判定车辆是否满足7.3.1.2的要求。
剖析：
这一条和7.1.1.1一样，7.1.1.1要求毛病扫描的对象为具有远程控制系统和安装第三方应用的ECU,这两系统一样平常为T-box和车机IVI, 假如车厂把OTA master摆设在T-box大概车机IVI，那么这一条就和7.1.1.1要求完全一样了，不必再重新做一遍了，但是，假如整车厂将OTA master摆设再中央网关大概其他ECU，那么就要针对此ECU在做一遍扫描，扫描的内容与7.1.1.1一样。

7.3.2 在线升级安全要求

7.3.2.1 车辆和在线升级服务器应举行身份认证,验证其身份的真实性,并在下载制止恢复时重新
验证。
注:常见的认证方式包罗使用证书举行身份认证。
测试方法：
测试人员应依据车辆制造商提供的在线升级服务器清单及接纳的通信协议类型,并按照以下三种
测试方法中适用的测试方法开展测试,判定车辆是否满足7.3.2.1的要求。
a) 若车辆与在线升级服务器接纳专用网络或虚拟专用网络情况举行通信,测试人员应根据企业
提供的在线升级服务器身份认证安全功能的证明文件,确认车辆是否满足7.3.2.1的要求。
b) 若车辆与在线升级服务器接纳公共网络情况举行通信,且使用公有通信协议,测试人员应使用
测试装备举行数据抓包,剖析通信报文数据,检查车辆是否对在线升级服务器举行身份真实性
验证;制止下载并恢复,使用测试装备举行数据抓包,剖析通信报文数据,检查是否重新举行身
份真实性验证。若使用测试装备无法举行数据抓包,测试人员应根据企业提供的在线升级服
务器身份认证安全功能的证明文件,确认车辆是否满足7.3.2.1的要求。
c) 若车辆与在线升级服务器接纳公共网络情况举行通信,且使用私有通信协议,测试人员应根据
企业提供的在线升级服务器身份认证安全功能的证明文件,确认车辆是否满足7.3.2.1的
要求。
剖析：
这一条和7.2.1一样，7.2.1提到与云平台通信时要做身份验证，OTA的后台服务器也是云平台的一种，目前车厂常见的OTA通信协议为HTTP+TLS大概MQTT+TLS, 前面反复提到，TLS提供了身份验证和数据加密传输的能力，所以通过抓包就可以看到TLS协议中使用了证书做身份验证。区别在于，有的车厂使用单向认证，即车端验证服务端，有的车厂实行双向认证，即服务端也会验证车端。单向认证是最低要求。

7.3.2.2 车辆应对下载的升级包举行真实性和完整性验证。
测试方法：
测试人员应按照以下测试方法依次开展测试,判定车辆是否满足7.3.2.2的要求。
a) 使用车辆制造商提供的正常升级包触发在线升级,测试升级功能是否正常。
b) 确认在线升级功能正常后,构造真实性和完整性被破坏的升级包,并依据车辆制造商提供的方
法和权限,将真实性和完整性被破坏的升级包下载或传输到车端,实行软件升级,测试是否升
级乐成。若车辆的信息安全防护机制不支持将真实性和完整性被破坏的升级包下载或传输到
车端,则依据车辆制造商提供的在线升级信息安全防护机制证明文件,检查车辆是否满足
7.3.2.2的要求。
剖析：
这一条相对容易测试，测试机构首先验证正常正当的升级包是否能够升级乐成，升级乐成后，通过篡改升级包的签名或文件，然后将篡改的升级包上传云端，触发OTA 升级，检察车端大概云端是否出现升级失败的征象。

7.3.2.3 应对在线升级过程中发生的信息安全事件日志举行记录,日志存储时长应不少于6个月。
测试方法：
测试人员应按照以下测试方法依次开展测试,判定是否满足7.3.2.3的要求:
a) 构造升级安全事件,检查是否存在在线升级信息安全事件日志;
b) 检查日志记录的时间跨度是否不少于6个月或是否具备留存日志不少于6个月的能力。
剖析：通常和OTA相干的信息安全事件包罗升级包签名校验失败，完整性校验失败，解密失败，下载失败，更新失败等。即使没有GB44495的要求 , 这些事件也会在OTA升级功能设计阶段定义好，协助整车厂排查标题。
log既可以存储在云端也可以存储在车端，通常车端的存储空间有限，跨度6个月的log更得当存在在云端。

7.3.3 离线升级安全要求

7.3.3.1 若车辆使用车载软件升级系统举行离线升级,车辆应对离线升级包真实性和完整性举行验证。
测试方法：
测试人员应分别构造被伪造、被篡改的升级包,使用离线升级工具将该升级包下载或传输到车载
端,实行离线升级,判定车辆是否满足7.3.3.1的要求。
剖析：
由于汗青原因和兼容性标题，很少有车企将车载软件系统既用于在线升级又用于离线升级，由于两者的协议一样，一个是http/mqtt协议，一个是UDS协议，但是不排除像特斯拉大概小米如许的公司，会将两者集成在车载升级系统中。
其实，无论是离线升级照旧在线升级，对升级包举行完整性和真实性校验都是根本要求，数字签名是实现真实性和完整性的常见技术。

7.3.3.2 若车辆不使用车载软件升级系统举行离线升级,应采取保护措施保证刷写接入端的安全性,或
验证升级包的真实性和完整性。
测试方法：
测试人员应按照如下测试方法中适用的测试方法开展测试,判定车辆是否满足7.3.3.2的要求:
a) 将非认证的刷写接入端接入车辆刷写接口并实行离线升级,测试车辆是否能辨认非认证的刷
写接入端;
b) 分别构造被伪造、被篡改的升级包
剖析：
一样平常情况下车内没有一个完整的车载软件升级系统举行离线升级，最常见的是，通过OBD直接访问对应的ECU,没有ECU有所谓的bootloader，实现升级包的下载，校验和安装，革新工具（诊断仪）通过诊断ID寻址到对应的ECU,举行升级流程。
对于刷写接入端，即诊断仪，使用UDS27/29服务举行验证诊断仪是不是正当的诊断仪，这背后是使用一些暗码学的机制来实现认证，例如数字签名，PKI等，这种情况下，假如革新的对象是BMS(电池管理系统)，那么肯定是BMS会对诊断仪做验证，而非某个ECU代替BMS验证诊断仪。另外，对升级包的验证也是云云，BMS自己验证升级包是不是真实完整的，而不是有别的ECU代劳。革新其他的ECU也是这个道理。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。