之前我們把SHE密鑰更新流程做了梳理，汽車信息安全 -- SHE 密鑰更新流程

但在實際做SHE Emulation的時候還是發現了問題，例如如果想更新SHE Key ID等于30，會如何影響M1-M5的值呢？。

今天就聊聊關于幾家對于SHE Key的管理。

1. NXP S32K1 CSEc

?S32K1xx 的 CSEc 模塊是一個硬件加密模塊，符合 HIS-SHE specification 1.1 rev 439 和 GM-SHE+ 安全規范標準。

在密鑰數量方面，HIS-SHE標準中支持最多15把Key，如下圖：

但根據文檔描述，CSEc 模塊一共可存儲 24 個密鑰，用戶密鑰最高可配置17把(難道是GM-SHE+的需求？)，如下表所示：

為了適配HIS-SHE的規范，K1引入了KBS的概念來管理和索引密鑰，

如上所示，每個密鑰有一個密鑰ID，密鑰 ID 由KBS+KEY IDs兩部分組成，CSEc 模塊都是通過KBS來選擇具體密鑰所在塊，通過KEY ID來決定使用哪一個密鑰，這樣就可以對所有的 17 個用戶密鑰進行索引。

例如密鑰 1~密鑰 10 在在塊 0區域，密鑰 11~密鑰 17 在塊 1（Bank1）區域，那么密鑰1的密鑰ID為0x04（KBS：0x0, KeyID：0x4），密鑰10的密鑰ID為0x0D(KBS：0，Key ID：0xD)，密鑰 11 的 Key ID 則為 0x14（0x1,0x4），密鑰17則為0x1A。

這樣就既滿足SHE key的要求，又滿足了超過15把SHE Key的需求（但有一點，它的RAM Key序號變為了0xF，而非SHE Spec里的0xE）。

滿足SHE Key的要求在于，如果要更新用戶密鑰，大家就可以按照規范去離線計算m1-m5，如下圖：

我們在拼接M1的時候，規范要求始終是SHE ID，長度只有4bits，這意味著如果按Spec實現，就只能更新最多ID 1-15?的密鑰。那如果超過了15把密鑰，這不就完犢子了。

因此，CSEc在實現時就加入了多個用戶密鑰塊的管理思路，如下所示：

通過往KBS寫入0、1來選擇使用哪個塊的密鑰，通過Key Id來索引對應塊中的實際ID。

?我們再回過頭來仔細看，

Key01 - Key17都是由塊號+KEY ID構成，而KEY ID永遠滿足SHE的KEY ID（Spec叫Key Address，0x4-0xD）的要求，如下圖所示。

需要注意的是，如果要使用0x0-0x3的ID，KBS必須填0。

2. ETAS? SHE Emulation

ETAS CycurHSM是一個固件，由于不依賴特定平臺，所以它們應該是使用軟件模擬SHE的方式。

該軟件包不僅支持SHE，還支持SHE+ ，最高支持40把額外Key，總計50把SHE Key，對應KEY1-KEY50。

有趣的是，它們也采用了類似K1的做法，將上述50把key分為了5個Bank，通過指定API來選擇索引哪一個Bank的哪一個Key，如下所示：

但不管是使用哪個bank，0x0-0x3的ID永遠是固定用途且只有一份，因此Bank也只能選0。?

3.Vector veHSM

veHSM相較于上述兩家，方案稍顯靈活，但毫無疑問，它們也使用軟件模擬SHE的方式。

在SHE Key方面，它們利用Page的方式進行管理（類似上述的Bank），每一個Page支持10把用戶定義的key和1把RAM key，最多可達255個page（所以理論上只要Flash空間夠，SHE Key大大的有），當然特定ID 0-3仍然使用的是Page0里存放的Key，這會在配置時自動索引。

由于veHSM的實現和AUTOSAR Crypto的API相關，因此就出現了Key ID到SHE ID的映射轉換，

這樣也就不用上面兩家再單獨調API或者操作寄存器來切換SHE Key的BANK。

Host只需要傳入Key ID，在SHE處理的時候會自動轉換到目標page和key id(she address)。

?

妙啊。

?