UDS - 深论Security Access Service

Posted 2022-12-06 诊断协议那些事儿

诊断协议那些事儿

诊断协议那些事儿专栏系列文章，本文将结合27服务SecurityAccess，介绍小编在工作中对其的思考。

对于标准协议可参考：27服务-SecurityAccess

27服务的初衷就是防止无权限人员进行非法数据操作，用来确保车辆ECU的安全，如果任何持有诊断设备的人都可以通过诊断指令对车辆ECU进行操作，将存在较大的安全隐患。为了验证产线、售后的操作人员是否有权限操作，在对车辆ECU进行诊断检查时，需要验证其提供的密钥是否有效，而产生有效密钥的前提需要ECU反馈给诊断设备一个随机的种子Seed，如果Seed不具有随机性，不法分子将通过大量的重试来破解密钥，只有Seed具有随机性，才能确保每次产生的Key不同，因此诊断设备每次应发送不同的密钥来进行解锁。

---

文章目录

• 诊断协议那些事儿
• 27服务-SecurityAccess
• • I.27服务发送seed，已解锁的情况下seed = 0
  • II.扩展会话跳转扩展会话，需要重新解锁
  • III.ECU产生随机种子
  • IV.否定响应解析
• 总结

---

27服务-SecurityAccess

在诊断开发和测试的过程中，大家首先会接触到会话管家（0x10）和安全卫士（0x27），本文将结合开发过程中一些常见的问题展开论述，
①客户端请求“种子”
②服务器发送“种子”
③客户端发送“密钥”（适用于已接收到种子）
④服务器确认“密钥”有效，做出响应，并自行解锁。

※生成种子的目的是为了产生独一无二的密钥(Key)，以便解锁ECU。
一般Bootloader和Application中，会使用不同Key算法，以保证升级更加复杂的安全校验。
在诊断应用中：奇数位请求Seed，偶数位发送Key值，需成对出现。

I.27服务发送seed，已解锁的情况下seed = 0

如果服务器支持安全访问，但在收到SecurityAccess 'requestSeed’消息时请求的安全级别已经解锁，该服务器应响应SecurityAccess 'requestSeed’正向响应消息服务，其种子值为零(0)。服务器将永远不会为当前锁定的给定安全级别发送全零种子。客户端应该使用这种方法通过检查非零种子来确定服务器是否被锁定为特定的安全级别。

II.扩展会话跳转扩展会话，需要重新解锁

当Server从非默认会话跳转非默认会话，包括相同会话的跳转（10 03再次进入10 03）,Server需要重新初始化Session，意味着：进入的非默认会话需要重新安全解锁，即：重新执行0x27服务。

III.ECU产生随机种子

Request: 10 03
Response:50 03 00 32 01 F4
Request: 27 11
Response:67 11 12 34 56
Request: 27 12 23 45 67
Response:67 12
Request: 27 11
Response:67 11 00 00 00

在已解锁的情况下，请求种子会返回0值。在实际测试过程中，我们进入非默认会话以后，可以多次执行request seed子服务，而不执行Key的对比子服务，以此验证种子的随机性，ECU又是如何产生随机种子的呢？
产生种子随机性的方法一般有如下手段：
①使用C库函数rand()和srand()
②使用HSM提供的真随机数接口函数

**srand()**是随机数发生器的初始化函数：

void srand(unsigned int seedForRand) 

srand()的作用主要是为rand()函数提供一个随机的种子，注意：srand()提供的种子并不是ECU产生的Seed，ECU要产生的Seed实质是rand()生成的随机数。

如果srand()的形参seedForRand每次提供的都一样，那么rand()之后产生的随机数也会是一样的，比如：使用srand(10)为rand()提供随机种子，每次运行如下进程，rand()都会产生同样的随机数。

#include <stdio.h>
#include <stdlib.h>
 
int main()
 
  /* 初始化随机数发生器 */
  srand((unsigned) 10); 

  /* 输出随机数，即ECU所需要的Seed */
  printf("Seed = 0x%x\\n", rand());
  
  getchar();
  return(0);

每次运行结果均为：Seed = 0x47
为了防止产生的随机数相同，就必须确保srand()每次传入的参数值不同。
在实际开发过程中经常使用系统定时器（SysTimer）

FUNC(Std_ReturnType, DCM_Server_CODE) SecurityAccess_Level_XXX_Unlocked_GetSeed(Dcm_OpStatusType OpStatus, P2VAR(uint8, AUTOMATIC, RTE_DCM_SERVER_APPL_VAR) Seed, P2VAR(Dcm_NegativeResponseCodeType, AUTOMATIC, RTE_DCM_SERVER_APPL_VAR) ErrorCode)

  #define  XXX_SEEDNUMBER           4

  uint8 index;
  Std_ReturnType ret = RTE_E_INVALID;
  /* 获取STM_TIM0寄存器的Tick值：STM_TIM0_VALUE */
  uint32 tick = STM_TIM0_VALUE;

  srand(tick);

  if(Seed != NULL_PTR)
  
    for(index = 0; index < XXX_SEEDNUMBER; index++)
    
      /* 填充Seed，即ECU响应所需的随机Seed */
      Seed[index] = (uint8)rand();
    
    XXX_SetDeed(seedValue);
    ret = RTE_E_OK;
  

  return ret;

IV.否定响应解析

在功能实现以及关于Service27测试时，NRC35、36、37是一组极其特别的NRC。
在需求规范中，定义Tester允许尝试解锁次数3次(Att_Cnt=3),Delay_Timer为10s。定义27 01/27 02解锁安全等级Level_1，Seed以及Key长度为3 bytes。

ISO14229-1 2020版 Table I.2 — State transitions – disjunctive normal form representation

解析：Tester尝试解锁ECU，第一次发送错误Key值，控制器响应NRC 35，等到第三次尝试解锁，控制器响应NRC 36（表示尝试次数已>=3），这时再去请求Seed值，会响应NRC 37，意味着需要等待Delay_Timer时间。可类比手机解锁，当使用者连续几次解锁失败后，手机会设置等待时间，这期间不允许尝试解锁，目的是防止持续破解，保护安全。经过Delay_Timer后Att_Cnt = 0【具体依赖车厂需求制定，在2020版之前往往是Att_Cnt-1,如下图，只有正确的安全解锁后，Att_Cnt清零！】

---

总结

以上就是今天要讲的内容，欢迎各位评论，提出宝贵意见，小编也会持续更新，以提供更好的作品。