汽车信息安全SHE中的密钥管理

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

随着智能网联汽车的盛行，汽车内部遭受黑客攻击的可能性与日俱增。

为了防范和缓解网络攻击，硬件信任锚（Hardware Trust Anchors）越来越多的被用到汽车控制器领域。

所谓HTA，就是提供了一种基于硬件安全机制的隔离环境，可以有效保护安全敏感数据、为应用控制算法提供各种密码服务。

大家最为熟悉的HTA就是HSM。实际上，除了HSM，HTA还有其他变体，如下：

• SHE：Secure Hardware Extension

• HSM：EVITA Hardware Security Module

• TPM：Trusted Platform Module

虽然HTA这个东西功能都差不多，但是每家芯片厂对于自己的HTA都有不同的称谓，具体如下：

• 英飞凌：Aurix HSM / SHE+

• 瑞萨：Intelligent Cryptographic Unit（ICU）

• 恩智浦：Hardware Security Engine/Crypto Service Engine(飞思卡尔称呼)

• ARM：Trust Zone

不过前几天看到ARM关于HSM、HSE和SHE各自优劣势的文章， 其中描述到“HSM可确保安全的密钥管理、加密操作等，SHE提供基于硬件的安全功能，如安全启动、安全存储”。

这引起了我的好奇，实际上我们知道HSM本身也可以做到SHE提供的这些功能，SHE本身也与Evita Light HSM非常类似，如下图：

那么为什么还要单独把SHE拉出来讨论呢？

从个人角度，主要是想要搞明白EVITA HSM和SHE的由来，同时借鉴这二者的密钥管理策略来修正当前正在设计的信息安全固件的密钥管理系统；

从使用角度来看，NXP的S32K1、MPC5777C等继续在使用CSE(即SHE)；

从客户调研情况来看，SHE仍有市场，因此理清SHE的由来是十分有必要的。

2.1 分清SHE和EVTIA HSM

SHE--Secure Hardware Extension，是由奥迪、宝马、Escrypt等在2009年提出的规范，本意是给HIS所有成员使用；从AUTOSAR R19-11版本开始，该规范被纳入到AUTOSAR。

SHE规范版本记录

根据规范描述，SHE是MCU的硬件扩展，旨在保护关键信息免受软件攻击，因此它在设计之初提供的功能就相对较少。

而EVITA 不一样，它是由欧盟委员会共同资助的项目，目的是为汽车车载网络提出一种架构，该架构可以保护安全相关组件不被篡改，保护敏感数据不被泄露。根据车车通信、车云通信等又分为了Light、Medium和Full三个等级的HSM。

EVITA成员

因此个人认为在芯片厂最初设计芯片Security架构时，针对SHE和HSM是有不同的目标群体。

2.2 SHE架构

既然SHE是硬件扩展，那么带SHE的MCU逻辑架构其实就很清楚了：

在SHE(即Secure Zone)包含一个控制逻辑(例如NXP S32K1就使用了FTFC Core)，一个AES硬件加速器、内部Memory 。

根据SHE组成部件，可以分析其作用如下：

• 防止加密密钥被软件攻击(通过仅与CPU交互实现)

• 提供对称加密算法(AES实现)

• 提供可信安全的软件运行环境

• 允许部署分布式密钥(memory实现)

因此，如果一个汽车应用场景需要简单的信息安全，例如仅需要单核实现SecOC通信和存储敏感数据，SHE无疑是首选，功能满足需求且成本较低。

2.3 SHE的数据存储和管理

密钥和MAC值的存储需要使用SHE内部memory，每个密钥均搭配一个位宽128bit的memory slot。

针对Key，SHE给出了如下三种分类：ROM Key、NvM Key、RAM Key。

逻辑框图如下：

进一步的，HIS-SHE规范中设计了15个密钥，以及密钥存储位置如下：

每个密钥用法具体解释如下：

• SECRET_KEY：芯片制造过程中注入的随机值，该值不可见也不可更改，因此该密钥基本就在密钥导入导出使用；

• MASTER_ECU_KEY：作为身份授权密钥，用于更新其他用户密钥（Key1-Key10）或者重置；

• BOOT_MAC_KEY：安全启动用于验证软件MAC的密钥；

• BOOT_MAC：存放BootLoader的MAC值；

• KEY1-10：用户自定义KEY；

• RAM_KEY：存储在 RAM 区域的可随时更改的密钥；

• PRNG_STATE和PRNG_KEY：随机数生成器内部使用密钥，用户不能访问。

虽然上表中的每个Key的地址是按字节排布，但是实际这些Key的物理内存地址是不相同的，所以在使用过程中可以把上述地址看做密钥的KeyID，毕竟从MCU的CPU视角来看，是只能通过KeyID来分辨。

上述密钥既然定义了名字，那么每个密钥的职责也是有所不同的，因此标定定义了6个配置属性(即6个bit)来表示当前密钥的功能。

如果密钥被更新了，还需要有相应计数器（标准定义28btis）来进行计数，因此密钥存储的相关信息可以总结如下表所示：

需要注意的是，出厂后，芯片只有SECRET_KEY有值，其他均为空白。

因此，在涉及到SHE的软件开发中，最重要的一步就是将密钥存储到SHE内部Flash空间。

目前MCU多用DFlash模拟EEPROM，因此首先需要将DFlash做空间划分，这就要求MCU在芯片设计之初就预留好这一段空间，保证SHE使能后，该段memory从硬件层面只能有SHE内部访问。

除此之外，为了保证密钥的完整、真实、机密以及防重放攻击，HIS-SHE中专门定义了一章内容用于阐述Memory更新策略。

该策略简单描述如下如下图所示：

1.  OEM把ECU UID、CID(密钥更新次数值)、FID(密钥功能配置)、授信密钥Kauth(ECU_MASTER_KEY)以及Knew(待更新的密钥)发送给生成器；

2. 生成器计算出M1-M5，并提供给工厂相关负责人；

3. 负责人使用诊断工具把M1-M3(包含加密的待更新密钥值)发送给ECU，ECU使用授信密钥对数据进行解密得到M3，比对M3值一致后固化新的密钥；

4. 如果用户设置了proof，ECU还要计算M4'和M5’并返回给诊断仪；

5. 诊断仪比对M4M5的值；

6. 如果比对成功，诊断仪返回给生成器；

7. 生成器增加一次CID，并返回给OEM，以便下次密钥更新使用。

经过对规范的分析和消化，大家应该对SHE架构和密钥管理这方面有了初步认识；在供应商代码里再也不用会SHE_Proof这类词汇感到困惑。

如果对这方面感兴趣的，可以在NXP申请S32K1的相关软件和EB配置工具，从代码和配置角度去理解SHE。