JP2019511141A - System and method for automatic wireless network authentication in Internet of Things (IoT) system - Google Patents

Abstract

Systems, devices, and methods are described for secure IoT wireless network configurations. For example, one embodiment of an Internet of Things (IoT) hub may be a local wireless communication interface that establishes a local wireless connection with one or more IoT devices and / or IoT extender hubs, an IoT device and / or an IoT extender hub Instead, a network router that establishes a network connection via the Internet, and an authentication module that is preconfigured using a passphrase and a hidden service set identifier (SSID), which is an IoT device and / or an IoT device. When the IoT device and / or IoT extender hub receives a connection request from the extender hub and the IoT device and / or IoT extender hub use a preconfigured pass phrase and hidden SSID, an authentication module that accepts the connection request and an Io specified by a known host name To block all incoming / outgoing request other than the connection request of the services of the server destined includes a firewall of IoT hub, the.

Description

  The present invention relates generally to the field of computer systems. More specifically, the present invention relates to systems and methods for automatic wireless network authentication in an IoT system.

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

  When a user gets a new WiFi enabled device, such as a WiFi enabled IoT device, a registration process needs to be performed between the new device and the user's home network. This process can be cumbersome if the user does not remember WiFi credentials, or if the device is outside the WiFi coverage area. Furthermore, if the device is at the coverage edge of the WiFi network, the registration process will fail because the low coverage condition will impair the registration process, which will result in the access point rejecting the registration of the new device. The problem is more complicated for users who have multiple WiFi networks at home or business. In such a situation, each network will need its own registration process.

  Finally, the user can not establish registration of a new device without being at home or inside a business hosting a private network. Hence, an original equipment manufacturer (OEM) can not send the user a device that is initially ready to connect to the user's WiFi network.

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

7 illustrates different embodiments of the IoT system architecture. 7 illustrates different embodiments of the IoT system architecture. 1 illustrates an IoT device according to an embodiment of the present invention. 1 illustrates an IoT hub according to an embodiment of the present invention. Fig. 6 illustrates an embodiment of the invention for controlling and collecting data from IoT devices and generating notifications. Fig. 6 illustrates an embodiment of the invention for controlling and collecting data from IoT devices and generating notifications. FIG. 5 illustrates an embodiment of the present invention for collecting data from IoT devices and generating notifications from IoT hubs and / or IoT services. 8 illustrates an embodiment of the invention implementing improved security techniques such as encryption and digital signatures. 1 illustrates one embodiment of an architecture in which a subscriber identity module (SIM) is used to store keys on an IoT device. 7 illustrates an embodiment in which an IoT device is registered using barcode or QR code (registered trademark). 8 illustrates one embodiment in which pairing is performed using barcodes or QR codes (registered trademark). 7 illustrates one embodiment of a method for programming a SIM using an IoT hub. 7 illustrates one embodiment of a method for registering an IoT device with an IoT hub and an IoT service. 7 illustrates one embodiment of a method for encrypting data sent to an IoT device. 1 illustrates one embodiment of an architecture for collecting and storing network credential information. 1 illustrates one embodiment of an architecture for registering a user with a wireless access point. 1 illustrates one embodiment of a method for collecting and storing network credential information. 5 illustrates one embodiment of a method for registering a new device using stored credentials. 5 illustrates different embodiments of the present invention for encrypting data between an IoT service and an IoT device. 5 illustrates different embodiments of the present invention for encrypting data between an IoT service and an IoT device. Fig. 5 illustrates an embodiment of the invention for performing secure key exchange, generating a common secret, and generating a key stream using the secret. Fig. 6 illustrates a packet structure according to an embodiment of the present invention. 8 illustrates a technique used in one embodiment to read and write data to and from an IoT device without pairing with the IoT device formally. FIG. 7 illustrates an exemplary set of command packets used in one embodiment of the present invention. 7 illustrates an exemplary sequence of transactions using command packets. 5 illustrates a method according to an embodiment of the present invention. 6 illustrates a method for secure pairing according to an embodiment of the present invention. 6 illustrates a method for secure pairing according to an embodiment of the present invention. 6 illustrates a method for secure pairing according to an embodiment of the present invention. 1 illustrates one embodiment of a system for configuring an IoT hub using WiFi security data. 1 illustrates a system architecture used in one embodiment of the present invention. 5 illustrates a method according to an embodiment of the present invention. 1 illustrates one embodiment of a master IoT hub comprising a WiFi router with authentication logic and a firewall. 5 illustrates a method according to an embodiment of the present invention.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In one embodiment, the IoT hub 110 and the IoT service 120 communicate at periodic intervals. If the IoT service 120 detects that the connection to the IoT hub 110 is broken (e.g., by not receiving a request or response from the IoT hub for a specified duration), the IoT service 120 may This information will be communicated to the end user's device 135 (eg, by sending a text message or an application specific notification).
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 the store (see, eg, FIGS. 6-11 and the associated text). Alternatively, the key may be secured in a subscriber identity module (SIM), as described below.

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

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

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

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

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

  Once symmetric keys are exchanged, they can be used by each device 101 and the IoT hub 110 to encrypt communications. Similarly, IoT hub 110 and IoT service 120 may perform secure symmetric key exchange and then encrypt communications using the exchanged symmetric key. In one embodiment, new symmetric keys are exchanged periodically between the device 101 and the hub 110 and between the hub 110 and the IoT service 120. In one embodiment, on each new communication session between device 101, hub 110 and service 120, a new symmetric key is exchanged (eg, a new key is generated for each communication session and exchanged securely) ). In one embodiment, if the security module 612 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 612 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 612 and then re-encrypted for transmission to device 101.

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

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

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

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

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

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

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

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

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

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

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

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

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

  FIG. 8B illustrates an embodiment in which the barcode reader 206 on the IoT hub 110 captures the barcode / QR code 801 associated with the IoT device 101. As mentioned above, the barcode / QR code 801 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 801 and provides the pairing code to the local communication module 880. In one embodiment, the local communication module 880 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 including pairing data 885, and the IoT device 101 and the IoT hub 110 are automatically paired. Each time an IoT hub is paired with a new IoT device in this manner, pairing data regarding the pairing is stored in the secure storage device 685. In one embodiment, when the local communication module 880 of the IoT hub 110 receives the pairing code, it may use this code as a key to encrypt communication with the IoT device 101 over the local wireless channel.

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

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

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

  At 901, the user receives a new IoT device with an empty SIM card, and at 802, the user inserts an empty SIM card into the IoT hub. At 903, the user programs an empty SIM card with one or more sets of encryption keys. For example, as described above, in one embodiment, the IoT hub randomly generates a public / private key pair, stores the private key on the SIM card, and stores the public key in its local secure storage device. obtain. In addition, at 904, 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 mentioned above, in one embodiment, programmable devices other than the "SIM" card may be used to perform the same function as the SIM card in the manner shown in FIG.

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

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

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

  At 1101, the IoT service encrypts data / commands using the IoT device public key to create an IoT device packet. The IoT service then encrypts this IoT device packet using the IoT hub's public key to create an IoT hub packet (eg, create an IoT hub wrapper around the IoT device packet). At 1102, the IoT service sends an IoT hub packet to the IoT hub. At 1103, the IoT hub decrypts the IoT hub packet using the IoT hub's secret key to generate an IoT device packet. Then, at 1104, the IoT hub sends the IoT device packet to the IoT device, and the IoT device decrypts the IoT device packet at 1105 using the IoT device secret key to generate data / commands. At 1106, the IoT device processes data / commands.

In certain embodiments that use symmetric keys, symmetric key exchange may be negotiated between each device (e.g., between each device and a hub, and between a hub and a service). When the key exchange is complete, each transmitting device encrypts and / or signs each transmission using the symmetric key and then transmits the data to the receiving device.
Embodiments for Automatic Wireless Network Authentication

  In order to connect the IoT hub to a local wireless network such as a WiFi network, the user has to provide network credentials such as a network security key or password. Other authentication layers, such as user ID / password combinations may be required. In one embodiment, when the IoT hub successfully connects to the local wireless network using the network credentials provided by the user, the IoT hub securely secures the network credentials to a secure storage location such as the IoT service 120. Send. Subsequently, when the user receives a new IoT device, this IoT device may be configured to send a network credential request to the IoT hub. In response, the IoT hub can forward this request to the IoT service 120, which, for example, identifies the IoT device, the user, and / or the access point to which a connection to it is required. Can be used to look up in the credential database to identify relevant network credentials. If network credentials can be identified, the network credentials are sent back to the IoT device, which then seamlessly connects to the local wireless network using the network credentials.

  FIG. 12 illustrates an exemplary system architecture in which the credential information management module 1210 on the IoT hub 1202 implements the credential information processing technology described herein. As illustrated, the user has network credentials such as a network security key or password via user device 135 (which may be a mobile smart phone device, wearable data processing device, laptop computer, or desktop computer). Can be provided to the IoT hub 1202. The user device 135 initially connects to the IoT hub 1202 through a wired connection or a near field wireless connection such as BTLE, and the user provides credentials via an application or browser configured to connect with the IoT hub 1202 .

  In one embodiment, the network credentials include a security key such as Wi-Fi Protected Access (WPA) or Wi-Fi Protected Access II (WPA 2). In this embodiment, the network credentials may be in the form of a pre-shared key (PSK) for WPA personal implementation, or WPA enterprise (which may be a RADIUS authentication server and various forms of Extensible Authentication Protocol (EAP) May rely on more advanced authentication technologies such as those used by

  Regardless of the specific authentication / encryption technology used, when the user provides the necessary network credentials, the IoT hub 1202 uses that credentials to provide a secure wireless connection to the WiFi access point / router 1200. Once established, the WiFi access point / router 1200 provides a connection to the cloud service 1220 across the Internet 1222. In one embodiment, the credential information management module 1210 on the IoT hub 1210 establishes a connection with the credential information management module 1215 on the cloud service 1220 (eg, this is the IoT service 120 or external website 130 described above). May be).

  In one embodiment, the connection between the credential management module 1210 on the IoT hub 1202 and the credential management module 1215 on the cloud service 1220 is necessarily secure using one or more of the key-based techniques described above (Eg, by encrypting all network traffic using symmetric or asymmetric keys). Once a secure connection is established, the credential management module 1210 on the IoT hub 1202 sends a copy of the network credential to the credential management module 1215 on the cloud service, and the credential management module 1215 Store the copy in secure credential database 1230. The credential information database 1230 may be data uniquely identifying the IoT hub 1202, data uniquely identifying a user account associated with the IoT hub 1202, and / or data uniquely identifying the WiFi access point / router 1200. (To ensure that network credentials are always associated with the correct user and WiFi access point / router).

  As illustrated in FIG. 13, when the user purchases a new IoT device 1300 after the network credentials are stored in the credential database 1230, the IoT device validates its local wireless interface (eg, BTLE) And search for valid devices (eg, IoT hub 1202, other IoT devices, or user's mobile devices) within the coverage. In the particular embodiment shown in FIG. 13, the IoT device 1300 detects and connects to the IoT hub 1202. In one embodiment, when the connection is established, the network registration module 1310 sends a network credential request to the credential management module 1210 on the IoT hub 1202. The credential information request is data identifying the WiFI access point / router 1200 with which the IoT device 1300 wishes to connect (eg, SSID, MAC address, or other data uniquely identifying the WiFi access point / router 1200) , As well as data uniquely identifying the IoT device 1300.

  The credential management module 1210 then securely sends a credential management request to the credential management module 1215 on the cloud service 1220, the credential management module 1215 may be a user, an IoT device 1300, and / or a WiFi access point // A lookup is performed in credential database 1230 using data that uniquely identifies router 1200. Again, any key based security technology may be used to ensure that the connection between the IoT hub and the cloud service is secure. If credential information is found based on the data provided in the request, credential management module 1215 securely sends back network credential information to credential management module 1210 on IoT hub 1202 and then credential management. Module 1210 provides the network credential to network registration module 1310 of IoT device 1300. The IoT device 1300 then automatically establishes a secure connection to the WiFi access point / router 1200 using the network credentials. As a result, the user does not have to manually configure the new IoT device 1300 to connect to the WiFi access point / router 1200. Rather, because network credentials are already associated with the user's account on the cloud service 1220, network credentials may be automatically provided to the IoT device 1300, which then seamlessly connects to the network It will be.

  As mentioned above, although FIG. 13 illustrates the IoT device 1300 connecting through the IoT hub 1202, the IoT device 1300 may connect through another IoT device if the IoT hub 1202 is not in range. Then, another IoT device (which is connected to the IoT hub) may couple the new IoT device to the credential management module 1210 on the IoT hub 1202. Similarly, if both the IoT hub and another IoT are unavailable (eg, out of range), the IoT device 1300 may be configured to connect to the mobile device 135 of the user, and the mobile device 135 may , A browser / application for connecting to the credential management module 1215 on the cloud service (either directly or through the IoT hub 1202).

  In one embodiment, the network registration module 1310 on the IoT hub 1300 is configured to search for the IoT hub 1202 first, then another IoT device, and then the user mobile device. The network registration module 1310 will then connect to the first of the devices and provide a connection. The above connections can be made using any type of local communication protocol, including but not limited to BTLE.

  In one embodiment, network credential information may be stored locally in a secure storage device accessible by IoT hub 1202 or may be contained within IoT hub 1202 (remotely on cloud service 1220) In addition to or instead of storing network credentials). Thus, in this embodiment, network credential information may be provided without the need for remote queries to the cloud service 1220.

  The terms "cloud service" and "IoT cloud service" may refer to any service on the Internet that can store and provide network credential information for the IoT devices described herein (e.g., the IoT above) Services and external services, etc.) In one embodiment, the cloud service 1220 is owned and operated by the same entity as the IoT hub and the entity that provides the IoT device to the end user. In another embodiment, at least a portion of the IoT devices may also be designed and sold by an OEM that cooperates with the cloud service, such that the techniques described herein can always be implemented using the cloud service 1220. Good (eg, through an agreed business agreement).

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

  At 1401, a user provides network credential information to the IoT hub. The credentials may be provided, for example, through a network configuration wizard running in a browser or application installed on the user's data processing device, which may be a wired connection or a local wireless connection (eg BTLE). Can connect to the IoT hub through Once the network credentials are provided, at 1402, the IoT hub establishes a secure connection to the IoT cloud service across the Internet and, at 1403, securely sends the network credentials to the IoT cloud service. At 1404, the IoT Cloud Service stores network credential information in its database, and the particular WiFi Access Point for which the credential information is used for the user's account on the IoT Cloud Service and / or for which network credential information is used Associate with / router.

  FIG. 15 illustrates a method according to an embodiment of the present invention for seamlessly updating a new IoT device using stored network credentials. The method may be implemented in the context of the system architecture described above, but is not limited to any particular architecture.

  At 1501, the user receives a new IoT device. The IoT device may be ordered from an IoT cloud service and / or from an OEM associated with the IoT cloud service. In any case, the new IoT device is associated with the account of the user who received the new IoT device.

  At 1502, when a new IoT device is powered on, the new IoT device first searches for a local IoT hub. As mentioned above, the search may be performed using a local wireless protocol such as BTLE. If the new IoT device can not find the IoT hub (eg because it is out of range), then the new IoT device may search for another IoT device and / or the end user's mobile device (IoT cloud By an application or browser installed on the mobile device to activate the connection to the service).

  At 1503, a determination is made as to whether the new IoT device has detected the presence of an IoT hub, another IoT device, or a mobile device of a user. If an IoT hub is detected, then at 1504, the new IoT device connects to the IoT hub, and at 1505, the IoT hub retrieves network credentials from the cloud service on behalf of the new IoT device, and the credentials are the new IoT device To provide. At 1510, the new IoT device registers with the wireless network using the network credentials.

  If the new IoT device detects another IoT device, then, at 1506, the new IoT device connects to that other IoT device, and at 1507, the IoT device obtains network credentials from the IoT Cloud Service, which is new Provide to IoT devices. In one embodiment, this may be accomplished through the IoT hub (ie, if that other device is connected to the IoT hub). Again, at 1510, the new IoT device registers with the wireless network using the network credentials.

  If the new IoT device detects the user's mobile device, then, at 1508, the new IoT device connects to the mobile device. In one embodiment, the connection is managed by an application such as a connection wizard or browser executable code on the user's mobile device. At 1509, the IoT device obtains network credential information from the IoT cloud service and provides it to the new IoT device. In one embodiment, this may be accomplished through the IoT hub (ie, if that other device is connected to the IoT hub). At 1510, the new IoT device registers with the wireless network using the network credentials.

As mentioned above, in one embodiment, the network registration module 1310 running on the new mobile device uses the connection priority scheme to order the devices that the network registration module 1310 should search when powered on. Decide. In one embodiment, the network registration module 1310 will first search for an IoT hub and will search for other IoT devices if none are found. If none or available, then the network registration module 1310 attempts to connect to the user's mobile device. Alternatively, the new IoT device may simply connect to the first device discovered by the new IoT device, and / or connect to the device where the new IoT device found the highest signal strength (ie, RSSI value) You may Various other connection technologies can be programmed into the network registration module 1310 while adhering to the basic principles of the present invention.
Apparatus and method for establishing a secure communication channel in an internet of things (IoT) system

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Thus, using the techniques described above, establish a two-way secure network socket abstraction between two BT enabled devices without formally pairing BT devices using standard pairing techniques be able to. While 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 may be implemented to negotiate and establish a secure communication channel between any two BT enabled devices Can.

  23A-C illustrate a detailed method for pairing devices 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 that includes the serial number of the IoT service and the public key. At 2302, the IoT service signs the packet using the factory secret key. At 2303, the IoT service sends the packet to the IoT hub via the encrypted channel, and at 2304 the IoT hub forwards the packet to the IoT device via the unencrypted channel. At 2305, the IoT device verifies the signature of the packet, and at 2306, the IoT device generates a packet that includes the serial number of the IoT device and the public key. At 2307, the IoT device signs the packet using the factory secret key, and at 2308, the IoT device sends the packet to the IoT hub over the unencrypted channel.

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

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

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

Moving on to FIG. 23C, at 2329, the IoT device re-encrypts the packet using the session secret, and at 2330, the IoT device sends the encrypted packet to the IoT hub via the unencrypted channel. At 2331, the IoT hub forwards the encrypted packet to the IoT service via the encryption channel. At 2332 the IoT service decrypts the packet using the session secret. At 2333, the IoT service verifies that the random number matches the random number sent by the IoT service. The IoT service then sends a packet at 2334 indicating that pairing is complete, and at 2335 all subsequent messages are encrypted using the session secret.
Apparatus and method for sharing WiFi security data in an IoT system

  As mentioned above, certain IoT devices and IoT hubs may be configured to establish a communication channel via a WiFi network. When establishing a connection via such a secure WiFi network, configuration needs to be performed to provide a WiFi key to the IoT device / hub. Embodiments of the invention described below include techniques for connecting an IoT hub to a secure WiFi channel by sharing security data, such as a WiFi key, thereby simplifying the configuration process.

  As illustrated in FIG. 24, one embodiment of the present invention is designed to connect multiple IoT devices 101-103 to IoT service 120 via the Internet 220 (as in the previous embodiment described above) Is performed in association with the IoT hub 110. In one embodiment, the security techniques described above are used to securely provide the IoT hub 110 with other data such as the WiFi key and the SSID of the local WiFi router 116. In one embodiment, to configure the IoT hub 110, the app on the client device 135 temporarily executes the functions of the IoT hub to communicatively couple the IoT hub 110 to the IoT service. The IoT hub 110 and the IoT service 120 then establish a secure communication channel to provide WiFi security data to the IoT hub described below.

  In particular, FIG. 25 illustrates that the IoT hub 110 and the IoT service 120 can establish a secure communication channel with an encryption engine 1660-1661, a secure key store 1650-1651, a KSGM module 1640-1641, and an HSM module 1630-1631. And how to include the various security components described above. These components operate substantially as described above to securely connect the IoT hub 110 to the IoT service 120. In one embodiment, client application 2505 (or other program code) running on client device 135 is used to encrypt IoT hub 110 and IoT service 120 and WiFi security data as described below Hub / service connection logic 2503 for establishing a communication channel with the security module 2502 for generating and sharing secrets. In one embodiment, client device 130 forms a BTLE connection with IoT hub 110 and a WiFi or cellular data connection with IoT service 120 to establish a connection between IoT hub 110 and IoT service 120.

  As mentioned above, in one embodiment, after the BTLE connection is formed between the IoT hub 110 and the client device 135 and the WiFi / cellular connection is formed between the client device 135 and the IoT service 120, the IoT The service 120 authenticates with the IoT hub using the ECDH key exchange technology described above. In this embodiment, the hub / service connection logic 2503 on the client device 135 performs the same or similar functions as the IoT hub described above (e.g., forming a two-way communication channel to transmit data traffic to the IoT hub 110 and IoT) Pass between services 120).

  In one embodiment, the security module 2502 of the client application 2505 generates a secret used for encryption and sends the secret to the IoT hub via the BTLE communication channel. In one embodiment, the secret comprises a 32 byte random number (eg, generated in a manner similar to the key stream described above). In this embodiment, the secret may be sent in plaintext (eg, WiFi key and related data), as the attacker does not access the underlying data using the secret.

  The client application 2505 then retrieves the WiFi key and other WiFi data (eg, SSID, etc.), encrypts it using the secret, and also sends it to the IoT service 120. In one embodiment, the client application 2505 directly requests this information from the user (eg, asking the user to enter a key via the GUI). In another embodiment, the client application 2505 obtains this information from the local secure storage after authentication by the end user. Because the IoT service 120 does not have the secret generated by the security module 2502, it can not read the WiFi key and other data.

  In one embodiment, the IoT service 120 then encrypts the (already encrypted) key and other data and sends the twice encrypted key / data to the IoT hub via the hub / service connection logic 2503. Send to 110 The client application 2505 in this embodiment can not read this traffic because only the IoT service 120 and the IoT hub 110 have session secrets (see, eg, FIGS. 16A-23C and related text). Thus, upon receiving the twice encrypted key and other data, the IoT hub 110 decrypts the twice encrypted key / data using the session secret to decrypt the encrypted key / data. Generate (a version encrypted using the secret generated by the security module 2502).

  In one embodiment, the WiFi data processing logic 2510 on the IoT hub then decrypts the encrypted key and other data using the secret provided by the security module 2502 to completely decrypt the WiFi Provides keys and associated data. The WiFi key and data (eg, WiFi router 116 SSID) may then be used to establish a secure communication channel with the local WiFi router 116. This connection may then be used to connect to the IoT service 120.

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

  At 2601, the IoT service creates a communication channel encrypted using the session secret to communicate with the IoT hub via the client device. At 2602, the app on the client device generates a secret used for encryption and sends the secret to the IoT hub. At 2603, the app on the client device obtains the WiFi key, encrypts the WiFi key using the secret, and sends it to the IoT service. As mentioned above, obtaining the WiFi key may involve the user manually entering the key or reading the key from secure storage on the client device.

At 2604, the IoT service encrypts the already encrypted key to generate a twice encrypted key and sends it to the IoT hub via the client device application. At 2605, the IoT hub decrypts the twice encrypted key using the session secret used to form a secure communication channel between the IoT hub and the IoT service. The resulting encrypted key is a version encrypted using the secret generated by the application on the client device. At 2606, the IoT hub decrypts the encrypted key using the secret provided by the app, resulting in an unencrypted key. Finally, at 2607, the IoT hub establishes a secure WiFi connection to use to connect to the IoT service using the unencrypted WiFi key.
System and method for automatic wireless network authentication in Internet of Things (IoT) system

  One embodiment of the present invention implements techniques for connecting new IoT devices and IoT hubs to WiFi routers securely and automatically. This embodiment is described with respect to FIG. 27, which initially includes a master IoT hub 2716 that forms a local wireless connection to one or more extender IoT hubs 2710-2711 and / or IoT devices 105. As used herein, an “extender” IoT hub is a wireless range of the master IoT hub 2716 to connect the IoT devices 101-104 (eg, an IoT device that is out of range of the master IoT hub 2716) to the IoT system It is an IoT hub that expands For example, IoT devices 101-104 can form a BTLE connection with IoT extender hubs 2710-2711 (using various techniques described herein), and extender IoT hubs 2710-2711 can be Form a WiFi connection to the master IoT hub 2716. As illustrated, the master IoT hub 2716 can also form a direct local wireless connection to a particular IoT device 105 within range (eg, BTLE or WiFi connection).

  In addition to performing all the functions of the IoT hub, one embodiment of the master IoT hub 2716 also connects various IoT devices 101-105 and IoT extender hubs 2710-2711 to the IoT service 120 via the Internet 220 Is also a WiFi router. In one embodiment, the master IoT hub 2716 includes an authentication module 2720 for authenticating various IoT devices 101-105 and extender IoT hubs 2710-2711 on the local network. In particular, in one embodiment, the authentication module 2720 is configured to pre-program non-displayed service set identifiers (SSIDs) into various IoT devices 101-105 and extender IoT hubs 2710-2711. Use with the name. For example, an SSID such as “_afero” may be used by the authentication module 2720, and each IoT device 101-104 and extender IoT hub 2710-2711 will be automatically connected to the master IoT hub 2716 by these hubs / devices As is possible, it may be preprogrammed with this SSID. In addition, authentication logic 2720 may require a security passphrase, such as a WPA2 passphrase. In one embodiment, each IoT device 101-105 and extender IoT hub 2710-2711 are also pre-programmed with this pass phrase to automatically connect to the master IoT hub 2716 during user installation.

  In one embodiment, the firewall 2730 is configured to block all incoming and outgoing requests except those for small servers within the IoT service 120 (or other external service) with known hostnames. It is implemented on the IoT hub 2716. In this embodiment, the IoT devices 101-105 may use the IoT service 120 through the master IoT hub 2716 but are not permitted to connect to any server other than one programmed in the master IoT hub 2716. In this manner, the IoT devices 101-104 may be securely configured by the end user and connected to the IoT service 120.

  In addition, an authentication module with a whitelist specifying all IoT devices 101-105 and extender IoT hubs 2710-2711 that are allowed to connect to the master IoT hub 2716 for an additional layer of security 2720 or firewall 2730 may be programmed. In one embodiment, the Media Access Control (MAC) addresses of the licensed IoT devices 101-105 and the extender IoT hubs 2710-2711 are included in the whitelist. Only those IoT devices and extender IoT hubs that are on the whitelist are allowed to connect through the master IoT hub 2716. The IoT service 120 may periodically update the whitelist as new IoT devices 101-105 and extender IoT hubs 2710-2711 are provided to the end user.

  In one embodiment, an existing WiFi router may be configured to perform the various functions described herein. For example, the WiFi router firewall 2730 may be programmed to block all in / out connections other than from the server of the IoT service 120. In addition, the firewall 2730 may be configured to only allow connections from IoT devices with MAC addresses that are on the whitelist and IoT extender hubs (periodically or dynamically as described above IoT services May be updated from 120). In addition, the WiFi router may be programmed with a hidden SSID and pass phrase preconfigured on the IoT devices 101-105 and IoT extender hubs 2710-2711.

  A method according to an embodiment of the invention is shown in FIG. The method may be implemented on the above described system architecture, but is not limited to any particular system architecture.

  At 2801, the master IoT hub is programmed with the hidden SSID and pass phrase. At 2802, one or more extender IoT hubs and / or IoT devices connect to the master IoT hub using the SSID and pass phrase. At 2803, the firewall on the master IoT hub is programmed to block all incoming and outgoing connection requests other than for designated servers (eg, servers internal to the IoT service). At 2804, the IoT hub is programmed with a white list of MAC addresses for the IoT device and / or extender IoT hub. At 2805, the IoT device and / or extender IoT hub attempts to connect through the master IoT hub. If the connection request is not destined for an authorized server determined at 2807 (eg, in an IoT service), then the connection attempt is blocked at 2809. If the server is authorized, then it is determined at 2807 whether the MAC address of the IoT device or extender IoT hub is included in the white list. Otherwise, the connection is blocked at 2809. If so, the connection is established at 2808.

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

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

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

Claims (24)

It is the Internet of Things (IoT) hub,
A first local wireless communication interface establishing a first local wireless connection with one or more IoT devices and / or IoT extender hubs using a first local wireless communication protocol;
A network router establishing a network connection via the Internet instead of all or a subset of the IoT device and / or IoT extender hub;
An authentication module that receives connection requests from the IoT device and / or IoT extender hub, and admits the connection request when the IoT device and / or IoT extender hub use appropriate authentication;
An IoT hub comprising: a firewall of the IoT hub that blocks all incoming / outgoing / outgoing connection requests other than connection requests for servers of the IoT service specified by a known host name.   The IoT according to claim 1, wherein the authentication module is further configured to reject connection requests other than connection requests from an IoT device and / or an IoT extender hub having a known medium access control (MAC) address. Hub.   The IoT hub of claim 1, wherein the first local wireless communication interface comprises a WiFi interface.   The IoT hub of claim 3, wherein the WiFi interface comprises an 802.11ac interface.   The IoT hub of claim 1, wherein the firewall is updated via the Internet to include a new host name of a designated server of the IoT service.   The IoT according to claim 1, further comprising: a second local wireless communication interface establishing a second local wireless connection with one or more other IoT devices using a second local wireless communication protocol. Hub.   The IoT hub of claim 6, wherein the second local wireless communication interface comprises a Bluetooth Low Energy (BTLE) interface.   The authentication module is pre-configured with a passphrase and a hidden service set identifier (SSID), and the authentication module uses the pre-configured passphrase and non-displayed SSID to configure these IoT devices and / or The IoT hub according to claim 1, wherein the connection request is accepted by the IoT extender hub. Method,
Establishing a first local wireless connection between the IoT hub and the one or more IoT devices and / or the IoT extender hub using a first local wireless communication protocol;
Receiving a connection request from the IoT device and / or the IoT extender hub using appropriate authentication;
When the IoT device and / or IoT extender hub use the pre-configured pass phrase and hidden SSID, acknowledge the connection request and connect the IoT device and / or IoT hub to the IoT service accordingly When,
Blocking all incoming / outgoing connection requests other than those directed to the server of said IoT service specified by a known host name.   The method according to claim 9, further comprising blocking all local wireless connection requests other than connection requests from IoT devices and / or IoT extender hubs with known medium access control (MAC) addresses.   11. The method of claim 10, wherein the first local wireless communication protocol comprises a WiFi protocol.   The method of claim 11, wherein the WiFi protocol comprises an 802.11ac protocol.   The method according to claim 9, further comprising: updating the IoT hub via the Internet to include a new host name of a designated server of the IoT service.   10. The method of claim 9, further comprising establishing a second local wireless connection with one or more other IoT devices using a second local wireless communication protocol.   15. The method of claim 14, wherein the second local wireless communication protocol comprises a Bluetooth Low Energy (BTLE) protocol.   The authentication module is pre-configured with a passphrase and a hidden service set identifier (SSID), and proper authentication is performed using the pre-configured passphrase and non-displayed SSID. 10. The method of claim 9, or including an IoT extender hub. A system,
With IoT services,
A plurality of IoT devices and / or IoT extender hubs that attempt to connect to the IoT service via the Internet;
It is the Internet of Things (IoT) hub,
A first local wireless communication interface establishing a first local wireless connection with one or more IoT devices and / or IoT extender hubs using a first local wireless communication protocol;
A network router establishing a network connection via the Internet instead of all or a subset of the IoT device and / or IoT extender hub;
An authentication module that receives connection requests from the IoT device and / or IoT extender hub, and admits the connection request when the IoT device and / or IoT extender hub use appropriate authentication;
An IoT hub comprising: a firewall of the IoT hub that blocks all incoming / outgoing / outgoing connection requests other than connection requests for servers of the IoT service specified by a known host name.   The system according to claim 17, wherein the authentication module is further configured to reject connection requests other than connection requests from IoT devices and / or IoT extender hubs having a known medium access control (MAC) address. .   The system of claim 17, wherein the first local wireless communication interface comprises a WiFi interface.   20. The system of claim 19, wherein the WiFi interface comprises an 802.11ac interface.   The system of claim 17, wherein the firewall is updated via the Internet to include a new host name of a designated server of the IoT service.   18. The system of claim 17, further comprising: a second local wireless communication interface establishing a second local wireless connection with one or more other IoT devices using a second local wireless communication protocol. .   23. The system of claim 22, wherein the second local wireless communication interface comprises a Bluetooth Low Energy (BTLE) interface.   The authentication module is pre-configured with a passphrase and a hidden service set identifier (SSID), and the authentication module uses the pre-configured passphrase and non-displayed SSID to configure these IoT devices and / or The system according to claim 17, wherein the system accepts the connection request to the IoT extender hub.