UDS诊断系列之七安全访问(27）服务(番外）附录I

这篇具有很好参考价值的文章主要介绍了UDS诊断系列之七安全访问(27）服务(番外）附录I。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

附录I的主要内容是通过一个状态图来描述ECU在安全访问的各状态之间的切换条件，以及如何进行状态切换即切换过程中都需要执行哪些操作。

一、状态图

下面直接先上图。
UDS诊断系列之七安全访问(27）服务(番外）附录I,UDS诊断,网络,网络协议,汽车
图看起来流程很多，但实际上很简单，先说图中的四个状态：
A - ECU没有接收过任何安全访问的请求，或者刚刚接收并处理完非默认诊断会话请求之后的状态；
B - ECU接收到了请求种子的请求且已经响应了种子，但没有接收到密钥，也就是在等待诊断仪发送密钥的状态；
C - ECU已经认证通过了一个安全等级处于已解锁状态，并且没有收到任何请求种子的请求；
D - ECU已经认证通过了一个安全等级处于解锁的状态，同时收到了新的不同安全等级请求种子的请求并已经发送了种子，在等待诊断仪发送密钥的状态。

其中，状态A和状态C相比，以及状态B和状态D相比，都只差了是否已经解锁了一个安全等级。

二、安全访问策略说明

在解释状态图的10个状态转换之前，先对安全访问的一个通用策略简单地说明一下。
安全认证算法增加破解难度的通用做法就是增加算法中使用的种子和密钥长度，以此来增加计算的复杂程度，从而增加计算过程的时间，使时间加长。但是UDS一开始是用在CAN/LIN总线这种报文长度比较短的传输协议上，因此使用长种子会比较不方便，在不改变种子和密钥长度的情况下，一般会采取限制尝试次数和两次尝试之间的最短时间的策略。
下面是这种策略所用到的一些参数，这里尽可能通俗的去说一下参数的具体用处。
Delay_Timer：两次安全访问尝试的最短时间，即当安全访问尝试失败达到一定次数之后，ECU应该开启此计时器来限制后续的尝试频率。这个时间长度是可以配置的，并且可以根据实际需求由OEM定义是否需要在ECU启动或者复位的时候也启用这个定时器。可以所有安全等级用同一个定时器，也可以每个安全等级都分配一个定时器。甚至，这个定时器可以是一个可变值，例如可以随着尝试失败的次数增加而增加。
Att_Cnt_Limit：这个参数就是安全访问失败的次数限制，当达到这个次数之后，就会开启Delay_Timer来限制安全访问的频率。
Att_Cnt：这个参数用来记录实际安全访问尝试失败的次数，每次安全访问尝试失败这个计数器都会加1，和Att_Cnt_Limit配合来实现限制安全访问尝试的功能。
这三个参数相互配合，可以实现一整套的机制。举个例子，设置Delay_Timer = 10s, Att_Cnt_Limit = 3, Att_Cnt初始为0，每次安全访问失败Att_Cnt都会增加1，当失败次数达到Att_Cnt_Limit即3的时候，定时器开始计时，在时间达到Delay_Timer之前，安全访问请求将被拒绝并给出否定响应。
除此之外，还有一个Static_Seed参数，用来表示是否需要ECU在特定条件下响应相同的种子，这个在下一章节会详细说明。

三、状态切换说明

接着说第一章里的图，前面解释了图里的四个状态，除了状态之外，还有10个跳转的路径未说明，接下来就简单聊聊。
ISO里是通过表格来进行的说明，多少有些抽象，我重新整理一下按图里的编号作为小章节号来逐一说明，可能会更容易理解一些。

ECU启动之后直接进入状态A，这里的启动包括正常的上电操作，复位操作以及网络唤醒操作。在此过程中，如果有支持第二章描述的策略，则初始化Att_Cnt这个参数为0或者上次关闭时候保存的值，这里需要按OEM的策略要求执行，同时如果OEM有要求启动计时器，也会启动Delay_Timer这个计时器。
从状态A切换到状态B，需要同时满足4个条件，包括两个强制的和两个可选的。两个强制的条件是收到请求种子的报文和报文的长度正确，两个可选的条件是根据OEM的要求来做的，分别是满足执行请求的前置条件和延时时间结束。有些OEM会处于驾驶安全考虑，在执行一些服务之前要先检查条件，如车速和发动机转速等，主要目的是为了防止车辆在运动过程中执行一些有潜在安全威胁的操作。为了增加破解的时间，防止通过不停地重启来缩短Delay_Timer的时间，有些OEM也会要求ECU上电之后即开启计时器。满足前面提到的条件后，ECU开始生成并存储种子，保存当前的子功能也就是安全等级，并把种子通过响应发送给请求方，然后切换到状态B。
从状态B切换到状态C，也需要同时满足4个条件，这些条件都是强制的。其实只是一些基本的服务检查，即必须是收到了发送密钥的请求，子功能和已经保存的子功能是一对儿（即发送密钥的子功能是请求种子的子功能加1），报文长度和密钥都要没有问题。检查完条件，ECU会将当前安全等级切换到解锁装填，如果支持第二章的策略，则需要将Att_Cnt清零，如果这个参数是要在NVM里保存的，这时候也需要进行更新，如果Static_Seed = true，这时候也需要对之前生成的种子清零，最后通过一个肯定响应告诉诊断仪安全访问执行成功。
这一条切换路径主要是指哪些情况下ECU会保持在当前状态，以及检测到问题之后需要给出什么响应。
- 请求种子报文的长度不正确，响应NRC13；
- 收到发送密钥的请求，响应NRC24；
- 请求种子报文长度正确，检查到条件不正确，响应NRC22；
- 请求种子报文长度正确，检查的条件正确，但是延时的时间未到，响应NRC37；
- 其他一些通用的否定响应，具体可参照系列第三篇通用的响应那里；
- 该子功能（安全等级）的延时时间到了，Att_Cnt需要清零并存储到NVM里（前提是支持该功能）。这里需要注意的是很多OEM并不会在这个时候让Att_Cnt清零，而仅仅是减1来增加破解的时间。
前面提到状态B和D很相似，所以这条路径也是一样的，共分为三种情况：
- 收到安全访问的请求种子的请求报文，Static_Seed参数配置为false，此时ECU应当对请求的安全等级生成新的种子，并通过肯定响应将种子发给诊断仪；
- 收到安全访问的请求种子的请求报文，Static_Seed参数配置为true并且请求的安全等级有已经保存的种子，此时ECU应当通过肯定响应将保存的种子发给诊断仪；
- 收到安全访问的请求种子的请求报文，Static_Seed参数配置为true但请求的安全等级因为跟当前已经请求过的安全等级不同，这时候没有已经保存的种子，此时ECU应当对请求的安全等级生成新的种子，并通过肯定响应将种子发给诊断仪；
从状态C到状态A的切换比较简单，即收到诊断会话模式的请求，或者发生了S3超时，这时候ECU在完成会话模式切换的同时，也需要将已经解锁的安全访问等级给重新恢复到锁定状态。
这条状态转换和4相似，只多出来了收到已经解锁的安全等级的请求种子报文的情况，这时候ECU应当给出肯定响应，响应里的种子用0代替。
当ECU在状态C的时候收到了跟已经解锁的安全等级不一样的请求种子报文时，如果报文长度、需要检查的条件都正常，并且延时时间已经到了，如果先前没有生成，这时候ECU应当生成并保存种子，同时保存请求的安全等级，最后通过肯定响应将种子发送给诊断仪。
从状态B切换到状态A的条件比较多，下面逐条说明：
- 收到了发送密钥的报文，安全等级、报文长度简单都没问题，但是密钥错误，如果这时候使用了第二章的策略，并且(Att_Cnt+1) < Att_Cnt_Limit，那么Att_Cnt++，并且要保存到NVM里（如果OEM要求有此功能），响应NRC35(密钥错误)。
- 收到了发送密钥的报文，安全等级、报文长度简单都没问题，但是密钥错误，如果这时候使用了第二章的策略，并且(Att_Cnt+1) >= Att_Cnt_Limit，那么Att_Cnt++，并且要保存到NVM里（如果OEM要求有此功能），开启安全访问延时，响应NRC36(密钥错误)。
- 如果收到的发送密钥报文安全等级和先前请求种子时候的安全等级不一致，那么ECU需要响应NRC24,安全计访问失败计数器不变。
- 如果收到的发送密钥报文安全等级和先前请求种子时候的安全等级一致，但是报文长度错误，那么ECU需要响应NRC13，安全计访问失败计数器不变。
- 收到了诊断会话模式的请求，或者发生了S3超时，这时候ECU在完成会话模式切换的同时，也需要将已经解锁的安全访问等级给重新恢复到锁定状态。
- 其他一些通用的否定响应，具体可参照系列第三篇通用的响应那里。
- 收到了请求种子的报文，但是报文长度不正确，ECU需要响应NRC13.
状态D切换到状态C和上一条稍有些不同，响应NRC13、NRC24、NRC35和NRC36以及其他NRC的条件和执行的动作都是一致的（注意这里关于NRC36执行的动作，我理解是笔误），少了会话模式切换的条件，因为那是跳转编号6，多出来两条新的跳转条件：文章来源地址https://www.toymoban.com/news/detail-693453.html
- 收到安全访问请求种子的报文，如果请求的安全等级正是当前解锁的等级，那么需要响应全零的种子；
- 收到发送密钥的报文，安全等级、报文长度和密钥都正确，这时候也要切换到状态C，但这里要注意的是，此时的状态C已经不是先前的状态C了，解锁的安全等级变了。切换过程主要几件事，新的安全等级的Att_Cnt计数器清零并保存，之前已经解锁的安全等级重新锁定，如果Static_Seed参数配置为true，那么需要清空先前生成的种子，发送肯定响应。