物联网智能家居情景安全分析方法和装置

摘要

本发明公开了一种物联网智能家居情景安全分析方法和装置，用于解决物联网平台的安全分析具有监测范围的局限性，且面对多种物联网平台时分析困难的问题。其中该方法包括：对物联网应用源代码进行静态程序分析，以提取设备实体和联动规则；对物联网设备功能和物联网应用用途的描述文本进行识别，以获取物联网物理通道；基于设备实体、联动规则以及物联网物理通道构建由实体单元组成的物联网模型；在物联网模型中，利用深度优先算法检测联动规则中的触发实体单元之间是否存在通路、以及不同物联网应用的触发实体单元是否对同一功能属性或物理通道具有可达性，从而确定物联网智能家居情景的风险因素。

说明书

技术领域

本发明属于计算机技术领域，具体是关于一种物联网智能家居情景安全分析方法和装置。

背景技术

物联网平台的运行离不开对设备、环境、物资的数字化集成，每个设备具有独自的功能与状态(例如，灯泡是否打开及其亮度调节)。市场上不同物联网平台在用户规模、技术实现等方面存在差异，支持运行的设备实体也不尽相同。

随着研究的深入，物联网应用交互安全逐渐引起各方重视。目前，针对物联网平台应用的安全分析仍采用传统的软件分析手段，例如污点分析、越权分析等，而尚无面向该问题的成熟技术。这类安全风险检测技术具有检测范围的局限性，无法帮助用户发现及预防智能家居环境下的新型安全问题，例如可能导致风险场景的隐式设备交互链。

经过对八种主要物联网平台的研究(三星的SmartThings、苹果的HomeKit、亚马逊的AWS、阿里云的AliOS Things、谷歌的Google Home、OpenHAB、安卓的Android Things、IoTivity)，发现物联网应用在程序分析方面具有独特的挑战。物联网编程平台是多样化的，每个平台都具有自己指定的统一编程语言和自己的特点，这对程序分析构成挑战。例如，三星物联网平台的程序脚本由Groovy语言编写，存在反射执行调用及发出web服务请求。这些特性使得程序分析变得困难。

公开于该背景技术部分的信息仅仅旨在增加对本发明的总体背景的理解，而不应当被视为承认或以任何形式暗示该信息构成已为本领域一般技术人员所公知的现有技术。

发明内容

本发明的目的在于提供一种物联网智能家居情景安全分析方法，用于解决物联网平台的安全分析具有监测范围的局限性，且面对多种物联网平台时分析困难的问题。

为实现上述目的，本发明提供了一种物联网智能家居情景安全分析方法，包括：

对物联网应用源代码进行静态程序分析，以提取设备实体和联动规则；

对物联网设备功能和物联网应用用途的描述文本进行识别，以获取物联网物理通道；

基于所述设备实体、联动规则以及物联网物理通道构建由实体单元组成的物联网模型，其中，所述实体单元包括用户、能量、平台系统、环境通道、功能、属性、以及指令；

在所述物联网模型中，利用深度优先算法检测所述联动规则中的触发实体单元之间是否存在通路、以及不同物联网应用的触发实体单元是否对同一功能属性或所述物理通道具有可达性，从而确定物联网智能家居情景的风险因素。

一实施例中，对物联网应用源代码进行静态程序分析，以提取设备实体和联动规则，具体包括：

根据物联网应用源代码编译过程生成的抽象语法树，构建程序间控制流图；

利用静态程序分析中的可达定义算法和所述程序间控制流图对物联网应用源代码进行数据流分析，以提取设备实体和联动规则。

一实施例中，利用静态程序分析中的可达定义算法和所述程序间控制流图对物联网应用源代码进行数据流分析，具体包括：

确定所述程序间控制流图的各程序段中的变量类型；

基于所述各程序段的前置程序段和后继程序段中的变量类型，更新所述各程序段内变量信息；

获取所述各程序段中与实体单元关联的变量信息。

一实施例中，对物联网设备功能和物联网应用用途的描述文本进行识别，以获取物联网物理通道，具体包括：

利用预设新闻向量模型对所述描述文本中的词条进行向量化处理，以获得对应的词向量；

对所述词向量进行聚类，并提取选定词语作为物联网物理通道。

一实施例中，基于所述设备实体、联动规则以及物联网物理通道构建由实体单元组成的物联网模型，具体包括：

定义所述物联网模型中各实体单元之间实体关系，所述实体关系包括读操作和写操作。

一实施例中，基于所述设备实体、联动规则以及物联网物理通道构建由实体单元组成的物联网模型，具体包括：

基于所述设备实体、联动规则、物联网物理通道以及各实体单元之间的实体关系，以有限状态自动机的形式构建由实体单元组成的物联网模型。

一实施例中，在所述物联网模型中，利用深度优先算法检测所述联动规则中的触发实体单元之间是否存在通路，具体包括：

选定两个不同物联网应用联动规则内触发条件对应的第一触发实体单元和第二触发实体单元；

在所述物联网模型中，从所述第一触发实体单元开始深度优先遍历，并记录遍历路径；

判断所述遍历路径中是否存在所述第二触发实体单元；若是，

确定所述联动规则中的触发实体单元之间存在通路。

本发明还提供一种物联网智能家居情景安全分析装置，包括：

提取模块，用于对物联网应用源代码进行静态程序分析，以提取设备实体和联动规则；

识别模块，用于对物联网设备功能和物联网应用用途的描述文本进行识别，以获取物联网物理通道；

构建模块，用于基于所述设备实体、联动规则以及物联网物理通道构建由实体单元组成的物联网模型，其中，所述实体单元包括用户、能量、平台系统、环境通道、功能、属性、以及指令；

检测模块，用于在所述物联网模型中，利用深度优先算法检测所述联动规则中的触发实体单元之间是否存在通路、以及不同物联网应用的触发实体单元是否对同一功能属性或所述物理通道具有可达性，从而确定物联网智能家居情景的风险因素。

本发明还提供一种计算设备，包括：

至少一个处理器；以及

存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如上所述的方法。

本发明还提供一种机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如上所述的方法。

与现有技术相比，根据本发明的物联网智能家居情景安全分析方法，通过从物联网应用源代码中提取设备实体和联动规则、以及识别物联网设备功能和应用用途的描述文本以获取物联网物理通道，并基于此构建物联网模型，这样可以对不同物联网应用进行统一表示；而基于该物联网模型进行规则歧义和实体抢占等风险的归纳发现，可以有效地发现物联网智能家居情景中的隐式交互链，提醒可能存在的安全风险因素。

附图说明

图1是根据本发明物联网智能家居情景安全分析方法一实施例的流程图；

图2是根据本发明物联网智能家居情景安全分析方法的流程概览图；

图3是根据本发明物联网智能家居情景安全分析方法定义的物联网模型的系统版块图；

图4是根据本发明物联网智能家居情景安全分析方法验证中，自动机内实体读写关系图；

图5是根据本发明物联网智能家居情景安全分析方法验证中，物联网应用间交互链连接件图；

图6是根据本发明物联网智能家居情景安全分析方法验证中，物联网应用间交互链连接件类型图；

图7是根据本发明物联网智能家居情景安全分析方法验证中，物联网应用间物理通道连接件图；

图8是根据本发明物联网智能家居情景安全分析方法验证中，实体属性抢占的交互链图；

图9是根据本发明物联网智能家居情景安全分析方法验证中，物理通道抢占的交互链图；

图10是根据本发明物联网智能家居情景安全分析方法验证中，物联网应用间分析图；

图11是根据本发明物联网智能家居情景安全分析方法验证中，情景1应用间控制流图；

图12是根据本发明物联网智能家居情景安全分析方法验证中，情景1重现记录图；

图13是根据本发明物联网智能家居情景安全分析方法验证中，情景2应用间控制流图；

图14是根据本发明物联网智能家居情景安全分析方法验证中，情景2重现记录图；

图15是根据本发明物联网智能家居情景安全分析装置一实施例的模块图；

图16是根据本发明物联网智能家居情景安全分析设备一实施例的硬件结构图。

具体实施方式

下面结合附图，对本发明的具体实施方式进行详细描述，但应当理解本发明的保护范围并不受具体实施方式的限制。

除非另有其它明确表示，否则在整个说明书和权利要求书中，术语“包括”或其变换如“包含”或“包括有”等等将被理解为包括所陈述的元件或组成部分，而并未排除其它元件或其它组成部分。

将物联网设备引入公共和私人空间，在工业控制系统和智慧城市等领域带来巨大变革。例如，在物联网智能家居场景中，集成了智能门锁、恒温器、 WiFi摄像头和智能水壶的智能家居应用可以帮助人们在外出时与生活空间互动。但是，物联网设备交互的隐式链会将用户置于危险场景中，例如，当用户不在家时打开窗户，或在75m之外通过语音助手打开车库门。此外，数字增强空间的实现离不开大量用户隐私数据的收集与处理，一旦泄露，就可能侵犯用户的隐私。

参图1，介绍本申请物联网智能家居情景安全分析方法的一具体实施方式。在本实施方式中，该方法包括：

S11、对物联网应用源代码进行静态程序分析，以提取设备实体和联动规则。

配合参照图2，本步骤中提取的设备实体是在后构建模型步骤的基础节点，这些基础节点在本申请实施方式中被定义为实体单元。具体地，物联网平台内具有交互特性的人、设备、系统及环境的个体统称为“实体单元”，是构建物联网系统的基础元素。物联网系统具有强大而丰富的信息交互特性，这些数据在“实体单元”之间产生、交互并与更改“实体单元”具体执行状态相对应。

如图3所示，本申请实施方式中定义了七种实体单元，包括：用户、能量、平台系统、环境通道、功能、属性、指令。其具体定义如下：

用户：指参与物联网系统内信息生成、交互及指令下达的操作者；

能量：指可以搭载指令信息的能量载体，如声音、光能、电能等，该实体单元类型为信息在“环境通道”实体单元之间的传递提供解释；

平台系统：指物联网系统平台提供给用户和开发者编写程序的应用程序编写接口(API)；

环境通道：指可以传递环境信息的通道，如温度、湿度、光强等；

功能：本实施方式对系统内物联网设备的功能执行原子化表述，将设备定义为不同“功能”的集合；

属性：“功能”实体单元包含一定的状态信息，在此称为功能实体单元的属性；

指令：“功能”实体单元具备的、能够更改自身或其他实体单元状态的控制指令。

在具体的提取过程中，可以根据物联网应用源代码编译过程生成的抽象语法树，构建程序间控制流图，再利用静态程序分析中的可达定义算法和程序间控制流图对物联网应用源代码进行数据流分析，以提取设备实体和联动规则。

这里的设备实体实质是物联网运行时涉及到的设备实体，而联动规则是对应“触发-动作”的关系。

在程序间控制流图中，各程序段被按照程序执行顺序相连。因此，在具体的数据流分析中，可以先确定程序间控制流图的各程序段中的变量类型。如果与本申请实施方式中定义的实体单元相关，可以直接直接确定其变量类型，否则可以将其初始化为“对象”(Object)。

接着，根据程序间控制流图执行可达定义分析算法，基于各程序段的前置程序段和后继程序段中的变量类型，更新各程序段内的变量信息，直至不存在程序段需要继续更新变量信息为止。

最后，获取各程序段中与实体单元关联的变量信息，并能在此基础上标注程序段内的敏感信息流。而对物联网应用内敏感信息流的标注可以协助物联网平台进行应用审核工作。

S12、对物联网设备功能和物联网应用用途的描述文本进行识别，以获取物联网物理通道。

在本申请的实施方式中，将物联网设备功能原子化，因此可以用原子功能的组合来描述不同用途的设备，每个原子化的功能都有解释该功能特性的描述文本。此外，每个物联网应用也具有解释该应用用途的描述文本。

在识别过程中，可以使用自然语言处理技术对上述的两类描述文本进行分析。具体地，可以利用预设新闻向量模型对描述文本中的词条进行向量化处理，以获得对应的词向量；再对获得的词向量进行聚类，并提取选定词语作为物联网物理通道。

这里的预设新闻向量模型可以是根据实际的应用需要进行选择，一实施例中，可以是利用谷歌新闻向量模型对磁条进行向量化处理。同时，提取的选定词语可以是具有代表性的词语。

S13、基于所述设备实体、联动规则以及物联网物理通道构建由实体单元组成的物联网模型。

实体单元之间具有一定固有的交互关系(实体关系)，在本物联网模型中将此抽象定义为各实体单元之间的读操作和写操作。例如，指令的执行能修改设备属性，是写操作；具有感知功能的设备从物理通道获取信息，是读操作。利用该物联网模型，可以对不同物联网应用进行统一表示，进行应用间分析，从而发现隐式交互链。

本申请实施方式中，可以是基于设备实体、联动规则、物联网物理通道以及各实体单元之间的实体关系，以有限状态自动机的形式构建由实体单元组成的物联网模型。而设备实体是多个功能的组合，摆脱了物联网系统中设备异质性对统一分析的阻碍。

S14、在所述物联网模型中，利用深度优先算法检测所述联动规则中的触发实体单元之间是否存在通路、以及不同物联网应用的触发实体单元是否对同一功能属性或所述物理通道具有可达性，从而确定物联网智能家居情景的风险因素。

具体地，可以先选定两个不同物联网应用A、B联动规则内触发条件对应的第一触发实体单元a和第二触发实体单元b；接着，在该物联网模型中，从第一触发实体单元a开始深度优先遍历，并记录遍历路径；随后判断遍历路径中是否存在第二触发实体单元b；若是，则确定联动规则中的触发实体单元之间存在通路(本申请中定义为“规则歧义”)。

而对于不同物联网应用联动规则内触发条件对应的实体单元，如果对同一功能属性或者物理通道具有可达性，则定义为“实体抢占”。

而无论是规则歧义还是实体抢占，都可以通过本申请上述实施方式中数据提取-模型构建-风险分析的过程进行归纳发现，并且，该分析过程摆脱了物联网系统中设备异质性对统一分析的阻碍，将不同物联网应用进行统一表示，从而可以发现隐式交互链，提醒可能存在的安全风险因素。

导致物联网智能家居情景的风险因素可以归纳为：规则歧义、实体抢占、语义模糊和设备硬件实现。

规则歧义指不同应用对同一资源状态的定义具有分歧，可能导致设备状态异常或耗电异常。在以上安全分析结果的基础上，本本申请实施方式可以进一步建议用户通过协调相关应用对同一实体单元属性的数值定义进行安全预防。例如，当两个应用均有调节房间温度的能力时，协调两者加热和制冷的温度阈值，防止出现在同一时刻同时开启空调和加热器的耗电场景。

实体抢占指不同应用对同一资源的反复抢占读写，可能导致相关应用丢失该实体单元的真实状态。在以上安全分析结果的基础上，本本申请实施方式可以进一步建议用户使用多个设备搭配不同应用的部署，对应用进行隔离操作。例如，当两个或多个应用拥有同一设备的控制权时，一方面可以通过增加该种设备的数量，使得不同应用控制不同设备，达到隔离效果；另一方面可以增加应用执行场景或时间限制，让不同应用分批分时控制同一设备，达到隔离效果。

语义模糊：一些物联网平台仅要求物联网应用中可选设备具有指定功能，然而具备该功能的设备在现实中不仅只有一个类型，这种设备描述上的语义模糊降低了物联网风险分析的可靠性。可以建议相关平台增加应用可选设备的类型限制。例如，在物联网平台编程脚本的规范中强制添加对于设备类型的定义，降低实际连接设备的不确定性。

设备硬件实现：利用超声波、超声导波以及激光等手段可以发起对物联网设备的注入式攻击。可以建议物联网平台在软件层面增加设备行为关联的严格程度，设备提供商在软件层面进行注入式攻击的识别，在硬件层面采用特殊产品外壳及材质，提高注入式攻击的能量耗散，预防此类攻击。

以上的风险因素中，与“语义模糊”、“设备硬件实现”对应的责任方分别是物联网平台和设备生产商。因此，这两种风险的分析可以通过参考责任方出具的官方文档进行人工审查。

以下示出从多个角度验证本申请物联网智能家居情景安全分析方法的有效性和效率。具体地，基于Smartthings平台开发了IoTAutomaton系统。其中参考117个功能的属性与指令，308个官方API调用接口，对186个官方应用 SmartApp进行了分析。评估意在验证以下问题：

1、能否顺利地从186个物联网应用中提取“触发-动作”(trigger-action) 数据？能否跟踪物联网应用中重要变量和系统调用，为后期分析提供帮助？物联网平台内常见的物理通道有哪些？

2、是否存在程序间交互链？哪些实体或属性为交互链的产生提供了帮助？

3、是否存在程序间抢占读写实体的现象？哪些实体的属性被频繁修改的可能性更大？

4、IoTAutomaton系统的性能开销？

5、如何预防物联网应用风险？

验证过程将以数据提取-模型构建-系统性能测试-风险分析与预防-用户和能量在物联网设备运行中影响的步骤展开。具体地：

1、数据提取

1.1、静态程序分析

在全体186个应用中，用IoTAutomaton系统提取出了185个应用的“触发-动作”信息。由于程序繁杂、映射多样，未能自动化地从“simple-control”这一应用中提取信息。在对应用进行控制流分析的基础上，选择用“may-analysis”的方式进行数据流分析，这降低了代码中数据依赖对最终结果造成的困扰。在生成控制流图和数据流图的基础上，找到每一个“触发”后可能使用的全部设备及平台系统调用，并跟踪程序到达此类控制语句的路径，为相关人员的后期分析提供帮助。

1.2、物理通道

使用stanza对186个应用中的描述和117个“功能”中的描述进行分词及语义分析，提取描述语句中的关键实体(即在stanza分析结果中标注为NN 的单词)。将关键实体词语转化为词向量后，使用K-means算法进行聚类。通过以上步骤，得以将词义相近的单词聚合在一个类中。在聚类的结果中挑选含有物理通道的簇，使用该类核心的单词本身或者使用Word2vec模型中距离类心单词最近的单词作为物理通道。

最终，将提取的355个关键实体分成了14个类，识别出了9个具有实际意义的物理通道。对于每个物理通道，在表中提供了对应类中部分关键实体单词。最终结果展示如下表。

2、模型构建

将物联网平台内数据的流动抽象为不同实体间的读写操作。“功能”中的“指令”可以修改对应“属性”的状态，是写操作。当“属性”状态发生改变，同时意味着“功能”本身发生改变，该信息从“属性”流向“功能”本身，是“功能”对“属性”的读操作。对于感应器类型的“功能”，数据从物理等通道流入对应的“属性”，这是“属性”对信息来源的读操作，如图4所示。

2.1、程序间交互

在185个应用中，一共发现了6745个应用间交互链。将交互链中的连接件出现的次数自高到低地展示在图5中，按照连接件的所述类别进行归纳，如图6所示。

可以发现“指令”类的连接件出现在应用间交互链的次数最频繁(4461次)，“系统平台”类的连接件最稀少(382次)，“模式”和“物理通道”位于第二和第三(2081次、1566次)。应用的编程范式是IFTTT(IfThis Then That)，与“动作”对应的通常是“功能”所属的“指令”和系统调用，因此“指令”类的连接件出现次数最多。当应用具有更改“模式”的能力时，会影响同一组下其他应用的执行效果(其他应用可能只有在指定“模式”下才能运行)，相比于“指令”，“模式”这一要素的影响更为宽泛。“系统平台”类的连接件对应“位置”以及“应用”(App)，当用户触碰手机按键或发生位置移动时会触发应用某些行动的发生。

在图7中，展示了物理通道作为交互链连接件的次数分布。出现次数最多的是“散发物”，最少的是“加速度”。处理的185个应用中也不含有地理定位相关的设备，更不包含对于人类声音的处理模块，因此“位置”，“声音”不在结果中扮演交互链连接件的角色。

应用中包含恒温器这一设备，该设备分为加热和制冷两个模块。在实际设备构建中，为加热模块功能的原料有电、汽油或天然气。当汽油或天然气不完全燃烧时，会产生烟雾(含碳颗粒)，也会产生一氧化碳等有害气体。这些物质会触发一氧化碳和烟雾感应器，从而引起相关的“动作”。恒温器的制冷模块包含风扇和空调，它们影响环境中的空气湿度和温度，触发湿度和温度感应器，引起相关“动作”。排名第二的物理通道是光照。官方应用中包含此类应用，即根据光照强弱判断当前是白天还是黑夜，当光照发生变化时引发通知用户等行动。能够影响光照通道的实体不仅包含灯具类的设备，还包含警报器等。考虑门窗在开关的过程中会影响周围环境的光照水平，并在门的平面上具有一定的加速度，因此在门窗上安装加速度感应器可以构建配合门窗闭合的应用，这对应了图中“加速度”通道。

2.2、实体抢占

抢占修改使得相关应用无法确定该实体单元处于何种状态，这会扰乱应用的正常运行，埋下了安全隐患。应用运行过程中获取设备实体状态的方式分两种，一种是即时询问物联网平台，另一种是在应用内记录上次该程序执行指令后的设备状态。应用的代码实现中具体采取哪种方法获取设备属性由开发者和应用需求决定。

2.2.1、实体属性抢占

图8展示了185个应用中存在6770个对于实体属性抢占的交互链。值得注意的是，“capability.switch.attributes.switch”这一属性被抢占的次数显著高于其他属性。通常情况下，智能家居设备实体大多都具有“capability.switch”的属性，这意味着在真实环境下被抢占修改状态的设备实体不止含有插座，还含有自动咖啡机、WiFi电热水壶、恒温器等设备。对该属性的抢占修改可能导致家用电器的频繁启用及关闭，危害用户安全。排在前五位的属性与光照、声音和开关有联系，mode这一属性被抢占更改的频次被排在第六位。应用中包含对“模式”的制定，存在一定数量的规则，它们需要在特定“模式”下才能启动运行。“模式”属性遭遇频繁修改，这对多个应用的组合使用造成了影响，可能会阻碍关键应用的运行。

2.2.1、物理通道抢占

图9展示了185个应用中存在3451个对于物理通道抢占的交互链。声音和光照通道被抢占修改的次数明显高于其他物理通道。官方应用中包含大量对灯光与智能音箱的联动，根据用户所处地点、当地时间或用户指令触发相关实体“动作”。对于剩下的四个物理通道，值得注意的是在真实环境下它们可能会相互影响进而干扰感应器的触发。例如，温度能影响用户环境的湿度，湿度的高低能影响空气中烟尘及部分气体的含量水平。

3、系统性能测试

通过对185个应用进行分析来衡量IoTAutomaton的系统性能。在一台具有IntelCore i5-1038NG7 CPU和16GB内存的MacBook Pro上进行了10次试验来获得系统的平均性能。程序间交互分析的性能与各个应用自身具有的实体数目和“触发-动作”规则的数量有关。本次实验是对n个应用中的每两个应用进行分析，发现其中的全部应用间交互链和全部实体抢占路径。如图10 所示，处理全体185个应用的平均时间是50.5331秒，考虑到C_185^2＝17020，则平均处理一对应用的时间是2.9690毫秒。

4、风险分析与预防

SmartThings IDE为物联网风险场景重现提供了可能。这里重现了两个实验结果中的风险场景并提出预防建议。

4.1、情景1

图11展示了"Keep Me Cozy II"和"It's Too Cold"两个应用共享温度通道，根据房间实时温度调节恒温器采取制冷或制热的运行模式。

温度这一物理通道连接了这两个应用的“触发”，当两者“触发”的阈值设定产生分歧时，会引起设备行为异常，导致用户房间用电增多。例如，假设"Keep Me Cozy II"应用对恒温器制定的制冷与制热阈值分别是30度和18 度，用户因为疏忽或应用设置遭受攻击者篡改，"It's Too Cold"应用的"过热" 属性被设置为20度，恒温器的制热模块会提前开启，增大用户电量消耗。当此类风险场景大范围触发时，将增大地区供电压力，极端情况下可能造成电网瘫痪。

图12展示了该场景复现的记录。室内温度从24度降低到20度的过程中，恒温器附近温度是22度，制冷与制热阈值分别是30度和18度(mode:cool-- temp:22,heat:18,cool:30)。房间内温度感应器数值从24度降低到20度，"Keep Me Cozy II"应用内设置的制冷与制热阈值和恒温器设定相同(sensor:24, heat:18,cool:30)。正常情况下，当室内温度降低到20度时，恒温器的模式依然是制冷模式，加热模块处于关闭状态。只有当温度降低到18度时，恒温器更改模式为制热，关闭制冷模块，启动制热模块。由于"It's Too Cold"应用的影响，室内温度在20度时制热模块被启动(PUBLISHED on())。值得注意的是，此时恒温器依然处于制冷模式，并且同时运行制冷和制热模块。这造成了用户未知的能源消耗。

对于场景1的建议:在该场景中，两个应用对温度通道的定义具有分歧，导致了设备状态异常和用户电量消耗异常。在IoTAutomaton中，将此类风险场景描述为“存在应用间交互链”，提醒用户协调相关应用对连接件属性的设定，避免此类风险的发生。

4.2、场景2

图13展示了"Lock ItWhen I Leave"和"Make It So"两个应用都具有更改用户房间门锁状态的权限。"Lock ItWhen I Leave"应用控制房间门锁在有人靠近时解锁，当人离开时关闭。"Make It So"应用在配置或更新时保存指定设备的即时状态(保存状态)，当用户主动点击手机应用按钮或定位发生更改时，恢复设备为此前保存的状态(restoreState:lock or unlock)。

在正常情况下，用户在房间时“位置”是“家庭”模式，两个应用正常运行。当用户离家时，"Lock It When I Leave"应用关闭门锁，“位置”不再为“家庭”模式，"Make It So"应用在离家状态下也会关闭门锁。然而，在"Lock It When I Leave"应用解锁房门时，如果用户部署"Make It So"应用，或者攻击者直接控制用户手机恶意更新该应用，该应用会记录此时门锁状态。当用户离家时，攻击者可以通过修改用户手机GPS定位或执行“setLocation”(物联网平台API)的方式更改“位置”的模式为“家庭”，触发房门解锁操作的执行。或者更为直接，攻击者在手机后台模拟点击物联网应用按钮打开房门门锁。

图14展示了该场景复现的记录。由于点击手机物联网应用按钮或更改“位置”模式的代码实现都是调用恢复状态函数，在复现时只验证“位置”这一“触发”。用户在家时"LockIt When I Leave"应用正常运行，"Make It So"在房门解锁状态下被部署，记录门锁状态为"locked:false"。在用户离家时，攻击者篡改“位置”为“家庭”模式，触发恢复状态函数的执行，房门被解锁。

对于场景2的建议:在该场景中，两个应用抢占更改门锁状态，用户离家情况下存在房门被解锁的风险。在IoTAutomaton中，将此类风险场景描述为“实体属性抢占”，提醒用户分割设备为两组，分别由不同的应用控制，避免实体抢占的发生。如果存在攻击者恶意篡改“位置”模式的风险，用户应添加手机通知信息的功能，只有在用户同意的前提下才能顺利更改IoT运行模式。

5、用户和能量在物联网设备运行中的影响

以三星SmartThings平台为例，其提供了向用户传递信息的API，如“sendNotification”,“sendSmsMessage”等，应用可以调用此类接口以应用通知或短信的方式传递设备状态等关键信息。在申请的自动机模型中，将此类系统调用的后继节点设为用户(表明数据从平台传送到用户)。在攻击者获取用户使用的应用组合并找到应用间风险交互链的前提下，他们可以仿冒物联网平台向用户发送通知消息(植入手机病毒并仿冒通知消息；冒充物联网平台身份并进行短信推送)，诱导用户更改关键设备状态，触发风险场景。

物联网设备的硬件实现不同于人类的普通感知。在微型麦克风采集声音的过程中，声波引发振动膜的震动，更改了内置电容，声信号以电信号的形式被存储在设备中。攻击者在熟知此类硬件实现的细节后，可以利用能量转换的形式进行硬件层面的攻击。在本申请描述的物联网模型中，物理通道是相互独立的，能量模块的意义在于从硬件层面解释了信息在物理通道间传输的可能。攻击者不一定用声音通道攻击智能语音助手，他们也可以通过激光在硬件层面注入攻击指令。攻击者也不一定通过微型麦克风解锁用户手机，他们也可以用超声导波的形式注入开机命令。这提醒在部署设备应用时应该严格控制设备运行场景，并在物理层面进行信号隔离。例如，当房间无人时应关闭窗帘，防止来自屋外对语音助手的“Light-Command”攻击；手机机身的结构和材料能有效阻碍基于超声导波的“SurfingAttack”攻击。

参图15，介绍本申请物联网智能家居情景安全分析装置的一实施方式。在本实施方式中，该物联网智能家居情景安全分析装置包括提取模块、识别模块、构建模块、以及检测模块。

提取模块，用于对物联网应用源代码进行静态程序分析，以提取设备实体和联动规则；识别模块，用于对物联网设备功能和物联网应用用途的描述文本进行识别，以获取物联网物理通道；构建模块，用于基于所述设备实体、联动规则以及物联网物理通道构建由实体单元组成的物联网模型，其中，所述实体单元包括用户、能量、平台系统、环境通道、功能、属性、以及指令；检测模块，用于在所述物联网模型中，利用深度优先算法检测所述联动规则中的触发实体单元之间是否存在通路、以及不同物联网应用的触发实体单元是否对同一功能属性或所述物理通道具有可达性，从而确定物联网智能家居情景的风险因素。

一实施例中，提取模块具体用于根据物联网应用源代码编译过程生成的抽象语法树，构建程序间控制流图；利用静态程序分析中的可达定义算法和所述程序间控制流图对物联网应用源代码进行数据流分析，以提取设备实体和联动规则。

一实施例中，提取模块具体用于确定所述程序间控制流图的各程序段中的变量类型；基于所述各程序段的前置程序段和后继程序段中的变量类型，更新所述各程序段内变量信息；获取所述各程序段中与实体单元关联的变量信息。

一实施例中，识别模块具体用于利用预设新闻向量模型对所述描述文本中的词条进行向量化处理，以获得对应的词向量；对所述词向量进行聚类，并提取选定词语作为物联网物理通道。

一实施例中，构建模块具体用于定义所述物联网模型中各实体单元之间实体关系，所述实体关系包括读操作和写操作。

一实施例中，构建模块具体用于基于所述设备实体、联动规则、物联网物理通道以及各实体单元之间的实体关系，以有限状态自动机的形式构建由实体单元组成的物联网模型。

一实施例中，检测模块具体用于选定两个不同物联网应用联动规则内触发条件对应的第一触发实体单元和第二触发实体单元；在所述物联网模型中，从所述第一触发实体单元开始深度优先遍历，并记录遍历路径；判断所述遍历路径中是否存在所述第二触发实体单元；若是，确定所述联动规则中的触发实体单元之间存在通路。

图16示出了根据本说明书的实施例的物联网智能家居情景安全分析的计算设备30的硬件结构图。如图8所示，计算设备30可以包括至少一个处理器301、存储器302(例如非易失性存储器)、内存303和通信接口304，并且至少一个处理器301、存储器302、内存303和通信接口304经由总线305连接在一起。至少一个处理器301执行在存储器302中存储或编码的至少一个计算机可读指令。

应该理解，在存储器302中存储的计算机可执行指令当执行时使得至少一个处理器301进行本说明书的各个实施例中以上结合图1-6描述的各种操作和功能。

在本说明书的实施例中，计算设备30可以包括但不限于：个人计算机、服务器计算机、工作站、桌面型计算机、膝上型计算机、笔记本计算机、移动计算设备、智能电话、平板计算机、蜂窝电话、个人数字助理(PDA)、手持装置、消息收发设备、可佩戴计算设备、消费电子设备等等。

根据一个实施例，提供了一种比如机器可读介质的程序产品。机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本说明书的各个实施例中以上结合图1-6描述的各种操作和功能。具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。

在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本说明书的一部分。

可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、 CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。

本领域技术人员应当理解，上面公开的各个实施例可以在不偏离发明实质的情况下做出各种变形和修改。因此，本说明书的保护范围应当由所附的权利要求书来限定。

需要说明的是，上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理客户实现，或者，有些单元可能分由多个物理客户实现，或者，可以由多个独立设备中的某些部件共同实现。

以上各实施例中，硬件单元或模块可以通过机械方式或电气方式实现。例如，一个硬件单元、模块或处理器可以包括永久性专用的电路或逻辑(如专门的处理器，FPGA或ASIC)来完成相应操作。硬件单元或处理器还可以包括可编程逻辑或电路(如通用处理器或其它可编程处理器)，可以由软件进行临时的设置以完成相应操作。具体的实现方式(机械方式、或专用的永久性电路、或者临时设置的电路)可以基于成本和时间上的考虑来确定。

上面结合附图阐述的具体实施方式描述了示例性实施例，但并不表示可以实现的或者落入权利要求书的保护范围的所有实施例。在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。

本公开内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本公开内容。对于本领域普通技术人员来说，对本公开内容进行的各种修改是显而易见的，并且，也可以在不脱离本公开内容的保护范围的情况下，将本文所对应的一般性原理应用于其它变型。因此，本公开内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。