AUTOSAR BSW 深度精解 · 診斷與身分認證模組

【EB AutoCore 模組精解】
Dcm 診斷安全防護

從 UDS 0x27 密鑰存取到 0x29 憑證身分鑑別與 ISO 21434 落地。診斷介面（OBD-II 與車載乙太網 DoIP）是車輛最易遭滲透的物理門戶。深度解析 EB AutoCore 架構下 Dcm 如何協同 CSM 與 KeyM，實現傳統 0x27 Seed-Key 防暴力破解演算法，以及邁向 CRA / ISO 21434 標準的 0x29 雙向非對稱憑證身分鑑別實踐。

UDS 0x27 / 0x29 憑證鑑別防暴力破解 ISO 21434

1. 診斷接口的威脅現狀與法規要求

在 ISO/SAE 21434 的 TARA 威脅分析中，ECU 診斷服務向來是攻擊者的首選目標。無論是透過傳統的 OBD-II 介面，還是透過車載乙太網 DoIP（ISO 13400），攻擊者一旦取得未授權的解鎖權限，即可恣意讀取 ECU 記憶體（0x23/0x3D）、覆寫控制參數（0x2E），甚至啟動非法軟體刷寫（0x34/0x36）。

為保障售後保養與工廠調試的安全性，Dcm（Diagnostic Communication Manager，診斷通訊管理器） 提供了階層式的安全存取防護體系。在 EB AutoCore 實作中，Dcm 透過與 Crypto Stack（CSM、KeyM）緊密聯動，構築了自傳統對稱密鑰到現代 PKI 憑證的完整鑑別屏障。

2. 傳統服務 0x27：SecurityAccess 深度機制

UDS 0x27 服務基於經典的 Seed & Key（挑戰-應答） 機制運作：

sequenceDiagram participant Tester as 診斷儀 (Tester) participant Dcm as EB AutoCore Dcm participant CSM as CSM 服務層 participant NvM as NvM 儲存層 Tester->>Dcm: 1. 請求種子：0x27 01 (Request Seed) rect rgb(240, 248, 255) Note over Dcm, CSM: 步驟 1：產生動態真隨機數 (Seed) Dcm->>NvM: 2. 讀取並檢核錯誤計數 (Attempt Counter) Dcm->>CSM: 3. Csm_RandomGenerate(TRNG JobId, SeedBuffer) CSM-->>Dcm: 4. 回傳高熵隨機數 Seed (8 Bytes) Dcm-->>Tester: 5. 響應種子：0x67 01 [Seed Bytes] end Note over Tester: 6. 依據 OEM 演算法由 Seed 計算 Key Tester->>Dcm: 7. 發送密鑰：0x27 02 (Send Key) [Calculated Key] rect rgb(240, 255, 240) Note over Dcm, CSM: 步驟 2：金鑰運算比對與狀態提升 Dcm->>CSM: 8. Csm_MacGenerate / 密碼原語校驗 Key CSM-->>Dcm: 9. 運算比對結果相符 (Match) Note over Dcm: 10. 躍遷至對應 Security Level (解鎖敏感服務) Dcm-->>Tester: 11. 認證成功：0x67 02 (Access Granted) end

圖 1：EB AutoCore Dcm 0x27 Security Access 認證時序與防護機制

⚠️ 防暴力破解（Anti-Brute Force）硬性規範

為符合 ISO 21434 要求，EB AutoCore Dcm 內建了嚴密的次數防護：

DcmDspSecurityNumAttDelay：連續嘗試錯誤次數上限（通常為 3 次）。
DcmDspSecurityDelayTime：達到錯誤上限後的強制鎖定延遲時間（如 10 秒）。鎖定期間即使收到正確的 Key 亦一律回傳 NRC 0x37 (RequiredTimeDelayNotExpired)。
DcmDspSecurityDelayTimeOnBoot：上電啟動後的安全延遲，防範利用反覆斷電重置來繞過鎖定計數器的攻擊手段。計數器狀態必須持久化至 NvM。

3. 次世代服務 0x29：Authentication 雙向憑證身分鑑別

在歐盟 CRA 與 ISO 21434 規範推進下，0x27 的對稱靜態演算法面臨被逆向分析與全域洩漏的巨大風險。AUTOSAR R20-11 正式制定了 UDS 0x29（Authentication 服務）。

EB AutoCore 率先提供了完整的 0x29 實作，支援基於 PKI 數位憑證與非對稱密碼學（X.509 + ECDSA / SPAKE2+） 的雙向鑑別：

儀器身分認證（Client Authentication）：診斷儀發送由 OEM 官方簽發的 X.509 證書，Dcm 調用 KeyM 與 CSM 逐級驗證憑證鏈，確保只有具備 OEM 官方授權的工程師才能存取。
ECU 身分防假冒（Server Authentication）：ECU 向診斷儀出示自身的車載設備證書，防止黑客搭建虛假測試環境竊取演算法。
會話密鑰協商（Session Key Derivation）：認證通過後動態協商工作密鑰，後續整個診斷會話全面啟用 MAC 完整性保護。

4. Dcm 安全狀態機（Security State Machine）

EB AutoCore Dcm 內部透過嚴格的狀態機管控訪問等級（Security Level）：

圖 2：EB AutoCore Dcm Security Level 狀態轉移與逾時回退機制

5. EB tresos 配置實踐與關鍵參數詳解

在 EB tresos 配置 Dcm 安全服務時，需重點定義以下參數：

配置容器 / 參數項	推薦值	說明
`DcmDspSecurityRow / DcmDspSecurityLevel`	1, 2, 3...	定義不同特權等級（如 Level 1 為日常讀取，Level 0x11 為刷寫授權）。
`DcmDspSecuritySeedSize`	8 ~ 16 Bytes	隨機數長度。建議至少 64-bit 以上以抵抗碰撞攻擊。
`DcmDspSecurityKeySize`	8 ~ 16 Bytes	回傳金鑰長度，與 CSM 演算法輸出寬度相匹配。
`DcmDspSecurityUseAuthentication`	`TRUE`	啟用 0x29 憑證認證支援，無縫銜接 KeyM 模組。

🚀 Jotactic（捷策動能）：EB AUTOSAR 診斷安全技術支持與配置服務

診斷安全訪問涉及 Dcm、KeyM 與 CSM 的跨模組配置。Jotactic（捷策動能） 基於 EB AUTOSAR 原生架構與標準配置工作流程，在不修改 EB 原廠代碼的前提下，為客戶提供專業技術服務：

EB tresos Dcm 模組參數配置服務：協助客戶在 EB tresos Studio 中進行 UDS 0x27 / 0x29 參數配置（安全等級 Security Level、延遲計時器、錯誤次數上限等）與 ARXML 匯入匯出。
技術支持與諮詢服務：提供 EB AUTOSAR Dcm 標準安全訪問流程的技術諮詢，協助客戶排查配置過程中的問題。
基於 EB 機制的客製化 Demo 專案開發：基於 EB 原生架構與標準 API 建立安全訪問驗證 Demo 專案，輔助客戶進行模組功能驗證。

💡 備註：EB AUTOSAR 提供標準化 Dcm 模組供客戶開發使用；ECU 與整車是否符合法規或通過資安認證，屬於 Tier 1 與 OEM 客戶系統層級之工程範疇。捷策動能基於 EB 原生機制提供配置與技術支持服務，不修改 EB 原廠代碼，非 AUTOSAR 基礎軟體開發商。歡迎聯絡捷策動能團隊獲取技術支持。

【EB AutoCore 模組精解】Dcm 診斷安全防護