車載資安專案實戰 · AUTOSAR Classic Platform

從 ISO 21434 與 CRA 規範落地到 EB AutoCore 資安架構：
Crypto Stack、KeyM 與 SecOC 深度實戰解析

全面剖析 Elektrobit（EB）AUTOSAR 經典平台實現方案 EB AutoCore / ACG（AutoCore Generic，亦以 AutoCore Package, ACP 形式交付）在網路安全法規下的縱深防禦體系，從宏觀密碼學服務架構（Crypto Stack）逐層剖析至微觀核心模組（CSM、KeyM、SecOC），助您建構高韌性、高合規的次世代車載 ECU 軟體架構。

ISO 21434 EU CRA Crypto Stack 縱深防禦

1. 法規浪潮下的車載資安戰略：從合規到架構落地

隨著歐盟 UN R155（網路安全管理體系，CSMS）、UN R156（軟體更新管理體系，SUMS） 與 ISO/SAE 21434 全面實施，全球主要汽車市場已將車載網路安全列為車型認證（Type Approval）的強制門檻。同時，歐盟即將生效的《網路韌性法案》（Cyber Resilience Act, CRA）更將連網硬體與嵌入式軟體的全生命週期漏洞管理法制化。

在此背景下，車載電子控制單元（ECU）的資安防禦不再是「可選項目」或「打補丁式」的防護，而是必須從電子電氣架構（E/E Architecture）與基礎軟體（BSW）設計之初，便將安全基因融入底層堆疊。

flowchart TD classDef reg fill:#ffebe6,stroke:#de350b,stroke-width:2px,color:#172b4d; classDef std fill:#fff0b3,stroke:#ff991f,stroke-width:2px,color:#172b4d; classDef eng fill:#e3fcef,stroke:#00875a,stroke-width:2px,color:#172b4d; classDef eb fill:#deebff,stroke:#0052cc,stroke-width:2px,color:#0747a6; R1["國際法規與指令
UNECE UN R155 / R156"]:::reg R2["歐盟橫向安全法案
EU Cyber Resilience Act (CRA)"]:::reg S1["工程流程與生命週期標準
ISO/SAE 21434:2021 (CSMS)"]:::std S2["密碼與安全機制技術標準
NIST SP 800 / FIPS / EVITA"]:::std E1["整車安全工程落地需求
TARA 威脅分析 · 安全目標 (Cybersecurity Goals)"]:::eng EB1["AUTOSAR Classic Platform (CP) 標準實現方案
Elektrobit (EB) AutoCore / ACG (AutoCore Package, ACP)"]:::eb R1 --> S1 R2 --> S1 S1 --> E1 S2 --> E1 E1 ==> EB1
圖 1：國際車載資安法規、標準與 EB AutoCore 基礎軟體實現之映射體系

1.1 全球資安法規的核心技術要求

剖析上述法規，其對車載嵌入式軟體的強制性技術要求主要收斂於以下四個維度：

  • 真實性鑑別（Authenticity）：通訊節點身份合法性校驗，防範偽造報文與未授權 ECU 接入總線。
  • 完整性校驗（Integrity）：傳輸資料與固件鏡像的防竄改校驗，確保控制指令與代碼無惡意修改。
  • 防重放機制（Freshness & Anti-Replay）：引入單調遞增計數器或時間戳，防止合法報文被竊聽並惡意重播。
  • 機密性保護（Confidentiality）：敏感數據（如個人隱私、金鑰資產、診斷通道）的強加密傳輸與安全存儲。
💡 法規合規的工程痛點
許多 Tier 1 與 OEM 面臨的最大瓶頸，在於「如何將高階法規條文與 TARA 產出的資安目標（Cybersecurity Goals），轉化為 ECU 基礎軟體（BSW）的具體配置」。若缺乏一套標準化、經過功能安全與資安認證的成熟 BSW 堆疊，自行開發密碼學驅動與通訊保護模組將承擔極高的維護成本與合規審核風險。

1.2 EB AutoCore / ACG 在 AUTOSAR Classic Platform (CP) 的關鍵定位

作為全球車載基礎軟體的領導品牌，Elektrobit（EB）所提供的 EB tresos AutoCore（亦稱為 ACG, AutoCore Generic，以 AutoCore Package, ACP 形式交付）是業界標竿級的 AUTOSAR Classic Platform (CP) 實現方案。EB AutoCore 不僅完整遵循 AUTOSAR 4.4 / R20-11 標準規範，更針對車載資安建立了成熟、模組化且高度解耦的資安模組套件（Security Portfolio）。

透過 EB AutoCore，工程團隊無需在應用層重造輪子，即可在基礎軟體層啟用支援硬體安全隔離的標準化密碼服務，為 Tier 1 與 OEM 客戶在因應 ISO 21434 與 CRA 等法規要求開發 ECU 時，提供具備標準支援架構的軟體基礎。

2. 大局觀：EB AutoCore 資安架構全景與 Crypto Stack 體系

在 EB AutoCore 體系中，資安防護並非單一孤立模組，而是一組橫跨服務層（Services Layer）、ECU 抽象層（ECU Abstraction Layer）與驅動層（Driver Layer）的有機整體。

2.1 Crypto Stack 三層式解耦架構

AUTOSAR R20-11 將密碼學服務標準化為分層式 Crypto Stack，EB AutoCore 藉此實現了「上層業務邏輯與底層加密硬體徹底解耦」的高彈性架構：

flowchart TD classDef appLayer fill:#e9f2ff,stroke:#0052cc,stroke-width:2px,color:#091e42; classDef bswService fill:#f3e8ff,stroke:#6554c0,stroke-width:2px,color:#091e42; classDef bswIf fill:#e3fcef,stroke:#00875a,stroke-width:2px,color:#091e42; classDef bswDriver fill:#fff0b3,stroke:#d97008,stroke-width:2px,color:#091e42; SWC["車載應用 SW-Cs"]:::appLayer SECOC["SecOC 安全通訊"]:::appLayer KEYM["KeyM 金鑰管理"]:::appLayer DCM["Dcm 診斷安全 (0x27/0x29)"]:::appLayer TLS["TLS 車聯網通訊"]:::appLayer SBOOT["Secure Boot 安全啟動"]:::appLayer CSM["【AUTOSAR 服務層：CSM 密碼服務管理器】
統一 CsmJob API · 排程佇列優先級裁決"]:::bswService CRYIF["【ECU 抽象層：CryIf 密碼介面】
通道透明分流 · 邏輯金鑰與物理金鑰重映射"]:::bswIf CRYPTO_HW["【MCAL 硬體驅動：Crypto Driver (HW)】
硬體安全核心 / HSM 加速器 (AES, SHA)"]:::bswDriver CRYPTO_SW["【軟體密碼庫：Crypto Driver (SW)】
EB 原生軟體密碼庫 (RSA, ECC 備援)"]:::bswDriver SWC --> CSM SECOC --> CSM KEYM --> CSM DCM --> CSM TLS --> CSM SBOOT --> CSM CSM -->|通道派發| CRYIF CRYIF -->|硬體加速通道| CRYPTO_HW CRYIF -->|純軟體運算通道| CRYPTO_SW
圖 1：EB AutoCore 標準 Crypto Stack 縱向分層與周邊資安模組協同全景圖

2.2 核心資安模組職責矩陣對照表

為滿足不同層級的資安威脅防護需求，EB AutoCore 提供了專責分工的 BSW 模組組合：

模組名稱 AUTOSAR 層級 核心功能與技術特色 ISO 21434 / CRA 對應支撐
CSM
(Crypto Service Manager)		 服務層 (Services) 提供對稱/非對稱加解密、雜湊（Hash）、簽章驗證、MAC 產生/驗證、亂數產生（RNG）等標準 API；管理 Job 佇列與非同步回調。 密碼演算法與生命週期控制
符合密碼操作隔離與標準演算法強度要求。
CryIf
(Crypto Interface)		 ECU 抽象層 (Abstraction) 將上層邏輯通道（Channels）動態路由至不同的 Crypto Driver；支援邏輯金鑰 ID 到底層實體金鑰槽位的透明重映射（Key Redirection）。 軟硬體解耦與演算法擴充性
實現底層硬體替換時上層資安邏輯零修改。
Crypto Driver
(MCAL / Crypto_EB)		 驅動層 (Driver) 直接操作底層硬體安全核心（HSM / 安全核心），或執行 EB 自研的高效純軟體密碼函式庫（Crypto_EB），提供最高安全隔離等級。 防竄改與物理金鑰防護
金鑰不出隔離區，滿足硬體級信任根要求。
KeyM
(Key Manager)		 服務層 (Services) 負責金鑰與憑證（X.509 憑證鏈）的安全存儲、派生（KDF）、產線注入、公鑰驗證與憑證狀態查詢。 金鑰全生命週期管理
防止靜態明文金鑰外洩，滿足憑證鏈階層審計。
SecOC
(Secure Onboard Com)		 通訊服務層 (Com Services) 為 CAN、CAN FD 及車載乙太網通訊提供身分鑑別與防竄改防護；計算並校驗訊息鑑別碼（MAC），結合新鮮度管理器（FVM）徹底防重放。 匯流排即時抗重放與防偽造
落實動力與底盤控制報文端到端通訊完整性。
IdsM
(Intrusion Detection Mgr)		 服務層 (Services) 採集各 BSW 模組（SecOC、Dcm、CanIf 等）上報之安全事件（Security Events），實施滑動時間窗口過濾、限速防風暴，並匯出至車載記錄器或雲端 VSOC。 持續監控與威脅審計 (UN R155)
落實威脅感知能力，符合 72 小時漏洞呈報時限。
Dcm Security
(UDS 0x27 / 0x29)		 診斷服務層 (Diagnostic) 實現診斷服務安全訪問（0x27 Seed & Key 鑑別，防暴力破解延遲鎖定）與基於非對稱公鑰憑證的身分鑑別（0x29 Authentication）。 產線與售後存取控制
嚴格限制診斷權限，防止非法刷寫與工程模式濫用。
TLS
(Transport Layer Sec)		 通訊層 (Com Services) 車載乙太網（DoIP、SOME/IP）傳輸層加密協議，執行雙向憑證握手，建立動態對稱會話密鑰進行高速封包加解密。 高速骨幹網路機密性
落實 ISO 13400-2 診斷通訊加密與敏感資料隱私保護。

3. 核心模組深潛（一）：CSM 密碼服務管理器

CSM（Crypto Service Manager） 是整個 Crypto Stack 的「大腦」。上層所有模組若需要密碼學運算，一律經由 CSM 發起請求，嚴禁跨層直連底層驅動。

3.1 密碼原語（Primitives）與標準服務

在 EB tresos 配置環境中，CSM 透過 CsmPrimitives 封裝了各大類別的密碼學操作：

  • 對稱加密/解密 (ENCRYPT / DECRYPT)：支援 AES-128、AES-256，涵蓋 CBC、CTR、GCM、XTS 等模式。
  • 訊息鑑別碼 (MAC_GENERATE / MAC_VERIFY)：支援 CMAC（基於 AES）、HMAC（基於 SHA-256），專為 SecOC 與診斷身分識別提供驗證基礎。
  • 雜湊計算 (HASH)：支援 SHA-2（SHA-256/384/512）及 SHA-3 系列。
  • 非對稱加密與數位簽章 (SIGNATURE_GENERATE / SIGNATURE_VERIFY)：支援 RSA（PKCS#1 v1.5 / PSS）與 ECC（ECDSA 曲線 NIST P-256/384、Ed25519），用於安全啟動驗證與安全刷寫驗證。
  • 隨機數生成 (RANDOM_GENERATE)：支援真隨機數（TRNG）或密碼學安全偽隨機數（CSPRNG）。

3.2 同步 vs 非同步排程與 Job 狀態機

密碼學演算法計算量龐大。為兼顧即時任務調度與高吞吐量，EB AutoCore CSM 提供了高度可靠的 Job 排程佇列機制：

flowchart TD classDef idle fill:#f4f5f7,stroke:#6b778c,stroke-width:2px,color:#091e42; classDef queued fill:#fff0b3,stroke:#d97008,stroke-width:2px,color:#091e42; classDef active fill:#e3fcef,stroke:#00875a,stroke-width:2px,color:#091e42; classDef action fill:#e9f2ff,stroke:#0052cc,stroke-dasharray: 4 4,stroke-width:1.5px,color:#091e42; INIT((● 系統初始化)) --> IDLE["【空閒狀態】CSM_JOB_STATE_IDLE
等待上層模組發起密碼學服務請求"]:::idle IDLE -->|非同步請求：Csm_JobStart| QUEUED["【排隊狀態】CSM_JOB_STATE_QUEUED
依 CsmJobPriority 排入優先級佇列"]:::queued IDLE -->|同步請求：Csm_JobStart| ACTIVE["【執行狀態】CSM_JOB_STATE_ACTIVE
派發至 CryIf / Crypto Driver 執行運算"]:::active QUEUED -->|排程器指派至可用通道| ACTIVE QUEUED -.->|Csm_JobCancel 取消任務| IDLE ACTIVE --> COMPLETE["【底層運算完成】觸發完成回調 Callback
返回運算結果 (E_OK / E_NOT_OK)"]:::action COMPLETE --> IDLE
圖 2：EB AutoCore CSM Job 內部運作生命週期狀態轉移圖
⚠️ 工程實務重點：優先級反轉防範
在 EB tresos 配置 CsmJobPriority 時，必須嚴格按照 ECU 的時效性進行劃分。例如：負責煞車與動力扭矩報文驗證的 SecOC MAC Verify Job 必須配置最高優先級；而耗時較長的診斷憑證鏈驗證（RSA-3072 Verify）則應設為較低優先級，並配置適當深度的 CsmQueueSize，以防高頻車載通訊突發時發生佇列溢位（Queue Overflow）。

4. 核心模組深潛（二）：KeyM 金鑰與憑證管理模組

在 ISO 21434 的軟體安全設計以及 CRA 的韌體安全要求中，「密碼學演算法的強度，取決於金鑰儲存與管理的安全性」。若金鑰以明文形式散落在程式碼常數區，整個資安體系將形同虛設。

4.1 金鑰生命週期保護機制

AUTOSAR 引入 KeyM（Key Management） 模組，專門解決金鑰從誕生到銷毀的全生命週期管控：

1

金鑰注入 (Provisioning)

支援產線安全注入，金鑰封裝在加密報文中，透過 KeyM 導入安全硬體儲存槽，全程不在 RAM 中暴露明文。

2

金鑰派生 (Derivation)

以主金鑰（Master Key）為根，利用 KDF 演算法（如 HKDF）依據特定情境動態派生工作金鑰，實現金鑰隔離。

3

證書鏈校驗 (Validation)

解析 X.509 格式公鑰證書，依據根憑證（Root CA）逐級驗證發行商簽章、有效期與作廢清單（CRL）。

4

銷毀與作廢 (Revocation)

當 ECU 偵測到物理入侵或收到遠端作廢指令時，KeyM 觸發安全擦除，將安全區敏感金鑰完全重寫歸零。

5. 核心模組深潛（三）：SecOC 安全車載通訊模組

傳統車載網路（CAN、CAN FD、LIN、Ethernet）先天缺乏身分鑑別與完整性校驗機制，攻擊者一旦侵入車載診斷座（OBD-II）或 T-Box，即可輕易實施報文偽造與重放攻擊。SecOC（Secure Onboard Communication） 是 AUTOSAR 為解決車載匯流排通訊安全而制定的核心標準。

5.1 SecOC 報文架構與身分鑑別

SecOC 在傳統資料負載（Authentic I-PDU）基礎上，附加了 新鮮度值（Freshness Value, FV） 與 訊息鑑別碼（Authenticator / MAC）：

flowchart TD classDef origNode fill:#e9f2ff,stroke:#0052cc,stroke-width:2px,color:#091e42; classDef secNode fill:#fff0b3,stroke:#d97008,stroke-width:2px,color:#091e42; classDef calcNode fill:#f3e8ff,stroke:#6554c0,stroke-width:2px,color:#091e42; classDef txNode fill:#e3fcef,stroke:#00875a,stroke-width:2px,color:#091e42; DATA["【原始資料報文】Authentic Data
(扭矩、車速、檔位等控制訊號)"]:::origNode FV["【新鮮度值】Freshness Value (FV)
(單調遞增計數器 / 時間戳)"]:::secNode KEY["【金鑰安全】對稱金鑰 (AES-128 Key)
(安全儲存於硬體安全區)"]:::secNode MAC_CALC["【SecOC 運算核心：呼叫 CSM】
AES-128-CMAC 演算法
計算完整 128-bit MAC"]:::calcNode TX_DATA["原始資料負載 (Authentic Data)"]:::txNode TX_FV["低位截斷新鮮度 (Truncated FV 4~8 bit)"]:::txNode TX_MAC["截斷鑑別碼 (Truncated MAC 28~64 bit)"]:::txNode SECURED_PDU["【最終匯流排傳輸：Secured I-PDU】"]:::txNode DATA --> MAC_CALC FV --> MAC_CALC KEY --> MAC_CALC DATA --> TX_DATA FV -->|低位截取| TX_FV MAC_CALC -->|截斷處理| TX_MAC TX_DATA --> SECURED_PDU TX_FV --> SECURED_PDU TX_MAC --> SECURED_PDU
圖 3：EB AutoCore SecOC 報文安全封裝與 MAC 截斷計算全景圖

5.2 FVM（新鮮度值管理器）機制與截斷防重放策略

單純使用 MAC 只能證明資料未被竄改，但無法防範「錄製舊報文後重新發送」的重放攻擊（Replay Attack）。因此，引入隨每次發送嚴格單調遞增的 Freshness Value（新鮮度值） 至關重要：

  • 完整新鮮度值（Complete FV）：通常長達 64 位元（包含 Trip Counter、Reset Counter 與 Message Counter），確保車輛生命週期內永不重複。
  • 截斷傳輸（Truncated FV）：為節省 CAN FD 的 Payload 頻寬，通常只在匯流排上發送最低的 4 至 8 位元；接收端透過本地維護的高位計數器進行同步重建（Reconstruction）。
  • 截斷 MAC（Truncated MAC）：將 128 位元的 CMAC 結果截取為 28 至 64 位元傳輸，在安全性與頻寬開銷之間取得最佳平衡。
✅ EB AutoCore SecOC 的獨家優勢
EB tresos 提供的 SecOC 實作高度優化了內部記憶體拷貝開銷，提供零拷貝（Zero-Copy）資料傳遞模式，並提供標準化 FVM（Freshness Value Manager） 整合介面。無論 OEM 規範採用 AUTOSAR 標準 Trip/Reset 複合計數器模式，或是基於 IEEE 802.1AS 全車主時鐘同步模式，EB AutoCore 均能透過清晰的外掛機制無縫適配。

6. 綜合貫穿：從匯流排封包到底層驗證的端到端時序圖

為了直觀理解當 ECU 接收到一幀 Secured CAN FD 報文時，各個模組如何緊密協作，以下展示從通訊路由到密碼硬體驗證的完整時序序列（Flow Sequence）：

sequenceDiagram participant Bus as CAN FD 匯流排 participant CanIf as CanIf / PduR participant SecOC as SecOC 模組 participant FVM as FVM (新鮮度管理) participant CSM as CSM (密碼服務管理) participant CryIf as CryIf (抽象路由) participant Driver as Crypto Driver / 硬體加速 Bus->>CanIf: 1. 接收 Secured I-PDU (Data + Truncated FV + Truncated MAC) CanIf->>SecOC: 2. SecOC_RxIndication(SecuredPduId, PduInfo) rect rgb(240, 248, 255) Note over SecOC, FVM: 【步驟 1】重建完整新鮮度值 (Reconstruction) SecOC->>FVM: 3. Fvm_GetRxFreshness(PduId, TruncatedFV) FVM-->>SecOC: 4. 回傳 Complete Freshness Value end rect rgb(255, 248, 240) Note over SecOC, Driver: 【步驟 2】派發 MAC 驗證 Job SecOC->>CSM: 5. Csm_MacVerify(JobId, CryIfKeyId, Data+FV, TruncatedMAC) Note over CSM: 檢核優先級，推入 CsmQueue 佇列 CSM->>CryIf: 6. CryIf_ProcessJob(ChannelId, JobPtr) CryIf->>Driver: 7. Crypto_ProcessJob(DriverObjectId, JobPtr) end rect rgb(240, 255, 240) Note over Driver: 【步驟 3】底層安全計算與比對 Note over Driver: 提取隔離區 Key 執行硬體 AES-CMAC 運算 Driver-->>CryIf: 8. Crypto_CallbackNotification(JobPtr, MAC_VALID) CryIf-->>CSM: 9. Csm_CallbackNotification(JobPtr, MAC_VALID) CSM-->>SecOC: 10. SecOC_VerificationCallback(MAC_VALID) end rect rgb(245, 245, 255) Note over SecOC, CanIf: 【步驟 4】認證成功，解包並交付應用層 SecOC->>FVM: 11. Fvm_VerificationStatusCallout(Valid_Success) SecOC->>CanIf: 12. PduR_SecOCRxIndication(AuthenticPayload) CanIf-->>Bus: 13. 交付目標 Control SW-C 執行控制指令 end
圖 4：SecOC 報文接收、新鮮度重建、CSM 調度與 MAC 驗證之完整交互時序圖

7. 虛擬化驗證加速：EB AutoCore 虛擬 ECU (vECU) 模擬實現「測試左移」

在傳統開發流程中，資安軟體工程師往往面臨「硬體晶片到貨晚、除錯介面難以監控、金鑰配置容易鎖死（Bricking）」等困境，使得 ISO 21434 所要求的反覆迭代測試難以在專案初期開展。

透過建立在 x86 虛擬化環境下的 EB AutoCore 虛擬 ECU（Virtual ECU, vECU）模擬，研發團隊能夠達成極具效益的「測試左移（Shift-Left Testing）」：

A

業務邏輯架構一致

CSM、CryIf、SecOC、KeyM 等 AutoCore 服務層與抽象層軟體架構與標準 API 保持高度一致，在 PC x86 端即可進行功能編譯與邏輯調試。

B

極端場景故障注入

可在虛擬環境中模擬 MAC 校驗失敗、計數器不同步、過期憑證、佇列溢位等實體硬體難以反覆觸發的測試用例。

C

CI/CD 自動化迴歸

與自動化測試腳本整合，在每次 Git 提交時自動化執行資安通訊迴歸測試，協助客戶加速量產前的專案驗證時程。

🚀 Jotactic（捷策動能）：專業的 EB AUTOSAR 技術支持與工程服務

Jotactic（捷策動能） 專注於車載嵌入式軟體技術支持與顧問服務。基於 EB AUTOSAR 原生機制與標準配置工作流程，在不修改 EB 原廠代碼的前提下，為客戶提供專業技術服務：

✔
EB tresos 模組配置服務：協助客戶在 EB tresos Studio 中進行 CSM、CryIf、KeyM、SecOC 等模組的標準參數配置、介面連接與 ARXML 匯入匯出。
✔
技術支持與諮詢服務：提供 EB AUTOSAR 官方模組配置流程的技術諮詢，協助客戶排查配置過程中的問題。
✔
基於 EB 機制的客製化 Demo 專案開發：基於 EB 原生架構與標準 API 為客戶建立概念驗證 Demo 專案，輔助客戶進行模組功能驗證。

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