根隔离：显式安全性的关键

在某些安全处理器中，应用程序之间的隔离充其量是微不足道的。采用其他安全处理器路由可提供 SoC 设计器的显式安全性。

OEM 厂商越来越多地要求其下一代系统具有更高的安全性。反过来，系统和片上系统（SoC）设计人员也有责任保护敏感资产免受未经授权或恶意的访问。在大多数情况下，设计界选择硬件而不是软件方法来将安全性设计到他们的设计中。

如今，设计人员将看到各种安全处理器品牌。然而，它们中的大多数都遵循几乎相同的芯片架构。它的最佳特征是基本上有两个域，一个是非安全的，而另一个是安全的，用一个位将安全域与非安全域分开，图1。

图1a和图1b – 安全芯片架构的特点是具有两个域。一个是非安全的（图1b），而另一个是安全的（图1a），用一个位将安全域与非安全域分开。

此外，来自不同实体的不同应用程序（其中实体可能是 SoC 供应商、设备 OEM、服务提供商、最终用户或设备生态系统中的其他参与者）可能在同一安全域中运行。但是，它们彼此之间并不隔离，它们不仅可以访问自己的密钥，还可以访问来自其他应用程序的密钥。硬件分区不是在不同实体之间，而是在安全和非安全之间。

用于安全应用程序的沙盒

实际上，安全处理器使用一位为安全应用程序创建沙箱，如图1a所示。计算机安全术语中的“沙盒”是指一种软件或硬件结构，通过该结构创建单独的受限制环境，仅用于运行某些应用程序，通常对其操作具有一组特定的限制。

实际上，此沙盒适用于安全应用程序，可以说，每个安全应用程序都在同一沙盒中运行。运行安全应用程序的实体之间没有隔离。如果正在运行一个安全的应用程序，那么它与所有其他应用程序一起处于“安全”世界中。在这种情况下，问题之所以出现，是因为不同的实体在安全方面可能不完全信任对方。如果一个实体受到恶意攻击，则会危及所有其他实体的安全。

让我们以一个写得很差的数字版权管理 （DRM） 内容保护应用程序为例。它可能会损害在同一处理器上运行的支付应用程序的安全性，并允许访问银行信息。同样，这里的问题是应用程序之间缺乏隔离。一个写得不好或恶意的应用程序可能会危及在该处理器上运行的其他应用程序的安全性。

这是一个缺点。另一个问题是存在各种各样的攻击，攻击者可以在设计中更改信号的值。这些所谓的“故障攻击”或“毛刺攻击”是基于扰动电路以改变其操作。它们的范围从简单的电源和时钟毛刺到激光脉冲、电磁脉冲等。正确执行此类攻击可以更改位控制安全模式，使其在某些操作中从非安全模式切换到安全模式，从而允许不安全的应用程序访问敏感数据和密钥。

多域和隔离

另一方面，考虑具有多个域或多个信任根的安全处理器内核，如图 2 所示。在这种情况下，每个实体都有一个单独的安全域。这些安全域使用强大的硬件安全性彼此完全分离。密钥和硬件资源等安全资产是完全隔离的。

图 2 – 具有多个域或多个信任根的安全处理器内核。

在此安全处理器体系结构中，每个实体都有自己的一组签名应用程序。当安全处理器从一个应用程序切换到另一个应用程序时，所有上下文都将从安全处理器刷新。当该安全处理器从一个应用程序切换到另一个应用程序时，该安全处理器中不会保留任何数据、密钥或其他信息。唯一的例外是能够在不同的应用程序之间传递消息，如果应用程序编写者明确要求这样做的话。这可确保不同实体之间无法共享任何上下文。

因此，安全资产被完整而安全地分配给特定实体，因此默认情况下没有重叠，这意味着不允许不同的实体访问相同的资源。但是，如果正确进行分配，重叠是可以接受的。

假设有一个 SoC 供应商使用的测试和调试端口。它希望向其 OEM 客户提供相同的测试和调试端口。它们可能允许为 OEM 根目录设置与为 SoC 供应商的根设置的权限位相同的权限位，从而允许访问该特定测试和首次亮相资源。

相反，SoC 供应商可能有其他测试和调试端口，它希望保留这些端口，但不会使它们可用。因此，在如何进行这些分配方面具有完全的灵活性，并且很大程度上取决于SoC设计人员想要重叠的资源类型。其他安全功能不能重叠。以加密和解密密钥为例。每个实体都有一个单独的密钥空间或密钥集，它们不能彼此共享。

分配给每个根的键

在这种信任体系结构的多个根中，为每个根分配一组密钥。如上所述的一个操作是，它们使应用程序能够为每个根进行不同的签名。因此，每个根本质上都有自己的一组私有应用程序。当应用程序加载到安全处理器核心时，将标识根，然后硬件专门为该根配置自身。

此外，与根关联的密钥提供根使用的一组完整、隔离的派生密钥。因此，一个密钥可以变成许多密钥，而这些密钥可以用于相当数量的不同安全操作。但是每个根的每组密钥都是唯一的，并且一个根无法从另一个根访问密钥，这是硬件强制执行的。

一组权限也与每个根相关联。这些权限与安全处理器内核中的不同硬件资源（如调试和 I/O 引脚）相关。这些不同的资源可以在不同的根之间进行分区，同样是硬件强制执行的。一个根可能能够访问调试端口;另一个根目录可能没有或只能部分访问这些根目录。

一个根可能能够控制芯片上的某些外部逻辑。另一个根可能能够控制一组不同的外部逻辑，但可能与另一个根不同。在本例中，让我们再次使用我们的测试和调试示例。SoC 供应商有一个根，使其能够完全控制测试和调试逻辑，并完全控制该 SoC 其他方面的配置。

它可能会向购买其SoC的OEM授予部分功能，但不是全部功能。SoC 供应商可能不希望 OEM 能够访问所有测试和调试逻辑，因为 OEM 可能对供应商不想共享的 SoC 技术了解得太多。它可能允许 OEM 配置 SoC 的某些部分，但不是全部。

从一个实体到另一个实体的委派是根的另一个方面。与 SoC 供应商可以将某些权限委派给 OEM 一样，如果 SoC 供应商授予 OEM 某些权限，则 OEM 也可以将某些权限委派给服务提供商。但是，该委派的权限必须是 OEM 已具有的权限的子集。

此外，根据业务关系和系统要求，SoC 供应商可能会让 OEM 抹去 SoC 供应商的根源。这意味着 SoC 供应商将无法再在 OEM 的设备上运行软件。

根隔离对即将到来的 SoC 设计至关重要

如今，对于绘图板上的几乎每个设备和系统，安全性都变得越来越重要。但是，设计人员必须记住，安全性有不同的用途，不同的实体需要安全功能。

例如，芯片制造商需要安全的功能来制造和测试其芯片产品。他们的OEM客户也需要其特定应用的安全性。服务提供商和其他人可能还需要安全功能。因此，SoC设计人员需要提供可由这些不同实体在芯片的整个生命周期中使用的安全性。但是，他们希望在不损害自身安全的情况下实现这一目标。

正如我们在这里所说，这个想法是在应用程序之间保持隔离。一个写得不好或恶意的应用程序可能会危及该 SoC 中所有其他应用程序的安全性。底线是避免每个应用程序容易受到恶意攻击，同时在该 SoC 上运行的所有应用程序之间保持完全信任。

审核编辑：郭婷