基于TrustZone的开放环境中敏感应用防护方案

2017-11-07张英骏冯登国

计算机研究与发展 2017年10期

张英骏冯登国秦宇杨波

1(中国科学院软件研究所可信计算与信息保障实验室北京 100190) 2(计算机科学国家重点实验室(中国科学院软件研究所) 北京 100190) 3(中国科学院大学北京 100190) (zhangyingjun@tca．iscas．ac．cn)

2017-06-02；

2017-07-25

国家自然科学基金项目 (91118006,61402455,61602455) This work was supported by the National Natural Science Foundation of China (91118006, 61402455, 61602455).

基于TrustZone的开放环境中敏感应用防护方案

张英骏1,3冯登国1,2秦宇1杨波1

1(中国科学院软件研究所可信计算与信息保障实验室北京 100190)2(计算机科学国家重点实验室(中国科学院软件研究所) 北京 100190)3(中国科学院大学北京 100190) (zhangyingjun@tca．iscas．ac．cn)

针对BYOD(bring your own device)、移动云计算等兼具强安全性、高开放性需求的新型应用场景，提出了一种移动嵌入式平台敏感应用防护方案.为满足强安全性需求，方案基于ARM TrustZone硬件隔离技术构建可信执行环境，即使在整个操作系统内核被攻破的情况下仍能保证敏感应用的安全.为满足高开放性需求，方案实现了传统TrustZone安全方案不具备的两大优势.首先，将TrustZone保护域扩展至普通世界，安全世界不再实现具体的敏感应用，而只实现一个轻量级监控模块用以监控普通世界内核的行为.因此整个系统可信计算基不随敏感应用数量的增加而增大，减少了其可攻击面和潜在漏洞。其次，监控模块确保内核为这些敏感应用提供安全的系统服务，从而为满足开放性需求提供关键功能支持，例如提供标准系统调用接口、敏感应用动态部署和加载等. 最后，方案提出了内核主动证明机制，要求内核主动提供关键信息协助监控模块验证其自身行为，有效提高了系统运行效率.在真实设备上实现了原型系统，实验结果证明了该方案的安全性和较为理想的运行效率.

TrustZone；可信执行环境；敏感应用防护；内核监控；内核主动证明

随着移动嵌入式设备计算性能的提升， BYOD(bring your own device)、移动云计算等广泛使用智能化移动设备的新型信息化应用场景应运而生.一方面，这些场景承载了大量敏感计算任务和隐私数据，直接关系到企业、云用户的经济利益，具有很强的安全需求;另一方面，移动商用操作系统在为这些场景提供必要功能支撑的同时，也由于自身可信计算基(trusted computing base, TCB)过大引入了大量安全威胁.事实上，利用各种系统漏洞获取控制权进而威胁上层应用的现象在移动平台已经比较普遍[1-2].而传统安全工具无法为这些敏感应用提供足够的安全保障，原因在于它们同样部署在内核层并以系统内核可信为基础，因此与潜在内核攻击者具有相同特权等级，一旦内核被攻破，这些防护手段都会失效.

面对层出不穷的系统漏洞，可信执行环境(trusted execution environment, TEE)技术逐渐成为研究热点.TEE技术能够提供硬件隔离保障，即使整个内核被攻击者控制，TEE内部的敏感应用仍可安全运行.TrustZone[3]作为ARM架构特有的TEE实现技术，目前被主流移动嵌入式设备广泛支持.TrustZone将ARM片上系统资源划分为2个独立的执行域：普通世界和安全世界.其中安全世界拥有更高的执行权限，普通世界程序无法对其资源进行访问.因此，普通世界运行一般应用和商用操作系统(Android, Linux等)，而将敏感应用部署在安全世界，已经成为移动平台主流的TEE实现方式.基于这种方式实现的支付认证[4-5]、密码计算[6]等安全方案被学术界提出并被苹果、三星、华为等主流移动设备厂商采用.

尽管TrustZone在一定程度上解决了操作系统层的固有安全问题，上述方案仍存在2个主要问题：1)安全世界代码规模将随敏感应用的数量而增大，从而引入更多的可攻击面和潜在漏洞.目前利用安全世界漏洞对移动设备的攻击已经成为实际存在的安全威胁[7-10].因此，设备厂商通常只允许自身应用使用TrustZone资源，而不对第三方开放，这在很大程度上限制了TrustZone技术的推广.2)隔离使得正常操作系统服务无法被安全世界调用，敏感应用需要重新编写，既增加了代码开发和维护成本，也导致其能够实现的功能受限.例如由于缺少动态内存分配、文件系统服务的支持，敏感应用通常只能集成在系统镜像文件中并随系统启动一次性加载，无法动态部署.而在安全世界内集成这些服务会急剧增大系统TCB，引入已经在操作系统中存在的漏洞风险，这与TrustZone的设计初衷相违背.在BYOD、移动云计算场景下，第三方敏感应用和数据需要动态部署到其所有者(企业和云用户)不可控的设备上(员工手机和云主机)，既有很强的安全需求，又具备一定的开放性.而现有TrustZone方案无法在安全性、可用性和开放性方面达到平衡，并不适用于这些场景.

本文面向移动嵌入式平台提出了1种开放环境中的敏感应用防护方案，改变了传统TrustZone系统架构，将敏感应用移至普通世界.安全世界不再包含具体应用和系统服务，只包含少量启动代码及1个轻量级监控模块.因此系统TCB较小且不会随敏感应用的数量而增大.监控模块对普通世界系统底层行为进行拦截和监控，确保为敏感应用提供与安全世界等价的隔离保护，同时确保内核为它们提供安全的基础系统服务.因此，本方案既能为BYOD、移动云计算等场景提供强安全保障和必要系统功能支持，又不会由于这些应用和服务而增大系统TCB，从而在安全性、易用性和开放性方面达到理想平衡，为将TrustZone资源向第三方应用安全开放提供了基础.

1 相关工作

自TrustZone推出后，相关的标准化工作便一直致力于TrustZone技术的推广.全球平台组织(global platform, GP)推出GP TEE接口规范[11]，并致力于为TrustZone等TEE实现技术提供统一的编程接口[12].微软可信语言运行时系统[13]和诺基亚开放票据系统[14]通过在安全世界内部署通用编程语言解释器，实现特定语言编写的安全应用的高效开发和移植.Open TEE系统[15]提供开源TrustZone开发环境并集成GP TEE规范，降低了TEE应用的开发和测试成本.这些工作为TrustZone应用的开发部署提供了一定方便，却没有解决传统TrustZone架构的本质安全问题，即系统安全性会随安全应用数量的增加而下降，因此并没有得到有效推广.

Fig. 1 TrustZone basic architecture图1 TrustZone基本架构

另一方面，针对TrustZone安全世界的实际攻击事件促进了将TrustZone保护域扩展至普通世界的研究.三星完整性度量架构[16]提供普通世界内核运行时完整性保护，然而方案只关注内核防护，对承载用户隐私和敏感信息的上层应用没有提供保护，同时，方案由于频繁陷入安全世界进行内核监控导致较大的性能开销；文献[17]在三星完整性度量架构的基础上，在普通世界进程地址空间创建隔离保护域，方案确保不可信内核无法访问该域内的敏感数据，如与安全世界的通信密钥，却没有为敏感应用调用系统服务提供安全保障；高级内核攻击如Iago攻击[18]能够通过篡改系统调用返回值引发进程异常行为，在不直接访问该保护域的情况下导致敏感应用自身泄露域内隐私数据；文献[19]在普通世界进程空间创建与内核隔离的安全计算环境，方案在受保护进程挂起时将进程内存拷贝到安全世界，性能开销较大，也由于技术限制无法支持多核系统，同时仍需在其安全域内重新实现必需的系统服务，系统TCB没有有效减小.事实上，不支持使用现有操作系统功能极大限制了安全世界敏感应用的功能扩展，尤其是文件读写等复杂的系统服务.现有TrustZone方案依赖加密以提供基本的文件存储安全[4,13-14]，然而，如何为安全世界提供可信的文件系统组件以实现安全的动态文件读写通常被忽略.此外，这些方案要求受保护应用与安全世界显式交互，因此需要改变现有程序代码，增加了开发和维护成本.

文献[20-22]利用硬件虚拟化技术，在操作系统不可信的情况下为上层应用进程提供隔离保障，同时对内核进行监控，确保其为受保护进程提供安全的系统服务.这些方案在功能上满足BYOD、移动云计算等新型应用场景的需求，但是都依赖频繁的内存加密实现进程隔离，整个系统运行效率会受到较大影响.另外，硬件虚拟化本身不是为安全设计，而是为了实现多操作系统共享同一硬件平台，其产生的巨大计算和性能开销不适用于资源受限的移动终端设备.而考虑到低功耗ARM处理器在服务器端市场份额的提升以及虚拟化扩展在ARM处理器中并没有普及，这些方案也不适用于移动云服务器.文献[23]利用Intel最新的TEE实现技术SGX(software guard extension)为受保护应用提供隔离执行环境，并在其地址空间内链接1个类操作系统库以提供标准的系统功能支持.与TrustZone相比，SGX能提供更强的安全保障，原因是支持SGX扩展的CPU实现了硬件级别的内存加密保护，高效的硬件密码学支持可能会抵消本方案的性能优势.然而，在ARM架构下没有类似SGX的实现技术，因此这些方案也不适用于移动嵌入式平台.另外，运行在受保护进程内部的复杂系统库也引入了已经在操作系统内核中存在的类似漏洞威胁和可攻击面.

2 背景知识

2.1TrustZone安全技术

TrustZone安全技术自ARMv6版本开始引入ARM架构规范.通过处理器扩展将整个ARM片上系统资源划分为2个隔离执行区域：安全世界(secure world, SW)和普通世界(normal world, NW)，如图1所示.通过安全配置寄存器的NS比特位标识当前CPU的安全状态，确保安全的客体如内存、外设，不能被非安全的主体如CPU、外设访问.一种新的CPU执行模式、Monitor模式作为安全世界的一部分，负责2个世界的切换工作.普通世界特权模式通过调用新的处理器指令，smc指令进入Monitor模式.

2.2ARM架构相关

ARM是目前最常用的移动嵌入式设备处理器架构.其 CP15协处理器实现了主要的内存管理组件，包括虚拟内存管理单元(memory map unit，MMU)、Truszone扩展及安全相关功能.其页表基址寄存器(translate table base register, TTBR)指向系统页表基地址.ARM提供7种不同的处理器运行模式，其中用户模式属于非特权模式，用来运行应用进程.其他特权模式分别用来处理中断、系统调用或异常.特权模式的入口指令由异常向量基址寄存器(vector base address register, VBAR)决定.引入TrustZone支持后，2个世界拥有不同的TTBR和VBAR，虚拟内存映射和异常处理相互独立.安全世界可以将普通世界物理内存映射到自身页表对其进行读写操作.

2.3Linux相关

本方案使用Linux作为普通世界的通用操作系统，因此方案核心目标是基于TrustZone，针对不可信内核为上层Linux进程提供与安全世界等价的隔离和安全保障.本节给出一些Linux相关的背景知识.

ARM版Linux使用4 KB的页结构(page)作为基本物理内存单元.每个进程用户空间虚拟地址范围为0～3 GB，其布局由1个虚拟内存区结构体vm_area_struct的链表描述.匿名区域(如进程堆、栈)不关联任何后端文件，由匿名内存页组成.非匿名区域(文件映射区)关联1个特定文件，由该文件缓存页组成.内核根据进程mmap系统调用创建并维护其vm_area_struct结构.进程物理内存以按需调页的形式由内核动态分配.进程访问尚未分配物理页的虚拟地址时将产生缺页中断， Linux检索包含该错误地址的vm_area_struct结构，并由内存管理子系统分配1个空闲物理页.最后，错误处理代码更新进程页表，将该页映射到访问出错的虚拟地址并返回.

3 敌手模型和安全假设

方案完全移除了对普通世界操作系统内核的信任，并假设敌手可以利用各种系统漏洞实施内核攻击以窃取隐私数据或干扰代码执行，包括任意读写敏感应用进程内存、拦截或篡改外设(包括存储设备和用户交互设备)的输入输出数据、篡改敏感应用系统调用的返回值等.方案不解决程序自身漏洞，若敏感应用代码自己泄露隐私信息，方案无法提供保护.方案不保证系统服务可达性，内核可能拒绝为敏感应用提供服务或拒绝调度敏感应用执行，然而这些行为不会造成隐私泄露等实质性危害，而且会造成严重的用户体验问题而被用户感知.本文重点关注系统启动后的运行时保护，因此假设设备使用安全引导机制在系统启动阶段确保安全世界，操作系统内核镜像文件的完整性，保证系统初始状态的可信.

4 方案整体概述

方案的基本设计思路是将核心监控模块部署在TrustZone安全世界，同时在普通世界内核代码区插入smc指令，拦截系统底层事件，在其发生前转入安全世界进行安全检查，从而提供两大核心保障：1)为普通世界敏感应用进程提供与安全世界等价的强隔离保护；2)确保内核为敏感应用提供安全的系统服务.

4.1设计思路

为实现方案的核心安全目标，需首先解决一系列技术挑战：

1) 普通世界对自己的系统资源具有完全控制权，包括物理内存、页表和系统控制寄存器.内核可以通过修改自身页表来设置自己的虚拟内存映射属性从而读写普通世界任一物理内存区域，包括分配给敏感应用的进程内存，使得上述隔离难以实现.

2) 允许敏感应用与内核进行交互以调用系统服务会引发进一步的安全问题.高级内核攻击如Iago攻击[18]能够通过篡改系统调用返回值破坏进程地址空间布局完整性，如通过修改mmap返回的虚拟地址，使其指向其他隐私数据区或栈内存储的函数调用返回值.之后，应用进程对此次mmap申请的内存映射区的读写访问会导致隐私泄露或控制流劫持.此类攻击可以在不直接破坏上述基本隔离保护的情况下危害进程安全.

3) 准确并高效地对内核行为进行拦截和监控难以实现.商用操作系统功能繁多、语义复杂，使得其正常行为和恶意行为难以区分，例如某些正常系统功能也需要对进程内存进行访问，包括读取系统调用参数、写时拷贝、文件读写等.因此监控模块必须正确识别底层系统行为背后的高层语义.之前的系统监控工作[20-22]重点关注如何在不修改内核源代码的前提下实现拦截，监控效率较低.监控模块不仅需要自己推导内核行为的高层语义，还需要频繁的进程内存加密操作确保隔离，从而产生巨大的计算负担和性能开销，不适用于资源受限的移动设备.

Fig. 2 The whole architecture图2 整体架构图

本文方案解决了上述挑战.1)方案实现了不可绕过的虚拟内存控制，移除了普通世界内核对自身MMU资源的修改能力，包括页表和MMU相关的控制寄存器.因此，内核必须首先转入安全世界进行安全验证，再由安全世界完成这些修改操作，确保进程内存页不会被映射为内核可访问，从而为敏感应用提供基本隔离保护.2)方案系统性地定义了一系列与Iago原理类似的高级内核攻击，这些攻击能够在不破坏基本隔离的情况下危害进程安全且无法被现有工作防御.3)方案定义并实现了2类细粒度的进程安全属性、地址空间布局完整性保护和外设输入输出保护来阻止这些攻击，确保内核为敏感应用提供可信的系统服务.4)方案提出了内核主动证明机制，通过修改内核源代码的方式，强制内核主动提供关键信息协助监控模块验证其自身行为，简化了验证过程，同时避免了之前工作中依赖的进程内存加密操作，从而极大提高了系统运行效率.

4.2系统安全属性

方案提供3层安全属性，为敏感应用进程的整个生命周期提供保护.

1) 与安全世界等价的隔离保护，即普通世界内核无法访问敏感应用进程的内存和寄存器状态.

2) 细粒度的安全保障.首先是地址空间布局完整性保护，确保进程物理内存页根据进程的要求(mmap系统调用)映射到正确的虚拟地址.然后是外设输入输出保护，确保受保护进程与外设的输入输出数据不被内核访问或篡改.对于存储设备，方案也确保进程的文件操作(对文件映射区内存的读写)最终会到达正确的后端存储文件.这些属性能够在基本隔离的基础上提供进一步保护，包括抵抗Iago等高级内核攻击，确保程序代码、数据的正确加载，以及可信用户交互.

3) 基于以上安全保障，方案确保受保护进程能够通过标准系统调用接口安全地使用关键的系统基础服务，包括动态内存分配(mmap,malloc)、文件操作(read,write)、进程控制(fork,exec)等.

5 基于TrustZone的敏感应用防护方案设计

5.1整体架构

本方案整体架构图如图2所示.其中灰色部分为可信实体，白色部分为不可信实体.其中部署在普通世界的敏感应用与其他应用及操作系统内核隔离.每个敏感应用地址空间都链接1个安全C运行时库，该库对标准C库进行封装，同时负责系统调用参数适配，检查系统调用返回值以防止Iago攻击，从而为敏感应用安全使用标准C库和标准系统调用接口提供支持.方案仍使用内核现有物理内存管理子系统为敏感应用分配内存，然而，一旦某一物理页被分配给了受保护的敏感应用，安全世界为其提供针对普通世界内核的隔离保护.因此，安全世界同时为普通世界的页表内存提供隔离保护并拦截所有的页表更新事件，确保受保护进程内存不会被映射为内核可访问.

在普通世界内核代码区，某些关键的底层系统操作(页表更新等)被替换为包含smc指令的监控代码，确保其发生前先转入安全世界.在安全世界内部，内核监控模块根据监控代码的详细参数、预置的安全策略，以及用来记录普通世界系统状态的安全元数据对操作请求进行安全验证，并在验证通过后执行必要操作，如更新普通世界页表或更新安全元数据等.

5.2安全元数据

为了能准确并高效地认证内核的行为，安全世界需要记录普通世界的系统状态.例如，为实现基本隔离，安全世界需首先记录哪些物理内存页(由页物理基地址唯一标识)被用作页表，确保页表内存自身不被内核映射为可写，从而实现页表更新的拦截.此后，安全世界需要记录哪些物理内存页被分配给受保护进程，以便在页表更新请求中确保其不被映射为内核可访问.在内核不可信的前提下，安全世界无法依赖现有内核数据结构，必须维护自己的安全元数据.

具体来讲，安全世界维护s-page结构标识1个4 KB安全物理内存页，包括受保护进程内存以及页表内存.s-page的成员变量[oid,offset]指定页所属对象和偏移.对文件缓存页表示所属文件和文件内偏移，对进程匿名页和页表，这些成员表示所属进程和进程空间虚拟地址偏移.文件页有2种状态，保留状态和同步状态，指明该页内容是否已经与后端存储文件同步.安全世界使用s-vma结构标识1个进程虚拟内存映射区.其成员变量[address_range,oid,offset]指定该映射区域在进程地址空间的虚拟地址范围，所映射的对象和对象偏移量.对文件映射区，表示所映射的文件和文件内偏移.对匿名映射区，表示所属进程和虚拟地址偏移.s-vma为确保地址空间布局完整性提供了必要信息.最后，安全世界使用s-task结构标识1个受保护的敏感应用进程.

安全世界的s-page,s-vma,s-task结构可以看做是原有Linux内核数据结构(page,vm_area_struct和task_struct)的可信版本.然而，安全世界没有全盘复用这些结构，而只保留了安全相关的成员变量，因此元数据管理代码规模较小，不会显著增加系统TCB，内存管理、进程管理核心代码仍位于普通世界内核.

5.3监控代码接口

本方案为某些普通世界系统资源提供针对内核的隔离保护，包括页表、MMU控制寄存器、受保护进程内存等，所有管理这些资源的内核函数均被替换为包含smc指令的监控函数.接口定义如表1所示，替换位置和具体含义将在后续章节详细描述.本方案以修改内核源代码的方式插入监控指令，相对于动态二进制代码重写，优势在于能够对内核行为进行细粒度的控制.例如强制内核为安全世界提供额外信息以实现内核主动证明机制.尽管二进制重写更适合闭源系统，本方案是为移动设备厂商设计的系统级安全方案，而这些厂商通常都维护自己的系统内核源代码.

Table 1 Interface for the Monitor Code表1 监控函数接口定义

5.4MMU隔离保护

对敏感应用的隔离依赖基本的硬件虚拟内存管理(MMU)机制.然而，普通世界拥有对自身MMU资源的全部控制权，包括MMU控制寄存器和页表.内核可以通过修改自身页表访问任意普通世界内存，包括分配给敏感应用的安全内存.因此，方案必须移除内核对自身MMU资源的控制能力.MMU隔离保护是方案其他保护机制的基础，因为它确保内核无法改变普通世界虚拟内存布局及访问权限，所有MMU相关操作被强制转入安全世界进行验证，确保这些操作不违背敏感应用进程内存隔离等既定安全策略.

方案沿用本文之前工作[24]的思路实现普通世界MMU隔离，本节给出高层设计方案和本文的改进工作，详细实现细节可参考文献[24].

方案对MMU控制指令(如更新页表基址寄存器TTBR)和页表更新事件实现了不可绕过的拦截，确保内核既无法使用未经验证的页表，也无法修改现有页表，从而实现MMU隔离.通过将内核TTBR写指令替换为监控代码(表1中的TTBR_switch函数)实现对TTBR切换的拦截.对页表更新事件的拦截借鉴虚了拟化技术中影子页表的管理机制，强制所有包含页表的物理内存映射为只读.这要求安全世界纪录所有被用作页表的物理内存页.ARM-Linux采用二级页表格式，对一级页表的记录发生在TTBR切换事件中，安全世界记录保存在TTBR寄存器中的一级页表基地址，并确保其自身在当前页表中不存在可写映射，从而实现对一级页表更新的拦截.二级页表的记录发生在一级页表更新事件中，安全世界记录保存在待更新一级页表项中的二级页表基地址.最后，安全世界采用2类安全策略所有的拦截不可绕过.1)所有内核代码区内存只能被映射为只读，确保已有监控代码不被删除或插入新的TTBR写指令;2)所有记录的页表内存只能被映射为只读.安全世界从系统启动第1次写入TTBR激活MMU后，将在之后每次TTBR切换和页表更新拦截中对这些安全策略进行检查.

本文之前的工作[23]，采用对内核透明的方式实现对上述MMU相关事件的拦截.如将普通世界异常向量表替换为smc指令，使得写入只读页表产生的页错误通过异常向量表转入安全世界.然而，这种方式下，页错误将产生额外的CPU模式切换.同时由于缺乏足够的语义信息，安全世界需要自行区分页表更新操作与其他正常的页错误中断，如按需调页，写时拷贝，从而产生额外的性能开销.本文方案通过修改内核源代码，要求内核在需要更新页表时通过监控函数(表1中的set_pt)显式请求安全世界，避免了额外的CPU模式切换以及安全世界语义推导工作.尽管不可信内核可能伪造页表更新请求，由于安全世界通过s-page结构记录所有页表内存的状态，任何对页表的可写映射请求都会被拒绝.所有对页表的直接写操作都会产生页错误从而被安全世界检测并拒绝.

5.5敏感应用基本隔离保护

MMU隔离使得内核无法修改普通世界虚拟内存映射属性，确保方案所有基于虚拟内存映射机制的安全策略不被破坏.首先，方案提供内核代码完整性保护，确保所有插入内核的监控代码不会被恶意删除.由于内核代码位于固定的内存区域，安全世界只需要在页表更新中验证该区不存在可写映射.

5.5.1 可信上下文切换

敏感应用进程在运行过程中，可能由于系统调用或硬件中断被挂起而转入内核，此时内核可直接访问进程的寄存器状态或通过用户空间虚拟地址(0-3 GB)访问进程物理内存，从而窃取敏感信息.因此，在进程-内核模式切换的入口点，即异常向量表处插入监控代码(表1中的mode_switch)，确保受保护进程挂起时首先转入安全世界进行可信上下文切换.此时，安全世界将寄存器状态保存至当前进程s-task结构中，并在寄存器中写入噪声值.之后，安全世界激活1个特殊的影子页表，该页表用户空间范围的页表项全为空，从而确保内核无法通过用户空间虚拟地址访问进程内存，由于TTBR_switch监控函数代替了内核TTBR写指令，内核无法私自禁用影子页表.mode_switch监控函数同时被插入内核-进程的返回代码处，确保安全世界在受保护进程重新运行前恢复其寄存器值和原有页表.可信上下文切换的安全性基于内核代码完整性对TTBR_switch和mode_switch代码的保护，整个流程如图3所示:

Fig. 3 Trusted context switch图3 进程-内核可信上下文切换

5.5.2 物理内存隔离保护

可信上下文切换提供了进程虚拟内存隔离保护，确保内核无法通过用户空间范围的虚拟地址访问进程内存.然而，内核仍可将进程物理内存映射到内核地址空间进行访问.因此，安全世界必须记录所有内核分配给受保护进程的物理页，并在页表更新事件的拦截中确保这些页不被映射为内核可访问.因此，方案修改了内核页错误处理函数中的内存分配代码，每当内核为受保护进程分配页面时，必须显式通知安全世界(表1中的zero和file函数，分别用于声明匿名页和文件页)，安全世界将为其创建s-page结构并标记为受保护.之后，任何将已声明的安全页映射至内核空间的页表更新请求都会被拒绝.方案同时确保该策略的反向安全，如果1个页面在1次页表更新中被映射至内核空间，安全世界同样对其进行记录并标记为非安全页，任何将非安全页声明为安全页的请求都将被拒绝.

5.6敏感应用地址空间布局完整性保护

基本隔离保护确保了内核无法直接对受保护进程内存进行访问或篡改.然而，进程在运行过程中会与内核进行交互，如通过系统调用接口使用系统基础服务，使得不可信内核可以通过篡改系统调用返回值篡改进程地址空间布局，从而间接影响进程执行.本节列举2种无需直接读写进程内存的高级内核攻击，并给出相应防御策略.假设受保护进程用户空间有1个内存缓冲区，虚拟地址为VA,VB，包含物理页PA,PB.之后该进程通过mmap系统调用申请了1个新的内存区.正常情况下，2个区域的虚拟地址、物理地址应互不重叠，如图4(a)所示.

Fig. 4 Attacks to address space layout图4 地址空间布局攻击

图4(b)为映射覆盖攻击，通过篡改mmap系统调用返回的内存区虚拟地址，使其与已有区域重叠，该攻击是一种典型的Iago攻击.图4(c)为映射重定向攻击，将某一内存区虚拟地址映射至其他区的物理内存，该攻击并没有篡改虚拟地址布局，应用层无法察觉，因此比Iago更具隐蔽性.在这2种情况下，进程通过虚拟地址VC对物理页PC的读写都会被重定向到PB，显然破坏了数据完整性并可能导致隐私泄漏.若PB位于进程栈，则可能造成栈上保存的函数调用返回值被篡改，形成典型的控制流劫持攻击.

5.6.1 防御策略

地址空间布局攻击利用了进程默认信任内核，不对系统服务及返回值做校验的特点，从而不按照进程的要求进行内存映射操作.因此，安全世界必须实现与受保护进程的可信交互以建立统一的地址空间布局视角，协同认证内核的内存映射操作.方案利用s-vma结构实现可信交互.每次进程调用mmap申请新的内存映射区，安全C库在进程-安全世界共享内存区为其创建s-vma结构.mmap从内核返回后，安全C库对其返回值进行验证(返回值指定新建内存区的虚拟起始地址).为防止映射覆盖攻击，只需确认新建区的虚拟地址范围不与任何已有区域的范围(由其s-vma标识)重叠.若该验证通过，安全C库将新s-vma标记为有效并初始化其地址范围及映射对象.

由于保存s-vma的共享内存区位于受保护进程用户空间，内核无法篡改，从而无法对s-vma进行伪造.s-vma向安全世界提供了进程真实的内存映射请求，可协助其验证内核的页表更新操作，确保所有安全页都根据进程的要求映射到正确的虚拟地址，从而防止映射重定向攻击.以文件映射区为例，若收到页表更新请求(“将物理页P映射到虚拟地址V”)，安全世界首先搜索包含V的s-vma结构，若该s-vma指定的映射对象为安全文件F，即表示(“进程要求将文件F映射到包含V的内存区”).此时，安全世界需确保内核确实根据进程的要求映射了正确的物理页，因此检查P的s-page结构，验证其[oid,offset]成员是否也指定了文件F及正确的文件内偏移.若检测到不匹配，此次页表更新请求将被安全世界拒绝.

5.6.2 内核主动证明

尽管可行，上述方案要求每次页表更新检查对所有s-vma实例进行遍历搜索，性能开销极大.实际上，Linux页错误处理代码已有机制专门用于快速检索内存映射区结构，包括红黑树和最近出错区域缓存.因此，本方案采用内核主动证明机制，要求内核主动将其搜索结果随页表更新请求一起发送给安全世界，协助对s-vma结构的快速检索.交互流程如图5所示.

Fig. 5 Proactive attestation图5 内核主动证明

安全C库使用连续数组维护s-vma结构.当受保护进程通过mmap调用创建内存映射区时，C库在数组中搜索1个空闲的s-vma实例，并将其索引作为mmap参数传给内核.内核为新内存区创建自身的映射结构(vm_area_struct)并将其与该索引绑定.之后，进程访问该区域内某一虚拟地址V将产生缺页错误，内核页错误处理代码利用已有机制检索包含V的vm_area_struct，最后将绑定的s-vma索引及页表更新请求(P,V)发送给安全世界.

与原方案相比，安全世界可以通过内核传送的索引快速检索s-vma，无需再遍历全部s-vma实例或重复内核中已有的搜索操作.由于安全世界维护自身元数据，因此可以通过对比P的s-page与包含V的s-vma检测任何伪造的索引值和页表更新请求.

5.7存储设备输入输出保护

Fig. 6 File IO redirect attack图6 文件输入输出重定向攻击

进程地址空间布局完整性保护确保了安全内存页都根据进程的要求映射到了正确的位置.然而，对于文件映射区，其页内容来自于被内核完全控制的后端存储设备，不可信内核可能发起文件输入输出重定向攻击.如图6所示，该攻击从错误的存储设备区域加载了文件缓存页内容，但没有破坏进程地址空间布局.尽管磁盘加密提供对存储文件的隐私性，完整性保护，却无法在文件与其缓存页间提供可信数据路径.显然，将安全文件页内容写入其他文件将导致隐私泄漏.而将内容读入数据流导向旧版本文件，将完整性检查数据流导向新版本文件将导致回滚攻击，使得代码、数据无法正确加载.针对此类攻击，方案提供文件输入输出保护，确保进程的文件操作(对文件缓存页的读写)将全部导向正确的存储文件.

为提供上述保护，须首先禁止内核直接对存储设备进行控制.因此，安全世界将块存储设备的内存映射区视为特殊的安全页，确保内核无法直接对其读写.同时，将内核块设备驱动中的设备交互代码替换为安全世界监控函数(表1中的popl)，实现安全世界对内核文件读写操作的拦截和验证.

在介绍具体的验证策略之前，本节首先给出1个必要的安全假设：所有属于敏感应用的安全文件包括可执行程序、库文件、其他普通文件，都位于块存储设备的1个独立分区之中，与普通文件系统隔离.该假设提供了1个简单但有效的安全不变量，即所有安全文件均位于1个固定连续的存储区域内.在该假设下，安全世界能够轻易实现基本的文件隔离：所有非安全内存页与安全分区的数据交互请求都将被拒绝.然而，验证安全内存页与安全文件数据流向的正确性需要更多的工作.例如当收到内核的文件操作请求(“从安全分区的第10块将安全文件F的第4块的内容读入其文件缓存页”)，安全世界需验证F的第4块是否确实存储在安全分区的第10块中.这要求安全世界实现从文件逻辑块号lbn到设备物理块号pbn的可信转换.考虑到目前商用文件系统复杂的存储结构，这种转换将极大增加安全世界的代码规模.实际上，逻辑块-物理块转换已经被内核文件系统层实现，以完成正常的文件读写操作.因此，方案仍采用内核主动证明机制，要求内核将其转换结果与块设备读写请求一起发送给安全世界.方案采用Linux下最常用的第二代扩展文件系统(second extended filesystem, EXT2)构建安全分区.EXT2中索引节点inode结构用来存储单个文件的元数据，所有的inode结构都保存在位于分区固定位置的inode块中.对单个文件的每个块,都对应1个索引项来标识其物理块号.1种特殊的文件块，即索引块用来专门存储其他文件块的索引项.每个文件的第1～12个逻辑数据块和1～3级索引块的索引项存储在其inode结构中，如图7所示.为检索给定数据块的索引项，其逻辑块号需首先转换成位置向量，转换公式如图7所示.位置向量指定了该数据块的各级索引项在索引块中的偏移量.之后，安全世界需从inode开始，依次读取各级索引项，最终找到该块对应的物理块号.然而，如果安全世界已经知道了给定数据块的父索引块的物理块号，上述过程可以简化为只在父索引块中读取其自身索引项.

Fig. 7 EXT2 index structure图7 EXT2文件系统存储结构

安全世界使用s-block结构存储单个物理块的元数据信息，包括该块所属文件的inode号、逻辑块号及位置向量.在内核主动证明机制下，内核的文件块读请求可定义为[ino,lbn,epbn]分别指定了所读文件inode号、所读块的逻辑块号以及该块的父索引块的物理块号.由于inode块位于分区中固定位置，安全世界预先知道它们的物理块号，并在分区加载后即为其创建s-block结构.由于inode块可以看做其他文件块的祖先块，因此其s-block可作为读取后续子块的根证据.当收到对子块的读请求，安全世界根据epbn搜索父块的s-block结构，将内核提交的子块lbn转换成位置向量，并与s-block内的父块位置向量进行比对，若父块向量是子块向量的前缀，则验证了内核提交的epbn确实指向了待读子块的父索引块.之后，安全世界即可直接从父块中找到子块的物理块号，并向块存储设备发送读指令.读取完成后，安全世界为子块创建s-block结构并标记为已读.之后，该s-block结构即可用作验证后续子块读操作的证据，从而形成从inode块到最终数据块的可信证据链.

内核主动证明机制要求内核提交关键的ebpn参数指明待读块的父索引块，使得安全世界能够直接从父块中快速检索待读块的物理块号，而无需重复整个lbn-pbn转换过程.实际上，在内核正常文件读写过程中，提交块操作请求前已经完成了对父索引块物理块号epbn的查找，因此方案不会增加内核额外的工作量，只要求其将已有搜索结果发送给安全世界.

文件输入输出保护在安全文件及其文件缓存页间建立了可信数据路径，确保受保护进程能够与其文件进行安全交互，也确保了其代码，数据的正确加载.通过内核主动证明机制，安全世界能够对内核文件操作进行高效验证，而不需要重新实现复杂的文件系统组件.另外，由于整个过程的根证据，即inode块的物理块号被安全世界预知，因此由此构建的s-block元数据信息都是可信的，所有恶意的文件操作请求都会造成元数据检查的不匹配而被安全世界检测.

5.8用户设备输入输出保护

存储设备输入输出保护方案展示了如何在不可信内核设备驱动中构建从应用进程到外围设备的可信数据路径.对于用户输入输出设备，其通信协议，数据结构远比存储设备简单.因此，方案提供用户输入输出设备保护，确保受保护进程和用户之间的数据交互(如键盘输入的密码和显示给用户的交易信息等)不被内核拦截或篡改.

方案的设计主要基于用户交互设备驱动程序的2个特点：1)用户输入输出只会在进程空间的应用缓冲区，内核驱动中的临时缓冲区，以及设备的内存映射区之间传输，数据流向非常简单.2)驱动中对这些关键区域进行读写操作的代码所占比例很小，根据本文对键盘、声卡、串口驱动程序的分析，这些代码仅占全部驱动代码的1%～3%，主要包括：①缓冲区间的数据拷贝操作；②对输入输出数据的预处理，如内核终端(Teletype,tty)子系统中的线路规程组件；③底层设备数据和控制指令，即对设备内存映射区的读写.因此，安全世界将驱动临时缓冲区，设备内存映射区视为特殊的s-page，确保内核无法对其访问，从而无法直接拦截用户数据或直接控制用户设备.之后，将上述驱动代码移入安全世界，确保对用户数据的正常操作能够安全执行.由于移植代码所占比例很小，本方案不会显著增加安全世界代码规模.此外，为防止内核使用非法缓冲区以伪造用户输入输出，方案修改了驱动初始化代码，要求其将驱动缓冲区，设备映射区地址提交给安全世界，此后，任何使用其他未经认证缓冲区的操作请求都会被安全世界拒绝.对于受保护进程内的应用缓冲区，安全C库会在进程调用输入输出函数(例如printf,scanf)时记录其地址，安全世界会在缓冲区数据拷贝操作中检查内核提交的缓冲区地址与C库记录的是否一致，从而确保数据流向的正确性.

方案对用户设备驱动代码进行了细粒度的功能划分，在不显著增加安全世界代码规模的情况下，实现了可信用户输入输出机制.此外，由于方案仅将少量已有驱动代码移入安全世界，因此并没有增加整体工作量，系统整体性能并没有受到显著影响.

5.9安全系统调用接口

本节介绍的各种保护策略为敏感应用进程安全使用内核系统服务提供了基础.然而，某些正常的系统功能也需要对进程内存进行操作.1)某些内核功能需要对进程安全页进行处理，如匿名页的清零初始化、文件页的内容读取等.2)内核需要在系统调用处理时从用户空间获取系统调用参数，如根据指针参数读取进程内存中的参数内容.对于前者，这些操作已经被替换为表1中的监控函数，因此能够在安全世界内正常运行.对于后者，安全C库在系统调用转入内核前进行了参数适配，将指针等地址参数的所指内容拷贝到1个内核共享页中，并用页内地址替换指针参数，确保内核既能够正确获取参数内容，又无法通过指针访问进程空间的其他内存.

基于各种保护策略和参数适配，进程可以安全使用标准系统调用功能.首先，地址空间布局完整性保护提供了安全的内存映射，内存分配接口，包括mmap,malloc等.对于文件读写，方案将read,write接口实现为对文件映射区的mmap操作.对于进程控制，MMU隔离保护确保了通过fork创建的子进程页表是父进程的正确拷贝，对exec产生的新进程，方案确保其地址空间布局(即初始s-vma结构)包含正确的可执行文件和动态链接库映射.安全系统调用支持避免了在安全世界内重新实现核心系统服务，既减轻了代码开发和维护负担，也降低了整个系统TCB.

5.10性能增强

第5.6,5.7节详细阐述了如何利用内核主动证明机制有效简化系统监控过程，减少安全世界的单次执行时间，本节着重介绍2种减少世界切换次数主要技术手段:

1) 性能开销本地化.本方案系统监控产生的性能开销应尽可能限制在受保护应用内部，其他普通进程的运行尽可能不受影响.对于普通进程，其寄存器内容和内存地址空间不需要保护，所以当他们运行时，方案使用原始异常向量表，从而CPU模式切换事件不会触发安全世界监控.受保护进程运行前，安全世界将新的异常向量表基地址载入VBAR寄存器，确保模式切换能被安全世界拦截以提供隔离保护.对VBAR的保护采用与TTBR类似的方式，即内核中所有VBAR修改指令均被替换为smc，从而防止内核加载非法异常向量表.性能开销本地化机制减少了不必要的世界切换，有效降低了系统监控对普通应用的效率影响.

2) 监控事件延迟提交.对于只影响受保护进程执行的系统事件，如用户空间页表更新操作，都可以被延迟到受保护进程重新运行前提交给安全世界进行处理.因此系统事件监控修改为如下流程：每次需要向安全世界提交可以被延迟处理的系统操作，内核将该请求写入1个与安全世界的共享内存区，不再立即调用smc转入安全世界.每次安全世界执行时，首先检查共享内存区，依次处理所有延迟请求.由于每次受保护应用被调度运行前都会触发模式切换的mode_swtich监控事件，从而确保所有被延迟的请求能够被安全世界及时处理.延迟提交机制将部分监控事件并入了不可延迟提交事件中进行处理，从而有效减少了世界切换次数.

5.11方案总结

本节对方案的各种保护策略、系统整体运行流程进行总结.系统启动阶段可信引导机制确保了正确的系统镜像文件被加载，保证了系统初始状态的可信.因此，该阶段产生的第1条TTBR写指令能够正确被安全世界拦截，确保所有初始页表被映射为只读.从此时起，方案的MMU隔离保护机制将被激活.之后，基于MMU隔离的内核代码完整性保护确保了所有包含smc指令的内核监控代码不会被恶意删除.其中，sfork和sexec监控函数确保了安全世界能及时获知内核的进程创建事件.安全世界为每个受保护进程创建s-task结构并记录其页表基地址，作为该进程的唯一标识.由于所有进程切换的TTBR写指令都被拦截，因此安全世界知道当前运行的是哪一进程，能够正确记录内核分配给每一进程的物理内存，结合MMU隔离为进程提供基本隔离保护，确保内核无法访问受保护进程内存.在基本隔离的基础上，地址空间布局完整性保护、存储设备和用户设备输入输出保护提供了进一步安全保障，包括防御地址空间布局篡改攻击、程序代码、数据正确加载、安全文件读写、安全用户交互以及安全系统调用接口.

6 安全分析

第5节详细介绍了本方案的各种保护策略如何实现在第4节中定义的安全属性.本节将对其他5种不常见的攻击方法进行分析.

1) 内核控制流劫持.尽管方案提供内核代码完整性保护，利用内核漏洞实现控制流劫持攻击仍可在不改变现有内核代码的情况下形成恶意行为.首先，这些攻击无法删除已有监控代码，确保敏感操作发生前总能转入安全世界进行安全检查.其次，初始的安全元数据在系统启动阶段建立，可信引导机制将确保这些数据的可信性.后续的运行时安全数据将由安全世界根据内核正常行为模式创建并维护，因此这些攻击产生的系统异常将触发与元数据不匹配的监控事件，无法攻破安全世界对敏感应用进程的保护.例如内核攻击者可以通过控制流篡改绕过安全页的声明函数，并试图将非安全页映射至安全区域.在处理该页表更新请求时，安全世界由于检索不到该页对应的s-page结构(声明函数被绕过，安全世界没有得到通知)而拒绝该操作，从而阻止了非安全页被当成安全页使用而造成隐私泄露.

2) DMA攻击.攻击者挂接恶意DMA设备，绕过MMU保护直接访问安全物理内存区域，包括安全世界内存以及普通世界的受保护进程内存.首先，TrustZone硬件保护机制支持对外接设备进行安全划分，确保恶意DMA设备无法访问安全世界内存.其次，针对普通世界的受保护进程内存，若设备支持IOMMU(input output memory map unit)，类似页表更新，安全世界需对IOMMU页表更新操作进行拦截和监控，阻止恶意的DMA内存映射.对不支持IOMMU的设备，DMA操作将通过DMA控制器直接访问物理内存，页表的映射保护属性全部失效.因此，安全世界需将DMA控制寄存器的设备内存映射区视为特殊s-page，阻止内核直接对其读写，从而确保攻击者无法发起恶意的DMA请求.

3) 拒绝服务攻击.内核攻击者可发起拒绝服务攻击，如关闭自身系统服务，拒绝对受保护进程进行调度，或绕过所有的监控函数以完全屏蔽安全世界.首先，这些攻击会造成受保护进程无法运行，却无法攻破本方案的进程隔离保护，隔离域内隐私数据和代码执行不会受到影响.其次，这种攻击会产生严重的用户体验问题，能够轻易被用户识别并及时采取补救措施，实际攻击效果并不明显.

4) 用户代码提权攻击.尽管方案对已有内核代码提供运行时完整性保护，攻击者仍可利用系统漏洞劫持内核控制流，在特权模式下跳转到用户空间，从而在特权模式下执行包含恶意特权指令的用户代码，如篡改、删除监控函数，或修改TTBR指向非法页表.因此，安全世界需在页表更新操作中确保所有用户空间内存映射全部带有特权不可执行属性(privilege execution never, PXN)属性，从而将特权模式可以执行的代码限制在内核代码区.

5) 安全世界攻击.虽然漏洞利用是所有安全软件存在的普遍问题，本方案基于TrustZone硬件隔离机制实现，安全性远高于传统的内核层安全工具.另外，与传统TrustZone安全方案相比，本方案的安全世界组件不包含任何具体的应用和系统服务，交互接口简单，代码规模很小，被攻击的可能性要小很多，因此具有更高的安全性.

7 实现

在赛灵思Zynq-7000开发板上实现了原型系统.该设备支持TrustZone安全扩展，配置ARM Cortex-A9双核处理器.正常世界操作系统内核为Linux 2.6.38，安全世界只包含少量系统启动代码，普通世界内核监控模块及安全元数据管理模块.

由于需要被替换为安全世界监控函数的内核源代码规模较小且模式固定，方案仅修改了1 226行内核代码.具体来讲，方案替换了位于pgalloc.h, pgtable.h文件中的页表更新函数.文件读写相关的监控代码位于内核通用MMC卡驱动中，其底层设备交互代码(仅包含简单了设备映射内存读写指令)被移入安全世界.此外，方案使用UART(universal asynchronous receiver/transmitter)串口作为用户交互设备，并用PC端键盘连接UART作为用户输入，而UART输出将显示在PC显示器上.用户交互相关的监控代码位于内核通用UART驱动中.

安全世界使用预先分配的连续数组结构维护s-page和s-block元数据，并使用物理页号、物理块号作为索引.因此对其访问只需要常数时间，而不会随数组长度增加.在目前的实现中，s-page和s-block大小均为8 KB，分别代表4 KB内存页和1 KB磁盘块.本文实验所用开发板、内存容量1 GB、存储卡容量1 GB，其中256 MB分配给安全分区，因此，这2个数组所占内存空间仅为4 MB.对于内存和存储容量更大的商用移动设备，存储安全元数据所需内存空间会更大，但访问效率和管理代码的规模不会改变.

方案将安全C库、Linux系统库、需要保护的敏感应用程序放入安全分区中.这些文件应该使用代码检查、模糊测试等技术进行严格的安全验证，从而将漏洞风险降至最低.由于方案支持使用标准系统调用接口以及程序动态加载，敏感应用可直接运行，不需要重写代码或重新编译.方案在安全世界中预置了程序白名单，定义了所有需要保护的敏感应用.敏感应用的启动可以通过2种方式.首先，普通进程可以通过exec调用将自己初始化为受保护进程，这种方式用于用户在不可信命令行中首次运行敏感应用.其次，敏感程序可通过fork调用创建子进程.安全世界收到内核sexec进程创建请求时，若待创建程序位于白名单中，则为其创建s-task结构并标记为受保护.所有受保护进程通过fork创建的子进程都将被标记为受保护.尽管恶意应用也可以通过exec将自己伪装为敏感应用，然而，在exec调用返回后，地址空间布局完整性保护将确保原有地址空间被完全清除，并强制进程构建与敏感应用完全等价的新地址空间，恶意应用中的原有恶意代码将无法加载运行.

由于程序白名单定义了所有授权的受保护敏感应用，移动设备厂商应该对其谨慎配置和更新，并使用现有TrustZone版权管理或固件更新技术提供安全保障.尽管方案解决了TrustZone在安全性、开放性方面的冲突问题，如何将TrustZone资源向第三方开发者开放涉及商业合作问题，不在本文的研究范围内.

8 实验结果评估

8.1系统TCB

本方案中，安全世界组件主要包括内核监控模块、元数据管理模块和内核操作代理模块.监控模块只关注安全相关的内核底层行为，验证策略简单且固定.元数据采用简单数组结构存储，因此管理代码实现简单.代理模块代替内核执行某些关键操作，如页表更新、底层设备交互等，这些操作仅由一系列简单内存读写指令组成，代码开销较小.因此，安全世界只包含2 400行代码，系统TCB很小.不仅如此，与传统TrustZone方案相比，本方案最大的优势在于TCB不会随受保护敏感应用的数量而增大.

8.2安全性评估

方案的安全性主要包括4个方面，对页表的保护、对内核代码的保护、对敏感应用进程的保护以及对用户设备数据流的保护.

1) 采取方法尝试篡改页表:①利用系统/dev/mem接口直接修改页表内存;②编写恶意内核模块，调用set_pt监控函数请求安全世界修改页表，将页表自身映射为可写.实验结果表明:第1类攻击由于页表内存的只读映射而失败;第2类攻击由于安全世界对页表的只读保护策略而失败.由此证实页表隔离保护的安全性.

2) 采用方法尝试篡改内核代码:①利用系统/dev/mem接口直接修改内核代码区内存;②编写恶意内核模块，调用set_pt监控函数，请求安全世界在页表中将内核代码页映射为可写.实验结果表明:第1类攻击由于内核代码区的只读映射属性而失败，第2类攻击由于安全世界对内核代码的只读保护策略而失败.由此证实内核代码完整性保护的安全性.

3) 尝试破坏进程保护.首先编写受保护进程实例，该进程从配置文件加载安全密钥至固定内存区域，并使用其进行加密操作:①编写内核模块，使用kprobes内核调试框架拦截内核入口代码，使用密钥虚拟地址窃取密钥;②编写内核模块，使用LSM框架(Linux security module)拦截mmap系统调用，篡改其返回值实现映射覆盖攻击，使其指向密钥地址;③编写内核模块实现映射重定向攻击，调用set_pt监控函数，请求安全世界将保存密钥的物理内存映射至公开内存缓冲区;④编写内核模块，实现文件重定向攻击，调用popl监控函数，请求安全世界将密钥从配置文件加载至非安全页中.实验结果表明:第1类攻击由于影子页表机制的存在而失败;第2类攻击由于安全C库对系统调用返回值的检查而失败;第3类攻击由于方案的地址空间布局完整性保护机制而失败;第4类攻击由于方案的文件输入输出保护而失败.由此验证了方案对敏感应用进程的保护.

Fig. 8 LMBench Overhead Comparison图8 LMBench性能开销结果对比

4) 尝试破坏对用户设备数据流的保护.首先编写受保护进程实例.该进程接收用户键入的密码完成交易验证，并将交易信息显示给用户进行确认.之后编写恶意内核模块:1)定期读取内核通用tty层输入缓冲区以窃取密码;2)定期写入UART串口输出缓冲区，以伪造交易信息.实验结果表明:2类攻击均由于方案对用户设备输入输出缓冲区的保护而失败.

上述攻击多以内核模块的方式实现，由于在实际场景中，攻击者往往只能利用某些内核漏洞实现有限的控制，敌手能力一般不足以加载内核模块以执行任意内核恶意代码，从而进一步证实了方案的安全性.

8.3效率评估

8.3.1 系统效率

使用Linux的系统服务评分工具LMBench评估方案对整体系统性能的影响，所选测试用例主要涉及内存映射、文件读写以及进程创建.表2给出了本方案与原始Linux系统的评估结果以及本方案产生的额外开销.结果表明：空系统调用产生了最大的性能开销，代表了普通世界与安全世界的切换时间.世界切换的高延迟直接影响了其他系统调用的效率，因为安全世界会拦截所有的系统调用请求.然而，结果表明随着系统调用处理时间的增加，性能开销逐渐降低，说明世界切换与具体的系统调用处理相比时间较短且固定不变.

Table 2 LMBench Results表2 LMBench系统效率评估

图8给出了本方案与相关工作中提到的2个类似系统Inktag[21]和SecRet[17]的LMBench性能开销对比.Inktag提供了与本方案类似的安全属性.然而，由于其依赖的硬件虚拟化机制和频繁的内存加解密操作产生的巨大计算负担，性能开销远高于本方案.SecRet同样基于TrustZone技术，只实现了本方案的部分安全目标却产生了几乎相同的性能开销.原因在于SecRet由于不完善的保护而需要更多的安全检查，例如由于缺少文件输入输出保护，进程寄存器保护而必需对进程代码页和控制流做完整性检查.相比之下，本方案提供了完善的安全策略，并且使用了内核主动证明机制极大简化了安全世界的验证过程，有效提高了系统运行效率.

8.3.2 应用层效率

本节评估了方案对实际应用程序运行的效率影响.包括SPEC CPU 2006测试套件、轻量级Tomcat服务器以及自编写的磁盘加密程序.

选取SPEC CPU中的解压缩程序bzip2、智能围棋程序gobmk、序列搜索算法程序hmmer、视频编码程序h264ref四款应用，对其进行交叉编译，分别在原始Linux系统和本方案下运行，效率对比见表3所示.由于SPEC CPU主要用于测试CPU性能，这些程序以纯数学计算为主，几乎不需要与内核进行交互，因此性能开销几乎可以忽略，都在2%以内.

Table 3 SPEC CPU Performance Overhead表3 SPEC CPU应用效率开销

之后对Tomcat Web服务器进行性能评估.使用本文所用开发板自带的千兆以太网卡连接1个PC客户端.客户端运行Apache的Web服务器评估工具(Apache benchmark, AB)，该工具与开发板上的Tomcat创建50个并行连接，同时发送5 000个http请求.Tomcat代表了运行性能较为理想的一类应用程序，特点是只运行几个长期工作线程处理连接请求，不需要频繁的进程创建操作.如表4所示，相对于原始的Linux系统，本方案在响应延迟和网络吞吐量方面的开销仅为6%和5%.

Table 4 Tomcat Performance Overhead表4 Tomcat应用效率开销

最后使用Linux shell编写的磁盘加密脚本，该程序对系统安全分区进行遍历，对分区所有文件进行加密.加密引擎使用openSSL-0.9.8y.将openSSL分别在原始Linux系统，以及作为受保护应用在本方案下运行，并记录总加密时间.Linux脚本通过fork+exec调用外部程序，程序运行中产生了大量进程创建事件，此外，文件加密需要频繁与存储设备进行交互，大量内存映射、文件读写操作导致了频繁的安全世界切换.因此，本程序产生了最坏的性能评估结果，相对于原始Linux系统，总加密时间增加了约12%.

8.3.3 效率评估总结

尽管LMBench的评估结果表明方案对某些系统调用产生了一定的性能影响(如表2所示)，但方案对实际应用程序的性能影响远低于单个系统服务，原因在于实际应用会执行更多的自身计算任务来平摊这些性能开销.此外，由于方案需要转入安全世界进行内核监控，世界切换时间将直接影响系统效率.本文采用内核主动证明机制有效减少了安全世界软件的运行时间，而纯粹的世界切换时间取决于设备厂商如何实现TrustZone硬件及系统配置，如CPU缓存、TLB(translation lookaside buffer)缓存配置.这些影响因子不在本文研究范围之内.

9 总结

本文针对BYOD、移动云计算等兼具强安全性，高开放性需求的新型应用场景，提出了1种基于TrustZone的移动平台敏感应用防护方案.该方案实现了传统TrustZone方案不具备的两大优势.1)将需要保护的敏感应用部署在普通世界，安全世界不再实现具体应用，因此整个系统可信计算基不随敏感应用数量而增大，减少了其可攻击面和潜在漏洞.2)方案支持通过标准系统调用接口安全使用内核系统服务，既为敏感应用提供了必要功能支持又减少了代码维护负担.最后，方案提出内核主动证明机制，有效提高了系统运行效率.方案首次解决了TrustZone技术在安全性、易用性和开放性方面的冲突问题.

[1] Hexamob. Android rooting method: Motochopeer[EB/OL]. [2017-05-31]. http://www.hexamob.com/how-to-root/motochopper-method

[2] AndroidMTK. How to root my android device using vroot[EB/OL]. [2017-05-31]. http://www.androidxda.com/download-vroot

[3] ARM. Building a secure system using TrustZone[EB/OL]. [2017-05-31]. http://www.arm.com

[4] Marforio C, Karapanos N, Soriente C, et al. Smartphones as practical and secure location veri_cation tokens for payments[C] //Proc of the 22nd Network and Distributed Systems Security Symp (NDSS 2014). Reston, VA: ISOC, 2015

[5] Zhang Yingjun, Zhao Shijun, Qin Yu, et al. TrustTokenF: A generic security framework for mobile two-factor authentication using TrustZone[C] //Proc of the 14th Int Conf on Trust, Security and Privacy in Computing and Communications. Piscataway, NJ: IEEE, 2015: 41-48

[6] Zhao Shijun, Zhang Qianying, Qin Yu, et al. Providing root of trust for ARM TrustZone using On-Chip SRAM[C] //Proc of the 4th Int Workshop on Trustworthy Embedded Devices (TrustED 2014). New York: ACM, 2014: 25-36

[7] Keltner N. Here be dragons: Vulnerabilities in TrustZone[EB/OL]. [2017-05-31]. https://atredispartners.blogspot.com/2014/08/here-be-dragons-vulnerabilities-in.html

[8] Shen D. Attacking your trusted core, exploiting TrustZone on Android[EB/OL]. [2017-05-31]. http://docplayer.net/34134465-Attacking-your-trusted-core-exploiting-trustzone-on-android.html

[9] Laginimaineb. Bits, please[EB/OL]. [2017-05-31]. https://bits-please.blogspot.com

[10] Machiry A, Gustafson E, Spensky C, et al. BOOMERANG: Exploiting the semantic gap in trusted execution environments[C] //Proc of the 24th Network and Distributed Systems Security Symp (NDSS 2017). Reston, VA: ISOC, 2017

[11] GlobalPlatform. TEE Internal Core API Specification[EB/OL]. [2017-05-31]. https://www.globalplatform.org/specificationsdevice.asp

[12] Nyman T, Mcgillion B, Asokan N, et al. On making emerging trusted execution environments accessible to developers[C] //Proc of the 8th Int Conf on Trust & Trustworthy Computing. Berlin： Springer, 2015: 58-67

[13] Santos N, Raj H, Saroiu S, et al. Using arm Trustzone to build a trusted language runtime for mobile applications[C] //Proc of the 19th Int Conf on Architectural Support for Programming Languages and Operating Systems (ASPLOS 2014). New York: ACM, 2014: 67-80

[14] Kostiainen K, Ekberg J, Asokan N, et al. On-board credentials with open provisioning[C] //Proc of the 2009 Symp on Information, Computer and Communications Security (ASIA CCS 2009). New York: ACM, 2009: 104-115

[15] Mcgillion B, Dettenborn T, Nyman T, et al. Open-TEE-An open virtual trusted execution environment[C] //Proc of the 14th Int Conf on Trust, Security and Privacy in Computing and Communications. Piscataway, NJ: IEEE, 2015: 400-407

[16] Azab M, Peng N, Shah J, et al. Hypervision across worlds: Real-time kernel protection from the ARM TrustZone secure world[C] //Proc of the 21st Conf on Computer and Communications Security (CCS 2014). New York: ACM, 2014: 90-102

[17] Jang J, Kong S, Kim M, et al. SeCReT: Secure channel between Rich execution environment and trusted execution environment[C] //Proc of the 22nd Network and Distributed Systems Security Symp (NDSS 2015). Reston, VA: ISOC, 2015

[18] Checkoway S, Shacham H. Iago attacks: Why the system call API is a bad untrusted RPC interface[C] //Proc of the 18th Int Conf on Architectural Support for Programming Languages and Operating Systems (ASPLOS 2013). New York: ACM, 2013: 253-264

[19] Sun He, Sun Kun, Wang Yuewu, et al. TrustICE: Hardware-assisted isolated computing environments on mobile devices[C] //Proc of the 45th Annual IEEE/IFIP Int Conf on Dependable Systems and Networks (DSN 2015). Piscataway, NJ: IEEE, 2015: 367-378

[20] Chen X, Garfinkel T, Lewis E C, et al. Overshadow: A virtualization-based approach to retrofitting protection in commodity operating systems[C] //Proc of the 13th Int Conf on Architectural Support for Programming Languages and Operating Systems (ASPLOS 2008). New York: ACM, 2008: 2-13

[21] Hofmann O S, Kim S, Dunn A M, et al. InkTag: Secure applications on an untrusted operating system[C] //Proc of the 18th Int Conf on Architectural Support for Programming Languages and Operating Systems (ASPLOS 2013). New York: ACM, 2013: 265-278

[22] Yang J, Shin K G. Using hypervisor to provide data secrecy for user applications on a per-page basis[C] //Proc of the 2008 Int Conf on Virtual Execution Environments (VEE 2008). New York: ACM, 2008: 71-80

[23] Baumann A, Peinado M, Hunt G. Shielding applications from an untrusted cloud with Haven[J]. ACM Transactions on Computer Systems, 2014, 33(3): 1-26

[24] Zhang Yingjun, Feng Dengguo, Qin Yu, et al. A TrustZone-based trusted code execution with strong security requirements[J]. Journal of Computer Research and Development, 2015, 52(10): 2224-2238 (in Chinese)

(张英骏, 冯登国, 秦宇, 等. 基于TrustZone的强安全需求环境下可信代码执行方案[J]. 计算机研究与发展, 2015, 52(10): 2224-2238)

ATrustZoneBasedApplicationProtectionSchemeinHighlyOpenScenarios

Zhang Yingjun1,3, Feng Dengguo1,2, Qin Yu1, and Yang Bo1

1(TrustedComputingandInformationAssuranceLaboratory,InstituteofSoftware,ChineseAcademyofSciences,Beijing100190)2(StateKeyLaboratoryofComputerSciece(InstituteofSoftware,ChineseAcademyofSciences),Beijing100190)3(UniversityofChineseAcademyofSciences,Beijing100190)

We propose a protection scheme for security-sensitive applications on mobile embedded devices, which is focus on the scenarios with both strong security and high openness requirements, such as “bring your own device”, mobile cloud computing. To meet the security requirements, we leverage the trusted execution environment of ARM TrustZone to provide strong isolation guarantees for applications even in the presence of a malicious operating system. To meet the openness requirements, our scheme has two major advantages compared with previous TrustZone-based solutions. Firstly, it moves concrete sensitive applications from TrustZone secure world to the normal world, so that the trusted computing base keeps small and unchanged regardless of the amount of supported security applications. Secondly, it leverages a light-weight kernel monitor in the secure world to enforce the untrusted operating system to serve these security applications legally, so that they could securely use standard system calls, which could provide critical features for the openness requirements, such as dynamic application deployment. We also propose proactive attestation, a novel technique that greatly improves the system efficiency by enforcing the operating system to contribute to its own verification. We implement the prototype system on real TrustZone devices. The experiment results show that our scheme is practical with acceptable performance overhead.

TrustZone; trusted execution environment; sensitive application protection; kernel monitor; kernel proactive attestation

TP309

ZhangYingjun, born in 1990. PhD candidate. His main research interests include TrustZone based security applications and system protection technology on mobile platform.

FengDengguo, born in 1965. Professor and PhD supervisor. Senior member of CCF. His main research interests include trusted computing and cryptography.