KR102303689B1 - Systems and methods for establishing secure communication channels with Internet of Things (IoT) devices - Google Patents

Abstract

A system and method for establishing secure communication channels are described. For example, one embodiment of a system may include an IoT device comprising secret/counter processing logic/circuitry that generates a master secret to be transmitted to an IoT service; one or more IoT hubs to receive the master secret from the IoT service via the first secure communication channel, wherein at least one of the IoT hubs establishes a second secure communication channel with the IoT device using the master secret.

Description

Systems and methods for establishing secure communication channels with Internet of Things (IoT) devices

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

"Internet of Things" refers to the interconnection of uniquely identifiable embedded devices within an Internet infrastructure. Ultimately, the IoT will open up a wide range of new applications in which virtually any type of physical object can provide information about itself or its surroundings and/or can be remotely controlled via a client device via the Internet. expected to create

A better understanding of the present invention may be obtained from the following detailed description in conjunction with the following drawings.
1A and 1B illustrate different embodiments of an IoT system architecture.
2 illustrates an IoT device according to an embodiment of the present invention.
3 illustrates an IoT hub according to an embodiment of the present invention.
4A and 4B illustrate embodiments of the present invention for controlling and collecting data and generating notifications from IoT devices.
5 illustrates embodiments of the present invention for collecting data from IoT devices and generating notifications from an IoT hub and/or IoT service.
6 illustrates an embodiment of a system in which an intermediary mobile device collects data from a stationary IoT device and provides the data to an IoT hub.
7 illustrates the intermediary connection logic implemented in one embodiment of the present invention.
8 illustrates a method according to an embodiment of the present invention.
9A illustrates an embodiment in which program code and data updates are provided to an IoT device.
9B illustrates an embodiment of how program code and data updates are provided to an IoT device.
10 illustrates a high-level diagram of one embodiment of a security architecture.
11 illustrates one embodiment of an architecture in which a Subscriber Identity Module (SIM) is used to store a key on an IoT device.
12A illustrates an embodiment in which an IoT device is registered using a barcode or QR code.
12B illustrates an embodiment in which pairing is performed using a barcode or QR code.
13 illustrates one embodiment of a method of programming a SIM using an IoT hub.
14 illustrates an embodiment of a method of registering an IoT device with an IoT hub and an IoT service.
15 illustrates an embodiment of a method of encrypting data to be transmitted to an IoT device.
16A and 16B illustrate different embodiments of the present invention for encrypting data between an IoT service and an IoT device.
17 illustrates embodiments of the present invention that perform a secure key exchange, generate a common secret, and use the secret to generate a key stream.
18 illustrates a packet structure according to an embodiment of the present invention.
19 illustrates a technique used in one embodiment to write data to and read data from an IoT device without formally pairing with the IoT device.
20 illustrates an exemplary set of command packets used in one embodiment of the present invention.
21 illustrates an example transaction sequence using command packets.
22 illustrates a method according to an embodiment of the present invention.
23A-23C illustrate a method for secure pairing according to an embodiment of the present invention.
24 illustrates an embodiment of the present invention that adjusts advertisement intervals to identify data transmission conditions.
25 illustrates a method according to an embodiment of the present invention.
26A-26C illustrate the operation of one embodiment in which multiple IoT hubs attempt to transmit data/commands to an IoT device.
27 illustrates a method according to an embodiment of the present invention.
28 illustrates one embodiment of a system for secure IoT device provisioning.
29 illustrates a method according to an embodiment of the present invention.
30 is an embodiment of a system for performing flow control for a plurality of IoT devices.
31 illustrates a method according to an embodiment of the present invention.
32 illustrates one embodiment of a system for managing application properties, system properties, and priority notification properties.
33 illustrates one embodiment of a system and corresponding method for secure wireless communication.
34 and 35 illustrate embodiments of the present invention for detecting false connections.
36 illustrates an embodiment of the present invention for implementing latched attributes.

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

One embodiment of the present invention includes an Internet of Things (IoT) platform that can be used by developers to design and build new IoT devices and applications. In particular, one embodiment includes an underlying hardware/software platform for IoT devices including an IoT hub and a predefined networking protocol stack through which the IoT devices are coupled to the Internet. Additionally, one embodiment includes an IoT service through which IoT hubs and connected IoT devices can be accessed and managed as described below. Additionally, one embodiment of the IoT platform includes an IoT app or web application (eg, running on a client device) for accessing and configuring IoT services, hubs, and connected devices. Existing online retailers and other website operators can leverage the IoT platform described herein to easily provide unique IoT capabilities to their existing user base.

1A illustrates an overview of an architectural platform on which an embodiment of the present invention may be implemented. In particular, the illustrated embodiment is a plurality of IoT communicatively coupled via a local communication channel 130 to a central IoT hub 110 that is itself communicatively coupled to an IoT service 120 via the Internet 220 . devices 101 to 105 . Each of the IoT devices 101 - 105 may be initially paired to the IoT hub 110 (eg, using a pairing technique described below) to enable each of the local communication channels 130 . In one embodiment, 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 a sensor (eg, a temperature sensor, accelerometer, thermal sensor, motion detector, etc.), the database 122 continues to store data collected by the IoT devices 101 - 105 . may be updated. The data stored in database 122 is then transferred to the end user via an IoT app or browser installed on the user's device 135 (or via a desktop or other client computer system) and (eg, IoT service 120 ). ) may be made accessible by a web client (such as a website 130 subscribed to).

The IoT devices 101 to 105 collect information about them and their surroundings, and transmit the collected information to the IoT service 120 , the user device 135 and/or the external website 130 through the IoT hub 110 . Various types of sensors for providing may be mounted. Some of the IoT devices 101 to 105 may perform a specified function in response to a control command transmitted through the IoT hub 110 . Various specific examples of information and control commands collected by IoT devices 101 - 105 are provided below. In one embodiment described below, IoT device 101 is a user input device designed to record user selections and transmit user selections to IoT service 120 and/or a website.

In one embodiment, the IoT hub 110 has a cellular radio to establish a connection to the Internet 220 via a cellular service 115 such as 4G (eg, Mobile WiMAX, LTE) or 5G cellular data service. include Alternatively or additionally, IoT hub 110 may be configured with a WiFi access point or router 116 that couples IoT hub 110 to the Internet (eg, via an Internet service provider that provides Internet services to end users). ) may include a WiFi radio for establishing a WiFi connection. Of course, it should be noted that the basic principles of the present invention are not limited to any particular type of communication channel or protocol.

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

As noted, in one embodiment, the IoT platform is a user device to allow a user to access and configure connected IoT devices 101 - 105 , IoT hub 110 , and/or IoT service 120 . an IoT app or web application running on 135 . In one embodiment, the app or web application may be designed by the operator of website 130 to provide IoT functionality to its user base. As illustrated, the website may maintain a user database 131 containing account records related to each user.

1B illustrates additional connection options for multiple IoT hubs 110 , 111 , 190 . In such an embodiment, a single user may have multiple hubs 110 , 111 field installed on a single user premises 180 (eg, 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 indicated, if a user has multiple hubs 110 , 111 , they may be connected via a local communication channel (eg, Wifi, Ethernet, power line networking, etc.). In one embodiment, each of the hubs 110 and 111 may 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 additionally, one of the IoT hubs, such as IoT hub 110 , may be configured as IoT hub 111 (as indicated by the dashed line connecting IoT hub 110 and IoT hub 111 ). , may act as a “master” hub providing connectivity and/or local services to all of the other IoT hubs on the user premises 180 . For example, the master IoT hub 110 may be the only IoT hub for establishing a direct connection to the IoT service 120 . In one embodiment, only the “master” IoT hub 110 is equipped with a cellular communication interface for establishing a connection to the IoT service 120 . As such, all communication between the IoT service 120 and the other IoT hub 111 will flow through the master IoT hub 110 . In this role, the master IoT hub 110 performs filtering operations on data exchanged between another IoT hub 111 and an IoT service 120 (eg, servicing some data requests locally if possible). Additional program code to perform may be provided.

Irrespective of how the IoT hubs 110 , 111 are connected, in one embodiment, the IoT service 120 provides a single, comprehensive user interface (and/or browser-) accessible through the user device 135 on which the app is installed. underlying interface) will logically associate the hub with the user and bind all of the attached IoT devices 101 - 105 .

In this embodiment, the master IoT hub 110 and one or more slave IoT hubs 111 are connected via a local network, which may be a WiFi network 116 , an Ethernet network, and/or use power-line communication (PLC) networking. (eg, where all or part of the network is powered through the user's power line). Additionally, with respect to IoT hubs 110 , 111 , each of IoT devices 101 - 105 uses an IoT device using any type of local network channel such as WiFi, Ethernet, PLC or Bluetooth LE to name a few. It may be interconnected with hubs 110 and 111 .

1B also shows an IoT hub 190 installed at the second user's premises 181 . A virtually 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's premises 180 may be a user's main home, and another user's premises 181 may be a user's villa. In such a case, IoT service 120 connects IoT hubs 110 , 111 , 190 with users under a single comprehensive user interface (and/or browser-based interface) accessible through user device 135 on which the app is installed. It will logically associate and couple all of the attached IoT devices 101 - 105 , 191 , 192 .

As illustrated in FIG. 2 , an exemplary embodiment of an IoT device 101 includes a memory 210 for storing program codes and data 201 to 203 and a low-power microcontroller for executing the program codes and processing data. (200). Memory 210 may be volatile memory, such as dynamic random access memory (DRAM), or may be 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 for execution of program code and data at runtime. Further, the memory 210 may be integrated into the low power microcontroller 200 , or may be coupled to the low power microcontroller 200 via a bus or communication fabric. The underlying principles of the present invention are not limited to any particular implementation of memory 210 .

As illustrated, the program code is application program code 203 that defines an application-specific set of functions to be performed by the IoT device 201 , and a predefined that can be used by an application developer of the IoT device 101 . library code 202 comprising a set of building blocks. In one embodiment, the library code 202 is the basic required to implement an IoT device, such as a communication protocol stack 201 to enable communication between each IoT device 101 and the IoT hub 110 . It contains a set of functions. As mentioned, in one embodiment, the communication protocol stack 201 comprises a Bluetooth LE protocol stack. In such an embodiment, the Bluetooth LE radio and antenna 207 may be integrated into the low power microcontroller 200 . However, the basic principles of the present invention are not limited to any particular communication protocol.

The particular embodiment shown in FIG. 2 also includes a plurality of input devices or sensors 210 for receiving user input and providing the user input to a low power microcontroller, the low power microcontroller including application code 203 and library code Process the user input according to (202). In one embodiment, each of the input devices includes an LED 209 for providing feedback to the end user.

Additionally, the illustrated embodiment includes a battery 208 for powering the low power microcontroller. In one embodiment, a non-rechargeable coin cell battery is used. However, in alternative embodiments, an integrated rechargeable battery may be used (eg, rechargeable by connecting the IoT device to an AC power supply (not shown)).

A speaker 205 for generating audio is also provided. In one embodiment, the low power microcontroller 299 provides audio for decoding a compressed audio stream (eg, an MPEG-4/Advanced Audio Coding (AAC) stream) to generate audio from the speaker 205 . Includes decoding logic. Alternatively, the low-power microcontroller 200 and/or application code/data 203 may be digitally sampled fragments of audio for providing verbal feedback to the end user as the user enters a selection via the input device 210 . (snippet) may be included.

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

In one embodiment, the low power microcontroller 200 also includes a secure key store for storing encryption keys for encrypting communications and/or 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 the IoT device from an ultra-low power state in which it is consuming virtually no power. In one embodiment, the wakeup receiver 207 causes the IoT device 101 to cause this configured to exit the low power state. In particular, in one embodiment, transmitter 307 and receiver 207 together form an electrically resonant transformer circuit, such as a Tesla coil. In operation, energy is transmitted from the transmitter 307 to the receiver 207 via a radio frequency signal when the hub 110 needs to wake the IoT device 101 from a very low power state. Because of energy transfer, the IoT device 101 may be configured to consume virtually no power when it is in its low power state, because (as in network protocols that allow the device to be awake via a network signal). That's because it doesn't need to constantly "listen" for a signal from the hub. Rather, the microcontroller 200 of the IoT device 101 may 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 data. ) is included. A wide area network (WAN) interface 302 and antenna 310 couple IoT hub 110 to cellular service 115 . Alternatively, as mentioned above, IoT hub 110 may also include a local network interface (not shown) such as a WiFi interface (and WiFi antenna) or an Ethernet interface for establishing a local area network communication channel. . In one embodiment, hardware logic 301 also includes a secure key store for storing encryption keys for encrypting communications and generating/verifying signatures. Alternatively, the key may be secured in a Subscriber Identity Module (SIM).

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

In one embodiment, the program code and data includes a communication protocol stack 308 , which may include separate stacks for communicating over a local communication interface 303 and a WAN interface 302 . Additionally, device pairing program code and data 306 may be stored in memory to allow the IoT hub to pair with a new IoT device. In one embodiment, each new IoT device 101 - 105 is assigned a unique code that is communicated to the IoT hub 110 during the pairing process. For example, the unique code may be embedded in a barcode on the IoT device and may be read by the barcode reader 106 or communicated over the local communication channel 130 . In an alternative embodiment, the unique ID code is magnetically embedded on the IoT device, which the IoT hub uses to detect the code when the IoT device 101 is moved within a few inches of the IoT hub 110 ( RFID) or magnetic sensors such as near field communication (NFC) sensors.

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

In one embodiment, the organization running the IoT service 120 may provide the IoT hub 110 and the underlying hardware/software platform to allow developers to easily design new IoT services. In particular, in addition to the IoT hub 110 , the developer may be provided with a software development kit (SDK) for updating the program code and data 305 running within the hub 110 . Additionally, for the IoT device 101 , the SDK includes the underlying IoT hardware (eg, the low-power microcontroller 200 shown in FIG. 2 , and other components) designed for an extensive set of library code 202 . In one embodiment, the SDK includes a graphical design interface in which the developer only needs to specify inputs and outputs for the IoT device. All networking code, including communication stack 201 that allows IoT device 101 to connect to hub 110 and services 120, is already in place for developers. Additionally, in one embodiment, the SDK also includes a library code base to facilitate the design of apps for mobile devices (eg, iPhone and Android devices).

In one embodiment, the IoT hub 110 manages a continuous bidirectional stream of data between the IoT devices 101 - 105 and the IoT service 120 . In situations where updates to/from IoT devices 101 - 105 are required in real time (eg, a user needs to view the current status of a security device or environmental measurement), the IoT hub may provide regular updates to the user device ( 135) and/or an open TCP socket for serving external websites 130 . The specific networking protocol used to provide updates can be fine-tuned based on the needs of the underlying application. For example, in some cases where it may not be feasible to have a continuous bidirectional stream, a simple request/response protocol may be used to gather information when needed.

In one embodiment, both the IoT hub 110 and IoT devices 101 - 105 are automatically upgradeable over the network. In particular, when a new update is available to the IoT hub 110 , it may automatically download and install the update from the IoT service 120 . It can first copy the updated code to local memory, run it, and verify the update before replacing the outdated program code. Similarly, when an update is available to each of the IoT devices 101 - 105 , the update may be initially downloaded by the IoT hub 110 and pushed out to each of the IoT devices 101 - 105 . Thereafter, each of the IoT devices 101 to 105 may apply the update in a similar manner to that described above for the IoT hub and report the result of the update back to the IoT hub 110 . If the update is successful, the IoT hub 110 deletes the update from its memory (eg, so that it can keep checking for new updates for each IoT device) and the latest version of the code installed on each IoT device. version can be recorded.

In one embodiment, the IoT hub 110 is powered via A/C power. In particular, the IoT hub 110 may include a power unit 390 having a transformer for transforming an A/C voltage supplied through an A/C power cord to a lower DC voltage.

4A illustrates an embodiment of the present invention for performing a universal remote control operation using an IoT system. In particular, in this embodiment, the set of IoT devices 101 - 103 includes a variety of different types of electronic equipment including (to name a few) an air conditioner/heater 430 , a lighting system 431 and audiovisual equipment 432 . Infrared (IR) and/or radio frequency (RF) blasters 401 to 403 for transmitting a remote control code to control the device are respectively mounted. In the embodiment shown in FIG. 4A , the IoT devices 101 to 103 are also equipped with sensors 404 to 406 for detecting the operation of the devices they control, respectively, as described below.

For example, a sensor 404 in the IoT device 101 may sense a current temperature/humidity and in response a temperature and/or humidity sensor for controlling the air conditioner/heater 430 based on the current desired temperature. can be In this embodiment, the air conditioner/heater 430 is designed to be controlled via a remote control device (typically a remote control having a temperature sensor embedded in itself). In one embodiment, the user provides the desired temperature to the IoT hub 110 via an app or browser installed on the user device 135 . Control logic 412 running on IoT hub 110 receives current temperature/humidity data from sensor 404 and in response, IoT device to control IR/RF blaster 401 according to desired temperature/humidity. A command is sent to 101. For example, if the temperature is below the desired temperature, the control logic 412 sends a command to the air conditioner/heater via the IR/RF blaster 401 (eg, by turning the air conditioner off or turning the heater on). temperature can be raised. The command may include the necessary remote control code stored in the database 413 on the IoT hub 110 . Alternatively or additionally, IoT service 421 may implement control logic 421 for controlling electronic equipment 430 - 432 based on specified user preferences and stored control code 422 .

The IoT device 102 of the illustrated example is used to control the lighting 431 . In particular, the sensor 405 in the IoT device 102 may be a photosensor or photodetector configured to detect the current brightness of light generated by the lighting fixture 431 (or other lighting device). A user may designate a desired lighting level (including an indication of on or off) to the IoT hub 110 via the user device 135 . In response, the control logic 412 will send a command to the IR/RF blaster 402 to control the current brightness level of the illuminator 431 (eg, increase the illumination if the current brightness is too low, or If the current brightness is too high, turn the lights down (or simply turn the illuminator on or off).

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

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

In an embodiment 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 present invention are not limited to Bluetooth LE or any other communication standard.

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

Also, in one embodiment, the IoT hub 110 has an IR that enables a remote control code learning module 491 to "learn" a new remote control code directly from the original remote control 495 provided with the electronic equipment. /RF interface 490 is mounted. For example, if the control code for 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 through an app/browser on the user device 135 . Thus, various control codes (eg, increase in temperature, decrease in temperature, etc.) generated by the original remote control may be taught to the IoT hub 110 . Once the remote control codes are learned, they may be stored in the control code database 413 on the IoT hub 110 and/or transmitted back to the IoT service 120 for inclusion in the central remote control code database 492 (and subsequent to be used by other users with the same air conditioning unit 430).

In one embodiment, each of the IoT devices 101 - 103 has an extremely small form factor, and can be placed on or near their respective electronic equipment 430 - 432 using double sided tape, small nails, magnetic attachment, or the like. can be attached. For control of equipment such as air conditioner 430 , it would be desirable to place IoT device 101 far enough away so that sensor 404 can accurately measure the ambient temperature inside the house (eg, directly on the air conditioner). Deploying IoT devices will result in temperature readings that are too low when the air conditioner is running or too high when the heater is running). In contrast, the IoT device 102 used to control lighting may be placed on or near the lighting fixture 431 for the sensor 405 to detect the current lighting level.

In addition to providing general control functions as described, one embodiment of IoT hub 110 and/or IoT service 120 sends notifications related to the current state of each electronic device to the end user. A notification, which may be a text message and/or an app-specific notification, may then be displayed on the display of the user's mobile device 135 . For example, if the user's air conditioner has been turned on for a long time but the temperature has not changed, the IoT hub 110 and/or the IoT service 120 may send a notification to the user that the air conditioner is not functioning properly. If the user is not at home (which may be detected via a motion sensor or based on the user's current detected location), the sensor 406 indicates that the audiovisual equipment 430 is on, or the sensor 405 is When indicating that the illuminator is on, a notification may be sent to the user asking if the user wishes to turn off the audiovisual equipment 432 and/or the illuminator 431 . The same type of notification may be sent for any equipment type.

When the user receives the notification, he/she can remotely control the electronic equipment 430 - 432 via an app or browser on the user device 135 . In one embodiment, user device 135 is a touch screen device, and an app or browser displays an image of a remote control with buttons that the user can select to control equipment 430 - 432 . Upon receiving the notification, the user can open the graphical remote control and turn off or adjust a variety of different equipment. When connected through the IoT service 120 , the user's selection may be transmitted from the IoT service 120 to the IoT hub 110 , and then the IoT hub 110 controls the equipment through the control logic 412 . will be. Alternatively, the user input may be sent directly from the user device 135 to the IoT hub 110 .

In one embodiment, the user may program the control logic 412 on the IoT hub 110 to perform various automatic control functions for the electronic equipment 430 - 432 . In addition to maintaining the desired temperature, brightness level, and volume level as described above, the control logic 412 may automatically turn off the electronic equipment when a predetermined condition is detected. For example, if the control logic 412 detects that the user is not at home and the air conditioner is not functioning, it may automatically turn off the air conditioner. Similarly, if the user is not at home, and the sensor 406 indicates that the audiovisual equipment 430 is on or the sensor 405 indicates that the illuminator is on, then the control logic 412 sends the IR/RF blaster 403 on. , 402) by automatically sending a command to turn off the audiovisual equipment and the illuminator, respectively.

5 illustrates a further embodiment of an IoT device 104 , 105 equipped with sensors 503 , 504 for monitoring electronic equipment 530 , 531 . In particular, the IoT device 104 of this embodiment includes a temperature sensor 503 that may be disposed 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 turned on (eg, based on the measured temperature) for more than a threshold period of time, the control logic 512 sends a notification to the user that the stove 530 is on, the end user's device 135 ) can be sent. Also, in one embodiment, the IoT device 104 controls to turn off the stove in response to receiving a command from a user or automatically (if control logic 512 is programmed to do so by the user). It may include a module 501 . In one embodiment, the control logic 501 includes a switch that shuts off electricity or gas to the stove 530 . However, in other embodiments, the control logic 501 may be incorporated within the stove itself.

5 also illustrates an IoT device 105 having a motion sensor 504 for detecting motion of certain types of electronic equipment, such as a washing machine and/or dryer. Other sensors that may be used are audio sensors (eg, microphones and logic) for detecting ambient volume levels. As with the other embodiments described above, this embodiment notifies the end user when certain specified conditions are met (eg, when motion is detected for an extended period of time, indicating that the washer/dryer has not been turned off). can be sent. Although not shown in FIG. 5 , the IoT device 105 also includes a control module that turns off the washer/dryer 531 automatically and/or in response to user input (eg, by switching off electricity/gas). can be mounted.

In one embodiment, the first IoT device having the control logic and the switch may be configured to turn off all power in the user's house, and the second IoT device having the control logic and the switch turns off all the gas in the user's house. It can be configured to turn off. The IoT device with the sensor may then be placed on or near the electronic or gas powered equipment in the user's home. When the user is notified that certain equipment (eg, stove 530 ) is left on, the user can send a command to turn off all electricity or gas in the house to prevent damage. Alternatively, control logic 512 within IoT hub 110 and/or IoT service 120 may be configured to automatically turn off electricity or gas in such a situation.

In one embodiment, IoT hub 110 and IoT service 120 communicate at periodic intervals. When the IoT service 120 detects that the connection to the IoT hub 110 is lost (eg, by not receiving a request or response from the IoT hub for a specified duration), (eg, a text message or will communicate this information to the end user's device 135 (by sending an app-specific notification).

Apparatus and method for communicating data via an intermediary device

As mentioned above, since the wireless technologies used to interconnect IoT devices, such as Bluetooth LE, are generally short-range technologies, when the hub for IoT implementation is out of range of the IoT device, the IoT device can transmit data to the IoT. You won't be able to send to the hub (and vice versa).

To address this deficiencies, an embodiment of the present invention provides a mechanism for an IoT device that is outside the wireless range of an IoT hub to periodically connect with one or more mobile devices when the mobile devices are within range. Once connected, the IoT device can send to the mobile device any data that needs to be provided to the IoT hub, which in turn sends the data to the IoT hub.

As illustrated in FIG. 6 , one embodiment includes an IoT hub 110 , an IoT device 601 that is out of range of the IoT hub 110 , and a mobile device 611 . Out-of-range IoT device 601 may include any type of IoT device capable of collecting and communicating data. For example, the IoT device 601 may include a data collection device configured within the refrigerator to monitor food items available in the refrigerator, users consuming the food items, and a current temperature. Of course, the basic principles of the present invention are not limited to any particular type of IoT device. The techniques described herein can be applied to any type of IoT, including those used to collect and transmit data for smart meters, stoves, washing machines, dryers, lighting systems, HVAC systems, and audiovisual equipment, to name just a few. It can be implemented using a device.

Moreover, the mobile device 611 illustrated in FIG. 6 may be any type of mobile device capable of communicating and storing data. For example, in one embodiment, mobile device 611 is a smartphone with an app installed to facilitate the techniques described herein. In another embodiment, mobile device 611 comprises a wearable device such as a communication token attached to a necklace or bracelet, a smartwatch, or a fitness device. Wearable tokens may be particularly useful for older users or other users who do not own a smartphone device.

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

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

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

As illustrated in FIG. 7 , the intermediary connection logic/applications 701 , 711 , 721 on each device may be configured based on applications in close proximity. For example, in the case of a refrigerator, the access logic/application 701 may only need to periodically transmit a small number of packets. For other applications (eg, temperature sensors), the connection logic/application 701 may need to send more frequent updates.

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

Also, although only a single mobile device 611 is illustrated in FIGS. 6 and 7 for simplicity, in one embodiment, multiple such mobile devices of different users may be configured to communicate with the IoT device 601 . Moreover, the same techniques may be implemented for a number of other IoT devices, thereby forming a home-wide intermediary device data collection system.

Moreover, in one embodiment, the techniques described herein may be used to collect a variety of different types of appropriate data. For example, in one embodiment, whenever the mobile device 611 connects with the IoT device 601 , the identity of the user may be included in the collected data 605 . In this way, the IoT system can be used to track the behavior of different users in the house. For example, when used within a refrigerator, the collected data 605 may include the identity of each user passing by the refrigerator, each user opening the refrigerator, and the specific food items consumed by each user. . Different types of data may be collected from different types of IoT devices. Using this data, the system can determine, for example, which users wash clothes, which users watch TV on a given day, when each user goes to bed and wakes up, and the like. All of this crowd-sourced data may then be aggregated within the IoT hub's data store 413 and/or sent to an external service or user.

Another advantageous application of the techniques described herein is monitoring elderly users who may need assistance. For this application, the mobile device 611 may be a very small token worn by an elderly user to gather information in different rooms of the user's home. For example, whenever a user opens a refrigerator, this data will be included in the collected data 605 and transmitted to the IoT hub 110 through a token. The IoT hub may then provide the data to one or more external users (eg, children or other individuals caring for an elderly user). If data has not been collected for a specified period of time (eg, 12 hours), this means that the elderly user has not moved around the house and/or has not opened the refrigerator. The IoT hub 110 or an external service connected to the IoT hub may then send an alert notification to these other individuals, informing them that they should check out the elderly user. In addition, the collected data 605 may be used to determine which food is being consumed by the user and whether it is necessary to go to the grocery store, whether and how often the elderly user is watching TV, how often the elderly user is washing clothes, etc. may contain information.

In another implementation, if there is a problem with an electronic device, such as a washing machine, refrigerator, HVAC system, etc., the collected data may include an indication of a part that needs to be replaced. In such a case, a notice may be sent to the technician with a request to resolve the problem. The technician can then arrive home with the necessary replacement parts.

A method according to an embodiment of the present invention is illustrated in FIG. 8 . The method may be implemented within the context of the architectures described above, but is not limited to any particular architecture.

At 801 , an IoT device that is out of range of the IoT hub periodically collects data (eg, opening a refrigerator door, food items used, etc.). At 802 , the IoT device periodically or continuously checks connectivity with the mobile device (eg, using standard local wireless technologies to establish a connection, such as those specified by the BTLE standard). If it is determined at 802 that a connection to the mobile device has been established, then at 803 the collected data is sent to the mobile device at 803 . At 804 , the mobile device sends data to the IoT hub, an external service, and/or a user. As mentioned, the mobile device can transmit data immediately if it is already connected (eg, via a WiFi link).

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

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

At 900 , new program code or data updates are made available on the IoT hub and/or external service (eg, coupled to the mobile device via the Internet). At 901 , the mobile device receives and stores program code or data updates on behalf of the IoT device. The IoT device and/or mobile device periodically checks at 902 to determine if a connection has been established. If it is determined at 903 that a connection has been established, then at 904 updates are sent to and installed on the IoT device.

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 for storing encryption keys used by the embodiments described below. Contains a key store (see, eg, FIGS. 10-15 and related text). Alternatively, the key may be secured in a Subscriber Identity Module (SIM) as discussed below.

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

An embodiment using a public/private key pair will be described first, followed by an embodiment using a symmetric key exchange/encryption technique. In particular, in embodiments 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 configured, its public key is provided to the IoT service 120 , and when a new IoT device 101 is configured, its public key is provided to the IoT hub 110 . ) and IoT service 120 . Various techniques for securely exchanging public keys between devices are described below. In one embodiment, all public keys are signed by a master key known to all receiving devices (ie in the form of a certificate) so that any receiving device can verify the validity of the public key by verifying the signature. Thus, rather than just exchanging the raw public key, these certificates will be exchanged.

As illustrated, in one embodiment, each IoT device 101 , 102 includes a secure key store 1001 , 1003 respectively for securely storing the respective device's private key. The security logic 1002, 1304 then uses the securely stored private key to perform the encryption/decryption operations described herein. Similarly, the IoT hub 110 uses an encryption/decryption operation using the key, as well as a secure storage 1011 for storing the IoT hub private key and the public key of the IoT devices 101 , 102 and the IoT service 120 . security logic 1012 for performing Finally, IoT service 120 uses a secure storage 1021 for securely storing its own private key, public keys of various IoT devices and IoT hubs, and the key to encrypt/encrypt communication with IoT hubs and devices. may include security logic 1013 for decryption. In one embodiment, when the IoT hub 110 receives the public key certificate from the IoT device, the IoT hub may verify it (eg, by verifying the signature using the master key as described above), It can then extract the public key from within it and store the public key in its secure key store 1011 .

For example, in one embodiment, the IoT service 120 sends a command or data (eg, a command to open a door, a request to read a sensor, data to be processed/displayed by the IoT device, etc.) to the IoT device ( When it needs to transmit to 101 , the security logic 1013 uses the public key of the IoT device 101 to encrypt the data/command to generate an encrypted IoT device packet. In one embodiment, the security logic 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, the service 120 signs the encrypted message with its private key or the master key mentioned above, so that the device 101 can verify that it is receiving an unaltered message from a trusted source. . The device 101 may then verify the signature using the private key and/or the public key corresponding to the master key. As mentioned above, a symmetric key exchange/encryption technique may be used instead of public/private key encryption. In these embodiments, rather than privately storing one key and providing the corresponding public key to another device, devices may each be provided with a copy of the same symmetric key used for encryption and used to verify signatures. An example of a symmetric key algorithm is the Advanced Encryption Standard (AES), but the underlying principles of the present invention are not limited to any type of specific symmetric key.

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

Once the symmetric key is exchanged, the symmetric key can be used by each device 101 and IoT hub 110 to encrypt the communication. Similarly, IoT hub 110 and IoT service 120 may perform a secure symmetric key exchange, and then use the exchanged symmetric key to encrypt communication. In one embodiment, a new symmetric key is periodically exchanged between the device 101 and the hub 110 and between the hub 110 and the IoT service 120 . In one embodiment, a new symmetric key is exchanged between device 101 , hub 110 and service 120 using each new communication session (eg, a new key is generated and during each communication session). safely exchanged). In one embodiment, if the security module 1012 in the IoT hub is trusted, the service 120 may negotiate a session key with the hub security module 1312 , which then the security module 1012 for each device 120 . ) and the session key. Messages from service 120 will then be decrypted and verified in hub security module 1012 before being re-encrypted for transmission to device 101 .

In one embodiment, to avoid compromise on the hub security module 1012 , a one-time (permanent) installation key may be negotiated between the device 101 and the service 120 upon installation. When sending a message to device 101, service 120 may first encrypt/MAC with this device installed key and then encrypt/MAC with the hub's session key. Then, the hub 110 will verify and extract the encrypted device blob, and transmit it to the device.

In one embodiment of the present 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 an ever-increasing counter value. Both hub 110 and device 101 will track this value and verify that this value is correct in each successive communication between the devices. The same technology may be implemented between hub 110 and service 120 . Using the counter in this way will make it more difficult to spoof the communication between the respective devices (because the counter value will be incorrect). However, even without this, the shared installation key between the service and the device will prevent network (hub)-wide attacks on all devices.

In one embodiment, when using public/private key encryption, the IoT hub 110 uses its private key to decrypt the IoT hub packet and generates an encrypted IoT device packet, which is sent to the associated IoT device 101 . send The IoT device 101 then decrypts the IoT device packet using its private key to generate commands/data originating from the IoT service 120 . The IoT device may then process the data and/or execute commands. Using symmetric encryption, each device will encrypt and decrypt using a shared symmetric key. In either case, each sending device can also sign the message with its private key, so that the receiving device can verify its authenticity.

A different set of keys may be used to encrypt communications from the IoT device 101 to the IoT hub 110 and to the IoT service 120 . For example, using a public/private key arrangement, in one embodiment, the security logic 1002 on the IoT device 101 is transmitted to the IoT hub 110 using the public key of the IoT hub 110 . Encrypt data packets. The security logic 1012 on the IoT hub 110 may then decrypt the data packet using the IoT hub's private key. Similarly, the security logic 1002 on the IoT device 101 and/or the security logic 1012 on the IoT hub 110 uses the public key of the IoT service 120 to send data packets to the IoT service 120 . (the data packet can then be decrypted by security logic 1013 on IoT service 120 using the service's private key). When 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 certain specific details are set forth in the above description, it should be noted that the basic principles of the present invention may be implemented using a variety of different cryptographic techniques. For example, while some embodiments discussed above use asymmetric public/private key pairs, alternative embodiments provide secure access between various IoT devices 101 , 102 , IoT hub 110 and IoT service 120 . An exchanged symmetric key can be used. Moreover, in some embodiments, rather than the data/command itself being encrypted, a key is used to generate a signature for the data/command (or other data structure). The recipient can then use its key to verify the signature.

11 , in one embodiment, the secure key store on each IoT device 101 is implemented using a programmable subscriber identity module (SIM) 1101 . In this embodiment, the IoT device 101 may initially be presented to the end user along with an unprogrammed SIM card 1101 that sits within the SIM interface 1100 on the IoT device 101 . To program the SIM to have one or more sets of encryption keys, the user takes the programmable SIM card 1101 from the SIM interface 500 and inserts it into the SIM programming interface 1102 on the IoT hub 110 . Then, the programming logic 1125 on the IoT hub securely programs the SIM card 1101 to register/pair the IoT device 101 to the IoT hub 110 and the IoT service 120 . In one embodiment, a public/private key pair may be randomly generated by programming logic 1125 , and then the public key of the pair may be stored in a secure storage device 411 of the IoT hub, while the private key is programmed It may be stored within the capable SIM 1101 . In addition, the programming logic 525 may send the public key of the IoT hub 110 , the IoT service 120 , and/or any other IoT device 101 (outgoing data by the security logic 1302 on the IoT device 101 ). may be stored on the SIM card 1401) to be used to encrypt the Once the SIM 1101 is programmed, the new IoT device 101 is provisioned with the IoT service 120 using the SIM as a security identifier (eg, using existing techniques for registering a device using the SIM). can be After provisioning, both IoT hub 110 and IoT service 120 will securely store a copy of the IoT device's public key to be used when encrypting communication with IoT device 101 .

The techniques described above with respect to FIG. 11 provide tremendous flexibility when providing new IoT devices to end users. Rather than requiring the user to register each SIM directly with a specific service provider at the time of sale/purchase (as is currently done), the SIM can be programmed directly by the end user via the IoT hub 110 and the The results can be securely communicated to the IoT service 120 . As a result, the new IoT device 101 can be sold to an end user online or from a local retailer, and later securely provisioned with the IoT service 120 .

Although registration and encryption techniques are described above in the specific context of a SIM (Subscriber Identification Module), the underlying principles of the present invention are not limited to "SIM" devices. Rather, the basic principles of the present invention may be implemented using any type of device having a secure store for storing a set of cryptographic keys. Also, although the above embodiment includes a mobile SIM device, in one embodiment, the SIM device is not movable, but the IoT device itself may be inserted into the programming interface 1102 on the IoT hub 110 .

In one embodiment, rather than requiring the user to program the SIM (or other device), the SIM is pre-programmed into the IoT device 101 before being distributed to the end user. In this embodiment, when the user sets up the IoT device 101 , the various techniques described herein securely exchange encryption keys between the IoT hub 110 / IoT service 120 and the new IoT device 101 . can be used to

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

In one embodiment, the data contained in the barcode or QR code 1201 is also sent to the user device 135 (eg, an iPhone or Android device) installed with an IoT app or browser-based applet designed by the IoT service provider. can be captured through Once captured, the barcode data may be securely communicated to the IoT service 120 via a secure connection (eg, such as a secure socket layer (SSL) connection). The barcode data may also be provided from the client device 135 to the IoT hub 110 via a secure local connection (eg, via a local WiFi or Bluetooth LE connection).

The security logic 1002 on the IoT device 101 and the security logic 1012 on the IoT hub 110 may be implemented using hardware, software, firmware, or any combination thereof. For example, in one embodiment, the security logic 1002 , 1012 is a chip (eg, a local channel) used to establish a local communication channel 130 between the IoT device 101 and the IoT hub 110 . In case 130 is a Bluetooth LE, it is implemented in a Bluetooth LE chip). Regardless of the specific location of security logic 1002, 1012, in one embodiment, security logic 1002, 1012 is designed to establish a secure execution environment for executing certain types of program code. This may be implemented using, for example, TrustZone technology (available on some ARM processors) and/or Trusted Execution Technology (designed by Intel). Of course, the underlying principles of the present invention are not limited to any particular type of secure implementation technique.

In one embodiment, a barcode or QR code 1501 may be used to pair each IoT device 101 with an IoT hub 110 . For example, rather than using the standard wireless pairing process currently used to pair Bluetooth LE devices, a pairing code embedded within a barcode or QR code 1501 may be used to pair an IoT hub with a corresponding IoT device ( 110) can be provided.

12B illustrates one embodiment in which a barcode reader 206 on an IoT hub 110 captures a barcode/QR code 1201 associated with an IoT device 101 . As mentioned, the barcode/QR code 1201 may be printed directly on the IoT device 101 , or it may be printed on a separate card provided with the IoT device 101 . In either case, barcode reader 206 reads the pairing code from barcode/QR code 1201 and provides the pairing code to local communication module 1280 . In one embodiment, the local communication module 1280 is a Bluetooth LE chip and related software, although the underlying principles of the present invention are not limited to any particular protocol standard. Once the pairing code is received, it is stored in a secure store containing the pairing data 1285 , and the IoT device 101 and IoT hub 110 are automatically paired. Whenever an IoT hub is paired with a new IoT device in this way, pairing data for such pairing is stored in secure storage 685 . In one embodiment, once the local communication module 1280 of the IoT hub 110 receives the pairing code, it may use the code as a key to encrypt communication over the local wireless channel with the IoT device 101 .

Similarly, on the IoT device 101 side, the local communication module 1590 stores pairing data instructing pairing with the IoT hub in the local secure storage device 1595 . Pairing data 1295 may include a pre-programmed pairing code identified in barcode/QR code 1201 . Pairing data 1295 may also be used to encrypt pairing data received from local communication module 1280 on IoT hub 110 (eg, for encrypting communication with IoT hub 110 ) that is necessary to establish a secure local communication channel. additional keys).

Thus, the barcode/QR code 1201 can be used to perform local pairing in a much more secure manner than current wireless pairing protocols because the pairing code is not transmitted over the air. Also, in one embodiment, the same barcode/QR code 1201 used for pairing is used to establish a secure connection from the IoT device 101 to the IoT hub 110 and from the IoT hub 110 to the IoT service 120 . It can be used to identify an encryption key for

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

At 1301 , the user receives a new IoT device with a blank SIM card, and at 1602 , the user inserts the blank SIM card into the IoT hub. At 1303 , the user programs the blank SIM card to have a set of one or more encryption keys. For example, as described above, in one embodiment, the IoT hub may randomly generate a public/private key pair, store the private key on the SIM card and store the public key in its local secure storage. Also, at 1304 , at least the public key is sent to the IoT service, which can be used to identify the IoT device and establish encrypted communication with the IoT device. As noted above, in one embodiment, a programmable device other than a “SIM” card may be used to perform the same functions as a SIM card in the method shown in FIG. 13 .

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

At 1401 , the user receives a new IoT device pre-assigned with an encryption key. At 1402 , the key is securely provided to the IoT hub. As noted above, in one embodiment, this includes reading a barcode associated with the IoT device to identify the public key of the public/private key pair assigned to the device. Barcodes can be read directly by the IoT hub or captured via an app or browser via a mobile device. In an alternative 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 to exchange keys. Regardless of how the key is transmitted, once received, it is stored in the IoT hub device's secure key store. As noted above, various secure enforcement technologies such as Secure Enclave, Trusted Execution Technology (TXT) and/or TrustZone may be used on the IoT hub to store and protect keys. Also, at 803 , the key is securely sent to the IoT service, which stores the key in its own secure key store. The IoT service may then use the key to encrypt communication with the IoT device. Once again, the exchange can be implemented using a certificate/signed key. It is particularly important to prevent alteration/addition/removal of stored keys within the hub 110 .

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

At 1501 , the IoT service encrypts data/commands using the IoT device public key to generate an IoT device packet. It then encrypts the IoT device packet using the IoT hub's public key to create an IoT hub packet (eg, creating an IoT hub wrapper around the IoT device packet). At 1502 , the IoT service sends an IoT hub packet to the IoT hub. At 1503 , the IoT hub uses the private key of the IoT hub to decrypt the IoT hub packet to generate an IoT device packet. At 1504 , it then sends the IoT device packet to the IoT device, which at 1505 decrypts the IoT device packet using the IoT device private key to generate data/commands. At 1506 , the IoT device processes data/commands.

In embodiments using symmetric keys, symmetric key exchange may be negotiated between respective devices (eg, between each device and hub and between hub and service). Once the key exchange is complete, each sending device encrypts and/or signs each transmission using the symmetric key before sending the data to the receiving device.

Apparatus and method for establishing a secure communication channel in an Internet of Things (IoT) system

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

Referring first to FIG. 16A , in order to encrypt/decrypt communication between the IoT device 101 and the IoT service 120 , the IoT service 120 includes an encryption engine that manages a set of “service session keys” 1650 ( 1660 , and each IoT device 101 includes a cryptographic engine 1661 that manages a set of “device session keys” 1651 . Cryptographic engines provide hardware security modules 1630, 1631 for generating (among other things) a session public/private key pair and preventing access to the private session key of the pair when performing the security/encryption techniques described herein. ) and key stream generation modules 1640 and 1641 for generating a key stream using the derived secret. In one embodiment, service session keys 1650 and device session keys 1651 include associated public/private key pairs. For example, in one embodiment, the device session keys 1651 on the IoT device 101 include a public key of the IoT service 120 and a private key of the IoT device 101 . As discussed in detail below, in one embodiment, to establish a secure communication session, the public/private session key pairs 1650 and 1651 have the same secret by their respective encryption engines 1660 and 1661, respectively. This same secret is then used by SKGMs 1640 , 1641 to generate a key stream for encrypting and decrypting communication between IoT service 120 and IoT device 101 . Additional details relating to the creation and use of secrets in accordance with one embodiment of the present invention are provided below.

In FIG. 16A , once the secret is created using keys 1650 and 1651 , the client always connects to the IoT device 101 via the IoT service 120 , as indicated by the Clear transaction 1611 . messages will be sent. "Clear" as used herein is intended to indicate that the underlying message is not encrypted using the encryption techniques described herein. However, as illustrated, in one embodiment, a Secure Sockets Layer (SSL) channel or other secure channel (eg, Internet Protocol security IPSEC) channel) is established. Then, at 1602 , the encryption engine 1660 on the IoT service 120 encrypts the message using the generated secret and sends the encrypted message to the IoT hub 110 . Rather than directly encrypting the message using the secret, in one embodiment, the secret and counter values are used to generate a key stream that is used to encrypt each message packet. Details of this embodiment are described below with respect to FIG. 17 .

As illustrated, an SSL connection or other secure channel may be established between the IoT service 120 and the IoT hub 110 . At 1603 , the IoT hub 110 (which in one embodiment does not have the ability to decrypt the message) transmits the encrypted message to the IoT device (eg, via a Bluetooth Low Energy (BTLE) communication channel). The encryption engine 1661 on the IoT device 101 can then use the secret to decrypt the message and process the message content. In an embodiment where the secret is used to generate the key stream, the encryption engine 1661 may use the secret and counter value to generate the key stream and then use the key stream to decrypt the message packet.

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 instructing the IoT device 101 to perform a specific function, such as taking a measurement and reporting the result back to the client device 611 , or It may contain configuration data that constitutes an operation.

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

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 involves the client device 611 (eg, as in the embodiments described above with respect to FIGS. 6-9B ). happens through In this embodiment, to send the message to the IoT device 101 , the client device 611 sends an unencrypted version of the message to the IoT service 120 at 1611 . The encryption engine 1660 encrypts the message using the secret or derived key stream at 1612 and sends the encrypted message back to the client device 611 . Then, the client device 611 sends the encrypted message to the IoT device 101 at 1613 , and the encryption engine 1661 decrypts the message using the secret or derived key stream. The IoT device 101 may then process the message as described herein. If a response is requested, the encryption engine 1661 encrypts the response using the secret at 1614 and sends the encrypted response to the client device 611 , which at 1615 sends the encrypted response to the IoT service 120 . send to Then, at 1616 , the encryption engine 1660 decrypts the response and sends the decrypted response to the client device 611 .

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

In one embodiment, the encryption engine 1660 of the IoT service 120 may be (eg, such as CloudHSM provided by Amazon) to generate a session public/private key pair. ) transmits a command to the HSM 1630 . HSM 1630 may subsequently prevent access to the pair's private session key. Similarly, the encryption engine on the IoT device 101 generates a session public/private key pair and prevents access to the pair's session private key (eg, with the Atecc508 HSM from Atmel Corporation) same) to the HSM 1631 . Of course, the basic principles of the present invention are not limited to any particular type of encryption engine or manufacturer.

In one embodiment, at 1701 , IoT service 120 sends its session public key generated using HSM 1630 to IoT device 101 . The IoT device generates its own session public/private key pair using its HSM 1631 , and sends the public key of its pair to the IoT service 120 at 1702 . In one embodiment, cryptographic engines 1660 and 1661 use the Elliptic Curve Diffie-Hellman (ECDH) protocol, an anonymous key agreement that allows two parties with an elliptic curve public-private key pair to 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 uses the IoT service 120 session public key and its own session private key to independently generate the same secret. More specifically, in one embodiment, the encryption engine 1660 on the IoT service 120 generates the secret according to the formula 'secret = IoT device session public key * IoT service session private key', where '*' is the IoT This means that the device session public key is point multiplied with the IoT service session private key. The encryption engine 1661 on the IoT device 101 generates the secret according to the formula 'secret = IoT service session public key * IoT device session private key', where the IoT service session public key is point multiplied by the IoT device session private key. . Finally, IoT service 120 and IoT device 101 have both created the same secret that will be used to encrypt the communication as described below. In one embodiment, encryption engines 1660 and 1661 rely on a hardware module, such as KSGMs 1640 and 1641, respectively, to perform the above operations for generating a secret.

Once the secret is determined, it can be used to directly encrypt and decrypt the data by the encryption engines 1660, 1661. Alternatively, in one embodiment, the encryption engines 1660, 1661 use the secret to generate a new key stream to encrypt/decrypt each data packet (ie, the new key stream data structure is generated for ) sends a command to the KSGMs 1640 and 1641 . In particular, one embodiment of the key stream generation module 1640, 1641 implements GCM (Galois/Counter Mode), in which the counter value is incremented for each data packet, and the secret and used in combination. Thus, in order to transmit a data packet to the IoT service 120 , the encryption engine 1661 of the IoT device 101 uses the secret and current counter value to generate a new key stream for the KSGMs 1640 and 1641 and then It causes the counter value to be incremented to generate the key stream. The newly generated key stream is then used to encrypt the data packet before being sent to the IoT service 120 . In one embodiment, the key stream is XORed with the data to produce an encrypted data packet. In one embodiment, the IoT device 101 transmits the counter value to the IoT service 120 along with the encrypted data packet. The encryption engine 1660 on the IoT service then communicates with the KSGM 1640, which uses the received counter value and secret to generate a key stream (which should be the same key stream since the same secret and counter value are used). It generates and decrypts the data packet using the generated key stream.

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

In one embodiment, each encryption engine 1660, 1661 records the last counter value it receives from the other, and detects whether counter values are received out of sequence or the same counter value is received more than once. sequencing logic to If the counter values are 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 crypto engines 1660 and 1661 may disconnect from the communication channel and/or generate a security alert.

18 illustrates an exemplary encrypted data packet used in one embodiment of the present invention comprising 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 to verify the decrypted data (once decrypted).

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

An embodiment of the present invention implements additional techniques for authenticating sessions between the IoT service 120 and the IoT device 101 . In particular, in one embodiment, a hierarchy of public/private key pairs is used that includes a master 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 master key pair contains the root of trust for all other key pairs and is maintained in a single, highly secure location (eg, under the control of the organization implementing the IoT systems described herein). . The master private key can be used to generate (and thereby authenticate) signatures through various other key pairs, such as factory key pairs. The signatures 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 that can be subsequently used to authenticate IoT service keys and IoT device keys. For example, in one embodiment, the factory private key is used to generate a signature via the IoT service public keys and the IoT device public keys. This signature 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 and 16B . While the session public/private keys described above are temporary (ie generated for a service/device session), IoT service/device key pairs are permanent (ie factory generated).

With the above-mentioned relationships between master keys, factory keys, and service/device keys in mind, one embodiment of the present invention performs the following operations to provide authentication and security between IoT service 120 and IoT device 101. It provides additional layers:

A. In one embodiment, IoT service 120 initially generates a message comprising:

1. Unique ID of IoT service:

IoT 서비스의 일련번호;

the serial number of the IoT service;

타임스탬프;

timestamp;

이 고유 ID에 서명하는 데 사용되는 공장 키의 ID;

ID of the factory key used to sign this unique ID;

고유 ID의 클래스(즉, 서비스);

class of unique id (ie service);

IoT 서비스의 공개 키

Public key of IoT service

고유 ID를 통한 서명.

Signature via unique ID.

2. Factory certificate including:

타임스탬프

timestamp

인증서에 서명하는 데 사용되는 마스터 키의 ID

ID of the master key used to sign the certificate

공장 공개 키

factory public key

공장 인증서의 서명

Signing of the factory certificate

3. IoT service session public key (as described above with respect to FIGS. 16A and 16B)

4. Sign the IoT service session public key (i.e. signed with the IoT service's private key)

B. In one embodiment, the message is sent to the IoT device on a negotiation channel (described below). The IoT device analyzes the message and:

1. Verifies the signature of the factory certificate (only if present in the message payload)

2. Validate the signature of the unique ID using the key identified by the unique ID

3. Validate the IoT service session public key signature using the IoT service's public key from the unique ID

4. Store the IoT service's public key as well as the IoT service's session public key

5. Create an IoT device session key pair.

C. The IoT device then generates a message comprising:

1. Unique ID of IoT device

IoT 디바이스 일련번호

IoT device serial number

타임스탬프

timestamp

이 고유 ID에 서명하는 데 사용되는 공장 키의 ID

ID of the factory key used to sign this unique ID

고유 ID의 클래스(즉, IoT 디바이스)

Class of Unique ID (i.e. IoT Device)

IoT 디바이스의 공개 키

IoT device public key

고유 ID의 서명

Signature of unique ID

2. Session public key of IoT device

3. Signature of (IoT device session public key + IoT service session public key) signed with the IoT device's key

D. This message is sent back to the IoT service. The IoT service analyzes the message and:

1. Validate the signature of the unique ID using the factory public key

2. Validate the signature of the session public keys using the IoT device's public key

3. Store the session public key of the IoT device

E. The IoT service then generates a message containing the signature of (IoT device session public key + IoT service session public key) signed with the IoT service key.

F. The IoT device parses the message and:

1. Validate the signature of the session public keys using the public key of the IoT service

2. Generate a key stream from the IoT device session private key and the IoT service session public key

3. The IoT device then sends a “messaging available” message.

G. The IoT service then:

1. Generate a key stream from the IoT service session private key and the IoT device's session public key

2. Create a new message on a messaging channel that includes:

난수 2 바이트 값을 생성하고 저장한다

Generate and store a random 2-byte value

(아래에 논의되는) 부메랑 속성 Id 및 난수 값을 갖는 속성 메시지를 설정한다

Sets a Boomerang Attribute Id (discussed below) and an attribute message with a random value.

H. The IoT device receives the message:

1. Attempts to decipher the message

2. Emit an update with the same value for the indicated attribute Id

I. The IoT service recognizes that the message payload contains a boomerang attribute update:

1. set its paired state to true

2. Send a pairing complete message on the negotiator channel

J. The IoT device receives the message and sets its paired state to true

While the above techniques are described in the context of "IoT service" and "IoT device", the basic principles of the present invention are to establish a secure communication channel between any two devices, including user client devices, servers and internet services. can be implemented.

The above techniques are very secure because the private keys are never shared over the air (as opposed to current Bluetooth pairing techniques where the secret is transmitted from one party to the other). An attacker listening to the entire conversation will have only insufficient public keys to create a shared secret. These techniques also prevent man-in-the-middle attacks by exchanging signed public keys. Also, because GCM and separate counters are used on each device, any kind of "replay attack" (the man-in-the-middle captures the data and sends it back) is prevented. Some embodiments also prevent replay attacks by using asymmetric counters.

Techniques 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 uses a generic data protocol called the Attribute Protocol (ATT), which is used to store services, properties and related data in a simple lookup table using 16-bit property IDs for each entry in the table. . Note that “properties” are sometimes referred to as “properties”.

On Bluetooth devices, the most commonly used characteristic is the device "name" (with characteristic ID 10752 (0x2A00)). For example, a Bluetooth device can identify other Bluetooth devices in its vicinity by using GATT to read the “name” characteristic published by those other Bluetooth devices. Thus, Bluetooth devices have the intrinsic ability to exchange data without formally pairing/bonding the devices ("pairing" and "bonding" are sometimes used interchangeably; the remainder of this discussion will use the term "" Note that we will use "pairing").

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

19 illustrates one specific embodiment in which a Bluetooth (BT) device 1910 establishes a network socket abstraction with a BT communication module 1901 of an IoT device 101 without formally establishing a paired BT connection. . The BT device 1910 may 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 list of feature IDs, names associated with those feature IDs, and values for those feature IDs. The value for each characteristic may be stored in a 20 byte buffer identified by a characteristic ID according to the current BT standard. However, the basic principles of the present invention are not limited to any particular buffer size.

In the example of FIG. 19 , the “Name” characteristic is a BT defined characteristic that is assigned a specific value of “IoT Device 14”. An embodiment of the present invention specifies a first set of additional characteristics to be used for negotiating a secure communication channel with the BT device 1910 and a second set of additional characteristics to be used for encrypted communication with the BT device 1910 . In particular, in the illustrated example the "Write Negotiation" characteristic identified by characteristic ID <65532> may be used to send outgoing negotiation messages, and the "Read Negotiation" characteristic identified by characteristic ID <65533> is an incoming negotiation message can be used to receive “Negotiation messages” may include messages used by the BT device 1910 and the BT communication module 1901 to establish a secure communication channel as described herein. As an example, in FIG. 17 , the IoT device 101 may receive the IoT service session public key 1701 via the “Read Negotiation” characteristic. The key 1701 may be transmitted from the IoT service 120 to the BTLE-enabled IoT hub 110 or client device 611 , which in turn may be sent to the BTLE-enabled IoT hub 110 or client device 611 by the GATT can be used to write the key 1701 to the negotiated read value buffer identified by the characteristic ID <65533>. IoT device application logic 1902 may then read key 1701 from the value buffer identified by property ID <65533> and process it as described above (eg, use it to create a secret, and to create a keystream, etc.).

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

In one embodiment, once a secure communication channel is established, a characteristic ID (for sending encrypted data packets from the IoT device 101) and a characteristic (for receiving data packets encrypted by the IoT device) A second network socket abstraction is established using ID <65533>. That is, when the BT communication module 1903 has an encrypted data packet to transmit (such as encrypted message 1603 in FIG. 16A ), it uses the message read value buffer identified by the characteristic ID <65533>. to start writing the encrypted data packets 20 bytes at a time. The IoT device application logic 1902 then reads the encrypted data packet from the read value buffer 20 bytes at a time, BT acknowledgment messages as needed through the write value buffer identified by the characteristic ID <65532>. to the communication module 1903 .

In one embodiment, the commands of GET, SET and UPDATE described below are used to exchange data and commands between the two BT communication modules 1901 and 1903. For example, the BT communication module 1903 identifies the characteristic ID <65533> and writes it into a value field/buffer identified by the characteristic ID <65533> that can be subsequently read by the IoT device application logic 1902 . A packet including a SET command to be performed may be transmitted. To retrieve 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 property ID <65534>. In response to the GET command, the BT communication module 1901 may send an UPDATE packet containing data from the value field/buffer identified by the property ID <65534> to the BT communication module 1903 . In addition, UPDATE packets may be automatically transmitted in response to changes of a specific attribute on the IoT device 101 . For example, when an IoT device is associated with a lighting system and a user turns on a illuminator, an UPDATE packet may be sent to reflect a change to an on/off attribute related to a lighting application.

20 illustrates exemplary packet formats used for GET, SET and UPDATE in accordance with an embodiment of the present invention. In one embodiment, these packets are transmitted over the Write Message <65534> and Read Message <65533> channels following the negotiation. In the GET packet 2001, the first 1-byte field contains a value (0X10) that identifies the packet as a GET packet. The second one byte field contains a request ID that uniquely identifies the current GET command (ie, identifies the current transaction to which the GET command relates). For example, each instance of a GET command sent from a service or device may be assigned a different request ID. This can be done, for example, by incrementing the counter and using the counter value as the request ID. However, the basic principles of the present invention are not limited to any particular manner for establishing a request ID.

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

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

An UPDATE packet 2003 may be sent to provide an update of the results of the SET command. UPDATE packet 2003 includes a 2-byte length value field for identifying the length of an n-byte value data field that may contain data related to the results of the SET command. In addition, the 1-byte update status field may identify the current status of the variable being updated. For example, if the SET command attempted to turn off a illuminator controlled by the IoT device, the update status field may indicate whether the illuminator was successfully turned off.

21 illustrates an example transaction sequence between IoT service 120 and IoT device 101 including SET and UPDATE commands. Intermediary devices such as an IoT hub and a user's mobile device are not shown in order to avoid obscuring the basic principles of the present invention. At 2101 , the SET command 2101 is transmitted from the IoT service to the IoT device 101 and received by the BT communication module 1901 , which in response thereto at 2102 , a GATT value buffer identified by the characteristic ID. update The SET command is read from the value buffer at 2103 by a low power microcontroller (MCU) 200 (or by program code executing on a low power MCU, such as IoT device application logic 1902 shown in FIG. 19 ). At 2104 , the MCU 200 or program code performs an operation in response to the SET command. For example, the SET command may include an attribute ID that specifies a new configuration parameter, such as a new temperature, or may include a state value such as on/off (to put the IoT device into an “on” or low-power state). can Thus, at 2104 , the new value is set in the IoT device, the UPDATE command is returned at 2105 , and at 2106 the actual value is updated in the GATT value field. In some cases, the actual value will be equal to the desired value. In other cases, the updated value may be different (ie, this is because 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 .

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 within the context of the network architectures 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 Elliptic Curve Digital Signature Algorithm (ECDSA) certificates. At 2202 , the IoT service encrypts the data/command in the IoT device packets using the session secret to generate an encrypted device packet. As mentioned above, the session secret may be independently generated by the IoT device and IoT service. 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 forwards 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, in one embodiment, this may be accomplished by generating a key stream using the secret and counter values (provided with the encrypted device packet) and then decrypting the packet using the key stream. Subsequently, at 2206 , the IoT device extracts and processes data and/or commands included in the device packet.

Thus, using the above techniques, a bidirectional secure network socket abstraction can be established between two BT enabled devices, without formally pairing the BT devices using standard pairing techniques. Although these techniques are described above with respect to an IoT device 101 communicating with an 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. have.

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

At 2301, the IoT service generates a packet including the serial number and public key of the IoT service. At 2302 , the IoT service signs the packet using the factory private key. At 2303 , the IoT service sends the packet to the IoT hub via the encrypted channel, and at 2304 , the IoT hub sends 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 including the IoT device's serial number and public key. At 2307 , the IoT device signs the packet using the factory private key, and at 2308 , the IoT device sends the packet to the IoT hub over an unencrypted channel.

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

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

At 2322, the IoT service verifies the signature of the packet (eg, using the IoT device public key), and at 2323 the IoT service uses the IoT service private key and the IoT device public key (as detailed above) for the session create a secret At 2324, the IoT device generates a session secret using the IoT device private key and the IoT service public key (also as described above), and at 2325 the IoT device generates a random number and encrypts it using the session secret. At 2326 , the IoT service sends the encrypted packet to the IoT hub via the encrypted channel. At 2327 , the IoT hub sends the encrypted packet to the IoT device over the unencrypted channel. At 2328 , the IoT device decrypts the packet using the session secret.

Referring to FIG. 23C , the IoT device re-encrypts the packet using the session secret at 2329 , and the IoT device transmits the encrypted packet to the IoT hub through an unencrypted channel at 2330 . At 2331 , the IoT hub sends the encrypted packet to the IoT service through the encrypted channel. The IoT service decrypts the packet using the session secret at 2332. At 2333, the IoT service verifies that the random number matches the random number it sent. The IoT service then sends a packet indicating that pairing is complete at 2334, and at 2335 all subsequent messages are encrypted using the session secret.

Apparatus and method for modifying packet interval timing to identify data transmission conditions

A Bluetooth Low Energy (BTLE) device sends advertisement packets separated by “advertising intervals” to establish a connection between the devices. A BTLE peripheral device broadcasts an advertisement packet to all nearby devices using the advertisement interval. The receiving BTLE device can then act on this information or connect to receive more information.

The 2.4 GHz spectrum for BTLE spans 2402 MHz to 2480 MHz and uses 40 1 MHz wide channels numbered 0 to 39. Each channel is separated by 2 MHz. Channels 37, 38 and 39 are only used to transmit advertisement packets. The remainder is used for data exchange during the connection. During a BTLE advertisement, the BTLE peripheral device transmits packets in turn on three advertisement channels. The device or central device scanning the beacon will listen to those channels for advertisement packets, which helps it discover nearby devices. Channels 37, 38, 39 are intentionally spread across the 2.4 GHz spectrum (ie, channels 37, 39 are the first and last channels in the band, and channel 38 is in the middle). If any single advertising channel is blocked, the other channels are likely to be free because they are separated by a bandwidth of several MHz.

When an IoT device has data to be transmitted, it will typically include a flag as part of its advertisement packet to indicate that the data is ready to be transmitted. In one embodiment of the present invention, rather than using this flag, the IoT device adjusts the advertisement interval to indicate that it has pending data. For example, if T is the time between advertisement packets when data is not pending, a different advertisement interval such as 0.75T, 0.5T or 1.25T may be selected to indicate that data is pending. In one embodiment, the two different intervals are programmable based on the specific needs of the application and make it more difficult to determine which interval means which state.

24 illustrates an embodiment of an IoT device 101 that includes ad interval selection logic 2411 in which the BTLE communication interface 2410 adjusts an advertisement interval when data is ready to be transmitted. In addition, the BTLE communication interface 2420 on the IoT hub 110 includes ad interval detection logic 2421 that detects a change in the advertisement interval, provides an acknowledgment, and receives the data.

In particular, in the illustrated embodiment, application 2401 on IoT device 101 indicates that it has data to be transmitted. In response, the advertisement interval selection logic 2411 modifies the advertisement interval to notify the IoT hub 110 that data will be sent (eg, changes the interval to .75T or some other value). When the ad interval detection logic 2421 detects a change, the BTLE communication interface 2420 connects to the BTLE communication interface 2410 of the IoT device 101 to indicate that it is ready to receive data. Then, the BTLE communication interface 2410 of the IoT device 101 transmits data to the BTLE communication interface 2420 of the IoT hub. The IoT hub may then pass the data to the IoT service 120 and/or the user's client device (not shown). After the data is transmitted, the ad interval selection logic 2411 may then return to the normal ad interval (eg, AI=T).

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

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

At 2500 , the IoT device uses a standard advertisement interval (eg, separated by time T) when generating the advertisement packet. The IoT device maintains the standard advertisement interval at 2502 until there is data to transmit, as determined at 2501 . Then, at 2503 , the IoT device switches the advertisement interval to indicate that there is data to transmit. At 2504 , the IoT hub or other network device establishes a connection with the IoT device, thereby enabling the IoT device to transmit its data. Finally, at 2505, the IoT device sends its pending data to the IoT hub.

It should be noted that although ad spacing techniques are described herein within the context of the BTLE protocol, the underlying principles of the present invention are not limited to BTLE. Indeed, the basic principles of the present invention may be implemented on any system that selects an advertisement interval for establishing wireless communication between devices.

Further, although a dedicated IoT hub 110 is illustrated in many of the embodiments above, a dedicated IoT hub hardware platform is not required to comply with the basic principles of the present invention. For example, the various IoT hubs described above may be implemented as software running within various other networking devices such as iPhone® and Android® devices. In practice, the IoT hub discussed above communicates with IoT devices (e.g., using BTLE or other local wireless protocols) and establishes a connection over the Internet (e.g., to an IoT service using WiFi or cellular data connection). It can be implemented on any device capable of

A system and method for reducing wireless traffic when connecting an IoT hub to an IoT device

When multiple IoT hubs are configured at a particular location, a single IoT device may have the ability to connect with each IoT hub within range. As mentioned, an IoT device may use an advertisement channel to notify any IoT hubs within a “connectable” range so that the IoT hub can be connected to it to send commands and/or data. When multiple IoT hubs are within range of an IoT device, the IoT service may attempt to transmit commands/data addressed to the IoT device via each of these IoT hubs, thereby wasting wireless bandwidth and reducing performance. eg due to interference due to multiple transmissions).

To solve this problem, one embodiment of the present invention implements a technique to ensure that when a particular IoT hub is successfully connected to an IoT device, other IoT hubs will be notified to stop attempting to transmit commands/data. This embodiment will be described with respect to FIGS. 26A-26C , which show an exemplary set of IoT hubs 110 - 112 all within the scope of IoT device 101 . As a result, the secure wireless communication module 2610 of the IoT device 101 may see and connect to the secure wireless communication modules 2650 to 2652 of the IoT hubs 110 to 112 , respectively. In one embodiment, the secure wireless communication module includes the secure BTLE module described above. However, the basic principles of the present invention are not limited to any particular wireless standard.

As illustrated in FIG. 26A , in one embodiment, the secure wireless communication module 2610 of the IoT device 101 is “connectable” to it (ie, can be connected to it by any device within range). and advertisement control logic 2610 that periodically transmits an advertisement beacon indicating that to nearby wireless communication devices. Then, any IoT hubs 110 to 112 that receive the advertisement beacon recognize the IoT device 101, and the secure wireless communication modules 2650 to 2652 send the command/data to the IoT device 101 by the IoT service. ) can connect to the secure wireless communication module 2610 of the IoT device 101 .

As illustrated in FIG. 26B , in one embodiment, when the IoT service has data/command for the IoT device 101, the IoT service sends the data/command to all of the IoT hubs 110 to 112 within a specific location ( For example, any IoT hub associated with the user's account and/or within range of the IoT device 101 ). As illustrated, each of the IoT hubs 110 - 112 may then attempt to connect with the IoT device 101 to provide commands/data.

26C , in one embodiment, only a single IoT hub 111 will successfully connect to the IoT device 101 and provide commands/data for processing by the IoT device 101 . In certain wireless communication protocols, such as BTLE, secure wireless communication module 2610 will stop sending advertisement beacons once a connection is established. As such, the other IoT hubs 110 , 112 will have no way of knowing that the IoT device 101 has successfully received data from the IoT hub 111 , and will continue to attempt to transmit commands/data. , thus consuming radio bandwidth and creating interference.

To solve this limitation, one embodiment of the secure wireless communication module 2610, when detecting a successful connection with the secure wireless communication module 2651 of the IoT hub 111, the advertisement control module 2612 and a connection manager 2611 to keep sending beacons. However, instead of indicating that the IoT device 101 is “connectable”, the new advertisement beacon indicates that the IoT device 101 is “not accessible”. In one embodiment, in response to the “not accessible” indication, the secure wireless communication modules 2650 , 2652 of the IoT hubs 110 , 112 stop attempting to transmit a command/data to the IoT device by It will reduce unnecessary wireless traffic.

The above techniques provide an excellent solution to undesirable wireless traffic using techniques that can be easily implemented in addition to existing wireless protocols. For example, in one embodiment, "accessible" and "not accessible" indications are implemented within the context of the BTLE standard. However, as mentioned, the basic principles of the present invention may be implemented using a variety of different wireless network protocols.

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

At 2701 , commands and/or data are transmitted from the IoT service via the two or more IoT hubs. For example, the user may be attempting to control the IoT device through an app on the user's mobile device connected to the IoT service. At 2702 , the IoT hub attempts to connect to the IoT device and one of the IoT hubs successfully connects and provides commands/data to the IoT device. As mentioned, an IoT hub may recognize an IoT device as a result of the IoT device sending a “connectable” indication in an advertisement beacon.

At 2703 , in response to the successful connection, the IoT device begins transmitting a “not accessible” advertisement beacon, thereby notifying any IoT hub in range that the IoT device is no longer accessible. At 2704 , upon receiving the “not accessible” beacon, the other IoT hub stops attempting to transmit commands/data to the IoT device.

Systems and Methods for Provisioning Secure Internet of Things (IoT) Devices

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

One security issue with this implementation is that, since barcode/QR code data can be transmitted without encryption, it can compromise the system by sniffing the wireless transmission of the device ID, so that another user can change the device ID to their own. It allows you to associate it with an account.

In one embodiment, to solve this problem, an "associated ID" is associated with each device ID and used during the provisioning process to ensure that the device ID is never explicitly transmitted. As illustrated in FIG. 28 , in this embodiment, the associated ID 2812 is included in the barcode/QR code printed on the IoT device 101 while the device ID 2811 is located within the secure wireless communication module 2810 . It remains secure, which implements the techniques described above to ensure secure communication with the IoT service 120 . In one embodiment, the associated ID 2812 is an 8 byte ID, such as a device ID, and is unique per IoT device. When a new IoT device 101 is provisioned into the system, the user scans the barcode/QR code containing the associated ID 2812 using the user device 135 on which the IoT app or application is installed. Alternatively, or additionally, the IoT hub 110 may be used to capture a barcode/QR code including an associated ID.

In either case, the associated ID is sent to the device provisioning module 2850 on the IoT service 120 that performs a search in the device database 2851 containing the association between each associated ID and each device ID. The device provisioning module 2850 uses the associated ID 2812 to identify the device ID 2811 , and then uses the device ID to provision a new IoT device 101 in the system. In particular, when the device ID is determined from the device database 2851 , the device provisioning module 2850 uses the device ID 2811 to issue a command for authorizing the IoT hub 110 to communicate with the IoT device 101 to the IoT hub ( 110 ) (which may include user device 135 ).

In one embodiment, the associated ID 2812 is generated at the factory when the IoT device 101 is manufactured (ie, when the secure wireless communication module 2810 is provisioned). Both the device ID 2811 and the associated ID 2812 may then be provided to the IoT service and stored in the device database 2851 . As illustrated, the device database 2851 may include an indication specifying whether each device has been provisioned. As an example, this may be a binary value having a first value (eg, 1) indicating that the IoT device 101 is provisioned and a second value (eg, 0) indicating that the IoT device is not provisioned. When the system provisions/registers the IoT device 101 , the device ID can be used because the communication between the IoT service 120 and the IoT device 101 is protected using the security techniques described above.

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

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

At 2901 , an association is created between the device ID and the associated ID of the IoT device (eg, in a factory where the IoT device is manufactured). The associated ID may be embedded within the barcode/QR code stamped on the IoT device. At 2902 , the association between the device ID and the associated ID is stored on the IoT service. At 2903 , the user purchases a new IoT device and scans the barcode/QR code including the associated ID (eg, via the user's mobile device with the app or application installed or via an IoT hub with a barcode reader).

At 2904 , the associated ID is sent to the IoT service, and at 2905 , the associated ID is used to identify the device ID. At 2906 , the IoT device is provisioned using the device ID. For example, the IoT device database may be updated to indicate that this particular device ID has been provisioned and the IoT service may communicate the device ID to the IoT hub, instructing the IoT hub to communicate with the new IoT device.

Systems and methods for performing flow control in Internet of Things (IoT) systems

Local wireless network traffic will increase based on the number of IoT devices in a given location. Also, in some cases, the IoT device may be transmitting more data than is reasonable given the function being performed by the IoT device. For example, software/hardware on the IoT device may malfunction, or the IoT device may be hacked, causing the IoT device to continue to transmit unnecessary data to the IoT service.

An embodiment of the present invention solves this problem by effectively ignoring data traffic by performing flow control in the IoT hub when a specified data threshold is reached by a specific IoT device. In one embodiment, each IoT device is configured with a designated set of flow control parameters that dictate the amount of data over a period of time the IoT device is allowed to transmit. The flow control parameters may be based on the type of IoT device. For example, certain IoT devices, such as door locks and thermostats, typically only need to periodically transmit short packets of data, while other IoT devices, such as video cameras, potentially transmit significantly larger amounts of data in a non-periodic manner. can send Accordingly, the flow control parameters can be set to provide a sufficient amount of bandwidth based on the expected behavior of the IoT device in question. In one embodiment, each IoT device is assigned to a specific flow control “class” based on that IoT device's data needs.

As such an embodiment is illustrated in FIG. 30 , it shows a plurality of IoT devices 101 to 103 having secure wireless communication modules 2810 , 3030 , 3040 configured with different sets of flow control parameters 3015 , 3031 , 3041 respectively. show In one embodiment, the flow control parameters specify the amount and/or frequency of data that each IoT device is expected to transmit over a specified time period (eg, 25 Mbytes/hour, 50 Mbytes/hour, 100 Mbyte/day, 10 communication attempts/day, etc.). In one embodiment, the flow control parameters 3015 , 3031 , 3041 are, as illustrated, a device management module 3021 that manages a set of device-specific flow control parameters 3020 in the IoT device database 2851 . It may be designated by the IoT service 120 including For example, when a data transmission request for each IoT device is determined, the device-specific flow control parameters 3020 may be updated to reflect the request.

As noted, in one embodiment, the device database 2851 contains data transfer requests for a plurality of different flow control “classes” (eg, audiovisual devices, temperature devices, control devices, security devices, etc.). . When a new IoT device is introduced into the system, it is associated with a specific flow control class based on the needs of the IoT device and/or the type of IoT device.

The device-specific flow control parameters 3020 may be distributed to the IoT hub 110 that includes flow control management logic 2811 that stores a copy of the device-specific flow control parameters 3010 in a local database. In one embodiment, flow control management 2811 may monitor the amount of data traffic received from and/or transmitted to each IoT device 101 - 103 . When the amount of data traffic reaches a specified threshold (as indicated by the per-device flow control parameters 3010 ), the IoT hub 110 may instruct the IoT device to stop transmitting for a period of time and/or You can simply block traffic from IoT devices.

If a specific IoT device is transmitting/receiving at a level higher than a specified threshold, this may indicate that the IoT device is malfunctioning. As such, in one embodiment, the IoT service 120 may send a command to reset the IoT device. If the device is still communicating at a level higher than the threshold, the IoT service 120 may send a software update, such as a patch, to the IoT device. When the updated software is installed, the IoT device is reset and initialized with the new software. Also, a notification may be sent from the IoT service to the user device to inform the user that the IoT device is malfunctioning.

In one embodiment, IoT hub 110 may allow certain types of data traffic despite the fact that a data communication threshold has been reached. For example, in one embodiment, the IoT hub 110 will allow some type of “high priority” notification even if the IoT device has reached its threshold. For example, if the IoT device is a door lock or door entry detector, under certain conditions (eg, when a house is being monitored), the IoT hub 110 indicates that someone has opened the door on which the IoT device is being used. data can be passed through. Similarly, if the IoT device is a heat and/or smoke detector, the IoT hub 110 may pass data indicating an alarm condition (eg, because the temperature has reached a threshold value). Various other types of “high priority” notifications (eg, such as representing potentially hazardous conditions) may be passed by the IoT hub 110 regardless of the current flow control state. In one embodiment, these “high priority” notifications are identified using different attributes as described below.

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

At 3101 , flow control parameters are specified for each IoT device. In one embodiment, an IoT device may be assigned to a particular IoT device “class” having a specified set of flow control parameters associated with it. At 3102 , the flow control parameters are stored on an IoT hub in the IoT system. In one embodiment, each hub may store a subset of all IoT device parameters (eg, only those parameters for locally provisioned IoT devices).

If the IoT hub detects that a particular IoT device is operating outside the specified flow control parameters determined at 3103 , at 3104 the IoT hub will temporarily inhibit further communication with the IoT device (eg, the IoT device and the IoT blocking communication between services). Also, as mentioned, the IoT service and/or IoT hub may take action to solve the problem by rebooting the IoT device and/or installing a software update on the IoT device.

Systems and methods for managing Internet of Things (IOT) devices and traffic using attribute classes

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

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

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

In one embodiment, system properties 3211 are used to define operational and configuration properties for IoT device 101 and IoT system. For example, system properties may include network configuration settings (such as the flow control parameters discussed above), device ID, software version, advertisement interval selection, security implementation features (described above), and IoT service by IoT device 101 It may contain various other low-level variables necessary to be able to communicate securely with it.

In one embodiment, a set of priority notification attributes 3212 is defined based on the level of importance or severity associated with these attributes. For example, if a particular attribute relates to a hazardous condition, such as a temperature value reaching a threshold (e.g., if the user accidentally leaves the stove on, or when a heat sensor in the user's house is triggered), this attribute takes precedence. It may be assigned to a rank notification attribute class. As mentioned above, priority notification attributes may be treated differently than other attributes. For example, when a particular priority notification attribute reaches a threshold, the IoT hub may pass the value of the attribute to the IoT service, regardless of the current flow control mechanism being implemented by the IoT hub. In one embodiment, the priority notification attributes also trigger the IoT service to generate a notification to the user and/or alarm conditions within the user's home or business (eg, to warn the user of a potentially hazardous condition). can do.

As illustrated in FIG. 32 , in one embodiment, the current state of application properties 3210 , system properties 3211 , and priority notification properties 3212 is device database 2851 on IoT service 120 . It is duplicated/mirrored within. For example, when a change in one of the properties is updated on the IoT device 101 , the secure wireless communication module 3218 communicates the change to the device management logic 3021 on the IoT service 120 , which Responsively updating the value of an attribute in database 2851 . Also, when the user updates one of the properties on the IoT service (eg, adjusting a current state or condition, such as a desired temperature), the property change is sent from the device management logic 3021 to the secure wireless communication module 3218 will be sent to , which will then update the local copy of its properties. In this way, the properties are maintained in a consistent manner between the IoT device 101 and the IoT service 120 . Attributes may also be accessed from the IoT service 120 via the IoT app or user device on which the application is installed and/or by one or more external services 3270 . As mentioned, IoT service 120 may expose an application programming interface (API) to provide access to a variety of different attribute classes.

Further, in one embodiment, the priority notification processing logic 3022 may perform a rule-based action in response to receipt of a notification related to the priority notification attribute 3212 . For example, if the priority notification attribute indicates a hazardous condition (eg, an iron or stove is left on by the user), the priority notification processing logic 3022 attempts to turn off the hazardous device. may implement a set of rules (eg, sending an “off” command to the device if possible). In one embodiment, the priority notification processing logic 3022 controls the user to determine whether to turn off the risky device (eg, if it is detected that the user has left the home when the risky device is in an “on” state). Other relevant data, such as the current location of In addition, the priority notification processing logic 3022 may notify the user of the condition by sending a warning condition to the user's client device. Various other types of rule sets may be implemented by priority notification processing logic 3022 to attempt to address a potentially dangerous or otherwise undesirable condition.

A set of BTLE attributes 3205 and an attribute address decoder 3207 are also shown in FIG. 32 . In one embodiment, BTLE attributes 3205 may be used to set the read and write port as described above with respect to FIGS. 19 and 20 . The attribute address decoder 3207 reads the unique ID code associated with each attribute to determine which attribute is being received/transmitted and processes the attribute accordingly (e.g., the attribute is Identifies where it is stored).

Systems and methods for establishing secure communication channels with Internet of Things (IoT) devices

A. Fake Advertising

In certain examples, it may be possible for an attacker to use a fake IoT device to advertise the same advertising data as a real IoT device in a normal state (ie, no data to send). If this advertisement packet is transmitted using a stronger signal than the actual signal, the hub can be controlled to never attempt to connect to the actual IoT device. For example, in the case of a door sensor, an attacker could then open the door without being detected.

In one embodiment of the present invention, each IoT device adds a cryptographic secret to its advertising data made available to all IoT hubs, so they can distinguish real IoT devices from fake IoT devices. In one embodiment, the cryptographic secret is set as a system property, so it will first be made available to the IoT service, from which it can be distributed to each of the IoT hubs using SSL or other secure communication protocol.

33 illustrates operations performed by the IoT device 101 , the IoT service 120 , and the IoT hub 110 according to an embodiment of the present invention. When the IoT device boots, before the IoT device 101 is linked, the IoT device 101 uses the set link request flags and connection request flags and the secret bytes set to 0 (indicating that a link/connection is being requested). to advertise on the IoT hub 110 . A link with the IoT hub or client device is then established. After link formation, the secret-counter processing logic 3310 of the secure wireless communication module 3218 generates a 32 byte master secret 3322 and converts it (e.g., using the attribute synchronization techniques described above) to a system attribute ( 3211 ) to make it available for the IoT service 120 .

The IoT service 120 may then make the secret available to the IoT hubs 110 via SSL or other security protocol. The secret/counter processing logic 3310 creates a 32-byte counter COUNTER_1 3331 and initializes it to zero. Secret/counter processing logic 3310 combines with 32 byte COUNTER_1 3331 to generate 32 byte shared secret 3340 using 32 byte master secret 3322 . In one embodiment, a keyed-hash message authentication code (HMAC)-SHA256 is used to generate the shared secret 3340 using the master secret as the key to the HMAC and COUNTER_1 as the data. .

The secret/counter processing logic 3310 creates a 1-byte counter COUNTER_2 3332 and initializes it to zero. In one embodiment, the HMAC generation logic 3345 uses the shared secret to generate the advertisement flags (eg, using SHA256) and the HMAC 3312 of COUNTER_2 3332 . The key is a 32 byte shared secret 3340 , the data is 32 bytes consisting of the manufacturer data from the advertisement packet 3314 followed by COUNTER_2 3332 followed by a sequence of zeros to pad in 32 bytes. In one embodiment, a 32-byte buffer 3317 is created and zero-terminated. Into the buffer, the buffer copies data from the advertisement packet 3314 containing the 2-byte manufacturer ID, manufacturer data containing flags, device ID, protocol version. The buffer also copies the current COUNTER_2 value (3332). The HMAC generation logic 3345 generates the HMAC 3312 using the shared secret 3340 as the key and the contents of the 32 byte buffer 3317 as data.

In one embodiment, bytes 26 , 27 of HMAC 3312 are placed in advertisement packet 3314 immediately following COUNTER_2 value 3332 . The secret/counter processing logic 3310 then sets the timer 3311 to run based on a frequency specified in another system attribute (eg, a timer attribute). In one embodiment, this period is 5 minutes.

In one embodiment, when the timer runs, the secret/counter processing logic 3310 increments the 32 byte COUNTER_1 and combines with the 32 byte COUNTER_1 to use the 32 byte master secret to create a new 32 byte shared secret. The secret/counter processing logic 3310 increments 1 byte COUNTER_2, creates a 32 byte buffer 3317, and terminates it with 0. Into the buffer, the buffer copies the 2-byte manufacturer ID, manufacturer data including flags, device id, protocol version and the value of COUNTER_2. HMAC generation logic 3345 generates HMAC 3312 using shared secret 3340 as the key and 32 byte buffer 3317 as data. Bytes 26 and 27 of HMAC are placed in advertisement packet 3314 immediately following COUNTER_2 3332 .

In one embodiment, when the advertisement flags change, the secret/counter processing logic 3310 increments 1 byte COUNTER_2, creates a 32 byte buffer 3317, and terminates it with zero. Into the buffer 3317 , the buffer copies the 2-byte manufacturer ID, manufacturer data including flags, device ID, protocol version and COUNTER_2 3332 . HMAC Generation 3345 HMAC 3312 is generated using a shared secret as a key and a 32 byte buffer as data. Bytes 26 and 27 of HMAC 3312 are placed in advertisement packet 3314 immediately following COUNTER_2 3332 .

In one embodiment of the present invention, the following security processing operations are performed on the IoT hub 110 . When the IoT hub 110 receives the master secret 3322 and counter 1 3331 for the IoT device 101 , the shared secret generation logic 3350 uses the master secret and counter 1 (+ or − 1). to create and store three shared secrets 3355 for the IoT device 101 . Hub 110 sets timer 3351 to run based on a frequency specified in another system attribute (eg, 5 minutes in one embodiment). When the timer runs, IoT hub 110 increments counter 1 and uses this (+ or - 1) along with master secret 3322 to create 3 new shared secrets 3355 for IoT device 101. create and save

In one embodiment, when the hub sees a new device for the first time, if the link and connection request bits are set in the advertisement packet 3314, the secret bytes are ignored and the hub connects. If the secret bytes are not correct and the link request flag is clear, the hub flags the malicious activity to the service via the security event reporting module 3375 . If the IoT hub 110 does not have a shared secret for the peripheral, it will ignore the peripheral until the master secret 3322 and counter 1 3331 values are received. If the IoT hub has shared secrets for the IoT device, then the HMAC generation logic 3360 generates three HMACs based on the shared secrets 3355 (from the advertisement packet 3314) and flags and counter 2 3332 . (3365) is calculated.

In one embodiment, for each HMAC generated, the HMAC parsing logic 3370 compares the first two bytes to the secret bytes in the advertisement packet 3314 . If no match is found, the security event reporting module 3375 reports the malicious activity to the IoT service 120 , which may then send a notification to the end user's client.

In one embodiment, when the IoT hub sees only a secret byte change (not flags or counter 2), it increments counter 1 (3331), regenerates shared secrets (3355), and restarts timer (3351). do. HMAC generation logic 3360 creates new HMACs 3365 , and HMAC analysis logic 3370 checks for new results for current advertisement packets 3314 . If there is no match, the security event reporting logic 3375 reports the malicious activity to the IoT service 120 .

When IoT hub 110 detects changes to flags and/or counter 2 3332 , IoT hub compares current shared secrets 3355 with current advertisement data 3314 (eg, HMAC) create new HMACs 3365 to be analyzed by the analysis module 3370). If the current shared secrets fail, the IoT hub increments counter 1 , regenerates the shared secrets 3355 , and restarts the timer 3351 . The IoT hub then checks the new shared secrets 3355 against the current advertisement data 3314 . If there is no match, the security event reporting module 3375 reports the malicious activity to the IoT service 120 .

B. Fake IoT Hub

It may be possible for someone to connect to an IoT device using a fake IoT hub. The connection will eventually time out, but if an attacker maintains a connection to the IoT device, they can effectively hide it from real IoT hubs.

As described above with respect to FIGS. 26A-26C , in one embodiment, when an IoT device 101 connects to an IoT hub 111 , it is “connectable” to other IoT hubs 110 , 112 that can see it. Advertise as "don't" 35 , in one embodiment, if a genuine IoT hub 110 , 112 sees an IoT device advertising as “not accessible”, it 112) and report the status (as indicated by the report to the IoT service 120). In one embodiment, when the IoT service 120 receives this information, it is a device database 2851 , or a device/hub connection state for determining which IoT hub 111 the IoT device 101 is connected to. Any other database holding 3400 is searched. In FIG. 34 , IoT device 101 is connected to IoT hub 111 providing its connection state to IoT service 120 as illustrated. The connection security module 3405 evaluates the device/hub connection state data 3400 to determine whether the IoT device 101 is connected to the legitimate IoT hub 111 .

In contrast, if the IoT device 101 is not connected to any IoT hub, as illustrated in FIG. 35 , the connection security module 3405 (eg, in the form of an alert notification to the client device 611 ) Report evil activity. In particular, in this embodiment, no legitimate IoT hubs 110 - 112 are reporting a connection with the IoT device 101 . As a result, in response to one or more of the IoT hubs 110 - 112 communicating to the IoT service 120 that it is receiving a “not accessible” indication from the IoT device 101 , it Combined with the lack of connectivity of the connection security module 3405 , the connection security module 3405 will conclude that the false IoT hub 3500 may be connecting to the IoT device 101 .

C. Hide Events

If an attacker can prevent an event, such as a door opening event, from being reported to the service long enough to close the door again, the user may not be alerted that the event has occurred.

One embodiment of the present invention solves this problem by using at least two features. First, the property that the door sensors are connected is defined as a "latched" property that will always report the current state as well as the state change when they send their property values to the service. This ensures that the user will receive a notification that the door has been opened even if the door is closed again. 36 shows that latched properties 3610 are maintained by MCU 3215 and/or secure wireless communication module 3218 and ultimately synchronized with IoT service 120 (eg, after a connection is re-established). Examples are illustrated. The latched attribute includes a current value 3600 indicating the current state of the sensor performing its function. For example, for a door sensor, the current state may be "open" or "closed". In addition, each latched attribute includes an indication of state changes 3601 that have occurred since the last time the IoT device 101 was reset and/or the last synchronization with the IoT service 120 . For example, if a door is opened and then closed while the IoT device 101 was unable to connect to the IoT service 120, this state change 3601 is stored in the IoT device and then, despite the current value 3600, When the connection is made, it will be provided to the IoT service 120 . In one embodiment, the latched attribute includes a dirty flag indicating that it is not synchronized with the corresponding latched attribute 3610 on the IoT service 120 .

Second, in one embodiment of the present invention, an acknowledgment from the IoT service 120 is required for the latched attributes. Therefore, when the IoT device 101 cannot provide information to the IoT service 120 due to a connection problem or interference by an attacker, the IoT device 101 successfully receives an acknowledgment from the IoT service 120 will keep trying until In one embodiment, the acknowledgment is performed in the form of an action set on a special system property. Only when IoT device 101 receives a set request, it clears the dirty flag on latched attribute 3610 to stop attempting to report a value.

Various functional components are described herein as “logic” or “module”. These functional components may be hardware, such as integrated circuits (eg, application specific integrated circuits, general purpose processors, microcontrollers, etc.). Alternatively, these functional components may be implemented in software executed by a processing device or using a combination of hardware and software.

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

As described herein, instructions are software instructions stored in a memory configured to perform certain operations or embodied in a non-transitory computer readable medium or hardware such as application specific integrated circuits (ASICs) having predetermined functions. It may refer to a specific configuration. Accordingly, the techniques depicted in the figures may be implemented using code and data stored on and executing 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) and transitory computer machine readable communication media (eg, store code and data (internally and/or network communicates with other electronic devices) through Additionally, such electronic devices typically include one or more storage devices (non-transitory machine-readable storage media), user input/output devices (eg, keyboards, touchscreens, and/or displays), and network connections, such as and a set of one or more processors coupled to one or more other components. The coupling of a set of processors with other components is typically via one or more buses and bridges (also referred to as bus controllers). The signals carrying the storage device and network traffic are representative of one or more machine-readable storage media and machine-readable communication media, respectively. Accordingly, the storage device of a given electronic device typically stores code and/or data for execution on a set of one or more processors of that electronic device. Of course, one or more portions of an embodiment of the invention may be implemented using different combinations of software, firmware, and/or hardware.

Throughout this detailed description, for 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 some instances, well-known structures and functions have not been described in detail in order to avoid obscuring the subject matter of the present invention. Accordingly, the scope and spirit of the invention should be judged in light of the claims that follow.

Claims (72)

As a system,
an IoT device comprising a secret/counter processing logic/circuit for generating a master secret to be transmitted to an IoT service, wherein the secret/counter processing logic/circuit generates a first counter and, in combination with the master secret, generating a shared secret using the value, the secret/counter processing logic/circuitry generating a second counter;
one or more IoT hubs receiving the master secret from the IoT service via a first secure communication channel, wherein at least one of the IoT hubs establishes a second secure communication channel with the IoT device using the master secret. ;
HMAC generation logic/circuitry for generating a keyed-hash message authentication code (HMAC) with the second counter value and data from an advertisement packet using the shared secret as a key; and
Shared secret generation logic to generate and store a plurality of shared secrets related to the IoT device using the master secret and the first counter value
including,
and the IoT device generates an advertisement packet that includes the specified set of bytes from the HMAC and the second counter value. The method of claim 1 , wherein the master secret is transmitted to the IoT service by setting the master secret as a system property on the IoT device, wherein the IoT device automatically synchronizes system properties of the IoT device with the IoT service. A system comprising circuit/logic. delete The system of claim 1 , wherein an HMAC is used to generate the shared secret using the master secret as a key to the HMAC and the first counter as data. delete The system of claim 1 , wherein the data from the advertisement packet includes a manufacturer ID, manufacturer flags, device ID and/or protocol version, and wherein the data from the advertisement packet is followed by the second counter value. 7. The method of claim 6,
and an N byte buffer to store the data from the advertisement packet and the second counter value, wherein the second counter value is followed by a sequence of zeros to pad to N bytes. The method of claim 1, wherein the system comprises:
further comprising a timer configured to run based on a frequency specified in a system property, wherein when the timer operates, the secret/counter processing logic/circuit increments the first counter value, and in combination with the master secret, and generating a new shared secret using the incremented first counter value. 9. The system of claim 8, wherein the secret/counter processing logic/circuitry further increments the second counter value in response to the timer actuation. 9. The system of claim 8, wherein the secret/counter processing logic/circuitry further increments the second counter value in response to a detected change to one or more advertisement flags. delete The method of claim 1, wherein the IoT hub comprises:
HMAC generation logic to generate a plurality of HMACs using the plurality of shared secrets and data from an advertisement packet received from the IoT device. 13. The system of claim 12, wherein the data from the advertisement packet includes the second counter value and advertisement data. The method of claim 13, wherein the IoT hub comprises:
HMAC parsing logic that compares designated bytes of HMAC with secret bytes in an advertisement packet received from the IoT device, and if no match is found, a warning condition is reported to the IoT service. As a method,
generating on the IoT device a master secret to be transmitted to the IoT service;
receiving the master secret from the IoT service at one or more IoT hubs via a first secure communication channel;
establishing a second secure communication channel with the IoT device using the master secret;
generating a first counter;
generating a shared secret using the value of the first counter in combination with the master secret;
generating a second counter;
generating an HMAC having the second counter value and data from an advertisement packet using the shared secret as a key;
generating a plurality of shared secrets associated with the IoT device on the IoT hub using the master secret and the first counter value; and
storing the plurality of shared secrets;
including,
The IoT device generates an advertisement packet that includes the specified set of bytes from the HMAC and the second counter value. 16. The method of claim 15, wherein the master secret is transmitted to the IoT service by setting the master secret as a system property on the IoT device, wherein the IoT device automatically synchronizes system properties of the IoT device with the IoT service. A method comprising circuit/logic. delete 16. The method of claim 15, wherein an HMAC is used to generate the shared secret using the master secret as a key to the HMAC and the first counter as data. delete The method of claim 15 , wherein the data from the advertisement packet includes a manufacturer ID, manufacturer flags, device ID and/or protocol version, and wherein the data from the advertisement packet is followed by the second counter value. 21. The method of claim 20,
and storing the data from the advertisement packet and the second counter value in an N byte buffer, wherein the second counter value is followed by a sequence of zeros to pad to N bytes. 16. The method of claim 15, wherein the method comprises:
further comprising configuring a timer to run based on a frequency specified in a system property, wherein when the timer operates, the first counter value is incremented and the first counter value is incremented in combination with the master secret. Using the method, a new shared secret is created. 23. The method of claim 22,
and incrementing the second counter value in response to the timer actuation. 23. The method of claim 22,
incrementing the second counter value in response to a detected change to one or more advertisement flags. delete 16. The method of claim 15,
generating a plurality of HMACs on the IoT hub using the plurality of shared secrets and data from an advertisement packet received from the IoT device. 27. The method of claim 26, wherein the data from the advertisement packet includes the second counter value and advertisement data. 28. The method of claim 27,
and comparing the designated bytes of the HMAC with secret bytes in an advertisement packet received from the IoT device, wherein if no match is found, a warning condition is reported to the IoT service. delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete

Images