之前我们把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)。

 

妙啊。