增加并隔离信任根以实现芯片设计的更高安全性

一颗芯片的安全设计可以有多个实体，且其上运行的不同应用程序是被隔离的。

在听说了很多硬件漏洞比如Spectre、Meltdown和Foreshadow之后，可能很多SoC和系统设计人员们都在思考如何在不牺牲安全性的前提下保持应用的处理效率。很多设计人员正在研究如何通过RISC-V的开放式指令集架构（ISA）设计安全引擎，一种从源头开始就被保护的安全引擎。

在主CPU管理并发执行多个进程的主要工作负载时，这些安全引擎充当协处理器。然而，设计人员意识到这其中许多应用都需要安全硅IP来隔离不同应用之间的安全资产。

如果一个SoC上运行多个需要访问安全资产的应用程序，那么这些应用程序最好不能访问彼此的资产。举个例子，人们肯定不希望他们的银行应用程序能够访问他们的DRM视频回放密钥，反之亦然。这样做的另一个好处在于，一个应用程序中的安全漏洞无法泄漏另一个应用程序使用的安全资产。

要满足这些需求，安全处理器（如Rambus的CryptoManager Root of Trust（CMRT））必须支持多个硬件信任根，这些信任根在安全硅IP自身中要被彼此隔离。简而言之，每个实体都有自己的虚拟信任根，无需信任其它实体即可执行安全功能。

信任根（RoT）为可信计算环境的安全性奠定了基础。为了支持多个根，安全硅IP必须能够识别当前根（即，每个根必须具有处理器已知的唯一标识符）。

一旦信任根被识别，安全硅IP就必须应用该根的特定策略。该策略通过一组在硬件中强制执行的权限来实现。这些权限描述了根对加密处理器中可用的安全与非安全资产的访问能力。创建权限的原则为：给定根对资产的访问权限与其它根完全隔离。当然如果非常必要，也可以允许两个根访问同一组资产。

创建信任根

要创建信任根，安全硅IP应用开发人员需要创建包括公钥与私钥的密钥对。椭圆曲线加密（ECC）或RSA密钥对在这里是比较合适的选择。要计算出公钥的唯一加密值（称为散列摘要），并将此散列摘要用作根的唯一标识符。公钥的散列摘要必须安全地提供给安全硅IP的非易失性存储器（NVM）。而私钥则用于计算应用的二进制映像的数字签名，该二进制映像将在安全硅IP内执行。

在运行时，当应用程序加载到安全硅IP中时，签名、虚拟根公钥和其它元数据都附加在应用程序映像中。安全硅IP使用附加到映像的公钥来确定该公钥的散列摘要是否与存储在处理器NVM中的虚拟根ID匹配。如果找到匹配的ID，则使用公钥来验证应用本身的散列摘要签名。一旦验证了映像的签名，则安全处理器将应用的根权限应用于硬件。

请注意，创建应用程序的实体拥有私钥。安全硅IP永远看不到这个密钥，它由实体安全地保存，永远不会被暴露。

KDF在应用隔离中的作用

安全硅IP内部的硬件密钥导出函数（KDF）对于进一步隔离虚拟根不可或缺（图1）。KDF应当基于一个标准，例如美国国家标准与技术研究院（NIST）SP 800-108。KDF可以有多个用于导出密钥的输入。为实现根之间的隔离，唯一根标识符是KDF的其中一个输入。

图1：安全硅IP内部的密钥导出函数对于进一步隔离不同的虚拟根非常必要（来源：Rambus）

当应用程序加载到安全硅IP中时，根标识符被编程到KDF中。这意味着由两个不同的根私钥签名的两个不同的应用程序不会导出相同的密钥集，即使KDF的所有其它输入参数都相同也不可以。因此，在安全硅IP内执行的应用程序可以使用KDF来导出它自己唯一的应用程序对称密钥或ECC密钥对。

使用KDF导出应用程序密钥的另一个好处在于无需将密钥存储在NVM中，而存储在内存中的密钥通常易受攻击。当下一次应用程序需要使用特定密钥时，应用程序将执行与先前相同的密钥导出过程。

使用KDF还有一个优点是可以重复导出相同的对称密钥或ECC公钥和私钥对。它们通常通过动态加密法（on-the-fly）导出。一旦应用程序使用完密钥，密钥就被系统删除。

简而言之，两个不同的虚拟根不能创建相同的密钥，因为通过KDF能够导出的密钥使用了根标识符作为数据的一部分来导出。这就是应用程序之间实现加密隔离的方式。

其它资产的隔离

除了通过导出的密钥隔离，安全硅IP还可以进一步扩展给定虚拟根环境之下执行的应用程序的隔离。例如，应用程序通常不会共享NVM区域。另外，一般会希望限制对安全硅IP的通用输入和输出（GPIO）的访问。而应用给定虚拟根权限策略可以实现对此类资产的严格访问控制。

还有一些应用程序要求安全硅IP将导出的密钥或从NVM读出的密钥通过安全总线传送到外部处理单元。这个外部处理单元可能由于某些特定原因或出于对性能的考虑而被使用。此时必须设置虚拟根的权限，以便只有那些应该将密钥传递给外部处理单元的应用程序才能这样做。而其他不需要将密钥传递给外部处理单元的应用程序则不能访问安全总线。

保证安全硅IP内的所有应用程序都彼此隔离可以增加我们对系统安全性的信心。
拥有了如此安全保护伞，为安全硅IP开发应用程序的实体得以维护其特定的虚拟根私钥。其它实体无法访问这些导出的密钥、特定密钥总线、NVM内存地址范围、GPIO引脚或任何其它相关数据。同时也阻止了其他人尝试攻击或意外地导出这些关键数据。例如，开发人员的错误不会导致误访其他人的资产。这些资产受硬件保护。一旦在硬件中为基本密钥、NVM、安全密钥目标和其它关联资产设置权限后，应用程序就无法修改这些权限，因为它们被设置在硬件中，不能被重写。

提供对多个信任根支持的安全硅IP解决方案

在前面，我们已经讨论了系统和SoC设计人员如何在其应用程序中增加多个安全硅IP信任根并隔离它们以实现超安全性。

这种安全硅IP的解决方案是提供对多个RoT的支持，就像Rambus的CryptoManager Root of Trust。安全硅IP产品的每个根都可为安全硅IP内的多个RoT提供支持。安全硅IP内的每个根都有自己的标识符和权限集，用于建立对执行所需资产的访问权限。加载应用程序时，其请求的权限被编程到硬件寄存器中，使得该应用程序只能访问它指定的资产。根据硬件中应用的其它应用程序的权限，可以限制在安全硅IP内执行的其它应用程序访问原始应用程序的资产。

如果攻击者想要在安全硅IP上运行应用程序，则必须能够访问其虚拟根私钥。即使攻击者可以访问另一个应用程序的虚拟根私钥，他们的应用程序也无法访问原始应用的资产。

对于系统或SoC设计人员来说，要实现此功能就必须选择具有多个硬件RoT的安全硅IP，且每个RoT在安全硅IP内部都被隔离。这意味着每个实体都依赖于自己的虚拟RoT来执行安全功能，而无需信任其它虚拟RoT。

应用示例

以下是基于此类安全硅IP应用的一些具体示例。如图2所示，示例中的实体可以是数字版权管理（DRM）、银行业务或安全通信应用。

图2：应用程序实体可以是数字版权管理（DRM）、银行业务或安全通信应用。每个实体都完全相互隔离。 （来源：Rambus）

如上图所示，每个应用程序在彼此完全隔离的情况下执行。另一种不太安全的替代方案是所有三个实体共享同一组资产（下方框图）。

如前所述，系统和SoC设计人员需要考虑其设备支持的潜在客户应用程序。一些可能的应用包括视频流、银行业务和安全通信的DRM。每种应用程序对安全性和对安全硅IP资产的访问都有不同的要求。

DRM应用：DRM应用需要将安全硅IP导出的密钥输出到可以解密和解码视频流的外部引擎。在这种情况下，我们可以使用安全硅IP提供的权限模型来确保只有DRM应用程序可以导出解密视频流所需的密钥。此外，我们还可以根据安全硅IP的权限设置仅允许DRM应用程序将密钥传递给视频解码模块。

图3详细图解了安全硅IP在DRM应用中的使用。非易失性存储器（NVM）保存了多个应用程序基本密钥。根据DRM应用程序的虚拟根权限设置，它唯一可访问的密钥是DRM基本密钥KD，而无法访问其它被遮蔽的密钥（KB和KC）。

图3：安全硅IP用于DRM应用（来源：Rambus）

CPU上执行的应用程序请求KDF使用KD来导出视频解密密钥KV。该应用程序还要求将KV直接输出到密钥传输（Key Transport）模块，以防止DRM应用程序中潜在的软件漏洞泄漏KV。密钥传输模块通过安全总线将KV传送到视频解密和解码模块，该模块随之对需要播放给用户的视频流进行解密和解码。

银行凭证应用：图4详细说明了安全硅IP的第二种应用可能——保护用户的银行凭证。与上述DRM应用程序一样，银行应用程序也仅具有NVM中基本密钥KB的唯一访问权限，同样无法访问NVM中的其它基本密钥。

图4：安全硅IP用于用户银行凭证（来源：Rambus）

应用程序可以请求KDF使用KB来导出解密密钥KA。KA被直接发送到高级加密标准（AES）引擎，这样CPU就不会读取其值。应用程序随后请求AES引擎解密存储在系统外部文件系统中的加密银行凭证。一旦凭证被解密，它们就被传送到安全硅IP的SRAM，以供在主CPU上执行的银行应用程序使用。

即使攻击者意图对安全硅IP内执行的银行应用程序执行反向工程，也无法获取银行凭证解密密钥KA。而且，如果攻击者可以访问另一个虚拟根私钥来签署他们自己的银行应用程序版本，该应用程序也无法导出合适的KA，其导出的密钥KA无法用于解密用户银行凭证。

安全通信应用：第三个示例为安全通信应用，如图5所示。安全通信应用程序在使用前需要进行一些设置。安全硅IP需要首先使用其安全通信基本密钥KC导出椭圆曲线加密（ECC）私钥KP，然后再使用KP导出相应的公钥KU。KU随后在证书签名请求过程中从设备导出。

图5：安全硅IP用于安全通信应用。 （来源：Rambus）

证书颁发机构（CA）根据证书签名请求生成由CA私钥签名的数字证书。该数字证书（CERT）随后被导入安全硅IP中，存储在NVM中只能由安全通信应用程序访问的位置。

在与另一方建立安全会话的初始阶段，安全通信应用程序从NVM中读取CERT。安全通信应用程序还会请求KDF使用KC重新导出私钥KP，并将KP传递给公钥引擎。随后，应用程序使用安全硅IP的散列引擎计算出安全通信参数的散列摘要，也将其传递给公钥引擎。

安全通信应用程序请求公钥引擎根据KP和安全通信参数的散列摘要生成数字签名，并放置在SRAM中，安全处理器CPU上执行的安全通信应用程序将可以访问它。最后，安全通信应用程序导出CERT、安全通信参数和数字签名，并发送到建立了安全信道的另一方。

随着安全通信协议的发展，安全硅IP被用于与另一方建立机密数据共享。安全硅IP的AES引擎（或其他对称加密算法）利用这些共享机密数据加密或解密来自/传递到另一方的数据块。

结论

应用程序保持最高级别的安全性至关重要。上文描述的示例演示了如何在应用程序之间建立完善的资产隔离。

此外，在这种保护机制之下，即使某个应用程序被攻击者执行了反向工程也没有什么价值，因为获取应用程序的虚拟根私钥才是关键。而且即使攻击者可以访问另一个应用程序的虚拟根私钥，也无法访问要攻击的应用程序资产。

本文为《电子工程专辑》10月刊杂志文章，版权所有，禁止转载。点击申请免费杂志订阅

责编：Yvonne Geng