汽车信息安全 -- HSM是否可以作为信任根？

信任锚和信任根
汽车中的硬件信任锚
HSM可以作为信任根吗？

最近在讨论汽车信息安全时听到一些新的概念：在车规MCU中HSM不能作为信任根。

但回想起之前做ECU产品时，HSM又像个黑盒子；特别是在做安全启动时，基本只做Host侧程序数据的身份、完整性验证，这很明显是把HSM当作了信任根。

有分歧就有讨论，偏信则暗，兼听则明；

那么今天就来收集整理下信任根、信任锚等概念，理清思路；

1. 信任锚和信任根

首先来搞清楚信任锚和信任根这两个最容易混淆的概念。

根据NIST相关标准，对于信任锚有多处定义，原文如下：

总结下来，信任锚是在信任模型中的起点和基础；它就像轮船的铁锚，起着固定系统的作用，将系统控制在可控范围，不至于跑得太远。

因此，个人理解信任锚的具体角色不一定是固定的，它可以是一组根证书（在PKI里），也可以是对称私钥或者是公钥（例如目前MCU里芯片厂预置的AES密钥、RSA公钥等）。

对于信任根(Root of Trust)，NIST SP800-164-Draft则有如下描述：

很明显，信任根指的是能提供授信、信息安全相关功能的软硬件；

相较于信任锚点，它所指的对象更加更加广泛，个人理解，只要是能防范各种恶意攻击和数据泄露风险的系统，确保信息交互处理中数据的安全和完整性，都可被认为是可信任的。

因此，一般来讲在安全领域中的RoTs可以包括安全芯片、安全启动程序、HSM等等。

虽然有时候我们会将信任根和信任锚点混为一谈，但这中间细微差别还是需要掌握。

2. 汽车中的硬件信任锚

来到汽车行业，信任根和信任锚的界定变得更加模糊。现在针对汽车信息安全基础，更为通用的说法则是HTA (Hardware Trust Anchors).

所谓的硬件信任锚(HTA)，其功能就是提供了由硬件安全机制引导的隔离运行环境，以实现敏感数据的安全存储和处理。

HTA有多种变体，可以保护隔离环境免受攻击，减轻针对软件漏洞的逻辑攻击，还可以检测和防止对硬件安全机制的物理攻击。

根据《Evaluating the applicability of hardware trust anchors for automotive applications》整理，HTA可分为如下类别：

安全芯片，有独立接口与其他芯片通信，例如TPM(SLI 9670)
安全子系统：集成到芯片内部，有自己独立的隔离运行环境；例如SHE、HSM
可信执行环境：TEE，与REE(Rich execution )共存，如ARM的Turst Zone，Intel的SGX

而大家最为熟悉的HTA，其实就是各大芯片厂的HSM/SHE，例如英飞凌Aurix的HSM\SHE+ Driver、瑞萨RH850的ICU，恩智浦的HSE；虽然名字不同，但是功能都很相近。

那么为什么大家愿意叫HTA呢？

我大胆胡说一下：因为上述芯片都把信息安全相关功能锚点在授信的、单独受保护的硬件中。

3. HSM可以作为信任根吗？

铺垫了那么多，最后回到本文重点的问题：HSM可以作为信任根吗？

首先我们来拆解什么是信任根：能提供授信、信息安全相关功能的软硬件。

那么可不可以这么理解，信任根应该是一个大的组件或者系统，至少得有如下构成：

提供可信执行环境（TEE），供关键软件运行；
必须具备密码服务硬件加速功能，以缓解主核负载；
必须具备防篡改机制，例如篡改留证、篡改抵抗，这是安全存储的前提；
分层防御机制：提供强大的分层防御，避免单点故障。例如仅单一接口和主机ID对访问加密硬件模块和其他敏感安全资源，同时仅加密硬件模块可访问关键密钥。

而这些功能恰好都是HSM的强项，所以个人理解HSM本身在汽车ECU里是可以作为信任根的。

假设HSM不能作为信任根，那么能够提供以上功能的还有什么？

纵观MCU，唯一难篡改的就只能是BootRom；如果把HSM内部的BootRom作为信任根，那么在做安全启动的路径就先得校验并运行HSM 固件代码，再由HSM 固件代码校验Host程序：