1、服务概述
汽车工业的很多领域都有严格的国际标准，其中针对车载诊断的ISO14229规定了车载诊断服务的通用需求(UDS)，UDS主要应用于OSI模型的应用层，UDS协议根据功能的不同定义了26种诊断服务。
为了应对网联汽车日益增加的安全风险，在ISO14229-1的2020版本增加了29服务。29服务英文名称为Authentication Service，译为认证服务。通过名称可以看出29服务的目的是为客户提供一种身份认证的方法。当客户想获取一些有访问限制的数据时来验证客户的身份，这些限制可能是由于安全或排放相关的原因。本文将详细介绍29服务。
29服务一般在如下场景中使用：
- 需要读取特定内存地址的数据；
- 上传或下载控制器数据；
- 关于车身安全或者会影响车身控制器属性。
传统的27服务不能满足这些需求，因此新版本的ISO14229协议增加了29服务，来实现基于以太网的身份认证。
2、背景知识介绍
对称加密：加密和解密使用相同密钥的加密算法。
非对称加密：一对加密密钥和解密密钥，用户加密后所得的信息，只能用该用户的解密密钥才能解开。如果知道了其中一个，不能计算出另一个。公开的加密密钥为公钥，不公开的解密密钥为私钥。
PKI：PKI的全称是Public Key Infrastructure，译为公钥基础设施。PKI是包括硬件、软件、人员、策略和规程的集合，用来实现基于公钥密码体制的密钥和证书的产生、管理、存储、分发和撤销等功能。用来建立不同实体间的“信任”关系。
3、服务介绍
29服务支持两种认证方式，如下图所示：
APCE: 采用非对称加密的基于PKI证书交换程序的认证
ACR: 采用对称或非对称加密的基于挑战确认（Challenge-Response）流程的认证。
3.1APCE认证流程
上图是APCE的认证流程图，包括单向认证和双向认证，
3.1.1单向认证
- Client通过VerifyCertificateUnidirectional(2)向Server发送带有Client公钥的证书。
- Server收到证书后会验证证书的有效性(3)，如果Client不合法，则停止流程，验证失败，返回否定响应，如果合法则继续之后的流程。
- Server创建Challenge(4)，并向Client发送针对证书的Challenge消息(7)，请求Client对所发证书的所有权证明，消息中包含认证所需的随机数。
- Client收到Challenge后使用私钥计算所有权证明客户端(10)，并且通过SubFunction ProofOfOwnership(11)发送所有权证明客户端。
- Server使用来自Client的公钥验证所有权客户端(12)，与Challenge消息比较，如果验证成功，则根据访问权限(14)，授予对诊断对象的访问权限。并向Client发送相应的响应,表示认证成功。
3.1.2双向认证
- Client创建Challenge客户端(1)，并通过SubFuntion Vertify Certificate Bidire- ntional向Server发送Challenge客户端和含有公钥的证书客户端。
- Server验证证书是否有效(3)，如果无效，则验证失败，返回否定响应。如果有效，则进行后续的流程。
- Server创建Challenge服务端，并且通过客户端发来的Challenge和自己的私钥计算出所有权证明(6)，并向Client发送Challenge服务端、服务端证书、服务端的所有权证明以及临时公钥(7)。
- Client根据所得的临时公钥验证服务器证书和所有权证明是否有效(8)，有效之后根据服务端发来的Challenge和客户端私钥计算客户端所有权证明(10)，并通过ProofOfOwnership向Server发送客户端所有权证明(11)。
- Server收到所有权证明后进行验证是否通过(12)，通过后发送访问权限(14)以及相应的响应(15)，认证成功。
图中(5)，(9)跟安全诊断通信有关，(16)，(17)，(18)跟创建会话密钥有关。
3.2ACR认证流程
3.2.1ACR认证前提条件
- 非对称加密：具有客户端密钥对：客户端存在客户端私钥，服务器中存在客户端公钥。如果是双向认证的话，还需要在服务器端加个密钥对：客户端存在服务器公钥，服务器端存在服务器私钥。
- 对称加密：和27服务的流程相似，在客户端和服务端同时存在对称密钥。
3.2.2单向认证
- Client通过RequestChallengeForAuthentication请求验证(1)。
- Server创建Challenge数据(2)并发送Challenge数据(3)。
- Client计算所有权证明(5)。
- Client通过VerifyProofOfOwnershipUnidirectional发送所有权证明(7)。
- Server验证所有权证明(8)，如果验证成功发送访问权限。
其中(14)，(15)，(16)是关于建立会话密钥使用的。
3.2.3双向认证
- Client通过SubFunction RequestChallengeForAuthentication请求验证(1)。
- Server创建Challenge数据(2)，并且发送Challenge数据(3)。
- Client创建Challenge数据(4)，并且计算Client所有权证明，并通过VerifyProofOfOwnershipBidirectional发送给服务器端(7)。
- Server验证所有权证明(8)。
- 如果验证成功，Server计算所有权证明(9)，并且发送访问权限(11)。
- Client验证服务器的所有权证明(13)，如果验证成功，访问成功。
3.3子功能介绍（部分）
|
SubFunction |
Name |
Description |
|
29 00 |
DeAuthenticate |
主动结束认证状态 |
|
29 01 |
VerifyCertificateUnidirectional |
启动单向身份验证过程，仅针对服务器对客户端进行身份验证 |
|
29 02 |
VerifyCertificateBidirectional |
启动双向身份验证过程，以针对服务器验证客户端和针对客户端验证服务器 |
|
29 03 |
ProofOfOwnership |
用于将所有权证明数据传输给客户端 |
|
29 04 |
TransmitCertificate |
独立地或在先前的认证之后传输证书 |
|
29 08 |
AuthenticationTask |
身份验证服务用于身份验证、去身份验证和显式证书传输 |
表1-29服务部分子功能
4、CANdelaStudio中配置29服务
在CANdelaStudio中打开CDDT文件，选择Protocol Service,在这里可以对29服务的请求和响应的格式进行编辑。
打开CDD文件，在Base Variant下选择Authentication，就可以对29服务的参数进行编辑。
在States下Dependencies可以配置每个服务在各个状态下的支持情况。
5、CANoe中29服务的实现
以CANoe中29服务的Demo工程为例，来介绍29服务的认证过程。
在诊断控制台中可以看到关于29服务的一些子功能。每个子功能都有不同的作用，每个认证方法的区别在于发送的子功能不同。可以根据上面的流程来决定使用哪些子功能，例如要用APCE单向认证方法的话，发送29 01和29 03服务，APCE双向认证的话发送29 02和29 03服务。用哪一个认证方法是OEM自定义的。
在使用29服务之前，需要配置29服务相关的文件，打开Simulation->Security
Manager->Open Security Manager，在这里就可以导入关于29服务的文件（X.509）。
在设置好29服务文件后，在Security Configuration就会显示刚才创建的文件，将证书和通道匹配好后就可以发送29服务。
在Panel面板中，可以发送29服务，选择单向认证或者双向认证。发送之后在Trace中可以查看认证的过程。
6、总结
29服务和27服务的功能比较相似，都是为了防止ECU的数据和软件安全受到威胁，但是27服务提供的安全机制已经不能满足现在车辆诊断功能面临的新的安全威胁，29服务就是为了弥补这些缺陷而产生的。由于27服务的安全访问控制手段缺乏灵活性，29服务引入了PKI和证书认证体系，可以灵活地给诊断的参与者分配权限,29服务还适用于多客户端，在车辆网联化共享化的趋势下很好的应对了这些新的安全威胁。
北汇信息专注于其汽车电子网络通信、诊断刷写、逻辑功能测试开发服务，期待进一步沟通交流、共享合作的机会。
参考文献：ISO14229-1(2020)
注：图片部分来源于ISO14229-1(2020)、CANoe16、CANdelaStudio18