CN107710216B - Apparatus and method for establishing a secure communication channel in an internet of things (IoT) system - Google Patents

Abstract

Apparatus and methods for secure communication between IoT devices and IoT services are described. For example, one embodiment of a system comprises: an Internet of things (IoT) service to establish communication with an IoT device through an IoT hub or a mobile user device; a first encryption engine on the IoT service, the first encryption engine comprising key generation logic to generate a service public key and a service private key; a second encryption engine on the IoT device, the second encryption engine comprising key generation logic to generate a device public key and a device private key; the first encryption engine to transmit the service public key to the second encryption engine and the second transmission engine to transmit the device public key to the first encryption engine; the first encryption engine generating a password using the device public key and the service private key; the second encryption engine generating the same password using the service public key and the device private key; and wherein once the password is generated, the first and second encryption engines encrypt and decrypt data packets transmitted between the first and second encryption engines using the password or using a data structure derived from the password.

Description

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

Background

Technical Field

The present invention relates generally to the field of computer systems. More particularly, the present invention relates to an apparatus and method for establishing a secure communication channel in an IoT system.

Description of the related Art

The "internet of things" refers to the interconnection of uniquely identifiable embedded devices within the internet infrastructure. Finally, IoT is expected to lead to a new and wide variety of applications in which virtually any type of physical thing can provide information about itself or its surroundings and/or can be remotely controlled through client devices on the internet.

The development and adoption of the internet of things has been slow due to some of the problems associated with lack of connectivity, power and standardization. For example, one obstacle faced by IoT development and adoption is that there is no standard platform that allows developers to design and provide new IoT devices and services. To enter the IoT market, developers must design the entire IoT platform from scratch, including the network protocols and infrastructure, hardware, software, and services needed to support the required IoT implementation. Thus, each provider of IoT devices uses proprietary technology to design and connect IoT devices, which makes employing multiple types of IoT devices a burdensome task for end users. Another obstacle faced by IoT adoption is the difficulties associated with the connection and powering of IoT devices. For example, connecting appliances such as refrigerators, garage door switches, environmental sensors, home security sensors/controllers, etc. requires a power source to power each connected IoT device, and this power source is often located inconveniently.

Another problem that exists is that the wireless technology used to interconnect IoT devices (such as bluetooth LE) is typically a short range technology. So, if the data collection center used to implement IoT is out of range of the IoT device, the IoT device will not be able to transmit data to the IoT center (and vice versa). Accordingly, there is a need for techniques to allow IoT devices to provide data to out-of-range IoT hubs (or other IoT devices).

Drawings

The invention may be better understood from the following detailed description taken in conjunction with the following drawings, in which:

fig. 1A-1B illustrate different embodiments of an IoT system architecture;

fig. 2 illustrates an IoT device in accordance with one embodiment of the present invention;

fig. 3 illustrates an IoT hub in accordance with one embodiment of the present invention;

fig. 4A-4B illustrate embodiments of the present invention for controlling and collecting data from IoT devices and generating notifications;

fig. 5 illustrates an embodiment of the present invention for collecting data from IoT devices and generating notifications from IoT hubs and/or IoT services;

fig. 6 illustrates one embodiment of a system in which an intermediate mobile device collects data from a fixed IoT device and provides the data to an IoT hub;

FIG. 7 illustrates intermediate connection logic implemented in one embodiment of the present invention;

FIG. 8 illustrates a method according to an embodiment of the invention;

fig. 9A illustrates an embodiment of providing program code and data updates to IoT devices;

fig. 9B illustrates an embodiment of a method of providing program code and data updates to IoT devices;

FIG. 10 illustrates a high-level view of one embodiment of a security architecture;

fig. 11 illustrates one embodiment of an architecture in which a user identity module (SIM) is used to store keys on an IoT device;

fig. 12A illustrates one embodiment in which a barcode or QR code is used to register an IoT device;

FIG. 12B shows an embodiment in which a barcode or QR code is used for pairing;

fig. 13 illustrates one embodiment of a method for programming a SIM using an IoT hub;

fig. 14 illustrates one embodiment of a method for registering IoT devices with an IoT hub and an IoT service; and is

Fig. 15 illustrates one embodiment of a method for encrypting data to be sent to an IoT device;

fig. 16A-16B illustrate different embodiments of the present invention for encrypting data between an IoT service and an IoT device;

FIG. 17 illustrates an embodiment of the present invention for performing a secure key exchange, generating a public cipher, and generating a keystream using the cipher;

FIG. 18 illustrates a data packet structure according to one embodiment of the invention;

fig. 19 illustrates a technique employed in one embodiment to write/read data to/from IoT devices without formal pairing with the IoT devices;

FIG. 20 illustrates an exemplary set of command packets employed in one embodiment of the present invention;

FIG. 21 shows an exemplary sequence of transactions using a command package;

FIG. 22 illustrates a method according to an embodiment of the invention; and is

Fig. 23A to 23C illustrate a method for secure pairing according to an embodiment of the present invention.

Detailed Description

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 invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the underlying principles of embodiments of the present invention.

One embodiment of the present invention includes an internet of things (IoT) platform that developers can utilize to design and build new IoT devices and applications. In particular, one embodiment includes an infrastructure hardware/software platform for internet of things devices that includes a predefined network protocol stack and an IoT hub through which IoT devices connect to the internet. Further, one embodiment includes an IoT service through which an IoT hub and connected IoT devices can be accessed and managed as described below. Further, one embodiment of the IoT platform includes an IoT application or Web application (e.g., executing on a client device) to access and configure IoT services, hubs, and connected devices. Existing online retailers and other website operators can easily provide unique IoT functionality for existing user groups using the IoT platform described herein.

FIG. 1A shows an overview of an architectural platform on which embodiments of the present invention may be implemented. In particular, the illustrated embodiment includes multiple IoT devices 101-105 that are communicatively connected to a central IoT hub 110 through a local communication channel 130, which itself is communicatively connected to an IoT service 120 through the internet 220. Each of the IoT devices 101-105 may initially be paired with the IoT hub 110 (e.g., using the pairing techniques described below) to enable each of the local communication channels 130. In one embodiment, the IoT service 120 includes an end user database 122 for maintaining user account information and data collected from each user's IoT devices. For example, if the IoT device includes sensors (e.g., temperature sensors, accelerometers, thermal sensors, motion detectors, etc.), database 122 may be continually updated to store data collected by IoT device 101 and 105. The data stored in the database 122 may then be accessible to end users and network clients (e.g., the websites 130 subscribed to the IoT service 120) via IoT applications and browsers installed on the user devices 135 (or via desktop computers or other client computer systems).

IoT devices 101-105 may be equipped with various types of sensors to collect information about themselves and their surroundings and provide the collected information to IoT services 120, user devices 135, and/or external websites 130 via IoT hubs 110. Some of the IoT devices 101-105 may perform specified functions in response to control commands sent through the IoT hub 110. The following provides a number of specific examples of information and control commands collected by IoT devices 101-105. In one embodiment described below, IoT device 101 is a user input device designed to record user selections and send the user selections to IoT service 120 and/or a website.

In one embodiment, the IoT hub 110 includes a cellular radio to establish a connection to the internet 220 via a cellular service 115, such as a 4G (e.g., mobile WiMAX, LTE) or 5G cellular data service. Alternatively or additionally, the IoT hub 110 may include a WiFi radio to establish a WiFi connection through a WiFi access point or router 116 that connects the IoT hub 110 to the internet (e.g., via an internet service provider that provides internet services to end users). Of course, it should be noted that the underlying principles of the 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 for long periods of time (e.g., years) using battery power. 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 IoT devices 101-105 and IoT hub 110 is equipped with a bluetooth LE radio and protocol stack.

As described above, in one embodiment, the IoT platform includes an IoT application or Web application that executes on the user device 135 to allow the user to access and configure the connected IoT devices 101-105, IoT hub 110, and/or IoT service 120. In one embodiment, the application or Web application may be designed by the operator of the website 130 to provide IoT functionality to its user group. As shown, the website may maintain a user database 131 containing account records associated with each user.

Fig. 1B illustrates additional connection options for multiple IoT hubs 110-111, 190. In this embodiment, a single customer may have multiple centers 110-111 installed on site at a single customer premises 180 (e.g., the customer's home or work site). This may be done, for example, to extend the wireless range required to connect all IoT devices 101-105. As shown, if a user has multiple hubs 110, 111, they may be connected via a local communication channel (e.g., Wifi, ethernet, powerline network, etc.). In one embodiment, each of the hubs 110-111 may establish a direct connection with the IoT service 120 through a cellular connection 115 or a WiFi connection 116 (not explicitly shown in fig. 1B). Alternatively or additionally, one of the IoT hubs, such as IoT hub 110, may act as a "master" hub that provides connectivity and/or local services to all other IoT hubs on customer premises 180, such as IoT hub 111 (as shown by the dashed line connecting IoT hub 110 and IoT hub 111). For example, the primary IoT hub 110 may be the only IoT hub that establishes a direct connection with the IoT service 120. In one embodiment, only the "master" IoT hub 110 is equipped with a cellular communication interface to establish a connection with the IoT service 120. As such, all communications between the IoT service 120 and the other IoT hubs 111 will flow through the primary IoT hub 110. As this role, the master IoT hub 110 may have additional program code to perform filtering operations on data exchanged between the other IoT hubs 111 and the IoT service 120 (e.g., to serve some data requests locally, when possible).

Regardless of how the IoT hubs 110-111 are connected, in one embodiment, the IoT service 120 will logically associate the hubs with the users and combine all attached IoT devices 101-105 under a single comprehensive user interface (and/or browser-based interface) that is accessible via the user devices that have installed the application 135.

In this embodiment, the master IoT hub 110 and the one or more slave IoT hubs 111 may be connected through local networks, which may be WiFi networks 116, ethernet networks, and/or use Power Line Communication (PLC) networks (e.g., where all or part of the network operates over the user's power lines). Additionally, for IoT hubs 110-111, each of IoT devices 101-105 may interconnect IoT hubs 110-111 using any type of local network channel, such as WiFi, ethernet, PLC, or bluetooth LE.

Fig. 1B also shows an IoT hub 190 installed at the second customer premises 181. An almost 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 customer premises 180 to 181 may be configured for the same user. For example, one customer premises 180 may be the user's main home, while the other customer premises 181 may be the user's vacation home. In this case, the IoT service 120 would logically associate the IoT hubs 110-111, 190 with the user and combine all of the attached IoT devices 101-105, 191-192 under a single comprehensive user interface (and/or browser-based interface) that is accessible via the user devices that have installed the application 135.

As shown in fig. 2, one exemplary embodiment of IoT device 101 includes a memory 210 for storing program code and data 201-203, and a low power microcontroller 200 for executing the program code and processing the data. The memory 210 may be a volatile memory such as a Dynamic Random Access Memory (DRAM) or may be a non-volatile memory such as a flash memory. In one embodiment, non-volatile memory may be used for persistent storage, while volatile memory may be used for execution of program code and data at runtime. Further, memory 210 may be integrated within low power microcontroller 200 or may be connected to low power microcontroller 200 via a bus or communication fabric. The underlying principles of the invention are not limited to any particular implementation of memory 210.

As shown, the program code may include application code 203 that defines a set of application-specific functions to be performed by the IoT device 201, and library code 202 that includes a set of predefined building blocks that may be utilized by application developers of the IoT device 101. In one embodiment, the library code 202 includes a set of basic functions required to implement the IoT devices, such as a communication protocol stack 201 for enabling communication between each IoT device 101 and the IoT hub 110. As noted above, in one embodiment, the communication protocol stack 201 comprises a bluetooth LE protocol stack. In this embodiment, the bluetooth LE radio and antenna 207 may be integrated within the low power microcontroller 200. However, the underlying principles of the 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 to receive user input and provide the user input to the low power microcontroller, which processes the user input according to the application code 203 and library code 202. In one embodiment, each of the input devices includes an LED 209 for providing feedback to the end user.

In addition, the illustrated embodiment includes a battery 208 for powering the low power microcontroller. In one embodiment, a non-rechargeable button cell battery is used. However, in an alternative embodiment, an integrated rechargeable battery may be used (e.g., charged by connecting the IoT device to an ac power source (not shown)).

A speaker 205 for producing audio is also provided. In one embodiment, the low power microcontroller 299 includes audio decoding logic for decoding a compressed audio stream (e.g., such as an MPEG-4/Advanced Audio Coding (AAC) stream) to produce audio on the speaker 205. Alternatively, the low power microcontroller 200 and/or the application code/data 203 may comprise digitally sampled audio clips to provide verbal feedback to the end user when the user inputs a selection via the input device 210.

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

In one embodiment, low power microcontroller 200 also includes a secure key storage for storing encryption keys used to encrypt communications and/or generate signatures. Alternatively, the key may be protected in a Subscriber Identity Module (SIM).

In one embodiment, a wake-up receiver 207 is included to wake up the IoT device from an ultra-low power state that consumes little power. In one embodiment, the wake-up receiver 207 is configured to cause the IoT device 101 to exit the low-power state in response to a wake-up signal received from the wake-up transmitter 307 configured on the IoT hub 110 as shown in fig. 3. In particular, in one embodiment, the transmitter 307 and receiver 207 together form an electrically resonant transformer circuit, such as a tesla coil. In operation, when the hub 110 needs to wake the IoT device 101 from a very low power state, energy is sent from the transmitter 307 to the receiver 207 via radio frequency signals. Due to this energy transfer, IoT device 101 may be configured to consume little power when in a low power state because it does not need to continuously "listen" for signals from the center (as is the case with network protocols that allow devices to be woken up through network signals). More specifically, the microcontroller 200 of the IoT device 101 may be configured to wake up after being effectively powered down by using energy electrically transmitted from the transmitter 307 to the receiver 207.

As shown in fig. 3, IoT hub 110 also includes memory 317 for storing program code and data 305, and hardware logic 301, such as a microcontroller, for executing the program code and processing the data. A Wide Area Network (WAN) interface 302 and an antenna 310 connect the IoT hub 110 to the cellular service 115. Alternatively, as described above, the 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 network communication channel. In one embodiment, the hardware logic 301 also includes a secure key storage for storing encryption keys used to encrypt communications and generate/verify signatures. Alternatively, the key may be protected in a Subscriber Identity Module (SIM).

The local communication interface 303 and the antenna 311 establish a local communication channel with each of the IoT devices 101 to 105. As described above, in one embodiment, the local communication interface 303/antenna 311 implements the bluetooth LE standard. However, the underlying principles of the invention are not limited to any particular protocol for establishing local communication channels with IoT devices 101-105. Although shown as separate units in fig. 3, the WAN interface 302 and/or the local communication interface 303 may be 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 the local communication interface 303 and the WAN interface 302. Further, device pairing program code and data 306 may be stored in memory to allow the IoT hub to pair with the new IoT device. In one embodiment, each new IoT device 101-105 is assigned a unique code that is transmitted 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 may be transmitted over the local communication channel 130. In an alternative embodiment, the unique ID code is magnetically embedded on the IoT device, and the IoT hub has a magnetic sensor, such as a radio frequency ID (rfid) or Near Field Communication (NFC) sensor, to detect the code when the IoT device 101 moves within 110 inches from the IoT hub.

In one embodiment, once the unique ID has been transmitted, IoT hub 110 may verify the unique ID by: query a local database (not shown), perform a hash to verify whether the code is acceptable, and/or communicate with the IoT service 120, the user device 135, and/or the website 130 to verify the ID code. In one embodiment, once verified, IoT hub 110 pairs with IoT device 101 and stores the pairing data in memory 317 (which, as described above, may comprise non-volatile memory). Once pairing is complete, IoT hub 110 may connect with IoT device 101 to perform the various IoT functions described herein.

In one embodiment, the organization running IoT services 120 may provide IoT hubs 110 and a basic hardware/software platform to allow developers to easily design new IoT services. In particular, in addition to the IoT hub 110, developers may be provided with a Software Development Kit (SDK) to update the program code and data 305 executing within the hub 110. Additionally, for IoT devices 101, the SDK may include a broad set of library code 202 designed for the underlying IoT hardware (e.g., the low power microcontroller 200 and other components shown in fig. 2) to facilitate designing a variety of different types of applications 101. In one embodiment, the SDK includes a graphical design interface in which developers need only specify inputs and outputs for IoT devices. All networking code has been prepared for developers, including a communication stack 201 that allows the IoT device 101 to connect to the hub 110 and the service 120. Further, in one embodiment, the SDK also includes library code bases for facilitating the design of applications for mobile devices (e.g., iPhone and Android devices).

In one embodiment, IoT hub 110 manages a continuous bi-directional data flow between IoT devices 101-105 and IoT service 120. In the event that real-time updates to/from IoT devices 101-105 are needed (e.g., if a user needs to view the current state of security devices or environmental readings), the IoT hub may keep an open TCP socket to provide periodic updates to the user device 135 and/or the external website 130. The particular networking protocol used to provide the update may be tailored to the needs of the underlying application. For example, in some cases, if continuous bi-directional flow may not make sense, a simple request/response protocol may be used to gather information when needed.

In one embodiment, both IoT hub 110 and IoT devices 101-105 may be automatically upgraded over a network. In particular, when IoT hub 110 has a new update available, it may automatically download and install the update from IoT service 120. It may first copy the updated code into local memory, run and validate the update, and then replace the older program code. Similarly, when updates are available for each of the IoT devices 101-105, the updates may be initially downloaded by the IoT hub 110 and pushed to each of the IoT devices 101-105. Each IoT device 101-105 may then apply the update in a manner similar to that described above for the IoT hub and report the results of the update back to IoT hub 110. If the update is successful, IoT hub 110 may delete the update from its memory and record the latest code version installed on each IoT device (e.g., so that it can continue to check each IoT device for new updates).

In one embodiment, the IoT hub 110 is powered by an ac power source. In particular, the IoT hub 110 may include a power supply unit 390 having a transformer for converting an ac voltage provided through an ac power line to a lower dc voltage.

Fig. 4A illustrates one embodiment of the present invention for performing universal remote control operations using an IoT system. Specifically, in this embodiment, a set of IoT devices 101 and 103 are equipped with Infrared (IR) and/or Radio Frequency (RF) transmitters 401 and 403, respectively, for transmitting remote control codes to control various different types of electronic equipment, including air conditioning/heaters 430, lighting systems 431, and audiovisual equipment 432, to name a few. In the embodiment shown in fig. 4A, IoT devices 101 and 103 are also equipped with sensors 404 and 406, respectively, for detecting the operation of the devices they control, as described below.

For example, the sensor 404 in the IoT device 101 may be a temperature and/or humidity sensor for sensing the current temperature/humidity, and in response, control the air conditioner/heater 430 based on the current desired temperature. In this embodiment, the air conditioner/heater 430 is an air conditioner/heater designed to be controlled via a remote control device (typically a remote control that itself has a temperature sensor embedded therein). In one embodiment, the user provides the required temperature to the IoT hub 110 via an application and browser installed on the user device 135. Control logic 412 executing on IoT hub 110 receives current temperature/humidity data from sensor 404 and responsively sends commands to IoT device 101 to control IR/RF transmitter 401 according to the desired temperature/humidity. For example, if the temperature is below the desired temperature, the control logic 412 may send a command to the air conditioner/heater via the IR/RF transmitter 401 to raise the temperature (e.g., by turning off the air conditioner or turning on the heater). The command may include the necessary remote control code stored in database 413 on IoT hub 110. Alternatively or additionally, IoT service 421 may implement control logic 421 to control electronic device 430 and 432 based on specified user preferences and stored control code 422.

The IoT device 102 in 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 the light produced by the luminaire 431 (or other lighting device). The user may specify 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 transmitter 402 to control the current brightness level of the light 431 (e.g., increase the illumination if the current brightness is too low, or decrease the illumination if the current brightness is too high, or simply turn the light on or off).

The IoT device 103 in the illustrated example is configured to control an audiovisual device 432 (e.g., television, a/V receiver, cable/satellite receiver, AppleTV^TMEtc.). The sensor 406 in the IoT device 103 may be an audio sensor (e.g., a microphone and associated logic) to detect the current ambient volume level and/or a photo sensor to detect the on-off condition of the television based on the light generated by the television (e.g., by measuring light within a particular spectrum). Alternatively, the sensor 406 may comprise a temperature sensor connected to the audio visual device to detect an on-off condition of the audio device based on the detected temperature. Again, in response to user input via the user device 135, the control logic 412 may send commands to the audiovisual device via the IR transmitter 403 of the IoT device 103.

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

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

In one embodiment, the control code needed to control each electronic device is stored in database 413 on IoT hub 110 and/or database 422 on IoT service 120. As shown in fig. 4B, control code may be provided to IoT hub 110 from a master database of control code 422 for different devices maintained on IoT service 120. The end user may specify the type of electronic (or other) device to be controlled through the application and browser executing on the user device 135, and in response, the remote control code learning module 491 on the IoT hub may retrieve the required IR/Rf codes from the remote control code database 492 on the IoT service 120 (e.g., identifying each electronic device with a unique ID).

Additionally, in one embodiment, the IoT hub 110 is equipped with an IR/RF interface 490 to allow the remote control code learning module 491 to "learn" new remote control codes directly from the original remote controller 495 provided with the electronic device. For example, if the control code for the original remote controller provided with the air conditioner 430 is not included in the remote control database, the user may interact with the IoT hub 110 via an application/browser on the user device 135 to teach the IoT hub 110 the various control codes generated by the original remote controller (e.g., increase temperature, decrease temperature, etc.). Once the remote control codes are learned, they may be stored in the control code database 413 on the IoT hub 110 and/or sent back to the IoT service 120 for inclusion in the central remote control code database 492 (and subsequent use by other users with the same air conditioning unit 430).

In one embodiment, each IoT device 101-103 has a very small profile and may be attached on or near their respective electronic device 430-432 using double-sided tape, small nails, magnetic attachments, and the like. To control some piece of equipment, such as air conditioner 430, IoT device 101 needs to be placed far enough so that sensor 404 can accurately measure the ambient temperature in the home (e.g., if the IoT device is placed directly on the air conditioner, the temperature measurement will be too low when the air conditioner is running and 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 of the sensor 405 to detect the current lighting level.

In addition to providing the overall control functionality, one embodiment of the IoT hub 110 and/or the IoT service 120 sends notifications to end users related to the current state of each electronic device. The notification may be a text message and/or an application-specific notification, which may then be displayed on the display of the user's mobile device 135. For example, if the user's air conditioner has been on for a long period of 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 working properly. If the user is not at home (which may be detected by a motion sensor or based on the currently detected user location) and either sensor 406 indicates that audiovisual device 430 is on or sensor 405 indicates that a light is on, a notification may be sent to the user asking if the user wants to turn off audiovisual device 432 and/or light 431. The same type of notification may be sent for any device type.

Once the user receives the notification, he/she may remotely control the electronic device 430 through an application or browser on the user device 135 and 432. In one embodiment, the user device 135 is a touch screen device and the application and browser display a remote controller image with user selectable buttons for controlling the device 430 and 432. Upon receiving the notification, the user may turn on the graphical remote control, turn off or adjust various devices. If connected through the IoT service 120, the user's selection may be forwarded from the IoT service 120 to the IoT hub 110, which will then control the device through the control logic 412. Alternatively, the user input may be sent directly from the user device 135 to the IoT hub 110.

In one embodiment, a user may program control logic 412 on IoT hub 110 to perform various automated control functions on electronic devices 430 and 432. In addition to maintaining the desired temperature, brightness level, and volume level as described above, the control logic 412 may automatically turn off the electronic device if certain conditions are detected. For example, if the control logic 412 detects that the user is not at home and the air conditioner is not operating, the air conditioner may be automatically turned off. Similarly, if the user is not at home and the sensor 406 indicates that the audiovisual device 430 is on or the sensor 405 indicates that the lights are on, the control logic 412 may automatically send commands via the IR/RF transmitters 403 and 402, respectively, to turn off the audiovisual device and lights.

Fig. 5 shows a further embodiment of the IoT device 104 and 105 equipped with the sensor 503 and 504 for monitoring the electronic device 530 and 531. In particular, the IoT device 104 of the present embodiment includes a temperature sensor 503 that may be placed on or near the stove 530 to detect when the stove is still on. In one embodiment, IoT device 104 sends the current temperature measured by temperature sensor 503 to IoT hub 110 and/or IoT service 120. If it is detected that the range is on for more than a threshold period of time (e.g., based on the measured temperature), the control logic 512 may send a notification to the end user's device 135 informing the user that the oven 530 is on. Additionally, in one embodiment, IoT device 104 may include control module 501 to turn off the range in response to receiving an instruction from a user or to automatically (if control logic 512 is programmed by the user to do so) turn off the range. In one embodiment, the control logic 501 includes a switch to cut off power or air supply to the stove 530. However, in other embodiments, the control logic 501 may be integrated within the stove.

Fig. 5 also shows 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. Another type of sensor that may be used is an audio sensor (e.g., microphone and logic) for detecting ambient volume levels. As with the other embodiments described above, this embodiment may send a notification to the end user if certain specified conditions are met (e.g., if motion is detected for a longer period of time, indicating that the washer/dryer is not turned off). Although not shown in fig. 5, IoT device 105 may also be equipped with a control module to automatically and/or in response to a user input turn off washer/dryer 531 (e.g., by turning off power/air).

In one embodiment, a first IoT device with control logic and a switch may be configured to turn off all power in a user's home, while a second IoT device with control logic and a switch may be configured to turn off all air supply in the user's home. The IoT devices with sensors may then be placed on or near the power supply or gas supply in the user's home. If the user is notified that there is a particular device (e.g., range 530) that is not turned off, the user may then send a command to turn off all power or air supply in the home to prevent damage from occurring. Alternatively, the control logic 512 in the IoT hub 110 and/or the IoT service 120 may be configured to automatically shut off power or supply air in such a case.

In one embodiment, the IoT hub 110 and the IoT service 120 communicate at periodic intervals. If the IoT service 120 detects that the connection with the IoT hub 110 has been lost (e.g., fails to receive a request or response from the IoT hub within a specified duration of time), it sends this information to the end-user's device 135 (e.g., by sending a text message or an application-specific notification).

Apparatus and method for transmitting data through an intermediate device

As described above, because the wireless technology used to interconnect IoT devices (such as bluetooth LE) is typically a short range technology, if the hub used to implement IoT is out of range of the IoT devices, the IoT devices will not be able to transmit data to the IoT hub (and vice versa).

To overcome this drawback, one embodiment of the present invention provides a mechanism for IoT devices that are outside the wireless range of an IoT hub to periodically connect with one or more mobile devices when the one or more mobile devices are within range. Once the connection is established, the IoT device may transmit any data that needs to be provided to the IoT hub to the mobile device, which then forwards the data to the IoT hub.

As shown in fig. 6, one embodiment includes an IoT hub 110, IoT devices 601 that are out of range of the IoT hub 110, and a mobile device 611. Out-of-range IoT devices 601 may include any form of IoT device capable of collecting and transmitting data. For example, IoT device 601 may include a data collection device configured within a refrigerator to monitor food items edible in the refrigerator, users eating the food items, and the current temperature. Of course, the underlying principles of the invention are not limited to any particular type of IoT device. The techniques described herein may be implemented using any type of IoT device, including those used to collect and transmit data for the following appliances: smart meters, stoves, washing machines, dryers, lighting systems, HVAC systems, and audio-visual equipment, to name a few.

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

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

Once the data has been transferred to the temporary data repository, the mobile device 611 will transfer the data when communication is established with the IoT hub 110 (e.g., when a user moves about within range of the IoT hub 110). The IoT hub may then store the data in the central data repository 413 and/or send the data over the internet to one or more services and/or other user devices. In one embodiment, the mobile device 611 may use different types of communication channels to provide data to the IoT hub 110 (possibly a higher power communication channel, such as WiFi).

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

As shown in fig. 7, the intermediate connection logic/ applications 701, 711, 721 on each device may be configured based on the current application. For example, for a refrigerator, the connection logic/application 701 may only need to send a few packets periodically. For other applications (e.g., temperature sensors), connection logic/application 701 may need to communicate more frequent updates.

In one embodiment, IoT device 601 (rather than mobile device 611) may be configured to establish a wireless connection with one or more intermediate IoT devices located within range of IoT hub 110. In this embodiment, any IoT device 601 that is out of range of the IoT hub may be linked to the hub by forming a "chain" using other IoT devices.

Additionally, although fig. 6-7 show only a single mobile device 611 for simplicity, in one embodiment, multiple such mobile devices of different users may be configured to communicate with IoT device 601. Also, the same techniques may be implemented for multiple other IoT devices, forming an intermediary device data collection system throughout the home.

Further, in one embodiment, the techniques described herein may be used to collect a variety of different types of relevant data. For example, in one embodiment, the collected data 605 may include the identity of the user whenever the mobile device 611 connects with the IoT device 601. In this way, the IoT system may be used to track the behavior of different users in the home. For example, if the system is used within a refrigerator, the collected data 605 may include the identity of each user passing through the refrigerator, the identity of each user opening the refrigerator, and the particular food consumed by each user. Different types of data may be collected from other types of IoT devices. Using this data, the system can determine, for example, which user washed clothes, which user watched the television on a given day, the time each user went to sleep and wake up, and so forth. All of this crowd-sourced data may then be compiled within IoT hub's data repository 413 and/or forwarded to external services or users.

Another beneficial application of the techniques described herein is for monitoring elderly users who may need assistance. For this application, the mobile device 611 may be a very small token worn by an elderly user to gather information in different rooms in the user's home. For example, whenever the user opens a refrigerator, this data will be included with the collected data 605 and transmitted to the IoT hub 110 via the token. The IoT hub may then provide the data to one or more external users (e.g., children or other individuals in care of elderly users). If no data is collected for a specified period of time (e.g., 12 hours), this means that the elderly user is not moving home and/or does not open the refrigerator. IoT hub 110 or an external service connected to the IoT hub may then send alert notifications to these other individuals informing them that they should view the condition of the elderly user. In addition, the collected data 605 may include other relevant information, such as the food the user is eating, and whether a trip to a grocery store is needed, whether an elderly user is watching television and the frequency with which an elderly user watches television, the frequency with which an elderly user washes clothes, and so forth.

In another implementation, if there is a problem with the electronic equipment, such as a washing machine, refrigerator, HVAC system, etc., the collected data may include an indication of the component that needs to be replaced. In such a case, a notification may be sent to the technician requesting that the problem be resolved. The technician then goes to the user's home with the replacement parts needed.

A method according to one embodiment of the invention is shown in fig. 8. The method may be implemented within the context of the architecture described above, but is not limited to any particular architecture.

At 801, data is periodically collected at IoT devices that are out of range of the IoT hub (e.g., refrigerator doors open, food served, etc.). At 802, the IoT device periodically or continuously checks for connectivity with the mobile device (e.g., establishes a connection using standard local wireless technology, such as that specified by the BTLE standard). If a connection is established with the mobile device, the connection is determined at 802 and the collected data is then transmitted to the mobile device at 803. At 804, the mobile device transmits data to the IoT hub, the external service, and/or the user. As described above, if the mobile device is already connected (e.g., via a WiFi link), the data may be transmitted immediately.

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. One example is shown in fig. 9A, which shows an IoT hub 110 with a program code update 901 that needs 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 needed for the IoT devices to operate as desired by the user. In one embodiment, a user may specify configuration options for IoT device 601 via a mobile device or computer, which are then stored on IoT hub 110 and provided to the IoT device using the techniques described herein. Specifically, in one embodiment, the intermediate connection logic/application 721 on the IoT hub 110 communicates with the intermediate connection logic/application 711 on the mobile device 611 to store the program code updates in the temporary memory 615. When the mobile device 611 comes into range of the IoT device 601, the mediation logic/application 711 on the mobile device 611 connects with the mediation logic/application 701 on the IoT device 601 to provide the program code updates to the device. In one embodiment, IoT device 601 may then enter an automatic update process to install new program code updates and/or data.

The method of updating the 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 provided on the IoT hub and/or external services (e.g., coupled to the mobile device through the internet). At 901, a mobile device receives and stores program code or data updates on behalf of an IoT device. At 902, the IoT device and/or the mobile device periodically check to determine whether a connection has been established. If it is determined at 903 that a connection is established, at 904, the update is transmitted to the IoT device and installed.

Embodiments for improving safety

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 include a security key memory for storing encryption keys used by the embodiments described below (see, e.g., fig. 10-15 and related text). Alternatively, the key may be protected in a Subscriber Identity Module (SIM) as described below.

Fig. 10 illustrates a high-level architecture that uses Public Key Infrastructure (PKI) techniques and/or symmetric key exchange/encryption techniques to encrypt communications among IoT services 120, IoT hubs 110, and IoT devices 101 and 102.

Embodiments using public key/private key pairs will now be described first, followed by embodiments using symmetric key exchange/encryption techniques. Specifically, in embodiments using PKI, a unique public/private key pair is associated with each IoT device 101 and 102, each IoT hub 110, and the IoT service 120. In one embodiment, when a new IoT hub 110 is established, its public key is provided to the IoT service 120, and when a new IoT device 101 is established, its public key is provided to the IoT hub 110 and the 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 (i.e., a form of certificate) known to all receiving devices, such that any receiving device can verify the validity of the public key by verifying the signature. Thus, these certificates will be exchanged, not just the original public key.

As shown, in one embodiment, each IoT device 101, 102 includes a secure key storage 1001, 1003, respectively, for securely storing the private key of each device. The security logic 1002, 1304 then utilizes the securely stored private key to perform the encryption/decryption operations described herein. Similarly, IoT hub 110 includes secure memory 1011 for storing IoT hub private keys and public keys of IoT device 101 and IoT service 120; and security logic 1012 to perform encryption/decryption operations using the key. Finally, the IoT service 120 may include a secure store 1021 for securely storing its own private keys, public keys of various IoT devices and IoT hubs; and security logic 1013 to encrypt/decrypt communications with the IoT hubs and devices using keys. In one embodiment, when IoT hub 110 receives the public key certificate from the IoT device, the IoT hub may verify the certificate (e.g., by verifying the signature using the master key as described above), then extract the public key therefrom, and store the public key in its security key memory 1011.

For example, in one embodiment, when IoT service 120 needs to transmit a command or data to IoT device 101 (e.g., a command to unlock a door, a request to read a sensor, data to be processed/displayed by IoT device, etc.), security logic 1013 encrypts the data/command using the public key of IoT device 101 to generate an encrypted IoT device data packet. In one embodiment, the security logic then encrypts the IoT device data packet using the public key of the IoT hub 110 to generate an IoT hub data packet and transmits the IoT hub data packet to the IoT hub 110. In one embodiment, service 120 signs the encrypted message with the private key or master key described above so that device 101 can verify whether it is receiving an unmodified message from a trusted source. Device 101 may then verify the signature using a public key corresponding to the private key and/or the master key. As described above, symmetric key exchange/encryption techniques may be used instead of public/private key encryption. In these embodiments, rather than storing the keys privately and providing the corresponding public keys to other devices, each device may be provided with a copy of the same symmetric key for use in encrypting and verifying the signature. One example of a symmetric key algorithm is Advanced Encryption Standard (AES), but the underlying principles of the invention are not limited to any particular type of symmetric key.

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

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

In one embodiment, to prevent compromise on the central security module 1012, a one-time (permanent) installation key may be negotiated between the device 101 and the service 120 at installation time. When sending a message to device 101, service 120 may first encrypt/MAC with the device installation key and then encrypt/MAC using the session key of the center. The center 110 will then verify and extract the encrypted device ambiguity and send it to the device.

In one embodiment of the invention, a counter mechanism is employed to prevent replay attacks. For example, each successive communication from device 101 to hub 110 (or vice versa) may be assigned a counter value that is continuously incremented. Both the center 110 and the device 101 will track the value and verify that the value is correct in each successive communication between the devices. The same technique may be implemented between the center 110 and the service 120. Using the counter in this manner will make it more difficult to spoof communications between each device (since the counter value will be incorrect). However, even without this counter mechanism, a shared installation key between the service and the device would prevent a wide range of attacks on the network (hub) of all devices.

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

Communications from IoT devices 101 to IoT hubs 110 and IoT services 120 may be encrypted using different sets of keys. For example, in one embodiment, using the public/private key arrangement, the security logic 1002 on the IoT device 101 encrypts the data packets sent to the IoT hub 110 using the public key of the IoT hub 110. Security logic 1012 on IoT hub 110 may then decrypt the data packet using the IoT hub's private key. Similarly, security logic 1002 on IoT device 101 and/or security logic 1012 on IoT hub 110 may encrypt data packets sent to IoT service 120 using the public key of IoT service 120 (which may then be decrypted by security logic 1013 on IoT service 120 using the private key of the service). Using a symmetric key, device 101 and center 110 may share a symmetric key, while center and service 120 may share a different symmetric key.

Although certain specific details have been set forth in the above description, it should be noted that the underlying principles of the invention may be implemented using a variety of different encryption techniques. For example, while some of the embodiments described above use asymmetric public/private key pairs, alternative embodiments may use symmetric keys that are securely exchanged between the various IoT devices 101 and 102, the IoT hub 110, and the IoT service 120. Further, in some embodiments, the data/command itself is not encrypted, but rather a signature is generated on the data/command (or other data structure) using a key. The recipient can then use its key to verify the signature.

As shown in fig. 11, in one embodiment, the security key storage on each IoT device 101 is implemented using a programmable Subscriber Identity Module (SIM) 1101. In this embodiment, IoT device 101 may be initially provided to an end user through an unprogrammed SIM card 1101 disposed within a SIM interface 1100 on IoT device 101. To program the SIM with a set of one or more encryption keys, the user removes the programmable SIM card 1101 from the SIM interface 500 and inserts it into the SIM programming interface 1102 on the IoT hub 110. Programming logic 1125 on the IoT hub then securely programs SIM card 1101 to register/pair IoT device 101 with IoT hub 110 and 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 key pair may be stored in security storage 411 of the IoT hub, while the private key of the key pair is stored within programmable SIM 1101. Additionally, programming logic 525 may store public keys of IoT hub 110, IoT service 120, and/or any other IoT device 101 on SIM card 1401 (to be used by security logic 1302 on IoT device 101 to encrypt outgoing data). Once the SIM 1101 is programmed, a new IoT device 101 may be provisioned with the IoT service 120 using the SIM as a security identifier (e.g., using existing techniques for registering devices using the SIM). After provisioning, both IoT hub 110 and IoT service 120 will securely store copies of IoT device's public keys to be used when encrypting communications with IoT device 101.

The techniques described above in connection with fig. 11 provide great flexibility in providing new IoT devices to end users. The SIM card can be programmed directly by the end user through the IoT hub 110 and the programmed results can be securely transferred to the IoT service 120 without requiring the user to register each SIM directly with a particular service provider at the time of sale/purchase (as is currently done). Thus, a new IoT device 101 may be sold by an online or local retailer to an end user and then securely provisioned with an IoT service 120.

Although the registration and encryption techniques are described above in the specific context of a SIM (subscriber identity module), the underlying principles of the invention are not limited to "SIM" devices. Rather, any type of secure storage for storing a set of encryption keys may be used to implement the basic principles of the present invention. Also, although the above embodiments include removable SIM devices, in one embodiment, the SIM devices are not removable, but the IoT devices themselves may be inserted into the programming interface 1102 of the IoT hub 110.

In one embodiment, instead of requiring the user to program the SIM (or other device), the SIM is preprogrammed into the IoT device 101 prior to distribution to the end user. In this embodiment, when a user sets up an IoT device 101, encryption keys between the IoT hub 110/IoT service 120 and the new IoT device 101 may be securely exchanged using the various techniques described herein.

For example, as shown in fig. 12A, each IoT device 101 or SIM 401 may be packaged with a barcode or QR code 1501 that uniquely identifies the IoT device 101 and/or SIM 1001. In one embodiment, the barcode or QR code 1201 includes an encoded representation of the public key for the IoT device 101 or SIM 1001. Alternatively, the barcode or QR code 1201 may be used by the IoT hub 110 and/or the IoT service 120 to identify or generate a public key (e.g., to use as a public key pointing to a secure store). 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 is equipped with barcode reader 206 for reading the barcode and providing the resulting data to security logic 1012 on IoT hub 110 and/or security logic 1013 on IoT service 120. Security logic 1012 on IoT hub 110 may then store the public key of the IoT device within its security key storage 1011, and security logic 1013 on IoT service 120 may store the public key within its security storage 1021 (for subsequent encrypted communications).

In one embodiment, the data contained in the barcode or QR code 1201 may also be captured by a user device 135 (e.g., such as an iPhone or Android device) installed with an IoT application or browser-based applet designed by the IoT service provider. Once captured, the barcode data may be securely transmitted to the IoT service 120 over a secure connection, such as a Secure Sockets Layer (SSL) connection, for example. The barcode data may also be provided from the client device 135 to the IoT hub 110 over a secure local connection (e.g., over a local WiFi or bluetooth LE connection).

Security logic 1002 on IoT device 101 and security logic 1012 on IoT hub 110 may be implemented using hardware, software, firmware, or any combination thereof. For example, in one embodiment, the security logic 1002, 1012 is implemented within a chip (e.g., a bluetooth LE chip if the local channel 130 is bluetooth LE) used to establish the local communication channel 130 between the IoT device 101 and the IoT hub 110. Regardless of the specific location of the security logic 1002, 1012, in one embodiment, the security logic 1002, 1012 is designed to establish a secure execution environment for executing certain types of program code. This may be accomplished, for example, by using TrustZone technology (available on some ARM processors) and/or trusted execution technology (designed by Intel). Of course, the underlying principles of the invention are not limited to any particular type of secure execution technology.

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 procedure currently used to pair bluetooth LE devices, pairing codes embedded within barcode or QR code 1501 may be provided to IoT hub 110 to pair the IoT hub with the corresponding IoT device.

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

Similarly, in terms of IoT devices 101, local communication module 1590 stores pairing data within local secure storage 1595 indicating pairing with the IoT hub. The pairing data 1295 may include a pre-programmed pairing code identified in the barcode/QR code 1201. Pairing data 1295 can also include pairing data received from local communication module 1280 on IoT hub 110 (e.g., an additional key to encrypt communications with IoT hub 110) needed to establish a secure local communication channel.

Because the pairing code is not transmitted wirelessly, the barcode/QR code 1201 may be used to perform local pairing in a more secure manner than current wireless pairing protocols. Additionally, in one embodiment, the same barcode/QR code 1201 used for pairing may be used to identify the encryption key to establish the secure connection from IoT device 101 to IoT hub 110 and from IoT hub 110 to IoT service 120.

Figure 13 illustrates a method for programming a SIM card according to one embodiment of the present invention. 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 a blank SIM card with 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 and store the private key on the SIM card and the public key in its local secure storage. Additionally, at 1304, at least the public key is transmitted to an IoT service such that it can be used to identify an IoT device and establish encrypted communication with the IoT device. As described above, in one embodiment, programmable devices other than a "SIM" card may be used in the method shown in fig. 13 to perform the same functions as a SIM card.

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

At 1401, a user receives a new IoT device that has been pre-assigned an encryption key. At 1402, the key is securely provided to the IoT hub. As described above, in one embodiment, this involves reading a barcode associated with an IoT device to identify the public key of the public/private key pair assigned to that device. The barcode may be read directly by the IoT hub or may be captured by the mobile device through an application or browser. In alternative embodiments, 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 the key. Regardless of how the key is transmitted, once received, it is stored in a security keystore of the IoT hub device. As described above, various security enforcement technologies may be used on the IoT hub to store and protect keys, such as secure enclaves, trusted enforcement technologies (TXT), and/or Trustzone. Additionally, at 803, the key is securely transmitted to the IoT service, which stores the key in its own secure keystore. It may then use the key to encrypt communications with the IoT device. Again, the exchange may be effected using a certificate/signed key. Within the center 110, it is particularly important to prevent modification/addition/removal of stored keys.

Fig. 15 illustrates a method for securely transmitting commands/data to IoT devices using public/private keys. The method may be implemented within the system architecture described above, but is not limited to any particular system architecture.

At 1501, the IoT service encrypts the data/command using the IoT device public key to create an IoT device data packet. The IoT device data packet is then encrypted using the public key of the IoT hub to create an IoT hub data packet (e.g., create an IoT hub wrapper around the IoT device data packet). At 1502, the IoT service transmits an IoT hub data packet to the IoT hub. At 1503, the IoT hub decrypts the IoT hub data packet using the IoT hub's private key to generate an IoT device data packet. Then, at 1504, it transmits the IoT device data packet to the IoT device, and at 1505, decrypts the IoT device data packet using the IoT device private key to generate the data/command. At 1506, the IoT device processes the data/command.

In embodiments using symmetric keys, a symmetric key exchange may be negotiated between each device (e.g., between each device and the center and between the center and the service). Once the key exchange is complete, each transmitting device encrypts and/or signs each transmission with the symmetric key before transmitting 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, regardless of the intermediary device used to support the communication channel (e.g., such as the user's mobile device 611 and/or the IoT hub 110), encryption and decryption of data is performed between the IoT service 120 and each IoT device 101. Fig. 16A shows one embodiment of communicating through IoT hubs 110, while fig. 16B shows another embodiment that does not require an IoT hub.

Turning first to fig. 16A, IoT service 120 includes an encryption engine 1660 that manages a set of "service session keys" 1650, and each IoT device 101 includes an encryption engine 1661 that manages a set of "device session keys" 1651 for encrypting/decrypting communications between IoT device 101 and IoT service 120. When performing the security/encryption techniques described herein, the encryption engine may rely on different hardware modules including a hardware security module 1630-. In one embodiment, service session key 1650 and device session key 1651 comprise related public/private key pairs. For example, in one embodiment, the device session key 1651 on the IoT device 101 includes the public key of the IoT service 120 and the private key of the IoT device 101. As discussed in detail below, in one embodiment, to establish a secure communication session, each encryption engine 1660 and 1661 generates the same cryptogram using a public/private session key pair 1650 and 1651, respectively, which is then used by SKGM 1640-. Additional details associated with the generation and use of passwords according to one embodiment of the present invention are provided below.

In fig. 16A, once the password is generated using key 1650 and 1651, the client will always send a message to IoT device 101 through IoT service 120, as shown by clear transaction 1611. As used herein, "clear" is meant to indicate that the underlying message was not encrypted using the encryption techniques described herein. However, as shown, in one embodiment, a Secure Sockets Layer (SSL) channel or other secure channel (e.g., an Internet Protocol Security (IPSEC) channel) is established between the client device 611 and the IoT service 120 to secure communications. The encryption engine 1660 on the IoT service 120 then encrypts the message using the generated password and transmits the encrypted message to the IoT hub 110 at 1602. In one embodiment, rather than directly encrypting the message using the cipher, the cipher and counter values are used to generate a keystream for encrypting each message packet. Details of this embodiment are described below in conjunction with fig. 17.

As shown, an SSL connection or other secure channel may be established between the IoT service 120 and the IoT hub 110. IoT hub 110, which in one embodiment does not have the capability to decrypt the message, transmits the encrypted message to the IoT device at 1603 (e.g., over a bluetooth low energy (BTLE) communication channel). Encryption engine 1661 on IoT device 101 may then decrypt the message using the password and process the message content. In embodiments where a cipher is used to generate the keystream, encryption engine 1661 may use the cipher and the counter value to generate the keystream and then use the keystream to decrypt the message packets.

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 IoT device 101 to perform a particular function, such as taking measurements and reporting the results back to client device 611, or may include configuration data for configuring the operation of IoT device 101.

If a response is needed, at 1604, encryption engine 1661 on IoT device 101 encrypts the response using the password or derived keystream and transmits the encrypted response to IoT hub 110, which forwards the response to IoT service 120 at 1605. Then at 1606 (e.g., over SSL or other secure communication channel), the encryption engine 1660 on the IoT service 120 decrypts the response using the password or derived keystream and transmits the decrypted response to the client device 611.

Fig. 16B illustrates an embodiment that does not require an IoT hub. Rather, in this embodiment, communication between IoT device 101 and IoT service 120 occurs through client device 611 (e.g., as described above in connection with fig. 6-9B). In this embodiment, to transmit the message to IoT device 101, client device 611 transmits the unencrypted version of the message to IoT service 120 at 1611. At 1612, the encryption engine 1660 encrypts the message using the cipher or derived keystream and transmits the encrypted message back to the client device 611. The client device 611 then forwards the encrypted message to the IoT device 101 at 1613, and the encryption engine 1661 decrypts the message using the cryptogram or derived keystream. IoT device 101 may then process the message as described herein. If a response is needed, encryption engine 1661 encrypts the response using the password and transmits the encrypted response to client device 611, which forwards the encrypted response to IoT service 120 at 1615, at 1614. The encryption engine 1660 then decrypts the response and transmits the decrypted response to the client device 611 at 1616.

Fig. 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 each time the IoT service 120 and the IoT device 101 establish a new communication session. Alternatively, a key exchange may be performed, and the exchanged session key may be used for a specified period of time (e.g., one day, one week, etc.). Although intermediary devices are not shown in fig. 17 for simplicity, communications may occur through IoT hubs 110 and/or client devices 611.

In one embodiment, the encryption engine 1660 of the IoT service 120 sends a command to the HSM 1630 (e.g., which may be CloudHSM such as provided by Amazon) to generate a session public/private key pair. Subsequently, HSM 1630 may prevent access to the private session key in the key pair. Similarly, the encryption engine on the IoT device 101 may send the HSM 1631 (e.g., available from Atmel

Atecc508 HSM), HSM 1631 generates a session public/private key pair and prevents access to the session private key in the key pair. Of course, the underlying principles of the invention are not limited to any particular type of encryption engine or manufacturer.

In one embodiment, at 1701, the IoT service 120 transmits the session public key generated using the HSM 1630 to the IoT device 101. The IoT device generates its own session public/private key pair using its HSM 1631 and transmits the public key of its key pair to the IoT service 120 at 1702. In one embodiment, encryption engine 1660-1661 uses the elliptic curve Diffie-Hellman (ECDH) protocol, which is an anonymous key agreement that allows both parties to have elliptic curve public-private key pairs, to establish a shared secret. Using these techniques, at 1703, in one embodiment, encryption engine 1660 of IoT service 120 generates a password 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 generates the same password using the IoT service 120 session public key and its own session private key separately. More specifically, in one embodiment, the encryption engine 1660 on the IoT service 120 generates the password according to the following formula: the password IoT device session public key IoT service session private key, where' denotes that the IoT device session public key is multiplied by the IoT service session private key in a point-to-point manner. The encryption engine 1661 on the IoT device 101 generates a password according to the following formula: the method further includes multiplying the IoT device session private key by the IoT service session public key in a point-to-point manner. Finally, as described below, both IoT service 120 and IoT device 101 have generated the same password used to encrypt the communication. In one embodiment, encryption engines 1660- > 1661 rely on hardware modules such as KSGM1640- > 1641, respectively, to perform the operations described above for generating passwords.

Once the secret has been determined, it can be used by the encryption engines 1660 and 1661 to directly encrypt and decrypt data. Alternatively, in one embodiment, encryption engine 1660-1661 sends a command to KSGM1640-1641 to generate a new keystream using a cipher to encrypt/decrypt each packet (i.e., to generate a new keystream data structure for each packet). In particular, one embodiment of the keystream generation module 1640-1641 employs a Galois/counter mode (GCM) in which a counter value is incremented for each packet and used in combination with a key to generate a keystream. Thus, to transmit the data packet to the IoT service 120, the encryption engine 1661 of the IoT device 101 uses the password and the current counter value to cause KSGM 1640-. The newly generated keystream is then used to encrypt the data packet prior to transmission to the IoT service 120. In one embodiment, the keystream is exclusive-or (XOR) operated on with the data to generate an encrypted data packet. In one embodiment, IoT device 101 transmits the counter value with the encrypted data packet to IoT service 120. Encryption engine 1660 on the IoT service then communicates with KSGM1640, which generates a keystream using the received counter value and cipher (which should be the same keystream since the same cipher and counter value were used) and decrypts the packet using the generated keystream.

In one embodiment, data packets transmitted from IoT service 120 to IoT device 101 are encrypted in the same manner. Specifically, a counter is incremented for each data packet and used with the cipher to generate a new keystream. The key stream is then used to encrypt the data (e.g., perform an XOR operation of the data and the key stream), and the encrypted data packet is transmitted to IoT device 101 along with the counter value. Encryption engine 1661 on IoT device 101 then communicates with KSGM1641, which KSGM1641 uses the counter value and the cipher to generate the same keystream for decrypting the packet. Thus, in this embodiment, encryption engines 1660-1661 generate keystreams for encrypting data using their own counter values, and generate keystreams for decrypting data using counter values received with the encrypted data packets.

In one embodiment, each encryption engine 1660-1661 tracks the last counter value it received from the other encryption engine and includes ordering logic to detect whether the counter values are received out of order or whether the same counter value is received multiple times. If one counter value is received out of order, or if the same counter value is received multiple times, this may indicate that a replay attack is being attempted. In response, encryption engine 1660-1661 may disconnect from the communication channel and/or may generate a security alert.

Fig. 18 illustrates an exemplary encrypted data packet including a 4-byte counter value 1800, a variable-size encrypted data field 1801, and a 6-byte tag 1802 employed in one embodiment of the present invention. In one embodiment, tag 1802 includes a checksum value to verify the decrypted data (once the data has been decrypted).

As described above, in one embodiment, the session public/private key pair 1650- "1651 exchanged between IoT service 120 and IoT device 101 may be generated periodically and/or in response to the initiation of each new communication session.

One embodiment of the present invention implements additional techniques for authenticating a session between an IoT service 120 and an IoT device 101. Specifically, in one embodiment, a hierarchy of public/private key pairs is used, including 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 includes a root of trust for all other key pairs and is maintained in a single highly secure location (e.g., under the control of an organization implementing the IoT system described herein). The master private key may be used to generate signatures (and thus verify) against various other key pairs, such as a factory key pair. The master public key may then be used to verify the signature. In one embodiment, each factory that manufactures the IoT devices is assigned its own factory key pair, which can then be used to authenticate the IoT service key and the IoT device key. For example, in one embodiment, the factory private key is used to generate signatures for the IoT service public key and the IoT device public key. These signatures can then be verified using the corresponding factory public key. Note that these IoT service/device public keys are different from the "session" public/private keys described above in connection with fig. 16A-16B. The session public/private keys described above are temporary (i.e., generated for service/device sessions), while the IoT service/device key pairs are permanent (i.e., generated at the factory).

In view of the above-described relationship between master keys, factory keys, service/device keys, one embodiment of the present invention performs the following to provide an additional layer of authentication and security between IoT services 120 and IoT devices 101:

A. in one embodiment, the IoT service 120 initially generates a message that contains:

unique ID of IoT service:

sequence number of IoT service;

a timestamp;

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

the category of the unique ID (i.e., service);

public keys for IoT services

The signature on the unique ID.

2. The factory certificate includes:

time stamp

ID of the master key used to sign the certificate

Public Key of the factory

Signature of factory certificate

IoT service session public key (as described above in connection with FIGS. 16A-16B)

IoT service Session public Key signature (e.g., Using IoT service's private Key signature)

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

1. verifying the signature of the factory certificate (only if it is present in the message payload)

2. Verifying signatures of unique IDs using keys identified by the unique IDs

3. Verifying IoT service session public key signatures using public keys of IoT services from unique IDs

4. Maintaining public keys of IoT services and session public keys of IoT services

5. Generating IoT device session key pairs

The iot device then generates a message containing:

unique ID of IoT device

IoT device sequence number

Time stamp

ID of factory key used to sign this unique ID

Class of unique ID (i.e., IoT device)

Public keys of IoT devices

Signature of unique ID

Session public Key for IoT devices

3. Signature signed using key of IoT device (IoT device session public key + IoT service session public key)

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

1. verifying signatures of unique IDs using factory public keys

2. Verifying a signature of a session public key using a public key of an IoT device

3. Maintaining session public keys for IoT devices

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

Iot devices parse messages and:

1. verifying a signature of a session public key using a public key of an IoT service

2. Generating a keystream from an IoT device session private key and an IoT service session public key

The IoT device then sends a "messaging available" message.

The iot service then performs the following operations:

1. generating a keystream from an IoT device session private key and an IoT device's session public key

2. Creating a new message on the messaging channel containing:

generating and storing random 2-byte values

Set attribute message with boomerang (boomerang) attribute Id (described below) and random value

The iot device receives the message and:

1. attempt to decrypt the message

2. Issuing updates on specified attribute Ids using the same values

Iot service identifies a message payload containing boomerang attribute updates and:

1. set its pairing status to true

2. Sending pairing complete messages on a negotiation channel

Iot device receives the message and sets its pairing state to true

Although the above-described techniques are described with respect to "IoT services" and "IoT devices," the underlying principles of the invention may be implemented to establish a secure communication channel between any two devices, including a user client device, a server, and an internet service.

The above technique is highly secure because the private key is never shared wirelessly (in contrast to current bluetooth pairing techniques where the password is transmitted from one party to the other). An attacker eavesdropping on the entire conversation has only public keys, which are not sufficient to generate a shared secret. These techniques also prevent man-in-the-middle attacks by exchanging signed public keys. In addition, since the GCM and separate counters are used on each device, any type of "replay attack" (in which case the man-in-the-middle captures the data and sends it again) can be prevented. Some embodiments also prevent replay attacks by using asymmetric counters.

Techniques to exchange data and commands without formal pairing of devices

GATT is an acronym for general Attribute Profile (Generic Attribute Profile), and defines the way two bluetooth low energy (BTLE) devices transfer data back and forth. It utilizes a generic data protocol called attribute protocol (ATT) for storing services, features and related data in a simple look-up table, using a 16-bit feature ID for each entry in the table. Note that although "features" are sometimes referred to as "attributes".

On bluetooth devices, the most common feature is the device "name" (with feature ID 10752(0 × 2a 00)). For example, a bluetooth device may identify other bluetooth devices in its vicinity by using the GATT to read the "name" feature issued by those other bluetooth devices. Thus, Bluetooth devices have the inherent ability to exchange data without the need for formal pairing/binding devices (note that "pairing" and "binding" are sometimes used interchangeably; the remainder of this discussion will use the term "pairing").

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

Fig. 19 illustrates one particular 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 positively establishing a paired BT connection. BT device 1910 may be included in IoT hub 110 and/or client device 611 as shown in fig. 16A. As shown, the BT communication module 1901 maintains a data structure containing a list of feature IDs, names associated with the feature IDs, and values of the feature IDs. According to the current BT standard, the value of each feature may be stored in a 20-byte buffer identified by the feature ID. However, the underlying principles of the invention are not limited to any particular buffer size.

In the example of fig. 19, the "name" feature is a BT-defined feature assigned to a particular value of the "IoT device 14". One embodiment of the present invention specifies a first set of additional features to be used for negotiating a secure communication channel with the BT device 1910 and a second set of additional features to be used for encrypted communications with the BT device 1910. In particular, in the illustrated example, a "negotiate write" feature identified by feature ID <65532> may be used to transmit outgoing negotiation messages, and a "negotiate read" feature identified by feature ID <65533> may be used to receive incoming negotiation messages. The "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. For example, in fig. 17, IoT device 101 may receive IoT service session common key 1701 via a "negotiate read" feature <65533 >. The key 1701 may be transmitted from the IoT service 120 to the BTLE enabled IoT hub 110 or client device 611 and then the GATT may be used to write the key 1701 to the negotiated read value buffer identified by feature ID <65533 >. IoT device application logic 1902 may then read key 1701 from the value buffer identified by feature ID <65533> and process it as described above (e.g., use it to generate a cryptogram and use it to generate a keystream, etc.).

If the key 1701 is larger than 20 bytes (maximum buffer size in some current implementations), the key may be written in 20 byte portions. For example, the first 20 bytes may be written to feature ID <65533> by BT communication module 1903 and read by IoT device application logic 1902, which may then write an acknowledgement message to the negotiated write value buffer identified by feature ID <65532 >. Using the GATT, the BT communication module 1903 may read the acknowledgement from feature ID <65532> and responsively write the next 20 bytes of the key 1701 to the negotiated read value buffer identified by feature ID <65533 >. In this manner, a network socket abstraction defined by feature IDs <65532> and <65533> is established to exchange negotiation messages for establishing a secure communication channel.

In one embodiment, once the secure communication channel is established, a second network socket abstraction is established using feature ID <65534> (for transmitting encrypted packets from IoT device 101) and feature ID <65533> (for receiving encrypted packets over the IoT device). That is, when the BT communication module 1903 has an encrypted packet (e.g., such as encrypted message 1603 of fig. 16A) for transmission, it starts writing the encrypted packet 20 bytes at a time using the message read value buffer identified by feature ID <65533 >. IoT device application logic 1902 will then read the encrypted data packet from the read value buffer, 20 bytes at a time, sending an acknowledgement message to the BT communication module 1903 via the write value buffer identified by feature ID <65532> as needed.

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, BT communication module 1903 may send a packet identifying feature ID <65533> and containing the SET command to write the value field/buffer identified by feature ID <65533>, which may then be read by IoT device application logic 1902. To retrieve data from the IoT device 101, the BT communication module 1903 may transmit a GET command directed to the value field/buffer identified by feature ID <65534 >. In response to the GET command, the BT communication module 1901 may transmit an UPDATE packet to the BT communication module 1903 that contains data from the value field/buffer identified by feature ID <65534 >. Additionally, UPDATE packets may be automatically transmitted in response to changes in particular attributes on IoT devices 101. For example, if an IoT device is associated with a lighting system and a user turns on a light, an UPDATE data packet may be sent to reflect the change in the on/off attributes associated with the lighting application.

FIG. 20 illustrates exemplary packet formats for a GET, SET, and UPDATE, according to one embodiment of the invention. In one embodiment, these packets are transmitted after negotiation via message write <65534> and message read <65533> channels. In GET packet 2001, the first 1-byte field includes a value (0 × 10) that identifies the packet as a GET packet. The second 1-byte field includes a request ID that uniquely identifies the current GET command (i.e., identifies the current transaction with which the GET command is associated). For example, each instance of a GET command transmitted from a service or device may be assigned a different request ID. This may be done by, for example, incrementing a counter and using the counter value as the request ID. However, the underlying principles of the invention are not limited to any particular manner of setting the request ID.

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

The SET packet 2002 and UPDATE packet 2003 shown in FIG. 20 also include a first 1-byte field that identifies the packet type (i.e., SET and UPDATE), a second 1-byte field that contains the request ID, and a 2-byte attribute ID field that identifies the application-defined attribute. In addition, the SET packet includes a 2-byte length value identifying the length of data contained in the n-byte value data field. The value data fields may include commands to be executed on the IoT device and/or configuration data to configure the operation of the IoT device in some manner (e.g., set desired parameters, shut down the IoT device, etc.). For example, if IoT device 101 controls the speed of a fan, the value field may reflect the current fan speed.

The UPDATE packet 2003 may be transmitted to provide an UPDATE of the result of the SET command. The UPDATE data packet 2003 includes a 2-byte length value field to identify the length of an n-byte value data field that may include data related to the result of the SET command. Additionally, a 1-byte update status field may identify the current state of the variable being updated. For example, if the SET command attempts to turn off light controlled by the IoT device, the update status field may indicate whether the light was successfully turned off.

Fig. 21 shows an exemplary sequence of transactions between the IoT service 120 and the IoT device 101 involving the SET command and the UPDATE command. Intermediate devices such as IoT hubs and mobile devices of users are not shown to avoid obscuring the underlying principles of the invention. At 2101, a SET command 2101 is transmitted from the IoT service to the IoT device 101 and received by the BT communication module 1901, which responsively updates the GATT value buffer identified by the feature ID at 2102. At 2103, the SET command is read from the value buffer by the low power Microcontroller (MCU)200 (or by program code executing on the low power MCU, such as IoT device application logic 1902 shown in fig. 19). At 2104, MCU 200 or program code performs an operation in response to the SET command. For example, the SET command may include an attribute ID specifying a new configuration parameter, such as a new temperature, or may include a state value, such as on/off (to bring the IoT device into an "on" or low power state). Thus, the new value is set in the IoT device at 2104, and the UPDATE command is returned at 2105, updating the actual value in the GATT value field at 2106. In some cases, the actual value will be equal to the desired value. In other cases, the updated values may be different (i.e., because IoT devices 101 may require time to update certain types of values). Finally, at 2107, the UPDATE command is transmitted back to the IoT service 120 containing the actual value from the GATT value field.

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

At 2201, the IoT service creates an encrypted channel for communicating with the IoT hub using an Elliptic Curve Digital Signature Algorithm (ECDSA) certificate. At 2202, the IoT service encrypts data/commands in the IoT device data packet using the session cipher to create an encrypted device data packet. As described above, the session password may be generated independently by the IoT device and the IoT service. At 2203, the IoT service transmits the encrypted device data packet to the IoT hub over the encrypted channel. At 2204, the IoT hub passes the encrypted device data packet to the IoT device without decryption. At 22-5, the IoT device decrypts the encrypted device data packet using the session cipher. As described above, in one embodiment, this may be accomplished by: the cipher and counter values (provided with the encrypted device packet) are used to generate a keystream, which is then used to decrypt the packet. At 2206, the IoT device then extracts and processes the data and/or commands contained within the device data packet.

Thus, using the techniques described above, a bi-directional, secure network socket abstraction can be established between two BT-enabled devices without formally pairing the BT devices using standard pairing techniques. While the techniques are described above with respect to IoT devices 101 communicating with IoT services 120, the underlying principles of the invention may be implemented to negotiate and establish a secure communication channel between any two BT-enabled devices.

Fig. 23A to 23C show 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 creates a data packet containing the IoT service's sequence number and a public key. At 2302, the IoT service signs the data packet using the factory private key. At 2303, the IoT service sends the data packet to the IoT hub over the encrypted channel, and at 2304, the IoT hub forwards the data packet to the IoT device over the unencrypted channel. At 2305, the IoT device verifies the signature of the data packet, and at 2306, the IoT device generates a data packet containing the IoT device's sequence number and a public key. At 2307, the IoT device signs the data packet using the factory private key, and at 2308, the IoT device sends the data packet over the unencrypted channel to the IoT hub.

At 2309, the IoT hub forwards the packet to the IoT service over 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 data packet containing a session public key. The IoT service then signs the data packet with the IoT service private key at 2313 and the IoT service sends the data packet over the encrypted channel to the IoT hub at 2314.

Turning to fig. 23B, the IoT hub forwards the packet to the IoT device over the unencrypted channel at 2315, and the IoT device verifies the signature of the packet at 2316. At 2317, the IoT device generates a session key pair (e.g., using the techniques described above), and at 2318, generates an IoT device data packet containing an IoT device session public key. At 2319, the IoT device signs the IoT device data packet using the IoT device private key. At 2320, the IoT device sends the data packet to the IoT hub over the unencrypted channel, and at 2321, the IoT hub forwards the data packet to the IoT service over the encrypted channel.

At 2322, the IoT service verifies the signature of the data packet (e.g., using the IoT device public key), and at 2323, the IoT service generates a session password using the IoT service private key and the IoT device public key (as described in detail above). At 2324, the IoT device generates a session password using the IoT device private key and the IoT service public key (again as described above), and at 2325, the IoT device generates a random number and encrypts it using the session password. At 2326, the IoT service sends the encrypted data packet to the IoT hub over the encrypted channel. At 2327, the IoT hub forwards the encrypted data packet to the IoT device over the unencrypted channel. At 2328, the IoT device decrypts the data packet using the session password.

Turning to fig. 23C, at 2329, the IoT device re-encrypts the data packet using the session password, and at 2330, the IoT device sends the encrypted data packet over the unencrypted channel to the IoT hub. At 2331, the IoT hub forwards the encrypted data packet to the IoT service over the encrypted channel. At 2332, the IoT service decrypts the data packet using the session cipher. At 2333, the IoT service verifies that the random number matches the random number it sent. The IoT service then sends a data packet indicating that the pairing is complete at 2334, and encrypts all subsequent messages using the session cipher at 2335.

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

As described herein, instructions may refer to a particular hardware configuration, such as an Application Specific Integrated Circuit (ASIC), configured to perform certain operations or having predetermined functions or software instructions stored in a memory embodied in a non-transitory computer readable medium. Thus, the techniques illustrated in the figures can be implemented using code and data stored and executed on one or more electronic devices (e.g., an end station, a network element, etc.). Such electronic devices store and communicate (internally and/or with other electronic devices on a network) code and data using a computer-machine-readable medium, such as a non-transitory computer-machine-readable storage medium (e.g., a magnetic disk; an optical disk; a random access memory; a read only memory; a flash memory device; a phase-change memory) and a transitory computer-machine-readable communication medium (e.g., an electrical, optical, acoustical or other form of propagated signals — such as carrier waves, infrared signals, digital signals, etc.). Further, such electronic devices typically include a set of one or more processors connected to one or more other components, such as one or more storage devices (non-transitory machine-readable storage media), user input/output devices (e.g., a keyboard, a touchscreen, and/or a display), and a network connection. The coupling of the processor book and other components is typically done through one or more buses and bridges (also called bus controllers). The storage devices and the signals carrying network traffic represent one or more machine-readable storage media and machine-readable communication media, respectively. Thus, the memory device of a given electronic device typically stores code and/or data for execution on a set of one or more processors of the electronic device. Of course, different combinations of software, firmware, and/or hardware may be used to implement one or more portions of embodiments of the invention.

Throughout the detailed description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, 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 so as not to obscure the subject matter of the present invention. Accordingly, the scope and spirit of the invention should be determined from the appended claims.

Claims (16)

1. A system, comprising:

an Internet of things service for establishing communication with an Internet of things device through an Internet of things center or a mobile user device;

a first cryptographic circuit on the internet of things service, the first cryptographic circuit comprising key generation logic to generate a service public key and a service private key;

a second cryptographic circuit on the internet of things device, the second cryptographic circuit comprising key generation logic to generate a device public key and a device private key;

the first encryption circuit is to transmit the service public key to the second encryption circuit and the second encryption circuit is to transmit the device public key to the first encryption circuit;

the first encryption circuit generates a cipher using the device public key and the service private key;

the second encryption circuit generates the same password using the service public key and the device private key;

wherein the first encryption circuit and the second encryption circuit encrypt and decrypt data packets transmitted between the first encryption circuit and the second encryption circuit using a data structure derived from the cipher once the cipher is generated, wherein the data structure derived from the cipher comprises a first keystream generated by the first encryption circuit and a second keystream generated by the second encryption circuit; and

a first counter associated with the first encryption circuit and a second counter associated with the second encryption circuit, the first encryption circuit incrementing the first counter in response to each data packet transmitted to the second encryption circuit, and the second encryption circuit incrementing the second counter in response to each data packet transmitted to the first encryption circuit.

2. The system of claim 1, wherein the key generation logic comprises a Hardware Security Module (HSM).

3. The system of claim 1, wherein the first encryption circuit generates the first keystream using a current counter value of the first counter and the cipher, and the second encryption circuit generates the second keystream using a current counter value of the second counter and the cipher.

4. The system of claim 3, wherein the first encryption circuit includes an elliptic curve method module for generating the first keystream using the current counter value and the cipher, and the second encryption circuit includes an elliptic curve method module for generating the second keystream using the current counter value and the cipher.

5. The system of claim 3, wherein the first encryption circuit encrypts a first packet using the first keystream to generate a first encrypted packet and transmits the first encrypted packet to the second encryption circuit along with a current counter value of the first counter.

6. The system of claim 5, wherein the second encryption circuit generates the first keystream using the current counter value of the first counter and the cipher, and decrypts the encrypted data packets using the first keystream.

7. The system of claim 5, wherein encrypting the first data packet comprises xoring the first keystream with the first data packet to generate the first encrypted data packet.

8. The system as recited in claim 6, wherein the internet of things device includes a Bluetooth Low energy (BTLE) communication interface for communicatively coupling the internet of things device to the internet of things center or the mobile user device, the internet of things center or the mobile user device communicatively coupled to the internet of things service over the internet.

9. A computer-implemented method, the method comprising:

establishing communication between the internet of things service and the internet of things device through the internet of things center or the mobile user device;

generating, by key generation logic of a first cryptographic circuit on the internet of things service, a service public key and a service private key;

generating, by key generation logic of a second cryptographic circuit on the internet of things device, a device public key and a device private key;

transmitting the service public key from the first encryption circuit to the second encryption circuit and the device public key from the second encryption circuit to the first encryption circuit;

generating a password using the device public key and the service private key;

generating a same password using the service public key and the device private key; and

encrypting and decrypting data packets transmitted between the first encryption circuit and the second encryption circuit using a cryptographically derived data structure, wherein the cryptographically derived data structure comprises a first keystream generated by the first encryption circuit and a second keystream generated by the second encryption circuit, and

wherein a first counter is associated with the first encryption circuit and a second counter is associated with the second encryption circuit, the first encryption circuit incrementing the first counter in response to each data packet transmitted to the second encryption circuit, and the second encryption circuit incrementing the second counter in response to each data packet transmitted to the first encryption circuit.

10. The method of claim 9, wherein the key generation logic comprises a Hardware Security Module (HSM).

11. The method of claim 9, wherein the first encryption circuit generates the first keystream using a current counter value of the first counter and the cipher, and the second encryption circuit generates the second keystream using a current counter value of the second counter and the cipher.

12. The method of claim 11, wherein the first encryption circuit includes an elliptic curve method module for generating the first keystream using the current counter value and the cipher, and the second encryption circuit includes an elliptic curve method module for generating the second keystream using the current counter value and the cipher.

13. The method of claim 11, wherein the first encryption circuit encrypts a first packet using the first keystream to generate a first encrypted packet and transmits the first encrypted packet to the second encryption circuit along with a current counter value of the first counter.

14. The method of claim 13, wherein the second encryption circuit generates the first keystream using the current counter value of the first counter and the cipher, and decrypts the encrypted data packets using the first keystream.

15. The method of claim 13, wherein encrypting the first data packet comprises xoring the first keystream with the first data packet to generate the first encrypted data packet.

16. The method of claim 14, wherein the internet of things device comprises a bluetooth low energy (BTLE) communication interface for communicatively coupling the internet of things device to the internet of things center or the mobile user device, the internet of things center or the mobile user device communicatively coupled to the internet of things service over the internet.

Images