HSM和TEE

本文摘自牛咖网文章
HSM和TEE
HSM为其他应用程序提供密钥管理和加密功能。
TEE还提供让应用程序（或应用程序的安全相关部分）在其隔离环境中执行的功能。
常规执行环境 (REE)是TEE社区中的术语，用于表示设备中特定TEE之外的所有内容。
HSM如何解决安全问题
在集成HSM的设备中，软件架构如下所示：

HSM为安全任务提供加密服务。
REE中的“安全”任务提供数据，HSM可以接收该数据并加密或解密该数据，然后再将其返回给REE中的任务发布者。

支持TEE的设备中实现HSM功能

在Android设备中，上述HSM通常由TEE中的TA代替，实现Keymaster功能和Android特定REE堆栈，而不是OpenSSL/PKCS#11。
对于上面的案例，即便在发动机控制器(ECU)中的简单的常规OS，也已专门编写通用TA以提供典型得HSM功能。

TEE可以完成HSM不能完成的工作
TEE不需要像HSM那样用作固定用途的服务提供者，它也可以直接处理任务。

在这里，我们将任务移到TEE中，就可以在REE中活动无法访问的地方对未加密数据进行操作。
举个例子：
– 设备通常支持其他任务，例如复杂的通信协议（例如CAN总线、IP、蓝牙甚至5G ）。
– 这些通信机制可能会或可能不会被特定的安全任务使用。
– 通过将安全任务放置在与该通信软件隔离的某个地方（例如，在TEE中），通信软件中的安全问题不再拖累安全任务的安全性。
一些HSM可以通过专有扩展加载代码执行，但符合GlobalPlatform的TEE使用标准化接口，使为一个TEE开发的任务能够在另一个TEE上执行。在TEE中执行的此类任务称为“受信任的应用程序”。

HSM不能直接保护提供传感器数据或控制执行器的I/O端口免受软件攻击，例如汽车ECU的REE。

与HSM不同，在正确设计SoC上，TEE还可以与外围设备连接。这样就可以创建一个安全的任务，安全地存放在TEE内，可用于显着增强关键任务的安全性。

举一个汽车燃油节流阀的案例。如果ECU上的油门I/O控制端口暴露在REE软件中，那么使用HSM的REE“安全”任务带来多少安全性并不重要；如果对REE本身的安全性有很高的信心，就不会使用HSM，因此无法确信REE中的软件不会受到攻击。
如果REE容易受到攻击，这意味着受攻击的REE软件可能会未经授权访问该I/O端口，无论HSM有多好。
在TEE（就像在HSM中）中，我们没有与安全无关的软件任务的顾虑。TEE中的任务可以连接到硬件控制端口，而不会有被其他软件进行未经授权访问的风险。
如果在上面的例子中只有一个HSM，那么所能做的就是保护设备的数据流，而不是设备中的决策。有了TEE，可以两者兼得。

物理攻击：TEE和HSM

正如我们在上面看到的，使用HSM的一个问题是在发生加密之前数据通信的暴露。
– 这会影响软件中的数据，在HSM有机会对其采取行动之前，就可以通过损坏的REE提取或修改数据。

– 这也会影响硬件攻击面。

从根本上说，设备集成HSM可以使用SoC上的硬件方法来保护其密钥不被提取，这比TEE的密钥更强大。但是，将数据传输到HSM通过这些密钥进行保护的方法并没有比TEE更强，而且可能要弱得多。
考虑以下与PCB连接的HSM与典型的TEE对比，后者将使用堆叠芯片（封装上的封装）来保护其更高的速度流量：

如上所示，更强的TEE甚至可以不使用外部RAM，而是使用SoC RAM。

在这种情况下，使用TEE提供传统HSM功能的好处是显着减少了未受保护数据的暴露，从而增强了平台的整体安全性。
最后，如果您担心密钥提取，无论是使用TEE还是HSM，建议设计保持较小的密钥大小。
值得注意的是，在EVITA 标准中，一些HSM类型与REE在同一个SoC上，在这些情况下，它们的硬件保护方法通常与TEE一样。