认识UDS诊断29认证服务-Authentication Service
目錄
1.概述
2. 背景知識
3. 服務介紹
4. 服務實現
5.?與27服務的比較
1.概述
29服務是在ISO 14229-2020版本中首次增加的為應對網聯汽車日益增加的安全風險的新服務。
此服務的目的顧名思義是為client和server之間的身份認證提供一種方法，以便對意圖獲取一些有訪問限制的數據或服務操作時驗證client的身份，這些限制可能是由于安全或排放相關的原因。需要認證服務保護的情況包括：調用server的例程服務，數據的上傳或下載相關服務、通過診斷服務讀取內存中特定地址存儲的數據。除server對client的認證外，某些情況下client也需要對server身份的合法性進行確認，從數據流向的兩個方向考慮，未經認證的操作都有可能為車輛電氣系統帶來危害或違反數據安全要求。
2. 背景知識
在了解29服務之前需要了解幾個標準中提到的信息安全概念：
- 對稱加密：通信雙方加密和解密使用相同的密鑰
- 非對稱加密：通信雙方各有一對密鑰，分為公鑰和私鑰，信息的加密使用公鑰，解密使用私鑰，公鑰雙方共享，私鑰只有自己知道，以此避免消息泄露
- PKI?是Public Key Infrastructure的首字母縮寫，翻譯過來就是公鑰基礎設施；PKI是一種遵循標準的利用公鑰加密技術為電子商務的開展提供一套安全基礎平臺的技術和規范。PKI技術是一種遵循既定標準的密鑰管理平臺，它的基礎是加密技術，核心是證書服務，支持集中自動的密鑰管理和密鑰分配，能夠為所有的網絡應用提供加密和數字簽名等密碼服務及所需要的密鑰和證書管理體系。通俗理解：PKI就是利用公開密鑰理論和技術建立提供安全服務的、具有通用性的基礎設施，是創建、頒發、管理、注銷公鑰證書所涉及的所有軟件、硬件集合體，PKI可以用來建立不同實體間的"信任"關系，它是目前網絡安全建設的基礎與核心。PKI的主要任務是在開放環境中為開放性業務提供基于非對稱密鑰密碼技術的一系列安全服務，包括身份證書和密鑰管理、機密性、完整性、身份認證和數字簽名等。因此，用戶可利用PKI平臺提供的服務進行電子商務和電子政務應用。?PKI詳解 - 運維-小松松 - 博客園 (cnblogs.com)
- CVC?is a public-key certificate that is stored in a very compact format 在一個在非常緊湊格式下存儲的公鑰證書?Card Verifiable Certificate (memim.com)
- X.509?是密碼學里公鑰證書的格式標準。X.509證書里含有公鑰、身份信息(比如網絡主機名，組織的名稱或個體名稱等)和簽名信息（可以是證書簽發機構CA的簽名，也可以是自簽名）。對于一份經由可信的證書簽發機構簽名或者可以通過其它方式驗證的證書，證書的擁有者就可以用證書及相應的私鑰來創建安全的通信，對文檔進行數字簽名
- 證書的組成結構（參考）：
-
- 證書
- ...
- 公鑰算法
- 主體公鑰?[1]
- 此日期前無效
- 此日期后無效
- 版本號
- 序列號
- 簽名算法
- 頒發者
- 證書有效期
- 主體
- 主體公鑰信息
- 頒發者唯一身份信息（可選項）
- 主體唯一身份信息（可選項）
- 擴展信息（可選項）
- 證書簽名算法
- 數字簽名
- 證書
- Diffie-Hellman密鑰協商算法?一個用于解決秘鑰配送問題的算法，本身并非用來加密，在標準中用于為ECU之間的加密通信傳輸密鑰?Diffie-Hellman密鑰協商算法 - Rookie丶flying - 博客園 (cnblogs.com)
- 挑戰確認（Challenge-Response）認證流程：
1) 客戶端向服務器發出認證請求；
2) 認證服務器判定用戶是否合法，若不是，則不做進一步的處理；
3) 認證服務器內部產生一個隨機數，作為Challenge，發送給用戶；
4) 客戶將口令和隨機數合并，使用單向哈希函數 ( 例如MD5算法 ) 生成一個字節串作為Response；
5) 認證服務器將Response與自己的計算結果比較，如兩者相同，則通過一次認證，反之認證失敗；
6) 認證服務器通知客戶端認證成功或失敗。
3. 服務介紹
29服務支持兩種安全概念：
3.1 APCE：
認證流程圖：
?
上圖既包含單向認證（對client的認證）也包含雙向認證的過程，除此以外還包含認證成功后的安全診斷通信（secure diagnostic communication）所需的密鑰傳遞過程。
雙向認證中client對server的認證流與單向認證流程無異，只是方向相反，所以為了使流程清晰易懂，下面針對單項認證流程單獨說明。
以單項認證為例，省略加密診斷通信所需的密鑰交換流程后的簡化流程圖如下：
?
對于支持安全診斷通信的client和server，在認證過程中同步使用Diffie-Hellman算法生成密鑰，密鑰生成流程請參考博文：Diffie-Hellman密鑰協商算法 - Qcer - 博客園 (cnblogs.com)
3.2 ACR：
相對于APEC基于成熟PKI，ACR則是將認證功能的定義交給主機廠，ACR的前提條件：
認證流程圖：
?
ACR認證流程與APCE相似，且相對更簡單，其中計算所有權證明的方法如下：
使用ACR方式時，前一次認證中激活的診斷訪問權限可以由新的ACR認證流程代替
3.3 認證服務支持的子功能
| SID | Name | Description |
| 00 | deAuthenticate | Request to leave the authenticated state 無其他請求參數 |
| 01 | verifyCertificateUnidirectional | Initiate Authentication by verifying the Certificate 請求包含：
|
| 02 | verifyCertificateBidirectional | Initiate Authentication by verifying the Certificate and generating a Proof of Ownership from the server 參數同上 |
| 03 | proofOfOwnership | Verify the Proof of Ownership from the client. 請求包含：
|
| 04 | transmitCertificate | Verify Certificate and extract information from Certificate to handle it according to its contents. 請求包含：
|
| 05 | requestChallengeForAuthentication | Initiate the Authentication process by requesting server to output a challenge. 請求包含：
|
| 06 | verifyProofOfOwnershipUnidirectional | Request server to verify the POWN for unidirectional authentication. 請求包含：
|
| 07 | verifyProofOfOwnershipBidirectional | Request server to verify the client side POWN and provide server-side POWN for bidirectional authentication. 參數同上 |
| 08 | authenticationConfiguration | Indicates the provided authentication configuration of the server. 無請求參數 |
3.4 認證服務的通用需求
- 認證服務和診斷會話以及安全等級沒有直接關系，換句話說一旦client和server完成認證，則在認證有效期范圍內認證流程配置相關的診斷服務都是可以訪問的，有效期可以定義為基于時間，里程或直到收到“deauthenticate”請求
- client和server的認證狀態應和某個診斷通道相關聯，基于多用戶的服務器系統，多個client可使用不同的認證配置在多個診斷通道上處理
- 支持認證服務的ECU需支持NRC-34 Authentication required
- 會話密鑰（Session key）作為可選項用于后續server和client之間安全的通信
4. 服務實現
實現認證服務，若使用APEC方式需要PKI的支持，若使用ACR方式則需要自定義相關元素并建立安全體系支持。
對于認證服務的需求，除標準定義內容外OEM還需要額外定義如下內容：
- 使用的加密算法，算法元素的定義等
- 算法所需元素的生成，分發及存儲方法和流程
- 對推出已認證狀態策略的定義，如超時時間，里程數等
- 認證失敗的處理機制定義，如設計最大嘗試次數，認證請求間隔等
- 對于server已通過client認證，但client對server的認證失敗的情況，由OEM定義是否client需要發送deauthentication子功能斷開連接以確保server離開已認證狀態，拒絕進一步的請求
- APCE
- 證書格式
- 對于已經通過認證的client想要進一步激活其他權限或證明已簽名的數據時可以使用transmitcertificate子功能，而無需再次通過挑戰-響應過程通過認證，此操作所拆傳輸的數據需要經過私鑰進行簽名（數據與簽名分別發送至server）。通過證書激活更多權限的方法需要OEM進行定義，若使用此方法時，應使用不同的certificateEvaluationId加以區分
- ACR
- 密鑰的分發，存儲，管理的方法和流程
5.?與27服務的比較
了解了29服務的定義后，熟悉診斷的不免會有個疑問：29服務和27服務很相似，為什么有了27服務為什么還要定義29服務？
先來看下27服務在標準里的說明：
The purpose of this service is to?provide a means to access data and/or diagnostic services, which have restricted access for?security, emissions, or safety reasons.?Diagnostic services for downloading/uploading routines or data into a server and reading specific memory locations from a server are situations where?security access?may be required.?Improper routines or data downloaded into a server could potentially damage the electronics or other vehicle components or risk the vehicle’s compliance to emission, safety, or security standards.?The security concept uses a seed and key relationship.
再看下29服務的說明(如概述):
The purpose of this service is to?provide a means for the client to prove its identity, allowing it to?access data and/or diagnostic services, which have restricted access for,?for example security, emissions, or safety reasons.?Diagnostic services for downloading/uploading routines or data into a server and reading specific memory locations from a server are situations where?authentication?may be required.?Improper routines or data downloaded into a server could potentially damage the electronics or other vehicle components or risk the vehicle’s compliance to emission, safety, or security standards.?On the other hand, data security might be violated when retrieving data from a server
可以看到提供27和29服務的目的幾乎完全相同，都是對診斷儀的合法性進行確認，從而保護ECU的數據和軟件安全受到威脅，區別僅在于使用的方法不同。由此可以推斷 29服務的誕生是由于27服務提供的安全機制已經不能滿足現在車輛診斷功能面臨的新的安全威脅，而這些新的安全威脅則是在車輛網聯化共享化的趨勢下產生的，即隨著車載以太網的應用普及，任意一臺互聯網設備理論上都可以通過DoIP訪問車輛的診斷功，進行數據獲取或執行診斷操作，這在為OTA，遠程診斷等功能帶來益處的同時也給車輛帶來更多的潛在風險，對意圖使用診斷功能的設備的認證至關重要，原有的27服務機制簡單，不適用于多客戶端，防護等級低，很難起到保護作用。
27服務和29服務的差異對比如下表
| 維度 | 27服務 | 29服務 |
| 認證方法 | 種子-密鑰 | 基于PKI的認證/OEM自定義 |
| 加密方式 | 對稱加密 | 對稱/非對稱加密 |
| 算法 | CRC（定義較為簡單） | 信息安全標準定義的安全算法 ISO/IEC 9798 HMAC or CMAC or GMAC |
| 實現機制 | 不區分來源，分多級保護（01, 03...） | 針對不同的診斷來源實現差異化定義（研發，工廠，售后，供應商） |
總結
以上是生活随笔為你收集整理的认识UDS诊断29认证服务-Authentication Service的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： C++模板元编程（7）typename的
- 下一篇： 大数据开发实战教程目录