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

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

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

背景知識介紹

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

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

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

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

單向認證

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

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

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

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

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

雙向認證

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

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

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

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

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

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

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

ACR認證前提條件

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

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

單向認證

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

2.Server創(chuàng)建Challenge數(shù)據(jù)(2)并發(fā)送Challenge數(shù)據(jù)(3)。

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

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

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

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

雙向認證

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

2.Server創(chuàng)建Challenge數(shù)據(jù)(2)，并且發(fā)送Challenge數(shù)據(jù)(3)。

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

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

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

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

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

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

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

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