【EB AutoCore 模組精解】
CSM 密碼服務管理器
建立符合 CRA 與 ISO 21434 標準的非同步密碼運算排程與優先級管理。在 AUTOSAR Classic Platform（CP）與 EB AutoCore / ACG 架構中，CSM 作為密碼學服務的單一核心調度者，承載了整車所有安全模組的原語運算需求。深入拆解 EB AutoCore CSM 的 Job 狀態機流轉、CsmQueue 搶佔排程、非同步回調機制，以及如何避免高優先級通訊任務逾時。
1. CSM 在車載資安體系中的角色：從混亂直連到統一中樞
在 ISO/SAE 21434 的軟體架構安全原則中，「單一職責與介面隔離」是抵禦側信道攻擊、杜絕安全邏輯旁路漏洞的根本。
如果讓上層業務模組（例如 SecOC、Dcm、KeyM）直接調用各自底層的晶片加密暫存器或專用驅動，會造成系統架構高度耦合。一旦更換晶片硬體，所有上層資安模組代碼皆須重構，大幅增加歐盟 CRA（Cyber Resilience Act）合規審核的重測負擔。
CSM（Crypto Service Manager，密碼服務管理器） 即是為此而生的標準化中樞。在 EB AutoCore 架構中，CSM 扮演了所有密碼學原語計算的單一入口：
- 統一應用層介面：為上層所有軟體元件提供符合 AUTOSAR 標準的 API（如
Csm_JobStart、Csm_JobUpdate、Csm_JobFinish）。 - 遮蔽底層硬體實現：無論後端運算是由硬體安全引擎（HSM）、專用加密加速器，或是純軟體密碼庫（如
Crypto_EB）完成，上層調用邏輯完全一致。 - 集中式任務佇列與仲裁：管理跨模組的密碼計算並行請求，防止多核心並發呼叫引發硬體資源競爭與暫存器死鎖。
2. 密碼原語（Primitives）與服務標準化
在 EB tresos 配置環境中，CSM 根據演算法類型將計算任務抽象為標準 CsmPrimitives：
| 密碼原語 (Primitive) | 支援演算法模式 | 典型輸出 / 格式 | 對應車載業務場景 |
|---|---|---|---|
| ENCRYPT / DECRYPT | AES-128/256 (CBC, CTR, GCM) | 密文 / 明文串流 | DoIP 診斷加密、SOME/IP 機密資料傳輸 |
| MAC_GENERATE / MAC_VERIFY | AES-CMAC / HMAC-SHA256 | Truncated MAC (28~64 bit) | SecOC 車載安全通訊、報文完整性校驗 |
| HASH | SHA-2 (SHA-256/384/512), SHA-3 | 標準雜湊摘要 | 韌體完整性檢查、軟體指紋比對 |
| SIGNATURE_VERIFY | RSA-2048/3072/4096, ECDSA (NIST P-256) | PKCS#1 v1.5, PSS, ASN.1 | CRA 安全刷寫 (FBL)、X.509 憑證鏈校驗 |
| RANDOM_GENERATE | TRNG / PRNG (NIST SP 800-90A) | 高熵真隨機數 | UDS 0x27 Security Seed、交握臨時亂數 (Nonce) |
Csm_JobStart() / Csm_JobUpdate() / Csm_JobFinish()"]:::csmNode QUEUE["【CSM 佇列管理】
CsmQueue 依優先級排序入列"]:::csmNode ARBIT["【CSM 仲裁與狀態機】
Job 排程派發與通道綁定"]:::csmNode CRYIF["【ECU 抽象層】
CryIf 密碼介面路由"]:::ifNode SECOC --> API DCM --> API FBL --> API TLS_MOD --> API API --> QUEUE QUEUE --> ARBIT ARBIT --> CRYIF
3. Job 生命週期與狀態機深度剖析
EB AutoCore CSM 支援兩種核心處理模式：同步模式（CRYPTO_PROCESSING_SYNC） 與 非同步模式（CRYPTO_PROCESSING_ASYNC）。
3.1 非同步狀態機流轉邏輯
在非同步模式下，調用方發起 Csm_JobStart() 後立即返回，不會阻塞呼叫線程。CSM 在內部維護以下嚴格的狀態機：
等待應用層呼叫 Csm_JobStart"]:::idle IDLE -->|非同步請求 ASYNC| QUEUED["【排隊狀態】CSM_JOB_STATE_QUEUED
依 CsmJobPriority 排入佇列"]:::queued IDLE -->|同步請求 SYNC| ACTIVE["【執行狀態】CSM_JOB_STATE_ACTIVE
直接佔用通道並派發底層運算"]:::active QUEUED -->|排程指派至可用通道| ACTIVE QUEUED -.->|主動取消 Csm_JobCancel| IDLE ACTIVE --> COMPLETE["【底層運算完成】觸發完成回調函數 Callback
釋放 CryIf 通道資源"]:::proc COMPLETE --> IDLE
3.2 Csm_MainFunction() 週期性處理職責
在非中斷驅動模式（Polling Mode）下，CSM 依賴定期調用的 Csm_MainFunction() 來執行佇列狀態推進、檢查底層驅動狀態並觸發完成回調。因此，MainFunction 的執行週期直接決定了非同步任務的延遲底線。
4. 排程演算法與優先級搶佔（Priority Preemption）
在多任務車載環境中，不同資安任務的時效性要求存在巨大差異。例如：煞車控制與轉向指令的 SecOC 驗證要求在 1ms 內完成，而雲端下發的 OTA 刷寫包數位簽章驗證（RSA-3072）耗時可能長達數百毫秒。
若一個低優先級的 RSA 驗證任務長時間霸佔底層 Crypto Driver，後續到達的緊急 SecOC CAN FD 報文驗證將在佇列中嚴重積壓，導致車輛動態控制逾時並觸發 DTC 故障碼。
EB AutoCore CSM 提供了基於優先級的搶佔機制（Job Priority Preemption）：
- CsmJobPriority：整數數值（數值越大代表優先級越高）。SecOC MAC Verify 應指派最高優先級（如 255），FBL 簽章驗證指派中等（如 50），背景金鑰生成指派最低（如 10）。
- CsmQueueSize：必須根據最高峰值並發量預留緩衝深度，防止突發負載引發
CRYPTO_E_QUEUE_FULL錯誤。
5. EB tresos 配置實踐與關鍵參數詳解
在 EB tresos Studio 中配置 CSM 模組時，核心在於正確配置 CsmJobs 與關聯的 CsmKeys：
| 配置容器 / 參數項 | 推薦值 / 類型 | 設計考量與說明 |
|---|---|---|
CsmJobs / CsmJobId |
唯一整數 ID | 供上層 SW-C 或 BSW 模組引用的 Job 標識符。 |
CsmJobPrimitiveRef |
指向對應 Primitive | 宣告該 Job 所執行的密碼學演算法類型。 |
CsmJobPriority |
0 ~ 255 | 配置優先級。高頻通訊 Job 務必設定較高數值。 |
CsmJobProcessing |
CRYPTO_PROCESSING_ASYNC |
推薦優先選用非同步模式，避免主執行緒阻塞。 |
CsmJobCryIfChannelRef |
指向具體 CryIfChannel |
將此 Job 綁定至特定的底層驅動通道。 |
🚀 Jotactic（捷策動能）：EB AUTOSAR CSM 專業技術支持與配置服務
CSM 的佇列深度、排程優先級與回調機制直接關乎車載通訊的即時性與穩定性。Jotactic（捷策動能） 基於 EB AUTOSAR 原生架構與標準配置工作流程，在不修改 EB 原廠代碼的前提下，為客戶提供專業技術服務：
- EB tresos CSM 模組參數配置服務：協助客戶在 EB tresos Studio 中進行 CsmJob 優先級、佇列深度（CsmQueueSize）與回調介面的標準參數配置與 ARXML 匯入匯出。
- 技術支持與諮詢服務：提供 EB AUTOSAR CSM 模組標準配置流程與非同步調度機制的技術諮詢，協助客戶排查配置過程中的問題。
- 基於 EB 機制的客製化 Demo 專案開發：基於 EB 原生架構與標準 API 建立 CSM 排程調度驗證 Demo 專案，輔助客戶進行模組功能驗證。
💡 備註：EB AUTOSAR 提供標準化密碼服務管理器模組供客戶開發使用；ECU 與整車是否符合法規或通過資安認證，屬於 Tier 1 與 OEM 客戶系統層級之工程範疇。捷策動能基於 EB 原生機制提供配置與技術支持服務，不修改 EB 原廠代碼，非 AUTOSAR 基礎軟體開發商。歡迎聯絡捷策動能團隊獲取技術支持。