车载诊断服务及安全要点

概述

汽车工业领域的很多功能都有严格的国际标准，比如针对车载诊断的ISO 14229规定了车载诊断服务的通用需求（UDS）。车载诊断作为汽车上的一个重要的功能，具备多项针对ECU进行操作的能力，如诊断、数据传输及刷写等，因此其安全性也是安全设计和安全研究人员关注的重点。

UDS对诊断的需求描述长达四百多页，想要全面、深入地学习可以阅读ISO的文档，但是站在安全设计者或研究者的角度，我们没有必要如此面面俱到，只需要把握要点即可。

UDS的要点我认为主要包含如下几个方面：

CS通信架构

请求-应答式的服务调用过程

不同的会话模式

不同的安全等级

需要重点关注的安全相关内容包括：

会话模式

安全访问服务

认证服务（page463）

刷写服务

Routine Control服务

UDS规范简介

UDS 即ISO-14429规范，诊断服务的实现可以理解为一种特殊的网络服务，其架构也遵循OSI七层架构，UDS主要描述诊断的应用层需求，UDS与OSI的对应关系如下图所示：

 

其中14429-1定义与数据链路无关的通用诊断需求， 根据传输协议的不同分为基于控制局域网的诊断DoCAN（ISO15765）或者基于以太网的诊断DoIP（ISO13400）。

 

 

C/S架构

UDS遵循C/S架构，一般来说以诊断仪（Tester）为Client，以ECU为Server，诊断的过程即诊断仪与ECU进行通信的过程，如下图所示：

Tester通过不同的SID调用不同的服务，ECU通过返回肯定或否定响应来反馈服务调用的结果。

请求的格式：

1. 有subfunction的诊断请求

Service ID(SID)标识调用的诊断服务，长度为1个字节。Sub-function标识具体的操作，比如开始、停止等，长度也是1个字节。Param为传递给诊断服务的参数，长度不固定。

1. 无sub-function的诊断请求

无子功能的请求相比而言只是缺少了sub-function ID。

响应的格式：

Diagnostic响应分为肯定响应和否定响应，积极响应表示ECU执行了诊断仪发过来的请求，否定响应表示ECU因为某种原因无法执行诊断仪的请求。

肯定响应的格式如上图所示，由三部分组成，其中response ID这个字节作为诊断请求的回显，它等于SID + 0X40。后面的两个部分则视具体的诊断服务而定。

否定的长度为3个字节，第一个字节为0x7F，第二个字节是被拒绝掉的SID，第三个字节是这个诊断服务无法被执行的原因。

请求-应答式服务调用过程

Tester向ECU发送如下消息：

请求 request

请求-确认 req-confirm

诊断应用层发送如下消息向ECU中诊断应用的服务函数传送数据：

指示 indicate

ECU中诊断应用的服务函数发送给Tester的响应：

响应 response

响应-确认 res-confirm

确认 confirm

服务分为有确认的服务和没有确认的服务，这里的确认指的是ECU在接收到消息之后是否会给出反馈，有确认服务会给出反馈，而无确认服务不会发出反馈，两种服务的消息时序图如下所示：

 

有确认服务

 

无确认服务

会话模式

Session可以理解为ECU的运行模式，不同模式对应的诊断权限不同，因此可运行的诊断服务也不一样。ECU上电后默认运行在defaultSession模式，这个模式可以认为是最低权限模式，很多诊断服务不能在这个模式下运行，但如果切换到 extendedDiagnosticSession模式之后，可运行的诊断服务就变多了。

安全比较关注的一个Session是ProgrammingSession，在这个Session中可以对ECU的软件进行刷写。

 

上图描述了不同类型Session之间的可转换途径，UDS使用0x10号服务（DiagnosticSessionControl）来实现Session的转换。从一种Session转换成另一种Session或同一种Session都需要重新初始化对应的服务，当转换到权限要求比较高的Session时，需要调用0x27号服务（AccessControl）解锁服务，因此Session实际上是UDS安全访问控制机制实现的基础。

安全访问（0x27号服务）

安全访问Service 0x27（SecurityAccess）用于解锁诸如ECU程序刷写等高权限服务，其应用模型如下：

1）client requests the “Seed”

2）server sends the “Seed”

3）client sends the “Key” (appropriate for the Seedreceived)

4）server responds that the “Key” was valid and that it willunlock itself

解锁模型的过程如下所示：

1）诊断仪以Service27子服务请求Seed，0x1代表安全等级，根据实际情况确定；

2）ECU接受到此请求后，返回包含Seed值的响应，例如0x36、0x57；

3）诊断仪根据解锁算法算出Key的值，并以偶数位子服务0x2发送给ECU；

4）ECU根据解锁算法得到key’，并与Key值比较，当Key == Key’时，解锁成功；

5）ECU发送肯定响应。

在实际项目中，一个ECU可以包含多个安全等级（Unlocked Level），常见情况是Bootloader和App各有一个不同的安全等级。

认证（Service 0x29）

由于0x27的安全访问控制手段缺乏灵活性，UDS 2020版本中增加了0x29服务，用于ECU对诊断仪的身份认证。0x29引入了PKI和证书认证体系，可以灵活地给诊断的参与者分配权限。

0x29服务一般在如下场景中使用：

1）需要读取特定内存地址的数据；

2）上传或下载控制器数据；

3）关于车身安全或者会影响车身控制器属性。

传统的0x27服务不能满足这些需求，因此新版本UDS协议新增0x29服务，来实现基于以太网的身份认证。

认证服务有两种实现模式：

1）基于PKI证书交换的非对称解密；

2）基于不带PKI证书的挑战-应答过程。

 

带PKI证书的非对称认证和不带PKI证书的挑战-应答式认证

基于PKI的非对称认证的流程：

 

基于不带PKI证书的质询-响应过程，其使用带有软件身份验证令牌的非对称解密或对称解密：