一．服務(wù)概述

此服務(wù)的目的是為客戶提供一種證明其身份的方法，允許其訪問數(shù)據(jù)和/或診斷服務(wù)，這些數(shù)據(jù)和/或診斷服務(wù)由于安全、排放或安全等原因而受到限制。 用于將例程或數(shù)據(jù)下載/上傳到服務(wù)器以及從服務(wù)器讀取特定內(nèi)存位置的診斷服務(wù)可能需要身份驗(yàn)證。 不正確的程序或下載到服務(wù)器的數(shù)據(jù)可能會(huì)潛在地?fù)p害電子設(shè)備或其他車輛部件，或危及車輛的排放、安全或安全標(biāo)準(zhǔn)的遵守。 另一方面，當(dāng)從服務(wù)器檢索數(shù)據(jù)時(shí)，可能會(huì)違反數(shù)據(jù)安全性。
該服務(wù)支持兩個(gè)安全概念:
概念 1 ：基于使用非對稱密碼的 PKI 證書交換過程。
概念 2 ：基于不帶 PKI 證書的挑戰(zhàn) – 應(yīng)答過程，使用帶有軟件身份驗(yàn)證令牌或?qū)ΨQ密碼的非對稱加密算法。
有關(guān)身份驗(yàn)證服務(wù)的概述，如下圖所示：

圖片摘自ISO 14229
子功能定義：
?“ deAuthenticate ”，此子功能參數(shù)有效地結(jié)束認(rèn)證狀態(tài)。
?“ VerfyCertificateUnidirectional ”，此子功能參數(shù)啟動(dòng)單向身份驗(yàn)證過程，僅針對 ECU 對測試儀進(jìn)行單向身份驗(yàn)證。
? “verifyCertificateBidirectional”， 這個(gè)SubFunction參數(shù)啟動(dòng)雙向身份驗(yàn)證過程，客戶端對服務(wù)器進(jìn)行身份驗(yàn)證，服務(wù)器對客戶端進(jìn)行身份驗(yàn)證。
?“ proofOfOwnership ”，此子功能參數(shù)用于將所有權(quán)證明數(shù)據(jù)傳輸?shù)綔y試儀。
?“ TransmitCertificate ”，此子功能參數(shù)獨(dú)立或在先前的身份驗(yàn)證之后傳輸證書。

二、基于PKI 證書交換的認(rèn)證Authentication with PKI Certificate Exchange (APCE)

前提條件：
雙方(客戶端和服務(wù)器)應(yīng)提供不同的證書(以及相應(yīng)的私鑰):
— 在單向身份驗(yàn)證的情況下，客戶端需要一個(gè)帶有其私鑰的證書，這允許客戶端將自己標(biāo)識(shí)為合法的客戶端。根據(jù)PKI的信任模型，服務(wù)器可能需要由頒發(fā)和簽署客戶端證書的頒發(fā)機(jī)構(gòu)(CA) 頒發(fā)和簽署的證書。
— 雙向認(rèn)證時(shí)，客戶端需要一個(gè)帶有私鑰的證書，以證明客戶端是合法的。此外，服務(wù)器還需要一個(gè)帶有私鑰的證書，這允許服務(wù)器將自己標(biāo)識(shí)為合法。根據(jù)公PKI的信任模型，客戶端和服務(wù)器可能需要證書頒發(fā)機(jī)構(gòu)(CA)頒發(fā)的證書，CA頒發(fā)并簽署了客戶端證書和服務(wù)器證書。

認(rèn)證流程

圖片摘自ISO 14229
認(rèn)證過程概述：
1 測試人員向 ECU 發(fā)出身份驗(yàn)證請求；
2. 在此請求消息中，包含測試儀的證書；
3. 收到請求消息后，ECU 將驗(yàn)證測試儀的證書；
4. 如果通過了證書驗(yàn)證，則 ECU 創(chuàng)建一個(gè)挑戰(zhàn) ；
5，6 取決于認(rèn)證所使用的算法及是否雙向認(rèn)證；
7.并將挑戰(zhàn)發(fā)送回測試人員；
8. 只是雙向認(rèn)證用到；
9.取決于認(rèn)證所用到的算法
10. 測試人員通過簽署挑戰(zhàn) ECU 來計(jì)算所有權(quán)證明測試人員；
11. 測試人員將所有權(quán)證明發(fā)送給 ECU ；
12. ECU 用收到的證書測試器中的公鑰驗(yàn)證所有權(quán)證明測試器；
13.用來創(chuàng)建會(huì)話密鑰（可選）；
14.設(shè)定訪問權(quán)限；
15. 如果通過了所有權(quán)證明的驗(yàn)證，則 ECU 返回響應(yīng)或者會(huì)話密鑰（會(huì)話密鑰可選）；
16，17，18用來設(shè)定會(huì)話密鑰
最后. ECU 響應(yīng)認(rèn)證成功。

三、基于挑戰(zhàn)應(yīng)答的認(rèn)證Authentication with Challenge-Response (ACR)

前提條件：
— 在使用非對稱加密的情況下，客戶端密鑰對必須存在:客戶端私鑰必須存在于客戶端，客戶端公鑰必須存在于服務(wù)器端。在雙向認(rèn)證的情況下，需要有一個(gè)額外的服務(wù)器密鑰對:服務(wù)器中需要有服務(wù)器私鑰，客戶端中需要有服務(wù)器公鑰。
— 在使用對稱加密的情況下，一個(gè)對稱密鑰應(yīng)該存在，并且應(yīng)該在客戶端和服務(wù)器之間預(yù)共享。
認(rèn)證流程
圖片摘自ISO 14229
認(rèn)證流程概述
1 測試人員通過 SubFunction requestChallengeForAuthentication 請求認(rèn)證。
2. ECU 創(chuàng)建挑戰(zhàn)
3. ECU 將挑戰(zhàn)發(fā)送給測試人員。（14229圖中的序號(hào)錯(cuò)誤應(yīng)該為3）
4. 雙向認(rèn)證時(shí)需要
5. 測試人員計(jì)算測試人員的所有權(quán)證明如下：
如果非對稱密碼時(shí):構(gòu)建適當(dāng)?shù)?特定于汽車制造商的)令牌(例如，基于CVC)內(nèi)容，包含令牌授權(quán)、身份驗(yàn)證、權(quán)限/角色、服務(wù)器端質(zhì)詢信息，以及客戶端質(zhì)詢信息和其他信息，視情況而定。使用客戶私鑰計(jì)算令牌內(nèi)容簽名，并構(gòu)建包含令牌內(nèi)容和簽名的客戶端身份驗(yàn)證令牌。產(chǎn)生的客戶端身份驗(yàn)證令牌是客戶端POWN。
如果使用對稱密碼：使用預(yù)共享的對稱密鑰，通過 ECU 側(cè) Challenge 來計(jì)算簽名（例如，一次簽名 或 HMAC 或 CMAC ）。生成的簽名是測試者方 POWN 。
6. 如果服務(wù)器在步驟3中指示了其他參數(shù)，那么客戶端在需要的附加參數(shù)中提供適當(dāng)?shù)母郊訁?shù)。
7. 測試人員通過子功能 verifyProofOfOwnershipUnidirectional 發(fā)送測試人員端 POWN 。
8. ECU 驗(yàn)證測試儀側(cè) POWN 。
11. 如果驗(yàn)證成功，ECU 根據(jù)訪問權(quán)限授予對診斷對象的訪問權(quán)限。
9，10，12~16 取決于是否雙向認(rèn)證和是否需要會(huì)話密鑰

四、服務(wù)格式

具體服務(wù)格式請參考ISO 14229-1 2020版

總結(jié)

以上是生活随笔為你收集整理的UDS 安全认证29服务概述的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。