物联网安全研究综述：威胁、检测与防御

杨毅宇，周威，赵尚儒，刘聪，张宇辉，王鹤，王文杰，张玉清,,,4

（1.中国科学院大学国家计算机网络入侵防范中心，北京 101408；2.西安邮电大学网络空间安全学院，陕西 西安 710121；3.西安电子科技大学网络与信息安全学院，陕西 西安 710071；4.海南大学计算机与网络空间安全学院，海南 海口 570228）

1 引言

近5 年来，物联网设备数量呈爆炸性增长，根据权威统计机构发布的数据，全球接入网络的物联网设备数量在2017 年已达20.35 亿台，并且到2025 年将增长到超过75.44 亿台[1]，物联网将深刻影响人类生产和生活的各个方面。然而，在物联网蓬勃发展的过程中，现有的安全机制难以应对日益增长的安全需求，导致各类应用场景中的安全问题层出不穷[2]，大量设备容易遭受恶意代码威胁或非法控制，甚至引发大规模安全事故。从2016 年著名的Mirai蠕虫利用物联网设备引发大规模拒绝服务攻击事件[3]，到近期的智能音箱被攻击者利用来窃听用户隐私[4]，物联网安全威胁随着技术发展而不断出现。

及时检测发现安全威胁或提前采取防御是对抗威胁的重要手段，但是物联网系统的特性[1]决定了对其实施完善的安全防护面临诸多挑战。例如，物联网平台在设计开发、通信交互、访问控制等方面缺乏统一的标准，设备的内部和外部运行环境缺乏有效保护，已有的解决方案中存在应用面窄、自动化不足等缺点。因此，面对不断出现的安全威胁，仍需要深入研究更全面可靠的检测和防御方案。

本文基于 2016 年—2020 年网络安全会议（ACM CCS、USENIX Security、NDSS、IEEE S&P）中发表的物联网安全相关文献，以及其他在物联网安全研究方面的高水平工作进行了总结分析。从“威胁、检测、防御”的角度对104 篇相关文献进行分析与整理，并围绕相应主题进行深入讨论。各类别的文献数量统计结果如图1 所示，部分文献在发现威胁的同时，建立了有效的检测或防御方案，因此同时计入2 个类别中。从图1 可看出，在威胁方面，近5 年文献数量总体持续增加，说明近有新的威胁被不断发现，本文对这些威胁进行了分类，并分析了它们的成因和危害；在检测和防御方面，后3 年数量较前两年有显著增加，说明针对已知威胁有更多的对抗方案被提出，本文也对这些检测和防御方案的技术特点进行了分析与总结。

图1 2016 年—2020 年物联网安全代表性研究统计

虽然当前已有面向物联网安全的综述研究[5-7]，但是专门对现有研究工作提出的攻击和检测防御方案的总结分析较少，本文紧紧围绕“威胁、检测、防御”3 个主题，覆盖近5 年物联网安全研究工作的主要方向，同时深入分析各类威胁的成因和危害，以及对应的检测和防御机制的技术类型和效果。本文的主要贡献如下：1) 系统总结近5 年物联网安全研究中发现的主要安全威胁，展示这些威胁产生的成因和危害；2) 深入分析对抗这些安全威胁的主要检测和防御方案，展示这些方案的技术类型和效果；3) 基于威胁、检测和防御3 个方面的分析来揭示物联网未来发展过程中将面临的主要安全挑战，并指出物联网安全研究下一步的方向。

2 背景介绍

本节对物联网系统的基本架构，以及架构各层对应的主要研究对象进行介绍，如图2 所示。物联网系统的一般架构主要分为感知层、网络层、应用层3 个部分。

图2 物联网系统基本架构与研究对象

感知层对应的是各类物联网设备。设备通过传感器实时收集应用场景信息并发送给应用层，或接收应用层指令并执行相应动作。设备的内部架构可以分为硬件层、系统层、用户层。其中，硬件层包括支持设备功能的各种硬件模组（如网络模组、传感器模组等）、处理器、外围电路等；系统层装载了固件程序，其中包括操作系统和应用程序，负责设备功能的实现；用户层主要向用户提供展示数据和接收输入的操作接口。

网络层对应的是设备之间，以及设备、云平台、手机App 这三类实体之间的通信。设备之间可以通过ZigBee、Z-Wave 等轻量级协议形成自组网络（如工业设备网络、无人机集群）；设备也可以经路由器连接后形成局域网（如智能家居网络）。设备连接路由器有2 种形式：一是直接通过Wi-Fi 连接；二是通过ZigBee、Z-Wave 等协议与网关设备（如hub）连接后，再经网关通过Wi-Fi 与路由器通信。

实体之间通信分为3 种类型：1) 设备与App通信，设备既可以通过蓝牙直接连接手机（如可穿戴设备、车载系统网络），也可以通过局域网Wi-Fi与手机通信（如智能家居网络）；2) 设备与云平台通信，设备依靠路由器转发请求和接收响应，而路由器与云平台的通信主要由传统TCP/IP 网络架构实现；3) 手机与云平台通信：手机App 可以通过4G/5G 网络或局域网Wi-Fi 连接云平台。

应用层对应的主要是云平台和手机App。云平台主要由厂商在云端部署的各类应用服务组成，负责管理设备和用户，对设备收集的数据进行处理，或向设备发送远程控制命令。根据云平台提供的功能，可以将其分为设备接入平台、服务联动平台、语音助手平台3 种。设备接入平台提供了实际的设备接入和管理功能，如Samsung SmartThings、Google Home、Philips Hue、小米米家等；服务联动平台并没有连接真实的设备，而是将其他平台的功能连接起来，提供“条件-动作”自动执行规则服务，如IFTTT 平台等；语音助手平台通过智能音箱向用户提供语音控制服务，用户发出的语音命令经语音平台处理后可以与其他控制设备的功能或服务连接到一起，如Amazon Alexa 等。另外，不同云平台之间也可以在授权后，通过互相调用API（application programming interface）执行设备控制。手机App 可看作云平台向用户提供的控制终端，主要用于向用户提供设备相关的功能界面，可以直观展示设备状态，或者执行控制命令。

3 研究现状

3.1 安全威胁

传统安全问题在物联网系统中具有特殊的表现形式，而物联网系统由于自身特性也引入了新的威胁类型。本节进一步从云平台、通信、设备等角度将研究发现的安全威胁归为8 类，分别阐述了各类安全威胁的漏洞成因和主要危害，分类结果如表1 所示。

表1 各类安全威胁的漏洞成因和主要危害

3.1.1 云平台访问控制缺陷

访问控制是云平台正常运转的重要前提，物联网云平台连接了大量与人类紧密联系的设备，如果身份验证或权限管理出现漏洞，云平台将转变成为攻击者的强大武器。现有研究显示，云平台的访问控制问题突出[8]，本节根据授权类型将权限管理的威胁分为平台内和平台间2 种。

首先，部分平台对内部应用或服务的权限管理设计存在漏洞。SmartThings 和IFTTT 是全球范围内广受欢迎的云平台，拥有广大的用户群体，且连接了海量的设备和服务，但是Fernandes 等[9-10]发现这2 家平台都对连接设备的应用或服务采取了粗粒度的权限划分方式，应用或服务可以获得其申请范围之外的权限，导致攻击者可以利用这种缺陷对他人的设备轻易发起信息监听或越权控制。

其次，云平台之间进行相互授权的过程中也存在设计漏洞。当前大部分云平台都允许用户将注册在其他厂商平台下的设备，经过“云云授权”后与自家平台联接（例如，可以将小京鱼平台下的设备联接到小米米家平台，通过米家App 控制小京鱼平台的设备）。然而，在目前缺乏统一的平台间授权标准的情况下，即使厂商在自身范围内做好了安全审核，在权限交接时可能会因为平台之间不对称的授权要求而暴露新的漏洞。Yuan 等[11]针对这类安全问题进行了系统性研究，在多家全球知名的云平台之间的授权过程中都发现了安全漏洞，这些安全漏洞导致攻击者可以通过代理平台绕过设备自身平台的保护机制，对设备发起非法访问。

3.1.2 云平台恶意应用

云平台提供了面向设备的各类应用，用户通过应用可以实现丰富的控制功能。但是，目前云平台对应用的安全审查不够完善，导致恶意应用混杂其中，本节介绍云平台恶意应用的几种形式。

部分云平台对用户来说是完全封闭的，用户无法获取应用的逻辑或代码，只能安装云平台封装好的应用或自动执行规则。部分平台虽然对用户隐藏底层的运行机制，但会开放一系列基础设计功能（如API 或编程框架）给用户，用户可以自己编写和发布应用。这类平台包括SmartThings、IFTTT、Alexa 等，它们虽然提供了更加丰富和灵活的应用生态，但是为攻击者提供了实现恶意应用的机会。

关于SmartThings平台的多项研究[9,12-14]都证明该平台的应用开放特性和不完善的审核机制极易引入恶意应用，已公开发布的应用（如SmartThings中的SmartApp）中，近2/3 都具有泄露设备隐私的风险[12]。在IFTTT 平台中，Bastys 等[15]发现市场中近30%的服务（如IFTTT 中的Applet）存在安全隐患，攻击者在代码中嵌入的恶意链接会将用户输入的隐私信息发送到攻击者服务器。此外，恶意代码在语音平台中的表现形式是带有恶意意图的Skill[4]，攻击者可以上传恶意的Skill[16-17]，在用户不易察觉的情况下暗中劫持正常的语音命令或替换真实Skill 的功能。

3.1.3 云平台实体和应用交互漏洞

云平台、手机App、设备三类实体之间的交互是物联网云平台区别于传统云服务的重要特性，然而复杂的交互过程也带来了安全挑战。本节将交互漏洞分为实体间交互和应用间交互2 种类型。

在用户访问设备的过程中，设备可能经历注册、绑定、使用、解绑、重置等阶段，在各个阶段中，云平台、手机App、设备这三类实体需要进行信息交互和状态转换，并且各实体的交互和转换次序必须遵照既定模型进行，如图3 所示，任一实体对交互模型的违背都会破坏模型的完整性。

图3 云平台三类实体交互模型

Zhou 等[18]和Chen 等[19]分别对多家全球知名厂商平台的实体交互过程进行检测后发现，厂商对功能的实现并未严格遵守通信模型的规定，例如，用户解除云平台中的设备绑定关系后，设备不会回退到初始状态，而是依然与云平台保持连接，所以攻击者可以在此时对该设备发起绑定请求实现远程劫持。

云平台应用或服务的交互情形有2 种，一是多个应用控制相同的设备，此时设备是应用的“交点”；二是多个应用的触发条件或执行动作重合，此时条件或动作是应用的“交点”。当多个应用在同一场景下被使用时，它们在“交点”上可能产生不可预期的执行冲突，而这种冲突会改变应用或服务的执行结果[13-14,20]。例如，智能家居场景中部署了2 条服务，分别为“如果检测到烟雾，则打开水阀”和“如果检测到漏水，则关闭水阀”，当厨房发生火灾时，烟雾传感器命令水阀打开，同时开启屋顶喷水器（第一条服务生效），但是漏水传感器检测到水流后命令水阀关闭（第二条服务生效），最终这种冲突将导致自动灭火的规则失效，引起人身财产损失。值得注意的是，这种威胁不一定来自恶意应用，也可能是由多个良性应用同时执行产生冲突造成的，由于服务规则间交互的复杂性，云平台依靠传统的审核机制难以发现这种问题。

3.1.4 通信协议漏洞

首先是物联网常用协议，如MQTT（message queuing telemetry transport）、CoAP、ZigBee、低功耗蓝牙等。这类协议虽然不是专门为物联网系统定制设计的，但是由于其适配于低功耗设备和低带宽需求的特性而受到众多物联网系统的青睐，因此在物联网系统中有较高的使用率，但是其本身并非为存在对抗性的应用场景所设计，因此缺乏内建的安全机制，厂商在应用和实现这些协议时容易忽略对安全属性的考虑。Jia 等[21]在多家全球知名厂商的物联网平台中，都发现其对MQTT 协议的实现存在缺陷，被攻击者利用后可能引发大规模分布式拒绝服务、远程设备劫持、用户隐私窃取等攻击。Cao等[22]发现基于ZigBee 的ghost 攻击会造成设备能量过度消耗，引发拒绝服务和重放攻击等威胁。低功耗蓝牙是当前可穿戴设备与手机App 通信的主要渠道，但是该协议在应用过程中被发现隐私泄露[23-24]、设备劫持[25]等威胁。

其次是物联网私有协议。这类协议是指厂商定制设计的协议类型，通常只适用于其平台下设备的通信，且一般不对外开放实现细节。但是，攻击者通过逆向工程仍可以获取通信细节，如果厂商对私有协议的设计存在缺陷，也可能被攻击者利用后发起攻击。当前研究[18-19,26-27]已证明全球多家知名物联网厂商的私有协议在被成功解析后，其关于设备认证与授权检查等方面的漏洞将立即暴露在攻击者眼前。

3.1.5 通信流量侧信道信息泄露

物联网系统中规模庞大和种类丰富的网络流量为侧信道攻击的实施提供了可行性条件，同时物联网系统的通信过程具有区别于其他系统的内在特性，例如，设备只被分配简单的任务和操作，只能发起有限的服务请求，并采用固定的协议和传输模式进行通信，所以物联网的通信流量具有明显的可识别特征。虽然有各类加密机制应用在流量信息保护中，但是仍然不能防止攻击者通过侧信道特征获得设备和用户相关的敏感信息。

表2 对几种侧信道攻击方法进行了对比。从表2可以看出，协议头部特征（如端口号、负载大小、DNS 查询目标等）容易提取，但是能获取的设备知识较少，例如，只能得知目标设备或对象是否存在，或者获知目标设备类型，在简单的交互环境中可以实现信息提取。虽然信号强度、方向、包长、时间等特征提取后需要采用特定的统计学习方法进行分析，但是可以获得较多关于的设备和活动信息。

表2 侧信道攻击方法对比

3.1.6 设备固件漏洞

固件是运行在设备中的二进制程序，负责管理设备中的硬件外设以及实现设备的应用功能。固件不同于传统的个人计算机或手机程序拥有成熟的漏洞检测和系统保护技术，大部分固件所运行的实时操作系统中缺乏基本的安全保护措施，如DEP（data execution prevention）、ASLR（address space layout randomization）等。同时，当前缺乏对固件程序进行调试和检测的有效工具，导致大量携带漏洞的固件存在于实际产品中，攻击者利用这些漏洞可以对设备进行拒绝服务、非法操作和劫持等攻击。本节根据固件漏洞产生的原因将其分为内存漏洞和逻辑漏洞2 类。

短裙子女孩约我来这里干什么呢？和美女单独约会的美梦看来是破灭了。但一种突然而至的神秘感让我又害怕又亢奋，我决定在这里等下去，等着把这件神秘的事情弄明白。上过大学的人都懂的，在大学里如果你不谈恋爱，那么日子会像白开水一样没滋没味，除了教室就是宿舍，除了宿舍就是厕所，三点一线的单调像只穿了三个蛋蛋的糖葫芦。周五晚上学校还有免费电影的，但在我心儿突突乱跳的那一刻，什么都没有这份神秘有诱惑力了。

固件内存漏洞一般由编码或设计错误引起，会导致内存非法访问、控制流劫持等攻击，如堆栈缓冲区溢出。物联网设备固件主要由底层语言（如C语言）开发，在开发过程中会不可避免地引入编码缺陷。在硬件层面，设备的CPU 异构性、外设多样性等特点，使对固件程序开展规模化和自动化的漏洞检测十分困难。在软件层面，设备操作系统呈现碎片化，同时由于有限的硬件资源导致缺乏必要的动态防御措施，如CFI（control flow integrity）等，导致攻击者更加容易利用内存漏洞。多项研究指出，代码注入[34-36]、控制流劫持[37-38]、跨二进制模块的调用[39]是固件内存漏洞的主要成因。

固件逻辑漏洞指的是固件在认证、授权、应用功能等方面的设计或实现缺陷。与内存漏洞不同，这种漏洞不一定会引发系统崩溃，攻击者利用逻辑设计缺陷，构造特定的输入就可以使程序的正常功能发生偏移。例如，认证绕过漏洞[40]是典型的固件逻辑漏洞类型，攻击者可以通过这种漏洞绕过系统对特权指令的权限检查；在智能网络打印机固件程序中的功能设计缺陷在实际办公场景中会导致任务篡改、机密窃取等后果[41]。

3.1.7 基于语音信道的攻击

语音助手设备（如智能音箱）在物联网系统中处于控制中心的地位，用户可以通过语音助手设备来控制其他设备，所以对语音设备的攻击将会威胁受其控制的所有设备。

首先，部分攻击技术可以在语音信道中藏匿人类无法察觉但设备可以识别的语音信号。Carlini 等[42]首先展示了用于构造可被语音识别系统解释但不被人类发现的语音命令的几种方法，同时证明这些命令会在暗中窥探用户隐私和自行打开钓鱼网站。之后，多项研究发现了传播语音命令的载体，例如，将语音信号调制为人类无法识别的高频超声波信号[43]，或者将语音命令嵌入音乐中[44]；还有研究将承载语音设备的固体作为媒介，通过固体震动频率来传输语音命令[45]，以上攻击的共同特点是语音设备可以正常接收和解释这种信号，但是人类难以察觉交互过程。

另外，隐藏的语音信号在传输过程中面临传播距离和噪声影响的挑战，但这种困难被证明可以克服。例如，Roy 等[46]通过多个扬声器来分离语音信号的频带，显著增加了攻击距离。Chen 等[47]通过提取硬件结构和信道频率造成的信号失真影响因素，以此作为生成语音信号对抗样本的因子之一，可以有效克服传播中的噪声影响，提高语音信号被识别的成功率。

3.1.8 基于物联网设备的僵尸网络

物联网系统中的设备数量众多且规模庞大，其一旦被病毒、木马等恶意软件攻击，就可以组建威力巨大的僵尸网络。被病毒劫持的设备除了无法正常使用之外，组成的僵尸网络还可被攻击者当作其他恶意行为的“跳板”，为后续的大规模分布式拒绝服务攻击、恶意邮件分发等攻击做好准备。

著名的Mirai 病毒以及由其衍生出的多类变种至今仍然是工控系统设备的主要威胁[48]。例如，MadIoT[49-50]是一种面向电网系统的新型攻击，利用被控制的高功率家庭物联网设备组建僵尸网络，以此操纵电网中的电力需求，进而向电网系统发起攻击，造成局域或大规模停电事故。此外，Ronen 等[51]展示了一种利用ZigBee 协议漏洞可在物联网设备中进行大规模传播的蠕虫病毒，该病毒可在邻近的智能路灯之间进行快速传播并导致设备接受远程控制，攻击者可接管城市的路灯控制权，从而发起大规模分布式拒绝服务攻击。

3.1.9 安全威胁小结

下面对3.1 节中关于安全威胁研究的特点和不足进行总结，主要分为以下几个方面。

1) 云平台威胁影响严重，但是当前研究针对的云平台类型有限。物联网云平台在近几年中获得了巨大发展，与之相关的安全研究也不断增多，但是从近5 年的研究来看，当前研究比较依赖于平台的“开放”特性，大多数研究[9-14]都围绕SmartThings、IFTTT 等可获取应用内部逻辑的云平台，而当前更多的云平台并不对外开放内部逻辑。在开放平台中已发现的威胁可能在封闭平台中同样存在，因此对封闭平台的类似威胁研究有待探索。

2) 云平台更注重系统机密性的保护，而轻视了系统的完整性和可用性。当前大多云平台通过加密机制对外隐藏应用和通信协议的实现作为主要的安全机制，而对其他的安全因素疏于维护，如身份和权限检查、交互模型维护等。上述的多项研究[11,18-19,26]表明，在物联网系统这种存在对抗性交互的环境中，敌手有能力破解加密保护，因此云平台在授权管理、协议应用、实体交互等过程中如果存在安全漏洞，将会被敌手轻易利用，云平台一旦受到威胁，其连接的各类设备将会被攻击者全部攻破。

3) 交互逻辑漏洞是物联网系统中新出现的威胁类型。物联网系统的一个显著特点是其中功能实现过程涉及用户、云平台、设备三类实体的交互，同时云平台面向用户提供日益丰富的自动控制服务，各类服务在同一个应用场景下也会存在交互。这些交互在实现之初难以准确判定其中是否存在设计缺陷，甚至导致安全隐患[13-14,18-20]。随着物联网系统应用功能不断提升，交互类型不断复杂化，交互过程中的逻辑漏洞是值得深入研究的方向。

4) 设备固件漏洞仍然是设备遭受威胁的主要因素。由于物联网设备的数量庞大，固件漏洞被利用后可以快速传播，造成更大规模的威胁[3,48]。随着设备硬件性能不断提升，固件包含的功能愈加丰富，内存漏洞的影响仍然是设备面临的主要安全威胁[34-35,37-39]。但是与内存漏洞相比，逻辑漏洞更难发现，而且攻击者利用逻辑漏洞可以实现更加隐秘却更具危害的威胁[40]，因此如何进一步提升逻辑漏洞检测能力是值得后续研究的方向。

5) 针对语音设备的攻击是物联网系统特有的威胁类型。基于语音信道的控制方式极大地提升了用户访问设备的效率，然而语音信道也引入了新的攻击，一方面是基于语音平台的恶意应用[16-17]，另一方面是利用语音信号的敏感性实施的隐藏语音信号攻击[42-44]，由于语音助手设备在应用场景中的核心地位，基于语音控制的功能越来越丰富，针对这类威胁的研究仍然是研究人员关注的重点。

由此可见，当前物联网系统面临的威胁类型种类繁多，且与物联网特性紧密相关，对这些新型威胁进行检测和防御是未来研究的必然趋势。

3.2 威胁检测

针对物联网应用场景中不同类型的安全威胁，部分研究提出了针对性的检测方案。本文对检测的定义是及时发现物联网系统中潜在或已出现的攻击，在危害产生或扩大之前进行分析或处理。本节根据检测面向的威胁类型和技术原理，将检测方案分为6 种不同的类型，其对比如表3 所示。

表3 威胁检测方案对比

3.2.1 云平台恶意应用检测

检测云平台应用的主要思想是提供一种独立于平台审核机制的方法，判断发布在市场中的应用是否会出现有威胁的运行状态，或者出现功能声明之外的运行结果，从而判定该应用是否具有“恶意”性质。

首先，对于SmartThings 和IFTTT 平台来说，其中恶意应用或服务引发的典型后果之一是隐私信息泄露，而且这2 种平台都可以获得应用代码或API 权限，因此对这2 种平台可以采用基于数据流分析的检测方案，即追踪敏感数据在应用中的传递过程来识别应用是否将携带敏感信息的数据在未经用户授权的情况下发送给外部不可信的目标[12,15,52-53]。例如，在SmartThings 平台中，Celik等[12]在应用中自动定位从产生敏感数据的函数到网络接口函数的数据流，识别应用是否将敏感数据通过网络向外发送。在IFTTT 平台中，Bastys 等[15]对每个应用的Trigger 和Action 打上敏感标签，然后检查每个Applet 的Trigger-Action 序列是否违背隐私约束规则。

其次，对于语音平台，由于无法获取Skill 功能的实现细节，因此当前研究主要采用黑盒测试方案，即通过构造不同形式的Skill 语音命令输入，来检查执行结果是否产生偏离正常功能的行为。这种方案面临的首要挑战是如何自动构造语音命令输入，Zhang 等[16]通过将Skill 名称转换为语音表达形式，然后对比不同Skill 的名称是否具有相似的发音形式来查找可能引起语音劫持攻击的恶意Skill；Guo 等[4]进一步提出了一种基于语法和语义理解技术，可以自动与平台进行语音交互。此外，对于平台返回的命令执行结果，Guo 等[4]的方案是基于安全策略检测其中是否包含侵犯用户隐私的行为；Zhang 等[54]设计了一种针对语音识别系统中的NLU（natural language understanding）模块的检测方案，可以发现具有不良意图的Skill 命令。

3.2.2 云平台实体和应用交互漏洞检测

当前研究中对交互漏洞的检测大多基于模型检测的方法，主要思想是先对实体或应用的交互过程建模，然后将正常模型和实际运行状态进行对比，检测其中出现的异常。

首先是对实体交互漏洞的检测，采用的模型主要是有限状态机，主要通过逆向分析实体的交互过程得到各实体状态的正常转换流程，及其组合而成的三元组状态集合，由此构成了实体的正常交互模型。由于攻击将导致实体出现异常状态转换，或出现异常的三元组集合，因此可根据标准交互模型与实体的实时状态进行对比来检测是否出现异常的交互。Zhou 等[18]和Chen 等[19]采用了上述的思路，通过对多家全球知名物联网云平台的三方交互过程建立实体交互模型和检测，最终在多家平台中验证了漏洞的存在，该漏洞可影响上亿台设备。

其次是对应用或服务交互漏洞的检测，由于云平台应用具有不同的实现方式，所以建立的模型也有不同的特点，表4 对部分方案的建模方式和检测效果等进行了对比。

表4 应用或服务交互漏洞检测方案对比

3.2.3 基于静态分析的固件漏洞检测

固件静态分析是指不运行固件程序，通过符号执行、污点分析等技术分析二进制文件的代码结构或逻辑关系，检测其中存在的内存漏洞或逻辑漏洞。

符号执行是固件分析中常用的技术[56-57]，核心思想是将程序输入变成符号，程序执行结束后可以得到与每条执行路径对应的符号表达式和约束条件，对约束条件进行求解即可得到满足路径需求的输入值。例如，Subramanyan 等[56]采用了一种专门的形式来描述固件中关于机密性和完整性的信息流属性，然后通过符号执行检查固件中的执行路径是否违背了属性的安全约定。污点分析的主要思想是在程序中建立数据依赖关系图，通过污点传播算法追踪从敏感数据源到数据聚集点的路径，并检测路径中是否存在安全问题[39-40,58]。例如，Karonte[39]基于二进制文件之间交互通常通过一组有限的进程间通信模式集合进行的思想，通过追踪进程间通信的数据传播过程实现了跨文件的污点分析。基于二进制相似性检测的思想是提取已知漏洞在二进制文件中的特征，然后在新的二进制文件中进行匹配查找以定位漏洞[35,59-60]。例如，Feng 等[60]借鉴了计算机视觉技术对图像处理的思路，将提取到的程序控制流图转换为数字特征向量，从而大大降低了特征维度，提高了匹配算法的效率。

3.2.4 基于动态分析的固件漏洞检测

固件动态分析通过获取程序运行的实时状态可以更加准确地发现漏洞，当前研究大多通过将固件程序加载到QEMU 等仿真软件中，在脱离硬件的情况下模拟固件的功能运行，再结合模糊测试等技术检测漏洞。

这种方法对基于Linux 内核且具有完整操作系统功能的固件类型进行仿真运行的成功率较高。例如，FIRMADYNE[61]和FIRM-AFL[62]可以对大部分基于Linux 内核的固件进行全系统仿真运行。但是对于其他基于实时操作系统的固件，或没有操作系统的“裸机”固件（即应用程序直接与硬件交互而不需要中间的操作系统）来说，这种方案难以应用。主要原因是：这种固件没有统一的文件格式导致难以加载，部分固件被加密导致难以提取核心代码，各种硬件组件和外设的输入输出信息难以获取。

基于以上挑战，部分研究实现了固件部分仿真[40,63-64]，主要思想是从固件中分离出与检测目标相关的代码执行路径，只对这部分路径进行仿真执行。例如，FIoT[63]从容易触发内存越界访问的汇聚点函数出发，采用反向程序切片方法得到从数据输入源到达汇聚点函数的路径，结合符号执行和模糊测试检测该路径执行过程中是否存在内存漏洞。

部分研究克服了设备硬件与固件的耦合性和底层架构的差异性等困难，实现了固件全仿真[65-68]。例如，uEmu[68]通过基于符号执行的路径约束和程序动态运行状态来推断固件运行过程中期望的输入并形成外设反馈知识库，借助此知识库可动态引导程序执行过程，以此实现不需要先验知识和原始硬件环境，即可对固件程序进行全系统仿真。

3.2.5 基于手机App 的固件漏洞检测

部分物联网厂商向用户提供了手机App 作为设备控制终端，App 中包含了与设备通信和功能相关的逻辑和数据。利用这种App 与设备之间的关联性，部分研究人员在不分析设备和固件的前提下，通过手机App 来检测固件中的漏洞。

由于现阶段实现物联网设备全系统仿真较困难并且难以直接从设备端定位数据输入，IoTFuzzer[69]和DIANE[70]转换思路，将App 看作设备的输入接口，将发向设备的请求参数看作可变异的种子数据，首先在App 中自动定位参数的数据源或处理函数；然后对参数值进行变异，通过App 的原始业务逻辑将变异数据发向设备；最后动态观察真实设备的崩溃信息，以快速检测固件中的内存漏洞。Zuo 等[71]发现从App 中可以提取设备UUID（universally unique identifier）信息，该信息可在蓝牙广播中识别设备，同时从App 中可以发现当前采用的蓝牙认证模式是否存在缺陷，攻击者结合以上条件可以通过分析App 对周围的蓝牙设备发起攻击。此外，设备厂商往往会复用相同的开发组件，因此组件中的漏洞将出现在不同的设备中，而这种相似性甚至会通过App 表现出来，因此通过比较不同设备在App 上的相似性就可以检测设备是否存在漏洞[72]。

3.2.6 基于侧信道的设备异常检测

受到攻击的设备除了内部功能受到影响之外，其外在的各类侧信道特征也会表现出异常，因此可以利用此特点进行设备的异常检测。

首先，设备与网络交互过程中产生的流量可以反映设备内部的行为，所以可以通过提取流量特征来检测设备的状态。一方面，可以提取流量中未加密的头部信息识别异常设备[73-75]。例如，Yu 等[74]基于设备通信中常见的广播和多播协议，将协议特征看作设备整体特征的一种视图，然后基于多视图学习算法进行设备签名，可以在具有大量设备的复杂环境中准确识别异常或伪造的设备。另一方面，可以提取加密流量的统计特征，如数据包长度、时间戳等。Zhang 等[75]利用ZigBee 和Z-Wave 协议的流量特征设计了识别SmartThings 平台设备行为系统，可以通过流量判断设备是否出现异常行为。

其次，设备工作过程中表现出的外在物理特征，如电量、电压、速度、重力、方向等，也可以反映设备的运行状态，部分研究基于物理特征实现设备异常检测[76-78]。例如，Choi 等[78]对无人机和地面探测器提取控制时的设备参数、物理运动数值、底层控制算法等数据作为正常运行标准，任何偏离标准的微小偏差都被视为异常，以此检测来自物理或网络的攻击。

此外，有部分研究基于邻近的设备或传感器对于活动发生时的物理环境感知应具有上下文一致性这一特点，将邻近设备的状态和动作数据作为特征进行恶意行为识别[79-80]。例如，Birnbach 等[79]基于智能家居环境中多个传感器对同一事件的感知数据集合作为签名，可以检测出由于传感器故障或攻击者造成的欺骗事件。

3.2.7 威胁检测小结

下面对3.2 节中关于威胁检测研究的特点和不足进行总结，主要分为以下几个方面。

1) 云平台恶意应用检测方案存在局限性。不难看出，大部分恶意应用检测[12,15,52-53]都面向SmartThings 和IFTTT 这2 个平台。这些方案虽然获得了较好的识别效果，但是实现方案显然都要基于平台应用开发语言的特性，在其他不开放应用逻辑的云平台中难以适用。与之相对的是FlowFence[81]，该方案与具体平台特性无关，通过在平台中预先建立沙箱隔离所有敏感操作，平台应用必须通过沙箱定义的接口才能访问敏感数据，以此隔离应用中所有可能产生隐私泄露的行为，但是该方案的应用需要高度定制化的系统支持。

2) 交互逻辑漏洞的检测仍然面临挑战。对三类实体交互漏洞检测的研究[18-19]探索了面向“黑盒”平台进行漏洞检测的方案，取得了较好的检测效果，但是不难看出，其中的建模过程需要大量人工分析，而且当前云平台对通信过程的保密机制越来越严格，例如，双向证书验证机制对研究中采用的解密通信方法带来了极大挑战，因此建立有效的交互过程建模方案是值得探索的方向。

3) 固件分析面临的共同问题是如何获取固件和加载固件。现有研究中提出了可以通过网站下载、截获OTA（over the air）更新、从App 提取、从设备硬件调试接口提取等方式获取固件，但是目前大多数物联网厂商对固件的保护越来越严格，不提供公开下载链接，或者消除了硬件调试接口，或者对更新的固件进行加密，因此可以获取固件的方式越来越少。对于固件加载，部分研究通过人工分析建立固件格式的数据库，但是此方法难以大规模扩展，而Wen 等[82]提出了一种通过绝对指针自动定位固件基址的方案，可以有效提高加载效率，但是该方案的加载成功率也会受到绝对指针数量不足的影响。

4) 3 种固件漏洞检测方案（静态、动态、App）在真实设备固件检测中各有不足。首先，静态分析中常用的符号执行和污点分析技术分别面临路径爆炸和过污染的挑战，因此在实际应用中需要在使用这些技术前针对分析目标缩减问题的求解空间[56-58]。对基于二进制相似性比较的漏洞检测方法来说，二进制特征的提取严重依赖于构建代码的编译环境[59-60]，编译器中不同的优化和混淆措施会对生成的二进制代码产生影响，从而降低识别的准确率。其次，在动态分析中，固件的仿真效果受限于如何处理各种不同类型的硬件组件属性，以及如何兼容不同的底层架构[65-68]。再次，基于App 的固件漏洞检测[69-70]要求设备必须具有对应的App 控制端，App 与设备的功能实现具有密切关系，而且此种方案对种子数据的生成和变异完全依赖于App的内部逻辑，因此只能发现固件是否存在会引发系统崩溃的漏洞，对于漏洞的具体原因和位置还需要人工验证。

5) 基于侧信道特征的检测方案的最大优点是可以通过外部手段发现设备异常，但其检测效果受限于应用场景中的特征选择和采用的学习算法，例如，流量特征容易受到信号强弱[74]、协议类型和通信模式的影响[75]，物理特征严重受限于物理环境因素[76-77]，而上下文特征的提取则要求检测目标周围必须存在能够提供丰富特征的其他设备[79]。

3.3 威胁防御

针对物联网应用场景中不同类型的安全威胁，部分研究提出了针对性的防御方案，本文对防御的定义是在威胁出现前就实施阻止措施，直接避免危害产生。本节根据防御面向的威胁类型和技术原理，将威胁防御方案分为5 种不同的类型，其对比如表5 所示。

表5 不同威胁防御方案对比

3.3.1 细粒度的云平台访问控制

物联网云平台访问控制问题产生的原因主要是云平台实现功能时未能遵循最小权限原则，因此当前研究利用云平台的特性设计了细粒度的访问控制机制。

对于SmartThings 平台，当前研究从SmartApp中提取应用运行过程中实时的上下文，为当前操作是否符合访问控制策略提供细粒度的参考信息。例如，ContextIoT[83]通过提取SmartApp 内部的执行路径、数据依赖关系、实时变量值、环境参数等信息来表示应用执行操作时的上下文信息，然后在操作执行前主动征求用户授权许可，只有获得用户授权的操作才可以继续执行。SmartAuth[84]通过自然语言处理技术提取SmartApp 对功能的文本说明中关于操作的信息，再通过污点分析技术在应用运行时获取真实操作，对比真实操作与文本说明是否一致，若不一致则主动通知用户以征求授权。这2 种方案在实际应用中都可以准确防止恶意应用产生的隐私泄露，但是也不可避免地增加了用户操作。

对于IFTTT 中基于访问令牌联动的服务规则，Fernandes 等[10]针对令牌管理模式中存在的问题提出了一种权限管理的优化方案，该方案引入应用代理方，并使用权限粒度更小的“规则令牌”将集中式的权限管理模式分散为以应用代理为单位的分布式管理，可以有效解决集中式管理和粗粒度令牌的问题。

此外，还有部分研究面向物联网中特殊应用场景，基于其他领域的理论，如SDN（software defined network）、智能手机访问控制等，提出了新的访问控制模型[85-87]，但其实现需要特殊架构支持。

3.3.2 安全的通信协议

为了保障物联网系统通信安全，在物联网常用协议中需要增加稳健的安全机制，然而协议的制定和改进是多方参与且长期演进的过程，因此更重要的是协议应用方必须在业务逻辑中对通信实体的身份和权限实施严格检查。例如，针对MQTT 协议模型中缺失的安全属性，应增加通信会话的管理机制、面向消息的访问控制机制，以及限制通配符的功能范围[21]；针对ZigBee 协议的内在缺陷，应增强设备在加入网络和正常通信这2 个阶段的加密级别[88]。此外，也有部分研究基于物联网系统特性设计了安全的通信协议[89-90]。例如，Alshahrani 等[89]提出了一种基于ZigBee 通信的设备间进行互相认证和密钥交换的模型，可以增强ZigBee 协议在对抗性环境中应用时的稳健性。

还有部分研究面向设备近距离通信设计了新型的安全配对协议[91-94]，可以克服传统配对协议存在密钥信息易被窃取、需要人工参与等问题。例如，Han 等[92]基于邻近的智能设备在相同时间周期内对物理活动的感知具有一致性这一特征，利用相同时间周期内的物理感知参数来生成对称密钥，可有效对抗设备伪装和中间人攻击。Jin 等[93]利用射频信号噪声在不同介质（如人体表面和空气）中传播时产生的信号特征具有高度随机性和不可预测性的特点，设计了针对可穿戴设备的新型配对方案。

3.3.3 流量特征隐藏

为了应对形式多样的通信流量侧信道分析，部分研究关注如何隐藏流量特征。流量特征推理主要是提取流量中的头部特征和统计特征，所以对应的防御方案是消除这2 种特征与设备和活动的对应关系。

对于头部特征，主要目标是在不影响流量转发和不改变负载数据的基础上进行头部信息的再次封装，令攻击者无法获得有意义的头部信息。例如，通过DNS 加密技术阻止对网络请求目标的分析[30]；通过隧道转发技术将设备与云服务之间的通信转换为VPN 节点之间的通信，间接阻止了对设备的识别和行为推理[33,75]。对于统计特征，主要目标是在不破坏正常功能的前提下，改变流量的整体特征。例如，在正常通信过程中注入欺骗流量妨碍窃听者对真实设备和活动的识别[32]；或采用流量塑形技术，通过增加发送时延或注入无关流量来降低或提高单位时间内的通信速率，改变流量传输曲线的形状，以混淆攻击者对行为的提取[32,95-96]。

3.3.4 基于可信计算的固件安全防护机制

物联网设备内在的软硬件资源受限是导致固件漏洞的主要原因之一，因此部分研究关注如何基于有限条件构建可信的固件运行环境。

首先，考虑将传统安全机制应用于固件程序，增强固件本身的防护性能。一方面，对固件程序组件权限和内存地址空间实行分离机制。针对物联网设备的实时操作系统或“裸机”系统中没有内存或数据隔离的缺点，部分研究将固件划分为不同组件以实施最小权限隔离，如EPOXY[34]、MINION[97]、ACES（automatic compartments for embedded system）[98]等。另一方面，对固件程序实施控制流完整性保护，确保函数返回地址完整性，以应对控制流劫持攻击，如μRAI[37]、Silhouette[38]等。表6 对几种固件安全防护机制的特点和性能进行了对比。

表6 固件安全防护机制对比

其次，远程证明是对远程设备执行状态的可信性进行认证的关键技术，其主要思想是可信的远程校验方通过获取本地证明方的状态信息，来检查证明方当前是否处于可信状态。在物联网系统中，远程认证的主要目标是设备需要提供高时效且细粒度的可认证信息[99-101]。例如，C-FLAT（control-flow attestation）[99]将证明方的信息细化到程序的控制流层面上，向校验方提供细粒度的程序执行路径信息以判断程序控制流完整性是否被破坏。DIAT（data integrity attestation）[101]设计了面向自动协作网络（如无人机集群）的认证方案，将软件分解为不同模块，证明方发送数据时还需发送数据在模块中的生成和处理过程信息，校验方以此检测数据的正确性。

3.3.5 语音攻击防御

针对隐藏在语音信道的各种媒介中，且用户无法察觉的恶意语音攻击样本，部分研究提出了对应的防御方案，本节分析了这些方案的原理和不足。

1) 在语音设备的交互过程中增加基于安全提示和语音确认的交互模式，用户需要对敏感操作进行主动确认来提高安全性[42]，但是这种方法会带来额外的可用性开销，且确认操作容易被用户忽略。2) 通过添加专用硬件模块对具有特殊信号特征的语音信号（如高频超声波）进行过滤[43]，或者物理隔断语音设备与桌面等硬件媒介的直接接触[45]，但是前者需要特殊硬件支持，后者为语音设备的可用性增加了负担。3) 通过增加噪声干扰或降低输入音频的采样频率，影响语音识别系统对恶意命令的识别率[44]，但是这种方案也会影响正常语音的识别率。4) 通过机器学习算法实现声纹识别区分人类和机器生成的语音[42-43,45]，但是这将使语音识别系统产生额外运行开销。

另外，由于人工生成的语音命令缺少了人类在现场说话引起的无线信号干扰，因此可以利用这个特征来区分隐藏语音命令。例如，Meng 等[102]利用人类发音时引起的Wi-Fi 信道状态信息变化模式和语音信号的关联，可以准确区分生成的恶意语音信号与真实人声。但是该方案目前依赖Wi-Fi 信号覆盖度较强的环境，且识别过程对信号波动强度敏感，如果发音者距离信号接收天线过远则会由于捕捉不到信号扰动而无法进行识别。

3.3.6 威胁防御小结

下面对3.3 节中关于威胁防御研究的特点和不足进行总结，主要分为以下几个方面。

1) 云平台访问控制的适用面有限。相较于传统的云服务，在物联网云平台中，用户访问设备的过程具有更加复杂的关系，例如，多个用户可以对同一个设备进行共享或交互，因此需要精准且高效的访问控制机制。当前研究提出的新型访问控制方案虽然解决了已知的授权管理问题[10,83-84]，但目前只能面向有限云平台。值得一提的是，Shezan 等[103]基于迁移学习思想提出了一种可在不同平台之间进行权限知识迁移的权限管理模型，在建立新平台的权限模型时，可以直接采用来自其他平台的权限管理规则。

2) 保障通信协议安全仍面临困难。一方面，在物联网系统这种存在对抗性的环境中建立安全且适配的通信协议是一个需要多方参与且长期演进的过程，此过程中更重要的是协议应用方应根据应用场景在业务逻辑中增加协议当前不具备的安全机制，以保障通信安全。另一方面，当前提出的设备安全配对协议均建立在“物理邻近即安全”的假设之上[91-93]，而物联网中复杂的设备应用环境是对这个假设的最大挑战，由于邻近的设备也可能是伪装的恶意设备，因此对设备的认证是配对协议需要重点考虑的问题。

3) 固件的安全防护机制需要进一步提升。设备固件受限于物联网设备有限资源的特性而无法直接应用传统的软件安全保护机制，因此现有研究[37-38,98]通过一些硬件辅助方案（如MPU 或者最新的ARMv8 TrustZone）来实现特殊的系统防御，如数据执行保护、控制流完整性保护等措施。但一方面这些硬件组件在现有设备上不一定存在，另一方面在现有的程序中配置和使用这些方案也需要投入过高的人工成本，此外，可能引入过多的功耗和时延，而物联网设备往往对功耗和时延有着更高的要求，因此这些方案的性能和适用面也需要进一步提升。

4) 面向语音攻击的防御措施不够完善。现有的语音攻击防御方案虽然在实际研究中被证明有效[42-45]，但是不难看出各方案在实现时都面临可用性和设备性能的额外开销。综合来看，目前对于藏匿在语音信道中的恶意命令没有完善的防御方法，这也使面向语音攻击的防御成为后续研究的热点。

4 挑战与机遇

本节基于第3 节中对安全威胁，以及检测和防御方案的分析，提出当前面临的研究挑战和未来研究机遇。图4 中展示了挑战和机遇的对应关系。

图4 挑战与机遇的对应关系

4.1 当前面临的主要挑战

4.1.1 不完善的隐私保护

物联网设备与人类生活密切相关，通过设备感知的信息可以推断出人的生活习惯、行为特征等，而当前在物联网系统中存在的各类攻击可能导致设备收集的信息被窃取。从表1 可以看出，当前物联网系统中的大部分威胁都会导致隐私泄露的危害。此外，导致隐私保护不够完善的另一个重要因素是隐私信息理解问题[104]，即用户使用设备前对设备的隐私收集和使用方式不能充分了解，或者现行的隐私信息保护法案不能完全满足真实的使用需求。

4.1.2 繁多的应用形式

云平台提供的应用或服务不仅数量庞大而且种类繁多，然而当前的云平台安全审核机制难以满足安全需求。现有研究充分证明，厂商在发展新应用和维护其安全性之间存在不平衡，依靠静态分析应用的方式难以发现其中的动态特性导致的问题，而动态分析应用安全的方案匮乏，人工审核方式有一定效果，但是耗时耗力且容易出现疏漏。随着物联网应用层生态的不断发展，在发布大量应用的同时，需要高效、准确、自动化的应用安全审核机制。

4.1.3 复杂的交互模型

物联网系统功能提升的同时，系统内的交互形式也不断增多，交互过程日益复杂，不仅有应用之间的交互、设备之间的交互，更有跨平台的交互，所以对平台或设备安全性的保护不能只限于单个实体，还要考虑交互过程可能引入的风险，典型的问题是即使实体单独运行过程中的安全性得到保障，然而在与其他实体的交互过程中原有的保护机制很可能被打破。当前检测和防御方案大多通过交互行为建模来检测其中的威胁，但是由于交互模式的差异，各类模型方案只能应用于特定平台或场景，彼此之间难以复用。

4.1.4 适用性受限的解决方案

当前研究提出的威胁检测和防御方案大多针对特定的应用类型和场景，或者特定的设备结构和系统。在云平台中，恶意应用和交互逻辑漏洞检测的大部分方案基于特定平台的开发特性建立分析框架；在设备固件分析中，固件运行依赖的底层架构和底层硬件多种多样，所以只能针对特定类型的固件进行仿真。这些特点使当前研究得到的分析方案只能应用在特定的领域中，组件之间无法移植或组合，在出现新的问题时难以达到预期的效果。

4.1.5 不统一的通信标准

物联网系统的通信具有网络类型多且结构差异大的特点，由于通信过程缺乏统一的协议或授权标准，各类网络的安全约束参差不齐。同时，物联网设备有限的资源和对实时性的要求令其更适配计算量低且逻辑简单的轻量级通信协议，而当前被广泛使用的各种轻量级协议一般缺乏内建的安全机制，设备厂商应用协议时容易忽略对安全机制的实现，导致引入安全威胁。

4.2 未来研究机遇

4.2.1 隐私保护和隐私理解

在物联网发展的过程中，隐私安全问题一直是研究关注的重点。一方面是物联网应用场景中隐私信息泄露的检测和保护措施[105-106]；另一方面是对隐私理解问题的研究，如调研用户对隐私政策的使用和理解现状[107]，或当前物联网生态中的各参与方对隐私保护措施的合理性[108]，以推动物联网系统中隐私保护机制的发展。

4.2.2 复杂环境下的访问控制

物联网系统的应用环境复杂，身份认证和授权管理缺陷导致的安全漏洞体现在多个方面，当前研究提出的访问控制增强方案存在不足。因此，设计既满足物联网系统的安全需求，又能够适应物联网的低能耗和高实时性要求，同时还具有扩展性的访问控制机制是物联网未来进一步发展的实际需要。

4.2.3 基于人工智能的检测和防御方案

人工智能技术可以对设备收集的信息进行深度学习和理解，在一定程度上可以弥补现有的检测和防御技术在自动化方面的不足。例如，结合深度学习与模糊测试自动进行恶意应用检测[4]或漏洞挖掘[109]，借鉴迁移学习思想融合不同平台的检测知识[103,110]。随着物联网应用类型不断丰富，以及交互场景越来越复杂，利用人工智能技术提升威胁检测和防御方案的效果是值得继续深入研究的方向。

4.2.4 高效的固件漏洞检测方案和可信防御架构

由于设备固件中普遍存在安全漏洞，需要更加有效的方法进行检测以避免威胁在使用过程中进一步扩大。例如，在固件动态分析方面，如何实现更全面的模拟，以及与其他工具结合检测固件漏洞，仍需要更深入的研究。另外，由于设备自身硬件和软件条件的受限，大多数传统安全机制不能直接应用，如何克服这种限制在固件中实施更可信的防御架构也是需要研究的问题。

4.2.5 安全的通信协议

通信协议是物联网传输层的核心。一方面由于当前厂商在应用缺乏内建安全机制的轻量级协议时容易忽略对安全因素的考虑，因此需要高效自动的协议安全分析方案；另一方面可利用物联网区别于其他系统的特性，如三类实体交互、设备邻近等，结合应用场景设计专属物联网的安全通信协议。

5 结束语

物联网系统由于应用种类多、设备规模大、交互过程复杂等特性在发展过程中不可避免地面临各类安全威胁，对威胁的检测和防御是促进物联网正常发展的关键。本文系统整理了近5 年物联网安全研究中的代表性工作，从“威胁、检测、防御”的角度分别阐述其中的主要类型，并以此为基础分析了当前面临的挑战，以及提出未来研究机遇。随着物联网技术不断发展，相关的安全研究也必将不断深入，成为物联网发展的重要支柱。