UDS之29服務(wù)：認(rèn)證服務(wù)

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

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

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

背景知識(shí)介紹

對(duì)稱(chēng)加密：加密和解密使用相同密鑰的加密算法。

非對(duì)稱(chēng)加密：一對(duì)加密密鑰和解密密鑰，用戶(hù)加密后所得的信息，只能用該用戶(hù)的解密密鑰才能解開(kāi)。如果知道了其中一個(gè)，不能計(jì)算出另一個(gè)。公開(kāi)的加密密鑰為公鑰，不公開(kāi)的解密密鑰為私鑰。

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

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

單向認(rèn)證

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

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

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

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

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

雙向認(rèn)證

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

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

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

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

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

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

2.ACR認(rèn)證流程
圖3-ACR的認(rèn)證流程圖

ACR認(rèn)證前提條件

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

2.對(duì)稱(chēng)加密：和27服務(wù)的流程相似，在客戶(hù)端和服務(wù)端同時(shí)存在對(duì)稱(chēng)密鑰。

單向認(rèn)證

1.Client通過(guò)RequestChallengeForAuthentication請(qǐng)求驗(yàn)證(1)。

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

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

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

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

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

雙向認(rèn)證

1.Client通過(guò)SubFunction RequestChallengeForAuthentication請(qǐng)求驗(yàn)證(1)。

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

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

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

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

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

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

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

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

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