UDS 安全认证29服务概述
一.服務(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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Nginx代理静态图片
- 下一篇: 求到达必败态的方法数 ZOJ 3067