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

29服務(wù)一般在如下場景中使用

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

背景知識介紹

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

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

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

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

單向認證

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

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

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

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

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

雙向認證

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

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

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

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

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

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

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

ACR認證前提條件

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

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

單向認證

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

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

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

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

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

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

雙向認證

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所有權(quán)證明，并通過VerifyProofOfOwnershipBidirectional發(fā)送給服務(wù)器端(7)。

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

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

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

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

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

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

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