使用可信执行环境的分布式软件执行

移动设备以及相关的安全标准和协议已经存在多年。保护入站和出站通信以及保护存储在设备上的永久数据是常见的做法。满足这些要求的标准和技术定义明确，并已被广泛采用 - 例如，互联网工程任务组定义的标准，如互联网协议安全（IPsec）和传输层安全（TLS）或磁盘或闪存的持久性存储加密技术，如Windows的BitLocker和Linux的dm-crypt。然而，随着生活方式变得越来越数字化，智能设备已成为我们日常活动中不可分割的一部分，对安全性的需求显着增加。

随着技术的不断发展并启用了其他用例，越来越多的敏感资产正在进入设备，例如与商业和娱乐相关的凭据。这一发展增加了潜在黑客的圈子，并创建了更广泛的攻击媒介，试图利用现代嵌入式系统的漏洞。

最近一类突出的威胁是由Android等“丰富而开放”的操作系统（OS）的激增引起的。虽然 Android 有意的开放性（表现为代码和文档的可用性，以及内置的调试工具）导致了庞大的开发人员社区的突破性创新，但它是以创新攻击媒介为代价的。这些向量通常会导致一种状态，即黑帽已设法获得特权执行权限，并在运行时完全访问Android操作系统可用的所有资产。

以下讨论描述了缓解此威胁或至少限制受损资产范围并最大限度地降低富操作系统上此类控制损失的相关成本的流行方法。此方法基于敏感信息执行环境的硬件隔离，对于确保最终用户和服务的数据隐私至关重要，尤其是在视频点播、商业和银行服务的情况下。

值得注意的是，设备暴露不断增长的攻击面的现象并不局限于移动消费电子领域。过去被公正地归类为“封闭”的其他嵌入式系统，如汽车控制单元或工业系统，正变得容易受到类似类型的攻击。由于操作系统的开放性以及大量外部连接，这些设备中的主要代码执行实体不再安全。

隔离的执行环境

这种安全方法的关键是引入可信执行环境 （TEE），正如全局平台所称的那样。此环境与功能丰富、基于性能的丰富执行环境 （REE） 隔离。简而言之，TEE用于保护敏感的，基于软件的安全服务免受REE的影响。现代片上系统 （SoC） 通常基于以下硬件措施之一进行这种隔离：

主 SoC 处理器中的硬件分离执行模式：这种方法在 ARM 开发的信任区技术中显而易见，该技术可用于 Cortex-A 处理器系列的所有成员。请注意，在这种方法中，CPU 内核要么执行属于 TEE 的代码，要么执行 REE 代码（通常在两个域之间来回切换）。

物理上分离的处理实体（独立 CPU），专用于安全任务：这种方法更直观地理解，尽管不一定更好（一如既往，魔鬼 - 又名黑帽 - 在细节中），已经存在了更长的时间，并且仍然在许多设备中使用。请注意，在此方法中，专用安全 CPU 内核仅执行与 TEE 相关的代码。

这两种方法的比较与特定的实现细节紧密结合，正确的方法可能因系统而异。实现这种隔离的另一种方法是基于虚拟机管理程序或虚拟机监视器 （VMM），该方法目前在嵌入式空间中不太普遍。使用此方法，执行环境或虚拟机由以较高权限级别运行的软件层（虚拟机监控程序）分隔。假设虚拟机管理程序的实现是可靠的、经过数学验证的，这种基于软件的方法可能非常有效。

在此上下文中，一个有趣的术语相关区别与受信任的 EE 和安全 EE 之间的区别是平行的。术语“受信任”暗指使用模型背后的基本假设：放置在 TEE 中的代码被信任为非恶意且无 bug。TEE 中没有固有的任何东西可以防止格式错误的 TEE 代码向 TEE 的“围墙花园”以外的世界泄露敏感资产。这种信任意味着需要对放置在TEE中的代码进行详尽的审查和验证，特别是如果此代码为TEE中运行的多个不相关的安全服务提供服务。

三通实施

TEE通常提供称为安全操作系统的通用安全服务，其中包括处理安全启动，通信，持久数据存储，加密，安全平台管理等。此外，特定的受信任应用程序 （TA） 使用这些服务在 TEE 中运行。TA 通常是在 REE 中运行的更广泛范围的应用程序的组件，并与用户和操作系统的其他部分进行交互。

使用场景的一个例子是用户尝试使用高价值内容，例如通过订阅服务获得的高清视频。用户界面和多媒体框架接口在丰富的操作系统中执行，而数字版权管理 （DRM） 方案的某些部分（如使用策略实施、内容密钥提取和安全视频路径实施）则在 TEE 中由专用 TA 处理。这种分离是必需的，以符合 DRM 方案所有者在开放环境中发布的健壮性规则。

一次性使用方案可能涉及多个 TA。按照高清内容消费示例，用户可能希望使用Wi-Fi联盟的Miracast等标准将视频从手持设备发送到远程且可能更大的显示器。为了在开放系统上符合米拉卡斯特安全相关要求，米拉卡斯特软件堆栈必须位于 REE 上，与 TEE 中的 TA 通信，按照米拉卡斯特规范的要求实施高带宽数字内容保护 （HDCP） 2.x 规范。

必须特别注意将用例分解为受益于 REE 中执行的部分与强制移植到 TEE 中的部分（参见图 2）：

将过多的代码推送到 TEE 中可能会导致性能下降（吞吐量和功耗）以及潜在的安全问题。如前所述，对TEE代码的信任源于对放置在那里的内容的仔细审查，这是一项有利于最少代码的任务。

TEE中没有所需的所有部件可能会增加潜在安全漏洞的风险，从而导致更大的财务制裁可能性。大多数（如果不是全部）内容保护计划的被许可人承担数百万美元的责任。一个常见的误解是，只有与安全相关的协议的加密部分必须得到很好的保护，而将连接加密的逻辑留在TEE之外。事实上，调整“无害”的胶水逻辑完全规避了安全方案。

图 2：在基于 Android 的设备中，分解 TEE 和 REE 之间的内容保护使用方案，可以发现性能问题和安全问题。

当 TEE 中需要多个 TA 时，复杂性级别会显著上升。基本要求是这些TA之间的相互不信任（确保受感染的TA不会损害其他TA）。相互不信任通常由安全操作系统安全服务层处理。然而，在某些情况下，不同的TA必须安全地协作和交换信息，例如前面提到的采用DRM和HDCP链接保护的内容保护方案。

前方的道路

尽管具有相应的安全优势，但使用TEE和REE进行分布式嵌入式软件开发的任务并非微不足道，与传统开发相比，实际上阻碍了开发周期。作为一项相对较新的技术，这一发现并不令人惊讶。一旦设计团队更好地了解概念、相关工具和开发环境，这种现象可能会发生变化。如果服务提供商的要求要求，TEE使用率将加快。

服务提供商关注的一个问题是，由于设备及其安全功能的碎片化，其系统的可扩展性。没有人愿意重复重做应用程序。目前，全球平台标准组织正在解决这一问题。全球平台计划发布一个正式的TEE流程，需要由认可的实验室进行认证。

现代设备的开放性，以及新用例引入的扩展连接性，要求嵌入式空间具有更高级别的安全性。使用 REE 和基于硬件的 TEE 进行分布式软件执行有可能形成强大的安全解决方案，在不影响用户体验的情况下满足严格的要求。

与其他技术一样，采用的关键是通过标准化进行碎片整理，这是一个持续的过程，其中TEE的概念正在获得支持。请继续关注TEE嵌入式软件开发的更多进展。

审核编辑：郭婷