【EB AutoCore 模組精解】
CryIf 密碼抽象介面層
軟硬體解耦、通道多路複用與金鑰透明重定向架構。CryIf（Crypto Interface）是實現車載軟體跨平台重用與軟硬體解耦的關鍵樞紐。深入解析 EB AutoCore 架構下 CryIf 的通道派發機制、多後端驅動分流、金鑰透明映射（Key Redirection），以及零開銷調度策略。
1. 為什麼需要 CryIf 抽象介面層？
在 AUTOSAR 早期規範中，服務層往往直接對接特定的硬體驅動，導致系統若更換底層晶片或引入第三方軟體密碼庫，上層業務邏輯代碼將面臨大規模重構。
自 AUTOSAR 4.4 / R20-11 起，正式確立了 CryIf（Crypto Interface，密碼抽象介面層）。在 EB AutoCore 架構中，CryIf 位於服務層（CSM）與驅動層（Crypto Driver）之間，扮演著「密碼學路由器」的關鍵角色：
- 隱藏底層實現差異：上層 CSM 只需面對標準的
CryIfChannelId與CryIfKeyId，底層究竟是硬體加速安全核心（HSM），還是純軟體運算的Crypto_EB函式庫，對 CSM 完全透明。 - 多後端併行支援：單一 ECU 內可同時註冊硬體加速驅動（處理高頻 SecOC 與安全啟動）與軟體演算法驅動（處理次要的非對稱加解密），CryIf 負責動態路由派發。
- 接近零效能損耗（Near Zero-Overhead）：EB AutoCore CryIf 採用高度優化的內聯函數（Inline Function）與靜態查表派發，確保呼叫鏈路的延遲達到微秒級。
2. 通道多路複用與多驅動路由機制
當 CSM 收到來自應用層的 Job 並排程就緒後，呼叫 CryIf_ProcessJob(channelId, job)。CryIf 透過配置的映射關係，將 Job 轉發至相應的驅動實體：
CsmJob 佇列管理與通道派發"]:::csmNode CH_FAST["【CryIf 通道 0 · 高優先級】
CryIfChannel_0"]:::cryifNode CH_SLOW["【CryIf 通道 1 · 背景計算】
CryIfChannel_1"]:::cryifNode HW_OBJ["【硬體安全驅動 HW Crypto Driver】
CryptoDriverObject_HSM
(專責硬體加速 AES-CMAC, SHA-256)"]:::drvHw SW_OBJ["【軟體密碼庫驅動 Crypto_EB】
CryptoDriverObject_SW
(專責純軟體運算 RSA-PSS, ECC 備援)"]:::drvSw CSM -->|高優先級：SecOC 報文驗證| CH_FAST CSM -->|背景任務：診斷憑證解析| CH_SLOW CH_FAST -->|透明轉發至底層硬體| HW_OBJ CH_SLOW -->|透明轉發至軟體庫| SW_OBJ
3. 金鑰重定向（Key Redirection）架構：保障隔離性
在複雜的 ECU 專案中，上層服務（如 KeyM 或 SecOC）定義的金鑰識別碼往往是通用的邏輯 ID（例如 KeyId = 1），但底層硬體安全模組中的金鑰槽位（Key Slot）可能是物理固定的（例如 HSM NVM Slot 5）。
CryIf 提供了強大的 金鑰重定向（Key Redirection） 功能：
| 層級 | 識別碼 | 角色與意義 |
|---|---|---|
| 服務層 (CSM / KeyM) | CsmKeyId / KeyMKeyId |
抽象業務邏輯金鑰（如「動力 CAN FD 通訊金鑰」）。 |
| 抽象層 (CryIf) | CryIfKeyId |
重定向映射中心：將上層 ID 轉換為指定 Driver 的特定 Key 參照。 |
| 驅動層 (Crypto Driver) | CryptoKeyId / KeyElementId |
對應硬體安全記憶體中的實體物理金鑰槽位。 |
4. 支援 ISO 21434 軟體架構解耦需求
ISO/SAE 21434 特別強調「網路安全架構在車輛全生命週期中的可維護性與韌性」。藉由 EB AutoCore CryIf 模組：
- 降低硬體更迭對上層架構之衝擊：當車載控制器因應供應鏈更替或硬體改版更換驅動時，上層 CSM、KeyM、SecOC 與 SW-C 業務邏輯介面維持一致，工程團隊僅需在 CryIf 重新定向通道映射至新版 Crypto Driver，大幅減少上層應用代碼的更動成本。
- 純軟體備援模式快速切換：在硬體安全模組尚未完成燒錄的樣件階段，可在 CryIf 中將通道切換至軟體
Crypto_EB進行通訊調試，解鎖硬體交付依賴。
5. EB tresos 配置實踐與關鍵參數
在 EB tresos Studio 中配置 CryIf 模組時，核心在於正確配置通道與金鑰容器：
| 配置容器 / 參數項 | 典型設定值 | 工程意義與說明 |
|---|---|---|
CryIfChannels / CryIfChannelId |
0, 1, 2... | 邏輯通道唯一編號，供 CSM Job 參照。 |
CryIfDriverObjectRef |
指向具體 CryptoDriverObject |
將此邏輯通道精準綁定至底層驅動實體。 |
CryIfKeys / CryIfKeyId |
0, 1, 2... | 邏輯金鑰唯一編號，供 CSM 原語關聯。 |
CryIfCryptoKeyRef |
指向底層 CryptoKey |
實現邏輯 Key 到底層實體 Key 的映射。 |
🚀 Jotactic（捷策動能）：EB AUTOSAR 抽象層配置與技術支持服務
良好的軟硬體解耦架構是車載軟體資產長期維護的關鍵。Jotactic（捷策動能） 基於 EB AUTOSAR 原生架構與標準配置工作流程，在不修改 EB 原廠代碼的前提下，為客戶提供專業技術服務：
- EB tresos CryIf 模組參數配置服務：協助客戶在 EB tresos Studio 中進行 CryIf 通道（CryIfChannel）、驅動對象關聯與金鑰重定向（Key Redirection）的標準配置與 ARXML 匯入匯出。
- 技術支持與諮詢服務：提供 EB AUTOSAR CryIf 抽象層配置流程與介面調用的技術諮詢，協助客戶排查配置過程中的問題。
- 基於 EB 機制的客製化 Demo 專案開發：基於 EB 原生架構與標準 API 建立多通道分流驗證 Demo 專案，輔助客戶進行模組功能驗證。
💡 備註：EB AUTOSAR 提供標準化 CryIf 模組供客戶開發使用；ECU 與整車是否符合法規或通過資安認證，屬於 Tier 1 與 OEM 客戶系統層級之工程範疇。捷策動能基於 EB 原生機制提供配置與技術支持服務，不修改 EB 原廠代碼，非 AUTOSAR 基礎軟體開發商。歡迎聯絡捷策動能團隊獲取技術支持。