JP2019502206A - System and method for secure Internet of Things (IoT) device provisioning - Google Patents

Abstract

  Systems and methods for provisioning IoT devices using association ID codes are described. For example, one embodiment of the method generates an association between a new Internet of Things (IoT) device identification (ID) code and an association ID code, and stores the association in the IoT device database of the IoT service. Reading the association ID code from the new IoT device and sending the association ID code to the IoT service, wherein the IoT service performs a lookup in the IoT device database using the association ID code; Determining a device ID code and provisioning a new IoT device to communicate with the IoT service using the device ID code.

Description

  The present invention relates generally to the field of computer systems. More specifically, the present invention relates to a system and method for secure Internet of Things (IoT) device provisioning.

[Description of related technology]
“Internet of Things” refers to the interconnection of devices that are uniquely identifiable within the Internet infrastructure. Ultimately, IoT provides a wide range of virtually any type of physical thing that can provide information about itself and / or its surroundings and / or remotely controlled via client devices across the Internet. Expected to bring new types of applications.

  IoT development and adoption is delayed due to issues related to connectivity, power, and lack of standardization. For example, one barrier to IoT development and adoption is the lack of a standard platform that allows developers to design and deliver new IoT devices and services. To enter the IoT market, developers need to design an entire IoT platform from scratch, including the network protocols and infrastructure, hardware, software, and services needed to accommodate the desired IoT implementation. is there. As a result, each provider of IoT devices uses proprietary technology to design and connect IoT devices, making it difficult for end users to adopt multiple types of IoT devices. Another obstacle to IoT adoption is the difficulty associated with connecting and powering IoT devices. For example, connected devices such as refrigerators, garage door openers, environmental sensors, home security sensors / controllers, etc. require a power source for supplying power to each connected IoT device, and such power sources are often provided at convenient locations. It is not done.

  Another problem that exists is that wireless technologies used to interconnect IoT devices such as Bluetooth® LE (BTLE) are generally short-range technologies. Thus, if a data collection hub for an IoT implementation is outside the scope of the IoT device, that IoT device cannot send data to the IoT hub (and vice versa). As a result, there is a need for techniques that allow an IoT device to provide data to an IoT hub (or other IoT device) that is out of range.

  In addition, current IoT implementations that rely on wireless communication protocols such as BTLE do not provide adequate security measures. Thus, additional techniques are needed to improve security in IoT implementations.

  A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:

2 illustrates different embodiments of an IoT system architecture. 2 illustrates different embodiments of an IoT system architecture. 2 illustrates an IoT device according to an embodiment of the present invention. 2 illustrates an IoT hub according to one embodiment of the present invention. Fig. 4 illustrates an embodiment of the present invention for controlling and collecting data from an IoT device and generating a notification. Fig. 4 illustrates an embodiment of the present invention for controlling and collecting data from an IoT device and generating a notification. Fig. 4 illustrates an embodiment of the present invention for collecting data from IoT devices and generating notifications from IoT hubs and / or IoT services. FIG. 4 illustrates one embodiment of a system where an intermediate mobile device collects data from a fixed IoT device and provides the data to an IoT hub. 2 illustrates intermediate connection logic implemented in one embodiment of the present invention. 2 illustrates a method according to one embodiment of the present invention. Fig. 4 illustrates one embodiment where program code and data updates are provided to an IoT device. FIG. 4 illustrates one embodiment of a method in which program code and data updates are provided to an IoT device. FIG. 3 illustrates a high level diagram of one embodiment of a security architecture. FIG. 6 illustrates one embodiment of an architecture in which a subscriber identity module (SIM) is used to store keys on an IoT device. FIG. 6 illustrates one embodiment where an IoT device is registered using a bar code or QR code. FIG. FIG. 6 illustrates an embodiment in which pairing is performed using a bar code or QR code. Fig. 4 illustrates one embodiment of a method for programming a SIM using an IoT hub. FIG. 6 illustrates one embodiment of a method for registering an IoT device with an IoT hub and an IoT service. FIG. 6 illustrates one embodiment of a method for encrypting data transmitted to an IoT device. Fig. 4 illustrates different embodiments of the present invention for encrypting data between an IoT service and an IoT device. Fig. 4 illustrates different embodiments of the present invention for encrypting data between an IoT service and an IoT device. Fig. 4 illustrates an embodiment of the present invention for performing a secure key exchange, generating a common secret, and generating a key stream using the secret. 2 illustrates a packet structure according to an embodiment of the present invention. Fig. 4 illustrates a technique used in one embodiment for reading and writing data to and from an IoT device without formally pairing with the IoT device. Fig. 3 illustrates an exemplary set of command packets used in one embodiment of the present invention. Fig. 4 illustrates an exemplary sequence of transactions using command packets. 2 illustrates a method according to one embodiment of the present invention. 2 illustrates a method for secure pairing according to an embodiment of the present invention. 2 illustrates a method for secure pairing according to an embodiment of the present invention. 2 illustrates a method for secure pairing according to an embodiment of the present invention. 3 illustrates an embodiment of the present invention for adjusting an advertising interval for identifying a data transmission state. 2 illustrates a method according to one embodiment of the present invention. FIG. 6 illustrates the operation of an embodiment in which multiple IoT hubs attempt to send data / commands to an IoT device. FIG. 6 illustrates the operation of an embodiment in which multiple IoT hubs attempt to send data / commands to an IoT device. FIG. 6 illustrates the operation of an embodiment in which multiple IoT hubs attempt to send data / commands to an IoT device. 2 illustrates a method according to one embodiment of the present invention. 1 illustrates one embodiment of a system for secure IoT device provisioning. 2 illustrates a method according to one embodiment of the present invention. One embodiment of a system for performing flow control of multiple IoT devices. 2 illustrates a method according to one embodiment of the present invention. 1 illustrates one embodiment of a system for managing application attributes, system attributes, and priority notification attributes.

  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 invention described below. However, it will be apparent to one 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 an 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 that includes a predefined networking protocol stack and a basic hardware / software platform for an IoT hub that is coupled to the Internet. In addition, one embodiment includes an IoT service through which an IoT hub and connected IoT devices can be accessed and managed as described below. In addition, one embodiment of an 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 architecture platform on which embodiments of the present invention may be implemented. Specifically, the illustrated embodiment includes a plurality of communicatively coupled via a local communication channel 130 to a central IoT hub 110 that is communicatively coupled to an IoT service 120 via the Internet 220 itself. IoT devices 101-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 (eg, using a pairing technique 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, thermal sensors, motion detectors, etc.), the database 122 is continuously updated to store data collected by the IoT devices 101-105. Can be done. The data stored in the database 122 is then sent to the end user via an IoT application or browser installed on the user device 135 (or via a desktop or other client computer system) and a web client (eg, A website 130 that subscribes to the IoT service 120, etc.) may be made accessible.

  The IoT devices 101-105 collect information about itself and its surroundings, and provide the collected information to the IoT service 120, the user device 135, and / or the external website 130 via the IoT hub 110. Various types of sensors may be provided. Some of the IoT devices 101-105 can perform specified functions in response to control commands sent via the IoT hub 110. Various examples of information collected by the IoT devices 101-105 and control commands are provided below. In one embodiment described below, the IoT device 101 is a user input device designed to record user selections and send user selections to the IoT service 120 and / or 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 may include a WiFi radio for establishing a WiFi connection via a WiFi access point or router 116, which connects the IoT hub 110 to the Internet (eg, end Connect (via an Internet service provider that provides Internet services to users). Of course, it should be noted that the basic principles of the present invention are not limited to a 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) with battery power. To conserve power, the local communication channel 130 can be implemented using a low power wireless communication technology 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 protocol stack.

  As described above, in one embodiment, the IoT platform allows a user to access and configure connected IoT devices 101-105, IoT hub 110, and / or IoT service 120. IoT applications or web applications running on the user device 135 are included. 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 may maintain a user database 131 that includes 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 (eg, the user's home or business). This can be done, for example, to extend the radio range required to connect all of the IoT devices 101-105. As described above, if a user has multiple hubs 110, 111, they may be connected via a local communication channel (eg, WiFi, Ethernet, power line 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 the IoT hub 110, can function as a “master” hub, which can be used for all other premises 180 on the user premises 180, such as the 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 provided with a cellular communication interface for establishing a connection to the IoT service 120. In this way, all communication between the IoT service 120 and the other IoT hub 111 flows through the master IoT hub 110. In this role, the master IoT hub 110 is responsible for data exchanged between other IoT hubs 111 and the IoT service 120 (eg, service some data requests locally if possible). Additional program code may be provided to perform the filtering operation.

  Regardless of how the IoT hubs 110-111 are connected, in one embodiment, the IoT service 120 logically associates the hub with the user and attaches all installed IoT devices 101-105 to the installed application. Combine 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 connected to a WiFi network 116, an Ethernet network, and / or power-line communications (PLC) networking (eg, a network). May be connected via a local network, all or part of which may be performed via the user's power line). In addition, for IoT hubs 110-111, each of the IoT devices 101-105 can be any arbitrary, such as WiFi, Ethernet, PLC, or Bluetooth LE, to name a few. A type of local network channel may be used to interconnect with the IoT hubs 110-111.

  FIG. 1B also shows an IoT hub 190 installed at 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, the 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 below, it is accessible via a user device having an installed application 135 (and / or browser-based interface).

  As illustrated in FIG. 2, an exemplary embodiment of the IoT device 101 includes a memory 210 that stores program code and data 201-203, and a low power microcontroller 200 that executes the program code and processes the data. . The memory 210 may be a volatile memory such as a dynamic random access memory (DRAM), or may be a non-volatile memory such as a flash memory. In one embodiment, non-volatile memory may be used for persistent storage and volatile memory may be used for program code execution and data execution. Further, the memory 210 may be integrated within the low power microcontroller 200 and coupled to the 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 defines an application-specific function set that is executed by the IoT device 201 and library code 202, including a predefined set of building blocks that can be utilized by an application developer of the IoT device 101. Program code 203 may be included. In one embodiment, the library code 202 is a set of basic functions required to implement an IoT device, such as a communication protocol stack 201, to enable communication between each IoT device 101 and the IoT hub 110. including. As described above, in one embodiment, the communication protocol stack 201 includes a Bluetooth® LE protocol stack. In this embodiment, the Bluetooth® LE radio and antenna 207 may be integrated within the low power microcontroller 200. However, the basic principles of the present invention are not limited to any particular communication protocol.

  The particular embodiment shown in FIG. 2 also includes a plurality of input devices or sensors 210 that receive user input and provide user input to the low power microcontroller, which includes 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 supplying 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 (eg, rechargeable by connecting an IoT device to an AC power source (not shown)).

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

  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 specific 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, a security sensor and / or a door lock opener may be included. Of course, these examples are provided for illustration only. The basic principles of the present invention are not limited to any particular type of IoT device. Indeed, considering the highly programmable nature of the low power microcontroller 200 with library code 202, application developers can easily develop new application code 203 and new I / O devices 250, substantially It can interface with a low power microcontroller for any type of IoT application.

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

  In one embodiment, a wake-up receiver 207 is included to wake up the IoT device from a very low power state that is not substantially consuming power. In one embodiment, the wakeup receiver 207 causes the IoT device 101 to respond to a wakeup signal received from a wakeup transmitter 307 configured on the IoT hub 110 as shown in FIG. Configured to get out of power state. Specifically, in one embodiment, transmitter 307 and receiver 207 together form an electrical resonant transformer circuit such as a Tesla coil. In operation, energy is transmitted via a radio frequency signal from the transmitter 307 to the receiver 207 when the hub 110 needs to wake up the IoT device 101 from a very low power state. For energy transfer reasons, the IoT device 101 can be configured to consume substantially no power because it does not need to “hear” the signal from the hub continuously when it is in a low power state. (Similar to the network protocol, where the device can be activated via a network signal). Rather, the microcontroller 200 of the IoT device 101 can be configured to wake up after being effectively powered down by using 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 the cellular service 115. Alternatively, as described above, the IoT hub 110 includes 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. You can also In one embodiment, the hardware logic 301 also includes a secure key store for storing encryption keys for encrypting communications and / or 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 to 105. As described above, in one embodiment, the local communication interface 303 / antenna 311 implements the Bluetooth (R) LE standard. However, the principles underlying the present invention are not limited to any particular protocol for establishing a local communication channel with IoT devices 101-105. Although shown as separate units in FIG. 3, the WAN interface 302 and / or the local communication interface 303 may be integrated into the same chip as the hardware logic 301.

  In one embodiment, the program code and data includes a communication protocol stack 308 that may include a separate stack for communicating via the local communication interface 303 and the WAN interface 302. In addition, the 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 a barcode on the IoT device and read by the barcode reader 106 or communicated via the local communication channel 130. In another embodiment, a unique ID code is magnetically incorporated into the IoT device, and the IoT hub can be a radio frequency ID (RFID) or near field communication (NFC) sensor, etc. When the IoT device 101 moves within a few inches of the IoT hub 110, the code is detected.

  In one embodiment, once the unique ID is communicated, the IoT hub 110 queries a local database (not shown), performs a hash 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 and the validity of the ID code can be confirmed. Once validated, in one embodiment, the IoT hub 110 pairs the IoT device 101 and stores the pairing data in 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 executing IoT service 120 may provide an IoT hub 110 and a basic hardware / software platform so that developers can easily design new IoT services. Specifically, in addition to the IoT hub 110, a 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 the IoT device 101, the SDK supports base IoT hardware (eg, the low power microcontroller 200 and other components shown in FIG. 2) to facilitate the design of various different types of applications 101. ) May include an extensive set of library codes 202 designed for In one embodiment, the SDK includes a graphical design interface where the developer only needs to specify the inputs and outputs of the IoT device. All the 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 in place 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, the IoT hub 110 manages a continuous bi-directional stream of data between the IoT devices 101-105 and the IoT service 120. In situations where updates to / from the IoT devices 101-105 are required in real time (eg, a situation where the user needs to see the current state of the security device or environmental measurements), the IoT hub may An open TCP socket can be maintained to provide periodic updates to external websites 130. The particular networking protocol used to provide the update may be tailored based on basic application needs. For example, if it may not make sense to have a continuous bi-directional stream, a simple request / response protocol can be used to collect information when needed.

  In one embodiment, both the IoT hub 110 and the IoT devices 101-105 can be updated automatically over the network. Specifically, when a new update is available for the IoT hub 110, the update can be automatically downloaded from the IoT service 120 and installed. 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 an update is available for each of the IoT devices 101-105, the update may be first 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 the same manner as described above for the IoT hub and report the result of the update to the IoT hub 110. If the update is successful, the IoT hub 110 deletes the update from its memory and updates the code installed on each IoT device (eg, so that it can continue to check for new updates for 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 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 (to name just a few) an air conditioner / heater 430, a lighting system 431, and an audiovisual device 432. Infrared (IR) and / or radio frequency (RF) blasters 401-403 are provided for transmitting remote control codes for controlling the electronic devices. In the embodiment shown in FIG. 4A, the IoT devices 101-103 are also provided with sensors 404-406, respectively, 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 sensing the current temperature / humidity and controlling the air conditioner / heater 430 accordingly based on the current desired temperature. Also good. In this embodiment, the air conditioner / heater 430 is designed to be controlled via a remote control device (typically a remote control device that itself incorporates a temperature sensor). 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. Control logic 412 executing on the IoT hub 110 receives current temperature / humidity data from the sensor 404 and accordingly controls the IoT device 101 to control the IR / RF blaster 401 according to the desired temperature / humidity. Send a 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, the air conditioner Either by turning off or turning on the heater). The command may include the necessary remote control codes 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 electronic devices 430-432 based on specified user preferences and stored control codes 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 provided by the lighting fixture 431 (or other lighting device). May be. The user may specify a desired lighting 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 brightness level of the lighting 431 (eg, brighten the lighting if the current brightness is too low, Or, if the current brightness is too high, dimm the lighting, or simply turn the lighting 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, AppleTVPP ™ PP, etc.). The sensor 406 of the IoT device 103 is based on an audio sensor (eg, microphone and associated logic) for detecting the current ambient volume level and / or light generated by the television (eg, within a specified spectrum). It may be an optical sensor for detecting whether the television is on or off (by measuring the light). Alternatively, the 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 user device 135, control logic 412 may send a command to the audiovisual device via IR blaster 403 of IoT device 103.

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

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

  In one embodiment, the control code required to control each of the electronic devices is stored in a database 413 on the IoT hub 110 and / or a database 422 on the IoT service 120. As illustrated in FIG. 4B, control codes may be provided to the IoT hub 110 from a master database of control codes 422 for different devices maintained on the IoT service 120. The end user may specify the type of electronic (or other) equipment that is controlled via an application or browser running on the user device 135, and in response, 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, identifying each electronic device having a unique ID).

  In addition, in one embodiment, the IoT hub 110 allows the remote control code learning module 491 to “learn” new remote control codes directly from the original remote control device 495 provided with the electronics. IR / RF interface 490 is provided. For example, if the original remote control code provided with air conditioner 430 is not included in the remote control database, the user interacts with IoT hub 110 via an application / browser on user device 135. Thus, various control codes generated by the original remote control device may be taught to the IoT hub 110 (eg, increasing temperature, decreasing temperature, etc.). As the 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 for inclusion in the central remote control code database 492. (And may subsequently be used by other users with the same air conditioner unit 430).

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

  In addition to providing the general control functions described, one embodiment of IoT hub 110 and / or IoT service 120 sends notifications related to the current state of each electronic device to the end user. The notification may be a text message and / or an application specific notification, and then the notification may be displayed on the display of the user's mobile device 135. For example, if the user's air conditioner has been on for a long time but the temperature has not changed, the IoT hub 110 and / or the IoT service 120 will send a notification to the user that the air conditioner is not functioning properly. May be. The user is not at home (this may be detected via a motion sensor or may be based on the user's current detected position) and the sensor 406 indicates that the audiovisual device 430 is on. Or 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 devices 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 the remote control that includes 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. When connected via the IoT service 120, the user selection may be transferred from the IoT service 120 to the IoT hub 110, which will then control the device via the control logic 412. . Alternatively, user input may be sent directly from the user device 135 to the 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 for the electronic devices 430-432. In addition to maintaining the desired temperature, brightness level, and volume level as described above, the control logic 412 may automatically turn off the electronic device 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 the sensor 405 indicates that the lighting is on, the control logic 412 can determine whether the audiovisual device and lighting May be sent automatically via IR / RF blasters 403 and 402 to turn off each.

  FIG. 5 illustrates an additional embodiment of the IoT devices 104 and 105 with sensors 503 and 504 for monitoring the 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 sends the current temperature measured by the temperature sensor 503 to the IoT hub 110 and / or the IoT service 120. If the stove is detected to be on beyond the threshold period (eg, based on the measured temperature), the control logic 512 may notify the end user of a notification that the stove 530 is on. It may be transmitted to the device 135. In addition, in one embodiment, the IoT device 104 is either responsive to receiving instructions 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 off the stove. In one embodiment, the control logic 501 comprises a switch for shutting off electricity or gas to the stove 530. However, in other embodiments, the 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 operation of certain types of electronic equipment such as washing machines and / or dryers. Another sensor that can be used is an audio sensor (eg, microphone and logic) for detecting 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 (eg, the operation is detected for an extended period of time and the washing machine / When 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, the first IoT device with control logic and switches may be configured to turn off all power in the user's home, and the second IoT device with control logic and switches is , May be configured to turn off all gas in the user's home. The IoT device with the sensor may then be positioned on or near an electric or gas powered device in the user's home. If the user is notified that a particular device remains on (eg, stove 530), the user can send a command to turn off all electricity or gas in the home to prevent damage. Also good. Alternatively, the control logic 512 of the IoT hub 110 and / or the 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 (eg, by not receiving a request or response from the IoT hub for a specified duration), the IoT service 120 This information will be communicated to the end user device 135 (eg, by sending a text message or 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 short-range technology, so the hub for IoT implementation is outside the scope of the IoT device. If so, the IoT device cannot send data to the IoT hub (and vice versa).

  To address this deficiency, an embodiment of the present invention provides an IoT device that is outside the radio range of an IoT hub to periodically connect with one or more mobile devices when the mobile device is in range. Provides a mechanism for Once connected, the IoT device can send any data that needs to be provided to the IoT hub to the mobile device, which then forwards 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 include a data collection device configured in the refrigerator to monitor available food items in the refrigerator, users consuming the food items, and current temperature. Of course, the basic principles of the present invention are not limited to any particular type of IoT device. The techniques described herein are devices used to collect and transmit data related to smart meters, stoves, washing machines, dryers, lighting systems, HVAC systems, and audiovisual equipment, to name just a few. May be implemented using any type of IoT device.

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

  During operation, an out-of-range IoT device 601 may check connectivity with the mobile device 611 periodically or continuously. After establishing the connection (eg, as a result of the user moving near 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 a 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 the data once communication with the IoT hub 110 is established (eg, when the user walks within range of the IoT hub 110). The IoT hub may then store the data in the central data repository 413 and / or send the data to one or more services and / or other user devices over the Internet. In one embodiment, the mobile device 611 may provide data to the IoT hub 110 using a different type of communication channel (potentially a higher power communication channel such as WiFi).

  IoT devices 601, mobile devices 611, and IoT hubs that are out of range 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 The IoT hub 110 may be configured by an 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 retrieves and establishes a connection with the intermediate connection logic / application 711 (which may be implemented as a device application) on the mobile device to provide a temporary data repository. Data is transmitted to 615. The intermediate connection logic / application 701 on the mobile device 611 then forwards 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, and 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 mobile device 611, in one embodiment, IoT device 601 may be configured to establish a wireless connection with one or more intermediate IoT devices located within range of IoT hub 110. In this embodiment, any IoT device 601 outside the scope of the IoT hub may be linked to the hub by forming a “chain” using other IoT devices.

  In addition, for simplicity, only a single mobile device 611 is illustrated in FIGS. 6-7, but in one embodiment, multiple such mobile devices of different users communicate with the IoT device 601. It may be configured as follows. Moreover, 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 a variety of different types of related data. For example, in one embodiment, each time the mobile device 611 connects with the IoT device 601, a user identification may be included 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 specific food items 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, who will wash clothes, which users will watch TV on a given day, the time each user will go to sleep and wake up, etc. is there. All of this cloud source 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 for monitoring elderly users who may need assistance. For this application, the mobile device 611 may be a very small token worn by an elderly user to collect information in different rooms at 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 an elderly user). If data has not been collected for a specified period (eg, 12 hours), this means that the elderly user has not moved around the home and / or has not opened the refrigerator. The IoT hub 110 or an external service connected to the IoT hub may then send alert notifications to these other individuals notifying them that they should confirm the elderly user. In addition, the collected data 605 shows 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 TV, and how often Other related information such as the frequency of elderly users washing clothes may also be included.

  In another implementation, if there is a problem with an electronic device such as a washing machine, refrigerator, HVAC system, 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 along with a request to resolve the problem. The technician can then arrive at home with the required replacement parts.

  A method according to 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, IoT devices that are outside the scope of the IoT hub periodically collect data (eg, opening the refrigerator door, used food items, etc.). At 802, the IoT device periodically or continuously checks connectivity with the mobile device (eg, using standard local radio technology to establish a connection, such as that specified by the BTLE standard). ). If a connection to the mobile device is established and determined at 802, the collected data is transmitted to the mobile device at 803. At 804, the mobile device transmits data to the IoT hub, external service, and / or user. As stated, the mobile device can immediately send data if it is already connected (eg, via a WiFi link).

  In addition to collecting data from the IoT device, in one embodiment, the techniques described herein may be used to update data or otherwise provide data to the IoT device. 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 an IoT device 601 (or group of such IoT devices). Program code updates may include system updates, patches, configuration data, and any other data required 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 a mobile device or computer, which are then on the IoT hub 110 using the techniques described herein. Stored and provided to the IoT device. Specifically, in one embodiment, intermediate connection logic / application 721 on IoT hub 110 communicates with intermediate connection logic / application 711 on mobile device 611 to store program code updates in temporary storage 615. To 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 update to the device. To do. In one embodiment, the IoT device 601 may then enter an automatic update process to install 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 made available on IoT hubs and / or external services (eg, coupled to mobile devices 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 the mobile device periodically checks to determine if a connection is established at 902. If a connection is established and determined at 903, 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 encryption keys used by the embodiments described below. Contains a store (see, eg, FIGS. 10-15 and 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 communication between the IoT service 120, the IoT hub 110, and the IoT devices 101 and 102. 2 illustrates a high-level architecture using technology.

  Embodiments using public / private key pairs are described first, followed by embodiments using symmetric key exchange / encryption techniques. 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, the public key is sent 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, 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 checking the validity of the signature ( That is, it is signed by a kind of certificate). Thus, rather than simply 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 each device's private key. Security logic 1002, 1304 then performs the encryption / decryption operations described herein using the securely stored secret key. Similarly, the IoT hub 110 uses a secure storage device 1011 for storing the IoT hub secret key and the public keys of the IoT devices 101-102 and the IoT service 120, and the encryption / decryption operation using the key. Includes security logic 1012 for execution. Finally, the IoT service 120 communicates with the IoT hub and device using the key and a secure storage device 1021 for security that stores the various IoT devices and the public key of the IoT hub. May include security logic 1013 for encrypting / decrypting. In one embodiment, when the IoT hub 110 receives a public key certificate from the IoT device, the IoT hub 110 verifies it (eg, by verifying the signature using the parent key above). The public key can then be extracted therefrom and stored in the secure key store 1011.

  By way of 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 needed, the security logic 1013 encrypts the data / command using the public key of the IoT device 101 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 parent key described above so that device 101 can verify that it has received an unmodified message from a trusted source. To sign the encrypted message. The device 101 may then validate the signature using the public key corresponding to the private key and / or the parent key. As described above, symmetric key exchange / encryption techniques may be used instead of public / private key encryption. In these embodiments, one device is stored privately and the corresponding public key is not provided to other devices, but to each device for encryption and to verify the validity of the signature. You may provide a copy of the same symmetric key that is used for. An example of a symmetric key algorithm is Advanced Encryption Standard (AES), but the basic principles of the present 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 (eg, Request for Comments ) (RFC) 6063). However, the basic principles of the present invention are not limited to any particular key provisioning protocol.

  Once the symmetric keys are exchanged, they can be used by each device 101 and IoT hub 110 to encrypt communications. Similarly, the IoT hub 110 and the IoT service 120 may perform a secure symmetric key exchange and then encrypt the communication using the exchanged symmetric key. In one embodiment, new symmetric keys are periodically exchanged between device 101 and hub 110 and between hub 110 and IoT service 120. In one embodiment, a new symmetric key is exchanged for each new communication session between device 101, hub 110, and service 120 (eg, a new key is generated and securely exchanged for each communication session). ). 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 device 101 and service 120 during installation to prevent security breaches at hub security module 1012. When sending a message to the device 101, the service 120 may first encrypt / MAC with this device installation key and then encrypt / MAC with the hub session key. 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 hub 110 and device 101 track this value and verify that it is correct for each successive communication between devices. This same technology can be implemented between the hub 110 and the service 120. Using counters in this way will make it more difficult to forge communications between devices (because the counter value is incorrect). However, even without this, an 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 uses the private key to decrypt the IoT hub packet to generate an encrypted IoT device packet and associate it with To the received IoT device 101. Next, the IoT device 101 decrypts the IoT device packet using the secret key and generates a command / data starting from the IoT service 120. The IoT device 101 may then process the data and / or execute the command. Using symmetric encryption, each device encrypts and decrypts using a shared symmetric key. In either 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 communications from the IoT device 101 to the IoT hub 110 and communications to the IoT service 120. For example, using a public / private key configuration, in one embodiment, the security logic 1002 on the IoT device 101 uses the public key of the IoT hub 110 to encrypt data packets sent to the IoT hub 110. To do. The security logic 1012 on the IoT hub 110 may then decrypt the data packet using the IoT hub's secret key. Similarly, the security logic 1002 on the IoT device 101 and / or the security logic 1012 on the IoT hub 110 may encrypt a data packet sent to the IoT service 120 using the public key of the IoT service 120 (this Can then be decrypted by the security logic 1013 on the IoT service 120 using the service's private key). Using symmetric keys, device 101 and hub 110 may share a symmetric key, while hub and service 120 may share different symmetric keys.

  In the above description, although certain specific details are described above, it should be noted that the basic principles of the invention may be implemented using a variety of different encryption techniques. For example, some embodiments described above use asymmetric public / private key pairs, while other embodiments securely exchange between various IoT devices 101-102, IoT hub 110, and IoT service 120. Can be used. Further, 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 can then use the key to validate the signature.

  As illustrated in FIG. 11, in one embodiment, the secure key store 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 a SIM with one or more sets of cryptographic keys, the user removes 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 this pair may be stored in the secure storage device 411 of the IoT hub, while The secret key may be stored in the programmable SIM 1101. In addition, the programming logic 525 uses the public key of the IoT hub 110, the IoT service 120, and / or any other IoT device 101 (for use in encrypting outgoing data by the security logic 1302 on the IoT device 101). B) 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 with the SIM). Can be done. 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 technique described above with respect to FIG. 11 provides great flexibility in providing new IoT devices to end users. Rather than requiring the user to register each SIM directly with a particular service provider at the point of sale / purchase (as is currently done), the SIM is directly connected by the end user via the IoT hub 110. It may be programmed and the result of the programming may be securely communicated to the IoT service 120. Therefore, a new IoT device 101 can be sold to an end user from an online or local retailer and later the IoT service 120 can be securely provisioned.

  Although registration and encryption techniques have been described above in the specific context of SIM (Subscriber Identity Module), the basic principles of the present invention are not limited to “SIM” devices. Rather, the basic principles of the present invention may be implemented using any type of device that has a secure storage device for storing cryptographic key sets. Furthermore, while the above embodiment includes a removable SIM device, 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 a SIM (or other device), the SIM is pre-programmed into the IoT device 101 prior to distribution to the end user. In this embodiment, when a user sets up the IoT device 101, various techniques described herein securely exchange encryption 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 public key of the IoT device 101 or SIM 1001. 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, in a secure storage device). Used as a pointer to an already stored public key). The barcode or QR code 601 may be printed on a separate card (as shown in FIG. 12A) or directly on the IoT device itself. Regardless of where the barcode is printed, in one embodiment, the IoT hub 110 reads the barcode and uses the resulting data as security logic 1012 on the IoT hub 110 and / or security logic on the IoT service 120. A bar code reader 206 is provided for provision to the computer 1013. The security logic 1012 on the IoT hub 110 may then store the public key of the IoT device in its secure key store 1011, and the security logic 1013 on the IoT service 120 is stored in its secure storage device 1021. The public key may be stored (for use in later encrypted communications).

  In one embodiment, the data contained in the barcode or QR code 1201 is also sent to the user device 135 (e.g., using a browser-based applet designed by an installed IoT application or IoT service provider). (e.g., an iPhone (R) or Android device). Once captured, the barcode data can 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 the client device 135 to the IoT hub 110 via a secure local connection (eg, via a local WiFi or Bluetooth LE connection).

  The security logic 1002 on the IoT device 101 and the security logic 1012 on the 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 a local communication channel 130 between the IoT device 101 and the IoT hub 110 (eg, the local channel 130 is Bluetooth®). In the case of LE, it is mounted in a Bluetooth (registered trademark) LE chip). Regardless of the specific location of security logic 1002, 1012, in one embodiment, security logic 1002, 1012 is designed to establish a secure execution environment for executing 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). Of course, the basic principles of the present invention are not limited to any particular type of secure execution technique.

  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, a pair embedded within a barcode or QR code 1501 rather than using the standard wireless pairing process currently used to pair Bluetooth® LE devices A ring code may be provided to the IoT hub 110 to pair the IoT hub with a corresponding IoT device.

  FIG. 12B illustrates one embodiment in which the barcode reader 206 on the IoT hub 110 captures a barcode / QR code 1201 associated with the IoT device 101. As described 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 (registered trademark) 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 a secure storage device containing 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 for that pairing is stored in secure storage 685. In one embodiment, when the local communication module 1280 of the IoT hub 110 receives the pairing code, it may encrypt communication with the IoT device 101 over the local radio channel using this code as a key.

  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 a barcode / QR code (registered trademark) 1201. The pairing data 1295 is also used to encrypt the pairing data received from the local communication module 1280 on the IoT hub 110 (e.g., to encrypt communications with the IoT hub 110) necessary to establish a secure local communication channel. Additional keys).

  Accordingly, the barcode / QR code 1201 can be used to perform local pairing in a much safer manner than current wireless pairing protocols because the pairing code is not transmitted over the air. In addition, in one embodiment, the same barcode / QR code 1201 that is used for pairing is used to identify the encryption key, from the IoT device 101 to the IoT hub 110, and to the IoT hub 110. A secure connection to the IoT service 120 can be established.

  A method for programming a SIM card according to one 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. obtain. In addition, at 1304, at least the 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 described above, in one embodiment, a programmable device other than a “SIM” card may be used to perform the same functions 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 is pre-assigned an encryption key. At 1402, this key is securely provided to the IoT hub. As described above, in one embodiment, this involves reading the barcode associated with the IoT device and identifying 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 is used between the IoT device and the IoT hub for key exchange. May be established. Regardless of how the key is transmitted, when received, the key is stored in the secure key store of the IoT hub device. As mentioned above, various secure execution technologies such as Secure Enclave, Trusted Execution Technology (TXT), and / or Trustzone are used in the IoT hub for key storage and protection Can be done. In addition, at 803, the key is securely transmitted to the IoT service, and the IoT service stores this key in its own secure key store. The IoT service may then use this key to encrypt communications 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 alteration / 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 the data / command using the IoT device public key to create an IoT device packet. The IoT service then encrypts the IoT device packet using the IoT hub's public key and creates an IoT hub packet (eg, creates 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 using the IoT device private key at 1505 to generate the data / command. At 1506, the IoT device processes the data / command.

In certain embodiments that use symmetric keys, symmetric key exchange may be negotiated between each device (eg, between each device and hub and between hub and service). When the key exchange is complete, each sending device encrypts and / or signs each transmission using a symmetric key and then sends the data to the receiving device.
Apparatus and method for establishing secure communications in an Internet of Things (IoT) system

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

  Initially in FIG. 16A, to encrypt / decrypt communications 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 the encryption engine performs 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 (other Different hardware modules can be relied upon, including, among other things, hardware security modules 1630-1631 and keystream generation modules 1640-1641 for generating a keystream using the derived secret. In one embodiment, service session key 1650 and device session key 1651 include an associated public / private key pair. 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 the same A secret is generated, which is then used by SKGM 1640-1641 to generate a key stream that encrypts and decrypts communications between the IoT service 120 and the IoT device 101. Additional details associated with generating and using secrets according to one embodiment of the present invention are provided below.

  In FIG. 16A, once a secret is generated using keys 1650-1651, the client will always send a message to IoT device 101 via IoT service 120 as indicated by clear transaction 1611. “Clear” as used herein means to indicate that the underlying message has not been encrypted using the encryption techniques described herein. However, as illustrated, in one embodiment, a secure socket layer (SSL) channel or other secure channel (e.g., Internet Protocol Security (IPSEC) channel) is used by the client to protect communications. 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 directly encrypt a message, in one embodiment, the secret and counter value are used to generate a key stream and this key stream is used to encrypt each message packet. Turn into. 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 (which in one embodiment does not have the ability to decrypt messages) 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 can then decrypt the message using the secret and process the message content. In an embodiment that uses a secret to generate a keystream, the encryption engine 1661 uses the secret and counter value to generate a keystream and then uses the keystream to decrypt the message packet. Can do.

  The message itself can include any form of communication between the IoT service 120 and the IoT device 101. For example, the message can include a command packet that instructs the IoT device 101 to perform a specific function, such as taking a measurement and notifying the client device 611 of the result and returning it, or of the IoT device 101 Configuration data constituting the operation can be included.

  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 the encrypted response to the IoT hub 110 at 1604, Hub 110 forwards the response to IoT service 120 at 1605. The encryption engine 1660 on the IoT service 120 then decrypts the response using the secret or derived keystream and is decrypted at 1606 (eg, via SSL or other secure communication channel). The response is transmitted 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 occurs via the client device 611 (eg, 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 an unencrypted version of the message to the IoT service 120 at 1611. The encryption engine 1660 encrypts the message using the secret or derived keystream and sends the encrypted message back to the client device 611 at 1612. The client device 611 then forwards the encrypted message to the IoT device 101 at 1613, and the encryption engine 1661 decrypts the message using the secret or derived key stream. The IoT device 101 can then process the message as described herein. If a response is required, the encryption engine 1661 encrypts the response using the secret, sends the encrypted response to the client device 611 at 1614, and the client device 611 sends the encrypted response at 1615 to the IoT. Transfer to service 120. The encryption engine 1660 then decrypts the response and sends the response decrypted at 1616 to the client device 611.

  FIG. 17 illustrates key exchange and key stream generation that can be initially performed between the IoT service 120 and the IoT device 101. In one embodiment, this key exchange can be performed each time the IoT service 120 and the IoT device 101 establish a new communication session. Alternatively, a key exchange can be performed and the exchanged session key can be used for a specified period of time (eg, a day, a week, etc.). Although the intermediate device is not shown in FIG. 17 for the sake of brevity, communication can occur through 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®) to generate a session public / private key pair. ). The HSM 1630 can then prevent access to this pair of session secret keys. Similarly, the encryption engine on the IoT device 101 generates a session public / private key pair to prevent access to the pair's session secret key (eg, Atmel Corporation® Attec 508 HSM, etc.). Command). Of course, the basic principles of the present invention are not limited to any particular type of encryption engine or manufacturer.

In one embodiment, the IoT service 120 sends 1701 its session public key generated using the HSM 1630 to the IoT device 101. 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 engines 1660-1661 use the Elliptic curve Diffie-Hellman (ECDH) protocol, which is used by two parties with an elliptic curve public-private key pair. An anonymous key arrangement 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 secret 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 secret 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 secret key, where ( ^* ) is , It means that the IoT device session public key is dot-multiplied by the IoT service session secret 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 secret key, and the IoT service session public key is dot-multiplied by the IoT device session secret key. The Eventually, both the IoT service 120 and the IoT device 101 generated the same secret that is used to encrypt the communication as described below. In one embodiment, the encryption engines 1660-1661 rely on hardware modules such as KSGMs, 1640-1641, respectively, that perform the above operations to generate secrets.

  Once the secret is determined, the secret can be used by the encryption engines 1660 and 1661 to directly encrypt and decrypt the data. Alternatively, in one embodiment, the encryption engine 1660-1661 sends a command to the KSGM 1640-1641 to generate a new keystream using a secret to encrypt / decrypt each data packet. (Ie, a new keystream data structure is generated for each packet). Specifically, one embodiment of the keystream generation module 1640-1641 may be used with a Galois / counter mode in which a counter value is incremented for each data packet and used in combination with a secret to generate a keystream. Implement (Galois / Counter Mode) (GCM). Thus, to send the 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-1641 to generate a new key stream and Increase the counter value to generate the stream. The newly generated key stream is then used to encrypt the data packet and then sent to the IoT service 120. In one embodiment, the key stream is XORed with the 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 value and secret to generate a key stream (the same key stream because the same secret and counter value are used). And decrypt the data packet using the generated keystream.

  In one embodiment, data packets transmitted from the IoT service 120 to the IoT device 101 are encrypted in the same manner. Specifically, a counter is incremented for each data packet and used with the secret to generate a new key stream. The key stream is then used to encrypt the data (eg, performing an XOR of the data and key stream), and the encrypted data packet is sent to the IoT device 101 along 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 secret to generate the same key stream that is used to decrypt the data packet. Thus, in this embodiment, the encryption engines 1660-1661 use their own counter values to generate a key stream that encrypts the 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 keeps track of the last counter value it received from the other and whether the counter value was received out of sequence or received the same counter value more than once. Including sequencing logic to detect whether or not If a 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 engines 1660-1661 can disconnect from the communication channel and / or generate security alerts.

  FIG. 18 illustrates an exemplary encrypted data packet used in one embodiment of the present invention that includes 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 described above, in one embodiment, session public / private key pairs 1650-1651 exchanged between IoT service 120 and IoT device 101 are periodically and / or at the start of each new communication session. Can be generated in response.

  One embodiment of the present invention implements additional techniques for authenticating a 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, an organization implementing an IoT system as described herein). Maintained below). The master private key can be used to generate (and thereby authenticate) a signature on various other key pairs, such as a factory key pair. The signature can then be verified using the master public key. In one embodiment, each factory that manufactures an IoT device 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, a factory private 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. The session public / private key described above is temporary (ie, generated for a service / device session), while the IoT service / device key pair is permanent (ie, generated at the factory). )

With the above relationship 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. Then, the following operation is performed.
A. In one embodiment, the IoT service 120 initially generates a message that includes:
1. IoT service unique ID:
-IoT service serial number,
·Time stamp,
The ID of the factory key used to sign this unique ID,
A class of unique IDs (ie services),
・ Public key of IoT service,
A signature on a unique ID.
2. Factory certificate including:
·Time stamp,
The ID of the parent key used to sign the certificate,
・ Factory public key,
・ Signing of factory certificate.
3. IoT service session public key (as described above with respect to FIGS. 16A-B)
4). IoT service session public key signature (eg, signed with the IoT service private key).
B. In one embodiment, the message is sent to the IoT device over a negotiation channel (described below). The IoT device parses the message:
1. Verify factory certificate signature (only if present in message payload).
2. The key identified by the unique ID is used to verify the unique ID signature.
3. The IoT service public key signature from the unique ID is used to verify the IoT service session public key signature.
4). The public key of the IoT service and the session public key of the IoT service are stored.
5. Generate an IoT device session key pair.
C. The IoT device then generates a message that includes the following:
1. A unique ID of the IoT device,
・ The serial number of the IoT device,
·Time stamp,
The ID of the factory key used to sign this unique ID,
A class of unique IDs (ie IoT devices),
The public key of the IoT device,
A unique ID signature.
2. The session public key of the IoT device.
3. Signature of (IoT device session public key + IoT service session public key) signed with the key of the IoT device.
D. This message is sent back to the IoT service. The IoT service parses the message:
1. Verify the unique ID signature using the factory public key.
2. The signature of the session public key is verified using the public key of the IoT device.
3. Store the session public key of the IoT device.
E. The IoT service then generates a message that includes a signature (IoT device session public key + IoT service session public key) signed with the IoT service key.
F. The IoT device parses the message:
1. The session public key signature is verified using the public key of the IoT service.
2. A key stream is generated 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. A key stream is generated from the IoT service session secret key and the session public key of the IoT device.
2. Create a new message on the messaging channel, including:
Generate and store a random 2-byte value.
Set a boomerang attribute Id (described below) and an attribute message with a random value.
H. The IoT device receives the message:
1. Attempts to decrypt 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 includes a boomerang attribute update:
1. Set the pairing state to true.
2. Send a pairing complete message on the negotiation channel.
J. et al. The IoT device receives the message and sets the pairing state of the IoT device to true.

  Although the above techniques have been described with respect to “IoT services” and “IoT devices”, the basic principles of the present invention are to establish a secure communication channel between any two devices, including user client devices, servers, and Internet services. Can be implemented to establish.

The technique described above is highly secure because the secret key is not shared over the air (in contrast to current Bluetooth® pairing techniques where secrets are transmitted from one party to the other). An attacker listening to the entire conversation will only have a 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 GCM and separate counters are used on each device, any kind of “replay attack” (man-in-the-middle captures data and retransmits it) 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 specifies how two Bluetooth® Low Energy (BTLE) devices transmit data back and forth. It utilizes a general data protocol called Attribute Protocol (ATT), which is a simple look-up table that uses a 16-bit property ID for each input to the table, service, property , And related data. On the other hand, it should be noted that “characteristic” is sometimes called “attribute”.

  The most commonly used property on Bluetooth® devices is the device's “name” (having property ID 10752 (0x2A00)). For example, a Bluetooth® device can read other “name” characteristics issued by these other Bluetooth® devices using GATT to other Bluetooth® devices in its vicinity. Can be identified. Therefore, Bluetooth® devices have the unique ability to exchange data without formally pairing / binding devices (“pairing” and “binding” are sometimes used interchangeably) (The rest of this discussion will use the term “pairing”).

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

  FIG. 19 shows a specific implementation in which a 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 form is illustrated. 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 property IDs, names associated with those property IDs, and a list of values for those property IDs. The value 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 principle of the present invention is not limited to any particular buffer size.

  In the example of FIG. 19, the “name” characteristic is a characteristic defined by a BT assigned a specific value of “IoT device 14”. One embodiment of the present invention provides a first set of additional characteristics used to negotiate a secure communication channel with the BT device 1910 and additional used for encrypted communication with the BT device 1910. Specifies a second set of characteristics. Specifically, the “negotiation write” property identified by property ID <65532> in the illustrated embodiment can be used to send an outgoing negotiation message and is identified by property ID <65533>. The “negotiation read” property can be used to receive an incoming negotiation message. A “negotiation message” may include a message used by the BT device 1910 and the BT communication module 1901 to establish a secure communication channel as described herein. As an example, in FIG. 17, the IoT device 101 may receive the IoT service session public key 1701 via the “negotiate read” property <65533>. Key 1701 can be sent from IoT service 120 to BTLE enabled IoT hub 110 or client device 611, which then uses GATT to negotiate reading buffer identified by property ID <65533>. 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 (eg, using it to Generate and use a secret to generate a keystream, etc.).

  If the key 1701 is larger than 20 bytes (the maximum buffer size in some current implementations), the key can be written into the 20 byte portion. For example, the first 20 bytes can be written to property ID <65533> by the BT communication module 1903 and read by the IoT device application logic 1902, which then sends an acknowledgment message to the property ID < Can be written to the negotiated write value buffer identified by 65532>. Using GATT, the BT communication module 1903 can read this acknowledgment from the property ID <65532>, and in response, the next 20 bytes of the key 1701 are negotiated read identified by the property ID <65533>. Can be written to the value buffer. In this way, the network socket abstraction defined by the characteristic IDs <65532> and <65533> is established to exchange negotiation messages used to establish a secure communication channel.

  In one embodiment, once a secure communication channel is established, a characteristic ID <65534> (for sending encrypted data packets from the IoT device 101) and a characteristic ID <65533> (encrypted data packets by the IoT device For receiving) a second network socket abstraction is established. That is, when the BT communication module 1903 has an encrypted data packet to be transmitted (for example, the encrypted message 1603 in FIG. 16A), the BT communication module 1903 stores the message reading value buffer identified by the characteristic ID <65533>. Use to start writing encrypted data packets 20 bytes at a time. The IoT device application logic 1902 then reads the encrypted data packet 20 bytes at a time from the reading value buffer and sends an acknowledgment message via the writing value buffer identified by the characteristic ID <65532> as necessary. It is 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, the BT communication module 1903 can identify a property ID <65533> and send a packet containing a SET command to write to the value field / buffer identified by the property ID <65533>, which It can be read by the IoT device application logic 1902. To obtain data from the IoT device 101, the BT communication module 1903 can send a GET command directed to the value field / buffer identified by the characteristic ID <65534>. In response to the GET command, the BT communication module 1901 can transmit an UPDATE packet including data from the value field / buffer identified by the characteristic ID <65534> to the BT communication module 1903. In addition, UPDATE packets can be automatically sent 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 the lighting, an UPDATE packet can be sent to reflect this change in the on / off attribute associated with the lighting application.

  FIG. 20 illustrates exemplary packet formats used for GET, SET, and UPDATE, according to one embodiment of the invention. In one embodiment, these packets are sent via the message write <65534> and message read <65533> channels after negotiation. In the GET packet 2001, the first one-byte field includes a value (0X10) that identifies the packet as a GET packet. The second 1-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, a different request ID 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 is 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 turned on or off. (For example, 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 including the current value identified by the attribute ID can be sent.

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

  The 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 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, the 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 lighting controlled by the IoT device, the update status field can indicate whether the lighting has been successfully turned off.

  FIG. 21 illustrates an exemplary transaction sequence 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. In 2101, the SET command 2101 is transmitted from the IoT service to the IoT device 101 and received by the BT communication module 1901. The BT communication module 1901 updates the GATT value buffer identified by the characteristic ID in 2102 accordingly. To do. The SET command is read from the value buffer at 2103 by the low power microcontroller (MCU) 200 (or by program code running on a low power MCU such as the IoT device application logic 1902 shown in FIG. 19). It is done. At 2104, the MCU 200 or program code performs an operation in response to the 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 in the IoT device, at 2105 an UPDATE command is returned, and at 2106 the actual value in the GATT value field is updated. In some cases, the actual value will be equal to the desired value. In other cases, the updated value may be different (ie, because it may take time to update a particular type of value for the IoT device 101). Finally, at 2107, an UPDATE command containing 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 described above, the session secret can be uniquely generated by the IoT device and the IoT service. At 2203, the IoT service sends the encrypted device packet to the IoT hub via the encrypted channel. At 2204, the IoT hub passes the encrypted device packet to the IoT device without decryption. At 22-5, the IoT device uses the session secret to decrypt the encrypted device packet. As described above, in one embodiment, this uses a secret and a counter value (provided with the encrypted device packet) to generate a key stream, and then uses the key stream to decrypt the packet. Can be realized. At 2206, the IoT device then extracts and processes the data and / or commands included in the device packet.

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

  23A-C illustrate a detailed method for pairing a device according to one 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 including the serial number and public key of the IoT service. 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 IoT device's serial number and 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 via an unencrypted channel.

  At 2309, the IoT hub forwards the packet to the IoT service via the encrypted channel, and at 2310, the IoT service verifies the signature of the packet. At 2311, the IoT service generates a session key pair, and at 2312, the IoT service generates a packet including the session public key. The IoT service then signs the packet with the IoT service private key at 2313, and at 2314, the IoT service sends the packet to the IoT hub over the encrypted channel.

  Turning to FIG. 23B, at 2315, the IoT hub forwards the packet to the IoT device via an 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 private 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 private key and the IoT device public key to generate a session secret. Generate (as detailed above). At 2324, the IoT device generates a session secret (and as described above) using the IoT device private key and the IoT service public key, and at 2325, the IoT device generates a random number to generate the session secret. To encrypt the random number. At 2326, the IoT service sends the encrypted packet to the IoT hub via the encrypted channel. At 2327, the IoT hub forwards the encrypted packet to the IoT device via the unencrypted channel. At 2328, the IoT device decrypts the packet using the session secret.

Turning 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 an unencrypted channel. At 2331, the IoT hub forwards the encrypted packet to the IoT service via the encrypted channel. At 2332, the IoT service uses the session secret to decrypt the packet. At 2333, the IoT service verifies that the random number matches the random number transmitted by the IoT service. The IoT service then sends a packet indicating that pairing is complete at 2334, and at 2335 all subsequent messages are encrypted using the session secret.
Apparatus and method for identifying data transfer status by modifying packet interval timing

  A Bluetooth (registered trademark) Low Energy (BTLE) device transmits an advertising packet divided by an “advertising interval” to establish a connection between the devices. The BTLE peripheral device sends the advertising packet to all surrounding devices using the advertising interval. The receiving BTLE device can then act on this information or connect to receive further information.

  BTLE's 2.4 GHz spectrum extends from 2402 MHz to 2480 MHz and uses 401 MHz wide channels numbered 0-39. Each channel is divided at 2 MHz. Channels 37, 38, and 39 are only used to transmit advertisement packets. The rest is used for data exchange during connection. During BTLE advertisement, the BTLE peripheral device transmits packets in sequence on the three advertising channels. A central device that scans for devices or beacons waits for advertising packets to listen to those channels and helps discover nearby devices. Channels 37, 38, and 39 are intentionally spread across the 2.4 GHz spectrum (ie, channels 37 and 39 are the first and last channels in the band, and channel 38 is intermediate). If any single advertising channel is blocked, the other channels are likely to be free because they are divided by a bandwidth of several MHz.

  When an IoT device has data to send, the IoT device typically includes a flag as part of its advertisement packet to indicate that it is ready to send data. In one embodiment of the invention, rather than using this flag, the IoT device adjusts the advertising interval to indicate that it has pending data. For example, if T is the time between advertisement packets and there is no pending data, a different advertising interval such as 0.75T, 0.5T, or 1.25T will indicate that the data is pending. Can be selected. In one embodiment, the two different intervals are programmable based on the specific requirements of the application, making it difficult to determine which interval indicates which state.

  FIG. 24 illustrates one embodiment of the IoT device 101, in which the BTLE communication interface 2410 includes advertising interval selection logic 2411 that adjusts the advertising interval when data is ready to be transmitted. In addition, the BTLE communication interface 2420 of the IoT hub 110 includes advertising interval detection logic 2421 to detect changes in the advertising interval, provide confirmation responses, 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, the advertising interval selection logic 2411 modifies the advertising interval to notify the IoT hub 110 that data is to be transmitted (eg, changing the interval to .75T, or some other value, etc.). To do. When the advertising interval detection logic 2421 detects a change, the BTLE communication interface 2420 connects to the BTLE communication interface 2410 of the IoT device 101 to indicate that it is ready to receive data. The BTLE communication interface 2410 of the IoT device 101 then transmits data to the BTLE communication interface 2420 of the IoT hub. The IoT hub may then pass data through itself to the IoT service 120 and / or to the user's client device (not shown). After the data is transmitted, the 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 a key exchange with the IoT device 101 as described above to encrypt all communications between the IoT device 101 and the IoT service 120.

  A method according to one embodiment of the 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 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 send 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.

  It should be noted that although the advertising interval technique is described herein in connection with the BTLE protocol, the basic principles of the present invention are not limited to BTLE. Indeed, the basic principles of the present invention may be implemented in any system that selects an advertising interval 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 running within various other networking devices, such as iPhones® and Android® devices. In fact, the IoT hub described above can communicate with an IoT device (eg, using BTLE or another local radio protocol), and (eg, to an IoT service using a WiFi or cellular data connection). It may be implemented on any device that can establish a connection over the Internet.
System and method for reducing wireless traffic when connecting an IoT hub to an IoT device

  When multiple IoT hubs are configured at a particular location, a single IoT device may have the ability to connect with each IoT hub in range. As described above, an IoT device can use any advertising channel to make any connection within a range that is “connectable” so that the IoT hub can connect to the IoT device and send commands and / or data. The IoT hub can be notified. When multiple IoT hubs are within range of an IoT device, the IoT service wastes radio bandwidth by attempting to send commands / data destined for the IoT device via each of these IoT hubs and May reduce performance (eg, due to interference due to multiple transmissions).

  To address this issue, one embodiment of the present invention informs other IoT hubs to cease attempts to send commands / data once a particular IoT hub is successfully connected to an IoT device. Implement technology to ensure that This embodiment will be described with respect to FIGS. 26A-26C showing an exemplary set of IoT hubs 110-112, all of which are within range of the IoT device 101. FIG. As a result, the secure wireless communication module 2610 of the IoT device 101 can find and connect to each secure wireless communication module 2650-2652 of the IoT hub 110-112. In one embodiment, the secure wireless communication module includes the secure BTLE module described above. However, the basic principles of the present invention are not limited to any particular wireless standard.

  As illustrated in FIG. 26A, in one embodiment, the secure wireless communication module 2610 of the IoT device 101 is periodically “connectable” to neighboring wireless communication devices (ie, any device within range). An advertising control logic 2610 that transmits an advertising beacon indicating that the Any IoT hub 110-112 that receives the advertising beacon then recognizes the IoT device 101 and once the command / data is addressed to the IoT device 101 by the IoT service, the secure wireless communication module 2650-2652 101 secure wireless communication modules 2610 may be connected.

  As illustrated in FIG. 26B, in one embodiment, when the IoT service has data / commands for the IoT device 101, the data / commands may be sent to all IoT hubs 110-112 in a particular location (eg, All IoT hubs associated with the user's account and / or within the scope of the IoT device 101). As illustrated, each of the IoT hubs 110-112 may then attempt to connect with the IoT device 101 to provide commands / data.

  As illustrated in FIG. 26C, in one embodiment, only a single IoT hub 111 successfully connects to the IoT device 101 and provides commands / data for processing by the IoT device 101. Once connected using a specific wireless communication protocol such as BTLE, the secure wireless communication module 2610 ceases sending advertising beacons. Thus, the other IoT hubs 110, 112 have no way of knowing that the IoT device 101 has successfully received data from the IoT hub 111 and continue to try to send commands / data, thereby consuming radio bandwidth, Cause interference.

  To address this limitation, one embodiment of the secure wireless communication module 2610 continues to send advertising beacons to the advertising control module 2612 when it detects a normal connection with the secure wireless communication module 2651 of the IoT hub 111. The connection manager 2611 is included. However, instead of indicating that the IoT device 101 is “connectable”, the new advertising beacon indicates that the IoT device 101 is “not connectable”. In one embodiment, in response to the “not connectable” indication, the secure wireless communication module 2650, 2652 of the IoT hub 110, 112 suspends the attempt to send command / data to the IoT device, thereby Reduce unnecessary wireless traffic.

  The techniques described above provide a sophisticated solution for unwanted radio traffic using techniques that can be easily implemented over existing radio protocols. For example, in one embodiment, “connectable” and “not connectable” indications are implemented within the context of the BTLE standard. However, as mentioned above, the basic principles of the present invention can be implemented using a wide variety of different wireless network protocols.

  A method according to 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 2701, commands and / or data are transmitted from an IoT service through two or more IoT hubs. For example, the user may be trying to control the IoT device via an app on the user's mobile device connected to the IoT service. At 2702, the IoT hub attempts to connect to the IoT device, one of the IoT hubs has successfully connected, and provides commands / data to the IoT device. As described above, the IoT hub may recognize the IoT device as a result of the IoT device sending a “connectable” indication in the advertising beacon.

At 2703, in response to a successful connection, the IoT device begins sending an “not connectable” advertising beacon, thereby notifying any IoT hub in range that the IoT device is no longer connectable. At 2704, upon receiving the “not connectable” beacon, the other IoT hub aborts the attempt to send the command / data to the IoT device.
System and method for secure Internet of Things (IoT) device provisioning

  As described above, in one embodiment, when a device advertises to an IoT hub, it uses an 8-byte “device ID” that is used by the hub and IoT services to individually identify the IoT device. The device ID may be included in a unique barcode or QR code printed on the IoT device that is read and sent to the IoT service to provision / register the IoT device with the system. Once provisioned / registered, the device ID is used to specify the address of the IoT device in the system.

  One security concern for this implementation is that the barcode / QR code data can be transmitted without encryption, allowing the device ID to be intercepted and penetrated into the system. To allow another user to associate his / her account with a device ID.

  In one embodiment, to address this concern, an “association ID” is associated with each device ID and used during the provisioning process to ensure that the device ID is never sent in clear text. As illustrated in FIG. 28, in this embodiment, the association ID 2812 is included in the barcode / QR code (registered trademark) printed on the IoT device 101, but the device ID 2811 is based on the technique described above. It is securely maintained in a secure wireless communication module 2810 that is implemented to ensure secure communication with the IoT service 120. In one embodiment, the association ID 2812 is an 8-byte ID, similar to the device ID, and is unique for each IoT device. When a new IoT device 101 is provisioned in the system, the user scans a barcode / QR code (registered trademark) that includes an association ID 2812 using the user device 135 that has an installed IoT app or application. Alternatively or additionally, the IoT hub 110 may be used to capture a barcode / QR code including an association ID.

  In any case, the association ID is sent to the device provisioning module 2850 that performs a lookup on the device database 2851 that includes an association between each association ID and each device ID on the IoT service 120. The device provisioning module 2850 uses the association ID 2812 to identify the device ID 2811, and then uses the device ID to provision a new IoT device 101 in the system. In particular, once the device ID is determined from the device database 2851, the device provisioning module 2850 sends a command to the IoT hub 110 (which may include the user device 135), and the IoT hub 110 uses the device ID 2811 to send the command. Allow communication with the device 101.

  In one embodiment, the association ID 2812 is generated at the factory when the IoT device 101 is manufactured (ie, when the secure wireless communication module 2810 is provisioned). Both the device ID 2811 and the association ID 2812 can then be provided to the IoT service and stored in the device database 2851. As illustrated, the device database 2851 may include instructions identifying whether each device has been provisioned. By way of example, this is a binary value with a first value (eg, 1) indicating that the IoT device 101 is provisioned and a second value (eg, 0) indicating that the IoT device is not provisioned. It may be. Once the system provisions / registers the IoT device 101, the communication between the IoT service 120 and the IoT device 101 is protected using the security technology described above, so the device ID can be used.

  In one embodiment, when a user sells an IoT device, the user can release the device ID by logging into the IoT service 120 and releasing the IoT device from the user's account. The new user can then provision the IoT device and associate the IoT device with his / her account using the device provisioning techniques described herein.

  A method according to an embodiment of the 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 2901, an association is generated between the device ID of the IoT device and the association ID (eg, at the factory where the IoT device is manufactured). The association ID can be incorporated into a barcode / QR code that is marked on the IoT device. At 2902, the association between the device ID and the association ID is stored in the IoT service. At 2903, the user purchases a new IoT device and receives a barcode / QR code (R) containing the association ID (e.g., via the user's mobile device on which the app or application is installed, or Scan (via IoT hub with code reader).

At 2904, the association ID is sent to the IoT service, and at 2905, the association ID is used to identify the device ID. At 2906, the IoT device is provisioned using the device ID. For example, the IoT device database may be updated to indicate that this particular device ID has been provisioned so that the IoT service communicates the device ID to the IoT hub and communicates with the new IoT device to the IoT hub. Can be directed to.
System and method for performing flow control in an Internet of Things (IoT) system

  Local wireless network traffic will increase based on the number of IoT devices in a given location. Further, in some cases, the IoT device may be sending more data than a reasonable predetermined function being performed by the IoT device. For example, software / hardware on the IoT device can malfunction or the IoT device can be intruded, causing the IoT device to continuously send unnecessary data for IoT services.

  One embodiment of the present invention addresses these issues by performing flow control at the IoT hub that effectively ignores data traffic when a particular IoT device reaches a specified data threshold. In one embodiment, each IoT device is configured with a specified set of flow control parameters that indicate the amount of data that the IoT device is allowed to transmit over a period of time. The flow control parameter may be based on the type of IoT device. For example, certain IoT devices such as door locks and thermostats should typically send only a short packet of data periodically, whereas other IoT devices such as video cameras are potentially A much larger amount of data may be transmitted in a non-periodic manner. Thus, the flow control parameters may be set to provide a sufficient amount of bandwidth based on the expected operation of the IoT device in question. In one embodiment, each IoT device is assigned to a particular flow control “class” based on the data requirements of that IoT device.

  When such an embodiment is illustrated in FIG. 30, the figure shows a plurality of IoT devices 101 having secure wireless communication modules 2810, 3030, 3040, each configured with a different set of flow control parameters 3015, 3031, 3041. -103. In one embodiment, the flow control parameter specifies the frequency and / or the amount of data each IoT device is expected to transmit over a specified period of time (eg, 25 Mbyte / hour, 50 Mbyte / hour, 100 Mbyte). / Day, 10 communication attempts / day, etc.). In one embodiment, the flow control parameters 3015, 3031, 3041 are specified by an IoT service 120 that includes a device management module 3021 that manages a set of flow control parameters 3020 for each device in the IoT device database 2851, as illustrated. obtain. For example, once the data transmission requirements for each IoT device are determined, the per-flow control parameters 3020 can be updated to reflect these requirements.

  As described above, in one embodiment, the device database 2851 includes data transmission requirements for multiple different flow control “classes” (eg, audiovisual devices, temperature devices, control devices, security devices, etc.). When a new IoT device is introduced into the system, it is then associated with a specific flow control class based on IoT device requirements and / or IoT device type.

  The per-device flow control parameters 3020 may be distributed to the IoT hub 110 that includes flow control management logic 2811 that stores a copy of the per-device flow control parameters 3010 in a local database. In one embodiment, the flow control management 2811 may monitor the amount of data traffic received from and / or transmitted to the respective IoT devices 101-103. If the amount of data traffic reaches the specified threshold (as indicated by the per-device flow control parameter 3010), then the IoT hub 110 may instruct the IoT device to suspend transmission for a period of time. Well, and / or traffic from IoT devices may simply be blocked.

  If a particular IoT device is transmitting / receiving at a level above a specified threshold, this may indicate that the IoT device is malfunctioning. Thus, in one embodiment, the IoT service 120 may send a command to reset the IoT device. If the device is still communicating at a level above the threshold, the IoT service 120 may then send a software update, such as a patch, to the IoT device. Once the updated software is installed, the IoT device is reset and initialized with the new software. In addition, a notification may be sent from the IoT service to the user device to inform the user that the IoT device is malfunctioning.

  In one embodiment, the IoT hub 110 may allow certain types of data traffic despite the fact that the data communication threshold has been reached. For example, in one embodiment, the IoT hub 110 will allow certain types of “high priority” notifications even if the IoT device reaches a threshold. By way of example, if the IoT device is a door lock or door entry detector, then under certain conditions (eg, when the house is being monitored), the IoT hub 110 may be the door where the IoT device is being used. Can pass data indicating that someone opened it. Similarly, if the IoT device is a heat and / or smoke detector, then the IoT hub 110 may pass data indicating an alarm condition (eg, because the temperature has reached a threshold). Various other types of “high priority” notifications (eg, indicating a potentially dangerous condition) may be passed by the IoT hub 110 regardless of the current flow control status. In one embodiment, these “high priority” notifications are identified using different attributes described below.

  A method according to 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 3101 flow control parameters are specified for each IoT device. In one embodiment, an IoT device may also be assigned to a particular IoT device “class” having a specified set of flow control parameters associated therewith. At 3102, flow control parameters are stored in an IoT hub within the IoT system. In one embodiment, each hub may store a subset of all IoT device parameters (eg, only parameters for locally provisioned IoT devices).

If the IoT hub detects that a particular IoT device is operating outside of the specified flow control parameters determined at 3103, then at 3104, the IoT hub further communicates with the IoT device. The communication will be temporarily stopped (for example, the communication between the IoT device and the IoT service is blocked). In addition, as described above, the IoT service and / or IoT hub may take measures to remedy the problem by restarting the IoT device and / or installing software updates on the IoT device.
System and method for managing Internet of Things (IoT) devices and traffic using attribute classes

  Different IoT devices can be used to perform different functions at a given location. For example, a specific IoT device may be used to collect data such as temperature and status (eg, on / off status) and report this data back to the IoT service, where the data is accessed by the end user Can be used, or can be used to generate various types of alert conditions. To enable this implementation, one embodiment of the present invention manages data collected using different attribute class types, system data, and other forms of data.

  FIG. 32 illustrates one embodiment of an IoT device that includes a secure wireless communication module 3218 that communicates with a microcontroller unit (MCU) 3215 via a serial interface 3216 such as a serial peripheral interface (SPI) bus. The secure wireless communication module 3218 manages secure communication with the IoT service 120 using the techniques described above, and the MCU 3215 executes program code for implementing the application specific functions of the IoT device 101.

  In one embodiment, a variety of different attribute classes are used to manage data collected by the IoT device and system configuration for the IoT device. Specifically, in the example illustrated in FIG. 32, the attributes include an application attribute 3210, a system attribute 3211, and a priority notification attribute 3212. In one embodiment, application attributes 3210 include attributes related to application specific functions performed by IoT device 101. For example, if the IoT device includes a security sensor, then the application attribute 3210 may include a binary value that indicates whether a door or window has been opened. If the IoT device includes a temperature sensor, then the application attribute 3210 may include a value indicating the current temperature. A virtually unlimited number of other application specific attributes can be defined. In one embodiment, MCU 3215 only executes application specific program code and has access to application specific attributes 3210. For example, an application developer may purchase the IoT device 101 with a secure wireless communication module 3218 and design application program code that is executed by the MCU 3215. As a result, application developers need to have access to application attributes, but do not need to have access to other attribute types described below.

  In one embodiment, system attributes 3211 are used to define operational and configuration attributes for IoT device 101 and IoT system. For example, system attributes include network configuration settings (such as the flow control parameters described above), device ID, software version, advertising interval selection, security implementation functions (as described above), and IoT device 101 as an IoT service. It may include various other low level variables that are necessary to enable communication.

  In one embodiment, the set of priority notification attributes 3212 is defined based on the level of importance or severity associated with those attributes. For example, if a particular attribute is associated with a dangerous condition such as a temperature value that reaches a threshold (e.g., when the user accidentally leaves the stove on, or the user's home thermal sensor triggers This attribute can then be assigned to the priority notification attribute class. As described above, the priority notification attribute can be handled differently from other attributes. For example, when a particular priority notification attribute reaches a threshold, the IoT hub may pass the value of the attribute to the IoT service, regardless of the current flow control mechanism implemented by the IoT hub. In one embodiment, the priority notification attribute also triggers the IoT service to notify the user and / or an alarm condition in the user's home or business (eg, warn a potentially dangerous user). Can be generated.

  As illustrated in FIG. 32, in one embodiment, the current state of application attributes 3210, system attributes 3211, and priority notification attributes 3212 are duplicated / mirrored in the device database 2851 on the IoT service 120. For example, when a change in one of the attributes of the IoT device 101 is updated, the secure wireless communication module 3218 communicates the change to the device management logic 3021 on the IoT service 120 and the device management logic reacts immediately. Then, the value of the attribute in the device database 2851 is updated. In addition, when the user updates one of the attributes of the IoT service (e.g., adjusting conditions such as the current state or desired temperature), the attribute change is transmitted from the device management logic 3021 to the secure wireless communication module 3218. Device management logic then updates the local copy of the attribute. In this way, attributes are maintained in a consistent manner between the IoT device 101 and the IoT service 120. The attributes may also be accessed from the IoT service 120 via a user device having an installed IoT app or application and / or by one or more external services 3270. As described above, the IoT service 120 may expose an application programming interface (API) to provide access to a variety of different attribute classes.

  In addition, in one embodiment, the priority notification processing logic 3022 may perform a rule-based operation in response to receiving a notification regarding the priority notification attribute 3212. For example, if the priority notification attribute indicates a dangerous condition (eg, an iron or stove left by the user), then the priority notification processing logic 3022 implements a set of rules that attempt to turn off the dangerous device. (Eg, send an “off” command to the device if possible). In one embodiment, priority notification processing logic 3022 may utilize other relevant data, such as the current user's location, to determine whether to turn off the dangerous device (eg, dangerous device). Is detected when the user is away from home when in the “on” state). In addition, the priority notification processing logic 3022 may send an alert state to the user's client device to notify the user of the state. Various other rule set types may be implemented by the priority notification processing logic 3022 to attempt to deal with potentially dangerous or undesirable conditions.

  FIG. 32 also shows a set of BTLE attributes 3205 and attribute address decoders 3207. In one embodiment, the BTLE attribute 3205 may be used to establish read and write ports as described above with respect to FIGS. The attribute address decoder 3207 reads the unique ID code associated with each attribute to determine which attribute is being received / transmitted and processes the attribute accordingly (eg, wireless communication with secure attributes). Identify the location stored in module 3218).

  Embodiments of the present invention may include the various steps described above. The process can be embodied in machine-executable instructions that can 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 hard-wired logic for performing the steps, or by any combination of programmed computer components and custom hardware components. Can do.

  As described herein, instructions are configured to perform certain specific operations, or certain functions or software instructions are stored in a memory embodied in a non-transitory computer readable medium. May refer to a specific configuration of hardware, such as an application specific integrated circuit (ASIC). 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 ( For example, computer and machine readable storage media such as carrier waves, infrared signals, digital signals, etc., electrical, optical, acoustic or other forms of propagation signals) are used to store and (internally and / or data). (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 a network connection. The connection between the processor set and other components is typically made through one or more buses and bridges (also called bus controllers). Each of the signals carrying the storage device and network traffic represents one or more machine-readable storage media and machine-readable communication media. 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 that electronic device. Of course, one or more portions of embodiments of the present invention may be implemented using different combinations of software, firmware, and / or hardware.

  Throughout this 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 those skilled in the art that the present invention may be practiced without some of these specific details. In certain instances, well-known structures and functions have not been described in detail in order to avoid obscuring the subject matter of the present invention. Accordingly, the scope and spirit of the present invention should be determined from the following claims.

Claims (40)

A method,
Generating an association between a new Internet of Things (IoT) device identification (ID) code and an association ID code;
Storing the association in an IoT device database of an IoT service;
Reading the association ID code from the new IoT device;
Sending the association ID code to the IoT service, wherein the IoT service performs a lookup in the IoT device database using the association ID code to determine the device ID code; And
Provisioning the new IoT device to communicate with the IoT service using the device ID code;
Including a method.   The provisioning of the IoT device comprises transmitting the device ID from the IoT service to at least one IoT hub, instructing the IoT hub to allow communication with the IoT device. The method according to 1.   The method of claim 2, wherein the new IoT device establishes a secure communication channel with the IoT service using the device ID code.   The method of claim 1, wherein the association ID is embodied in a QR code or barcode on the new IoT device.   The method of claim 4, wherein reading the association ID comprises reading the QR code or barcode on the new IoT device.   6. The method of claim 5, wherein the reading operation of the QR code or barcode is performed using an app or application on a client device and / or using an IoT hub.   The method of claim 1, wherein the IoT service updates the IoT device database to indicate that the new IoT device has been provisioned. Establishing the secure communication channel between the new IoT device and the IoT service;
Establishing communication between the IoT service and the new IoT device through an IoT hub or mobile user device;
Generating a service public key and a service secret key by a key generation logic of a first encryption engine on the IoT service;
Generating a device public key and a device private 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 secret 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 3 comprising: An Internet of Things (IoT) system,
A new IoT device storing the association between the device identification (ID) code and the association ID code;
An IoT device database of the IoT service storing the association;
A client device and / or an IoT hub that reads the association ID code from the new IoT device;
The client device and / or IoT hub sending the association ID code to the IoT service;
The IoT service to perform a lookup in the IoT device database using the association ID code to determine the device ID code;
The IoT service provisioning the new IoT device to allow the new IoT device to communicate with the IoT service using the device ID code;
Including system.   The provisioning of the IoT device comprises transmitting the device ID from the IoT service to at least one IoT hub, instructing the IoT hub to allow communication with the IoT device. 10. The system according to 9.   The system of claim 10, wherein the new IoT device uses the device ID code to establish a secure communication channel with the IoT service.   The system of claim 9, wherein the association ID is embodied in a QR code or barcode on the new IoT device.   The system of claim 12, wherein reading the association ID includes reading the QR code or barcode on the new IoT device.   14. The system of claim 13, wherein the reading operation of the QR code or barcode is performed using an app or application on a client device and / or using an IoT hub.   The system of claim 9, wherein the IoT service updates the IoT device database to indicate that the new IoT device has been provisioned. Establishing the secure communication channel between the new IoT device and the IoT service;
Establishing communication between the IoT service and the new IoT device through an IoT hub or mobile user device;
Generating a service public key and a service secret key by a key generation logic of a first encryption engine on the IoT service;
Generating a device public key and a device private 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 secret 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 system of claim 3 comprising: A machine readable medium having program code stored thereon, wherein when the program code is executed by one or more machines,
Generating an association between a new Internet of Things (IoT) device identification (ID) code and an association ID code;
Storing the association in an IoT device database of an IoT service;
Reading the association ID code from the new IoT device;
Sending the association ID code to the IoT service, wherein the IoT service performs a lookup in the IoT device database using the association ID code to determine the device ID code. When,
A machine-readable medium that causes the operations of provisioning the new IoT device to communicate with the IoT service using the device ID code.   The provisioning of the IoT device comprises transmitting the device ID from the IoT service to at least one IoT hub, instructing the IoT hub to allow communication with the IoT device. The machine-readable medium according to claim 17.   19. The machine readable medium of claim 18, wherein the new IoT device establishes a secure communication channel with the IoT service using the device ID code.   The machine-readable medium of claim 17, wherein the association ID is embodied in a QR code or barcode on the new IoT device.   21. The machine readable medium of claim 20, wherein reading the association ID includes reading the QR code or barcode on the new IoT device.   The machine-readable medium of claim 21, wherein the reading operation of the QR code or barcode is performed using an app or application on a client device and / or using an IoT hub.   The machine-readable medium of claim 17, wherein the IoT service updates the IoT device database to indicate that the new IoT device has been provisioned. A system,
Multiple IoT devices;
An IoT hub that establishes a local wireless connection with the plurality of IoT devices and communicatively couples the plurality of IoT devices to an IoT service;
Said IoT hub storing flow control parameters for each of said plurality of IoT devices, wherein said flow control parameters are determined based on respective data communication requests of said IoT devices, and each one of said IoT devices; An IoT hub showing the above data communication thresholds;
A IoT hub that monitors data communication with each of the IoT devices and determines whether one of the IoT devices has reached a data communication threshold specified by the flow control parameter; A system comprising: an IoT hub, wherein the IoT hub temporarily prevents communication between the first IoT device and the IoT service in response to a device reaching a data communication threshold.   25. The system of claim 24, wherein the flow control parameters are transmitted from the IoT service to the IoT hub.   26. The system of claim 25, wherein the flow control parameters are defined as a plurality of flow control classes and each IoT device is associated with one of the flow control classes.   27. The system of claim 26, wherein data associating each of the flow control class and the IoT device with a flow control class is stored in an IoT device database on the IoT service.   Monitoring the data communication with each of the IoT devices includes an amount of data transmitted from the respective IoT device to the IoT service over a period of time and / or each IoT device with the IoT service over a period of time. 25. The system of claim 24, comprising monitoring the number of communications.   25. The system of claim 24, wherein temporarily hindering includes ignoring or interrupting data transmission from the IoT device.   30. The system of claim 29, wherein the IoT hub prevents communication with the IoT service for a specified time and resumes communication after the specified time.   The IoT hub notifies the IoT service when it determines that the data communication threshold has been reached, and the IoT service reacts immediately and performs a software update and / or restarts the first IoT device. 25. The system of claim 24.   25. The system of claim 24, wherein the IoT hub allows certain specified types of data communication from the first IoT device despite the fact that the data communication threshold has been reached.   36. The system of claim 32, wherein the specific designated type of data communication includes data communication associated with a high priority attribute on the IoT device. A method,
Specifying each attribute of a plurality of data items managed in an Internet of Things (IoT) device and / or IoT service;
Defining multiple attribute classes,
Associating each of the attributes with one or more of the attribute classes, wherein the attribute class is such that the data item is stored and processed by a component of the IoT device and / or the IoT service. Specify
The attribute class is a plurality of notification attribute classes and a first attribute set, the first attribute set being associated with the priority notification attribute class based on the importance or severity associated with the first attribute set. Including a set of attributes,
Sending a notification from the IoT device to the IoT service regarding attributes associated with the priority notification attribute class prior to other notifications regarding attributes not associated with the priority notification attribute class;
Implementing a set of priority notification attribute rules on the IoT service when receiving the notification to attempt to deal with potentially dangerous or undesirable conditions associated with the notification; Including methods. The IoT device is
A microcontroller unit that executes application-specific program code to perform application-specific functions of the IoT device;
35. A method according to claim 34, comprising: a secure wireless communication module that establishes a secure wireless communication channel with the IoT service.   36. The method of claim 35, wherein the attribute class comprises an application attribute class that is usable by the MCU when executing the application specific program code.   37. The method of claim 36, wherein the attribute class further comprises a system attribute class for system attributes that can be used by the secure wireless communication module, the MCU, and / or the IoT service.   38. The method of claim 37, wherein the system attribute, application attribute, and priority notification attribute are synchronized between the IoT device and the IoT service.   40. The one or more of the system attribute, application attribute, and priority notification attribute are synchronized between the IoT service and a client device and / or one or more external services. Method.   Due to flow control restrictions for a particular IoT device, an IoT hub configured to block notifications not associated with the priority notification attribute class may receive notifications from the IoT device associated with the priority notification attribute class. 40. The method of claim 39, wherein the method is passed.