汽车信息安全 -- 存到HSM中的密钥还需包裹吗？

1.车规芯片的ROM_KEY

2.密钥加密与包裹

3.瑞萨RZ\T2M的密钥导入

4.小结

在车控类ECU中，我们通常把主控芯片MCU中的HSM以及HSM固件统一看做整个系统安全架构的信任根。

所以大家默认在HSM内部存储的数据等都是可信的，例如CycurHSM方案中使用HSM硬件存储认证启动所需要的公钥，保证该公钥不被篡改；vHSM同理。

但是，最近交流听说有工具可以将某芯片的所有Flash全部dump出来，首先我对这个保持怀疑，其次结合之前从实际调试来看，有部分OEM或者Tier1以明文形式将存储这些密钥信息（最多加个厂家自定义混淆算法）存储在HSM独占DFlash中。假设这个工具是确实存在，那这些明文形式的密钥就有泄露的风险。

所以今天就来看看关于密钥包裹的一系列话题。

1.车规芯片的ROM_KEY

目前国外大多数车规MCU的HSM设计雏形都来源于SHE(Secure Hardware Extensions)。所以我们首先来回顾下，SHE长什么样，如下图所示：

从上图可以看到，SHE中的RAM、NvM、ROM用于存储密钥，密钥槽定义格式如下：

其中，SECRET_KEY存储在ROM中，是由芯片厂在流片时固化到SHE中，仅能有SHE读取，用户端只能通过索引引用。

这个做法也沿用到了现在的芯片上，例如英飞凌TC3xx的HSM AES引擎中包含了两个Key，分别是PRIVATE_KEY（UID）和SECRET_KEY，如下图：

瑞萨RH850-U2A的AES引擎包含了3个ROM_KEY供其使用；

同样的，NXP S32K3内部也包含了ROM KEY作为设备的信任根，如下图：

一般来说，ROM_KEY 主要是用于密钥的导入、导出和派生。

2.密钥加密与包裹

回到我们开头的话题，如果说工具真能DUMP出HSM内部Flash的数据，那么密钥就会存在泄露的风险，因此就需要对密钥进行数据混淆处理。

首先大家想到的肯定是对密钥进行加密后再存储到Flash中，如下图：

使用的时候再解密出来，但这有个问题，如果存在Flash中的密钥由于ECC等错误造成了加密后的数据出现错误，那么解密出来的数据就不是原来的密钥的呀。

为此，我们需要做什么？

当然是再添加一个完整性，这也就是所谓的密钥包裹(Wrap)。

Key Wrapping = Encryption + Intergrity

这一点我们可以在TC3xx的HSM中得到印证。

TC3xx HSM中的AES引擎前两个密钥槽给到的是Private Key和Secret Key，如何保证数据完整性和机密性？如下图所示：

首先在HSM BootRom里有两个MASK Key和IV，其中Mask-Key2用于解密Encrypted Private Key\Secret Key，Mask-Key1和IV用于计算上述区域的MAC(Hash)，完成比对后再把Key进行加载，这样最大限度保证了数据的机密性和完整性。

3.瑞萨RZ\T2M的密钥导入

有了上述ROM KEY、Key Wrapping、Key Encryption的概念后，最后我们来拓展拓展芯片厂自研的一些密钥管理系统。其实主要还是关心用户密钥是如何灌装到芯片内部的。

以瑞萨RZ/T2M为例，它是一款行业领先的高性能、多功能MPU，可实现 AC 伺服系统和工业电机等工业设备的高速处理、高精度控制和功能安全。

RZ/T2M 具有最大频率为 800 MHz 的双 Arm® Cortex®-R52 内核，可进行实时控制，而且还拥有能够与 CPU 直接连接的大容量TCM (576KB)，以实现高性能实时处理。此外，它还可以将电机控制的外设布置到能直接连接至 CPU 的 LLPP（低延迟外设端口）上，来实现较低的延迟访问。它本身还包含Security，因此有一套很完善的密钥管理工具，可以帮助用户端安全导入密钥。

其大致步骤如下：