IoT smart home scenario security analysis method and device

Abstract

The present invention discloses a method and device for security analysis of IoT smart home scenarios, which are used to solve the problem that the security analysis of IoT platforms has limitations in monitoring range and is difficult to analyze when facing multiple IoT platforms. The method includes: static program analysis of IoT application source code to extract device entities and linkage rules; identification of description texts of IoT device functions and IoT application uses to obtain IoT physical channels; construction of an IoT model composed of entity units based on device entities, linkage rules and IoT physical channels; in the IoT model, a depth-first algorithm is used to detect whether there is a path between the trigger entity units in the linkage rules, and whether the trigger entity units of different IoT applications have accessibility to the same functional attributes or physical channels, thereby determining the risk factors of IoT smart home scenarios.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology, and in particular relates to a method and device for analyzing security of smart home scenarios in the Internet of Things. Background Art

[0002] The operation of the IoT platform is inseparable from the digital integration of devices, environments, and materials. Each device has its own function and status (for example, whether a light bulb is turned on and its brightness adjustment). Different IoT platforms on the market differ in terms of user scale, technical implementation, etc., and the device entities they support are also different.

[0003] As research deepens, the security of IoT application interactions has gradually attracted attention from all parties. At present, security analysis of IoT platform applications still uses traditional software analysis methods, such as taint analysis and unauthorized analysis, and there is no mature technology for this problem. This type of security risk detection technology has limitations in detection range and cannot help users discover and prevent new security issues in smart home environments, such as implicit device interaction chains that may lead to risk scenarios.

[0004] After studying eight major IoT platforms (Samsung's SmartThings, Apple's HomeKit, Amazon's AWS, Alibaba Cloud's AliOS Things, Google's Google Home, OpenHAB, Android's Android Things, IoTivity), it was found that IoT applications have unique challenges in program analysis. IoT programming platforms are diverse, and each platform has its own designated unified programming language and its own characteristics, which poses a challenge to program analysis. For example, the program scripts of the Samsung IoT platform are written in Groovy, and there are reflection execution calls and web service requests. These characteristics make program analysis difficult.

[0005] The information disclosed in this background technology section is only intended to enhance the understanding of the overall background of the invention and should not be regarded as an acknowledgment or any form of suggestion that the information constitutes the prior art already known to a person skilled in the art. Summary of the invention

[0006] The purpose of the present invention is to provide an IoT smart home scenario security analysis method to solve the problem that the security analysis of the IoT platform has limitations in monitoring range and is difficult to analyze when facing multiple IoT platforms.

[0007] To achieve the above object, the present invention provides a scenario security analysis method for an IoT smart home, comprising:

[0008] Perform static program analysis on IoT application source code to extract device entities and linkage rules;

[0009] Identify the description text of IoT device functions and IoT application usage to obtain IoT physical channels;

[0010] Based on the device entity, linkage rules and physical channels of the Internet of Things, an Internet of Things model consisting of entity units is constructed, wherein the entity units include users, energy, platform systems, environmental channels, functions, attributes, and instructions;

[0011] In the IoT model, a depth-first algorithm is used to detect whether there is a path between the trigger entity units in the linkage rules, and whether the trigger entity units of different IoT applications have accessibility to the same functional attribute or the physical channel, so as to determine the risk factors of the IoT smart home scenario.

[0012] In one embodiment, static program analysis is performed on the IoT application source code to extract device entities and linkage rules, specifically including:

[0013] Construct an inter-program control flow graph based on the abstract syntax tree generated during the compilation process of the IoT application source code;

[0014] The reachable definition algorithm in static program analysis and the inter-program control flow graph are used to perform data flow analysis on the source code of the Internet of Things application to extract device entities and linkage rules.

[0015] In one embodiment, the reachable definition algorithm in static program analysis and the inter-program control flow graph are used to perform data flow analysis on the IoT application source code, specifically including:

[0016] Determining the variable type in each program segment of the inter-program control flow graph;

[0017] Based on the variable types in the preceding program segment and the succeeding program segment of each program segment, updating the variable information in each program segment;

[0018] Obtain variable information associated with the entity unit in each program segment.

[0019] In one embodiment, the description text of the IoT device function and the IoT application purpose is identified to obtain the IoT physical channel, specifically including:

[0020] Using a preset news vector model to vectorize the terms in the description text to obtain corresponding word vectors;

[0021] The word vectors are clustered, and selected words are extracted as physical channels of the Internet of Things.

[0022] In one embodiment, an Internet of Things model composed of entity units is constructed based on the device entity, linkage rules, and physical channels of the Internet of Things, specifically including:

[0023] An entity relationship between entity units in the Internet of Things model is defined, wherein the entity relationship includes a read operation and a write operation.

[0024] In one embodiment, an Internet of Things model composed of entity units is constructed based on the device entity, linkage rules, and physical channels of the Internet of Things, specifically including:

[0025] Based on the device entities, linkage rules, physical channels of the Internet of Things and entity relationships between the entity units, an Internet of Things model composed of entity units is constructed in the form of a finite state automaton.

[0026] In one embodiment, in the Internet of Things model, a depth-first algorithm is used to detect whether there is a path between the trigger entity units in the linkage rule, specifically including:

[0027] Selecting a first trigger entity unit and a second trigger entity unit corresponding to trigger conditions in two different IoT application linkage rules;

[0028] In the Internet of Things model, a depth-first traversal is started from the first trigger entity unit, and the traversal path is recorded;

[0029] Determine whether the second trigger entity unit exists in the traversal path; if so,

[0030] It is determined that there is a path between the trigger entity units in the linkage rule.

[0031] The present invention also provides an IoT smart home scenario security analysis device, comprising:

[0032] The extraction module is used to perform static program analysis on the source code of IoT applications to extract device entities and linkage rules;

[0033] An identification module is used to identify the description text of the IoT device function and the IoT application purpose to obtain the IoT physical channel;

[0034] A construction module, used to construct an Internet of Things model composed of entity units based on the device entity, linkage rules and physical channels of the Internet of Things, wherein the entity units include users, energy, platform systems, environmental channels, functions, attributes, and instructions;

[0035] The detection module is used to detect whether there is a path between the trigger entity units in the linkage rules and whether the trigger entity units of different Internet of Things applications have accessibility to the same functional attribute or the physical channel in the Internet of Things model by using a depth-first algorithm, so as to determine the risk factors of the Internet of Things smart home scenario.

[0036] The present invention also provides a computing device, comprising:

[0037] at least one processor; and

[0038] A memory stores instructions, and when the instructions are executed by the at least one processor, the at least one processor executes the method as described above.

[0039] The present invention also provides a machine-readable storage medium storing executable instructions, which, when executed, enable the machine to perform the method as described above.

[0040] Compared with the prior art, the IoT smart home scenario security analysis method according to the present invention extracts device entities and linkage rules from IoT application source code, and identifies description texts of IoT device functions and application uses to obtain IoT physical channels, and builds an IoT model based on this, so that different IoT applications can be represented uniformly; and based on the IoT model, the risks such as rule ambiguity and entity preemption are summarized and discovered, which can effectively discover implicit interaction chains in IoT smart home scenarios and remind possible security risk factors. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 This is a flow chart of an embodiment of a method for analyzing security of smart home scenarios in the Internet of Things according to the present invention;

[0042] Figure 2 It is a flow chart of the method for security analysis of smart home scenarios in the Internet of Things according to the present invention;

[0043] Figure 3 It is a system block diagram of the Internet of Things model defined by the Internet of Things smart home scenario security analysis method of the present invention;

[0044] Figure 4 It is a read-write relationship diagram of entities in the automaton during verification of the IoT smart home scenario security analysis method of the present invention;

[0045] Figure 5 It is a diagram of the interactive chain connectors between IoT applications in the verification of the IoT smart home scenario security analysis method according to the present invention;

[0046] Figure 6It is a diagram of the types of interactive chain connectors between IoT applications in the verification of the IoT smart home scenario security analysis method of the present invention;

[0047] Figure 7 It is a diagram of physical channel connectors between IoT applications in the verification of the IoT smart home scenario security analysis method according to the present invention;

[0048] Figure 8 It is an interactive chain diagram of entity attribute preemption in the verification of the IoT smart home scenario security analysis method of the present invention;

[0049] Fig. 9 It is an interactive chain diagram of physical channel preemption in the verification of the IoT smart home scenario security analysis method according to the present invention;

[0050] Fig.10 It is an analysis diagram between Internet of Things applications in the verification of the Internet of Things smart home scenario security analysis method according to the present invention;

[0051] Fig.11 It is the control flow diagram between applications in scenario 1 in the verification of the IoT smart home scenario security analysis method of the present invention;

[0052] Fig.12 It is the recording diagram of scenario 1 reproducing in the verification of the scenario security analysis method of the Internet of Things smart home according to the present invention;

[0053] Fig.13 It is the control flow diagram between applications in scenario 2 in the verification of the IoT smart home scenario security analysis method of the present invention;

[0054] Fig.14 It is the recording diagram of scenario 2 reproducing in the verification of the scenario security analysis method of the Internet of Things smart home according to the present invention;

[0055] Fig.15 It is a module diagram of an embodiment of a scenario security analysis device for an Internet of Things smart home according to the present invention;

[0056] Fig.16 It is a hardware structure diagram of an embodiment of the IoT smart home scenario security analysis device according to the present invention. DETAILED DESCRIPTION

[0057] The specific implementation modes of the present invention are described in detail below in conjunction with the accompanying drawings, but it should be understood that the protection scope of the present invention is not limited by the specific implementation modes.

[0058] Unless explicitly stated otherwise, throughout the specification and claims, the term “comprise” or variations such as “include” or “comprising”, etc., will be understood to include the stated elements or components but not to exclude other elements or components.

[0059] The introduction of IoT devices into public and private spaces has brought about tremendous changes in areas such as industrial control systems and smart cities. For example, in the IoT smart home scenario, smart home applications that integrate smart door locks, thermostats, WiFi cameras, and smart kettles can help people interact with their living spaces while away from home. However, the implicit chain of IoT device interactions can put users in dangerous scenarios, such as opening a window when the user is not at home, or opening a garage door through a voice assistant 75m away. In addition, the realization of digitally enhanced spaces is inseparable from the collection and processing of a large amount of user privacy data, which, once leaked, may infringe on the user's privacy.

[0060] Ginseng Figure 1 , introduces a specific implementation of the IoT smart home scenario security analysis method of the present application. In this implementation, the method includes:

[0061] S11. Perform static program analysis on IoT application source code to extract device entities and linkage rules.

[0062] Mate Reference Figure 2 , the device entities extracted in this step are the basic nodes in the subsequent model building step, and these basic nodes are defined as entity units in the implementation of this application. Specifically, individuals with interactive characteristics of people, devices, systems and environments in the Internet of Things platform are collectively referred to as "entity units", which are the basic elements for building the Internet of Things system. The Internet of Things system has powerful and rich information interaction characteristics. These data are generated and interacted between "entity units" and correspond to the changes in the specific execution status of "entity units".

[0063] like Figure 3 As shown, seven entity units are defined in the implementation of this application, including: user, energy, platform system, environmental channel, function, attribute, and instruction. The specific definitions are as follows:

[0064] User: refers to the operator who participates in information generation, interaction and instruction issuance within the IoT system;

[0065] Energy: refers to the energy carrier that can carry command information, such as sound, light energy, electrical energy, etc. This entity unit type provides an explanation for the transmission of information between entity units in the "environment channel";

[0066] Platform system: refers to the application programming interface (API) provided by the IoT system platform to users and developers to write programs;

[0067] Environmental channel: refers to the channel that can transmit environmental information, such as temperature, humidity, light intensity, etc.;

[0068] Function: This implementation atomically represents the functions of IoT devices within the system, defining devices as a collection of different “functions”;

[0069] Attributes: A "functional" entity unit contains certain state information, which is referred to as the attributes of the functional entity unit;

[0070] Instructions: Control instructions possessed by a “functional” entity unit that can change the state of itself or other entity units.

[0071] In the specific extraction process, we can build an inter-program control flow graph based on the abstract syntax tree generated by the IoT application source code compilation process, and then use the reachable definition algorithm and inter-program control flow graph in static program analysis to perform data flow analysis on the IoT application source code to extract device entities and linkage rules.

[0072] The device entity here is actually the device entity involved in the operation of the Internet of Things, and the linkage rule corresponds to the "trigger-action" relationship.

[0073] In the inter-program control flow graph, each program segment is connected in the order of program execution. Therefore, in a specific data flow analysis, the variable type in each program segment of the inter-program control flow graph can be determined first. If it is related to the entity unit defined in the embodiment of the present application, its variable type can be directly determined directly, otherwise it can be initialized to "object" (Object).

[0074] Next, the reachable definition analysis algorithm is executed according to the inter-program control flow graph, and the variable information in each program segment is updated based on the variable types in the predecessor and successor program segments of each program segment until there is no program segment that needs to continue updating the variable information.

[0075] Finally, the variable information associated with the entity unit in each program segment is obtained, and the sensitive information flow in the program segment can be marked on this basis. The marking of sensitive information flow in IoT applications can assist IoT platforms in application auditing.

[0076] S12. Identify the description text of the IoT device functions and IoT application purposes to obtain the IoT physical channel.

[0077] In the implementation of the present application, the functions of IoT devices are atomized, so that devices with different uses can be described by a combination of atomic functions, and each atomized function has a description text explaining the functional characteristics. In addition, each IoT application also has a description text explaining the purpose of the application.

[0078] In the recognition process, natural language processing technology can be used to analyze the above two types of description texts. Specifically, the terms in the description text can be vectorized using a preset news vector model to obtain corresponding word vectors; the obtained word vectors are then clustered, and selected words are extracted as physical channels of the Internet of Things.

[0079] The preset news vector model here can be selected according to actual application needs. In one embodiment, the magnetic stripe can be vectorized using the Google News vector model. At the same time, the selected words extracted can be representative words.

[0080] S13: construct an Internet of Things model consisting of entity units based on the device entity, linkage rules and physical channels of the Internet of Things.

[0081] There are certain inherent interactions (entity relationships) between entity units. In this IoT model, this abstraction is defined as read and write operations between entity units. For example, the execution of instructions can modify device properties, which is a write operation; a device with perception function obtains information from a physical channel, which is a read operation. Using this IoT model, different IoT applications can be uniformly represented, and inter-application analysis can be performed to discover implicit interaction chains.

[0082] In the implementation of the present application, an IoT model composed of entity units can be constructed in the form of a finite state automaton based on device entities, linkage rules, IoT physical channels, and entity relationships between entity units. The device entity is a combination of multiple functions, which eliminates the obstacles to unified analysis caused by device heterogeneity in the IoT system.

[0083] S14. In the IoT model, a depth-first algorithm is used to detect whether there is a path between the trigger entity units in the linkage rules, and whether the trigger entity units of different IoT applications have accessibility to the same functional attribute or the physical channel, so as to determine the risk factors of the IoT smart home scenario.

[0084] Specifically, the first trigger entity unit a and the second trigger entity unit b corresponding to the trigger conditions in the linkage rules of two different Internet of Things applications A and B can be selected first; then, in the Internet of Things model, a depth-first traversal is started from the first trigger entity unit a, and the traversal path is recorded; then, it is determined whether there is a second trigger entity unit b in the traversal path; if so, it is determined that there is a path between the trigger entity units in the linkage rules (defined as "rule ambiguity" in this application).

[0085] For the entity units corresponding to the trigger conditions in different IoT application linkage rules, if they have accessibility to the same functional attributes or physical channels, it is defined as "entity preemption".

[0086] Whether it is rule ambiguity or entity preemption, it can be summarized and discovered through the process of data extraction-model construction-risk analysis in the above-mentioned implementation mode of this application. Moreover, the analysis process gets rid of the obstacle of device heterogeneity in the Internet of Things system to unified analysis, and uniformly represents different Internet of Things applications, so that implicit interaction chains can be discovered and possible security risk factors can be reminded.

[0087] The risk factors leading to IoT smart home scenarios can be summarized as: rule ambiguity, entity preemption, semantic ambiguity, and device hardware implementation.

[0088] Rule ambiguity refers to the fact that different applications have different definitions of the same resource state, which may lead to abnormal device status or abnormal power consumption. Based on the above security analysis results, the implementation method of this application can further suggest that users take safety precautions by coordinating the numerical definitions of the same entity unit attributes of related applications. For example, when two applications both have the ability to adjust the room temperature, coordinate the temperature thresholds for heating and cooling of the two applications to prevent the power-consuming scenario of turning on the air conditioner and heater at the same time.

[0089] Entity preemption refers to the repeated preemption of reading and writing of the same resource by different applications, which may cause the related applications to lose the real state of the entity unit. Based on the above security analysis results, the implementation method of this application can further suggest that users use multiple devices to deploy different applications and isolate the applications. For example, when two or more applications have control over the same device, on the one hand, by increasing the number of such devices, different applications can control different devices to achieve an isolation effect; on the other hand, the application execution scenarios or time limits can be increased to allow different applications to control the same device in batches and at different times to achieve an isolation effect.

[0090] Semantic ambiguity: Some IoT platforms only require that optional devices in IoT applications have specified functions. However, in reality, there is more than one type of device with this function. This semantic ambiguity in device description reduces the reliability of IoT risk analysis. It is recommended that relevant platforms increase restrictions on the types of optional devices in applications. For example, the definition of device types can be added to the specifications of IoT platform programming scripts to reduce the uncertainty of actual connected devices.

[0091] Device hardware implementation: Injection attacks on IoT devices can be launched using ultrasound, ultrasonic waveguides, and lasers. It is recommended that IoT platforms increase the strictness of device behavior association at the software level, that device providers identify injection attacks at the software level, and that special product casings and materials be used at the hardware level to increase the energy dissipation of injection attacks and prevent such attacks.

[0092] Among the above risk factors, the responsible parties corresponding to "semantic ambiguity" and "device hardware implementation" are the IoT platform and the device manufacturer. Therefore, the analysis of these two risks can be manually reviewed by referring to the official documents issued by the responsible parties.

[0093] The following shows the effectiveness and efficiency of the IoT smart home scenario security analysis method of this application from multiple perspectives. Specifically, the IoTAutomaton system was developed based on the Smartthings platform. The attributes and instructions of 117 functions, 308 official API call interfaces, and 186 official applications SmartApp were analyzed. The evaluation is intended to verify the following issues:

[0094] 1. Can you successfully extract trigger-action data from 186 IoT applications? Can you track important variables and system calls in IoT applications to help with later analysis? What are the common physical channels in IoT platforms?

[0095] 2. Is there an interaction chain between programs? What entities or attributes help to generate the interaction chain?

[0096] 3. Is there a phenomenon of preemption of reading and writing entities between programs? Which entity attributes are more likely to be frequently modified?

[0097] 4. What is the performance overhead of the IoTAutomaton system?

[0098] 5. How to prevent risks in IoT applications?

[0099] The verification process will be carried out in the steps of data extraction - model building - system performance testing - risk analysis and prevention - the impact of users and energy on the operation of IoT devices. Specifically:

[0100] 1. Data extraction

[0101] 1.1 Static Program Analysis

[0102] Among the 186 applications, the IoTAutomaton system extracted the "trigger-action" information of 185 applications. Due to the complexity of the program and the diverse mappings, it was not possible to automatically extract information from the "simple-control" application. On the basis of the control flow analysis of the application, the "may-analysis" method was chosen to perform data flow analysis, which reduced the trouble caused by data dependencies in the code on the final result. On the basis of generating control flow graphs and data flow graphs, all device and platform system calls that may be used after each "trigger" are found, and the path of the program to reach such control statements is tracked to provide assistance for the subsequent analysis of relevant personnel.

[0103] 1.2 Physical Channel

[0104] Stanza was used to perform word segmentation and semantic analysis on the descriptions of 186 applications and 117 "functions", and the key entities in the description sentences (i.e., the words marked as NN in the stanza analysis results) were extracted. After the key entity words were converted into word vectors, they were clustered using the K-means algorithm. Through the above steps, words with similar meanings were clustered in one class. In the clustering results, clusters containing physical channels were selected, and the core words of the class themselves or the words closest to the class center words in the Word2vec model were used as physical channels.

[0105] Finally, the 355 extracted key entities were divided into 14 categories, and 9 physical channels with practical significance were identified. For each physical channel, some key entity words in the corresponding class are provided in the table. The final results are shown in the following table.

[0106]

[0107] 2. Model construction

[0108] The flow of data in the IoT platform is abstracted into read and write operations between different entities. The "instructions" in the "function" can modify the state of the corresponding "attribute", which is a write operation. When the state of the "attribute" changes, it also means that the "function" itself has changed. The information flows from the "attribute" to the "function" itself, which is a read operation of the "function" on the "attribute". For the "function" of the sensor type, data flows from the physical channel to the corresponding "attribute", which is a read operation of the "attribute" on the information source, such as Figure 4 shown.

[0109] 2.1 Inter-program interaction

[0110] In total, 6745 application-to-application interaction chains were found in 185 applications. The number of occurrences of the connectors in the interaction chain is displayed in descending order. Figure 5 In the figure, the connectors are classified according to the categories, such as Figure 6 shown.

[0111] It can be found that the connectors of the "instruction" type appear most frequently in the interaction chain between applications (4461 times), the connectors of the "system platform" type are the rarest (382 times), and the "mode" and "physical channel" are ranked second and third (2081 times and 1566 times). The programming paradigm of the application is IFTTT (IfThis Then That), and the "action" usually corresponds to the "instruction" and system call belonging to the "function", so the connectors of the "instruction" type appear the most. When an application has the ability to change the "mode", it will affect the execution effect of other applications in the same group (other applications may only run in a specified "mode"). Compared with the "instruction", the influence of the "mode" element is broader. The connectors of the "system platform" type correspond to "location" and "application" (App). When the user touches the phone button or moves the position, it will trigger certain actions of the application.

[0112] exist Figure 7 The distribution of the number of physical channels as interactive chain connectors is shown in Figure 1. The most frequent one is "emissions", and the least frequent one is "acceleration". The 185 applications processed do not contain any devices related to geolocation, let alone modules for processing human voice, so "location" and "sound" do not play the role of interactive chain connectors in the results.

[0113] The application includes a thermostat, which is divided into two modules: heating and cooling. In actual device construction, the raw materials for the heating module function are electricity, gasoline or natural gas. When gasoline or natural gas is not completely burned, smoke (carbon particles) will be produced, as well as harmful gases such as carbon monoxide. These substances will trigger carbon monoxide and smoke sensors, causing related "actions". The cooling module of the thermostat contains fans and air conditioners, which affect the air humidity and temperature in the environment, trigger humidity and temperature sensors, and cause related "actions". The second-ranked physical channel is light. The official application includes such applications, that is, judging whether it is day or night based on the intensity of light, and triggering actions such as notifying the user when the light changes. Entities that can affect the light channel include not only lamps and other devices, but also alarms. Considering that doors and windows will affect the light level of the surrounding environment during the opening and closing process, and have a certain acceleration on the plane of the door, installing acceleration sensors on doors and windows can build applications that cooperate with the closing of doors and windows, which corresponds to the "acceleration" channel in the figure.

[0114] 2.2 Entity Preemption

[0115] Preemptive modification makes it impossible for related applications to determine the state of the entity unit, which will disrupt the normal operation of the application and pose a security risk. There are two ways to obtain the entity state of the device during the application operation. One is to query the IoT platform immediately, and the other is to record the device state after the last execution of the program in the application. The specific method used in the application code implementation to obtain device properties is determined by the developer and application requirements.

[0116] 2.2.1 Entity attribute preemption

[0117] Figure 8 It shows that there are 6770 interaction chains of entity attribute preemption in 185 applications. It is worth noting that the attribute "capability.switch.attributes.switch" is preempted significantly more often than other attributes. Generally speaking, most smart home device entities have the attribute "capability.switch", which means that in real environments, the device entities whose states are preempted and modified include not only sockets, but also automatic coffee machines, WiFi electric kettles, thermostats and other devices. The preemption modification of this attribute may cause the frequent activation and shutdown of household appliances, endangering user safety. The top five attributes are related to light, sound and switch, and the frequency of preemption modification of the mode attribute ranks sixth. The application contains the formulation of "mode", and there are a certain number of rules that need to be started and run in a specific "mode". The "mode" attribute is frequently modified, which affects the combined use of multiple applications and may hinder the operation of key applications.

[0118] 2.2.1 Physical Channel Preemption

[0119] Fig. 9 It shows that there are 3451 interaction chains for physical channel preemption in 185 applications. The number of times the sound and light channels are preempted and modified is significantly higher than other physical channels. The official application contains a large number of linkages between lights and smart speakers, which trigger related entity "actions" based on the user's location, local time or user instructions. For the remaining four physical channels, it is worth noting that in a real environment they may affect each other and interfere with the triggering of the sensor. For example, temperature can affect the humidity of the user's environment, and the level of humidity can affect the content level of smoke and some gases in the air.

[0120] 3. System performance test

[0121] The performance of IoTAutomaton was measured by analyzing 185 applications. Ten experiments were conducted on a MacBook Pro with an Intel Core i5-1038NG7 CPU and 16GB of memory to obtain the average performance of the system. The performance of the program interaction analysis is related to the number of entities and the number of "trigger-action" rules in each application. This experiment analyzed every two applications out of n applications and found all the application interaction chains and all entity preemption paths. Fig.10 As shown, the average time to process all 185 applications is 50.5331 seconds. Considering that C_185^2=17020, the average time to process a pair of applications is 2.9690 milliseconds.

[0122] 4. Risk analysis and prevention

[0123] SmartThings IDE makes it possible to reproduce IoT risk scenarios. Here, we reproduce the risk scenarios in two experimental results and provide prevention suggestions.

[0124] 4.1 Scenario 1

[0125] Fig.11 The two applications "Keep Me Cozy II" and "It's Too Cold" were demonstrated to share the temperature channel, and the thermostat was adjusted to adopt cooling or heating operation mode according to the real-time temperature of the room.

[0126] The temperature is a physical channel that connects the "triggers" of these two applications. When the threshold settings of the "triggers" of the two applications diverge, it will cause abnormal device behavior, resulting in increased electricity consumption in the user's room. For example, suppose the "Keep Me Cozy II" application sets the cooling and heating thresholds for the thermostat to 30 degrees and 18 degrees respectively. Due to negligence by the user or tampering with the application settings by an attacker, the "overheating" attribute of the "It's Too Cold" application is set to 20 degrees. The heating module of the thermostat will be turned on in advance, increasing the user's power consumption. When such risk scenarios are triggered on a large scale, it will increase the pressure on regional power supply, and in extreme cases, it may cause the power grid to collapse.

[0127] Fig.12The record of the scene reproduction is shown. When the indoor temperature drops from 24 degrees to 20 degrees, the temperature near the thermostat is 22 degrees, and the cooling and heating thresholds are 30 degrees and 18 degrees respectively (mode:cool-- temp:22,heat:18,cool:30). The temperature sensor value in the room drops from 24 degrees to 20 degrees, and the cooling and heating thresholds set in the "Keep Me Cozy II" application are the same as the thermostat settings (sensor:24, heat:18,cool:30). Under normal circumstances, when the indoor temperature drops to 20 degrees, the thermostat mode is still cooling mode, and the heating module is turned off. Only when the temperature drops to 18 degrees, the thermostat changes mode to heating, turns off the cooling module, and starts the heating module. Due to the influence of the "It's Too Cold" application, the heating module is started when the indoor temperature is 20 degrees (PUBLISHED on()). It is worth noting that at this time, the thermostat is still in cooling mode and runs the cooling and heating modules at the same time. This causes energy consumption unknown to users.

[0128] Suggestions for scenario 1: In this scenario, the two applications have different definitions of the temperature channel, which leads to abnormal device status and abnormal user power consumption. In IoTAutomaton, this risk scenario is described as "there is an interaction chain between applications", reminding users to coordinate the settings of the connector properties of related applications to avoid such risks.

[0129] 4.2 Scenario 2

[0130] Fig.13 It shows that both "Lock ItWhen I Leave" and "Make It So" apps have the permission to change the state of the user's room door lock. The "Lock ItWhen I Leave" app controls the room door lock to unlock when someone approaches and close when the person leaves. The "Make It So" app saves the instant state of the specified device when configuring or updating (save state), and restores the device to the previously saved state (restoreState: lock or unlock) when the user actively clicks the mobile app button or the location changes.

[0131] Under normal circumstances, when the user is in the room, "Location" is in "Home" mode, and both applications run normally. When the user leaves home, the "Lock It When I Leave" application closes the door lock, "Location" is no longer in "Home" mode, and the "Make It So" application also closes the door lock when away from home. However, when the "Lock It When I Leave" application unlocks the door, if the user deploys the "Make It So" application, or the attacker directly controls the user's phone to maliciously update the application, the application will record the door lock status at this time. When the user leaves home, the attacker can change the "Location" mode to "Home" by modifying the user's phone GPS location or executing "setLocation" (IoT platform API), triggering the execution of the door unlocking operation. Or more directly, the attacker simulates clicking the IoT application button in the background of the phone to open the door lock.

[0132] Fig.14 The record of the scene recurrence is shown. Since the code implementation of clicking the mobile IoT application button or changing the "location" mode calls the restore state function, only the "location" "trigger" is verified during the recurrence. When the user is at home, the "LockIt When I Leave" application runs normally, and "Make It So" is deployed when the door is unlocked, and the door lock state is recorded as "locked:false". When the user leaves home, the attacker tampered with the "location" to "home" mode, triggering the execution of the restore state function, and the door is unlocked.

[0133] Suggestions for scenario 2: In this scenario, two applications compete to change the door lock status, and there is a risk that the door will be unlocked when the user is away from home. In IoTAutomaton, this risk scenario is described as "entity attribute preemption", reminding users to split the device into two groups, each controlled by a different application, to avoid entity preemption. If there is a risk of an attacker maliciously tampering with the "location" mode, the user should add the function of mobile phone notification information. The IoT operation mode can only be changed smoothly with the user's consent.

[0134] 5. Impact of users and energy on the operation of IoT devices

[0135] Taking Samsung SmartThings platform as an example, it provides APIs for delivering information to users, such as "sendNotification" and "sendSmsMessage". Applications can call such interfaces to deliver key information such as device status in the form of application notifications or text messages. In the automaton model applied for, the successor node of such system calls is set to the user (indicating that data is transmitted from the platform to the user). On the premise that attackers obtain the application combination used by users and find the risk interaction chain between applications, they can impersonate the IoT platform to send notification messages to users (implant mobile phone viruses and impersonate notification messages; impersonate the IoT platform identity and send text messages), induce users to change the status of key devices, and trigger risk scenarios.

[0136] The hardware implementation of IoT devices is different from ordinary human perception. In the process of collecting sound with a micro-microphone, the sound wave triggers the vibration of the diaphragm, changes the built-in capacitor, and the sound signal is stored in the device in the form of an electrical signal. After the attacker is familiar with the details of such hardware implementation, he can use the form of energy conversion to carry out hardware-level attacks. In the IoT model described in this application, the physical channels are independent of each other, and the significance of the energy module is to explain the possibility of information transmission between physical channels from the hardware level. Attackers do not necessarily use sound channels to attack smart voice assistants. They can also inject attack commands at the hardware level through lasers. Attackers do not necessarily unlock the user's mobile phone through a micro-microphone. They can also inject power-on commands in the form of ultrasonic guided waves. This reminds that when deploying device applications, the device operation scenario should be strictly controlled and signal isolation should be performed at the physical level. For example, when there is no one in the room, the curtains should be closed to prevent "Light-Command" attacks on voice assistants from outside the house; the structure and material of the mobile phone body can effectively hinder the "SurfingAttack" attack based on ultrasonic guided waves.

[0137] Ginseng Fig.15 , introduces an implementation of the IoT smart home scenario security analysis device of the present application. In this implementation, the IoT smart home scenario security analysis device includes an extraction module, an identification module, a construction module, and a detection module.

[0138] The invention discloses an extraction module for performing static program analysis on the source code of the Internet of Things application to extract the device entity and linkage rules; an identification module for identifying the description text of the function of the Internet of Things device and the purpose of the Internet of Things application to obtain the physical channel of the Internet of Things; a construction module for constructing an Internet of Things model composed of entity units based on the device entity, linkage rules and the physical channel of the Internet of Things, wherein the entity units include users, energy, platform systems, environmental channels, functions, attributes and instructions; and a detection module for detecting in the Internet of Things model whether there is a path between the trigger entity units in the linkage rules and whether the trigger entity units of different Internet of Things applications have accessibility to the same functional attribute or the physical channel, thereby determining the risk factors of the Internet of Things smart home scenario.

[0139] In one embodiment, the extraction module is specifically used to construct an inter-program control flow graph based on an abstract syntax tree generated during the compilation process of the IoT application source code; and perform data flow analysis on the IoT application source code using a reachable definition algorithm in static program analysis and the inter-program control flow graph to extract device entities and linkage rules.

[0140] In one embodiment, the extraction module is specifically used to determine the variable type in each program segment of the inter-program control flow graph; based on the variable types in the predecessor program segment and the successor program segment of each program segment, update the variable information in each program segment; and obtain the variable information associated with the entity unit in each program segment.

[0141] In one embodiment, the recognition module is specifically used to vectorize the terms in the description text using a preset news vector model to obtain corresponding word vectors; cluster the word vectors, and extract selected words as physical channels of the Internet of Things.

[0142] In one embodiment, the construction module is specifically used to define the entity relationship between the entity units in the Internet of Things model, and the entity relationship includes a read operation and a write operation.

[0143] In one embodiment, the construction module is specifically used to construct an Internet of Things model composed of entity units in the form of a finite state automaton based on the device entity, linkage rules, Internet of Things physical channels and entity relationships between the entity units.

[0144] In one embodiment, the detection module is specifically used to select a first trigger entity unit and a second trigger entity unit corresponding to trigger conditions in two different IoT application linkage rules; in the IoT model, a depth-first traversal is started from the first trigger entity unit, and the traversal path is recorded; it is determined whether the second trigger entity unit exists in the traversal path; if so, it is determined that there is a path between the trigger entity units in the linkage rules.

[0145] Fig.16 FIG. 1 shows a hardware structure diagram of a computing device 30 for IoT smart home scenario security analysis according to an embodiment of the present specification. Figure 8 As shown, the computing device 30 may include at least one processor 301, a memory 302 (e.g., a non-volatile memory), a memory 303, and a communication interface 304, and the at least one processor 301, the memory 302, the memory 303, and the communication interface 304 are connected together via a bus 305. At least one processor 301 executes at least one computer-readable instruction stored or encoded in the memory 302.

[0146] It should be understood that the computer executable instructions stored in the memory 302, when executed, cause at least one processor 301 to perform the above combined operations in various embodiments of the present specification. Figure 1-6 Describes the various operations and functions.

[0147] In the embodiments of the present specification, the computing device 30 may include, but is not limited to, a personal computer, a server computer, a workstation, a desktop computer, a laptop computer, a notebook computer, a mobile computing device, a smart phone, a tablet computer, a cellular phone, a personal digital assistant (PDA), a handheld device, a messaging device, a wearable computing device, a consumer electronic device, and the like.

[0148] According to one embodiment, a program product such as a machine-readable medium is provided. The machine-readable medium may have instructions (i.e., the above-mentioned elements implemented in the form of software), which, when executed by a machine, causes the machine to perform the above-mentioned combination of various embodiments of this specification. Figure 1-6 Specifically, a system or device equipped with a readable storage medium may be provided, on which a software program code implementing the functions of any of the above-mentioned embodiments is stored, and a computer or processor of the system or device reads and executes the instructions stored in the readable storage medium.

[0149] In this case, the program code itself read from the machine-readable medium can realize the function of any one of the above embodiments, and thus the machine-readable code and the machine-readable storage medium storing the machine-readable code constitute part of this specification.

[0150] Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD-RW), magnetic tapes, non-volatile memory cards, and ROMs. Optionally, the program code may be downloaded from a server computer or a cloud via a communication network.

[0151] Those skilled in the art should understand that the various embodiments disclosed above can be modified and altered in various ways without departing from the essence of the invention. Therefore, the protection scope of this specification should be defined by the appended claims.

[0152] It should be noted that not all steps and units in the above-mentioned processes and system structure diagrams are necessary, and some steps or units can be ignored according to actual needs. The execution order of each step is not fixed and can be determined as needed. The device structure described in the above-mentioned embodiments can be a physical structure or a logical structure, that is, some units may be implemented by the same physical client, or some units may be implemented by multiple physical clients, or some components in multiple independent devices may be implemented together.

[0153] In the above embodiments, the hardware unit or module can be realized by mechanical or electrical means. For example, a hardware unit, module or processor can include permanent dedicated circuit or logic (such as special processor, FPGA or ASIC) to complete the corresponding operation. The hardware unit or processor can also include programmable logic or circuit (such as general-purpose processor or other programmable processor), which can be temporarily set by software to complete the corresponding operation. Specific implementation (mechanical method or dedicated permanent circuit or temporary circuit) can be determined based on cost and time consideration.

[0154] The specific embodiments described above in conjunction with the accompanying drawings describe exemplary embodiments, but do not represent all embodiments that can be implemented or fall within the scope of protection of the claims. The term "exemplary" used throughout this specification means "used as an example, instance or illustration" and does not mean "preferred" or "having advantages" over other embodiments. For the purpose of providing an understanding of the described technology, the specific embodiments include specific details. However, these technologies can be implemented without these specific details. In some instances, in order to avoid making the concepts of the described embodiments difficult to understand, well-known structures and devices are shown in block diagram form.

[0155] The above description of the present disclosure is provided to enable any person of ordinary skill in the art to implement or use the present disclosure. Various modifications to the present disclosure will be apparent to those of ordinary skill in the art, and the general principles corresponding to the present disclosure may be applied to other variations without departing from the scope of protection of the present disclosure. Therefore, the present disclosure is not limited to the examples and designs described herein, but is consistent with the widest range of principles and novel features disclosed herein.

Claims

1. A scenario security analysis method for IoT smart home, It is characterized in that include: Perform static program analysis on the IoT application source code to extract device entities and linkage rules, including constructing an inter-program control flow graph based on the abstract syntax tree generated during the IoT application source code compilation process; Using the reachable definition algorithm in static program analysis and the inter-program control flow graph, data flow analysis is performed on the source code of the Internet of Things application to extract device entities and linkage rules; Identify the description text of the IoT device function and the IoT application purpose to obtain the IoT physical channel, specifically including vectorizing the terms in the description text using a preset news vector model to obtain corresponding word vectors; cluster the word vectors, and extract selected words as the IoT physical channel; Building an Internet of Things model composed of entity units based on the device entity, linkage rules and physical channels of the Internet of Things, specifically including defining entity relationships between entity units in the Internet of Things model, wherein the entity relationships include read operations and write operations, and the entity units include users, energy, platform systems, environmental channels, functions, attributes, and instructions; In the IoT model, a depth-first algorithm is used to detect whether there is a path between the trigger entity units in the linkage rules, and whether the trigger entity units of different IoT applications have accessibility to the same functional attribute or physical channel, so as to determine the risk factors of the IoT smart home scenario.

2. The IoT smart home scenario security analysis method according to claim 1, It is characterized in that The reachable definition algorithm in static program analysis and the inter-program control flow graph are used to perform data flow analysis on the IoT application source code, specifically including: Determining the variable type in each program segment of the inter-program control flow graph; Based on the variable types in the preceding program segment and the succeeding program segment of each program segment, updating the variable information in each program segment; Obtain variable information associated with the entity unit in each program segment.

3. The IoT smart home scenario security analysis method according to claim 1, It is characterized in that Based on the device entity, linkage rules and physical channels of the Internet of Things, an Internet of Things model composed of entity units is constructed, specifically including: Based on the device entities, linkage rules, physical channels of the Internet of Things and entity relationships between the entity units, an Internet of Things model composed of entity units is constructed in the form of a finite state automaton.

4. The IoT smart home scenario security analysis method according to claim 1, It is characterized in that In the Internet of Things model, a depth-first algorithm is used to detect whether there is a path between the trigger entity units in the linkage rule, specifically including: Selecting a first trigger entity unit and a second trigger entity unit corresponding to trigger conditions in two different IoT application linkage rules; In the Internet of Things model, a depth-first traversal is started from the first trigger entity unit, and the traversal path is recorded; Determine whether the second trigger entity unit exists in the traversal path; if so, It is determined that there is a path between the trigger entity units in the linkage rule.

5. An IoT smart home scenario security analysis device, It is characterized in that include: An extraction module is used to perform static program analysis on the IoT application source code to extract device entities and linkage rules, specifically including constructing an inter-program control flow graph based on an abstract syntax tree generated during the IoT application source code compilation process; Using the reachable definition algorithm in static program analysis and the inter-program control flow graph, data flow analysis is performed on the source code of the Internet of Things application to extract device entities and linkage rules; An identification module is used to identify the description text of the IoT device function and the IoT application purpose to obtain the IoT physical channel, specifically including using a preset news vector model to vectorize the entries in the description text to obtain corresponding word vectors; Clustering the word vectors and extracting selected words as physical channels of the Internet of Things; A construction module, for constructing an Internet of Things model composed of entity units based on the device entity, linkage rules and physical channels of the Internet of Things, specifically including defining entity relationships between entity units in the Internet of Things model, wherein the entity relationships include read operations and write operations, and the entity units include users, energy, platform systems, environmental channels, functions, attributes, and instructions; The detection module is used to detect whether there is a path between the trigger entity units in the linkage rules and whether the trigger entity units of different Internet of Things applications have accessibility to the same functional attribute or the physical channel in the Internet of Things model by using a depth-first algorithm, so as to determine the risk factors of the Internet of Things smart home scenario.

6. A computing device, include: at least one processor; as well as A memory storing instructions, which, when executed by the at least one processor, causes the at least one processor to perform the method according to any one of claims 1 to 4.

7. A machine-readable storage medium storing executable instructions, wherein when the instructions are executed, the machine executes the method according to any one of claims 1 to 4.

Images