TrustZone

TrustZone技术

让我们从最重要的问题开始:为什么存在TrustZone技术,它防御什么?保护用 C 和 C++ 编写的大型程序免受黑客攻击可能是一个挑战。内存损坏漏洞是一个常见问题,尽管消除它们是安全工程师的核心目标,但从操作系统内核等大型应用程序中完全消除它们一直被证明是难以捉摸的。

对于普通应用程序,此问题的一个解决方案是将大型程序隔离在“沙箱”中,然后通过沙盒“代理”限制该程序与系统其余部分之间的所有交互。然后,发现并利用此大型程序中的漏洞的攻击者只能通过代理与系统交互。由于代理进程可以比应用程序的其余部分小得多,因此保护其代码免受损害是一项更易于处理的任务。

现代操作系统内核也很大,并且在避免内存损坏漏洞时存在类似的问题。隔离这些内核比普通程序要复杂得多。为此,设备开发人员可以使用“受信任的执行环境”(TEE)。这些 TEE 将关键代码和数据与主操作系统隔离开来,因此即使主操作系统遭到入侵,驻留在 TEE 中的数据和代码仍保持隔离。TEE 的用例包括验证操作系统本身的完整性、管理用户凭据(例如通过指纹传感器)以及存储设备加密密钥的存储和管理。高价值资产不限于内核模式组件。视频数字版权管理 (DRM) 应用程序、银行应用程序和安全信使可能还希望保护其代码和数据免受可能安装了恶意软件的设备的影响。

ARM TrustZone 简介

即使操作系统内核受到威胁,也要保持数据安全需要特殊的硬件支持。在 Arm 上运行的设备(如智能手机)可以使用 TrustZone 执行硬件级隔离,以确保 TEE 的安全。Armv8-A 配置文件提供 TrustZone 扩展,可用于具有集成 V6 或更高版本 MMU 的 SoC。受信任区保护的代码和数据与恶意外围设备和非信任区代码隔离开来。它可用于构建功能齐全的可信执行环境 (TEE),包括运行在 S-EL1 上的 TEE 操作系统、与外围设备安全交互的可信驱动程序 (TD),甚至是在 S-EL0 上运行的可信应用程序 (TA)。TrustZone 还提供一个安全监视器,该监视器以 S-EL3 的最高权限级别运行,可在所有模式下完全访问设备。

TrustZone 的工作原理是引入一种新的“安全”模式,CPU 可以在该模式下运行。在这种新模式下运行时,CPU 可以访问设备的所有硬件和内存。在非信任区(“正常”)模式下运行时,只能访问外围设备的子集和特定范围的物理内存。TEE 可以利用此技术将自己的代码和数据放入此“安全内存”中,防止在“正常模式”下运行的任何代码访问或修改它,即使该代码在内核中运行。虽然内核无法访问 TEE 内存,但在 TEE 中运行的代码可以在正常世界中读取、修改和选择处理数据。
TrustZone_第1张图片
TrustZone 还扩展了 CPU 的标准“异常级别”权限模型。在 TrustZone 之前,存在三个级别:EL0(用户模式)、EL1(内核模式)和 EL2(虚拟机管理程序模式)。TrustZone 添加了一个新的 EL3(安全监控模式),这是最高特权级别并控制整个系统。但 TrustZone 还允许 CPU 以较低的权限在安全模式下运行,从而允许在 TEE 本身内进行权限隔离。因此,CPU 也可以在 S-EL0(安全用户模式)和 S-EL1(安全内核模式)下运行。

S-EL3 操作安全监视器的代码,这是 CPU 的最高权限级别。安全监视器运行设备制造商提供的 Arm 可信固件 (ATF) 中的代码。此代码在丰富执行环境 (REE) 和 TEE 内核之间执行上下文切换,并通过安全监视器调用 (SMC) 处理程序为两者提供基本服务,REE 和 TEE 操作系统可以通过 SMC 指令请求该处理程序。

S-EL1 运行受信任执行环境的操作系统的代码。根据 TEE 实现,受信任的驱动程序也可以作为 S-EL1 运行。Secure World (SWd) 中不存在 EL2 等效项,因此无法在 SWd 内部的虚拟机管理程序中运行多个虚拟 TEE 操作系统。 已提议将 S-EL2 的支持包含在 Armv8.4-A 配置文件中。

S-EL0 运行非特权的“受信任的应用程序”(TA),在某些 TEE 实现中甚至运行 TEE 中的受信任驱动程序 (TD)。默认情况下,除非 TEE 操作系统明确允许,否则 TA 不能在其他 TA 的上下文中运行、直接与设备外围设备通信或与正常世界 (NWd) 或安全世界 (SWd) 中的其他进程交互。

正常世界和安全世界

在 TrustZone 体系结构中,每个逻辑处理器内核都像有两个不同的“虚拟内核”一样运行;一个在信任区内运行,另一个在信任区之外运行。“正常世界”(NWd)核心像以前一样运行传统的操作系统,并具有丰富的功能和正常的应用程序。在 TrustZone 术语中,这整个环境称为富执行环境 (REE)。相比之下,TrustZone 虚拟核心在“安全世界”(SWd) 中托管并运行可信执行环境 (TEE)。实际上,TrustZone 虚拟内核是通过在安全监视器内执行的快速上下文切换来实现的。

SCR 寄存器 在硬件级别,CPU 通过 CP15 中安全配置寄存器
(SCR) 的 NS 位确定它是在 SWd 还是 NWd 中运行。如果启用该位,则 CPU 在 NWd 中运行;否则,它将在 SWd 中运行。安全监视器确保此位不能由非安全程序写入,以保持 SWd 的完整性。

通过系统总线进行受保护的外设访问 CPU 还可以将内存页标记为受信任区域保护(“安全”)或属于正常世界(“不安全”)。页表条目 (PTE) 的 NS 位(位 19)确定页面是属于安全环境 (SWd) 还是普通世界 (NWd)。此位确定在通过系统总线访问底层物理内存时是否设置 AxPROT[1] 安全位,从而允许受 TrustZone 保护的操作系统和进程访问同一地址空间中受信任区域保护的安全内存和 NWd 内存。当处理器在信任区模式之外运行时,内存访问始终忽略 NS 位;就像设置了 NS 位一样运行。

启用 TrustZone 的 AMBA3 AXI 总线结构中的硬件逻辑允许在总线传输期间将系统总线上的读取和写入标记为“安全”或“不安全”,从而防止 SWd 资源被 NWd 访问。当安全总线主站启动总线传输操作时,ARPROT[1] 或 AWPROT[1] 位确定传输应被视为安全事务还是非安全事务。此外,NS 位在硬件中设置得很高,可防止非安全总线主站访问安全总线从站(安全主站仍然可以发出安全传输)。

信任区保护内存

TZASC 为了严格限制受信任区域保护的代码和数据免受不受信任的代码和外围设备的侵害,信任区访问空间控制器 (TZASC) 硬件允许将物理内存的特定区域标记为“仅安全”。这些 TrustZone 域通过 TZASC 寄存器设置,这些寄存器由设备上的 Arm 可信固件 (ATF) 配置。更改访问表中的开始或结束地址是一项特权操作,必须谨慎执行;配置错误可能允许不受信任的内存访问信任区内正在使用的物理内存区域。

页表 与 NWd 一样,SWd 内核和程序可以有自己的地址空间,这些地址空间通过称为页表的稀疏查找表进行管理。这些页表使 MMU 能够在 CPU 使用的虚拟地址到其相应的物理页之间执行快速转换,并在访问内存时执行权限检查。

在 TrustZone 架构中,每个 CPU 都有两个虚拟 MMU(一个管理 SWd 地址空间,另一个管理 NWd 地址空间),每个虚拟 MMU 都有自己对应的 TTBRx 寄存器。这意味着两个世界的操作系统都可以独立创建和管理自己的一组虚拟页表,供它们自己和各自的进程使用。

非安全内存信任区页表可以将特定虚拟地址标记为“不安全”。这是通过在相应的虚拟地址页表条目 (PTE) 中设置 NS 位来完成的。SWd 代码可以使用它来将 NWd 内存的视图映射到其自己的(或 TA)地址空间中,该地址空间可用于监视或与 NWd 通信。在 NWd 中,PTE 中的 NS 标志将被忽略;来自 NWd 的所有内存访问都被视为不安全。

安全启动

使用 TrustZone 的设备还可以利用一种称为 SecureBoot 的技术,在操作系统从磁盘加载时强制实施操作系统的完整性。这可确保在设备关闭电源时没有人篡改操作系统的代码。新式引导序列作为一系列阶段运行,每个阶段加载并验证下一个阶段的完整性。安全启动提供硬件信任根机制,允许设备ROM验证第一阶段。只要所有不同的启动阶段都正确加载并检查下一个后续阶段的签名,并且只要数字签名密钥保持安全,此启动链就可以让用户确信他们的设备已启动操作系统的未更改副本,即使他们让设备无人看管。

对于 Arm 可信固件,引导加载程序的顺序命名如下,每个阶段验证下一个阶段:

引导加载程序阶段 1 (BL1) AP 可信 ROM
引导加载程序阶段 2 (BL2) 可信引导固件
引导加载程序阶段 3-1 (BL3-1) EL3 运行时固件
引导加载程序阶段 3-2 (BL3-2) 安全 EL1 有效负载(可选)
引导加载程序阶段 3-3 (BL3-3) 不受信任的固件

可信的执行环境

TrustZone_第2张图片

TrustZone 是可用于构建“可信执行环境”(TEE) 的众多硬件功能之一,旨在提供代码和数据与操作系统其余部分的硬件和内存隔离。并非所有 TEE 都使用 TrustZone。例如,Apple的Secure Enclave和Intel的SGX使用非TrustZone硬件保护其代码和数据。

存在许多不同的主要 TEE,可以利用 Arm TrustZone 扩展:

NVidia’s Trusted Little Kernel for Tegra (TLK)
Qualcomm Trusted Execution Environment (QTEE)
The Open Portable Trusted Execution Environment (OP-TEE)
Huawei iTrustee, based on the HiSilicon platform
Trustonic Kinibi TEE-OS for the Trustonic Secured Platform (TSP)
Samsung’s Teegris TEE
Sierra TEE
ProvenCore TEE
Trusty TEE for Android
TrustKernel T6

可信执行环境的演变 可信执行环境最初主要是作为提供安全启动功能的机制而开发的。从那时起,TEE 已经发展到提供一组更大的功能并向 NWd 公开服务。例如,支持各种功能,如安全指纹身份验证、加密服务、受保护的移动支付(如三星支付)、DRM、运行时完整性保护以及员工设备上受保护的企业服务,例如通过 TEE 的套接字 API 在移动设备和企业基础设施之间提供安全通信。现代 TEE 还可以通过受信任的用户界面保护设备上的敏感数据,该接口允许用户直接在 TEE 中输入 PIN 和密码,从而防止用户凭据对 REE 中运行的代码可见。此外,TEE 还可用于在设备丢失或被盗时保护敏感数据。例如,设备可以选择将解密密钥专门保留在 TEE 内以防止提取,并且可以设计设备解密系统,以便必须在 TEE 内验证密码猜测并限制速率。GlobalPlatform提出了在REE和TEE之间进行通信的API,并成为新标准。

TEE 依靠硬件来强制隔离。此硬件组件提供允许分离和初始化安全代码的基本基元。然后,TEE 软件在此硬件上运行,扩展这些基元以提供功能齐全的执行环境,支持安全启动、安全监视器和轻量级 TEE 操作系统等各种功能。TEE 通常还会为 REE 应用程序提供支持,以将其自己的代码和数据的关键部分隔离到隔离的受信任应用程序 (TA) 中。第三方助教不直接属于 TEE;它们由 TEE 操作系统在 TEE 内部执行。它是硬件隔离、安全启动和受信任的 TEE 操作系统的组合,共同构成了一个功能齐全的 TEE,可以在其上加载和运行 TA。

TEE 操作系统是正常世界 (NWd) 操作系统的安全世界 (SWd) 补充。它以比受信任的应用程序 (TA) 和受信任的驱动程序 (TD) 更高的权限级别运行。TEE OS 支持与 REE 的通信,提供核心服务和对 TA 的访问,并为受信任的驱动程序提供环境。TEE OS 处理从 EL3 调度的安全监视器呼叫 (SMC),并处理来自在 S-EL0 中运行的 TA 的主管呼叫 (SVC) 请求。

受信任的应用程序和受信任的驱动程序

普通 TA 受信任的应用程序 (TA) 在 S-EL0 上运行,使 NWd 应用程序能够提供特定于应用程序的功能,例如 DRM、受信任的 UI 以及机密和密钥的存储。TA 由 TEE OS 加载并计划执行,并与 NWd 应用程序、NWd 内核以及其他 TA 隔离。但是,给定的 TA 不与 TEE 操作系统隔离,并且必须隐式信任设备上可用的 TEE。TEE 操作系统的泄露必然会影响在 TEE 内运行的 TA 中的数据和代码的完整性和机密性。最初,设备仅允许设备上预装的 TA。但是,现代设备支持动态部署从 TA 应用商店下载的应用中包含的 TA。

系统 TA 是提供关键 TEE OS 服务(如安全存储、加密服务以及 TA 身份验证和解密)的 TA 子类。系统 TA 通常由 TEE OS 制造商或 OEM 提供。例如,华为拥有一个名为“GlobalTask”的特权系统TA,它实现了某些可信操作系统功能并控制普通TA的生命周期。

受信任的驱动程序包含访问安全外围设备(如指纹读取器)或在信任区内提供特权服务所需的代码。根据TEE的不同,可信驱动程序要么在S-EL0(例如Trustonic,Nvidia TEEs)中运行,要么直接加载到TEE OS内核的地址空间中并在S-EL1中运行(例如高通,华为,Linaro TEE)。受信任的驱动程序可以为 TA 提供其他服务,并可以访问比 TA 更多的功能。

安全世界与普通世界之间的通信

使用 TA 的应用(例如移动支付应用程序)需要一种机制来在 REE 中的 NWd 应用和 TEE 中的 TA 之间进行通信。为此,REE 中的应用会经历一个过程,通过 REE 和 TEE 可用的特定通信通道和 API 加载 TEE 内部的 TA 并与之通信。这些通信通道扩大了攻击面并引入了新的攻击媒介。未能验证通过这些通信接口从 REE 到达的输入可能会导致严重权限提升攻击。本系列的下一部分将向您介绍Kinibi TEE,并更详细地描述NWd和SWd之间的通信。

基于 SMC 的通信 TEE 中的受信任代码与 REE 中的代码之间的通信必须通过两种机制之一进行。第一种机制是使用 SMC 接口。在 EL1(或 EL2,如果使用虚拟机管理程序)运行的 REE 操作系统可以使用安全监视器调用 (SMC) 指令从 S-EL3 内部运行的安全监视器请求系统服务,然后将其中继到 TEE 操作系统。

特定于硬件的服务 除了提供服务以允许 EL0 应用程序加载 S-EL0 受信任的应用程序并与之通信外,TEE 通常还提供特定于硬件和特定于 TEE 的服务,这些服务可由 EL1 中的 NWd 操作系统代码直接使用。例如,TEE 可能会提供创建看门狗计时器的机制,以便在设备无响应时重新启动设备、与板载 SoC 交互或在 NWd 和 SWd 之间共享内存。 在 S-EL3 和 S-EL1 中运行的安全代码提供可以使用 SMC 指令请求的这些服务。此指令是特权指令,必须从 EL1 调用,并由安全监视器的 SMC 调度处理程序处理。

第二种通信方法是利用共享内存,即在NWd中运行的代码将一些物理内存映射到其地址空间,TEE中的代码将相同的物理内存地址映射到其自己的地址空间,注意将内存标记为“不安全”。然后,从任一世界写入此共享内存缓冲区的内存对两个进程都可见。共享内存是一种有效的通信形式,因为它允许在 TrustZone 之间快速传输大量数据,而无需切换上下文。

你可能感兴趣的:(TEE,网络,安全,TEE,arm开发)