基于可信执行环境的物联网边缘流处理 安全技术综述

姜 超, 李玉峰,2, 曹晨红, 李江涛

1上海大学计算机工程与科学学院 上海 中国 200444

2网络通信与安全紫金山实验室 南京 中国211100

1 引言

物联网(Internet of Things, IoT)设备在生活中随处可见, 其形成的一系列物联网智能应用, 如智能运输[1], 智慧城市[2], 智能家居[3]以及智能电网[4]等, 正深刻改变着人们的日常生活以及社会公共服务。据国际著名网络方案供应商思科(Cisco)预测, 2020年将有500亿台终端设备接入网络[5], 产生的数据将超过500ZB[6]。

随着万物互联趋势的不断发展, 越来越多的物联网关键应用需要对感知设备产生的大量数据进行低延时、高吞吐的流式数据分析与处理。例如, 北京和伦敦等大城市已部署了数百万个摄像头进行实时的数据监控与收集, 用于交通的实时监测和控制; 越来越多地建筑物配备了各种各样的传感器, 实时监测照明、 温度、湿度、气压、空气质量等信息, 以提高人员安全性和居住舒适度等。这些数据流中包含了大量的个人位置信息、医疗信息、快递信息、以及政务企业信息等敏感信息, 因此, 对物联网流处理的安全性提出了更高的要求。

传统方法通过对数据进行加密(如 Styx[7], MrCrypt[8])来确保数据的机密性, 而加密操作通常是计算密集型的, 对于资源受限的物联网终端设备来说代价过于昂贵。复杂的加密操作也降低了物联网应用响应的及时性, 影响应用性能。近年来, 很多研究工作利用边缘计算[9-10]构建物联网流处理系统, 在靠近物或数据源头的网络边缘侧, 对数据进行一系列计算、处理及汇总, 从而实现对数据处理的安全性与实时性的提升。典型的物联网边缘流处理基本架构如图1所示, 主要分为三个部分, 分别为终端, 边缘端, 云端。物联网数据流由终端流出, 流经边缘进行数据处理与分析, 最后到达云端。例如文献[11]中提到的一个具体案例, 该案例基于上述架构并利用DNN[12]完成分类任务。其中移动设备终端是数据的来源。边缘对DNN的网络层进行划分, 并将计算不密集部分放在边缘, 计算密集型部分放在云端。首先, 移动终端将收集到的等待分类的图片数据发送到边缘; 随后, 边缘将经过部分处理后的结果传到云端; 接着云端对该结果进行验证并进行下一步的处理; 最后云端再将处理后的最终结果传输到移动设备终端。

一方面, 对于传统云计算而言, 边缘更加靠近终端设备, 降低了远距离传输带来的安全风险, 并能够更加及时地响应终端设备。另一方面, 对于终端而言, 边缘拥有更多的计算资源, 数据流处理能力强大。

图1 基于边缘计算的物联网流处理架构 Figure 1 IoT stream processing architecture based on edge computing

目前基于边缘架构的物联网流处理系统依然存在很多安全问题。首先, 与终端设备类似, 边缘设备通常分布式地部署在多种多样的环境中, 缺乏专业有效地监管[13]且配置薄弱[14]。其次, 在边缘侧对物联网数据流的处理往往需要经由一系列复杂的组件, 这些组件存在大量潜在的攻击面与安全威胁。这些组件包括商用操作系统(例如Linux或Windows), 各种用户库以及流分析引擎的运行时框架等等。组件中往往重用了大量为服务器和工作站开发的代码, 其中存在不少可被攻击者利用的配置[15]和漏洞[16]。另外, 边缘处通常汇集了来自多个终端的数据, 是攻击者的高价值目标。与终端相比, 边缘更容易受到攻击, 一旦边缘被攻破, 攻击者不但能访问到机密数据, 而且可能会删除或伪造发送到云端的数据, 从而威胁到整个物联网部署的完整性。如表1所示, 总结了典型物联网边缘流处理架构中每个部分的功能、特征、安全技术与安全现状。

表1 物联网边缘流处理架构各部分功能、特征、安全技术与安全现状 Table 1 The functions, features, security technologies and security status of each part of the edge stream processing architecture of the Internet of Things

为了在边缘平台上进行安全流处理, 本文将探讨基于可信执行环境(Trusted Execution Environment, TEE)的物联网边缘流处理安全技术, 维护物联网数据流的机密性和完整性, 并确保高吞吐量和低输出延迟。其主要思想是在受信任的执行环境中保护和处理数据并限制其访问接口, 忽略其余被认为不受信任的边缘软件堆栈, 从而保证数据流的安全处理。

文章将首先介绍边缘数据流安全处理的相关背景, 然后对基于可信执行环境相关技术的具体解决方案进行介绍与探讨, 接着对主流解决方案的实验平台与结果进行介绍与分析, 最后对未来边缘数据流安全处理的研究方向进行展望与探讨。

2 边缘安全流处理相关背景

本节将从边缘计算、流处理、可信计算基、可信执行环境四个方面展开, 对边缘安全流处理的相关背景进行介绍。流处理与边缘计算能够解决物联网中数据流的高吞吐量与高延迟的问题。可信执行环境保障边缘数据流的安全处理。可信计算基为可信执行环境构建的基础, 因此, 也为基于可信执行环境的边缘数据流的安全处理机制提供必要的条件。可信执行环境利用可信计算基, 在边缘构造一个安全的环境。在该环境中, 数据的计算、存储、保护, 敏感代码的执行等, 均与不安全的世界隔离, 从而保证边缘数据流的安全处理。另外, 2.4小节介绍的RISC微处理器TrustZone(Advanced Risc Machines TrustZone, ARM TrustZone)、英特尔软件防护扩展(Intel Software Guard Extensions, Intel SGX)等平台均为支持TEE技术的产品。

2.1 边缘计算

边缘计算是一种计算范例, 它利用靠近终端设备的边缘服务器构建一个本地云, 并利用该本地云执行计算密集型任务以及存储大量终端用户数据[17-19]。相比云计算来说, 边缘计算中的本地云更靠近用户终端设备, 能够运行较为复杂的分析, 并得到实时处理结果。边缘计算旨在解决在云计算中未得到适当处理的问题, 如延迟敏感型服务和应用程序中的高延迟问题[20-22]。相对于云计算, 边缘计算在一定程度上提供了优势, 但由于其为新兴领域, 其发展仍处于萌芽阶段。

边缘计算具有如下特征: 边缘设备密集分布, 对移动设备流动性支持, 位置感知, 距离用户近, 网络延迟低, 情境感知, 异构性。表2给出了边缘计算特征的具体介绍。

边缘计算的这些独特特征, 能够大大提高物联网应用的性能, 如快速计算物联网终端产生的大量数据流、存储物联网终端数据流及实时响应物联网终端的请求等。文章[23]从网络传输、存储性能及计算能力这三个方面对基于边缘计算的物联网架构带来的优势进行了介绍。而网络传输的快慢, 存储能力的大小, 算力的强弱是决定物联网应用性能高低的关键因素。因此, 近些年来边缘计算在物联网中得到广泛的应用。随着边缘计算的发展, 目前基于边缘的物联网应用也有很多, 并取得了出色的效果, 如公共安全实时数据处理问题[24-26], 智能网联车[27-29], 虚拟现实[30-31]等。

表2 边缘计算的特征及具体介绍 Table 2 Features and specific introduction of edge computing

基于边缘计算的物联网架构, 能够对物联网终端设备产生的庞大数据流进行实时的处理以及快速的响应。这种架构利用边缘在资源受限的终端设备与延迟较高的云端之间找到一个平衡点。但由于其发展时间较短, 在应用安全, 数据安全, 网络安全, 以及节点安全等方面仍然面临着巨大的挑战。

2.2 流处理

流处理一般是指对运动中的数据进行处理。换句话说, 就是在生成或接收数据时直接对数据进行处理[32-34]。物联网中大部分数据都是连续不断的, 如传感器数据, 人的体温、血压等健康信息, 智能网联车的控制信息等。这些数据都是随着时间的流逝而创建的一系列事件。在流处理出现之前, 通常将数据存储在数据库, 文件系统或其他形式的大容量存储中, 并在后期采取批处理的方式对数据进行处理。但对于实时性要求较高的物联网应用来说, 若仍采用这种方式对数据进行处理, 带来的弊端将是灾难性的。

在流处理架构中有一个组件称为流处理器[35-36], 它主要具有两种类型的功能, 分别为用于数据移动和计算的数据功能以及用于资源管理和计算流程的控制功能(例如创建和安排任务)。流处理器基本要求是确保物联网的庞大数据能够在物联网中高效地流动以及被快速及时的计算并拥有一定的容错能力, 保证每个数据至少被处理过一次。目前市面上已有许多成熟的流处理框架, 如 Samza[40], Storm[41], Flink[42]等, 但是现存框架难以解决流数据在处理过程中面临的安全挑战。

基于边缘的物联网架构对数据处理的流程如下, 首先物联网产生的数据到达边缘; 随后, 流处理器在管道处对数据进行提取并及进行处理(如计算, 存储, 分组等); 最后, 利用管道将处理结果输出。因此, 物联网中的流数据具有实时性, 易失性, 突发性, 无序性及无限性[37-39]这几个特征。表3具体介绍了物联网中的流数据的特征。

表3 物联网中的数据流的特征及具体介绍 Table 3 The characteristics and specific introduction of data flow in the Internet of Things

有限的终端设备资源无法同时保证数据流处理的安全与实时性要求。即便借用云计算技术, 仍然面临着带宽、能耗的限制, 难以保证物联网流数据的安全与隐私性。此外, 由于云距离终端较远, 传输延时高, 因此, 其实时性难以保障。边缘计算则为该问题的解决带来了新的思路。表4介绍了边缘计算为流处理带来的优势与缺点。

表4 边缘计算在流处理中的优缺点 Table 4 Advantages and disadvantages of edge computing in stream processing

边缘计算与流处理的结合能够更好的保证物联网的庞大数据高效流动以及快速及时的计算与容错能力。同时, 对于时延性要求较高的物联网应用也能够及时响应。并且, 能够采用终端设备无法使用的安全机制。

边缘安全流处理目前面临着诸多挑战。在边缘设备资源受限的情况下, 如何高效且快速的处理物联网终端传输的海量数据以及在数据处理过程中如何有效保证数据的安全性。在存在多个终端数据源的情况下, 如何保证多个数据源的数据被安全且快速的处理。在存在多个边缘流处理引擎的情况下, 如何合理利用多个流处理引擎进行数据处理以及保证流数据的处理具有一定的鲁棒性与安全性。

2.3 可信计算基

在数据流处理过程中, 物联网应用系统需要抵御不同类型的攻击、保证系统的稳定运行以及用户的信息安全等。若无法满足以上条件, 可能会面临系统的宕机、用户信息的泄露、物理安全等挑战。可信计算基(Trusted Computing Base, TCB)在一定程度上能够对上述物联网应用系统的能力进行补充。举例来说, 医疗机构的可信计算基通常具有安全机制, 以对其临床信息数据库实施访问控制和用户身份验证, 使攻击者难以获取任何一个患者的信息。为保证边缘数据流的安全处理, 设计一个适用于边缘的安全架构必不可少, 而设计用于这些安全架构的可信计算基更是重中之重。

表5介绍了TCB的定义, 组成部分, 以及功能。另外TCB还需要进行固定形式的测试或验证, 只有当测试结果达到一定要求时, 才能将其投入使用。

表5 TCB定义、组成部分、功能 Table 5 TCB definition, components and functions

2.4 可信执行环境

2.4.1 可信执行环境的定义

随着物联网应用系统变得越来越复杂, 用户对安全性的要求越来越高。因此, 边缘数据流的安全处理面临了新的挑战。传统的物联网安全技术不再能够满足物联网边缘流处理架构的安全要求, 而可信执行环境的设计能够有效保证物联网数据流的安全处理。

如下为TEE的四个不同时期的定义, 这些定义表明对TEE不同的使用和理解:

· Ben Pfaff[44]认为TEE是“专用的封闭虚拟机, 与平台的其余部分隔离。通过硬件内存保护和存储的密码保护, 可以保护其内容免受未经授权的人员的观察和篡改。”

· OMTP[45]认为“TEE能抵制一组已定义的威胁。它实现与平台的不安全部分的隔离, 对生命周期管理, 安全存储, 加密密钥和应用程序代码保护。”

· GlobalPlatform[46]认为“ TEE是一个与设备主操作系统同时运行但与设备主操作系统隔离的执行环境。它可以保护其资源免受一般软件攻击。它可以使用多种技术来实现, 并且其安全级别也会相应变化。”

· Jonathan M[47]认为TEE“旨在实现可信执行的功能集如下: 隔离执行, 安全存储, 远程证明, 安全设置和可信路径。”

从以上定义来看, TEE可以简单描述为一种安全的, 受完整性保护的处理环境, 并具有内存和存储功能[48], 另外TCB是TEE设计实现的重要基础。不同于可信平台模块[49](Trusted Platform Module, TPM), TEE在帮助系统实现安全的计算、隐私保护和数据保护的同时, 还为第三方提供隔离的执行环境。在该环境中, 代码的执行过程中对TEE的拥有的资源(如内存、高速缓存等)具有高度的信任, 并能够保证程序被隔离执行, 数据被安全的存储。另外文献[50]认为TEE保证了所执行代码的真实性, 运行时状态(例如CPU寄存器, 内存和敏感I/O)的完整性以及其代码、数据和运行时状态存储在持久性内存中的机密性。此外, 一些基于硬件设计的TEE维护特定的凭证表, 云端根据凭证判断边缘设备是否值得信赖。

如表6为TEE的核心构件方面的定义, 这些构件块的设计能够帮助TEE抵御不同攻击。

2.4.2 支持可信执行环境的主流硬件平台

1) ARM TrustZone

ARM TrustZone是物联网网关的典型硬件[52]。大多数现代ARM内核都配备了TrustZone[53], 这是支持TEE技术的一种产品。ARM TrustZone在逻辑上对平台的软硬件资源进行分区, 例如动态随机存储器和I/O, 使它们分为安全与非不安全的两个世界。安全世界与非安全世界也称为普通操作系统和安全操作系统。在安全世界中执行一些需要保密的操作, 具体如指纹识别、密码处理、安全认证等。其余操作在非安全世界中执行, 具体如用户操作系统、各种应用程序等。安全世界与不安全世界通过一个名为Monitor Mode的模式进行转换。这两个世界通过消息传递以及共享内存这两种方式进行通信。另外, 由于许多恶意攻击人员会在系统断电的时候对系统进行攻击, 所以基于ARM TrustZone的系统会在引导启动的开始就保证其安全性, 以保证整个系统的安全。表7对ARM TrustZone的定义, 重要组件以及主要的功能进行介绍。

表7 ARM TrustZone的定义, 主要组件以及主要功能 Table 7 Definition, main components and main functions of ARM TrustZone

ARM TrustZone不同于其他TEE技术(如Intel SGX), 其拥有专用的受信任的I/O。受信任的I/O是ARM TrustZone的独特功能, 通过TrustZone TZASC和TZPC这两个硬件组件来实现。另外, 目前ARM平台由于其低功耗与出色的性能以及低廉的成本, 十分适合用于边缘的可信执行环境构造, 并保证边缘的安全流处理。

2) Intel SGX

Intel SGX 是Intel在2013年推出的指令集扩展,旨在以硬件安全为强制性保障,为用户空间提供可信执行环境。文献[54]对该项技术进行了系统的介绍与分析, Intel设计一组新的指令集扩展与访问控制机制,实现不同程序间的隔离运行,使得关键代码和数据的机密性与完整性免受恶意软件的攻击和泄露。 其主要思想是将合法软件的安全操作封装在一个飞地(enclave)中, 保护其不受恶意软件的攻击。

无论是特权或者非特权的软件(例如操作系统和虚拟机监视程序[55](Virtual Machine Monitor, VMM))都无法访问飞地, 所以攻击者难以影响飞地中的代码和数据, 并且飞地的安全边界只包含CPU和它自身。SGX创建的飞地也可以理解为一个可信执行环境TEE, 无论恶意软件的特权等级有多高都无法访问飞地中的数据, 从而保证数据与代码的完整性与机密性。如图2所示为SGX的核心操作原则, 首先在不可信环境中创建不同的飞地, 随后飞地通过SGX提供的调用接口调用可信函数, 数据会在飞地中被处理和分析, 最终返回得到的结果。以上内容均说明SGX的设计能够很大程度上提升系统的安全。

图2 SGX核心操作原则 Figure 2 SGX core operating principles

ARM TrustZone与Intel SGX之间的共同点和区别具体如表8所示。

表8 SGX与ARM TrustZone共同点与区别 Table 8 Common points and differences between SGX and ARM TrustZone

2.4.3 其他支持可信执行环境的硬件平台或相关技术

还有一些支持TEE的硬件平台, 如TI M- Shield[56], Intel TXT[57], AMD SVM[58]也利用隔离的方式来保障系统的安全。TI M-Shield与ARM TrustZone类似, 都适用于嵌入式系统, TI M-Shield在提供安全的隔离环境的同时, 还提供了安全的移动框架。但是TI M-Shield的安全隔离技术只限于两个处理器, 分别为OMAP以及OMAP-Vox[59], 所以应用领域比较狭窄。Intel TXT和AMD SVM都是基于TPM发展起来的, 并且提供从BIOS到应用层的完整信任链, 从而提高系统的安全性。但由于其对硬件配置及安全控制策略过度依赖导致其无法获得普及。由于这些平台存在一定的缺陷, 目前很少有基于这些平台进行设计的物联网边缘流处理安全方案。

随着物联网应用的不断发展, RISC-V指令集进入人们的视野。该项目始于2010年, 由加州大学伯克利分校的David A. Patterson教授主导下完成。RISC-V是一个全新的指令集架构, 该指令集架构完全开源, 并且允许自由地制造和销售基于该指令集的芯片或软件。相比于其他开源指令集, 其适用于云计算机、手机和嵌入式系统等现代计算设备, 因此具有重大意义。目前市面上常见的基于RISC-V设计的系统级芯片(System on Chip, SoC)有 Rocket[60], Hummingbird[61], VexRiscv[62]等。但是由于其诞生时间太短, 相关编译器、软件开发环境和开发工具以及其他生态要素仍然处于发展阶段。目前基于RISC-V的边缘安全流处理方案也并不常见。

2.4.4 可信执行环境在终端、边缘以及云端的构建

TEE的构建能够有效提升物联网应用数据流处理的安全性。但在终端、边缘以及云端构建可信执行环境仍面临诸多挑战, 具体见表9所示。

表9 构建可信执行环境面临的挑战与安全现状 Table 9 Challenges and security status of building a trusted execution environment

基于边缘计算的物联网应用架构可以提供较低的延迟, 最大程度地减少传输到后端数据中心所需的流量, 并减少单个云提供商的故障风险。因此, 在边缘构建TEE能够解决终端与云端面临的挑战。

3 边缘安全流处理解决方案

现有的边缘软件堆栈将物联网数据委托给商用操作系统(Operating System, OS), 分析引擎和语言运行环境(例如Java虚拟机)。这些组件由成千上万行代码组成[63], 存在许多可利用的漏洞[64-65], 难以保证边缘系统的安全。目前边缘流处理面临的安全问题主要分为两个。一方面, 在边缘端发起攻击的本地攻击者可能会通过广泛的用户/内核接口[66-67]或IPC[68]攻击分析引擎; 另一方面, 远程的攻击者可能会通过边缘网络服务来损害分析引擎[69]或操作系统[70]。攻击者成功后可能会暴露物联网数据, 破坏或暗中操纵数据。在边缘建立可信执行环境能够有效解决上述问题, 从而保证边缘数据流的安全处理。

3.1 基于软件的可信执行环境技术

3.1.1 基于操作系统进程隔离恶意软件机制

目前许多应用程序对系统拥有极高的特权, 它们能够利用高分辨率相机和其他传感器来观察其用户和物理环境。若这些应用系统被攻击, 很可能造成用户信息的泄露(如银行卡号, 车牌号, 物理位置, 计算机内容)或用户被监视等安全问题。

Jana 等人[71]针对以上问题, 提出了一种隐私保护系统——Darkly。作者重点关注以下场景, 该场景中设备的操作系统与感知传感器的硬件完全可信, 但设备上第三方应用程序正在不可信的环境中运行。系统主要思想为, 即使应用程序是恶意的, 但是只能以用户级特权运行, 并且只能通过可信的API(例如OpenCV计算机视觉库)访问系统(包括感知传感器), 从而提高边缘上数据流处理的安全性。

Darkly的系统模型如图3所示, 其中受信任的组件以阴影表示。Darkly本身包含两个部分, 受信任的本地服务器和不受信任的客户端库。作者利用操作系统提供的基于用户的标准隔离: 其中Darkly服务器是特权进程, 可以直接访问感知传感器, 而应用 程序作为非特权进程运行, 只能通过Darkly访问传感器。不受信任的Darkly客户端库作为每个应用程序进程的一部分运行, 并与Darkly服务器通信。即使恶意应用程序修改了相关库, 系统仍保持安全。

图3 DARKLY的系统模型 Figure 3 DARKLY’s system model

该方法将数据流的存储、获取、计算等操作与恶意应用程序隔开, 在一定程度上防止数据被恶意程序泄露或者篡改。但其数据的计算主要在OS进程中, 这样容易导致TCB过大。TCB越大导致代码量过大, 容易利用的漏洞就越多, 攻击面也越广, TCB中的任何漏洞都可能使攻击者具有访问应用程序数据或损害其完整性的能力。

3.1.2 基于虚拟化隔离恶意操作系统机制

商用操作系统的可信组件往往包含大量代码, 因此, 具有广泛的攻击面。可信组件一旦被破坏, 攻击者可以完全访问系统上的敏感数据。目前有许多基于虚拟化的安全方案来隔离这些可能受到破坏的OS, 从而保证应用程序中的敏感数据免受攻击者的读取与修改。Chen等人[72]提出了Overshadow, 利用多重阴影技术, 即使整个操作系统都被攻击者破坏, 仍然能够保护应用程序数据的隐私和完整性。Owen S等人[73]提出的一个基于虚拟化架构的系统—Inktag, 该系统利用安全、可靠的程序对不受信任的商品OS的行为进行验证。John等人[74]提出的Virtual Ghost系统, 它能够创建操作系统根本无法读取或修改的安全内存, 从而保护敏感数据的安全。上述安全方案利用虚拟化技术保护应用程序的敏感数据免受感染OS内核的侵害。但是, 这样的系统容易受到侧信道攻击。Dong等人提出了防御一种侧信道攻击的方法, 具体攻击为受到入侵的OS内核发起的页表和最后一级缓存(Last Level Cache, LLC)侧信道攻击。

目前基于虚拟化的隔离恶意OS的机制在物联网边缘流处理安全方案的应用仍然面临着一些挑战, 主要可以分为三个方面。第一, 上述安全方案大都实现于资源相对丰富的PC, 并不适用于物联网嵌入式系统; 第二, 上述安全方案并不适用于流处理或无法高效快速的数据流; 第三, 对于边缘设备而言, 上述安全方案代码体量仍然过大, 并具有广泛的攻击面。但虚拟化技术由于其更高的资源利用率、更高的安全性以及更高的可用性和扩展性等优势, 对基于虚拟化的边缘流处理安全方案仍然值得研究。

3.1.3 基于可信计算基的安全机制

为了进一步提升TCB的安全性, 缩小TCB的尺寸是一种直接可行的措施。只有保持较小的TCB安全区域尺寸, 才能够有效保证边缘数据流的安全处理。

文献[75]提出了Flicker, 一种使用最小TCB对敏感代码隔离执行的体系结构。在Flicker开始执行之前和执行过程中, 任何软件都无法对Flicker代码进行监视或干扰。并且在Flicker执行完全结束之前, 可以消除所有Flicker代码执行的痕迹。例如, 证书颁发机构(Certificate Authority, CA)可以使用其私钥对证书进行签名, 即使基本输入输出系统(Basic Input Output System, BIOS), OS和直接存储器访问(Direct Memory Access, DMA)设备被控制, 密钥仍然安全, 并且还提供代码的远程证明。但是由于Flicker需要执行Rootkit[76]检测, 在执行的过程中会进行完整性度量[77]。若完整性度量方法的结果的误报率和漏报率过高, 则可能无法检测出Rootkit, 从而导致系统被攻击。

文献[78]开发了一个安全的虚拟机管理程序, 称为TrustVisor, 为安全敏感的代码模块提供安全的执行环境, 另外TCB中仅包含5306行代码(其中一半以上用于加密操作)。TrustVisor能够保护不受信任平台上的安全敏感代码和数据, 并阻止恶意软件(例如内核级Rootkit)的攻击。更具体地说, TrustVisor旨在保护安全敏感的代码的完整性, 以及该代码所使用数据的机密性和完整性, 并向远程实体证明这些属性。该系统支持许多应用程序(例如安全套接字/安全传输层协议), 特别适用于敏感代码量较小的情况。这项工作的主要贡献是设计和实现了一个综合系统, 使应用程序开发人员能够为在不安全的平台上执行的数据和代码提供强大的安全保证, 并向外部验证者证明这些安全性。同时, TrustVisor设计了小型的TCB, 大幅提升了工作效率、易用性和安全性。

以上方法将TCB尺寸保持在安全区域内较小, 从而减少TCB中存在的漏洞, 使得攻击者难以访问应用程序数据或损害其完整性, 在一定程度上提升了边缘数据流处理的安全性。但在以最小的TCB支持数据密集型计算时, 面临诸多挑战。

3.2 基于硬件的可信执行环境技术

3.2.1 基于Intel SGX安全流处理方案

攻击者通常攻击现有系统软件中的漏洞, 或者损害特权系统管理员的凭据, 从而获得对其他应用程序数据的访问, 修改或对系统的控制等。SGX增加了对安全区域的支持, 能够保护应用程序代码和数据免受其他软件(包括特权更高的软件)的访问。SGX的这个特性能够有效解决上述问题, 并保证边缘数据流处理的安全性。

文献[79]为保证物联网数据流的安全处理, 介绍了一个基于Intel SGX的SecureStreams中间件框架, 该框架能够支持在不受信任的分布式环境中开发和部署安全流处理应用。其设计将高级反应数据流编程范例与英特尔底层软件防护扩展相结合, 以确保处理数据的私密性和完整性。另外, SecureStreams支持从大型集群到多租户云基础架构的分布式环境中流处理任务的实现、部署和执行, 能够有效解决数据流处理在分布式环境中面临的安全问题。作者利用LUA[80](一个小巧的脚本语言)实现了SecureStreams的原型。尽管该方案在一定程度上能够保证数据流处理的安全, 但在其TEE中缺乏对于数据流并行处理的优化, 可能会导致边缘处理结果的延迟性较高、数据吞吐量较小等问题。

现有的容器隔离机制[81], 仅能防止不受信任的容器对数据的访问, 但无法阻止高级特权系统软件的访问, 如OS内核和系统管理程序等。文献[82]针对这一问题, 提出了一种用于Docker的安全容器机制-SCONE, 该机制使用Intel CPU的SGX受信任执行技术来保护数据免受容器进程外的攻击。该系统主要关注以下场景, 一个攻击者拥有像超级用户那样对系统以及物理硬件的访问权, 并能够控制整个软件堆栈, 重播、修改记录以及删除任何网络数据包或对文件系统访问。最终, 该机制能够在不受信任的OS上提供并运行安全容器, 从而保证数据的完整性与机密性。但该系统将整个用户应用程序和库放入TCB中, 这样会导致TCB过大, 致使TCB暴露较多的漏洞。

目前云计算基础架构旨在保护特权代码免受不受信任的代码侵害, 无法有效防御云计算中恶意特权软件对系统的攻击(如管理程序和固件), 以及对用户数据的访问。文献[83]针对上述问题, 利用Intel SGX提出了一个应用于云端的屏蔽执行系统-Haven, 通过将部分代码和数据放置在SGX的安全区中的方式来保证数据免受攻击。该系统利用SGX的硬件保护技术来防御特权代码和物理攻击(例如内存探针)。

VC3[84]针对上述问题提出了一个基于MapReduce框架系统, 这是第一个允许用户使用云服务器进行分布式计算的同时, 还能够保持运行代码和数据的机密性, 并确保结果正确性和完整性的系统。即使恶意攻击者可以控制整个云提供商的软件和硬件基础架构, 该系统仍然能够正常的工作, 但计算中若经过认证的物理处理器被攻击, 那将无法保证系统仍然保持正常。系统使用可信的SGX处理器[85-86]作为构建模块, 将系统分为受信任和不受信任的部分, 并最大程度地减少其TCB。该方法主要适用于批处理, 但其设计思想与取得的效果值得参考。

上述的两个系统VC3与Haven均实现于云平台, 对于资源受限的边缘端未必合适, 但其思想及技术值得运用于边缘安全流处理系统的设计上。尽管该系统在设计TCB时遵循最小原则, 但对于边缘安全流处理方案而言仍然较大, 会暴露较多漏洞。另外该系统由于设计与实现上的缺陷, 导致无法检测磁盘块的回滚攻击, 对处理性能有一定的影响。

3.2.2 基于ARM TrustZone的安全流处理方案

物联网边缘上的商用OS, 因代码体量过于庞大导致其面临许多的安全挑战, 而这些设备经常处理机密数据, 攻击者完全有可能利用受感染的OS访问这些数据。为了解决这个问题, 传统的方案如在单独虚拟机中处理数据[87], 利用硬件功能或改造商用操作系统, 从而保护应用程序免受恶意操作系统的侵害。但是这些方案并不适用与物联网平台。为此文献[88]针对上述问题开发一个系统——TrustShadow。TrustShadow将旧版本, 未打补丁的应用程序与受到威胁的OS进行隔离。并利用ARM TrustZone技术, 将资源划分到安全和不安全的环境中。在安全的世界中, TrustShadow为安全性至关重要的应用程序构建一个受信任的执行环境。这个受信任的环境由轻量级的系统维护, 并且由该系统协调应用程序与不安全世界中的普通OS的通信。作者在具有ARM TrustZone的真实芯片板上对TrustShadow进行了设计, 并使用微基准测试和实际应用程序对其性能进行了评估, 评估的结果十分出色。但是该系统将整个用户应用程序和库拉到TCB中。但正如前文所述, 若TCB过大, 则导致流分析引擎及其库很大, 很复杂, 容易受到攻击。

文献[89]基于ARM TrustZone提出一个边缘流处理安全引擎——StreamBox-TrustZone, 简称SBT。其目标是维护物联网数据的机密性和完整性, 支持可验证的结果, 并确保高吞吐量和低输出延迟。该系统遵循最小特权原则, 在TEE中保护分析数据和计算并限制它们的接口。该方案能够解决TCB过大的问题, 将TCB缩小为仅包含受保护的功能、TEE和安全硬件的部分。该系统的整体框架分为终端、边缘端、云端三个部分。终端是数据流来源, 通过使用安全感测技术保证终端产生可信事件; 边缘端对数据流进行处理和分析操作, 是流处理安全的关键部分; 云端则是受信任的部分, 主要负责对边缘处理结果的验证, 以证明分析结果的正确性。

该引擎利用ARM TrustZone构造一个可信执行环境StreamBox-TrustZone, 将系统软硬件资源划分为安全世界与不安全世界, 从而保证边缘数据流的安全处理。如图4所示, SBT主要分为两个部分, 上半部分是受信任的是数据平面, 下半部分是不受信任的控制平面, 这个部分在流处理过程中会面对许多安全问题。另外终端传送的数据流只会通过ARM TrustZone的可信IO通道流经安全的数据平面, 并且数据流的所有处理都发生在数据平面中。每当数据流经过数据平面, 数据平面会发送一个特定凭证到控制平面。控制平面会根据需要使用凭证, 调用系统接口安排数据分析管道, 最后数据平面将操作管道划分为多个可信计算原语来对数据流进行处理。处理完成后由数据平面将数据发送到云端进行进一步的验证和分析, 验证数据流的结果正确度与新鲜度。通过创建可信执行环境以及高效的验证机制, 来提高边缘数据流处理的安全性。同时, SBT还设计特殊的内存管理技术与并行计算技术来提高数据流分析的吞吐量与时延性。

图4 SBT框架图 Figure 4 SBT framework diagram

通过创建可信执行环境以及高效的验证机制, 来提高边缘数据流处理的安全性。同时, SBT还设计特殊的内存管理技术与并行计算技术来提高数据流分析的吞吐量与时延性。Heejin Park在华为的Hikey960开发对系统进行了实现。结果证明, SBT的TCB中的可执行文件只有42.5 KB, 缩小了TCB的大小。在八核ARMv8平台上, 它对输入事件处理速度高达140 MB/s并具有亚秒级的延迟, 得到了最佳性能。

SBT为将TCB设计到最小, 其仅包含低级计算原语, 导致流管道的机密性无法得到保证。SBT无法防御以下攻击: (1)可信任的非边缘组件, 如传感器[90]; (2)TEE 内核的错误[91]; (3)侧信道攻击, 如 key skew[92]; (4)物理攻击, 例如嗅探TEE的DRAM[93]。

由于ARM TrustZone设计上的不足, 一旦搭配ARM平台的终端或者边缘设备丢失, 容易受到内存攻击, 例如冷启动攻击[94], DMA攻击[95]等。文献[96]针对这些问题提出了Sentry, 该系统允许应用程序和OS组件将代码和数据存储在ARM SOC而不是DRAM中, 防止攻击者通过内存攻击的方式破坏数据的机密性, 完整性以及系统的可用性。

Sentry将数据存储在ARM SOC上来抵御内存攻击, 但当负责创建和维护SOC的操作系统受到威胁时, 所有保存在ARM SOC上敏感数据都会泄露出去。文献[97]提出了一个基于ARM处理器的缓存辅助安全执行框架-CaSE, 该框架可防御软件攻击, 硬件内存泄露攻击等。CaSE利用TrustZone和Cache-as- RAM技术来创建基于缓存的隔离执行环境, 应用程序的数据与代码在内存中进行加密, 并且仅在处理器内解密才能执行。这样能够保护安全敏感型应用程序的代码和数据, 使其免受操作系统和冷启动攻击的侵害。作者在搭配ARM Cortex-A8处理器的IMX53上实现了CaSE的原型。实验结果表明, 在执行包括AES, RSA和SHA1的加密算法时, CaSE对系统性能的影响很小。但相比直接处理明文数据, 仍然无法完全满足物联网应用的低延迟要求。

TEE内核是SBT安全世界的重要组成部分, 对处理器拥有最高特权, 并对硬件具有无限访问权。因此, TEE内核中存在的任何错误都有可能被攻击者利用并攻击, 随后破坏数据的机密性, 安全性以及系统其余部分的正常运行。文献[98]为保证微内核的功能正确性, 提出了SEL4, 它是L4[99]微内核家族的成员, 旨在通过机器辅助和机器检查的形式证明内核的功能正确性。作者实现并证明了SEL4G功能的正确性。

3.2.3 基于RISC-V的安全流处理方案

当软件开发人员选择目标硬件平台时, 他们的实际应用需求可能会被锁定在不同硬件平台的TEE设计限制中。例如, 3.3.1小节中提到的Intel SGX的可信执行环境—enclave需要的内存大小是静态的, 缺乏安全的I / O和系统调用支持, 容易受到侧信道攻击。该情况下, 只有Intel才能更改SGX中固有的设计, 例如动态调整SGX enclave虚拟内存的大小[100]。正是由于这些限制和其他类似限制, 很多开发人员在其他指令集架构(Instruction Set Architecture, ISA)(例如OpenSPARC[101], RISC-V[102-103])上重新实现TEE。但对TEE进行重新设计时将面临诸多困难, 另外设计出的TEE也可能存在上述的限制。为此, Dayeol Lee提出了KeyStone[104]—第一个用于构建可定制TEE的开源框架。该框架突破固定TEE的限制, 允许开发人员构建自定义的TEE, 从而保证边缘流处理的安全。另外, KeyStone保证TEE原型被快速制作与修复, 对威胁模型具有一定的鲁棒性以及针对特定用例的部署。作者使用RISC-V设计和构建KeyStone, 并在HiFive Unleashed(搭载RISC-V处理器的硬件)上实现了KeyStone的原型。其中RISC-V是由多个开源核心实现的开放式ISA[105]。

标记内存是一种提供细粒度和灵活的隔离边界, 从而保证TEE的健壮性。其原因有两个, 一方面, 细粒度的隔离边界能够使受信任的内存在有限物理地址中更加紧密集成; 另一方面, 灵活的隔离机制对于动态管理受信任的内存至关重要。但目前标记内存方案产生的内存开销对于资源受限的小型嵌入式系统并不适合。所以, 对于小型嵌入式系统而言, 强大、高效而又灵活的隔离执行仍然是一个未解决的问题。为此Samuel Weiser设计了Timber-V[106], 一种新的带标记的内存体系结构, 该机制能够在小型嵌入式系统上灵活, 高效地隔离代码和数据。作者在RISC-V模拟器上将系统实现, 并展示了Timber-V的出色性能。作者利用特殊的标记内存技术, 从而保证边缘数据流的安全处理, 该方案将隔离执行机制引入到资源受限的低端设备, 该隔离执行机制类似于Intel SGX的enclave。

TEE常常无法与外部外围设备建立安全通信, 并且部署在安全环境中, 但该安全环境中的操作系统并不提供最新的防御策略(如保护页面等), 因此, TEE容易遭受各种攻击。针对上述问题, Pascal Nasahl提出了HECTOR-V[107], 一种利用异构多核体系结构开发安全的TEE的设计方法。作者认为在主应用处理器上实现的TEE(例如Intel SGX或ARM TrustZone)是不安全的。因此, 作者另外使用一个安全处理器-RVSCP将其直接嵌入到HECTOR-V架构中。RVSCP是一种经过安全加固的RISC-V处理器, 专为构建TEE而设计。该架构在安全域和非安全域之间实现了高度隔离, 并能够抵御侧信道攻击(例如缓存和基于瞬态的攻击)。另外, TEE与应用处理器的紧密耦合使HECTOR-V能够帮助不同设备之间建立安全通信通道。

RISC-V相较于Intel SGX和ARM TrustZone起步较晚。因此, 还没有广泛出现于市场的RISC-V处理器, 并且对RISC-V处理器的隔离执行没有进行广泛的研究。

3.3 边缘安全流处理方案小结

本节将对上述的边缘安全流处理方案进行总结, 主要从三个方面, 分别是可防御攻击、主要方法, 以及主要缺陷。具体如表10所示。

表10 相关技术可防御攻击, 主要方法及主要缺陷 Table 10 Related technologies can defend against attacks, main methods and main flaws

以上部分方案并不完全适用于边缘或边缘安全流处理, 但其设计思想值得在边缘应用, 如基于虚拟化技术隔离技术、Haven和SEL4等。因此, 在设计边缘安全流处理方案时, 上述方案均值得研究。

目前适用于边缘的安全方案大都存在一些缺陷。具体如下, 加密的方法会消耗过大的资源且数据处理速度会大幅下降, 难以在边缘应用。基于OS进程隔离机制会导致过大的TCB, 容易暴露庞大的攻击面。利用缩小TCB的方法, 无法有效支持数据密集型计算, 难以满足物联网庞大数据流的快速处理。基于Intel SGX的方案成本较高且能耗较高, 另外大都适用于云端。基于RISC-V的方案目前仍处于初期, 但其完全开源且适用于终端、边缘和云端, 具有广阔的发展前景。TrustZone具有低能耗, 出色的性能, 低廉的成本和成熟的技术等特性。因此, 基于TrustZone的安全方案目前最适用于物联网边缘。但由于其设计缺陷, 无法防御物理攻击, 侧信道攻击, TEE内核攻击等。

4 硬件辅助的边缘典型流处理安全方案实验结果对比分析

为应对边缘流处理过程中面临的安全威胁, 通常, 可以采用基于软件的TEE安全方案来进行防护, 如Darkly, 密码加密, 访问控制策略等机制。但基于软件的安全方案性能开销巨大, 对于资源受限的边 缘来说并不适用。另外, 单纯基于软件的TEE安全方案, 代码行数可能达到百万级别。如3.1小节所述, 代码行数越多, 攻击面越大。而硬件辅助的TEE安全方案能够有效解决上述问题。本节将对2.4小节介绍的支持TEE的硬件平台进行分析与总结, 并对两个基于主流硬件平台的安全流处理方案的具体实验结果进行分析与对比。

4.1 硬件平台分析与总结

2.4.2 小节中说明目前常见的支持TEE的硬件平台有ARM Trustzone, Texas Intruments M-Sheild, Intel SGX以及AMD SVM等。该小节说明Texas Intruments M-Sheild, AMD SVM等平台存在一定的缺陷(如应用领域狭窄, 难以普及等), 因此, 并不适用于物联网边缘安全流处理这一场景。由于RISC-V指令集架构诞生时间较短, 基于RISC-V设计的安全流处理方案并未得到广泛研究。

ARM TrustZone与Intel SGX相比于其他硬件平台更加适用于边缘可信执行环境的构建, 并保证物联网流数据的安全处理。一方面, 由于Intel SGX健壮、可信、灵活的安全功能与硬件扩展的性能保证, 使得这项技术在边缘安全流处理方面具有广阔的应用空间与发展前景。目前学术界和工业界已经对SGX技术展开了广泛的研究, Intel也在其最新的第六代CPU中加入了对SGX的支持, 并加紧研究适用于边缘的Intel处理器。另一方面, 根据2018年的Eclipse一项调查[52], 边缘平台一般使用ARM TrustZone来构建边缘安全系统。因此, ARM Trust-Zone和Intel SGX是目前适用于边缘构建安全流处理方案的主流硬件平台。

表11对这些支持TEE的不同的平台进行了总结。

4.2 主流硬件平台安全方案实验结果分析

4.1 小节说明Intel SGX和ARM TrustZone目前市场上的两个主流硬件平台。SecureStreams和StreamBox-TrustZone在流数据处理方面的表现都十分出色, 并且实验配置, 评判基准, 以及安全性也都近似。因此, 本节将对这两个方案实验结果进行分析与对比, 前者基于Intel SGX, 后者基于ARM Trust-Zone。

4.2.1 StreamBox-TrustZone实验结果分析

SBT利用缩小TCB尺寸, 优化TEE内部计算与内存管理机制以及压缩审计记录等技术来保证处理终端流数据的速度与安全性。作者在华为的开发板-Hikey960上对SBT进行了实现与评估。Hikey板支持OP-TEE[108]的运行, 并搭载ARM TrustZone以及支持第三方编程。该板具体配置见表12。

表11 支持TEE的硬件平台 Table 11 Hardware platforms supporting TEE

表12 SBT开发板配置 Table 12 SBT development board configuration

作者设定了相同CPU内核数量与输出延迟, 并测试了SBT(在TEE内处理数据, 对数据加密, 并利用可信I/O)以及三个修改版的SBT。这三个SBT修改版分别是SBT ClearIngress(在TEE内处理数据, 以明文方式提取数据), SBT IOviaOS(在TEE内处理数据, 并不利用可信I/O), Incure(在TEE外处理数据, 没有任何安全措施)。另外, 作者使用六个行为基准来判断SBT处理终端数据流的能力, 这些基准均包含主要的流操作符。这六个基准具体如表13所示。

表13 基准的名称及具体含义 Table 13 The name and specific meaning of the benchmark

作者测试了所有基准的吞吐量, 每个基准的测试结果都类似, 我们以Windowed Aggregation基准为例, 介绍在不同内核数下的不同SBT的吞吐量大小, 具体如表14所示。

表14 不同SBT Windowed Aggregation的吞吐量结果 Table 14 Throughput results of different SBT Windowed Aggregation (MB/s)

最终结果表明, Inscure表现最佳, SBT ClearIngress 第二, StreamBox-TZ其次, SBT IOviaOS相对最差。但是Inscure安全性最差, 而SBT的安全性是最好的, 并且随着内核数的增加, SBT的吞吐量也在不断增加。

4.2.2 SecureStream实验结果分析

SecureStreams主要用于部署和处理大规模的安全流, 而目前基于Intel SGX部署的边缘安全方案很少, 适用于流处理的安全方案更是少之又少。SecureStreams使用两台计算机组成集群来进行实验与评估, 具体配置如表15所示。

表15 SecureStreams开发板实验配置 Table 15 SecureStreams experimental configuration

为了衡量系统可实现的吞吐量以及体系结构的网络开销, 作者在三种不同的配置中部署了SecureStreams管道。第一个配置是允许流框架绕过SGX飞地对数据直接进行处理, 并且不对数据集加密。第二个配置是对数据集进行加密, 但允许加密的数据不在SGX飞地中进行处理。最后, 配置一个完全安全的管道, 对输入数据集进行加密, 并在SGX飞地中对进行数据处理。数据节点不断的注入数据集, 辅助组件通过非阻塞I / O连续侦听传入的数据, 并对数据进行处理。作者通过利用Docker的内部监视和统计模块来收集带宽测量结果, 具体结果(以每种配置吞吐量峰值为例)见表16。

表16 不同SecureStreams配置的吞吐量结果 Table 16 Throughput results of different SecureStreams configurations (MB/s)

最终结果表明, 安全机制越多, 数据吞吐量越小。而数据的处理速度会随着辅助组件的增加而增加, 但是加速度会随着辅助组件增加而变小。其中的原因是辅助组件能够并行处理数据, 而辅助组件的并行会受到物理核心总数的限制。

4.2.3 StreamBox-TrustZone 与SecureStream结果分析与对比

从上述两个实验结果可以看出, 在相同实验配置的情况下(均进行数据加密, 均TEE内进行数据处理, 相同数量的并行组件处理), SBT每秒处理的数据更多, 性能更加出色。比如在4核心情况下, SBT的吞吐量能够达到65MB/s左右, 而SecureStream只能够达到8MB/s左右。

SecureStreams在小型x86集群实现了该系统, 该集群的资源比HiKey丰富得多, 其具有更快的CPU(8倍i7-6700@3.4GHz与8倍Cortex-A53@ 1.2GHz), 更大的DRAM(16 GB对2 GB), 更高的功率(130W对36W)和更高的成本(600美元对65美元)。因此SBT利用更小的成本以及计算资源得到比SecureStreams更好的实验效果。

具体实验结果如表17所示。

表17 主流边缘流处理方案实验结果 Table 17 Experimental results of mainstream edge stream processing scheme

综上所述, 在边缘安全数据流处理过程中, SBT能够以更小的计算资源及更低的成本来获得更出色的性能, 但SecureStreams能够防御一些SBT无法防御的攻击, 如冷启动攻击, DMA攻击等。

5 安全展望

在之前的章节中, 对基于可信执行环境的物联网边缘流处理安全技术进行了介绍与探讨。但目前对物联网边缘流处理安全的研究还处于一个早期阶段, 依然存在着一系列的安全问题尚待解决, 在这里我们对未来研究方向进行讨论和展望。

(1)边缘数据流处理中的安全与效率的权衡问题。大多数的物联网应用场景需要边缘节点进行复杂的运算操作, 这些复杂的操作往往会消耗很多的时间以及大量的计算资源。若边缘设备上采用的安全机制所消耗的计算资源以及时间代价太高, 会加重物联网设备与边缘之间的延迟问题, 所以在物联网的实际应用场景中需要对安全和效率之间做好权衡, 在保证边缘数据处理安全的情况下同时也要能够保证能够及时对终端设备进行响应。

(2)跨越多个边缘设备的流处理安全问题。在物联网边缘端设备往往不只一个, 可能是一个或者多个边缘设备共同合作进行流处理操作。边缘端的设备一般都是分布式的, 其中网络设备的可信度仍然需要进行进一步的研究, 从而提出一种有效的信任模型来保证跨越多个边缘设备的数据流处理的安全性。

(3)低功耗的高效加密措施。目前, 基于数据加密的方法难以应用于边缘流处理的场景, 主要原因在于1)边缘设备的资源受限; 2)加解密算法过于复杂; 3)缺乏针对边缘侧的数据加密处理方案及标准。

(4)ARM TrustZone的安全问题。由于ARM TrustZone设计上的缺陷, 目前基于ARM TrustZone构建的边缘流分析引擎均难以防御TEE内核缺陷攻击、侧信道攻击和物理攻击(内存攻击)等攻击。尽管有一些方法能够在一定程度上防御以上攻击, 但这些方法还未应用于基于ARM TrustZone平台的边缘安全流处理引擎。未来可以借鉴并利用这些方法, 来设计基于ARM TrustZone平台的边缘安全流处理引擎, 从而解决上述问题, 提高边缘流处理的安全性。

(5)基于RISC-V的物联网边缘流处理安全方案的研究。目前市面上的TEE硬件平台普遍存在一些问题。例如, Intel SGX成本太高暂时无法广泛适用于物联网; ARM TrustZone是封闭式的指令集架构且存在着高昂的专利和架构授权问题; TI M-Shield过度依赖于硬件配置及安全控制策略, 导致其应用领域比较狭窄。RISC-V适用于云计算机、手机和嵌入式系统等现代计算设备, 并且完全开源, 因此, RISC- V前景十分广阔。在未来的物联网市场, RISC-V凭借其完全开源的优势, 很可能击败ARM。因此, 基于RISC-V的物联网边缘安全流处理方案值得研究。

6 结束语

随着物联网的普及, 越来越多的感知设备每时每刻都产生着大量数据, 需要进行低延时、高吞吐的流式数据分析与处理。在这些数据流中往往包含了大量涉及用户隐私的敏感数据, 在要求实时性的同时, 对流处理的安全性提出了更高的要求。边缘计算的出现一定程度上提升了数据流处理的安全性与实时性然而, 基于边缘计算的架构会使数据暴露于边缘端结构复杂、易受攻击的软件堆栈中, 从而带来诸多的安全威胁。为了解决这个问题, 本文探讨了基于可信执行环境的物联网边缘流处理安全技术, 从边缘安全流处理相关背景出发, 介绍了流处理, 边缘计算以及适用于边缘的可信执行环境技术与相关平台; 然后, 介绍并探讨了用于边缘端的基于可信执行环境的流处理安全技术; 接着, 对主流解决方案的实验平台与结果进行介绍与分析; 最后, 对未来物联网边缘安全流处理的研究方向进行了展望。