目录
1.概述
2. 背景知识
3. 服务介绍
4. 服务实现
5. 与27服务的比较
1.概述
29服务是在ISO 14229-2020版本中首次增加的为应对网联汽车日益增加的安全风险的新服务。
此服务的目的顾名思义是为client和server之间的身份认证提供一种方法，以便对意图获取一些有访问限制的数据或服务操作时验证client的身份，这些限制可能是由于安全或排放相关的原因。需要认证服务保护的情况包括：调用server的例程服务，数据的上传或下载相关服务、通过诊断服务读取内存中特定地址存储的数据。除server对client的认证外，某些情况下client也需要对server身份的合法性进行确认，从数据流向的两个方向考虑，未经认证的操作都有可能为车辆电气系统带来危害或违反数据安全要求。
2. 背景知识
在了解29服务之前需要了解几个标准中提到的信息安全概念：
- 对称加密：通信双方加密和解密使用相同的密钥
- 非对称加密：通信双方各有一对密钥，分为公钥和私钥，信息的加密使用公钥，解密使用私钥，公钥双方共享，私钥只有自己知道，以此避免消息泄露
- PKI 是Public Key Infrastructure的首字母缩写，翻译过来就是公钥基础设施；PKI是一种遵循标准的利用公钥加密技术为电子商务的开展提供一套安全基础平台的技术和规范。PKI技术是一种遵循既定标准的密钥管理平台，它的基础是加密技术，核心是证书服务，支持集中自动的密钥管理和密钥分配，能够为所有的网络应用提供加密和数字签名等密码服务及所需要的密钥和证书管理体系。通俗理解：PKI就是利用公开密钥理论和技术建立提供安全服务的、具有通用性的基础设施，是创建、颁发、管理、注销公钥证书所涉及的所有软件、硬件集合体，PKI可以用来建立不同实体间的"信任"关系，它是目前网络安全建设的基础与核心。PKI的主要任务是在开放环境中为开放性业务提供基于非对称密钥密码技术的一系列安全服务，包括身份证书和密钥管理、机密性、完整性、身份认证和数字签名等。因此，用户可利用PKI平台提供的服务进行电子商务和电子政务应用。 PKI详解 - 运维-小松松 - 博客园 (cnblogs.com)
- CVC is a public-key certificate that is stored in a very compact format 在一个在非常紧凑格式下存储的公钥证书 Card Verifiable Certificate (memim.com)
- X.509 是密码学里公钥证书的格式标准。X.509证书里含有公钥、身份信息(比如网络主机名，组织的名称或个体名称等)和签名信息（可以是证书签发机构CA的签名，也可以是自签名）。对于一份经由可信的证书签发机构签名或者可以通过其它方式验证的证书，证书的拥有者就可以用证书及相应的私钥来创建安全的通信，对文档进行数字签名
- 证书的组成结构（参考）：
-
- 证书
- ...
- 公钥算法
- 主体公钥 [1]
- 此日期前无效
- 此日期后无效
- 版本号
- 序列号
- 签名算法
- 颁发者
- 证书有效期
- 主体
- 主体公钥信息
- 颁发者唯一身份信息（可选项）
- 主体唯一身份信息（可选项）
- 扩展信息（可选项）
- 证书签名算法
- 数字签名
- 证书
- Diffie-Hellman密钥协商算法 一个用于解决秘钥配送问题的算法，本身并非用来加密，在标准中用于为ECU之间的加密通信传输密钥 Diffie-Hellman密钥协商算法 - Rookie丶flying - 博客园 (cnblogs.com)
- 挑战确认（Challenge-Response）认证流程：
1) 客户端向服务器发出认证请求；
2) 认证服务器判定用户是否合法，若不是，则不做进一步的处理；
3) 认证服务器内部产生一个随机数，作为Challenge，发送给用户；
4) 客户将口令和随机数合并，使用单向哈希函数 ( 例如MD5算法 ) 生成一个字节串作为Response；
5) 认证服务器将Response与自己的计算结果比较，如两者相同，则通过一次认证，反之认证失败；
6) 认证服务器通知客户端认证成功或失败。
3. 服务介绍
29服务支持两种安全概念：
- APCE: 采用非对称加密的基于PKI证书交换程序的认证
- ACR: 采用对称或非对称加密的基于挑战确认（Challenge-Response）流程的认证
3.1 APCE：
认证流程图：
上图既包含单向认证（对client的认证）也包含双向认证的过程，除此以外还包含认证成功后的安全诊断通信（secure diagnostic communication）所需的密钥传递过程。
双向认证中client对server的认证流与单向认证流程无异，只是方向相反，所以为了使流程清晰易懂，下面针对单项认证流程单独说明。
以单项认证为例，省略加密诊断通信所需的密钥交换流程后的简化流程图如下：
- client发送证书至server，证书中包含client的公钥
- server收到证书后确认证书的有效性（使用PKI提供的证书有效性检查功能），验证client是否合法，若不合法则停止认证流程，返回否定响应，合法则继续认证流程
- server发送针对证书的challenge消息，请求client对所发证书的所有权证明（proof of ownership），消息中包含认证所需随机数
- client接收到challenge后使用私钥对接收到的随机数进行计算得到签名，放入响应消息中发给server
- server使用client的公钥解密并验证应答消息中的签名信息，与challenge消息比较，向client回复认证结果
对于支持安全诊断通信的client和server，在认证过程中同步使用Diffie-Hellman算法生成密钥，密钥生成流程请参考博文：Diffie-Hellman密钥协商算法 - Qcer - 博客园 (cnblogs.com)
3.2 ACR：
相对于APEC基于成熟PKI，ACR则是将认证功能的定义交给主机厂，ACR的前提条件：
- 如果采用非对称加密算法，则需要具有client密钥对：client侧存有client私钥，server侧存有client公钥，如果是双向认证还需要有相似的一对service密钥；
- 如果采用对称加密算法，则应存在一对client和server同时预先存储的密钥，于27服务类似。
认证流程图：
ACR认证流程与APCE相似，且相对更简单，其中计算所有权证明的方法如下：
- 对于非对称加密来说与APCE流程类似，需要建立包含challenge数据，令牌授权，认证，以及可选的附加信息等令牌内容，并使用私钥计算得到令牌内容签名，生成的认证令牌包含令牌内容及签名。接收方使用公钥解密并使用相同方法计算令牌内容，验证计算结果是否一致，从而完成对认证结果的判断。令牌的生成推荐基于ISO/IEC 9798-2 或 ISO/IEC 9798-4 (mutual, three pass authentication)，或与之相当的认证令牌。
- 对于对称加密来说，需要基于先前共享的对称密钥来计算签名信息，对方也根据相同的密钥进行解密，计算及比对完成验证。令牌的生成推荐基于ISO/IEC 9798-2 或 ISO/IEC 9798-4 (mutual, three pass authentication)，或与之相当的认证令牌。
使用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 认证服务的通用需求
- 认证服务和诊断会话以及安全等级没有直接关系，换句话说一旦client和server完成认证，则在认证有效期范围内认证流程配置相关的诊断服务都是可以访问的，有效期可以定义为基于时间，里程或直到收到“deauthenticate”请求
- client和server的认证状态应和某个诊断通道相关联，基于多用户的服务器系统，多个client可使用不同的认证配置在多个诊断通道上处理
- 支持认证服务的ECU需支持NRC-34 Authentication required
- 会话密钥（Session key）作为可选项用于后续server和client之间安全的通信
4. 服务实现
实现认证服务，若使用APEC方式需要PKI的支持，若使用ACR方式则需要自定义相关元素并建立安全体系支持。
对于认证服务的需求，除标准定义内容外OEM还需要额外定义如下内容：
- 使用的加密算法，算法元素的定义等
- 算法所需元素的生成，分发及存储方法和流程
- 对推出已认证状态策略的定义，如超时时间，里程数等
- 认证失败的处理机制定义，如设计最大尝试次数，认证请求间隔等
- 对于server已通过client认证，但client对server的认证失败的情况，由OEM定义是否client需要发送deauthentication子功能断开连接以确保server离开已认证状态，拒绝进一步的请求
- APCE
- 证书格式
- 对于已经通过认证的client想要进一步激活其他权限或证明已签名的数据时可以使用transmitcertificate子功能，而无需再次通过挑战-响应过程通过认证，此操作所拆传输的数据需要经过私钥进行签名（数据与签名分别发送至server）。通过证书激活更多权限的方法需要OEM进行定义，若使用此方法时，应使用不同的certificateEvaluationId加以区分
- ACR
- 密钥的分发，存储，管理的方法和流程
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...） | 针对不同的诊断来源实现差异化定义（研发，工厂，售后，供应商） |
