作者 | 李伟 上海控安安全测评中心安全测评部总监来源 |鉴源实验室

引言：第三篇(车载ECU嵌入式设备的诊断测试 - 服务)中我们已经把UDS的相关知识给大家做了介绍，主要讲解CAN通讯的地址和寻址、UDS的请求和响应数据帧、多帧数据的结构、部分UDS服务介绍，以及测试测试设计的注意事项说明。本篇以及后续两篇将会对UDS中最常用的服务进行详细介绍。本文首先对会话控制请求服务$10和安全接入请求服务$27进行介绍。

01

$10会话控制请求服务

ECU在正常工作时会处于某一个会话模式下，上电后会自动进入默认会话模式，所以ECU启动后我们不需要输入$10 01来进入该会话模式。ECU的不同会话模式间存在一定的状态转换关系规则。

初次接触会话控制模式可能不太理解这个服务的含义和用途，我们通过一个例子来进行类比。例如：我们将ECU之间的通讯类比成不同人员之间的对话。两个人在公共场所畅所欲言，随意讨论非私密性的话题，这个场景类似默认会话，不会对安全性有要求，无需刻意寻找专门使用场所，即不需要专门会话控制进入此模式，上电即默认进入。如果两人想讨论隐秘点的话题，不想其他不相关人员知道，于是换个环境，从公共场所进入了单独的会议室，这个过程可以类比成从默认会话进入了扩展会话，进入会议室后为了确认对方是本人没被冒充，进行识别鉴权询问口令“天王盖地虎”，查看对方能不能答出“小鸡炖蘑菇”，认证鉴权的这个附加过程就属于跟$10服务配合使用的安全接入请求服务$27，沟通结束退出会议室回到公共区域，这个过程就是从扩展会话退出到默认会话的过程。大家可能有疑问为何没提及编程会话，这个模式我们会另外讲解。

1.1 会话模式间的转换

前面的例子中我们可以看到不同会话模式间的切换存在一定的逻辑关系。下图显示的就是一个不同会话间转换示例图，需要注意的是不同项目中对于进入编程会话通常会有不同的设计要求，具体项目中会话间跳转关系必须依据项目的规范文件。

图 1

1）默认会话

设备上电后自动进入默认会话模式，从图中我们可以看出在默认会话模式下的切换关系。

本模式重新进入：可以通过$10 01再次进入默认会话，通过$11 01、$11 03复位服务重启进入默认会话。

本模式进入其他模式：默认会话模式可以通过$10 02进入编程会话模式，在有些项目中默认会话是不能直接进入编程会话模式，具体项目中是否能够支持需要查阅项目产品的诊断技术规范；默认会话模式下还可以通过$10 03进入扩展会话模式。

2）编程会话

启动编程会话ECU会进入boot模式，进入boot模式后ECU可以进行固件的更新。boot的更新可以通过Jtag接口使用工具进行烧录，相对来说Jtag接口的权限等级比较高，可以通过工具直接修改存储空间中对应地址的数据信息。实际项目会使用CAN网络来软件刷写，商用阶段去除Jtag接口，这样处理的话安全性会得到一定保障。同样的在boot模式下可以刷写固件，那很多诊断服务在boot下也可以正常执行，如配合刷写的$11、$22、$2E、$31、$28、$34、$36、$37、$85等服务。

本模式重新进入：处于编程会话模式下，可以通过$10 02再次进入编程会话。

本模式进入其他模式：编程会话状态下可以通过$10 01进入默认会话，通过$11 01服务复位ECU来进入默认会话；编程会话不能进入扩展会话模式。

3）扩展会话

某些服务需要扩展会话的支持才能执行，扩展会话下如果不配合使用$3E服务，ECU会在数秒后自动退出扩展会话模式进入到默认会话模式。

本模式重新进入：处于扩展会话模式下，可以通过$10 03再次进入扩展会话。

本模式进入其他模式：在不使用$3E服务保持会话时，可以通过超时自动退出到默认会话模式，可以通过$10 01进入默认会话，通过$11 01、11 03服务复位ECU来进入默认会话；在某些项目中仅支持$10 03扩展模式下，才能进入$10 02编程会话。

1.2 $10服务请求报文

$10服务的请求报文格式总体上跟上篇中描述服务发送报文内容一致。子服务通常是前文讲的01默认会话、02编程会话、03扩展会话，当然规范中还存在00保留字段、04安全系统诊断会话、05-3F保留、40-5F主机厂自定义字段、60-7E零部件供应商自定义字段等等。实际上主机厂可以根据项目情况进行高自由度的内部自定义，因为这些定义的范围都只是在当前项目适用，为了设计上的高复用性和减少设计研发工作量，要适当考虑自定义部分的占比。发送报文帧结构如下图：

图 2

举例，$10服务的请求报文通常为：$10 01、$10 02、$10 03，当然根据项目实际情况可以进行自定义子服务。

1.3 $10服务响应报文

$10服务的响应报文格式总体上跟上篇中报文发送内容格式一致。正响应报文的首字节服务号根据协议变为$50，第二字节对应请求报文的子功能。第3至4字节属性字段是跟ECU收到报文后发送第一帧响应报文间隔时间相关的计时器设置数值，第5至6字节是NRC中0x78否定响应报文发送和下一个消息发送间隔时间相关的计时器设置数值。响应报文帧的结构图如下所示：

图 3

举例，$10服务的响应报文通常为：$50 01、$50 02、$50 03。

$10服务的否定响应格式，可以参考上篇文章服务响应总体中负响应部分介绍，所有UDS服务的负响应故障代码表在项目中均是通用的。

02

$27安全控制服务

在本篇当中，我们之所以把这两个服务一起来进行介绍，是因为通常$27服务使用的前提就是先进入$10服务的扩展会话，反过来讲$10服务很少单独使用，一般都是跟$27服务配合先完成安全验证，然后其他服务才能在一定的会话模式和安全接入等级中正常使用。我们在前篇介绍过主机厂和零部件厂商可以通过不同的UDS服务对ECU执行很多操作，这些操作有的会修改ECU配置，有的可以重启设备，有的可以读取信息等等。显而易见的是，不同操作失误造成的后果严重程度是不一样的，因此通过安全认证就很有必要。我们通常把默认状态下的ECU叫做锁定状态（Locked），成功执行完成$27服务后的状态叫做解锁（Unlock），只有在解锁状态下才能进行数据写入、修改等等操作。

每次$27服务的安全认证过程在Tester和ECU间会有两轮的信息报文交互，大体的交互过程如下图所示：

图 4

2.1 请求报文

$27服务请求报文格式总体上跟上篇中UDS请求报文介绍一致，在交互过程图中我们可以看到$27服务发送了2次请求报文。

1）Seed请求报文

$27服务开始时，第1条发送报文是用于向ECU请求获取seed，seed通常由ECU根据算法随机生成（不会是固定数值）。Tester获取到seed后根据定义的算法算出key。$27服务根据项目诊断规范要求通常会有几个不同的安全级别（一般3个足够了），不同级别的区分通过报文第2字节子服务，即上图中2n-1字段来定义，通常有0x1、0x 3、0x 5、0x 7-0x 41（奇数）都可以由主机厂根据实际情况自定义选择，后面的0x43-0x7F很多用于预留，当然主机厂想用于自定义也不是不可以。

举例，本报文通常有$27 01、$27 05 、$27 09等等用于不同级别安全认证服务。具体安全等级个数和对应的子功能号均根据项目实际情况可以自定义实现。

2）Send key报文

$27服务的第2条发送报文是用于将计算好的key发送给ECU，key的计算都是基于和ECU使用的相同算法，以及ECU发出的seed。报文的第2字节子功能值跟第一条请求报文相关，通常是第1条报文子功能值加1，所以本报文的子服务为偶数。报文第3至6字节即为附带的key。

举例，本报文通常有27 02 XX XX XX XX、27 06 XX XX XX XX、27 0A XX XX XX XX。

2.2 响应报文

与请求报文相对应，$27服务的响应报文也为2条。响应报文的格式整体上跟上篇文章介绍的响应报文格式一致。

1）Send seed响应报文

$27服务ECU的第1条响应报文目的是向Tester发送seed，seed是一串随机数，长度由具体项目规范确定，seed的产生是ECU根据内置的算法随机产生的。ECU将seed发送给Tester时，本身也会根据seed值通过算法得出key值。

举例，本报文通常有67 01 XX XX XX XX、67 05 XX XX XX XX、67 09 XX XX XX XX。

2）解锁确认报文

解锁成功正响应报文，$27服务ECU的第2条响应报文，是ECU根据Tester发送过来的key，对比本身基于同样seed，同样算法计算出的key值，在两个key值相等的情况下，ECU通过安全认证服务，向Tester发送正响应，通知进入解锁状态成功。

举例，本报文通常有$67 02、$67 06、$67 0A。

3）负响应

负响应的报文格式可以参考上篇的相关章节，负响应NRC代码表一般在项目中是通用的。

03

总结

$10服务和$27服务通常是配套使用的。

通过上面的描述我们可以看到$27服务用来做安全等级认证，有几个关键的要点。一是seed计算，因为seed用于不同安全等级的key计算，且必须做好一定强度的防破解设计，所以通常情况下都会根据当前时间结合其他固定值，通过内部设计的算法来计算获得一串伪随机数，将这串伪随机数作为seed使用。二是key的计算方法，对应不同的安全认证等级，基于seed来计算key，算法在加密复杂度和数据交换速度之间做衡量。

用于$27服务认证的这套算法属于主机厂的秘密等级较高的信息，主机厂对零部件供应商释放时通常是以DLL库文件的方法进行发布，并释放调用方法的接口。

04

测试要点

对于$10服务的测试注意点在于：

· 不同模式间的转换实现是否跟规范要求一致；

· 其他服务在不同状态下的支持情况是否符合规范要求。

对于$27服务的测试注意点在于：

算法本身及dll文件一般都经过网络架构组内部测试才发布，不需要过多关注，需要测试注意的是零部件厂商对于key的计算，在项目初期经常会碰到大小端和移位导致的同样算法key不一致的情况。