AUTOSAR BSW 深度精解 · 安全啟動與刷寫模組

【EB AutoCore 模組精解】
Secure Boot 與安全刷寫

打造防竄改信任鏈、UDS 0x34/0x36/0x37 驗證與 CRA 反回退實務。安全開機（Secure Boot）與安全刷寫（Secure Flashing）是車載控制器的底層終極防線。深入剖析 EB AutoCore 架構下如何自硬體信任根（Root of Trust）建立不可竄改的垂直信任鏈、UDS 診斷刷寫管線化雜湊與簽章驗證，以及如何落實歐盟 CRA 反版本回退（Anti-Rollback）標準。

Secure Boot Secure Flashing UDS 0x34/0x36/0x37 Anti-Rollback

1. 系統基石：為什麼 Secure Boot 與安全刷寫是最後防線？

在現代車載電子電氣架構中，若 ECU 的韌體開機引導程式（Bootloader）與執行鏡像（Application Image）缺乏防竄改與合法性校驗機制，攻擊者一旦透過實體接腳（如 JTAG、SWD）或遠端 OTA 漏洞寫入被植入後門的惡意韌體，整個上層的 SecOC、TLS 與訪問控制將全面崩潰。

國際法規對此提出了極為嚴格的剛性規範：

  • ISO/SAE 21434（車載網路安全工程）：要求 ECU 在軟體安裝與執行前必須實施「軟體真實性與完整性確認（Software Authenticity and Integrity Verification）」，並將未授權韌體替換列為關鍵威脅場景。
  • 歐盟 CRA（Cyber Resilience Act）：明確規定產品出廠時必須遵循 Secure-by-Design，在設備更新過程中必須具備防竄改驗證，且必須提供反版本回退（Anti-Rollback Protection）機制，杜絕將系統降級至已知存在漏洞之舊版本的惡意攻擊。
💡 傳統校驗與安全驗證的本質差異
傳統 Bootloader 常用 32 位元 CRC（如 CRC-32）來確認資料傳輸完整性。然而 CRC 只能防物理噪聲，無法防人為惡意竄改。攻擊者可輕易算出竄改後資料的配對 CRC。在 EB AutoCore 的現代資安架構中，必須全面採用基於密碼學的數位簽章（如 RSA-PSS、ECDSA NIST P-256）配合 SHA-256/384 雜湊演算法。

2. 信任鏈體系：硬體信任根至 AutoCore OS 的垂直傳遞

安全開機的核心思想是「信任鏈（Chain of Trust）」：每一個執行階段的程式碼，都必須在被下一個階段執行前，經過前一個已受信任實體的密碼學簽章驗證。

flowchart TD classDef rot fill:#fffbe6,stroke:#d97008,stroke-width:2px,color:#172b4d; classDef boot fill:#e9f2ff,stroke:#0052cc,stroke-width:2px,color:#091e42; classDef os fill:#e3fcef,stroke:#00875a,stroke-width:2px,color:#00472e; classDef app fill:#f3e8ff,stroke:#6554c0,stroke-width:2px,color:#253858; classDef lock fill:#ffebe6,stroke:#de350b,stroke-width:2px,color:#bf2600; STAGE0["【階段 0：硬體信任根 RoT】
不可變 Boot ROM / 硬體安全核心
唯讀固化 OEM 根公鑰雜湊 (Root PK Hash)"]:::rot STAGE1["【階段 1：第一階段引導 Primary Bootloader】
Secure Bootloader (SBL)
校驗韌體鏡像頭 (Header) 與簽章"]:::boot STAGE2["【階段 2：ACP 基礎軟體引導 AutoCore ACP OS】
EB AutoCore OS 啟動
初始化 EcuM / BswM / CSM 堆疊"]:::os STAGE3["【階段 3：應用層就緒 Application SW-Cs】
車載控制邏輯與安全通訊 (SecOC) 就緒"]:::app LOCK1["【進入安全救援模式】
安全鎖死 / 拒絕啟動"]:::lock LOCK2["【停留在 Bootloader】
等待診斷安全刷寫修復"]:::lock STAGE0 -->|硬體驗證 SBL 簽章 E_OK| STAGE1 STAGE0 -.->|校驗失敗| LOCK1 STAGE1 -->|SBL 驗證 App 鏡像簽章 E_OK| STAGE2 STAGE1 -.->|校驗失敗| LOCK2 STAGE2 -->|初始化完成並切換任務| STAGE3
圖 1：從不可變硬體信任根到 EB AutoCore 應用層之垂直信任鏈遞移架構

信任鏈核心元件說明：

  • Root of Trust（RoT，硬體信任根）：固化於晶片唯讀記憶體（Boot ROM）或安全核心中，任何人包括 OEM 都無法覆寫。內部持有 OEM 根公鑰的雜湊值（Root Key Digest）。
  • Secure Bootloader（SBL）：由 RoT 驗證通過後接管執行。負責管理 UDS 診斷安全刷寫流程，並在跳轉前驗證 Application 區塊之數位簽章。
  • EB AutoCore Application：包含完整 AUTOSAR BSW（CSM、CryIf、Crypto Driver、SecOC、KeyM 等）及上層應用 SW-C。

3. 安全開機（Secure Boot）驗證流程與策略權衡

在量產車輛專案中，ECU 開機時間要求極為嚴苛（例如 CAN 匯流排必須在通電 50ms 內送出第一幀報文，倒車顯影需在 2 秒內就緒）。如何在嚴格的開機時間限制下完成數百 KB 乃至數 MB 程式碼的密碼學驗證？

A

全量驗證 (Sequential Full Boot)

時序特性：開機時對整個 Application Flash 區塊計算 SHA-256 並驗證數位簽章，通過後才允許執行。

適用場景：小型感測器節點、程式碼體積小（< 512KB）且開機時間裕度較大的控制器。

B

平行/分段驗證 (Parallel / Staged Boot)

時序特性：硬體核心在背景平行計算簽章；主核心先啟動關鍵通訊模組發送報文，若背景驗證失敗再發起安全中斷（Safe State Reset）。

適用場景：車載通訊閘道（Gateway）、車身網關等要求極端快速匯流排握手的控制器。

C

快速啟動與運行時巡檢 (Run-time Check)

時序特性：開機僅驗證程式碼段的 Header 與 MAC 認證值；系統閒置時由 EB AutoCore 背景任務持續計算分區 Hash 進行動態防竄改校驗。

適用場景：高安全等級（ASIL-D）底盤與自動駕駛控制器。

4. UDS 安全刷寫核心：0x34 / 0x36 / 0x37 協議機制

在售後維修或工廠生產中，韌體刷寫通常遵循 ISO 14229-1（UDS）診斷標準。在 EB AutoCore 支援的安全刷寫（Secure Flashing）機制中，密碼學檢驗貫穿於整個資料傳輸流程：

UDS 服務碼 服務名稱 安全刷寫職責與 EB AutoCore 處理邏輯 資安防禦重點
0x22 / 0x27 / 0x29 安全訪問與身分鑑別 解鎖 Programming Session 前，透過 Seed-Key（0x27）或憑證（0x29）鑑別診斷儀身分。 阻擋未授權連線存取 Flash 擦寫權限。
0x34 RequestDownload 指定目標記憶體起始位址、資料長度及壓縮/加密格式。Bootloader 分配安全快取區並重置 Hash 上下文。 記憶體邊界溢位檢查、位址重疊防護。
0x36 TransferData 循環分塊傳輸韌體 Payload。EB Bootloader 採用管線化（Pipelined）雜湊計算：在將區塊寫入 Flash 的同時，背景由 CSM 計算 SHA-256 雜湊。 區塊計數器（BlockSequenceCounter）單調遞增檢查，防止資料包丟失或亂序。
0x37 RequestTransferExit 通知傳輸完畢。Bootloader 終結資料接收流水線，準備進入簽章校驗階段。 確認總接收長度與 0x34 宣告之長度嚴格一致。
0x31 RoutineControl (CheckProgDependencies) 安全刷寫之核心！傳入 OEM 數位簽章與升級憑證。Bootloader 呼叫 CSM 進行非對稱簽章驗證（RSA-PSS 或 ECDSA）。 非對稱密碼學驗證；校驗軟體版本反回退計數器（Anti-Rollback）。

5. 端到端流程時序：安全刷寫與簽章驗證全時序圖

下圖展示診斷儀（Tester）透過 UDS 0x34/0x36/0x37 服務將新版本應用軟體刷入 ECU，並透過 EB AutoCore Crypto 模組完成簽章驗證的完整交互時序：

sequenceDiagram participant Tester as 診斷儀 / OTA 客戶端 participant Dcm as Bootloader Dcm participant Flash as Flash 驅動模組 participant CSM as CSM 密碼服務 participant Crypto as 底層 Crypto 驅動 participant NvM as NvM (反回退儲存) Note over Tester, NvM: 階段一：請求下載與上下文初始化 Tester->>Dcm: 1. 0x34 RequestDownload (MemoryAddress, Length) Dcm->>CSM: 2. Csm_HashStart (JobId: SHA256) CSM->>Crypto: 3. Crypto_ProcessJob (HASH_START) Dcm-->>Tester: 4. 0x74 Positive Response (MaxNumberOfBlockLen) Note over Tester, NvM: 階段二：分塊傳輸與管線化雜湊運算 loop 循環傳輸韌體資料區塊 Tester->>Dcm: 5. 0x36 TransferData (BlockSequenceCounter, PayloadChunk) Dcm->>Flash: 6. Flash_Write (TargetAddress, PayloadChunk) Dcm->>CSM: 7. Csm_HashUpdate (JobId, PayloadChunk) CSM->>Crypto: 8. Crypto_ProcessJob (HASH_UPDATE) Dcm-->>Tester: 9. 0x76 Positive Response (BlockSequenceCounter) end Tester->>Dcm: 10. 0x37 RequestTransferExit () Dcm->>CSM: 11. Csm_HashFinish (JobId, DigestBuffer) CSM-->>Dcm: 12. 回傳計算所得之 SHA-256 Digest Dcm-->>Tester: 13. 0x77 Positive Response () Note over Tester, NvM: 階段三：非對稱數位簽章與反回退驗證 Tester->>Dcm: 14. 0x31 01 02 02 (CheckProgDependencies + Signature) Dcm->>CSM: 15. Csm_SignatureVerify (PublicKey, Digest, Signature) CSM->>Crypto: 16. Crypto_ProcessJob (SIGNATURE_VERIFY) Crypto-->>CSM: 17. 簽章驗證成功 (E_OK) CSM-->>Dcm: 18. 回傳驗證通過 (Signature Valid) Dcm->>NvM: 19. 檢查軟體版本號 >= 目前已固化之 Anti-Rollback 門檻 NvM-->>Dcm: 20. 版本號合法 (不允許降級) Dcm->>NvM: 21. 更新並持久化新軟體版本號至單調增計數器 Dcm-->>Tester: 22. 0x71 01 02 02 (Routine Positive Response)
圖 2：UDS 0x34/0x36/0x37 安全刷寫、管線化 Hash 與數位簽章校驗完整交互時序圖

6. CRA 規範下的反版本回退保護機制 (Anti-Rollback Protection)

歐盟 CRA（Cyber Resilience Act）明確規定：「設備在更新後，不得被未授權降級至存在已知漏洞的早期軟體版本」。黑客常用的攻擊手法是故意刷入 3 年前未修補漏洞的官方歷史韌體，進而利用舊版漏洞取得控制權。

在 EB AutoCore 架構中，結合硬體安全核心維護不可逆的單調增計數器（Monotonic Counter）或 安全 eFuse：

  • 每次發布新版韌體時，OEM 在簽章中封裝該版本的安全性版本號（Security Version Number, SVN）。
  • Bootloader 在執行 RoutineControl 0x31 驗證時，若 Image_SVN < Hardware_SVN，即使密碼學簽章完全正確，依然一律強制判定為非法升級並拒絕刷寫。
  • 只有當 Image_SVN > Hardware_SVN 且完整校驗通過後，Bootloader 才會燒錄 eFuse 遞增硬體門檻，達成物理級別的防降級保護。

7. 虛擬化驗證加速：EB AutoCore 虛擬 ECU (vECU) 模擬加速安全啟動與刷寫測試

在真實硬體晶片上調試 Bootloader 具有極大風險：一旦金鑰燒錄錯誤、Flash 簽章配置不匹配或信任鏈跳轉異常，極易造成 MCU 永久鎖死（Brick），開發週期嚴重受阻。

透過 x86 虛擬 ECU（vECU）模擬技術，團隊可以在 PC 環境下建立完全對等的軟體模擬環境：

1

全自動故障簽章注入測試

在 x86 模擬環境中自動注入竄改 Payload、偽造憑證、反轉 Hash 位元等測試用例，深入驗證 Bootloader 攔截與安全鎖定邏輯。

2

反回退與版本跨度壓測

模擬多次不同版本韌體升級與回退測試，驗證 Monotonic Counter 與 NvM 記憶體邏輯之正確性。

3

CI/CD 自動化迴歸測試

無需排隊等待有限的實體測試台架，在代碼提交時自動執行 0x34/0x36/0x37 流程驗證，加速專案開發進度。

🚀 Jotactic（捷策動能）：EB AUTOSAR 安全啟動與刷寫技術支持服務

安全啟動與安全刷寫是保護車載韌體免於被竄改與惡意逆向的防禦根基。Jotactic（捷策動能） 基於 EB AUTOSAR 原生架構與標準配置工作流程，在不修改 EB 原廠代碼的前提下，為客戶提供專業技術服務：

  • EB tresos 密碼服務與安全刷寫參數配置服務：協助客戶在 EB tresos Studio 中進行 CSM 數位簽章驗證原語、Hash 算法參數與金鑰引導流程的標準配置與 ARXML 匯入匯出。
  • 技術支持與諮詢服務：提供 EB AUTOSAR 安全啟動與刷寫驗證標準流程的技術諮詢，協助客戶排查配置過程中的問題。
  • 基於 EB 機制的客製化 Demo 專案開發：基於 EB 原生架構與標準 API 建立 UDS 0x34/0x36/0x37 安全刷寫驗證 Demo 專案，輔助客戶進行模組功能驗證。

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