1. 引言
可信执行环境（TEEs）在我们周围的设备中迅速崛起，从大规模基于云的解决方案到资源受限的嵌入式设备。随着ARM TrustZone-M的引入，硬件辅助的可信执行现在也支持物联网节点。TrustZone-M提供了安全关键操作和敏感数据生成外围设备的隔离执行。然而，TrustZone-M与所有其他TEEs一样，不提供监控设备可信区域操作的机制，并且物联网设备安全区域的软件可以访问整个安全和非安全软件栈。这对于市场上设备制造商和组件供应商的多样性至关重要，这会引发信任问题，特别是当第三方外围设备集成到TEE中时。被破坏的TEEs可能被用于工业间谍活动、通过系统后门的数据外泄和非法数据共享。在此，系统外围设备的资源访问行为必须与集成期间指定的预期使用一致至关重要。我们提出了TEE-Watchdog，一个轻量级框架，为TrustZone-M支持的低端物联网设备中的安全系统外围设备建立MPU保护。TEE-Watchdog确保阻止未经授权的外围设备访问，并根据清单文件记录运行在TEE中的应用程序的不当行为。我们定义了轻量级规范和结构，用简洁的二进制对象表示法（CBOR）列出关键系统外围设备的权限。我们使用Musca-A2测试芯片板实现并评估了TEE-Watchdog。我们的CPU时间和RAM使用微基准评估展示了TEE-Watchdog的实用性。使用TEE-Watchdog保护系统外围设备使外围设备访问的延迟增加了1.4%，在我们的测试板上为61微秒。我们的优化CBOR编码的清单文件模板也显示与标准文件格式（如JSON）相比，清单文件大小减少了40%。
2. 挑战
如果安全应用程序被破坏（由于未检测到的漏洞），检测这种破坏并部署补救措施将变得非常具有挑战性。有几个例子表明，在这种被破坏的TEEs中实施隐秘的rootkit [8, 9]。因此，设备用户相信设备安全区域中的软件没有bug，没有后门，也不会滥用特权访问来操纵或泄露数据，因为它们也可以访问网络栈。根本问题在于，在多供应商环境中，设备制造商必须确保供应商信任（即组件供应商彼此信任数据处理）和用户信任（即用户对设备制造商的信任，即使设备的各个组件来自不同的来源）。在供应商之间利益冲突的情况下，工业间谍活动和使用被破坏的安全区域进行非法文件共享是TEE启用系统可能被利用的一些潜在方式。需要一种解决方案来强制外围设备及其软件在集成期间按约定行为的需求尤为迫切。在包括智能手机、智能电视和智能车辆的常规物联网设备的情况下，组件供应商和供应商较少且知名。此外，底层架构和应用程序的安全性经过多年的研究和开发已成熟。另一方面，物联网设备供应商仍在迅速涌现，导致不受监管的物联网设备的传播。随着TrustZone-M（TZ-M）的引入，用于基于Cortex-M的设备（即低端物联网节点），硬件支持的TEE用于关键操作的隔离执行也可用于物联网世界。这使得可以将关键组件与系统操作分离，但上述问题现在同样适用于低端设备。因此，在没有明确定义信任锚的情况下将这些设备引入我们的环境中，威胁到我们的隐私和安全。这里提出的主要问题是运行在TrustZone-M启用设备安全区域中的软件缺乏对系统外围设备的细粒度访问。这引发了关于安装的外围设备预期使用方式及其实际使用方式的担忧。运行常规杀毒系统会增加安全区域的代码库，这是不切实际的，因此不建议使用这些方法。在本研究中，我们提出了TEE-Watchdog（如图1所示），一个将用户/供应商定义的策略（例如与外围设备关联的CBOR策略，如图1中的指纹传感器）映射到系统内存的框架，有效检测访问违规，并记录违规应用程序的行为，审计后有助于选择适当的补救措施。我们实现了一个安全管理器，包括一个策略转换器、一个策略执行模块和一个日志模块。我们引入了一种最优结构，用于清单文件中的访问策略、访问表和包含恶意行为分析所需信息的系统日志文件。TEE-Watchdog的优化设计实现了对安全故障处理程序和引导加载程序的最小修改。TEE-Watchdog根据策略使用内存保护单元（MPU）执行内存访问。TEE-Watchdog添加了系统结构，如清单文件、访问表和日志文件，以建立整个框架。结合这些机制，除了提供在TrustZone-M启用的物联网设备中对安全外围设备的运行时安全访问监控和行为记录机制外，我们确保以下内容：（i）对安全系统外围设备的细粒度访问控制，（ii）所提议的系统组件的不可变性，即安全管理器和访问表，以及（iii）日志文件的机密性和完整性。
3. 贡献
我们TEE-Watchdog论文的主要贡献如下：
(i) 一种保护机制，防止可信应用程序在基于TrustZone的物联网设备的TEE中未经授权、好奇地访问关键资源。
(ii) 我们提出了一种轻量级清单文件规范（CBOR格式），用于在TEE中运行的可信应用程序。
(iii) 我们提出了一种自动转换机制，将应用程序的访问策略转换为平台相关和防篡改的访问表。
(iv) 利用MPU，我们提供检测、阻止和记录TEE中策略违规的可疑应用程序的行为日志。
(v) 我们使用实际的物联网硬件（Musca-A评估板）实现和评估TEE-Watchdog，并展示其在ARM低功耗物联网设备中的物联网水表用例中的适用性。
本文其余部分结构如下：相关工作在第1节讨论。在第2节中，我们详细讨论了理解TEE-Watchdog所需的技术和背景。第3节描述了威胁模型。
紧接着第4节的TEE-Watchdog设计，第5节解释了实现细节。在第6节中，我们对实现进行性能评估和结果分析。第7节讨论了TEE-Watchdog的一个用例。第8节讨论了我们提出的设计的安全分析。第9节是本研究的结论。
4. 相关工作
在以下章节中，我们讨论了相关文献：可信执行环境（TEEs）、TEE被攻破的事件、基于策略的物联网外围设备访问以及物联网应用的沙箱化。
4.1 可信执行环境（TEEs）
可信执行环境提供了一个隔离的软件处理和执行环境，关键系统组件可以通过虚拟化或基于硬件的机制进行分离。许多方法存在以保护嵌入式系统、商用PC、云环境等中的代码和数据[5–7, 10–13]。Intel Software Guard Extensions [14]为商用PC和云环境提供了一个平台，建立名为enclaves的安全隔离域，以隔离应用程序执行。ARM TrustZone提供了将应用程序代码、系统资源和外围设备分为安全和正常世界的机制，其中关键操作在安全域执行，所有其他操作包括操作系统在正常域执行。随着ARM TrustZone-M的引入，资源受限的物联网设备也可以创建TEEs以隔离关键操作。在TrustZone-M引入之前，技术如[13, 15, 16]提供了基于其重要性的微控制器和物联网设备中不同级别代码隔离的高效方法。
4.2 TEE的破坏
TEE被引入是为了保护软件执行和关键数据的操作，它们的安全保证依赖于小型TCB和强隔离机制，但最近随着物联网领域的扩展，TEE利用事件的数量急剧增加。在过去十年中，TEE破坏事件的例子有Boomerang [17]、Armageddon [18]和对高通安全执行环境的攻击[19]。Boomerang是一类漏洞，由于TEE启用设备中可信和不可信域之间的语义差距而出现，允许普通世界的攻击者通过可信域控制普通世界的其他资源。在高通安全执行环境中，通信通道管理器被用于利用整数溢出漏洞写入安全内存。Armageddon展示了强大的跨核缓存攻击（如prime + probe、flush + reload和evict + reload）可以用于从普通世界监控安全域活动。所有这些漏洞都导致了安全域的妥协，其中可以安装隐秘的rootkit。由于现有基础设施中没有方法监控TEE启用设备的安全区域，识别安全域中的安全漏洞非常困难（如[20, 21]所示）。随着TrustZone-M对资源受限物联网设备的可用性，这些攻击同样适用于低端物联网设备。随着物联网网络在用户周围的扩展，数据滥用对隐私的威胁更大。因此，我们提出了一种机制，用于监控TEE启用物联网设备安全世界中的软件对数据生成外围设备的访问。
4.3 基于策略的物联网外围设备访问
物联网设备，如智能手机、平板电脑、可穿戴设备、智能家居助手（例如Google Home和Amazon Echo）和墙壁安装摄像头，配备了各种传感器，特别是摄像头和麦克风。在多供应商环境中，威胁更大，应用程序只能访问那些功能要求的外围设备变得至关重要。FlowFence [22]是一个系统，要求敏感数据的消费者声明他们的预期数据流模式，并在阻止所有其他未声明的流的同时强制执行这些模式。FlowFence专为具有几千兆字节运行内存的智能手机和物联网设备设计。类似地，Android应用程序有与其功能相关的清单文件，列出系统传感器、外围设备、资源等所需的权限。这些清单用于指定访问权限、数据流等[23]。支持TrustZone-M的物联网设备是高度资源受限的设备，只有几千字节的RAM。因此，在低端平台上实现这些解决方案变得不可行。在支持TrustZone-M的低端设备中，第三方应用程序在安全域中的不当行为同样可能[24, 25]。Ditio [4]旨在启用对现代移动和物联网设备（在普通世界中）的传感器活动的审计。它记录传感器活动日志，审计员可以稍后检查并检查是否符合给定的政策。它基于一种混合安全监控架构，利用了ARM的虚拟化硬件和TrustZone。然而，它不提供阻止未经授权访问或违反合规政策的机制，也不支持检测TrustZone启用设备安全世界中行为不当的传感器。
4.4 物联网应用的沙箱化
将软件模块彼此隔离，也称为代码沙箱化，是一种防止软件相互影响功能的方法。它用于防止一个软件中的故障影响另一个软件，防止应用程序之间的干扰，使应用程序能够按批准的行为运行等。ARMor [26]、ARMLock [27]和uSFI [28]是应用于普通操作世界的软件故障隔离机制，通过硬件和软件手段防止代码相互影响。我们提出的解决方案受TrustZone启用设备安全世界中沙箱化模块这一概念的影响。当安全软件变为活跃时，一部分内存映射外围设备对软件可见。这个子集通过利用MPU启用，并符合第4节中详细讨论的使用策略。据我们所知，我们提出的解决方案是第一次密切关注监控安全应用行为和基于清单文件中的策略自动阻止外围设备访问。我们提出的解决方案可以与前面讨论的任何代码隔离机制和支持TrustZone MPU样保护和处理内存管理故障的TEEs一起使用。
5. TEE-Watchdog中使用的技术
在本节中，我们讨论了TEE-Watchdog设计中使用的基本技术。
5.1 ARM TrustZone的基于MPU的保护
嵌入式系统和低端物联网设备有严格的能源预算。这些设备是电池供电的，通常设计为多年在同一电池上运行。因此，这些系统使用原始的访问控制器，如内存保护单元（MPUs），而不是集成完整的内存管理单元（MMUs），为物联网设备提供安全和可信的执行能力[29]。MPUs是处理器中存在的可编程模块，使系统开发人员能够将系统内存（闪存、RAM、ROM、MMIO）划分为多个区域，可以分配访问权限。MPU可以通过使用一系列32位内存映射寄存器的特权软件配置为支持8个或16个区域。ARMv8-M架构有8个可用的MPU区域[30]。区域属性和大小寄存器（RASR）用于定义MPU区域的区域大小和内存属性。Cortex-M23和Cortex-M33如果实现并启用TrustZone安全扩展，则可以拥有多达两个MPUs（一个用于安全世界，一个用于普通世界）。可以独立配置安全和非安全MPU，以不同数量的MPU区域保护与安全域相关的内存。基于MPU的访问控制允许通过设置（i）共享性，（ii）访问权限（读/写）和（iii）代码执行权限来管理区域。MPU_RBAR寄存器是一个32位内存映射寄存器，存储MPU保护区域的起始地址和访问权限（表1描述了寄存器的位）。对该区域的所有内存访问由MPU监督，包括处理器的指令获取和数据访问，当检测到访问违规时，可以触发故障异常。由于这些故障异常，处理器会填充内存管理故障状态寄存器（MMFSR）和内存管理故障地址寄存器（MMFAR）。
5.2 内存管理故障状态寄存器
在具有主扩展的ARMv8-M架构中，故障状态寄存器（xFSR）可用于允许故障处理程序识别故障异常的原因。每个故障都有一个相关的FSR。
当发生故障时，处理器会在进入故障处理程序之前将多个CPU寄存器推入堆栈。可以检查这些32位寄存器以进一步调试故障原因。对于由于对MPU保护区域的非法访问而触发的MemManage故障，可以访问MMFSR位以确定故障的性质和原因。MMFSR指示故障的原因。通过检查位0到7的值，我们可以找到导致故障的访问类型。例如，如果MMFSR的位0被设置，这表示尝试从没有执行权限的位置获取指令，如MPU配置所示。表2总结了MMFSR各位的功能。
5.3 内存管理故障地址寄存器
内存管理故障地址寄存器（MMFAR）在发生MemManage故障时也会被填充。它包含生成MemManage故障的位置地址。换句话说，该寄存器会更新为产生MemManage故障的位置地址，并可用于检索故障地址。仅当MMFSR的MMARVALID位被设置时，MMFAR地址才有效。
5.4 物联网中的清单文件
清单文件是关于物联网设备固件或应用程序的元数据集合，包括关于软件位置、支持的设备、与软件模块访问系统组件相关的访问策略以及保护清单的加密信息。清单文件通常是平台特定的，平台供应商向应用程序开发人员和供应商提供元数据文件应遵循的一组规则和指示。智能手机的Android清单包含应用程序需要访问的系统外围设备的访问权限（如图2(a)所示）。Android应用程序开发人员必须遵守基于XML的清单文件模板[31]。物联网固件具有相关的清单文件，必须确保在零接触物联网设备中进行安全的空中更新。Ubuntu还列出了基于JSON的清单（图2(b)）中第三方应用程序打包格式的规范[32]。Trusted Firmware-M (TF-M)，一个TrustZone-M的参考实现，正在为物联网设备开发[10]。图2©显示了与TF-M相关的清单文件示例，包含关于系统分区、其优先级、外围设备等的详细信息。
5.5 简洁二进制对象表示法
简洁二进制对象表示法（CBOR）是一种二进制序列化数据格式，互联网工程任务组（IETF）为物联网应用推荐[33]。它非常适合物联网环境，因为它有助于实现资源受限物联网设备的轻量级栈目标。CBOR的编码器和解码器是用小代码库实现的。其最小的代码占用和小消息大小使其即使对于只有几千字节RAM的最受限物联网设备也适用。我们使用CBOR实现清单文件（在第4.1节中讨论）。
6. 威胁模型/攻击模型
在我们的威胁模型中，我们定义并区分了三类攻击者。首先，一个可信供应商可能无意中在TEE中运行不安全的第三方代码/API；这可能是因为从一开始代码中就存在已知漏洞，或者随着时间的推移代码变得易受攻击。这允许任何攻击者（A1）利用已知漏洞。其次，供应商本身是半可信的，虽然诚实但好奇，能够访问安全世界中的其他应用程序数据（A2）。第三，现在大量物联网设备由未知和不可信的供应商制造，这些供应商也没有维护安全供应链的机制（https://blog.checkpoint.com/2017/03/10/preinstalled-malware-targeting-mobile-users/）；这些不可信的物联网供应商和/或个别组件供应商可能会恶意收集最终用户的关键数据（A3）。
我们的攻击模型基于一个主要假设，即在安全世界中运行的服务可以自主访问和控制整个系统资源（包括正常和安全）。因此，具有网络栈访问权限的服务可以通过互联网泄露另一服务的数据。此类攻击者的目标可能是由于制造商之间的利益冲突导致的数据泄漏（A2）。同样，其他攻击者，如A1和A3，可以利用其代码在TEE中的特权级别，访问结构和功能。我们还假设提出的结构和组件（如访问表和日志文件，在第3节中介绍）可以被修改，系统操作（如清单文件解析和行为记录）可以被安全软件中断以更改访问表中存储的MPU配置和MMIO区域权限。我们认为我们的系统运行在支持ARM TrustZone-M的资源受限物联网设备上。我们的安全保证基于TrustZone本身正确实施且没有引入任何故意缺陷和错误的假设。我们信任特权固件和安全引导加载程序。我们假设堆栈限制寄存器
适当地使用，以防止堆栈操作，并且非安全中断服务例程（ISRs）不能中断安全ISRs。此外，正确使用堆栈限制寄存器确保安全ISRs由特权软件处理。此外，我们假设安全软件中没有验证漏洞，这些漏洞可能导致特权提升到特权固件级别。
基于上述威胁模型和假设，我们设计了TEE-Watchdog，具有以下安全目标，这些目标将在安全分析部分（第6节）中详细分析：(i) 安全应用程序不能修改TEE-Watchdog组件和结构，即访问表、日志文件和清单文件（G1）；(ii) 普通世界的应用程序及其可信代码不能中断使TEE-Watchdog功能正常的关键系统进程（G2）；(iii) 防止恶意应用程序耗尽TEE-Watchdog资源，如日志文件（G3）。表3总结了这些识别出的目标。
7. Tee-Watchdog设计和架构
我们提出了TEE-Watchdog，一个用于TrustZone启用平台中安全软件的沙箱和行为日志记录机制。TEE-Watchdog的高级架构如图3所示，描绘了三个实体：物联网设备、物联网设备供应商和外部审计服务。我们将安全管理器引入安全内核中，作为特权安全软件的一部分。它是处理所有子模块的监督组件。应用程序/服务供应商提供的软件清单文件列出了关于软件、其子模块和所需系统外围设备访问的功能详细信息。软件可以是任何用户级应用程序或外围设备的固件。该清单文件在系统启动时由策略转换器转换为内存映射访问表，其中包含与每个软件相关的访问权限。允许的外围设备记录在访问表中，每个应用程序及其允许的外围设备集都列出。默认情况下，除了列出的系统外围设备外，其他设备不允许访问。
在启用TrustZone-M的物联网设备中，系统设计者可以将系统内存划分为安全世界和普通世界。这种划分通过在启动时使用实现定义属性单元（IDAU）和安全属性单元（SAU）配置内存映射来实现。MPU用于在系统内存和外围设备上实施运行时访问控制。MPU对所有内存访问实施访问控制，包括常规内存和设备的内存映射I/O（MMIO）。我们利用MPU限制安全软件对安全资源的访问。沙箱模块利用安全MPU对安全资源和外围设备实施基于MPU的保护。审计模块拦截软件对安全资源的非法访问所触发的MemManage故障，以在日志文件中记录应用程序和发生的违规行为。我们还提出了一个基于CBOR文件格式的应用程序清单文件模板。所提出的框架要求每个物联网应用程序都配备清单文件，以便受益于TEE-Watchdog的保护。在接下来的章节中，我们讨论TEE-Watchdog框架的系统结构和安全管理器的主要模块。
7.1 系统结构
在本节中，我们讨论TEE-Watchdog组件的规格、结构和放置，主要包括清单文件、访问表和日志文件。
7.1.1 应用程序清单文件
由于物联网设备在计算能力（即网络容量、处理能力、能耗和内存容量）方面具有多样性，清单文件应足够简洁，以便在最受限的环境中使用。我们设计的与安全软件相关的清单文件应轻量级且可互操作，因为所提出的框架针对资源受限的设备。我们基于CBOR提出这些规范。虽然它不易于人类阅读，但由于物联网设备通常在最少人为干预下部署和运行，这不构成问题。现成物联网设备中CBOR的可用性及其在低功耗设备上编码和运行的效率是选择它的有力理由[34]。我们识别了一些清单文件应具有的属性，以使TEE-Watchdog能够监控安全软件并记录恶意行为：(a) 用于跨平台和供应商全局识别应用程序的唯一标识符（UniqueID），(b) 列出其正常功能所需的外围设备，© 各外围设备的相应访问权限。可选属性包括系统内存需求和安全密钥，但不是必需的。应用程序标识符用于跨设备、平台和供应商监控应用程序行为，标识服务层对象和逻辑实体。这些标识符通常遵循标准格式，如IEEE 64位扩展唯一标识符（EUI-64）、统一资源标识符（URI）或统一资源定位器（URL）[35]。提出的清单文件中的唯一标识符用于全局识别安全软件。以下清单是根据提出的指南的清单文件示例。
以上JSON文件的CBOR编码如下所示。
TEE-Watchdog的清单文件应符合以下指南：
(i) 清单文件应包含一个全局唯一的应用程序标识符，UniqueID。
(ii) UniqueID应通过连接供应商的组织标识和供应商分配给应用程序的本地标识（供应商私下知道）来构建。
(iii) 使用标准如ISO/IEC 6523-1 [36]和IEEE管理的组织标识符、组织唯一标识符（OUI）和公司ID（CID）[37]，为组织和公司分配唯一标识符。OUI可以扩展以添加分配给应用程序的本地标识。我们建议使用EUI-64 [37]来全球识别应用软件，因为它们旨在用于需要全局唯一标识符的接口或实例的应用程序。
(iv) 以下是符合EUI-64的UniqueID的十六进制表示形式，由用连字符分隔的八位字节组成。
(v) “UniqueID”：“AD-4E-22-C5-61-FF-AF”。这个UniqueID是通过向IEEE管理的OUI或CID（例如，OUI-36和CID-24）添加附加位构建的。在上述示例中，前四个半（最显著）八位字节是OUI-36，剩余的十六进制值是供应商分配的唯一应用程序标识，用于构建EUI-64。
(i) 清单文件应包含一组策略，指定软件对每个安全系统外围设备所需的访问类型。清单文件中未提到的平台外围设备默认情况下不允许软件访问。
(ii) 清单文件的内容应是包含名称-值对的数组/映射，符合CBOR编码格式，例如。
(iii) “Temp-Sensor”：“RO”。
(iv) 清单文件中指定的外围设备名称应与物联网设备供应商列出的名称相同（通常在数据表或规范中），以在设备之间保持一致性。
(v) 系统外围设备的访问权限应为“RO”表示只读访问或“RW”表示读写访问。
表3：TEE-Watchdog的安全目标摘要。
图3：此图显示了TrustZone启用的物联网设备中TEE-Watchdog的高级架构和在安全世界中的过程。
- 物联网供应商提供签名的清单文件和包含物联网设备中每个安全外围设备访问要求的外围设备/传感器。2. TEE-Watchdog的安全管理器解析清单文件，并在系统启动时基于清单文件生成访问表。3. 当安全软件变为活跃时，安全管理器根据访问表中指定的权限配置安全外围设备。如果安全软件试图访问超出其访问权限的外围设备，TEE-Watchdog的安全管理器将获取所有有关访问违规的信息，并将事件记录在可信存储中的日志文件中。5. 日志文件可以发送给外部审计员或用于入侵检测系统的训练，或简单地报告不当行为的软件。
清单文件的属性考虑了不同类别物联网设备的内存可用性多样性，提出了最小化的尺寸。
7.1.2 访问表
访问表是所提出框架的一部分，在系统启动时生成。它列出了安装在设备上的安全软件，并存储了它们对系统外围设备的访问权限（如表4所示）。第7.2.2节描述了将清单文件转换为平台特定访问表的过程。
7.1.3 日志文件
日志文件是所提出机制中的另一个主要组件。它仅由安全管理器填充，并作为安全系统资源加密存储。包含行为违规信息的日志文件如表5所示。每个违规行为都附有：(i) 表示应用程序执行的非法访问类型的违规代码，(ii) 导致违规的应用程序的UniqueID，(iii) 被违规访问的外围设备，和(iv) 违规时正在访问的地址。
7.2 沙箱模块
安全管理器的沙箱模块负责验证清单文件，将其转换为访问表，并执行清单文件中的访问策略。它由子模块组成：验证器、策略转换器和策略执行模块。
7.2.1 清单文件验证
与软件相关的清单文件的生命周期，包括硬件、软件或固件的元数据，始于供应商在文件中指定关键属性。在我们提出的系统设计中，我们假设物联网组件供应商会将清单文件与硬件一起提供给设备制造商。物联网设备制造商也可以制造自己的部件，在这种情况下，它也需要负责指定策略。清单文件中声明的传感器/外围设备的策略将作为资源公开。设备制造商负责集成各个组件并组装物联网设备。它还加载设备上的软件和清单文件。然后设备作为准备部署的解决方案发货给用户。物联网设备是(i) 硬件，(ii) 固件及其证书，(iii) 集成的外围设备及其软件驱动程序，以及(iv) 含有加密的唯一标识符和清单文件的哈希/证书的清单文件的组合包。设备配置文件是当前最先进物联网设备中的受信组件。它包含设备配置详细信息，并可以包括到安全固件和清单文件的路径。在设备部署期间，设备配置文件被配置，每个软件的清单文件被加载。在安全启动将控制转移到特权安全内核后，验证器开始加载每个清单文件以生成访问表。每个清单文件都会被哈希，并与预安装的合法清单文件哈希列表进行验证。一旦确定清单文件没有被修改或替换，策略转换器模块就会被调用。
7.2.2 策略转换器
我们的系统设计在系统启动过程中引入了一个策略转换器。在设备启动和系统更新时，安全管理器会检查是否有与安全应用程序相关的清单文件。在此步骤中创建了一个内存映射的访问表，其中包含安装的应用程序及其对所有安全系统外围设备的访问权限。给定系统外围设备列表和从清单文件中提取的访问策略列表，策略转换器生成一个访问表（如表4所示）并映射到MMIO。算法1表示了策略转换器执行的解释步骤。对于每个应用程序，策略转换器从提供的外围设备列表中识别外围设备，并将其地址输入访问表中。这些外围设备在访问表中被标记为允许访问，所有其他外围设备对特定软件都是不可访问的。
7.3 策略执行
如前所述，Cortex-M23和Cortex-M33最多有两个MPU。我们利用安全MPU保护安全世界中的系统资源，包括代码、数据、MMIO区域和其他系统结构。当普通世界的应用程序调用安全服务时，它将成为安全世界中当前的活动应用程序/服务。基于安全侧的这个活动服务，策略执行模块根据访问表配置整个安全内存空间（算法13，2）。如果访问表中的资源有针对特定服务列出的权限，策略执行模块使用MPU保护该资源，并为特定内存区域分配给定的权限。因此，安全服务只能根据访问表访问系统资源和外围设备。图4按步骤描述了策略执行的过程。安全MPU和访问表的完整性对于提出的系统架构至关重要。由于它们是位于安全内存中的系统资源，因此通过MPU保护来保证其完整性。这些结构的访问权限被配置为仅由特权安全软件（即我们的安全管理器）可编辑。
7.4 审计模块
我们提出了一个审计模块，作为我们安全管理器的一部分，负责监督安全软件对外围设备和资源的访问行为。
7.4.1 应用程序行为日志记录
审计模块仅在服务/应用程序超出其指定权限并试图访问超出允许列表的内存或外围设备时激活。在此之前，沙箱模块根据访问表配置权限，将安全内存划分为MPU保护的区域。在此类违规行为期间，尝试非法访问安全外围设备的服务将触发一个违规事件。
发生MemManage故障时，处理器会立即触发故障，将被访问资源的内存地址填入MMFAR，并在MMFSR中设置MMARVALID位，表示MMFAR包含有效的故障地址，并根据生成故障的访问类型在MMFSR中设置相应的位（0到7）。我们修改了MemManage故障处理程序以引入审计模块。审计模块在继续调查故障之前会检查LogFileExists标志。如果MMARVALID位被设置，审计模块从MMFAR读取地址（如图5所示），并将其与违规详细信息和应用程序的UniqueID一起输入日志文件（表5）。由于设备内存有限，日志文件可能存在过度填充的风险。日志文件在任何时候只能维护有限数量的违规记录。为了确保存储所有违规记录，审计模块在进行新条目之前会检查现有日志条目的数量。如果等于maxEntries，日志文件的现有条目会被移至外部审计服务进行进一步处理，新条目可以存储在设备上。安全管理器维护一个安全服务列表，并根据从普通世界或其他安全服务调用的服务设置或清除isActive标志。这确保了导致违规的活动应用程序与日志文件条目之间的链接。成功记录尝试后，控制流返回MemManage故障处理程序，并根据系统设置处理故障。算法3描述了处理日志文件条目的过程。
7.5 日志文件的可用性
日志文件存储在闪存中的MPU保护区域或硬件提供的受信存储中，以确保完整性。存储文件的MPU区域配置为仅允许我们的安全特权安全管理器访问或修改日志文件的内容。日志文件结构包含足够的访问违规信息，可以通过多种方式进行评估。它包含当前系统中违规实体的UniqueID，该ID如第4.1节所述是全局唯一的。日志文件旨在共享给外部实体进行进一步处理，UniqueID可以充分识别行为不当的应用程序和供应商。
日志文件可以通过多种方式处理，以确定对违反策略的软件的处理方法。服务/应用程序的不当行为是偏离最初商定的策略。一个合适的选项是在软件更新修复问题之前禁用设备上的服务。这种访问模式可能源于配置错误的策略，但也同样可能是供应商为了工业间谍活动而故意为之。如果多个物联网设备上的应用程序违规行为显示出一致的模式，这些违规行为的增加可以公开并反馈给供应商，迫使供应商修补问题。此外，这还允许没有TEE-Watchdog支持的物联网设备在安装应用程序之前识别此类应用程序和供应商。
更复杂的日志文件使用方法是将其作为威胁情报平台的一部分输入到入侵检测系统中。结构化信息标准促进组织（OASIS）的网络威胁情报技术委员会（CTI TC）提出了一些标准，旨在促进威胁信息的交换。结构化威胁信息表达（STIX）就是这样的标准之一，允许多种工具之间的自动信息交换【38】。STIX基于JSON，其对象表示指标、恶意软件及对象之间的关系。日志文件中的信息，如UniqueID和Violation Code，可以转换为STIX可理解的对象，表示一个指标或潜在的恶意软件。
8. 实现
TEE-Watchdog的设计基于ARMv8-M【10】，这是Cortex-M处理器的32位ARM架构。
8.1 运行时环境
TEE-Watchdog原型的实现构建在安全侧的Trusted Firmware-M（TF-M）上，普通世界的操作系统为CMSIS RTOS2（https://www.trustedfirmware.org/）。
每个系统外围设备的权限如清单文件所指定。在开始翻译清单文件之前，策略转换器模块会确认清单文件的真实性。我们使用TF-M加密服务提供的SHA-512来计算清单文件哈希列表。
8.2.2 访问表执行
我们提出方案中的策略执行模块使用在启动时由策略转换器生成的访问表。我们实现的策略执行模块利用Trusted Firmware-M中提供的mpu_armv8m_drv API来配置所有MMIO，并使用安全MPU。
符合访问表。mpu_armv8m_drv API使用MPU_BASE地址访问MPU进行配置。
8.2.3. 策略违规日志记录
我们实现了MemManage故障处理程序，以从MMFAR和MMFSR寄存器中检索有关内存访问违规的信息。我们使用tfm_sst_api将日志文件条目写入日志文件。日志文件存储在TFM-SST（用于存储敏感数据的TF-M服务）中。TF-M提供20KB的安全存储，数据使用AEAD加密（每次加密使用新nonce）和硬件唯一密钥（HUK）进行加密存储。
9. 评估
在本节中，我们对TEE-Watchdog原型的性能进行了严格评估。我们执行了一组微基准测试，针对作为安全外围设备的温度传感器访问应用程序。我们选择CPU时间作为性能指标，因为它与能耗直接相关。内存和能耗是低功耗物联网设备中最受限的资源。量化的CPU时间与TEE-Watchdog操作消耗的功率直接相关。我们还计算了一个简单的温度监控物联网应用的端到端延迟，并测量了由于TEE-Watchdog保护机制引起的延迟。我们将CBOR编码的策略与JSON文件格式进行比较，并突出显示文件大小的减少。我们还讨论了由于TEE-Watchdog服务对RAM可用性的最小影响，从而证明了所提出方案的轻量级性质。
9.1. 实验设置
我们在图6所示的ARM Musca-A2测试芯片板上评估了TEE-Watchdog的性能。Musca-A2板实现了ARM CoreLink SSE-200子系统，具有启用CPU0的双核Cortex-M33，频率为50 MHz。我们在这些实验中使用了启用TEE-Watchdog组件的TF-M和CMSIS RTOS v2。执行时间通过Musca-A2测试芯片板上的CoreSight调试端口测量。CoreSight调试端口包含一个32位自由运行计数器，计数CPU时钟周期。该计数器是调试、监视和跟踪（DWT）模块的一部分，我们用它来测量代码的执行时间。
9.2. CBOR与其他文件编码格式的比较
我们以CBOR和JSON格式实现了清单文件。表6中的比较清楚地显示了，使用CBOR表示相同数量的策略文件大小平均减少了40.81%。
9.3. 内存开销
Musca-A2物联网评估芯片可用256KB的RAM。TEE-Watchdog对系统RAM的运行时影响为1.79KB，仅减少了0.7%的RAM可用性。
9.4. TEE-Watchdog组件的性能评估
我们从两个方面评估系统。在评估的第一部分，我们分析了所提出解决方案的各个模块和机制。我们通过CPU时间来衡量TEE-Watchdog机制的执行时间，这使我们能够提供安全的外围设备保护和行为日志记录。
9.4.1. 基于清单文件填充访问表
在系统启动时，如第5节所述，应用程序关联的CBOR编码清单文件被解码，然后将策略解析到访问表中。在解析清单文件之前，我们的安全管理器会根据先前计算的一组哈希值验证清单文件的真实性。第4.2.1节详细描述了该过程。我们在包含多达8个策略的清单文件上执行评估，以估算此步骤对系统启动时间造成的最大延迟。表7显示了验证单个清单文件（取决于策略数量）的时间。解码清单文件并将其转换为平台相关的访问表增加了约298.34微秒的CPU时间（如表7所示）。我们发现，由于(i) 清单文件验证，(ii) 从CBOR解码，以及(iii) 转换为平台相关的访问表，系统启动时间的总开销为1312.96微秒，适用于包含2个策略的清单文件。考虑到嵌入式物联网设备的系统重启是罕见事件，并且不会影响设备的实时功能，我们认为这项开销是合理的。
9.4.2. 根据访问表设置TEE-Watchdog保护的CPU时间
当应用程序请求调用安全外围设备的安全服务时，控制切换到安全侧，TEE-Watchdog根据访问表配置所有安全外围设备。在此时刻，只有应用程序允许使用的外围设备可以访问。完成过程后，控制流重定向到普通世界，但在此之前，所有内存配置都会重置为默认配置。在我们的评估中，我们发现启用和禁用内存映射保护的时间分别为47.6微秒和13.7微秒，对于一个安全外围设备。图7(a)显示了根据系统中安全外围设备的数量启用和禁用TEE-Watchdog保护的执行时间。考虑到资源受限的物联网设备通常具有较少的外围设备，因为这些设备是为特定功能而构建的，为4个安全外围设备启用保护的156微秒延迟是最小的开销。这种开销对物联网应用程序的影响将在后续章节中讨论。
流量传感器驱动程序读取流量传感器，并请求加密服务对读取值进行加密，以便可以通过网络传输。
水表应用程序的主要功能是从安全水流量传感器读取数据，将原始数据值转换为有用的读数，并传输该读数。在本节中，我们讨论了TEE-Watchdog对水表应用程序执行的开销：(i) 对内存（RAM）的运行时开销，(ii) 由于启用保护机制导致的CPU时间延迟，和 (iii) 端到端延迟。端到端延迟是指从水表应用程序在普通世界请求安全水流量传感器开始，到控制返回普通世界时为止的完整计算周期。TEE-Watchdog消耗了总可用RAM的5.47%。每次切换到安全域时，TEE-Watchdog根据访问表保护传感器。这些保护的代价是执行时间延迟208微秒。这种上下文切换期间的轻微延迟对传感器访问的端到端延迟影响为156微秒，占5.6%。图7(b)详细展示了TEE-Watchdog对应用程序延迟的影响。在此用例中，156微秒的延迟不会显著影响诸如计费或用水量等实时操作。TEE-Watchdog保护生命周期中最耗时和能耗的操作是将非法行为记录到日志文件中。日志文件的完整性和机密性对设备的安全性至关重要，受信存储（TrustZone-M的SST）用于存储日志文件。TrustZone-M的SST是硬件保护的存储，其中数据经过加密存储。写入SST每字节数据耗时0.76毫秒，因此，写入一个日志文件条目需要50.16毫秒。
10. 安全分析
我们介绍了TEE-Watchdog，提出的框架用于限制对安全外围设备的访问并有效生成不当行为软件的记录。我们使用多种机制设计了TEE-Watchdog，例如基于MPU的保护、故障处理和CBOR解码和解析。在本节中，我们对提出的解决方案及其模块进行安全评估。我们考虑了在威胁模型（第3节）中讨论的攻击者A1、A2和A3，其主要目标是绕过TEE-Watchdog的保护机制，获取超出其权限的外围设备数据。这里的最终威胁是从物联网设备中窃取数据。
我们重新审视了TEE-Watchdog的每个安全目标：在我们的威胁模型中列出的G1、G2和G3，并讨论了TEE-Watchdog模块的潜在攻击面以及如何通过我们的设计选择进行缓解。
G1: 安全应用程序不能修改TEE-Watchdog组件和结构
(i) 物联网设备制造商（作为第3节定义的A2或A3类攻击者）可以将设备运送到物联网解决方案提供商，且TEE-Watchdog本身已被做出不必要的更改。我们的设计方法是，物联网解决方案提供商（被认为是可信的）应能够在部署物联网设备之前检查TEE-Watchdog的完整性。所提出的TEE-Watchdog实现了一个安全管理器，这是运行在安全世界中的标准操作系统中的特权软件。因此，可以通过计算并比较TEE-Watchdog二进制文件的哈希值与发布的良好哈希值（就像通常验证操作系统的完整性一样）来验证TEE-Watchdog的完整性。因此，物联网解决方案提供商可以轻松检测任何对TEE-Watchdog的恶意更改。
(ii) 访问表可以被TEE中的任何安全软件修改，以更改自身或其他进程的访问权限。TEE-Watchdog的设计使得访问表由安全管理器创建，这是特权安全软件。这使访问表成为特权内存区域的一部分，其他访问级别无法访问。
(iii) 日志文件条目可以被安全软件访问和读取，因为它是一个安全资源。为了保证日志文件的机密性，它被加密存储在安全存储（TFM-SST）中，使用安全管理器的应用程序ID加密存储。
日志文件条目可以被安全软件伪造，通过复制现有条目或创建新的虚假条目。TEE-Watchdog利用TF-M客户端ID管理系统和安全世界中的任务控制块（TCB）将日志文件条目与进行记录的软件关联。这有助于轻松识别日志文件条目是否由安全管理器之外的其他软件包创建。
(i) 恶意软件可以通过重复创建访问故障并耗尽日志文件的容量来覆盖日志文件条目。为了缓解这一问题，在创建新条目之前，安全管理器会检查日志文件中现有条目的数量与maxEntries是否一致；如果现有条目达到日志文件的容量，则将日志文件发送进行进一步处理。
(ii) 清单文件可以通过添加伪造的策略进行操纵，然后再将其转换为访问表。在转换之前，可以使用常规证书或供应商之间决定的签名管理方案验证清单文件的真实性。
G2: 普通世界的应用程序及其可信代码不能中断TEE-Watchdog操作和使其功能正常的进程
(i) 清单文件解析过程可能会被安全软件中断。TEE-Watchdog设计为在系统启动时作为安全启动过程的一部分解析编码的清单文件，不允许运行时解析新策略，从而缓解了此过程被中断的任何可能性。
G3: 防止恶意应用程序耗尽TEE-Watchdog资源
(i) 日志文件条目可能会耗尽资源受限设备上的有限存储空间。日志文件中的条目数量达到预定义限制后，日志文件会被上传到外部实体进行进一步处理或存储。这消除了意外或恶意覆盖日志文件的风险。
11. 结论
我们提出了TEE-Watchdog，以在由多个供应商提供的异构组件组成的物联网设备中建立信任。TEE-Watchdog是一种基于预定义的安全策略和权限来限制软件访问安全系统外围设备的机制。TEE-Watchdog引入了一个紧凑的CBOR编码清单文件模板，供设备供应商/制造商使用，以指定访问策略。TEE-Watchdog还实现了高效的行为日志记录。TEE-Watchdog利用ARM MPU创建内存限制，使用故障处理机制记录不当行为，并利用标准的CBOR编码和解码机制解析紧凑的CBOR编码清单文件。我们在支持TrustZone-M的物联网设备中实现了TEE-Watchdog，并评估了其执行开销和性能。我们的概念验证实现的微基准评估表明，TEE-Watchdog引入的额外操作与正常系统操作相当。由于TEE-Watchdog保护导致的外围设备访问延迟为1.4%。我们还强调了使用我们提出的CBOR编码模板与标准JSON文件格式相比的优势。清单文件大小减少40%，这是考虑到物联网设备受限特性而取得的边际收益。我们还通过ARM的水表用例展示了TEE-Watchdog框架的适用性。
参考：TEE-Watchdog: Mitigating Unauthorized Activities within Trusted Execution Environments in ARM-Based
