點擊上方藍字談思實驗室

獲取更多汽車網絡安全資訊

HSM 的全稱是：

Hardware Security Module

直譯就是：

硬件安全模塊

如果你把 AURIX 主芯片想象成一家公司，那么：

• TriCore CPU 像業務部門

• Flash / RAM 像資料庫

• 外設像生產工具

• 而 HSM 更像一個獨立的安保與審計部門

這個部門不負責跑你的主業務邏輯，但它負責做幾類特別敏感的事情：

1. 啟動前先檢查程序能不能信

2. 處理密鑰

3. 做加密、認證、哈希、隨機數

4. 控制某些調試權限能不能打開

5. 在系統安全這件事上，替主 CPU 扛一部分“可信執行”的責任

所以，HSM 不是普通加速器，更不是“一個庫函數”。 它本質上是一塊獨立運行的安全子系統。

圖 1：AURIX HSM 總體架構。它在芯片里不是一個“功能點”，而是一套帶獨立 CPU、Bridge、AES、PKC、TRNG、本地 RAM/ROM 的安全子系統。 來源：HSM_TS_V2.0_Rev2.0.pdf，Figure 1-1 Architecture Overview。

在 PC、手機、服務器里，安全很重要；但在汽車里，安全不僅是“數據安全”，還可能直接影響功能安全和車輛控制。

舉幾個最常見的場景：

1. 防止非法刷寫

如果攻擊者把 ECU 固件換成惡意版本，輕則篡改參數，重則影響整車控制邏輯。

2. 防止調參攻擊

很多汽車控制器里有標定參數、扭矩限制、速度限制、診斷策略。 如果這些被非法修改，后果可能非常嚴重。

3. 做安全啟動

也就是常說的 Secure Boot。 系統上電后，不是“有代碼就跑”，而是“先證明這份代碼可信，再決定要不要跑”。

4. 做安全通信

車內 ECU、傳感器、網關之間越來越多地需要做身份認證和報文完整性校驗。

5. 做安全升級

尤其是 OTA 場景，更新包必須驗證來源、版本和完整性。

一句話總結：車規芯片不是只要“能算”就夠了，它還必須回答“這段代碼能不能信、這份數據有沒有被改、這個人有沒有權限調試和更新”。

而 HSM，就是為這些問題服務的。

很多人第一次學 HSM，最容易犯的錯誤是：

覺得它就是一個“帶加密指令的從核”。

這只說對了一小部分。

在 AURIX TC3xx 體系里，HSM 的關鍵特點是：

1. 它有自己的執行環境

HSM 不是跑在 TriCore 上的一個任務，而是有自己獨立的處理核心和運行空間。

2. 它有自己的安全邊界

HSM 內部的很多寄存器、密鑰槽、局部 RAM，并不是主 CPU 想看就能看。

3. 它能更早介入啟動流程

這點非常關鍵。 在 Secure Boot 場景下，HSM 可以在主業務核真正運行前，先做認證和放行判斷。

4. 它不是單一算法模塊，而是一整套安全子系統

AURIX HSM 通常包含：

• TRNG：真隨機數發生器

• AES：對稱加密模塊

• HASH：哈希模塊

• PKC：公鑰密碼模塊

• Bridge：與主核通信的橋梁

• Boot ROM / 本地 RAM / Watchdog / Timer 等安全運行基礎設施

所以，真正的理解方式不是：

HSM = 加密器

而是：

HSM = 一個能獨立執行安全任務、并帶有密碼學硬件能力的安全執行域

圖 2：HSM Bridge 總覽。可以把它理解成 HSM 和主系統之間的“安全邊界 + 通信橋梁 + 訪問控制入口”。 來源：HSM_TS_V2.0_Rev2.0.pdf，Figure 9-1 HSM bridge overview。

下面我們按“小白最容易理解”的方式講。

1. 它能做隨機數

HSM 里通常有 TRNG，也就是真隨機數發生器。

這有什么意義？

隨機數是很多安全機制的根。比如：

• 會話密鑰生成

• 挑戰應答

• 一次性數值

• 某些簽名和認證流程

如果隨機數不靠譜，很多“看起來很安全”的機制其實都站不住。

2. 它能做對稱加密和認證

最典型的是 AES。

你可以把它理解成：

• 能把數據加密

• 能驗證數據有沒有被改

在很多車載場景里，AES-CMAC 這種對稱認證機制很常見。 比如 Secure Boot 里，就可能用它來驗證程序鏡像是否被篡改。

圖 3：AES 基本加解密示意。小白可以先把它理解成“同一把密鑰既參與加密，也參與解密驗證”的基礎能力。 來源：HSM_TS_V2.0_Rev2.0.pdf，Figure 4-1 AES。

3. 它能做哈希

哈希可以理解為：

給一大段數據算出一個“指紋”

如果數據改了一點點，指紋就會明顯變化。

這在完整性校驗、簽名前摘要、文件驗證里很常見。

4. 它能做公鑰密碼

也就是 PKC。

這一塊通常用來做：

• 簽名驗證

• 身份認證

• 更高級的 Secure Boot

• 安全升級

如果說對稱算法更像“雙方共享同一把鑰匙”， 那公鑰密碼更像“公開鎖、私有鑰匙”的機制，更適合大規模設備認證和升級簽名場景。

5. 它能參與 Secure Boot

這是 AURIX HSM 最常見、也最容易被工程師關注的用途。

簡單說就是：

1. 上電

2. HSM 先起來

3. HSM 去檢查主程序是不是可信

4. 如果可信，就放行主 CPU

5. 如果不可信，就不讓它正常啟動

這一點決定了 HSM 不只是“算密碼”，而是“參與系統信任鏈的起點”。

6. 它能管調試權限

很多安全體系里，調試口不是想開就開。 HSM 可以參與判斷：

• 調試認證是否通過

• 某類敏感資源是否允許訪問

這對防止量產后被隨意調試、讀密鑰、抓內部狀態非常重要。

如果只講一句最核心的話，那就是：

Secure Boot 的本質不是“會算一個校驗值”，而是“誰來決定這段代碼值不值得被執行”。

在 AURIX 架構下，HSM 之所以關鍵，是因為它比主業務核更適合扮演這個裁判角色。

典型的思路是這樣

• 啟動參數保存在安全配置區

• HSM 讀取這些參數

• HSM 對主程序區做哈希或 CMAC

• HSM 把計算結果和參考值比較

• 比較通過才釋放 CPU0

這個設計的價值在于：

• 認證邏輯不依賴主業務程序自己“自證清白”

• 密鑰或參考值可以放在更受控的位置

• 啟動是否繼續，不再只是普通軟件分支判斷

這就是為什么很多學習 AURIX HSM 的人，最終都會從 Secure Boot 這個場景真正理解它。

圖 4：BOS 啟動總覽。核心意思很簡單: 先看啟動請求是否合法，再決定進入 Testmode、Usermode，還是直接鎖定并休眠。 來源：HSM_TS_V2.0_Rev2.0.pdf，Figure 11-2 BOS startup overview。

圖 5：HSM 對用戶啟動代碼的檢查流程。它不是“主 CPU 自己說自己可信”，而是 HSM 逐步檢查候選啟動段，找到合法入口后才放行。 來源：HSM_TS_V2.0_Rev2.0.pdf，Figure 11-6 BOS User-OS code check。

這一點必須說透，不然文章會誤導人。

很多人一聽到 HSM，就會默認：

只要芯片里有 HSM，系統安全就有保障了。

其實不是。

1. HSM 提供的是能力，不是自動閉環

HSM 能提供：

• 算法能力

• 安全邊界

• 更可信的執行位置

但它不會自動幫你完成：

• 密鑰生命周期管理

• 升級策略設計

• 失敗恢復策略

• 版本回滾保護

• 完整的異常診斷閉環

2. 有 HSM，不代表軟件邏輯一定正確

舉個最典型的工程問題：

如果你明明算了 CMAC，但最后函數無條件返回成功， 那系統表面上“用了 HSM”，實際上還是可能把非法鏡像放過去。

所以真正重要的是：

安全能力要變成安全閉環

3. HSM 也不是萬能的物理防護罩

從規格書角度看，AURIX HSM 也明確有邊界。 例如，很多硬件模塊本身并不自動等于“抗一切物理攻擊”。

也就是說：

• 抗側信道

• 抗故障注入

• 更復雜的物理攻擊防護

這些仍然需要系統設計和軟件配合，不能把鍋全甩給 HSM。

誤區 1：覺得 HSM = 加密模塊

錯。 加密模塊只是 HSM 里的一個子能力。 HSM 更像一個安全子系統。

誤區 2：覺得 HSM = Secure Boot

也錯。 HSM 能支撐 Secure Boot，但 Secure Boot 是一整套機制，不只是一塊硬件。

誤區 3：覺得有 PKC 就一定比對稱方案高級

不一定。 對稱方案和非對稱方案適用場景不同。 很多量產系統會先把對稱閉環做扎實，再升級到非對稱。

誤區 4：覺得“跑通 Demo”就等于“能量產”

這是最常見的誤區。 Demo 解決的是“能展示主線”，量產方案解決的是“異常時也不能出錯”。

我建議按這個順序：

第一步：先建立全局印象

先記住一句話：

HSM 是 AURIX 里負責安全能力和安全決策的一塊獨立執行域。

第二步：搞懂它的核心模塊

至少要知道這幾個詞是干什么的：

• TRNG

• AES

• HASH

• PKC

• Bridge

• Secure Boot

第三步：從 Secure Boot 場景進入

因為這是最容易把“算法、密鑰、配置、啟動控制、主核放行”串起來的場景。

第四步：再去看規格書

很多人一上來啃 HSM Target Specification，會直接被寄存器和地址空間淹沒。 更好的方法是：

1. 先知道它大概在干什么

2. 再回頭看規格書確認“硬件到底給了哪些能力”

第五步：最后再看量產化差距

包括：

• 密鑰管理

• 版本管理

• 回滾保護

• 失敗恢復

• 調試認證

這樣你會從“能看懂”走向“能設計”。

我會這么說：

AURIX 的 HSM，本質上不是一塊單純做加密運算的硬件，而是一個獨立、可參與系統信任決策的安全子系統；它最重要的價值，不是“算得快”，而是“能在更可信的邊界里，替整車控制系統做安全相關的判斷與執行”。

來源：嵌入式程序猿

https://mp.weixin.qq.com/s/FwVUo5gRA3vHMLvLfkwtYQ