JP2019507971A - System and method for establishing a secondary communication channel for controlling an internet of things (IoT) device - Google Patents

Abstract

  Systems and methods for establishing a secondary communication channel between an IoT device and a client device are described. For example, one embodiment of the method uses a primary key set to establish a primary secure communication channel between the IoT device and the IoT service, and uses the primary secure communication channel. Performing a secondary key exchange, wherein the client device and the IoT device are each provided with a secondary key set after the secondary key exchange, and a primary secure communication channel is operating Detecting the inability and, accordingly, establishing a secondary secure wireless connection between the client device and the IoT device using the secondary key set, the client The device is provided with access to data and functions made available by the IoT device via a secondary secure wireless connection.

Description

(background)
The present invention relates generally to the field of computer systems. More specifically, the present invention relates to systems and methods for establishing a secondary communication channel to control an IoT device.

  "Internet of Things" refers to the interconnection of devices that are uniquely identifiable within the Internet infrastructure. Finally, IoT has a broad spectrum that virtually any type of physical thing can provide information about itself or its surroundings and / or can be remotely controlled via a client device across the Internet It is expected to bring new types of applications.

The assignee of the present application has developed a system in which an IoT device performs secure key exchange to establish a secure communication channel with an IoT service. Once a secure communication channel is established, the IoT service may securely control and receive data from the IoT device. However, in some cases, for example, when the IoT service is inaccessible (eg, when network connectivity is lost), enabling the second channel to be established by the IoT device It may be preferable.
A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings.

7 illustrates different embodiments of the IoT system architecture. 7 illustrates different embodiments of the IoT system architecture. 1 illustrates an IoT device according to an embodiment of the present invention. 1 illustrates an IoT hub according to an embodiment of the present invention. Fig. 6 illustrates an embodiment of the invention for controlling and collecting data from IoT devices and generating notifications. Fig. 6 illustrates an embodiment of the invention for controlling and collecting data from IoT devices and generating notifications. FIG. 5 illustrates an embodiment of the present invention for collecting data from IoT devices and generating notifications from IoT hubs and / or IoT services. 1 illustrates one embodiment of a system in which an intermediate mobile device collects data from fixed IoT devices and provides data to an IoT hub. 5 illustrates intermediate connection logic implemented in an embodiment of the present invention. 5 illustrates a method according to an embodiment of the present invention. 7 illustrates one embodiment in which program code and data updates are provided to an IoT device. 4 illustrates one embodiment of how program code and data updates are provided to an IoT device. 7 illustrates a high level diagram of one embodiment of a security architecture. 1 illustrates one embodiment of an architecture in which a subscriber identity module (SIM) is used to store keys on an IoT device. 1 illustrates one embodiment in which an IoT device is registered using barcode or QR code (registered trademark). 8 illustrates one embodiment in which pairing is performed using barcodes or QR codes. 7 illustrates one embodiment of a method for programming a SIM using an IoT hub. 7 illustrates one embodiment of a method for registering an IoT device with an IoT hub and an IoT service. 7 illustrates one embodiment of a method for encrypting data sent to an IoT device. 5 illustrates different embodiments of the present invention for encrypting data between an IoT service and an IoT device. 5 illustrates different embodiments of the present invention for encrypting data between an IoT service and an IoT device. Fig. 5 illustrates an embodiment of the invention for performing secure key exchange, generating a common secret, and generating a key stream using the secret. Fig. 6 illustrates a packet structure according to an embodiment of the present invention. 8 illustrates a technique used in one embodiment to read and write data to and from an IoT device without pairing with the IoT device formally. FIG. 7 illustrates an exemplary set of command packets used in one embodiment of the present invention. 7 illustrates an exemplary sequence of transactions using command packets. 5 illustrates a method according to an embodiment of the present invention. 6 illustrates a method for secure pairing according to an embodiment of the present invention. 6 illustrates a method for secure pairing according to an embodiment of the present invention. 6 illustrates a method for secure pairing according to an embodiment of the present invention. 1 illustrates a system architecture in accordance with an embodiment of the present invention. 1 illustrates an integrated secure IoT device according to one embodiment of the present invention. It is illustrated here that an integral secure IoT device may be coupled to the door according to an embodiment of the present invention. 5 illustrates another embodiment of the invention comprising a pressure sensor. 5 illustrates another embodiment of the invention comprising a pressure sensor. 5 illustrates a method according to an embodiment of the present invention. 1 illustrates a system architecture that supports secondary communication channels. 7 illustrates a method for implementing a secondary communication channel. 5 illustrates one embodiment of the present invention for adjusting advertising intervals to identify data transmission conditions. 5 illustrates a method according to an embodiment of the present invention. FIG. 7 illustrates exemplary command and response patterns according to one embodiment of the present invention. 1 illustrates one embodiment of the present invention for obscuring wireless communication patterns. 7 illustrates another embodiment for obscuring communication between an IoT service and an IoT device 101. 5 illustrates a method according to an embodiment of the present invention. 5 illustrates another method according to an embodiment of the present invention. 5 illustrates one embodiment of the present invention for adjusting advertising intervals to identify data transmission conditions. 5 illustrates a method according to an embodiment of the present invention.

  In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the present invention described below. However, it will be apparent to those skilled in the art that embodiments of the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the underlying principles of embodiments of the present invention.

  One embodiment of the present invention includes the Internet of Things (IoT) platform that can be utilized by developers to design and build new IoT devices and applications. Specifically, one embodiment includes an IoT device including a predetermined networking protocol stack, and a basic hardware / software platform for an IoT hub where the IoT device is connected to the Internet. In addition, one embodiment includes IoT services through which the IoT hub and connected IoT devices may be accessed and managed as described below. In addition, one embodiment of the IoT platform includes an IoT application or web application (eg, running on a client device) that accesses and configures IoT services, hubs, and connected devices. Existing online retailers and other website operators can easily provide their own IoT functionality to their existing user base using the IoT platform described herein.

  FIG. 1A illustrates an overview of an architectural platform on which embodiments of the present invention can be implemented. Specifically, the illustrated embodiment includes a plurality of communicatively coupled via a local communication channel 130 to a central IoT hub 110, which is itself communicatively coupled to the IoT service 120 via the Internet 220. The IoT devices 101 to 105 are included. Each of the IoT devices 101-105 can be initially paired with the IoT hub 110 to enable each of the local communication channels 130 (e.g., using pairing techniques described below). In one embodiment, the IoT service 120 includes an end user database 122 for maintaining user account information and data collected from each user's IoT device. For example, if the IoT device includes sensors (eg, temperature sensors, accelerometers, heat sensors, motion detectors, etc.), the database 122 is continually updated to store data collected by the IoT devices 101-105 It can be done. The data stored in database 122 may then be delivered to the end user via an IoT application or browser installed on user device 135 (or via a desktop or other client computer system), and to a web client (eg, The website 130 that subscribes to the IoT service 120 may be made accessible.

  The IoT devices 101 to 105 collect information about themselves and their surroundings, and provide the collected information to the IoT service 120, the user device 135, and / or the external website 130 through the IoT hub 110. And various types of sensors may be provided. Some of the IoT devices 101-105 can perform designated functions in response to control commands sent via the IoT hub 110. Various examples and control commands of information collected by the IoT devices 101-105 are provided below. In one embodiment described below, the IoT device 101 is a user input device designed to record user preferences and transmit user preferences to the IoT service 120 and / or a website.

  In one embodiment, the IoT hub 110 includes a cellular radio that establishes a connection to the Internet 220 via a cellular service 115 such as 4G (eg, mobile WiMAX, LTE) or 5G cellular data service. Alternatively, or in addition, the IoT hub 110 can include a WiFi radio to establish a WiFi connection via a WiFi access point or router 116, which connects the IoT hub 110 to the Internet (e.g. Connect through Internet service providers that provide Internet services to users. It should be appreciated that the basic principles of the present invention are not limited to any particular type of communication channel or protocol.

  In one embodiment, the IoT devices 101-105 are ultra low power devices that can operate for long periods of time (eg, several years) on battery power. To conserve power, the local communication channel 130 can be implemented using low power wireless communication technologies such as Bluetooth Low Energy (LE). In this embodiment, each of the IoT devices 101-105 and the IoT hub 110 is equipped with a Bluetooth LE radio and a protocol stack.

  As mentioned above, in one embodiment, the IoT platform enables users to access and configure the connected IoT devices 101-105, the IoT hub 110, and / or the IoT service 120, It includes an IoT application or web application executed on the user device 135. In one embodiment, the application or web application may be designed by the operator of website 130 to provide IoT functionality to its user base. As illustrated, the website can maintain a user database 131 that contains account records associated with each user.

  FIG. 1B illustrates additional connection options for multiple IoT hubs 110-111, 190. In this embodiment, a single user may have multiple hubs 110-111 installed on-site at a single user premises 180 (e.g., the user's home or business). This may be done, for example, to extend the radio range needed to connect all of the IoT devices 101-105. As mentioned above, if the user has multiple hubs 110, 111, they may be connected via a local communication channel (eg, Wifi, Ethernet, Powerline Networking, etc.). In one embodiment, each of the hubs 110-111 can establish a direct connection to the IoT service 120 via a cellular 115 or WiFi 116 connection (not explicitly shown in FIG. 1B). Alternatively, or in addition, one of the IoT hubs, such as IoT hub 110, can function as a "master" hub, which is associated with all other user premises 180, such as IoT hub 111 Provide connectivity and / or local services to the IoT hub (as shown by the dotted line connecting the IoT hub 110 and the IoT hub 111). For example, the master IoT hub 110 may be the only IoT hub that establishes a direct connection to the IoT service 120. In one embodiment, only the "master" IoT hub 110 is equipped with a cellular communication interface to establish a connection to the IoT service 120. Thus, all communication between the IoT service 120 and the other IoT hubs 111 flows through the master IoT hub 110. In this role, the master IoT hub 110 is responsible for the data exchanged between the other IoT hub 111 and the IoT service 120 (eg, serving some data requests locally if possible) Additional program code may be provided to perform the filtering operation.

  No matter how the IoT hubs 110-111 are connected, in one embodiment, the IoT service 120 logically associates the hub with the user and the installed application of all of the attached IoT devices 101-105 Coupled under a single generic user interface accessible via a user device having 135 (and / or a browser based interface).

  In this embodiment, the master IoT hub 110 and one or more slave IoT hubs 111 may be WiFi network 116, Ethernet network, and / or power-line communications (PLC) networking (eg, all or one of the networks). Unit may be implemented via the user's power line), and may be connected via a local network. In addition, for IoT hubs 110-111, each of the IoT devices 101-105 use any type of local network channel, such as WiFi, Ethernet, PLC or Bluetooth LE, to name a few. And may be interconnected with the IoT hubs 110-111.

  FIG. 1B also shows the IoT hub 190 installed on the second user premises 181. A substantially unlimited number of such IoT hubs 190 may be installed and configured to collect data from IoT devices 191-192 at user premises around the world. In one embodiment, two user premises 180-181 may be configured for the same user. For example, one user premises 180 may be the user's basic home and the other user premises 181 may be the user's vacation home. In such a case, the IoT service 120 logically associates the IoT hubs 110-111, 190 with the user, and attaches all attached IoT devices 101-105, 191-192 to a single comprehensive user interface. Coupled down and accessible via a user device having the installed application 135 (and / or a browser based interface).

  As illustrated in FIG. 2, an exemplary embodiment of the IoT device 101 includes a memory 210 for storing program code and data 201-203, and a low power microcontroller 200 for executing program code and processing data. . The memory 210 may be volatile memory such as dynamic random access memory (DRAM) or non-volatile memory such as flash memory. In one embodiment, non-volatile memory may be used for persistent storage and volatile memory may be used to execute program code and execute data. Furthermore, memory 210 may be integrated within low power microcontroller 200 and may be coupled to low power microcontroller 200 via a bus or communication fabric. The underlying principles of the present invention are not limited to any particular implementation of memory 210.

  As illustrated, the program code is an application that defines an application specific function set to be executed by the IoT device 201 and the library code 202, including a set of predefined building blocks that may be utilized by application developers of the IoT device 101. Program code 203 may be included. In one embodiment, library code 202 is a set of basic functions required to implement an IoT device, such as communication protocol stack 201, to enable communication between each IoT device 101 and IoT hub 110. including. As mentioned above, in one embodiment, communication protocol stack 201 includes a Bluetooth LE protocol stack. In this embodiment, the Bluetooth LE radio and antenna 207 may be integrated into the low power microcontroller 200. However, the basic principles of the invention are not limited to any particular communication protocol.

  The particular embodiment shown in FIG. 2 also includes multiple input devices or sensors 210 that receive user input and provide user input to the low power microcontroller, the low power microcontroller comprising application code 203 and library code 202. Process user input according to. In one embodiment, each of the input devices includes an LED 209 that provides feedback to the end user.

  In addition, the illustrated embodiment includes a battery 208 for providing power to the low power microcontroller. In one embodiment, a non-rechargeable coin cell battery is used. However, in another embodiment, an integrated rechargeable battery can be used (e.g., rechargeable by connecting the IoT device to an AC power supply (not shown)).

  A speaker 205 is also provided for generating audio. In one embodiment, low power microcontroller 299 decodes the compressed audio stream (eg, MPEG-4 / Advanced Audio Coding (AAC) stream) to generate audio on speaker 205 Include audio decoding logic. Alternatively, digitally sampled audio for providing low end microcontroller 200 and / or application code / data 203 with verbal feedback to the end user when the user inputs a selection via input device 210. It can contain snippets.

  In one embodiment, one or more other / alternative I / O devices or sensors 250 may be included in the IoT device 101 based on the particular application for which the IoT device 101 is designed. For example, environmental sensors can be included to measure temperature, pressure, humidity, and the like. If the IoT device is used as a security device, security sensors and / or door lock openers may be included. Of course, these examples are provided for illustration only. The basic principles of the invention are not limited to any particular type of IoT device. In fact, given the highly programmable nature of low power microcontroller 200 with library code 202, application developers can easily develop new application code 203 and new I / O device 250, substantially It can interface with low power microcontrollers for any type of IoT application.

  In one embodiment, the low power microcontroller 200 also includes a secure key store for encrypting communications and / or storing cryptographic keys for generating signatures. Alternatively, the key may be secured in a subscriber identity module (SIM).

  In one embodiment, a wakeup receiver 207 is included to wake up the IoT device from a substantially powerless ultra-low power state. In one embodiment, the wakeup receiver 207 responds to the wakeup signal received from the wakeup transmitter 307 configured on the IoT hub 110 as shown in FIG. It is configured to get out of the power state. Specifically, in one embodiment, the transmitter 307 and receiver 207 together form an electrical resonant transformer circuit, such as a Tesla coil. In operation, when the hub 110 needs to recover the IoT device 101 from a very low power state, energy is transmitted from the transmitter 307 via a radio frequency signal to the receiver 207. Because of energy transfer, the IoT device 101 can be configured to consume substantially no power when it is in a low power state, as there is no need to continually "listen" to the signal from the hub (The device can be activated via network signaling, as in the case of network protocols). Rather, the microcontroller 200 of the IoT device 101 can be configured to wake up after being effectively powered down by using the energy electrically transmitted from the transmitter 307 to the receiver 207.

  As illustrated in FIG. 3, the IoT hub 110 also includes a memory 317 for storing program code and data 305, and hardware logic 301 such as a microcontroller for executing the program code and processing the data. . A wide area network (WAN) interface 302 and an antenna 310 couple the IoT hub 110 to a cellular service 115. Alternatively, as mentioned above, the IoT hub 110 may also include a local network interface (not shown) such as a WiFi interface (and a WiFi antenna) or an Ethernet interface to establish a local area network communication channel. In one embodiment, hardware logic 301 also includes a secure key store for encrypting communications and / or storing cryptographic keys for generating / verifying signatures. Alternatively, the key may be secured in a subscriber identity module (SIM).

  The local communication interface 303 and the antenna 311 establish a local communication channel with each of the IoT devices 101-105. As mentioned above, in one embodiment, the local communication interface 303 / antenna 311 implements the Bluetooth LE standard. However, the underlying principles of the present invention are not limited to any particular protocol for establishing a local communication channel with the IoT devices 101-105. Although shown as separate units in FIG. 3, WAN interface 302 and / or local communication interface 303 may be incorporated within the same chip as hardware logic 301.

  In one embodiment, the program code and data include a communication protocol stack 308 that can include separate stacks for communicating via the local communication interface 303 and the WAN interface 302. In addition, device pairing program code and data 306 may be stored in memory so that the IoT hub can be paired with a new IoT device. In one embodiment, each new IoT device 101-105 is assigned a unique code that is communicated to the IoT hub 110 during the pairing process. For example, the unique code may be embedded in the barcode on the IoT device and may be read by the barcode reader 106 or may be communicated via the local communication channel 130. In another embodiment, a unique ID code is magnetically integrated into the IoT device, such as an IoT hub, such as a radio frequency ID (RFID) or near field communication (NFC) sensor, etc. And detect codes when the IoT device 101 moves within several inches of the IoT hub 110.

  In one embodiment, once the unique ID is communicated, the IoT hub 110 queries a local database (not shown), performs hashing to verify that the code is acceptable, and By communicating with the IoT service 120, the user device 135, and / or the website 130, the unique ID can be verified to validate the ID code. Once validated, in one embodiment, the IoT hub 110 pairs the IoT device 101 and pairing data to the memory 317 (which may include non-volatile memory as described above) Remember. Once pairing is complete, the IoT hub 110 can connect with the IoT device 101 to perform the various IoT functions described herein.

  In one embodiment, an organization running IoT services 120 can provide an IoT hub 110 and a base hardware / software platform so that developers can easily design new IoT services. Specifically, in addition to the IoT hub 110, the developer may be provided with a software development kit (SDK) for updating program code and data 305 executed in the hub 110. Good. In addition, for IoT devices 101, the SDK is based on IoT hardware (eg, low power microcontroller 200 and other components shown in FIG. 2) to facilitate the design of various different types of applications 101. May include a broad set of library code 202 designed for. In one embodiment, the SDK includes a graphical design interface that the developer need only specify inputs and outputs of the IoT device. All networking code, including the communication stack 201 that allows the IoT device 101 to connect to the hub 110 and the service 120, is already deployed for the developer. In addition, in one embodiment, the SDK also includes a library code base that facilitates the design of applications for mobile devices (e.g., iPhone (R) and Android (R) devices).

  In one embodiment, IoT hub 110 manages a continuous bi-directional stream of data between IoT devices 101-105 and IoT service 120. In situations where updates to / from IoT devices 101-105 are required in real time (e.g. situations where the user needs to see the current status of security devices or environmental measurements), the IoT hub An open TCP socket can be maintained to provide periodic updates to external website 130. The particular networking protocol used to provide the update may be adjusted based on the needs of the base application. For example, if it may not make sense to have a continuous bi-directional stream, a simple request / response protocol can be used to gather information when needed.

  In one embodiment, both the IoT hub 110 and the IoT devices 101-105 can be automatically updated via the network. Specifically, when a new update is available for the IoT hub 110, the update can be automatically downloaded and installed from the IoT service 120. It may first copy the updated code to local memory and execute it to verify the update before replacing the old program code. Similarly, if updates are available for each of the IoT devices 101-105, the updates may be initially downloaded by the IoT hub 110 and pushed out to each of the IoT devices 101-105. Each IoT device 101-105 can apply the update in a manner similar to that described above for the IoT hub and report the results of the update to the IoT hub 110. If the update is successful, the IoT hub 110 removes the update from its memory and (for example, keeps on checking for new updates for each IoT device) of the code installed on each IoT device The latest version can be recorded.

  In one embodiment, the IoT hub 110 is powered via A / C power. Specifically, the IoT hub 110 can include a power supply unit 390 with a transformer for converting the A / C voltage supplied via the A / C power cord to a lower DC voltage.

  FIG. 4A illustrates one embodiment of the present invention for performing universal remote control operations using an IoT system. Specifically, in this embodiment, the set of IoT devices 101-103 includes a variety of different types including air conditioners / heaters 430, lighting systems 431, and audiovisual equipment 432 (to name but a few) An infrared (IR) and / or radio frequency (RF) blasters 401-403 are provided for transmitting remote control codes for controlling the electronic devices of the invention. In the embodiment shown in FIG. 4A, the IoT devices 101-103 are also each equipped with sensors 404-406 for detecting the operation of the devices they control, as described below.

  For example, the sensor 404 in the IoT device 101 is a temperature and / or humidity sensor for detecting the current temperature / humidity and accordingly controlling the air conditioner / heater 430 based on the current desired temperature. It is also good. In this embodiment, the air conditioner / heater 430 is designed to be controlled via a remote control device (typically a remote control that itself incorporates a temperature sensor therein). is there. In one embodiment, the user provides the desired temperature to the IoT hub 110 via an application or browser installed on the user device 135. The control logic 412 running on the IoT hub 110 receives the current temperature / humidity data from the sensor 404 and, accordingly, controls the IR / RF blaster 401 according to the desired temperature / humidity. Send command to For example, if the temperature is below the desired temperature, the control logic 412 may send a command to the air conditioner / heater via the IR / RF blaster 401 to raise the temperature (eg, air conditioner) (By either turning off or turning on the heater). The command may include the necessary remote control code stored in the database 413 on the IoT hub 110. Alternatively or additionally, the IoT service 421 may implement control logic 421 to control the electronics 430-432 based on specified user preferences and stored control code 422.

  The IoT device 102 in the illustrated embodiment is used to control the lighting 431. Specifically, the sensor 405 of the IoT device 102 is a light sensor or light detector configured to detect the current brightness of the light being provided by the lighting fixture 431 (or other lighting device) May be The user may specify a desired illumination level (including an on or off indication) to the IoT hub 110 via the user device 135. In response, the control logic 412 sends a command to the IR / RF blaster 402 to control the current intensity level of the illumination 431 (eg, brighten the illumination if the current intensity is too low, or Or dim the light if the current brightness is too high, or simply turn the light on or off).

  The IoT device 103 in the illustrated embodiment is configured to control audiovisual equipment 432 (eg, television, A / V receiver, cable / satellite receiver, AppleTVTM, etc.). The sensor 406 of the IoT device 103 is based on light generated by an audio sensor (eg, a microphone and associated logic) and / or a television to detect a current ambient volume level (eg, in a designated spectrum) It may be a light sensor to detect whether the television is on or off by measuring the light). Alternatively, sensor 406 may include a temperature sensor connected to the audiovisual device to detect whether the audio device is on or off based on the detected temperature. Again, in response to user input via the user device 135, the control logic 412 may send commands to the audiovisual device via the IR blaster 403 of the IoT device 103.

  It should be noted that the above are merely illustrative examples of an embodiment of the present invention. The basic principles of the invention are not limited to any particular type of sensor or device controlled by an IoT device.

  In embodiments where IoT devices 101-103 are coupled to IoT hub 110 via a Bluetooth LE connection, sensor data and commands are transmitted via a Bluetooth LE channel. However, the basic principles of the invention are not limited to Bluetooth LE or any other communication standard.

  In one embodiment, the control code needed to control each of the electronic devices is stored in database 413 on IoT hub 110 and / or database 422 on IoT service 120. As illustrated in FIG. 4B, control code may be provided from the master database of control code 422 to the IoT hub 110 for different devices maintained on the IoT service 120. The end user may specify the type of electronic (or other) equipment controlled via the application or browser running on the user device 135, in response to remote control code learning on the IoT hub Module 491 may obtain the required IR / RF code from remote control code database 492 on IoT service 120 (eg, identify each electronic device with a unique ID).

  In addition, in one embodiment, the IoT hub 110 allows the remote control code learning module 491 to "learn" a new remote control code directly from the original remote control 495 provided with the electronics. , IR / RF interface 490. For example, if the control code of the original remote control provided with the air conditioner 430 is not included in the remote control database, the user interacts with the IoT hub 110 via the application / browser on the user device 135 Then, various control codes generated by the original remote control device may be taught to the IoT hub 110 (eg, temperature increase, temperature decrease, etc.). As remote control codes are learned, they may be stored in the control code database 413 on the IoT hub 110 and / or sent back to the IoT service 120 to be included in the central remote control code database 492 (May be subsequently used by other users having the same air conditioner unit 430).

  In one embodiment, each of the IoT devices 101-103 has an extremely small form factor and is on or near their corresponding electronics 430-432 using double-sided tape, small nails, magnetic attachments, etc. It may be attached to In order to control one device, such as air conditioner 430, it is desirable to position IoT device 101 far enough to allow sensor 404 to accurately measure the ambient temperature in the home (eg, If you place the IoT device directly on the air conditioner, the temperature measurement will be too low when the air conditioner is operating and will be too high when the heater is operating). In contrast, the IoT device 102 used to control the lighting may be located on or near the lighting fixture 431 in order for the sensor 405 to detect the current lighting level.

  In addition to providing the general control functionality described, one embodiment of the IoT hub 110 and / or the IoT service 120 sends notifications to end users related to the current state of each electronic device. The notification may be a text message and / or an application specific notification, which may then be displayed on the display of the mobile device 135 of the user. For example, if the user's air conditioning unit is on for a long time but the temperature has not changed, the IoT hub 110 and / or the IoT service 120 sends a notification to the user that the air conditioning unit is not functioning properly. May be If the user is not at home (which may be detected via the motion sensor or may be based on the user's current detected position), the sensor 406 may be on the audiovisual device 430 Or if the sensor 405 indicates that the light is on, a notification may be sent to the user asking if the user wishes to turn off the audiovisual device 432 and / or the light 431. The same type of notification may be sent for any device type.

  When the user receives the notification, he / she may remotely control the electronic device 430-432 via an application or browser on the user device 135. In one embodiment, the user device 135 is a touch screen device, and the application or browser displays an image of a remote control including user selectable buttons for controlling the devices 430-432. After receiving the notification, the user may open the graphical remote control and turn off or adjust various different devices. If connected via IoT service 120, user preferences may be transferred from IoT service 120 to IoT hub 110, which will then control the device via control logic 412. . Alternatively, user input may be sent directly from user device 135 to IoT hub 110.

  In one embodiment, the user may program the control logic 412 on the IoT hub 110 to perform various automatic control functions on the electronic devices 430-432. In addition to maintaining the desired temperature, brightness level, and volume level described above, control logic 412 may automatically turn off the electronics when certain conditions are detected. For example, if the control logic 412 detects that the user is not at home and the air conditioner is not functioning, the control logic 412 may automatically turn off the air conditioner. Similarly, if the user is not at home and the sensor 406 indicates that the audiovisual device 430 is on, or if the sensor 405 indicates that the illumination is on, then the control logic 412 controls the audiovisual device and the illumination. The commands may be sent automatically via the IR / RF blasters 403 and 402 to turn off each of the

  FIG. 5 illustrates an additional embodiment of IoT devices 104 and 105 with sensors 503 and 504 for monitoring electronics 530 and 531. Specifically, the IoT device 104 of this embodiment includes a temperature sensor 503 that may be placed on or near the stove 530 to detect when the stove remains on. In one embodiment, the IoT device 104 transmits the current temperature measured by the temperature sensor 503 to the IoT hub 110 and / or the IoT service 120. If it is detected that the stove is on for more than a threshold period (eg, based on the measured temperature), control logic 512 may notify the end user of a notification to the user that stove 530 is on. It may be sent to the device 135. Additionally, in one embodiment, the IoT device 104 is either responsive to receiving an instruction from the user or automatically (if the control logic 512 is programmed by the user to do so) May include a control module 501 for turning the stove off. In one embodiment, the control logic 501 comprises a switch to shut off the electricity or gas to the stove 530. However, in other embodiments, control logic 501 may be integrated within the stove itself.

  FIG. 5 also illustrates an IoT device 105 having a motion sensor 504 for detecting the motion of certain types of electronic devices, such as a washer and / or dryer. Another sensor that may be used is an audio sensor (eg, a microphone and logic) to detect ambient volume levels. As with the other embodiments described above, this embodiment may send a notification to the end user if certain specified conditions are met (e.g. operation is detected for a long time, washing machine / Indicate that the dryer is not turned off). Although not shown in FIG. 5, the IoT device 105 also turns off the washer / dryer 531 (eg, by switching off electricity / gas) automatically and / or in response to user input. A control module may be provided.

  In one embodiment, a first IoT device having control logic and a switch may be configured to turn off all power in the user's home, and a second IoT device having control logic and a switch is , May be configured to turn off all the gas in the user's home. The IoT device with the sensor may then be located on or near an electrical or gas powered device in the user's home. If the user is notified that a particular device remains on (e.g. stove 530), the user sends a command to turn off all electricity or gas in the home to prevent damage It is also good. Alternatively, control logic 512 of IoT hub 110 and / or IoT service 120 may be configured to automatically turn off electricity or gas in such situations.

In one embodiment, the IoT hub 110 and the IoT service 120 communicate at periodic intervals. If the IoT service 120 detects that the connection to the IoT hub 110 is broken (e.g., by not receiving a request or response from the IoT hub for a specified duration), the IoT service 120 may This information will be communicated to the end user's device 135 (eg, by sending a text message or an application specific notification).
Apparatus and method for communication-Data through an intermediate device

  As mentioned above, the wireless technology used to interconnect IoT devices such as Bluetooth LE is generally a near-field technology, so if the hub for the IoT implementation is outside the scope of the IoT device, the IoT device Can not send data to the IoT hub (and vice versa).

  To address this deficiency, one embodiment of the present invention is an IoT device that is outside the wireless range of the IoT hub to periodically connect with one or more mobile devices when the mobile device is in range. Provide a mechanism for Once connected, the IoT device can transmit to the mobile device any data that needs to be provided to the IoT hub, which then transfers the data to the IoT hub.

  As illustrated in FIG. 6, one embodiment includes an IoT hub 110, an IoT device 601 that is out of range of the IoT hub 110, and a mobile device 611. Out-of-range IoT devices 601 may include any form of IoT device capable of collecting and communicating data. For example, the IoT device 601 may comprise available food products in the refrigerator, a user consuming the food product, and a data collection device configured in the refrigerator to monitor the current temperature. It will be appreciated that the basic principle of the invention is not limited to any particular type of IoT device. The technology described herein is used to collect and transmit data on smart meters, stoves, washers, dryers, lighting systems, HVAC systems, and audiovisual equipment, to name but a few. And may be implemented using any type of IoT device.

  Further, the IoT device 611 illustrated in FIG. 6, which is an operating mobile device, may be any form of mobile device capable of communicating and storing data. For example, in one embodiment, mobile device 611 is a smart phone with an application installed thereon to facilitate the techniques described herein. In another embodiment, the mobile device 611 comprises a wearable device such as a communication token attached to a necklace or bracelet, a smart watch, or a fitness device. Wearable tokens may be particularly useful for elderly users or other users who do not possess a smartphone device.

  In operation, the out-of-range IoT device 601 may periodically or continuously check connectivity with the mobile device 611. After establishing the connection (eg as a result of the user moving close to the refrigerator), any collected data 605 on the IoT device 601 is automatically sent to the temporary data repository 615 on the mobile device 611 . In one embodiment, the IoT device 601 and the mobile device 611 establish a local wireless communication channel using a low power wireless standard such as BTLE. In such case, mobile device 611 may be initially paired with IoT device 601 using known pairing techniques.

  Once the data is transmitted to the temporary data repository, the mobile device 611 transmits data once communication with the IoT hub 110 is established (eg, when the user walks within the IoT hub 110). The IoT hub may then store data in the central data repository 413 and / or send data over the Internet to one or more services and / or other user devices. In one embodiment, mobile device 611 may provide data to IoT hub 110 using a different type of communication channel (potentially a higher power communication channel such as WiFi).

  Out of range IoT devices 601, mobile devices 611, and IoT hubs may all be configured with program code and / or logic to implement the techniques described herein. As illustrated in FIG. 7, for example, to perform the operations described herein, the IoT device 601 may be configured with intermediate connection logic and / or applications, and the mobile device 611 may be configured with an intermediate connection. It may be configured by logic / application, and the IoT hub 110 may be configured by intermediate connection logic / application 721. The intermediate connection logic / application on each device may be implemented in hardware, software, or any combination thereof. In one embodiment, the intermediate connection logic / application 701 of the IoT device 601 searches for and establishes a connection with the intermediate connection logic / application 711 (which may be implemented as a device application) on the mobile device to create a temporary data repository Transmit the data to 615. The intermediate connection logic / application 701 on the mobile device 611 then transfers the data to the intermediate connection logic / application on the IoT hub that stores the data in the central data repository 413.

  As illustrated in FIG. 7, the intermediate connection logic / applications 701, 711, 721 on each device may be configured based on the application at hand. For example, for a refrigerator, the connection logic / application 701 need only send a small number of packets on a periodic basis. For other applications (eg, temperature sensors), the connection logic / application 701 may need to send more frequent updates.

  Rather than the mobile device 611, in one embodiment, the IoT device 601 may be configured to establish a wireless connection with one or more intermediate IoT devices located within the IoT hub 110. In this embodiment, any IoT device 601 outside of the IoT hub may be linked to the hub by forming a "chain" using other IoT devices.

  Additionally, although only a single mobile device 611 is illustrated in FIGS. 6 and 7 for simplicity, in one embodiment, multiple such mobile devices of different users communicate with the IoT device 601 It may be configured to Furthermore, the same technology may be implemented for multiple other IoT devices, thereby forming an intermediate device data collection system throughout the home.

  Further, in one embodiment, the techniques described herein may be used to collect various different types of related data. For example, in one embodiment, each time mobile device 611 connects with IoT device 601, the identity of the user may be included along with the collected data 605. In this way, the IoT system may be used to track the behavior of different users in the home. For example, when used in a refrigerator, the collected data 605 may include identification of each user passing by the refrigerator, each user opening the refrigerator, and the particular food item consumed by each user. Different types of data may be collected from other types of IoT devices. Using this data, the system can determine, for example, which users wash their clothes, which users watch television on a given day, the time each user goes to bed and wakes up, etc. is there. All of this crowdsource data may then be compiled into the data repository 413 of the IoT hub and / or transferred to an external service or user.

  Another useful application of the technology described herein is to monitor elderly users who may need assistance. For this application, mobile device 611 may be a very small token worn by an elderly user to collect information in different rooms of the user's home. Each time the user opens the refrigerator, for example, this data is included with the collected data 605 and transmitted to the IoT hub 110 via a token. The IoT hub may then provide data to one or more external users (eg, a child or other individual who cares for the elderly user). If the data has not been collected for a specified period of time (e.g. 12 hours), this means that the elderly user is not moving around home and / or has not opened the refrigerator. Then, the IoT hub 110 or an external service connected to the IoT hub may send alert notifications to these other individuals, notifying them that they should confirm an elderly user. In addition, the collected data 605 may be the food consumed by the user, as well as whether it is necessary to go to the grocery store, whether the elderly user is watching television and how often it is watching , And other relevant information such as the frequency with which the elderly user washes clothes.

  In another implementation, if there is a problem with an electronic device such as a washing machine, refrigerator, HVAC system, etc., the collected data may include an indication of the parts that need to be replaced. In such cases, a notification may be sent to the technician with a request to solve the problem. The technician can then arrive at home with the required replacement parts.

  A method in accordance with one embodiment of the present invention is illustrated in FIG. The method may be implemented in the context of the above architecture, but is not limited to any particular architecture.

  At 801, an IoT device that is outside the scope of the IoT hub periodically collects data (eg, opening a refrigerator door, used groceries, etc.). At 802, the IoT device periodically or continuously checks connectivity with the mobile device (e.g., using standard local wireless techniques to establish a connection, such as those specified by the BTLE standard) ). At 802, when a connection to the mobile device is established and determined, at 803, the collected data is transmitted at 803 to the mobile device. At 804, the mobile device transmits data to the IoT hub, an external service, and / or a user. As mentioned, the mobile device may transmit data immediately if it is already connected (eg, via a WiFi link).

  In addition to collecting data from IoT devices, in one embodiment, the techniques described herein may also be used to update data or otherwise provide data to IoT devices Good. An example is shown in FIG. 9A, which shows an IoT hub 110 with program code updates 901 that need to be installed on the IoT device 601 (or a group of such IoT devices). Program code updates may include system updates, patches, configuration data, and any other data needed for the IoT device to operate as requested by the user. In one embodiment, the user may specify configuration options for the IoT device 601 via the mobile device or computer, which in turn use the techniques described herein on the IoT hub 110. And stored in the IoT device. Specifically, in one embodiment, the intermediate connection logic / application 721 on the IoT hub 110 communicates with the intermediate connection logic / application 711 on the mobile device 611 to store program code updates in temporary storage 615 Do. When the mobile device 611 enters the range of the IoT device 601, the intermediate connection logic / application 711 on the mobile device 611 connects with the intermediate / connection logic / application 701 on the IoT device 601 to provide program code updates to the device Do. In one embodiment, the IoT device 601 may then enter an automatic update process for installing new program code updates and / or data.

  A method for updating an IoT device is shown in FIG. 9B. The method may be implemented in the context of the system architecture described above, but is not limited to any particular system architecture.

At 900, new program code or data updates are available on the IoT hub and / or external services (eg, coupled to a mobile device over the Internet). At 901, the mobile device receives and stores program code or data updates on behalf of the IoT device. The IoT device and / or mobile device periodically checks at 902 to determine if a connection is established. If a connection is established and determined at 903, then at 904 the update is transmitted to the IoT device and installed.
Embodiments for Improved Security

  In one embodiment, the low power microcontroller 200 of each IoT device 101 and the low power logic / microcontroller 301 of the IoT hub 110 are secure keys for storing cryptographic keys used by the embodiments described below. Contains the store (see, eg, FIGS. 10-15 and the associated text). Alternatively, the key may be secured in a subscriber identity module (SIM), as described below.

  FIG. 10 illustrates public key infrastructure (PKI) technology and / or symmetric key exchange / encryption to encrypt communications between IoT service 120, IoT hub 110, and IoT devices 101 and 102. Illustrate high-level architecture using technology.

  An embodiment using a public / private key pair is described first, followed by an embodiment using a symmetric key exchange / encryption technique. Specifically, in one embodiment using PKI, a unique public / private key pair is associated with each IoT device 101-102, each IoT hub 110, and IoT service 120. In one embodiment, when a new IoT hub 110 is set up, its public key is provided to the IoT service 120, and when a new IoT device 101 is set up, its public key is distributed to both the IoT hub 110 and the IoT service 120. Provided. Various techniques for securely exchanging public keys between devices are described below. In one embodiment, a parent key in which all public keys are known to all of the receiving devices so that any receiving device can verify the validity of the public key by verifying the validity of the signature That is, it is signed by a kind of certificate). Thus, rather than merely exchanging the raw public key, these certificates will be exchanged.

  As illustrated, in one embodiment, each IoT device 101, 102 includes a secure key store 1001, 1003, respectively, for security storing the secret key of each device. Security logic 1002, 1304 then performs the encryption / decryption operations described herein using the secret key stored securely. Similarly, the IoT hub 110 uses the IoT hub secret key and the secure storage device 1011 for storing the IoT devices 101 to 102 and the public key of the IoT service 120, and the encryption / decryption operation using the key. It includes security logic 1012 to execute. Finally, the IoT service 120 communicates with the IoT hub and devices using a secure storage device 1021 for security storing its own secret key, various IoT devices and the public key of the IoT hub, and the key. May include security logic 1013 to encrypt / decrypt. In one embodiment, when IoT hub 110 receives a public key certificate from the IoT device, IoT hub 110 validates it (eg, by verifying the signature using the parent key described above). Then, the public key can be extracted therefrom, and the public key can be stored in the secure key store 1011.

  As an example, in one embodiment, the IoT service 120 sends a command or data (eg, a command to unlock the door, a request to read a sensor, data to be processed / displayed by the IoT device, etc.) to the IoT device 101 When necessary, the security logic 1013 encrypts the data / command using the IoT device's 101 public key to generate an encrypted IoT device packet. In one embodiment, the security logic 1013 then encrypts the IoT device packet using the public key of the IoT hub 110 to generate an IoT hub packet and sends the IoT hub packet to the IoT hub 110. In one embodiment, service 120 uses its private key or the above-mentioned parent key so that device 101 can verify that it has received an unaltered message from a trusted source. Sign the encrypted message. The device 101 may then use the public key corresponding to the private key and / or the parent key to verify the validity of the signature. As mentioned above, symmetric key exchange / encryption techniques may be used instead of public / private key encryption. In these embodiments, rather than storing one key privately and providing the corresponding public key to the other device, to each device for encryption and to validate the signature. You may provide a copy of the same symmetric key as that used in. One example of a symmetric key algorithm is the Advanced Encryption Standard (AES), but the basic principles of the invention are not limited to any type of specific symmetric key.

  Using a symmetric key implementation, each device 101 enters a secure key exchange protocol to exchange symmetric keys with the IoT hub 110. A secure key provisioning protocol such as Dynamic Symmetric Key Provisioning Protocol (DSKPP) may be used to exchange keys over a secure communication channel (e.g. Request for Comments) ) (RFC) 6063)). However, the basic principles of the invention are not limited to any particular key provisioning protocol.

  Once symmetric keys are exchanged, they can be used by each device 101 and the IoT hub 110 to encrypt communications. Similarly, IoT hub 110 and IoT service 120 may perform secure symmetric key exchange and then encrypt communications using the exchanged symmetric key. In one embodiment, new symmetric keys are exchanged periodically between the device 101 and the hub 110 and between the hub 110 and the IoT service 120. In one embodiment, on each new communication session between device 101, hub 110 and service 120, a new symmetric key is exchanged (eg, a new key is generated for each communication session and exchanged securely) ). In one embodiment, if the security module 1012 in the IoT hub is trusted, the service 120 may negotiate a session key with the hub security module 1312 and then the security module 1012 negotiates a session key with each device 120 It will be. The message from service 120 is then decrypted and verified at hub security module 1012, and then re-encrypted for transmission to device 101.

  In one embodiment, a one-time (permanent) installation key may be negotiated between the device 101 and the service 120 at installation time to prevent a security breach at the hub security module 1012. When sending a message to the device 101, the service 120 may first encrypt / MAC using this device installation key and then encrypt / MAC it using the hub's session key. The hub 110 will then verify and extract the encrypted device blob and send it to the device.

  In one embodiment of the invention, a counter mechanism is implemented to prevent replay attacks. For example, each successive communication from device 101 to hub 110 (or vice versa) may be assigned a continuously increasing counter value. Both the hub 110 and the device 101 track this value and verify that the value is correct in each successive communication between the devices. The same technology may be implemented between the hub 110 and the service 120. Using counters in this way will make it more difficult to spoof communication between devices (because the counter values will be incorrect). However, without this, the installation key shared between the service and the device will prevent network (hub) scale attacks on all devices.

  In one embodiment, when using public / private key encryption, the IoT hub 110 decrypts the IoT hub packet using its private key, generates an encrypted IoT device packet, and associates it To the selected IoT device 101. Then, the IoT device 101 decrypts the IoT device packet using the secret key to generate a command / data originating from the IoT service 120. The IoT device 101 may then process the data and / or execute commands. Using symmetric encryption, each device performs encryption and decryption using a shared symmetric key. In any case, each sending device may also sign the message with its private key so that the receiving device can verify the authenticity of the message.

  Different sets of keys may be used to encrypt the communication from the IoT device 101 to the IoT hub 110 and the communication to the IoT service 120. For example, using one public / private key configuration, in one embodiment, security logic 1002 on IoT device 101 encrypts data packets sent to IoT hub 110 using the public key of IoT hub 110. Do. Security logic 1012 on IoT hub 110 may then decrypt the data packet using the IoT hub's secret key. Similarly, security logic 1002 on IoT device 101 and / or security logic 1012 on IoT hub 110 may encrypt data packets sent to IoT service 120 using the IoT service 120's public key. May then be decrypted by the security logic 1013 on the IoT service 120 using the service's private key). Using a symmetric key, device 101 and hub 110 may share one symmetric key while hub and service 120 may share different symmetric keys.

  Although in the above description certain specific details have been described above, it should be noted that the basic principles of the invention can be implemented using various different encryption techniques. For example, while some embodiments described above use asymmetric public / private key pairs, other embodiments securely exchange between various IoT devices 101-102, IoT hub 110, and IoT service 120 Can use symmetric keys. Furthermore, in some embodiments, the data / command itself is not encrypted but a key is used to generate a signature on the data / command (or other data structure). The recipient may then use the key to validate the signature.

  As illustrated in FIG. 11, in one embodiment, the secure keystore on each IoT device 101 is implemented using a programmable subscriber identity module (SIM) 1101. In this embodiment, the IoT device 101 may be initially provided to the end user with an unprogrammed SIM card 1101 installed in the SIM interface 1100 on the IoT device 101. To program the SIM with one or more sets of cryptographic keys, the user retrieves the programmable SIM card 1101 from the SIM interface 500 and inserts it into the SIM programming interface 1102 on the IoT hub 110. The programming logic 1125 on the IoT hub then securely programs the SIM card 1101 to register / pair the IoT device 101 with the IoT hub 110 and the IoT service 120. In one embodiment, the public / private key pair may be randomly generated by the programming logic 1125, and then the public key of the pair may be stored in the secure storage device 411 of the IoT hub, The secret key may be stored in the programmable SIM 1101. In addition, the programming logic 525 may use the public key of the IoT hub 110, the IoT service 120, and / or any other IoT device 101 (for encryption of outgoing data by the security logic 1302 on the IoT device 101) ) May be stored on the SIM card 1401. Once the SIM 1101 is programmed, the new IoT device 101 is provisioned with the IoT service 120 using the SIM as a secure identifier (eg using existing technology to register the device using the SIM) obtain. After provisioning, both the IoT hub 110 and the IoT service 120 securely store a copy of the IoT device's public key for use in encrypting communications with the IoT device 101.

  The techniques described above with respect to FIG. 11 provide a great deal of flexibility in providing new IoT devices to end users. Rather than requiring users to register each SIM directly with a particular service provider for sale / purchase (as is currently done), the SIM can be directly configured by the end user via the IoT hub 110 It may be programmed and the results of the programming may be securely communicated to the IoT service 120. Therefore, new IoT devices 101 can be sold to end users from online or local retailers and IoT services 120 can be securely provisioned later.

  Although the registration and encryption techniques are described above in the specific context of a SIM (Subscriber Identity Module), the basic principle of the invention is not limited to "SIM" devices. Rather, the basic principles of the present invention may be implemented using any type of device having secure storage for storing cryptographic key sets. Furthermore, while the above embodiments include removable SIM devices, in one embodiment, the SIM device is not removable, but the IoT device itself may be inserted into the programming interface 1102 of the IoT hub 110.

  In one embodiment, rather than requiring the user to program the SIM (or other device), the SIM is preprogrammed into the IoT device 101 prior to distribution to the end user. In this embodiment, when the user sets up the IoT device 101, the various techniques described herein securely exchange cryptographic keys between the IoT hub 110 / IoT service 120 and the new IoT device 101. Can be used for

  For example, as illustrated in FIG. 12A, each IoT device 101 or SIM 401 may be packaged with a barcode or QR code 1501 that uniquely identifies the IoT device 101 and / or SIM 1001. In one embodiment, the barcode or QR code 1201 includes an encoded representation of the IoT device 101 or SIM 1001 public key. Alternatively, the barcode or QR code 1201 may be used by the IoT hub 110 and / or the IoT service 120 to identify or generate a public key (eg, already stored in a secure storage device) Used as a pointer to the public key). The barcode or QR code 601 may be printed on a separate card (as shown in FIG. 12A) or may be printed directly on the IoT device itself. Regardless of where the barcode is printed, in one embodiment, the IoT hub 110 reads the barcode and obtains the obtained data on security logic 1012 on the IoT hub 110 and / or security logic on the IoT service 120 A barcode reader 206 is provided to provide to 1013. The security logic 1012 on the IoT hub 110 may then store the IoT device's public key in its secure keystore 1011, and the security logic 1013 on the IoT service 120 in its secure storage 1021. The public key may be stored (for use in later encrypted communication).

  In one embodiment, the data contained within the barcode or QR code 1201 is also transmitted to the user device 135 (eg, an iPhone or Android device) using an installed IoT application or browser-based applet designed by the IoT service provider. Etc.). Once captured, the barcode data may be securely communicated to the IoT service 120 via a secure connection (eg, a secure sockets layer (SSL) connection, etc.). Barcode data may also be provided from client device 135 to IoT hub 110 via a secure local connection (eg, via a local WiFi or Bluetooth LE connection).

  Security logic 1002 on IoT device 101 and security logic 1012 on IoT hub 110 may be implemented using hardware, software, firmware, or any combination thereof. For example, in one embodiment, the security logic 1002, 1012 is a chip used to establish the local communication channel 130 between the IoT device 101 and the IoT hub 110 (eg, if the local channel 130 is a Bluetooth LE Is implemented in the Bluetooth LE chip). Regardless of the specific location of the security logic 1002, 1012, in one embodiment, the security logic 1002, 1012 is designed to establish a secure execution environment to execute certain types of program code. . This can be implemented, for example, by using TrustZone technology (available on some ARM processors) and / or trusted execution technology (designed by Intel). It will be appreciated that the basic principle of the invention is not limited to any particular type of secure implementation technology.

  In one embodiment, a barcode or QR code 1501 may be used to pair each IoT device 101 with the IoT hub 110. For example, instead of using the standard wireless pairing process currently used to pair Bluetooth LE devices, the IoT hub 110 is provided with a pairing code embedded in a barcode or QR code 1501 Then, the IoT hub may be paired with the corresponding IoT device.

  FIG. 12B illustrates an embodiment in which the barcode reader 206 on the IoT hub 110 captures the barcode / QR code 1201 associated with the IoT device 101. As mentioned above, the barcode / QR code 1201 may be printed directly on the IoT device 101, or may be printed on a separate card provided with the IoT device 101. In any case, the barcode reader 206 reads the pairing code from the barcode / QR code 1201 and provides the pairing code to the local communication module 1280. In one embodiment, the local communication module 1280 is a Bluetooth LE chip and associated software, but the basic principles of the invention are not limited to any particular protocol standard. When the pairing code is received, it is stored in the secure storage device including the pairing data 1285, and the IoT device 101 and the IoT hub 110 are automatically paired. Each time an IoT hub is paired with a new IoT device in this manner, pairing data regarding the pairing is stored in the secure storage device 685. In one embodiment, when the local communication module 1280 of the IoT hub 110 receives the pairing code, it may use this code as a key to encrypt communication with the IoT device 101 over the local wireless channel.

  Similarly, on the IoT device 101 side, the local communication module 1590 stores pairing data indicating pairing with the IoT hub in the local secure storage device 1595. The pairing data 1295 may include a preprogrammed pairing code identified by the barcode / QR code 1201. The pairing data 1295 is also for pairing data received from the local communication module 1280 on the IoT hub 110 (eg, to encrypt communication with the IoT hub 110, necessary to establish a secure local communication channel) Additional keys) may be included.

  Thus, the barcode / QR code 1201 can be used to perform local pairing in a much more secure manner than current wireless pairing protocols, as no pairing code is transmitted wirelessly. In addition, in one embodiment, the same bar code / QR code 1201 used for pairing is used to identify the encryption key, from IoT device 101 to IoT hub 110, and from IoT hub 110 to IoT service 120. You can build a secure connection to it.

  A method for programming a SIM card according to an embodiment of the present invention is illustrated in FIG. The method may be implemented within the system architecture described above, but is not limited to any particular system architecture.

  At 1301, the user receives a new IoT device with an empty SIM card, and at 1602, the user inserts an empty SIM card into the IoT hub. At 1303, the user programs an empty SIM card with a set of one or more encryption keys. For example, as described above, in one embodiment, the IoT hub randomly generates a public / private key pair, stores the private key on the SIM card, and stores the public key in its local secure storage device. obtain. In addition, at 1304, at least a public key is sent to the IoT service so that it can be used to identify the IoT device and establish encrypted communication with the IoT device. As mentioned above, in one embodiment, programmable devices other than the "SIM" card may be used to perform the same function as the SIM card in the manner shown in FIG.

  A method for integrating a new IoT device into a network is illustrated in FIG. The method may be implemented within the system architecture described above, but is not limited to any particular system architecture.

  At 1401, the user receives a new IoT device that has been pre-assigned an encryption key. At 1402, this key is securely provided to the IoT hub. As mentioned above, in one embodiment, this involves reading the barcode associated with the IoT device to identify the public key of the public / private key pair assigned to the device. The barcode may be read directly by the IoT hub or captured by the mobile device via an application or browser. In another embodiment, a secure communication channel such as a Bluetooth LE channel, a near field communication (NFC) channel, or a secure WiFi channel may be established between the IoT device and the IoT hub for key exchange Good. Regardless of how the key is sent, once received, the key is stored in the IoT hub device's secure keystore. As mentioned above, various secure execution technologies such as Secure Enclave, Trusted Execution Technology (TXT), and / or Trustzone are used at the IoT hub for key storage and protection It can be done. In addition, at 803, the key is securely transmitted to the IoT service, which stores the key in its own secure key store. The IoT service may then use this key to encrypt communication with the IoT device. Again, this exchange may be performed using a certificate / signed key. Within the hub 110, it is particularly important to prevent modification / addition / removal of stored keys.

  A method for securely communicating commands / data to an IoT device using a public / private key is illustrated in FIG. The method may be implemented within the system architecture described above, but is not limited to any particular system architecture.

  At 1501, the IoT service encrypts data / commands using the IoT device public key to create an IoT device packet. The IoT service then encrypts this IoT device packet using the IoT hub's public key to create an IoT hub packet (eg, create an IoT hub wrapper around the IoT device packet). At 1502, the IoT service sends an IoT hub packet to the IoT hub. At 1503, the IoT hub decrypts the IoT hub packet using the IoT hub's secret key to generate an IoT device packet. Then, at 1504, the IoT hub sends the IoT device packet to the IoT device, and the IoT device decrypts the IoT device packet at 1505 using the IoT device secret key to generate data / commands. At 1506, the IoT device processes data / commands.

In certain embodiments that use symmetric keys, symmetric key exchange may be negotiated between each device (e.g., between each device and a hub, and between a hub and a service). When the key exchange is complete, each transmitting device encrypts and / or signs each transmission using the symmetric key and then transmits the data to the receiving device.
Device and method for establishing secure communication in the Internet of Things (IoT) system

  In one embodiment of the present invention, regardless of the intermediate device used to support the communication channel (e.g., the user's mobile device 611 and / or IoT hub 110, etc.), encryption and decryption of the data may be performed using the IoT service. It is performed between 120 and each IoT device 101. One embodiment of communicating via IoT hub 110 is illustrated in FIG. 16A, and another embodiment not requiring an IoT hub is illustrated in FIG. 16B.

  First, in FIG. 16A, to encrypt / decrypt communication between the IoT device 101 and the IoT service 120, the IoT service 120 includes an encryption engine 1660 that manages a set of “service session keys” 1650, Each IoT device 101 includes an encryption engine 1661 that manages a set of “device session keys” 1651. When performing the security / encryption techniques described herein, the encryption engine generates a session public / private key pair to prevent access to the session private key of this pair (of others Different hardware modules can be relied on, including hardware security modules 1630-1631, and key stream generation modules 1640-1641 for generating key streams using derived secrets, among others. In one embodiment, service session key 1650 and device session key 1651 include associated public / private key pairs. For example, in one embodiment, the device session key 1651 on the IoT device 101 includes the public key of the IoT service 120 and the secret key of the IoT device 101. As described in detail below, in one embodiment, session public / private key pairs 1650 and 1651 are used by respective encryption engines, 1660 and 1661 respectively, to establish a secure communication session, and are identical The secret is generated and this secret is then used by the SKGMs 1640-1641 to generate a key stream that encrypts and decrypts the communication between the IoT service 120 and the IoT device 101. Additional details associated with the generation and use of secrets according to one embodiment of the present invention are provided below.

  In FIG. 16A, once the secret is generated using the keys 1650-1651, the client will always send a message to the IoT device 101 via the IoT service 120 as indicated by the clear transaction 1611. As used herein, "clear" means to indicate that the underlying message is not encrypted using the encryption techniques described herein. However, as illustrated, in one embodiment, a Secure Socket Layer (SSL) channel or other secure channel (eg, an Internet Protocol Security (IPSEC) channel) is a client to secure communications. It is established between the device 611 and the IoT service 120. The encryption engine 1660 on the IoT service 120 then encrypts the message using the generated secret and sends the encrypted message to the IoT hub 110 at 1602. Rather than using a secret to encrypt messages directly, in one embodiment, a secret and a counter value are used to generate a key stream, which is used to encrypt each message packet Turn The details of this embodiment are described below with respect to FIG.

  As illustrated, an SSL connection or other secure channel can be established between the IoT service 120 and the IoT hub 110. The IoT hub 110 (in one embodiment, having no ability to decrypt the message) sends an encrypted message to the IoT device at 1603 (eg, via a Bluetooth Low Energy (BTLE) communication channel). The encryption engine 1661 on the IoT device 101 may then decrypt the message using the secret to process the message content. In embodiments that use a secret to generate a key stream, the encryption engine 1661 generates the key stream using the secret and the counter value, and then uses the key stream to decrypt the message packet. Can.

  The message itself may include any form of communication between the IoT service 120 and the IoT device 101. For example, the message may include a command packet that instructs the IoT device 101 to perform a specific function, such as performing measurements and notifying the client device 611 of the results back, or It can include configuration data that constitutes an operation.

  If a response is required, the encryption engine 1661 on the IoT device 101 encrypts the response using the secret or derived keystream and sends an encrypted response to the IoT hub 110 at 1604, The hub 110 forwards the response to the IoT service 120 at 1605. The encryption engine 1660 on the IoT service 120 is then decrypted (eg, via SSL or other secure communication channel) at 1606, decrypting the response using the secret or derived key stream Sends a response to the client device 611.

  FIG. 16B illustrates an embodiment that does not require an IoT hub. Rather, in this embodiment, communication between the IoT device 101 and the IoT service 120 takes place via the client device 611 (e.g., as in the embodiment described above with respect to FIGS. 6-9B). In this embodiment, to send the message to the IoT device 101, the client device 611 sends a non-encrypted version of the message to the IoT service 120 at 1611. The encryption engine 1660 encrypts the message using the secret or derived key stream and sends the encrypted message back to the client device 611 at 1612. The client device 611 then forwards 1613 the encrypted message to the IoT device 101, and the encryption engine 1661 decrypts the message using the secret or derived key stream. The IoT device 101 may then process the message as described herein. If a response is required, the encryption engine 1661 encrypts the response using the secret and sends an encrypted response to the client device 611 at 1614, and the client device 611 IoT an encrypted response at 1615 Transfer to service 120 The encryption engine 1660 then decrypts the response and sends 1616 the decrypted response to the client device 611.

  FIG. 17 illustrates key exchange and key stream generation that may initially be performed between the IoT service 120 and the IoT device 101. In one embodiment, this key exchange may be performed each time IoT service 120 and IoT device 101 establish a new communication session. Alternatively, key exchange can be performed, and the exchanged session key can be used for a specified period of time (e.g., one day, one week, etc.). Although intermediate devices are not shown in FIG. 17 for simplicity, communication may occur via the IoT hub 110 and / or the client device 611.

  In one embodiment, the encryption engine 1660 of the IoT service 120 may command the HSM 1630 (eg, CloudHSM provided by Amazon®, etc.) to generate a session public / private key pair. Send to The HSM 1630 can then prevent access to this pair of session private keys. Similarly, the encryption engine on the IoT device 101 generates a session public / private key pair to prevent access to the session private key of this pair (e.g. Atecc 508 HSM by Atmel Corporation) Can send commands to). It will be appreciated that the basic principle of the invention is not limited to any particular type of encryption engine or manufacturer.

In one embodiment, the IoT service 120 transmits the session public key generated using the HSM 1630 to the IoT device 101 at 1701. The IoT device uses its HSM 1631 to generate its own session public / private key pair and sends the public key of the pair to the IoT service 120 at 1702. In one embodiment, the encryption engine 1660-1661 uses the Elliptic curve Diffie-Hellman (ECDH) protocol, which consists of two parties with an elliptic curve public-private key pair. An arrangement of anonymous keys that can establish a shared secret. In one embodiment, using these techniques, at 1703, the encryption engine 1660 of the IoT service 120 generates a secret using the IoT device session public key and its own session private key. Similarly, at 1704, the encryption engine 1661 of the IoT device 101 uniquely generates the same secret using the session public key of the IoT service 120 and its own session private key. More specifically, in one embodiment, the encryption engine 1660 on the IoT service 120 generates a secret according to the formula secret = IoT device session public key ^* IoT service session private key, where ( ^* ) is It means that the IoT device session public key is dot-multiplied by the IoT service session private key. The encryption engine 1661 on the IoT device 101 generates a secret according to the formula secret = IoT service session public key ^* IoT device session private key, and the IoT service session public key is dotted with the IoT device session private key Ru. Eventually, both the IoT service 120 and the IoT device 101 have generated the same secret that is used to encrypt the communication as described below. In one embodiment, the encryption engine 1660-1661 relies on hardware modules such as KSGM, 1640-1641, respectively, to perform the above-described operations for generating a secret.

  Once the secret is determined, the secret can be used by the encryption engines 1660 and 1661 to directly encrypt and decrypt data. Alternatively, in one embodiment, the encryption engine 1660-1661 sends a command to the KSGM 1640-1641 to generate a new key stream using the secret to encrypt / decrypt each data packet (Ie, a new keystream data structure is generated for each packet). Specifically, one embodiment of the key stream generation module 1640-1641 is used in combination with a secret to generate a key stream, the counter value is incremented for each data packet, Galois / Counter mode Implement (Galois / Counter Mode) (GCM). Thus, to send a data packet to the IoT service 120, the encryption engine 1661 of the IoT device 101 uses the secret and the current counter value to cause the KSGM 1640 to 1641 to generate a new key stream, and the next key stream Increase the counter value to generate. The newly generated key stream is then used to encrypt the data packet, which is then sent to the IoT service 120. In one embodiment, the key stream is XOR'd with data to generate an encrypted data packet. In one embodiment, the IoT device 101 sends the counter value to the IoT service 120 along with the encrypted data packet. The encryption engine 1660 on the IoT service then communicates with the KSGM 1640, which uses the received counter values and secrets, and must use the same key stream (the same secret and counter values are used, so And the generated key stream is used to decrypt the data packet.

  In one embodiment, data packets transmitted from IoT service 120 to IoT device 101 are encrypted in the same manner. Specifically, for each data packet, a counter is incremented and used with the secret to generate a new key stream. The key stream is then used to encrypt data (eg, performing an XOR of the data and key stream), and the encrypted data packet is sent to the IoT device 101 with the counter value. The encryption engine 1661 on the IoT device 101 then communicates with the KSGM 1641, which uses the counter value and the secret to generate the same key stream used to decrypt the data packet. Thus, in this embodiment, the encryption engines 1660-1661 use their own counter values to generate a keystream that encrypts data, and using the counter values received with the encrypted data packet, Generate a keystream that decrypts the data.

  In one embodiment, each encryption engine 1660-1661 tracks the last counter value it received from the other, whether the counter value was received out of sequence or the same counter value received more than once It includes sequencing logic to detect whether it has been done or not. If the counter value is received out of sequence, or if the same counter value is received more than once, this may indicate that a replay attack is being attempted. In response, the encryption engine 1660-1661 can disconnect from the communication channel and / or generate a security alert.

  FIG. 18 illustrates an exemplary encrypted data packet for use in one embodiment of the present invention, including a 4-byte counter value 1800, a variable-size encrypted data field 1801, and a 6-byte tag 1802. . In one embodiment, tag 1802 includes a checksum value that validates the decrypted data (if it is decrypted).

  As mentioned above, in one embodiment, the session public / private key pair 1650-1651 exchanged between the IoT service 120 and the IoT device 101 periodically and / or at the start of each new communication session It can be generated in response.

  One embodiment of the present invention implements an additional technique for authenticating the session between the IoT service 120 and the IoT device 101. Specifically, in one embodiment, a hierarchy of public / private key pairs is used, including a parent key pair, a set of factory key pairs, and a set of IoT service key pairs and a set of IoT device key pairs. In one embodiment, the parent key pair includes a root of trust for all of the other key pairs and is managed in a single highly secure location (eg, managing an organization implementing the IoT system described herein) Down). The master secret key can be used to generate (and thereby authenticate) signatures on various other key pairs, such as factory key pairs. The signature can then be verified using the master public key. In one embodiment, each factory that manufactures IoT devices is assigned its own factory key pair, which can then be used to authenticate the IoT service key and the IoT device key . For example, in one embodiment, the factory secret key is used to generate a signature on the IoT service public key and the IoT device public key. These signatures can then be verified using the corresponding factory public key. Note that these IoT service / device public keys are not the same as the “session” public / private keys described above with respect to FIGS. 16A-16B. The session public / private key mentioned above is temporary (ie generated for service / device session) while IoT service / device key pair is permanent (ie generated at the factory) Will be

With the above relationships between parent key, factory key, service / device key in mind, one embodiment of the present invention provides an additional layer of authentication and security between IoT service 120 and IoT device 101 Perform the following actions:
A. In one embodiment, the IoT service 120 initially generates a message that includes:
1. Unique ID of IoT Service:
・ Serial number of IoT service,
·Time stamp,
The ID of the factory key used to sign this unique ID,
・ Class of unique ID (ie, service),
・ Public key of IoT service,
-Signature over unique ID.
2. Factory certificate including:
·Time stamp,
The ID of the parent key used to sign the certificate,
・ Factory public key,
・ Signature of factory certificate.
3. IoT service session public key (as described above with respect to FIGS. 16A-16B).
4. IoT service session public key signature (eg signed with the secret key of the IoT service).
B. In one embodiment, the message is sent to the IoT device over a negotiation channel (described below). IoT devices analyze messages:
1. Verify the factory certificate signature (only if present in the message payload).
2. Verify the signature of the unique ID using the key identified by the unique ID.
3. Verify the IoT service session public key signature using the IoT service public key from a unique ID.
4. Save the public key of IoT service and the session public key of IoT service.
5. Generate an IoT device session key pair.
C. The IoT device then generates a message that includes:
1. Unique ID of IoT Device,
・ IoT device serial number,
·Time stamp,
The ID of the factory key used to sign this unique ID,
・ Class of unique ID (ie IoT device),
・ Public key of IoT device,
-Unique ID signature.
2. Session public key of IoT device.
3. Signed with the key of the IoT device (IoT device session public key + IoT service session public key).
D. This message is sent back to the IoT service. IoT services analyze messages:
1. Verify unique ID signature using factory public key.
2. Verify the session public key signature using the IoT device's public key.
3. Save session public key of IoT device.
E. The IoT service then generates a message that includes the signature of the IoT service key (IoT device session public key + IoT service session public key).
F. IoT devices analyze messages:
1. Verify the session public key signature using the IoT service's public key.
2. Generate a key stream from the IoT device session secret key and the session public key of the IoT service.
3. The IoT device then sends a "Messaging Available" message.
G. The IoT service then performs the following:
1. Generate key stream from IoT service session secret key and session public key of IoT device.
2. Create a new message on the messaging channel, including:
Generate and store random 2-byte values.
Set an attribute message with a boomerang attribute Id (described below) and a random value.
H. IoT Device Receives Messages:
1. Try to decipher the message.
2. Send an update with the same value as on the indicated attribute Id.
I. The IoT service recognizes that the message payload contains boomerang attribute updates:
1. Set the pairing state to true.
2. Send a pairing complete message on the negotiation channel.
J. The IoT device receives the message and sets the pairing state of the IoT device to true.

  Although the techniques described above have been described in terms of "IoT services" and "IoT devices", the basic principles of the present invention are: a secure communication channel between any two devices, including the user's client device, server, and Internet service It can be implemented to establish.

The techniques described above are highly secure because the secret key is not shared wirelessly (as opposed to the current Bluetooth pairing technique where the secret is sent from one party to the other). An attacker listening to the entire conversation will only have the public key, which is insufficient to generate a shared secret. These techniques also prevent man-in-the-middle attacks by exchanging signed public keys. In addition, since the GCM and separate counters are used on each device, any kind of "Replay Attack" (intermediate captures data and sends it again) is prevented. Some embodiments also prevent replay attacks by using an asymmetric counter.
Technology for exchanging data and commands without formally pairing devices

  GATT is an acronym for Generic Attribute Profile, which defines how two Bluetooth Low Energy (BTLE) devices transmit data back and forth. It makes use of a general data protocol called Attribute Protocol (ATT), which uses a simple lookup table, a service using 16 bit attribute IDs for each entry into the table, a characteristic , And used to store related data. It should be noted that "characteristics" may also be referred to as "attributes".

  On Bluetooth® devices, the most commonly used property is the “name” of the device (with property ID 10752 (0x2A00)). For example, a Bluetooth device can identify other Bluetooth devices in its vicinity by reading the "name" property issued by these other Bluetooth devices using GATT. Thus, a Bluetooth device has the inherent ability to exchange data without formally pairing / binding the device (note that "pairing" and "coupling" are sometimes used interchangeably) The rest of this discussion will use the term "pairing").

  One embodiment of the present invention utilizes this capability to communicate with BTLE enabled IoT devices without formally pairing with these devices. Pairing with each individual IoT device would be extremely inefficient because of the time required to pair and because only one paired connection can be established at a time.

  FIG. 19 illustrates one particular embodiment in which the Bluetooth (BT) device 1910 establishes a network socket abstraction with the BT communication module 1901 of the IoT device 101 without formally establishing a paired BT connection. . The BT device 1910 can be included in the IoT hub 110 and / or the client device 611 as shown in FIG. 16A. As illustrated, the BT communication module 1901 maintains a data structure that includes a property ID, a name associated with the property ID, and a list of values for the property ID. The values for each property can be stored in a 20 byte buffer identified by the property ID according to the current BT standard. However, the basic principles of the invention are not limited to any particular buffer size.

  In the example of FIG. 19, the “name” property is a BT defined property assigned a specific value of “IoT device 14”. One embodiment of the present invention is the first set of additional properties used to negotiate a secure communication channel with BT device 1910 and the additional used for encrypted communication with BT device 1910 Specify a second set of properties of. In particular, the "negotiate write" characteristic identified by characteristic ID <65532> in the illustrated embodiment can be used to send an outgoing negotiation message and identified by characteristic ID <65533>. The "negotiate read" feature can be used to receive an incoming negotiation message. The “negotiation message” may include the message used by BT device 1910 and BT communication module 1901 to establish a secure communication channel as described herein. As an example, in FIG. 17, the IoT device 101 can receive the IoT service session public key 1701 via the "Negotiate Read" feature <65533>. The key 1701 can be sent from the IoT service 120 to the BTLE enabled IoT hub 110 or client device 611, which in turn use the GATT to negotiate a reading buffer identified by property ID <65533> The key 1701 can be written. The application logic 1902 of the IoT device can then read the key 1701 from the value buffer identified by the property ID <65533> and process it as described above (e.g. using it a secret Generate and generate keystreams using secrets, etc.)

  If the key 1701 is larger than 20 bytes (the maximum buffer size in some current implementations), the key can be written in 20-byte parts. For example, the first 20 bytes can be written to feature ID <65533> by the BT communication module 1903 and read by the IoT device application logic 1902, which in turn can use the acknowledgment message to identify the feature ID < The negotiated write value buffer identified by Using the GATT, the BT communication module 1903 can read this acknowledgment from the property ID <65532>, and correspondingly, reads the next 20 bytes of the key 1701 the negotiation read identified by the property ID <65533>. You can write to the value buffer. In this manner, network socket abstractions defined by property IDs <65532> and <65533> are established to exchange negotiation messages used to establish a secure communication channel.

  In one embodiment, once the secure communication channel is established, feature ID <65534> (for sending encrypted data packets from IoT device 101) and feature ID <65533> (for encrypted data packets with IoT device) A second network socket abstraction is established using (for receiving). That is, when the BT communication module 1903 has an encrypted data packet (for example, the encrypted message 1603 in FIG. 16A, etc.) to be transmitted, the BT communication module 1903 uses the message read value buffer identified by the characteristic ID <65533>. Use 20 bytes at a time to start writing encrypted data packets. The IoT device application logic 1902 then reads the encrypted data packet, 20 bytes at a time, from the reading buffer and, if necessary, acknowledges the message via the writing buffer identified by property ID <65532>. It is to be transmitted to the BT communication module 1903.

  In one embodiment, data and commands are exchanged between the two BT communication modules 1901 and 1903 using GET, SET and UPDATE commands described below. For example, BT communication module 1903 may identify feature ID <65533> and send a packet containing a SET command to write to the value field / buffer identified by feature ID <65533>, which is then: It can be read by the IoT device application logic 1902. In order to obtain data from the IoT device 101, the BT communication module 1903 may send a GET command directed to the value field / buffer identified by the feature ID <65534>. In response to the GET command, the BT communication module 1901 can transmit to the BT communication module 1903 an UPDATE packet including data from the value field / buffer identified by the characteristic ID <65534>. In addition, UPDATE packets can be sent automatically in response to changes in certain attributes on the IoT device 101. For example, if the IoT device is associated with a lighting system and the user turns on lighting, an UPDATE packet can be sent to reflect this change in the on / off attribute associated with the lighting application.

  FIG. 20 illustrates an exemplary packet format used for GET, SET, and UPDATE, according to one embodiment of the present invention. In one embodiment, these packets are sent after the message write <65534> and read message <65533> channels. In GET packet 2001, the first 1-byte field contains a value (0x10) that identifies the packet as a GET packet. The second one-byte field contains a request ID that uniquely identifies the current GET command (ie, identifies the current transaction with which the GET command is associated). For example, different request IDs can be assigned to each instance of a GET command sent from a service or device. This can be done, for example, by incrementing the counter and using the counter value as the request ID. However, the basic principle of the present invention is not limited to any particular method for setting the request ID.

  The 2-byte attribute ID identifies the application-specific attribute to which the packet was directed. For example, if a GET command is being sent to the IoT device 101 illustrated in FIG. 19, the attribute ID can be used to identify the specific application-specific value being requested. Returning to the above example, the GET command can be directed to an application specific attribute ID, such as the power state of the lighting system, which is a value that identifies whether the light is powered on or off. (Eg, 1 = on, 0 = off). If the IoT device 101 is a security device associated with a door, the value field can identify the current state of the door (eg, 1 = open, 0 = closed). In response to the GET command, a response can be sent that includes the current value identified by the attribute ID.

  The SET packet 2002 and the UPDATE packet 2003 illustrated in FIG. 20 also include the first 1-byte field identifying the type of packet (ie, SET and UPDATE), the second 1-byte field including the request ID, and the application. It contains a 2 byte Attribute ID field that identifies the defined attribute. In addition, the SET packet contains a 2-byte long value that identifies the length of the data contained in the n-byte value data field. The value data field contains commands that are executed on the IoT device and / or configuration data that configures the operation of the IoT device in some way (eg, set desired parameters, power off the IoT device, etc.) be able to. For example, if the IoT device 101 controls the speed of a fan, the value field can reflect the current speed of the fan.

  An UPDATE packet 2003 can be sent to provide an update of the result of the SET command. The UPDATE packet 2003 includes a 2-byte-long value field that identifies the length of an n-byte value data field that can include data associated with the result of the SET command. In addition, a 1-byte update status field can identify the current status of the variable being updated. For example, if the SET command attempts to turn off the light controlled by the IoT device, the update status field may indicate whether the light was turned off normally.

  FIG. 21 illustrates an exemplary sequence of transactions between the IoT service 120 and the IoT device 101 with SET and UPDATE commands. Intermediate devices such as IoT hubs and user mobile devices are not shown to avoid obscuring the basic principles of the present invention. At 2101, a SET command 2101 is sent from the IoT service to the IoT device 101 and received by the BT communication module 1901, which correspondingly updates the GATT value buffer identified by the characteristic ID at 2102 Do. The SET command is read from the value buffer by the low power microcontroller (MCU) 200 at 2103 (or by program code running on the low power MCU such as the IoT device application logic 1902 shown in FIG. 19). At 2104, the MCU 200 or program code performs an action in response to a SET command. For example, the SET command can include an attribute ID that specifies a new configuration parameter, such as a new temperature, or a state value, such as on / off (to cause the IoT device to enter an "on" or low power state) Can be included. Thus, at 2104 a new value is set to the IoT device, at 2105 an UPDATE command is returned, and at 2106 the actual value of the GATT value field is updated. In some cases, the actual value will be equal to the desired value. In other cases, the updated values may be different (ie, it may take time for the IoT device 101 to update certain types of values). Finally, at 2107, an UPDATE command including the actual value from the GATT value field is sent back to the IoT service 120.

  FIG. 22 illustrates a method for implementing a secure communication channel between an IoT service and an IoT device according to an embodiment of the present invention. The method may be implemented in the context of the network architecture described above, but is not limited to any particular architecture.

  At 2201, the IoT service creates an encrypted channel for communicating with the IoT hub using an elliptic curve digital signature algorithm (ECDSA) certificate. At 2202, the IoT service encrypts data / commands in the IoT device packet using the session secret to create an encrypted device packet. As mentioned above, session secrets can be uniquely generated by IoT devices and IoT services. At 2203, the IoT service sends the encrypted device packet to the IoT hub via the encrypted channel. At 2204, without decryption, the IoT hub passes the encrypted device packet to the IoT device. At 22-5, the IoT device decrypts the encrypted device packet using the session secret. As mentioned above, in one embodiment, this generates a keystream using the secret and counter value (provided with the encrypted device packet) and then decrypts the packet using the keystream Can be realized by At 2206, the IoT device then extracts and processes data and / or commands contained in the device packet.

  Thus, using the techniques described above, establish a two-way secure network socket abstraction between two BT enabled devices without formally pairing BT devices using standard pairing techniques be able to. Although these techniques are described above with respect to the IoT device 101 communicating with the IoT service 120, the basic principle of the present invention is implemented to negotiate and establish a secure communication channel between any two BT enabled devices Can.

  23A-23C illustrate a detailed method for pairing devices according to an embodiment of the present invention. The method may be implemented in the context of the system architecture described above, but is not limited to any particular system architecture.

  At 2301, the IoT service creates a packet that includes the serial number of the IoT service and the public key. At 2302, the IoT service signs the packet using the factory secret key. At 2303, the IoT service sends the packet to the IoT hub via the encrypted channel, and at 2304 the IoT hub forwards the packet to the IoT device via the unencrypted channel. At 2305, the IoT device verifies the signature of the packet, and at 2306, the IoT device generates a packet that includes the serial number of the IoT device and the public key. At 2307, the IoT device signs the packet using the factory secret key, and at 2308, the IoT device sends the packet to the IoT hub over the unencrypted channel.

  At 2309, the IoT hub forwards the packet to the IoT service via the encryption channel, and at 2310, the IoT service verifies the packet's signature. At 2311 the IoT service generates a session key pair, and at 2312 the IoT service generates a packet containing the session public key. The IoT service then signs the packet with the IoT service secret key at 2313, and at 2314 the IoT service sends the packet to the IoT hub via the encrypted channel.

  Moving to FIG. 23B, at 2315, the IoT hub forwards the packet to the IoT device via the unencrypted channel, and at 2316, the IoT device verifies the signature of the packet. At 2317, the IoT device generates a session key pair (eg, using the techniques described above), and at 2318 an IoT device packet is generated that includes the IoT device session public key. At 2319, the IoT device signs the IoT device packet with the IoT device secret key. At 2320, the IoT device sends the packet to the IoT hub via the unencrypted channel, and at 2321 the IoT hub forwards the packet to the IoT service via the encrypted channel.

  At 2322, the IoT service verifies the signature of the packet (eg, using the IoT device public key), and at 2323 the IoT service uses the IoT service secret key and the IoT device public key to Generate (as detailed above). At 2324, the IoT device generates a session secret (also as described above) using the IoT device secret key and the IoT service public key, and at 2325 the IoT device generates a random number to generate a session secret Use to encrypt that random number. At 2326, the IoT service sends the encrypted packet to the IoT hub via the encryption channel. At 2327, the IoT hub forwards the encrypted packet to the IoT device over the unencrypted channel. At 2328, the IoT device decrypts the packet using the session secret.

Moving on to FIG. 23C, at 2329, the IoT device re-encrypts the packet using the session secret, and at 2330, the IoT device sends the encrypted packet to the IoT hub via the unencrypted channel. At 2331, the IoT hub forwards the encrypted packet to the IoT service via the encryption channel. At 2332 the IoT service decrypts the packet using the session secret. At 2333, the IoT service verifies that the random number matches the random number sent by the IoT service. The IoT service then sends a packet at 2334 indicating that pairing is complete, and at 2335 all subsequent messages are encrypted using the session secret.
System and method for integrally molded parts Internet of things (IoT) security sensor

  One embodiment of the present invention comprises an integrally formed Internet of Things (IoT) security sensor, which is compatible with existing wireless door / window sensor constraints (eg, alignment, bulkiness, malfunction, etc.) deal with. FIG. 24 shows a system architecture having three such IoT devices 2401-2403 coupled to various doors and / or windows in the user's home or office. The interaction between the various system components may occur as described above. For example, the architecture shown includes an IoT hub 2405, which communicates with the IoT devices 2401-2403 via a low power wireless communication channel, such as a Bluetooth Low Energy (BTLE) channel, and in one embodiment Establish a communication channel with the IoT cloud service 2420.

  As shown, the IoT cloud service 2420 may include an IoT device database 2430, which is configured into the system (which may include multiple IoT hubs and devices not shown in FIG. 24) IoT devices 2401-2403 And database records for each of the IoT hub 2405. The IoT device management logic 2415 creates database records for the new IoT device and updates the IoT device records according to the data sent by each of the IoT devices 2401-2403. The IoT Device Management Logic 2415 also adds new devices to the system (eg using QR code / bar code) by implementing the various security / encryption functions described above, A key may be used to encrypt the communication when communicating with 2403 and / or a digital signature may be generated. In one embodiment, the user may access information associated with each of the devices 2401-2403 and / or may be a smartphone device such as an Android® device or an iPhone®. The device may be controlled via an application installed on the device 2410. In addition, the user may access or control the IoT device via a browser or application installed on a desktop or laptop computer. In one embodiment, control signals transmitted from the application or application of the user device 2410 are passed to the IoT cloud service 2420 via the Internet 2422 and then from the IoT cloud service 2420 to the IoT hub 2405 and the IoT hub 2405 To one or more of the IoT devices 2401-2403. Of course, the underlying principles of the present invention are not limited to any particular manner in which the user accesses / controls the various IoT devices 2401-2403.

  As noted above, in one embodiment, the IoT devices 2401-2403 comprise an integrally formed security device configured on the door and / or the window. FIG. 25 shows an exemplary IoT device 2401, a radio microcontroller for reporting security status to the IoT hub 2405 (e.g., using a low power radio link such as BTLE as described above) 2510, an accelerometer 2502 for detecting motion, and proximity sensors and logic 2505 for generating and sensing electromagnetic radiation reflected from nearby objects. In one embodiment, the electromagnetic radiation is infrared (IR) radiation (ie in the IR spectrum). However, various other types of electromagnetic radiation may be used in accordance with the basic principles of the present invention.

  In another embodiment, the proximity sensor 2505 comprises a magnetometer for detecting the current door position. For example, the magnetometer may be configured to detect the orientation of the door relative to the direction of the geomagnetic field. The magnetometer may be calibrated by taking measurements when the door is in the closed and open positions. The latest magnetometer measurements may then be compared to the calibrated measurements to determine if the door is currently open or closed.

  In the example shown in FIG. 25, the IoT device 2401 is attached to the inside portion of the door 2520 facing the side post 2521. In one embodiment, for example, it may be small enough to fit between the door and the side post (the vertical portion of the frame in which the door is secured). However, it should be noted that this particular arrangement is not necessary to follow the basic principles of the invention. Furthermore, the basic principles of the present invention may also be implemented in the window of the user's home or office or any other moveable object.

  In operation, when the door 2520 is stationary, the radio uC 2510 is maintained at a very low voltage or off state to preserve battery life. In one embodiment, when the door is moved, the accelerometer 2502 cuts in and activates the radio uC 2510, which in turn uses the proximity sensor / logic 2505 whether the side post 2521 is stationary in front "See" if not. If the door is not stationary, the proximity sensor may generate a warning signal that the radio uC sends to the IoT hub 2405.

  In one embodiment, the proximity sensor / logic 2505 comprises an IR transmitter for transmitting IR radiation and an IR detector for detecting IR radiation reflected from the side posts 2521. In one embodiment, the proximity sensor / logic 2505 measures the intensity of the reflected IR radiation. The proximity sensor / logic 2505 is then known to be present when the door is closed (eg, may be collected via calibration as discussed below) and the latest IR readings You may compare. If the readings match (or are within the specified threshold), the proximity sensor / logic 2505 determines that the door is in the closed position. However, if the readings do not match (e.g., are outside the threshold), the proximity sensor / logic 2505 may determine that the door is open and may generate an alarm condition via the radio uC 2510.

  In one embodiment, the proximity sensor / logic 2505 includes calibration logic to calibrate the IR reading to the “closed” position of the door 2520. In one embodiment, after the IoT device 2401 is attached to the door, the user performs a calibration process via an application on the user device 2410 that requires the user to confirm when the door is in the closed position. . Once the user gives an indication, a command may be sent to notify the proximity sensor 2505 which will record the reading. These readings may then be compared to the latest readings as described above to determine if the door is currently open or closed.

  FIG. 26 shows an embodiment in which the IoT device 2401 is installed in the lower part of the door 2520 between the inner surface of the door 2520 and the side post 2521. In this embodiment, only the proximity sensor / logic 2505 is installed between the door 2520 and the side pole 2521 in this embodiment, and at the same time, the remaining components of the IoT device 2401 (eg, radio uC and accelerometer 2502) A right angle form factor may be used, being installed on the face of the door. This embodiment allows the portion that fits between the door 2520 and the side post 2521 to be as thin as possible (e.g., in some cases only a few millimeters) while at the same time (which may tend to be more bulky) Other components such as the radio radio uC may be allowed to not impede the movement of the door. Of course, the underlying principles of the present invention may include an IoT device 2401 such that all of the components are small enough to fit in a single package between the door 2520 and the side post 2521.

  Further, it will be appreciated that the IoT device 2401 may be placed at another location, such as the edge of the door farthest from the side post 2521. In this embodiment, the proximity sensor / logic 2505 may take IR measurements between the edge of the door and the immediate portion of the door frame. Similarly, the IoT device 2401 may also be placed at or near the edge of the window. In this embodiment, the proximity sensor / logic 2505 will take IR measurements that are bounced off nearby structural objects such as windows or window sills. Again, a calibration process may be implemented to take measurements at the closed and / or open positions, and subsequent readings may be compared to these measurements to open the window. It may be determined whether it is closed or closed.

  Various different types of sensors may be used within or coupled to the IoT device 2401 to sense the position of a door, window, or other device within the user's home or office. Several exemplary embodiments are described below.

  As shown in FIGS. 27A-27B, another embodiment of the present invention includes a force sensing resistor (FSR) 2702 coupled to the inside of the door 2710. In this illustrated embodiment, the FSR 2702 is attached to a rubber bumper component 2701 which itself is directly attached to the door as shown. The FSR 2702 is communicatively attached to the IoT device 2703 via a set of FSR leads 2704 (e.g., a set of wires communicating the most recent force acting on the FSR 2702). As in the embodiment shown in FIG. 27, in this embodiment, the IoT device 2703 is, as represented, only the FSR sensor installed between the door 2710 and the side post, at the same time the remaining components of the IoT device 2703 (E.g., the radio uC and the accelerometer 2502) may have a right-angled form factor that is mounted on the face of the door. The IoT device 2703 may include a radio module (as in the above embodiment) and a small battery for power supply.

  In another embodiment, FSR 2702 may be attached to the outside edge of door 2710 rather than the inside edge of the door, and may be coupled to the door frame (eg, side post 2521). The underlying principles of the present invention are not limited to any particular attachment location for IoT device 2703 and FSR 2702. Furthermore, the same basic principles may be applied to use FSR 2702 in a window or another device of the user's home or office.

  In the example shown in FIGS. 27A-27B, a pressure sensitive resistor (FSR) 2702 can detect when the inside of the door enters very close to the door frame. Beyond a short distance, the FSR 2702 provides a continuous measurement of the force being applied by the door through the FSR to the door frame. As noted above, one embodiment of the FSR 2702 is attached to a small rubber bumper 2701 that transmits forces from the door to the frame through the FSR. The size and consistency of bumper 2701 may be varied to accommodate different door clearances. Depending on the forces acting on the FSR (eg, as a result of the door closing), the FSR 2702 is received and processed by the IoT device 2703 and / or transmitted to the IoT hub 2405 and the IoT service 2420 through itself Generate an electrical signal. For example, different resistances may be measured across the FSR 2702 for different levels of force (ie, resulting in different amounts of current when assuming consistent voltages). When the specified threshold force is reached, the IoT device 2703 (or IoT hub 2405 or service 2420) may interpret this to mean that the door is in the "closed" position. When a force below the threshold is detected, the IoT device 2703, the IoT hub 2405, or the IoT service 2420 may have this partially open the door (e.g. slightly open, thereby only partially It may be interpreted to mean that the FSR is depressed). When no force is detected, the IoT device 2703, the IoT hub 2410, and / or the service 2420 may conclude that the door is open. Thus, using a sensor that provides continuous force measurements over a small dynamic range, such as the FSR 2702, will result in a more accurate determination of door position (as opposed to existing security sensors that are simply on or off) provide. As in the previous embodiment, the FSR 2702 / IoT device 2703 may be an all-in-one device that may be completely attached to the door or door frame (as opposed to the current type of magnetic door sensor that is two-part) May be implemented as

  In one embodiment, the user may calibrate the FSR 2702 / IoT device 2703 when initially installed. For example, the application of the user device 2410 may require the user to provide an indication of when the door is fully closed, fully open, and half open. Sensor readings may be taken at each location and recorded by IoT device 2703, IoT hub 2410, and / or service 2420. These readings may then be compared to the latest readings to determine the current state of the door. For example, if the latest reading is within the specified range of recorded readings for a closed door, IoT device 2703, IoT hub 2410, and / or service 2420 determine that the door is currently closed You may Similar comparisons may be made to the open and half open states.

  Various attachment techniques may be used, depending on form factor and design goals, including adhesives, pressure fit, rubber products, or attached brackets. In the embodiment shown in FIGS. 27A-27B, for example, an adhesive may be applied to the backing of the rubber bumper to attach the FSR 2702 and the IoT device 2703 to the door. One example of an FSR that may be used is the FSR 402 Round Force Sensing Resistor available from Digi-Key Electronics.

  Another embodiment not only includes all of the features shown in FIGS. 27A-27B, but also includes a piezoelectric vibration sensor added to the package. For example, in one embodiment, the piezoelectric vibration sensor may be located below the rubber bumper 2701 or may be integrated therein. Similar to the FSR, electrical leads communicatively couple the piezoelectric vibration sensor to the IoT device 2703. In one embodiment, the piezoelectric vibration sensor is passive and generates high voltage without requiring power supply to the external device when force, bending or vibration is applied. Thus, the vibration sensor may be configured to activate another component in the radio microcontroller 2510 and the IoT device 2703 in response to the vibration or movement, whereby the component vibrates or moves. In the absence of, it is possible to enter a very low power state. The vibration sensor may be activated, for example, by knocking / striking a door, may act as a pressure / tactile sensor, or may be configured as a simple accelerometer (such as the accelerometer 2502 in FIG. 25). Good.

  In one embodiment, FSR 2702 of FIGS. 27A-27B is replaced by a strain gauge coupled to a leaf spring. As the door closes and contacts the spring, the strain gauge resistance changes in response to the strain on the spring surface. The resistance change corresponds, in turn, to the spring angle and thus to the spring deflection which is correlated to the door angle. The result of this embodiment is similar to the above FSR embodiment, except that a much larger operating range for the door angle is available. However, strain gauge circuits require amplification to increase the operating range, and as a result, this design may tend to consume more power than FSR embodiments.

  In another embodiment, the FSR 2702 sensor element of FIGS. 27A-27B is replaced by a combination of a piezoelectric film and a piezoresistive film. The piezoelectric film of this embodiment operates as described above for the piezoelectric vibration sensor to generate high voltage without requiring power supply to the external device when force, bending or vibration is applied. However, piezoresistive films utilize piezoresistive effects and have variable resistance based on force and bending. In one embodiment, these two films may be used in the same manner as the leaf spring / strain gauge combination described above. However, in another embodiment, the combination of piezoelectric / piezoresistive films may be mounted inside the latch / bolt slot of the door mechanism and may be communicatively coupled to the IoT device 2703 via a set of conductors . A lock lock condition of the door may be determined from the generated electrical signal depending on whether the latch is lock locked to deform the sensor or unlatched to free the sensor. In one embodiment, the attachment is performed either at the frame or at the door. In this embodiment, the film is glued / adhered to the surface near the door latch and the latching action contacts the film by protruding into the latch path. As in the previous embodiment, this embodiment may be calibrated after installation so that the open and closed state of the door may be correlated with the corresponding resistance of the piezoresistive film.

  Yet another embodiment is attached to the interior of the door, although having the same or similar components as the embodiment of FIGS. 27A-27B. Either during retrofit or assembly, a small cavity may be created inside the door or frame (hinge mount) in which the sensor is installed only by the FSR bumper extending beyond the plane of the surface is there. By embedding the FSR sensor in this way, the contribution of size and form factor is less, and by using a battery of larger capacity, the unit life may be extended up to 10 years. Furthermore, this embodiment has almost no profile visible and much less penetration into vision. Unit size limitations depend on the type of battery.

  Although described in the context of a standard door 2710, all of the above embodiments are also applicable to sliding doors and sliding windows. A universal door is the most complex of the currently proposed implementations. When attached to a sliding window or sliding door, these embodiments perform the same basic function despite having a purely linear path.

  A method in accordance with one embodiment of the present invention is shown in FIG. The method may be implemented in the context of the system architecture described above, but is not limited to any particular architecture.

  At 2801, the door / window is initially in the resting position. If motion is detected at 2802, then at 2803 the wireless uC is awakened from its own low power / sleep state. At 2804, the wireless uC queries the proximity sensor (which may also be in a low power state prior to query and / or may be activated by the accelerometer) for taking proximity readings. In response, the proximity sensor creates an reading at 2805 to determine if the door / window is in the open or closed position. If it is determined at 2806 that the door / window is open, then at 2807 an alarm condition may be generated that may be sent to the IoT hub, IoT service, and / or user device. Finally, after the alarm condition has been examined, the alarm condition may be disabled at 2809. In one embodiment, alarm conditions may be disabled in response to signals sent from the IoT hub, IoT service, and / or the mobile device of the user. If it is not determined at 2806 that the door / window is open, then at 2808 the wireless uC may be returned to the low power / sleep state and processing returns to 2801.

  In one embodiment, when the user's home is in a "protected" state (e.g., when the user leaves home during the day, or at night when the user is sleeping), the system is as described above It may be configured to generate an alarm. Various components of the IoT device 2401 may enter a low power / sleep state when the home is not in a protected state for another time. The signal from the IoT hub 2405 is then responsive to a manual input from the user (e.g., via the user device's app) and / or according to a daily schedule (e.g. at a user specified time of day and night) May be placed in the operating mode.

Various techniques may be used to attach the IoT device 2401 to doors and windows, such as through adhesive (eg, double sided tape), mounting holes in the housing of the IoT device Includes miniature screws sized to mate.
System and method for establishing a secondary communication channel for controlling an internet of things (IoT) device

  In the embodiments of the invention described above, a secure channel is established by the IoT hub or client device between each IoT device and the IoT service (see, eg, FIGS. 16A-17 and the associated text). Once established, the IoT service may securely send commands to control and configure each IoT device. In the reverse direction, each IoT device may send data back to the IoT service, where the data may be stored and / or accessed by the end user. As an example, when a door or window is open at the user's home, an IoT device configured to detect this condition displays an indication that the door / window is open to the IoT service via a secure communication channel It may be sent. Similarly, if the IoT device is configured as a wireless lock fixture on the user's front door, the user sends a command from the IoT service to the IoT device via a secure communication channel to unlock the front door It is also good.

  The above configuration assumes that there is a viable connection between the IoT device and the IoT service. However, in some instances, the connection to the IoT service may not be feasible. For example, the IoT service may be down, or the Internet connection to the IoT service (eg, via a cellular data network or a dedicated home Internet connection) may be inoperable.

  As shown in FIG. 29, to address this issue, one embodiment of the present invention provides a technique for establishing a secondary communication channel 2910 between the user's client device 611 and the IoT device 101. By doing so, the user may receive a connection from the IoT device 101 even when the connection to the IoT service 120 is lost (as indicated by the cross on the communication path between the IoT hub 110 and the IoT service 120). Data may be controlled and collected. Thus, if the IoT device 101 is a wireless door lock, the user uses the secondary communication channel 2910 to use the front door of the user, even if the primary communication channel 2911 to the IoT service 120 is inoperable. You may unlock it.

  In one embodiment, the secondary channel 2910 comprises a Bluetooth Low Energy (BTLE) communication channel. However, the basic principles of the invention are not limited to any particular wireless communication protocol.

  In one embodiment, a secure secondary communication channel between the IoT device 101 and the client device 611 by storing or maintaining a set of secondary channel keys 2950-2951 in the client device 611 and the IoT device 101. Used to establish 2910. Secondary channel keys 2950-2951 may be exchanged between client device 611 and IoT device 101 using a secure key exchange protocol. For example, the same key exchange protocol (or a subset thereof) described above may be used to exchange keys between client device 611 and IoT device 101. Alternatively, the key may be randomly generated and securely provided from the IoT service 120 to the IoT device 101 and the client device 611 (ie, during a period when the connection to the IoT service is operational).

  Once the keys are exchanged, the encryption engine 2960 of the client device 611 may encrypt communication with the IoT device 101 using its own key 2950, and the encryption engine 1661 of the IoT device 101 , Its own key 2951 may be used to decrypt the communication received from the client device 611. Conversely, encryption engine 1661 of IoT device 101 may encrypt communications using its own key, and encryption engine 2960 of client device 611 decrypts communications using its own key You may

  Because storing the key on the client device is less secure than the above embodiment, the functionality published by the IoT device 101 may be limited when the second communication channel 2910 is used. The functionality that is announced / enabled when the second channel 2910 is used may also be product dependent. For example, the user may be enabled to retrieve a subset of data from the IoT device 101, and / or be provided with a subset of commands to configure or control the IoT device 101. As an example, an IoT device may refuse user access to data considered to be "safe" data, and may refuse access to "secure" commands (eg, change the security code of the IoT device) .

  Certain types of IoT devices 101, such as wireless door locks, may have a single simple function. In one embodiment, access to these functions is provided via the secondary channel 2910 using an additional layer of security. For example, in one embodiment, the authentication module 2970 of the IoT device is configured with a security pass code 2971 such as an N-digit number or an alphanumeric password. For example, this may be performed during the time when the primary secure communication channel 1911 is established between the IoT service 120 and the IoT device 101. Once connected to the IoT service 120, the user may select a passcode via the passcode entry application 2920 of the client device 611. The passcode may then be securely transmitted from the IoT service 120 and stored securely in the secure storage of the IoT device 101.

  Then, when the user establishes a secondary communication channel 2910 from the client device 611 (e.g., using the secondary channel key as described above), the IoT device 101 can provide the user with a secure passcode. You may be prompted to enter. If the user enters the correct secure passcode from the passcode entry application 2920, the authentication module 2970 authenticates the user to the data and functions to be performed by the IoT device 101 (or a designated subset of it). It will provide access. In one embodiment, authentication engine 2970 will disconnect the secondary communication channel 2910 after a specified number of passcode attempts have failed. For example, if the IoT device 101 is a wireless door lock, the passcode acts as an additional layer of security for entry into the user's home.

  A method in accordance with one embodiment of the present invention is shown in FIG. The method may be implemented in the context of the system architecture described above, but is not limited to any particular system architecture.

  At 3001, a secure connection is established between the IoT service and the IoT device (e.g., by the IoT device using the secure key exchange technique described above). At 3002, a secondary key exchange is performed between the IoT device and the client device. As noted above, this is directly between the client device and the IoT device (eg, which may generate a random set of keys to securely provide the key to each of the IoT device and client device) Or may be achieved in various ways, including through IoT services.

  At 3003, the IoT device is programmed with a secure passcode. As noted above, this may be performed via an application on the user's client device, prompting the user to enter an N-digit numeric code or alphanumeric code. The passcode may be securely transmitted to the IoT device via a secure channel established between the IoT service and the IoT device.

  If a primary secure connection failure is determined at 3004, at 3005, a secondary secure connection between the client device and the IoT device may be established using a secondary communication protocol. In one embodiment, the secondary protocol uses the secondary key exchanged at 3002 to encrypt communication between the IoT device and the client device. As mentioned above, the underlying wireless communication protocol may be implemented using BTLE or another local wireless protocol.

  At 3006, the IoT device prompts the user to enter a secure password via the user's client device. If the correct passcode entry by the user is determined at 3007, the IoT device grants at 3008 access to its own data and functions (or a subset thereof). If the user does not enter the correct passcode, then at 3009, access to the IoT device is denied.

  Embodiments of the present invention may include the various steps described above. The process may be embodied in machine-executable instructions that may be used to cause a general purpose or special purpose processor to perform the process. Alternatively, these steps may be performed by specific hardware components including hardwired logic to perform the steps, or by any combination of programmed computer components and custom hardware components. Can.

  As described herein, the instructions are configured to perform certain operations or are stored in a memory in which predetermined functions or software instructions are embodied in a non-transitory computer readable medium. It may refer to a specific configuration of hardware, such as an application specific integrated circuit (ASIC) that has been Thus, the techniques shown in the drawings may be implemented using code and data stored and executed on one or more electronic devices (eg, end stations, network elements, etc.). Such electronic devices include non-transitory computer machine readable storage media (eg, magnetic disks, optical disks, random access memory, read only memory, flash memory devices, phase change memory), as well as temporary computer machine readable communication media (eg For example, code and data may be stored and / or internally using a computer machine readable storage medium such as a carrier wave, an infrared signal, an electrical, optical, acoustic or other form of propagated signal such as a digital signal. Or communicate with other electronic devices via a network). In addition, such electronic devices typically include one or more storage devices (non-transitory machine-readable storage media), user input / output devices (eg, keyboards, touch screens, and / or displays), and It includes a set of one or more processors coupled to one or more other components, such as network connections. The coupling of a set of processors to other components is typically performed through one or more buses and bridges (also called bus controllers). Each of the storage device and the signal carrying the network traffic represents one or more machine readable storage media and a machine readable communication medium. Thus, the storage device of a given electronic device typically stores code and / or data for execution on the set of one or more processors of the electronic device. It should be appreciated that one or more parts of the embodiments of the present invention may be implemented using different combinations of software, firmware and / or hardware.

  Throughout the detailed description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without some of these specific details. In certain instances, known structures and functions have not been described in detail to avoid obscuring the subject matter of the present invention. Accordingly, the scope and spirit of the present invention should be determined in terms of the following claims.

  FIG. 31 illustrates one embodiment of an IoT device 101, in which BTLE communication interface 3110 includes advertising interval selection logic 3111 that adjusts the advertising interval when data is ready to be sent. In addition, BTLE communication interface 3120 of IoT hub 110 includes advertising interval detection logic 3121 for detecting changes in advertising intervals, providing acknowledgments, and receiving data.

  In particular, in the illustrated embodiment, the application 3101 of the IoT device 101 indicates that it has data to be transmitted. In response, the advertising interval selection logic 3111 notifies the IoT hub 110 that the advertising interval should be modified and data should be sent (e.g., changing the interval to .75T or some other value). When advertising interval detection logic 3121 detects a change, BTLE communication interface 3120 connects to BTLE communication interface 3110 of IoT device 101 to indicate that it is ready to receive data. The BTLE communication interface 3110 of the IoT device 101 then sends data to the BTLE communication interface 3120 of the IoT hub. The IoT hub may then pass data through to itself to the IoT service 120 and / or to the user's client device (not shown). After the data has been sent, advertising interval selection logic 3111 may then return to the normal advertising interval (eg, AI = T).

  In one embodiment of the present invention, a secure communication channel is established between the IoT device 101 and the IoT service 120 using one or more of the security / encryption techniques described above (eg, 16A-23C and related text). For example, in one embodiment, the IoT service 120 performs key exchange with the IoT device 101 as described above to encrypt all communication between the IoT device 101 and the IoT service 120.

  A method in accordance with one embodiment of the present invention is illustrated in FIG. The method may be implemented in the context of the system architecture described above, but is not limited to any particular system architecture.

  At 3200, the IoT device uses a standard advertising interval when generating advertising packets (e.g., separated by time T). At 3202, the IoT device maintains a standard advertising interval until it is determined at 3201 to have data to send. Then, at 3203, the IoT device indicates to switch advertising intervals to have data to transmit. At 3204, the IoT hub or another network device enables the IoT device to transmit its own data by establishing a connection with the IoT device. Finally, at 3205, the IoT device sends its own pending data to the IoT hub.

  It should be noted that although the advertising interval technology is described herein in connection with the BTLE protocol, the underlying principles of the present invention are not limited to BTLE. In fact, the underlying principles of the present invention may be implemented in any system that selects advertising intervals for establishing wireless communication between devices.

In addition, although a dedicated IoT hub 110 is shown in many of the above embodiments, a dedicated IoT hub hardware platform is not required to follow the basic principles of the present invention. For example, the various IoT hubs described above may be implemented as software executing in various other networking devices such as iPhones® and Android® devices. In fact, the IoT hub described herein can communicate with the IoT device (e.g., using BTLE or another local wireless protocol), and (e.g., use a WiFi or cellular data connection) It may be implemented in any device that can establish a connection via the Internet)).
Apparatus and method for obscuring wireless communication patterns

Even if the data sent between the IoT service and the IoT device is encrypted using the above technology, the wireless transaction between the IoT service and the IoT device is collected and analyzed Determine the action. For example, as shown in FIG. 33, IoT service 120, when IoT device is a wireless door lock, sends a command 3302 to the IoT device at the designated time t _0, the particular function, such as unlocking the door May be performed. As shown, the commands may be passed through the WAN interface 3321 and the local wireless communication interface 3320 of the IoT hub 110 (or via a mobile device or another device implementing the IoT hub function). Application specific program code 3315 for IoT device 101 may then execute the command at 3303, may provide a response to the local wireless communication module 3310 in the second time t _1. Wireless communication module then sends a response 3304 at t _2. Generally, the timing between the command 3302 sent over the wireless link, the execution of the command 3303 and the response 3304 sent back to the IoT service will all occur in a predictable manner. For example, upon receiving command 3302, application 3315 may generally take the same time to execute the command and return response 3304. Thus, someone listening to the wireless communication decrypts the communication pattern and the user unlocks (or locks) the user's door or performs various other device-specific functions. Understand what you are doing.

To address these concerns, one embodiment of the present invention implements techniques for obfuscating or obscuring the communication patterns between the IoT device 101 and the IoT service 120. FIG. 34 illustrates one such embodiment in which service program code 3321 and / or local wireless communication interface 3310 of IoT device 101 are messages for implementing the various techniques described herein. Communication disambiguating logic 3411, 3410 is included. In particular, in one embodiment, upon receiving the command 3302 at t _0, the application 3315 provides a response by executing its own application-specific functions of the t _1. However, in contrast to the embodiment shown in FIG. 33, in FIG. 34, the message communication disambiguating logic 3410 introduces a timing delay for sending the response 3404. Thus, instead of sending a response at t ₂ , it sends a response at t ₂ + N, where N may be a randomly selected value within a specified range of time. In addition to changing timing, in one embodiment, the message communication disambiguating logic 3410 performs another technique to modify the size of the response 3404 by a specified or random amount (eg, M in response packets) The response may be obscured, such as appending additional bytes of In this aspect, transactions between the IoT service and the IoT device are more difficult to predict than in the previous embodiments.

FIG. 35 shows another embodiment for obscuring communication between the IoT service 120 and the IoT device 101. In this embodiment, the message communication disambiguating logic 3411 of the IoT service 120 sends the disambiguating packet 3501 either before or after the command packet 3302. In the particular example shown in FIG. 35, it is sent earlier (ie, at time t _x ). In one embodiment, the disambiguating packet 3501 comprises an encrypted message, which is sent to the messaging communication disguising logic 3410 of the IoT device 101 (eg, 100 ms, 200 ms, etc. identified by the value L in FIG. 35) Send a reply message 3502 at some specific time in the future). The specific time to wait before sending the response 3502 may be specified in the disambiguating packet 3501. Alternatively, the length of the waiting time may be specified by the message communication disambiguating logic 3410 of the IoT device 101. For example, the length of time may be randomly selected by the messaging communication logic 3411 of the IoT service 120 or by the messaging logic 3410 of the IoT device 101. Randomizing the times at which responses are sent makes it difficult for hackers to distinguish between true traffic 2602, 2604 and obfuscated traffic 2801, 2802 (which is essentially no operation traffic). As shown, the message communication disambiguating logic 2710 of the IoT device 101 may still implement a random delay to send the actual response 2604 to further obscure the traffic.

  Additionally, in one embodiment, the disambiguating packet 2801 may instruct the messaging communication disguising logic 2710 of the IoT device 101 to send one or more decoy advertisement packets 2804. IoT devices using the secure BTLE technology described above perform "advertising" that they transmit an RF "chirp" indicating that they are available at some programmable interval. Anyone can eavesdrop and listen to this advertisement packet. As part of the advertisement, one bit is used to indicate that the IoT service 120 has data for the IoT device to read. Thus, when the IoT service 120 sends an obfuscation packet 2801, it may also require the device to send decoy advertisements at some future programmable time. This additional mechanism makes it difficult for hackers who eavesdrop on advertisements (which are clear) to distinguish between true and decoy.

  In one embodiment, the various disambiguation techniques described above are programmable based on the set of disambiguation rules 2712 of the IoT device 101 and the disambiguation rules 2713 of the IoT service 120. The rules 2712 may specify, for example, particular timings to be used for the disambiguating packet 2801, the response 2802, and the decoy advertisement 2804. In one embodiment, rules 2712 2713 specify the operation of messaging communication disambiguating logic 2710 2711 according to the latest state variables 2720 2721 respectively of the system. The latest state variables 2720, 2721 may include high-level factors such as the type of IoT device 101 for which communication is being obscured, the latest battery level of the IoT device 101, the time of day, the latest weather, and so on. For example, a particular IoT device 101 should not inherently generate predictable periodic communication patterns. For such IoT devices, the obfuscation techniques described herein may be set to a minimum. Further, if the battery life of the IoT device 101 is short (eg, below a threshold), a smaller number of obfuscated packets 2801 and decoy advertisements 2804 may be generated to preserve battery life. Of course, various different types of rules may be specified in accordance with the basic principles of the present invention.

  A method in accordance with one embodiment of the present invention is shown in FIG. The method may be implemented in the context of the system architecture described above, but is not limited to any particular system architecture.

  At 2900, the IoT device receives a command from the IoT service and executes the command at 2901. At 2902, the message communication disambiguating logic adjusts the timing of the response. As mentioned above, this may be achieved by inserting random or pre-selected timing delays. At 2903, the IoT device sends a response according to the adjusted timing.

  Another method according to one embodiment is shown in FIG. At 3000, the IoT service sends a command (eg, a command to unlock the door) to the IoT device. At 3001, the IoT service sends an obfuscation packet to the IoT device. As mentioned above, the disambiguating packet may be sent either before or after the command. At 3002, the IoT device executes a command (eg, unlocks the door) and sends a response. In one embodiment, timing delays may be used for responses (eg, as described with respect to FIG. 29). At 3003, the IoT device sends an obfuscation response to the obfuscation packet. In one embodiment, the obfuscation packet indicates that timing is used for the response. In another embodiment, the IoT device determines the timing for the response (eg, selecting a random length of time within a specified range). The obfuscated response may be sent to the command either before or after the response, depending on the timing selected. At 3004, the IoT device sends decoy advertisements in response to the obfuscated packet. The decoy advertisement may be sent alone or in addition to the sending of the obfuscation response.

  FIG. 24 illustrates one embodiment of an IoT device 101, in which BTLE communication interface 2410 includes advertising interval selection logic 2411 that adjusts the advertising interval when data is ready to be sent. In addition, the BTLE communication interface 2420 of the IoT hub 110 includes an advertising interval detection logic 2421 to detect changes in the advertising interval, provide acknowledgments, and receive data.

  In particular, in the illustrated embodiment, the application 2401 of the IoT device 101 indicates that the data to be transmitted has. In response, advertising interval selection logic 2411 notifies IoT hub 110 that the data should be sent (eg, changing the interval to .75 T, or some other value) by modifying the advertising interval. Do. When advertising interval detection logic 2421 detects a change, BTLE communication interface 2420 connects to BTLE communication interface 2410 of IoT device 101 to indicate that it is ready to receive data. The BTLE communication interface 2410 of the IoT device 101 then sends data to the BTLE communication interface 2420 of the IoT hub. The IoT hub may then pass data through to itself to the IoT service 120 and / or to the user's client device (not shown). After the data has been sent, advertising interval selection logic 2411 may then return to the normal advertising interval (eg, AI = T).

  In one embodiment of the present invention, a secure communication channel is established between the IoT device 101 and the IoT service 120 using one or more of the security / encryption techniques described above (eg, 16A-23C and related text). For example, in one embodiment, the IoT service 120 performs key exchange with the IoT device 101 as described above to encrypt all communication between the IoT device 101 and the IoT service 120.

  A method in accordance with one embodiment of the present invention is illustrated in FIG. The method may be implemented in the context of the system architecture described above, but is not limited to any particular system architecture.

  At 2500, the IoT device uses a standard advertising interval when generating advertising packets (eg, separated by time T). The IoT device maintains a standard advertising interval at 2502 until it is determined at 2501 that it has data to send. Then, at 2503, the IoT device indicates that it has data to transmit by switching the advertising interval. At 2504, the IoT hub or another network device enables the IoT device to transmit its own data by establishing a connection with the IoT device. Finally, at 2505, the IoT device sends its own pending data to the IoT hub.

Claims (66)

A method of establishing a secondary communication channel between an Internet of Things (IoT) device and a client device, comprising:
Establishing a primary secure communication channel between the IoT device and the IoT service using a primary key set;
Performing the secondary key exchange using the primary secure communication channel, wherein the client device and the IoT device respectively provide a set of secondary keys after the secondary key exchange To be done
Detecting that the primary secure communication channel is inoperable;
Accordingly, establishing a secondary secure wireless connection between the client device and the IoT device using the set of secondary keys, the client device being configured to: Providing access to data and / or functions made available by the IoT device via a secure wireless connection of
Method, including.   Access to the data and / or functions via the secondary secure wireless connection is more limited access to the data and / or functions than when connected via the primary secure communication channel The method of claim 1, comprising: Storing a pass code in the IoT device;
Requesting the user to enter the passcode from the client device;
The method according to claim 1, further comprising: providing access to the data and / or functionality of the IoT device only if the user inputs a correct passcode from the wireless device.   The method further comprises first receiving the passcode from an application of the client device prior to storing the passcode in the IoT device, the user selecting the passcode, the passcode indicating the first order safety The method according to claim 3, wherein the method is transmitted to the IoT device via a common communication channel.   The method further comprises executing the application of the client device to prompt the user to enter the passcode upon establishing the secondary secure wireless connection, the passcode comprising: The method according to claim 4, wherein the application transmits to the IoT device before providing access to the data and / or functions.   6. The method according to claim 5, wherein the IoT device comprises a wireless door lock and at least one function to be accessed via the secondary secure communication channel comprises unlocking the door lock. . Establishing a primary secure communication channel between the IoT device and the IoT service using a primary key set,
Establishing communication between the IoT service and the IoT device through an IoT hub or client device;
Generating a service public key and a service secret key by key generation logic of a first encryption engine on the IoT service;
Generating a device public key and a device secret key by key generation logic of a second encryption engine on the IoT device;
Transmitting the service public key from the first encryption engine to the second encryption engine, and transmitting the device public key from the second encryption engine to the first encryption engine.
Generating a secret using the device public key and the service private key;
Generating the same secret using the service public key and the device private key;
Encrypting and decrypting data packets transmitted between the first encryption engine and the second encryption engine using the secret or using a data structure derived from the secret When,
The method of claim 1, comprising:   The method of claim 7, wherein the key generation logic comprises a hardware security module (HSM).   The data structure derived from the secret comprises a first key stream generated by the first encryption engine and a second key stream generated by the second encryption engine. The method according to item 8.   A first counter is associated with the first encryption engine, a second counter is associated with the second encryption engine, and the first encryption engine is associated with the second encryption engine And the second encryption engine increments the second counter responsive to each data packet sent to the first encryption engine. The method according to claim 9, wherein   The first encryption engine generates the first key stream using the current counter value of the first counter and the secret, and the second encryption engine generates the second key stream. The method according to claim 10, wherein the second key stream is generated using a current counter value of and the secret.   The first encryption engine comprises an elliptic curve method (ECM) module for generating the first key stream using the first counter value and the secret, and the second encryption engine The method according to claim 11, comprising an ECM module for generating the second key stream using the first counter value and the secret. The first encryption engine generates a first encrypted data packet by encrypting a first data packet using the first key stream,
The method according to claim 11, wherein the first encrypted data packet is sent to the second encryption engine along with the current counter value of the first counter.   The second encryption engine generates the first key stream using the current counter value of the first counter and the secret, and the encryption is performed using the first key stream The method according to claim 13, wherein said data packet is decoded. A system,
With an IoT device to establish a primary secure communication channel with the IoT service using a primary key set,
The IoT device performs secondary key exchange using the primary secure communication channel,
The client device and the IoT device are each provided with a set of secondary keys after the secondary key exchange,
The IoT device and / or client device detects that the primary secure communication channel is inoperable,
The IoT device and / or the client device accordingly establish a secondary secure wireless connection between the client device and the IoT device using the set of secondary keys,
The system, wherein the client device is provided access to data and / or functions made available by the IoT device via the secondary secure wireless connection.   The access to data and / or functions via the secondary secure wireless connection is more limited to the data and / or functions than when connected via the primary secure communication channel The system of claim 15, comprising access. An authentication module for storing a passcode on the IoT device and prompting a user to input the passcode from the client device, further comprising:
16. The system of claim 15, wherein the authentication module provides access to the data and / or functionality of the IoT device only if the user enters the correct passcode from the wireless device.   The passcode is first received from an application of the client device before storing the passcode in the IoT device, the user selects the passcode, and the passcode is the primary secure communication channel The system according to claim 17, which is sent to the IoT device via.   The application executed on the client device further comprises prompting the user to enter the passcode when the secondary secure wireless connection is established, the passcode comprising: The system according to claim 18, wherein the application transmits to the IoT device before providing access to data and / or functions.   20. The IoT device comprises a wireless door lock, wherein at least one function to be accessed via the secondary secure communication channel comprises locking or unlocking the door lock. System described. Establishing a primary secure communication channel between the IoT device and the IoT service using a primary key set,
Establishing communication with the IoT device through the IoT hub or client device;
A first encryption engine on the IoT service, comprising key generation logic for generating a service public key and a service secret key;
A second encryption engine on the IoT device, comprising key generation logic for generating a device public key and a device secret key,
The first encryption engine is for transmitting the service public key to the second encryption engine, and the second encryption engine is for transmitting the device public key to the first encryption engine It is
The first encryption engine is for generating a secret using the device public key and the service private key,
The second encryption engine is for generating the same secret using the service public key and the device secret key,
Once the secret is generated, the first encryption engine and the second encryption engine use the secret or use a data structure derived from the secret to generate the first cipher. 16. The system of claim 15, wherein the system encrypts and decrypts data packets transmitted between an encryption engine and the second encryption engine.   22. The system of claim 21, wherein the key generation logic comprises a hardware security module (HSM).   The data structure derived from the secret comprises a first key stream generated by the first encryption engine and a second key stream generated by the second encryption engine. The system according to 22.   The system further comprises a first counter associated with the first encryption engine and a second counter associated with the second encryption engine, the first encryption engine comprising the second encryption engine. Said second counter responsive to each data packet sent to said first encryption engine, and said second counter responsive to each data packet sent to said second encryption engine. 24. The system of claim 23, wherein: A system,
An IoT device comprising a wireless communication interface to establish communication with an Internet of Things (IoT) service, comprising:
The IoT device comprises an application for executing commands received from the IoT service and generating responses accordingly.
Messaging obfuscation logic to modify timing for sending the response to the IoT service.   26. The system of claim 25, wherein the messaging disambiguation logic corrects the timing for sending the response by introducing a variable delay into the response.   27. The system of claim 26, wherein the messaging disambiguation logic generates a random delay to be used for the variable delay for each response.   An IoT hub or mobile device for communicatively coupling the IoT device to the IoT service, the IoT device establishing a local wireless connection to the IoT hub or mobile device using the wireless communication interface The system according to claim 25, wherein the IoT hub establishes a connection to the IoT service via the Internet.   The method further comprises service-side messaging disambiguation logic executed on the IoT service, the service-side messaging disambiguation logic sending one or more disambiguation packets to the IoT device, responsive to the disambiguation packets, 26. The system of claim 25, wherein the messaging disambiguation logic of the IoT device generates an obfuscated reply at a specified time.   30. The system of claim 29, wherein each obfuscation packet sent by the service-side messaging disambiguation logic includes timing data indicating when the obfuscation reply should be sent.   31. The system of claim 30, wherein the service-side messaging disambiguation logic comprises a set of disambiguation rules to determine when an disambiguation packet should be sent and to generate the timing data.   The service-side messaging disambiguation logic generates randomly selected timing data within a specified range, and the randomly selected timing data results in an obfuscated reply randomly transmitted from the IoT device A system according to item 31.   The messaging disambiguation logic of the IoT device should send one or more decoy advertisements in response to one or more of the disambiguation packets sent from the service-side messaging disambiguation logic 30. The system of claim 29, wherein A system,
An IoT device comprising a wireless communication interface for establishing communication with an Internet of Things (IoT) service, comprising:
The IoT device comprises an application for executing commands received from the IoT service and for generating responses accordingly.
Service-side messaging disambiguation logic executed on the IoT service, wherein the service-side messaging disambiguation logic sends one or more disambiguation packets to the IoT device, responsive to the disambiguation packets: The IoT device generates an obfuscated reply at a specified time, service side messaging obfuscation logic,
A system comprising:   35. The system of claim 34, wherein each disambiguation packet sent by the service-side messaging disambiguation logic includes timing data indicating when the disambiguation reply should be sent.   36. The system of claim 35, wherein the service-side messaging disambiguation logic comprises a set of disambiguation rules to determine when disambiguation packets should be sent and to generate the timing data.   The service-side messaging disambiguation logic generates randomly selected timing data within a specified range, and the randomly selected timing data results in an obfuscated reply randomly transmitted from the IoT device A system according to item 36.   The messaging disambiguation logic of the IoT device should send one or more decoy advertisements in response to one or more of the disambiguation packets sent from the service-side messaging disambiguation logic 35. The system of claim 34.   37. The system of claim 36, wherein the obscuring rules specify generating an obscuring packet and / or setting timing data based on latest state variables associated with the IoT device.   40. The system of claim 39, wherein the updated state variable includes an updated battery level of the IoT device and / or an indication of an IoT device type.   41. The service-side messaging disambiguating logic should send relatively less obfuscated packets, for relatively low battery levels, and / or for particular types of IoT devices. System described. Method,
Sending commands from the Internet of Things (IoT) service to the IoT device;
Sending an obfuscation packet from the IoT service to the IoT device;
Executing the command on the IoT device to generate a result;
Sending the result from the IoT device to the IoT service;
Sending an ambiguous reply from the IoT device to the IoT service;
Method, including. Determining a first length of time to wait before sending the obfuscated reply;
43. The method of claim 42, further comprising: sending the obscuring reply after waiting for the first length of time.   44. The method of claim 43, wherein the first length of time is specified in the obfuscated packet sent from the IoT service. A system,
An IoT device comprising a first wireless networking interface for establishing communication with an Internet of Things (IoT) hub via a local wireless network channel, wherein the first wireless networking interface is between advertising packets Implement the first advertising interval on the IoT device,
Advertising interval selection logic for causing the first wireless networking interface to use a second advertising interval for advertising packets when it detects that the IoT device has data to be sent to the IoT hub. Advertising interval selection logic, wherein the IoT hub detects that the IoT device has data to be transmitted based on a change to the second advertising interval;
A system comprising:   46. The apparatus of claim 45, wherein the first advertising interval comprises a first time length T, and the second advertising interval comprises a second time length T / n, where n is a positive value. System.   46. The apparatus of claim 45, wherein the wireless networking interface comprises a Bluetooth Low Energy (BTLE) interface, the local wireless network channel comprises a BTLE channel, and the first advertising interval comprises a standard BTLE advertising interval. system.   The method according to claim 45, wherein the IoT hub comprises a second wireless networking interface comprising advertising interval detection logic for detecting the second advertising interval indicating that the IoT device has data to be transmitted. System described.   51. The method of claim 48, wherein upon detecting the second advertising interval, the second wireless networking interface should send an indication to the first wireless networking interface that it may transmit the data. System described.   50. The system of claim 49, wherein upon receiving the indication, the first wireless networking interface transmits the data to the second wireless networking interface.   The IoT service further includes an IoT service communicably coupled to the IoT hub via the Internet, wherein the IoT service establishes a secure communication channel with the IoT device through the IoT hub, and the IoT hub is configured to 51. The system of claim 50, transmitting the data received from a device to the IoT service. A first encryption engine on the IoT service, comprising key generation logic for generating a service public key and a service secret key;
And a second encryption engine on the IoT device, comprising key generation logic for generating a device public key and a device private key.
The first encryption engine is for transmitting the service public key to the second encryption engine, and the second encryption engine transmits the device to the first encryption engine. For sending the public key,
The first encryption engine is for generating a secret using the device public key and the service secret key,
The second encryption engine is for generating the same secret using the service public key and the device secret key,
Once the secret is generated, the first encryption engine and the second encryption engine use the secret or use a data structure derived from the secret to generate the first cipher. 52. The system of claim 51, wherein the system encrypts and decrypts data packets sent between an encryption engine and the second encryption engine.   53. The system of claim 52, wherein the key generation logic comprises a hardware security module (HSM).   The data structure derived from the secret comprises a first key stream generated by the first encryption engine and a second key stream generated by the second encryption engine. 52. A system according to item 52.   The system further comprises a first counter associated with the first encryption engine and a second counter associated with the second encryption engine, the first encryption engine comprising the second encryption engine. Said second counter responsive to each data packet sent to said first encryption engine, and said second counter responsive to each data packet sent to said second encryption engine. 55. The system of claim 54, wherein is increased.   The first encryption engine generates the first key stream using the current counter value of the first counter and the secret, and the second encryption engine generates the second key stream. 56. The system of claim 55, wherein the second key stream is generated using a current counter value of and the secret.   The first encryption engine comprises an elliptic curve method (ECM) module for generating the first key stream using the first counter value and the secret, and the second encryption engine 57. The system of claim 56, comprising an ECM module for generating the second key stream using the first counter value and the first secret.   The first encryption engine generates a first encrypted data packet by encrypting a first data packet using the first key stream, the first encryption 57. The system of claim 56, further comprising transmitting an encrypted data packet to the second encryption engine along with the current counter value of the first counter.   The second encryption engine generates the first key stream using the current counter value of the first counter and the secret, and the encryption is performed using the first key stream 59. The system of claim 58, wherein said data packet is decoded. Method,
Selecting a first advertising interval for the Internet of Things (IoT) device, wherein the first advertising interval specifies a timing for the transmission of advertising packets;
Detecting that the IoT device has data to send to the IoT hub;
Dynamically modifying the advertising interval to a second advertising interval, wherein the second advertising interval informs the IoT hub that the IoT device has data to send;
Receiving instructions from the IoT hub to transmit the data from the IoT device;
Transmitting the data from the IoT device;
Method including.   61. The apparatus of claim 60, wherein the first advertising interval comprises a first length of time T, and the second advertising interval comprises a second length of time T / n, where n is a positive value. the method of.   61. The method of claim 60, wherein the first and second advertising intervals comprise Bluetooth Low Energy (BTLE) advertising intervals.   The IoT device comprises a first BTLE network interface for transmitting advertising packets according to the first and second advertising intervals, and the IoT hub transmits the advertising packets according to the first and second advertising intervals. 61. The method of claim 60, comprising a second BTLE network interface for detecting advertising packets.   64. When detecting the second advertising interval, the second wireless networking interface should send an indication to the first wireless networking interface that it may send the data. Method described.   65. The method of claim 64, wherein upon receiving the indication, the first wireless networking interface transmits the data to the second wireless networking interface.   The method further includes communicatively coupling an IoT service to the IoT hub via the Internet, wherein the IoT service establishes a secure communication channel with the IoT device through the IoT hub, the IoT hub is configured to: 66. The method of claim 65, transmitting the data received from a device to the IoT service.