服務概述
汽車工業的很多領域都有嚴格的國際標準，其中針對車載診斷的ISO14229規定了車載診斷服務的通用需求(UDS)，UDS主要應用于OSI模型的應用層，UDS協議根據功能的不同定義了26種診斷服務。
為了應對網聯汽車日益增加的安全風險，在ISO14229-1的2020版本增加了29服務。29服務英文名稱為Authentication Service，譯為認證服務。通過名稱可以看出29服務的目的是為客戶提供一種身份認證的方法。當客戶想獲取一些有訪問限制的數據時來驗證客戶的身份，這些限制可能是由于安全或排放相關的原因。本文將詳細介紹29服務。

29服務一般在如下場景中使用

1.需要讀取特定內存地址的數據；2.上傳或下載控制器數據；3.關于車身安全或者會影響車身控制器屬性。傳統的27服務不能滿足這些需求，因此新版本的ISO14229協議增加了29服務，來實現基于以太網的身份認證。

背景知識介紹

對稱加密：加密和解密使用相同密鑰的加密算法。

非對稱加密：一對加密密鑰和解密密鑰，用戶加密后所得的信息，只能用該用戶的解密密鑰才能解開。如果知道了其中一個，不能計算出另一個。公開的加密密鑰為公鑰，不公開的解密密鑰為私鑰。

PKI：PKI的全稱是Public Key Infrastructure，譯為公鑰基礎設施。PKI是包括硬件、軟件、人員、策略和規程的集合，用來實現基于公鑰密碼體制的密鑰和證書的產生、管理、存儲、分發和撤銷等功能。用來建立不同實體間的“信任”關系。

服務介紹
29服務支持兩種認證方式，如下圖所示：APCE: 采用非對稱加密的基于PKI證書交換程序的認證ACR: 采用對稱或非對稱加密的基于挑戰確認（Challenge-Response）流程的認證。圖1-29服務支持的兩種認證方式1.APCE認證流程圖2-APCE的認證流程圖
上圖是APCE的認證流程圖，包括單向認證和雙向認證。

單向認證

1.Client通過VerifyCertificateUnidirectional(2)向Server發送帶有Client公鑰的證書。

2.Server收到證書后會驗證證書的有效性(3)，如果Client不合法，則停止流程，驗證失敗，返回否定響應，如果合法則繼續之后的流程。

3.Server創建Challenge(4)，并向Client發送針對證書的Challenge消息(7)，請求Client對所發證書的所有權證明，消息中包含認證所需的隨機數。

4.Client收到Challenge后使用私鑰計算所有權證明客戶端(10)，并且通過SubFunction ProofOfOwnership(11)發送所有權證明客戶端。

5.Server使用來自Client的公鑰驗證所有權客戶端(12)，與Challenge消息比較，如果驗證成功，則根據訪問權限(14)，授予對診斷對象的訪問權限。并向Client發送相應的響應,表示認證成功。

雙向認證

1.Client創建Challenge客戶端(1)，并通過SubFuntion Vertify Certificate Bidire- ntional向Server發送Challenge客戶端和含有公鑰的證書客戶端。

2.Server驗證證書是否有效(3)，如果無效，則驗證失敗，返回否定響應。如果有效，則進行后續的流程。

3.Server創建Challenge服務端，并且通過客戶端發來的Challenge和自己的私鑰計算出所有權證明(6)，并向Client發送Challenge服務端、服務端證書、服務端的所有權證明以及臨時公鑰(7)。

4.Client根據所得的臨時公鑰驗證服務器證書和所有權證明是否有效(8)，有效之后根據服務端發來的Challenge和客戶端私鑰計算客戶端所有權證明(10)，并通過ProofOfOwnership向Server發送客戶端所有權證明(11)。

5.Server收到所有權證明后進行驗證是否通過(12)，通過后發送訪問權限(14)以及相應的響應(15)，認證成功。

圖中(5)，(9)跟安全診斷通信有關，(16)，(17)，(18)跟創建會話密鑰有關。

2.ACR認證流程
圖3-ACR的認證流程圖

ACR認證前提條件

1.非對稱加密：具有客戶端密鑰對：客戶端存在客戶端私鑰，服務器中存在客戶端公鑰。如果是雙向認證的話，還需要在服務器端加個密鑰對：客戶端存在服務器公鑰，服務器端存在服務器私鑰。

2.對稱加密：和27服務的流程相似，在客戶端和服務端同時存在對稱密鑰。

單向認證

1.Client通過RequestChallengeForAuthentication請求驗證(1)。

2.Server創建Challenge數據(2)并發送Challenge數據(3)。

3.Client計算所有權證明(5)。

4.Client通過VerifyProofOfOwnershipUnidirectional發送所有權證明(7)。

5.Server驗證所有權證明(8)，如果驗證成功發送訪問權限。

其中(14)，(15)，(16)是關于建立會話密鑰使用的。

雙向認證

1.Client通過SubFunction RequestChallengeForAuthentication請求驗證(1)。

2.Server創建Challenge數據(2)，并且發送Challenge數據(3)。

3.Client創建Challenge數據(4)，并且計算Client所有權證明，并通過VerifyProofOfOwnershipBidirectional發送給服務器端(7)。

4.Server驗證所有權證明(8)。

5.如果驗證成功，Server計算所有權證明(9)，并且發送訪問權限(11)。

6.Client驗證服務器的所有權證明(13)，如果驗證成功，訪問成功。

3.子功能介紹（部分）
表1-29服務部分子功能

CANdelaStudio中配置29服務
在CANdelaStudio中打開CDDT文件，選擇Protocol Service,在這里可以對29服務的請求和響應的格式進行編輯。
圖4-29服務編輯
打開CDD文件，在Base Variant下選擇Authentication，就可以對29服務的參數進行編輯。
圖5-29服務參數編輯
在States下Dependencies可以配置每個服務在各個狀態下的支持情況。
圖6-服務狀態編輯

CANoe中29服務的實現
以CANoe中29服務的Demo工程為例，來介紹29服務的認證過程。
圖7-29服務Demo工程
在診斷控制臺中可以看到關于29服務的一些子功能。每個子功能都有不同的作用，每個認證方法的區別在于發送的子功能不同。可以根據上面的流程來決定使用哪些子功能，例如要用APCE單向認證方法的話，發送29 01和29 03服務，APCE雙向認證的話發送29 02和29 03服務。用哪一個認證方法是OEM自定義的。
圖8-29服務子功能
在使用29服務之前，需要配置29服務相關的文件，打開Simulation->SecurityManager->Open Security Manager，在這里就可以導入關于29服務的文件（X.509）。
圖9-29服務配置
在設置好29服務文件后，在Security Configuration就會顯示剛才創建的文件，將證書和通道匹配好后就可以發送29服務。
圖10-29服務證書和通道匹配
在Panel面板中，可以發送29服務，選擇單向認證或者雙向認證。發送之后在Trace中可以查看認證的過程。
圖11-29服務Panel面板

總結
29服務和27服務的功能比較相似，都是為了防止ECU的數據和軟件安全受到威脅，但是27服務提供的安全機制已經不能滿足現在車輛診斷功能面臨的新的安全威脅，29服務就是為了彌補這些缺陷而產生的。由于27服務的安全訪問控制手段缺乏靈活性，29服務引入了PKI和證書認證體系，可以靈活地給診斷的參與者分配權限,29服務還適用于多客戶端，在車輛網聯化共享化的趨勢下很好的應對了這些新的安全威脅。