认识UDS诊断29认证服务-Authentication Service
目录:
1.概述
29服务是在ISO 14229-2020版本中首次增加的为应对网联汽车日益增加的安全风险的新服务。
此服务的目的顾名思义是为client和server之间的身份认证提供一种方法,以便对意图获取一些有访问限制的数据或服务操作时验证client的身份,这些限制可能是由于安全或排放相关的原因。需要认证服务保护的情况包括:调用server的例程服务,数据的上传或下载相关服务、通过诊断服务读取内存中特定地址存储的数据。除server对client的认证外,某些情况下client也需要对server身份的合法性进行确认,从数据流向的两个方向考虑,未经认证的操作都有可能为车辆电气系统带来危害或违反数据安全要求。
2. 背景知识
在了解29服务之前需要了解几个标准中提到的信息安全概念:
1) 客户端向服务器发出认证请求;
2) 认证服务器判定用户是否合法,若不是,则不做进一步的处理;
3) 认证服务器内部产生一个随机数,作为Challenge,发送给用户;
4) 客户将口令和随机数合并,使用单向哈希函数 ( 例如MD5算法 ) 生成一个字节串作为Response;
5) 认证服务器将Response与自己的计算结果比较,如两者相同,则通过一次认证,反之认证失败;
6) 认证服务器通知客户端认证成功或失败。
3. 服务介绍
29服务支持两种安全概念:
3.1 APCE:
认证流程图:
上图既包含单向认证(对client的认证)也包含双向认证的过程,除此以外还包含认证成功后的安全诊断通信(secure diagnostic communication)所需的密钥传递过程。
双向认证中client对server的认证流与单向认证流程无异,只是方向相反,所以为了使流程清晰易懂,下面针对单项认证流程单独说明。
以单项认证为例,省略加密诊断通信所需的密钥交换流程后的简化流程图如下:
对于支持安全诊断通信的client和server,在认证过程中同步使用Diffie-Hellman算法生成密钥,密钥生成流程请参考博文:Diffie-Hellman密钥协商算法 - Qcer - 博客园 (cnblogs.com)
3.2 ACR:
相对于APEC基于成熟PKI,ACR则是将认证功能的定义交给主机厂,ACR的前提条件:
认证流程图:
ACR认证流程与APCE相似,且相对更简单,其中计算所有权证明的方法如下:
使用ACR方式时,前一次认证中激活的诊断访问权限可以由新的ACR认证流程代替
3.3 下表列出了认证服务支持的子功能
SID |
Name |
Description |
00 |
deAuthenticate |
Request to leave the authenticated state 无其他请求参数 |
01 |
verifyCertificateUnidirectional |
Initiate Authentication by verifying the Certificate 请求包含:
|
02 |
verifyCertificateBidirectional |
Initiate Authentication by verifying the Certificate and generating a Proof of Ownership from the server 参数同上 |
03 |
proofOfOwnership |
Verify the Proof of Ownership from the client. 请求包含:
|
04 |
transmitCertificate |
Verify Certificate and extract information from Certificate to handle it according to its contents. 请求包含:
|
05 |
requestChallengeForAuthentication |
Initiate the Authentication process by requesting server to output a challenge. 请求包含:
|
06 |
verifyProofOfOwnershipUnidirectional |
Request server to verify the POWN for unidirectional authentication. 请求包含:
|
07 |
verifyProofOfOwnershipBidirectional |
Request server to verify the client side POWN and provide server-side POWN for bidirectional authentication. 参数同上 |
08 |
authenticationConfiguration |
Indicates the provided authentication configuration of the server. 无请求参数 |
3.4 认证服务的通用需求
4. 服务实现
实现认证服务,若使用APEC方式需要PKI的支持,若使用ACR方式则需要自定义相关元素并建立安全体系支持。
对于认证服务的需求,除标准定义内容外OEM还需要额外定义如下内容:
5. 与27服务的比较
了解了29服务的定义后,熟悉诊断的不免会有个疑问:29服务和27服务很相似,为什么有了27服务为什么还要定义29服务?
先来看下27服务在标准里的说明:
The purpose of this service is to provide a means to access data and/or diagnostic services, which have restricted access for security, emissions, or safety reasons. Diagnostic services for downloading/uploading routines or data into a server and reading specific memory locations from a server are situations where security access may be required. Improper routines or data downloaded into a server could potentially damage the electronics or other vehicle components or risk the vehicle’s compliance to emission, safety, or security standards. The security concept uses a seed and key relationship.
再看下29服务的说明(如概述):
The purpose of this service is to provide a means for the client to prove its identity, allowing it to access data and/or diagnostic services, which have restricted access for, for example security, emissions, or safety reasons. Diagnostic services for downloading/uploading routines or data into a server and reading specific memory locations from a server are situations where authentication may be required. Improper routines or data downloaded into a server could potentially damage the electronics or other vehicle components or risk the vehicle’s compliance to emission, safety, or security standards. On the other hand, data security might be violated when retrieving data from a server
可以看到提供27和29服务的目的几乎完全相同,都是对诊断仪的合法性进行确认,从而保护ECU的数据和软件安全受到威胁,区别仅在于使用的方法不同。由此可以推断 29服务的诞生是由于27服务提供的安全机制已经不能满足现在车辆诊断功能面临的新的安全威胁,而这些新的安全威胁则是在车辆网联化共享化的趋势下产生的,即随着车载以太网的应用普及,任意一台互联网设备理论上都可以通过DoIP访问车辆的诊断功,进行数据获取或执行诊断操作,这在为OTA,远程诊断等功能带来益处的同时也给车辆带来更多的潜在风险,对意图使用诊断功能的设备的认证至关重要,原有的27服务机制简单,不适用于多客户端,防护等级低,很难起到保护作用。
27服务和29服务的差异对比如下表
维度 |
27服务 |
29服务 |
认证方法 |
种子-密钥 |
基于PKI的认证/OEM自定义 |
加密方式 |
对称加密 |
对称/非对称加密 |
算法 |
CRC(定义较为简单) |
信息安全标准定义的安全算法 ISO/IEC 9798 HMAC or CMAC or GMAC |
实现机制 |
不区分来源,分多级保护(01, 03...) |
针对不同的诊断来源实现差异化定义(研发,工厂,售后,供应商) |