A system for smart device networking includes an endpoint that enables communication with a connected device, a bridge that communicates with the endpoint over a PAN and relays PAN communications to a wan, and a router that connects to the bridge through the wan and routes communication to and from the endpoint.
|
14. A system for smart device networking comprising:
a first endpoint operable to enable communication with a connected device and to encrypt a first frame based on a first cryptographic key and a nonce, the first endpoint comprising:
a hardware encryption module storing the first cryptographic key; and
a first multi-band radio operable to transmit the first frame;
a bridge comprising:
a second multi-band radio operable to receive the first frame from the first multi-band radio on a broadcast spectrum of a set of broadcast spectra; and
a wan communications module operable to communicatively couple to a wan; and
a server system connected to the bridge through the wan, wherein the server system is operable to:
store a second cryptographic key associated with the first endpoint;
receive the first frame through the wan; and
decrypt the first frame based on the second cryptographic key and the nonce.
1. A system for smart device networking comprising:
an endpoint operable to enable communication with a connected device and to encrypt a frame based on a cryptographic key and a mac address of the endpoint, wherein the endpoint comprises:
a hardware encryption module storing the cryptographic key; and
a first multi-band radio operable to transmit the frame;
a bridge comprising:
a second multi-band radio operable to receive the frame from the first multi-band radio on a broadcast spectrum of a set of broadcast spectra; and
a wide area network (wan) communications module operable to communicatively couple to a wan; and
a server system remote from the endpoint and connected to the bridge through the wan, wherein the server system is operable to:
receive the frame through the wan;
extract the mac address of the endpoint from the frame;
identify the cryptographic key based on the mac address of the endpoint; and
decrypt the frame based on the cryptographic key.
2. The system of
a key server operable to:
store the cryptographic key in association with the mac address of the endpoint; and
generate a first session key based on the cryptographic key and the mac address of the endpoint; and
a first server operable to:
store the first session key received from the key server; and
decrypt first communications from the endpoint using the first session key.
3. The system of
wherein the endpoint is operable to:
generate a join key based on the mac address and the cryptographic key; and
encrypt the frame using the join key; and
wherein the server system is operable to:
generate the join key based on the mac address and the cryptographic key in response to receiving the join request; and
verify the join request using the join key.
4. The system of
wherein the key server is operable to transmit the join key to the first router in response to generating the join key;
wherein the first router is operable to, in response to decrypting the frame using the join key:
store the first session key; and
transmit, to the endpoint, a join response frame encrypted with the first session key; and
wherein the endpoint is operable to generate and store the first session key based on the join response frame.
5. The system of
generate a second session key based on the cryptographic key and the mac address after a predetermined period of time from generation of the first session key;
control the endpoint to delete the first session key stored at the endpoint; and
decrypt second communications, received from the endpoint after the predetermined period of time, using the second session key.
6. The system of
generate a third session key based on the cryptographic key and the mac address in response to enabling communication between the endpoint and the second router; and
decrypt third communications from the endpoint using the third session key.
7. The system of
wherein the endpoint is operable to:
combine the mac address of the endpoint and a nonce to create a mac+nonce value; and
encrypt the frame based on the cryptographic key and the mac+nonce value; and
wherein the server system is operable to decrypt the frame based on the cryptographic key and the mac+nonce value.
8. The system of
wherein the endpoint is operable to:
truncate a first set of time bits of the nonce to create a truncated nonce; and
insert the truncated nonce into a header of the frame; and
wherein the server system is operable to:
decrypt the frame based on the truncated nonce.
9. The system of
recover the nonce from the truncated nonce by adding a second set of time bits retrieved from a system time of the server system; and
decrypt the frame based on the cryptographic key and the recovered nonce.
10. The system of
11. The system of
wherein the endpoint is operable to:
combine the mac+nonce value with the cryptographic key to create a mac+nonce+key value;
generate a session key from the mac+nonce+key value; and
encrypt a payload of the frame using the session key without encrypting a header of the frame; and
wherein the server system is operable to:
extract the mac address from the header of the frame.
12. The system of
13. The system of
authenticate the endpoint based on the frame and the cryptographic key; and
disable operation of the endpoint in response to failed authentication of the endpoint.
15. The system of
16. The system of
17. The system of
wherein the first endpoint is associated with a first user,
wherein the set of endpoints comprises a second endpoint associated with a second user and operable to:
encrypt a second frame; and
transmit the second frame to the bridge; and
wherein the bridge is operable to route the encrypted first frame and the encrypted second frame to the server system.
18. The system of
19. The system of
store the set of globally unique mac addresses;
generate a third cryptographic key;
generate a fourth cryptographic key based on and complementary to the third cryptographic key; and
distribute the fourth cryptographic key to the set of endpoints based on the set of globally unique mac addresses.
20. The system of
wherein the first endpoint is operable to:
truncate a first set of time bits of the nonce to create a truncated nonce; and
insert the truncated nonce into the first frame; and
wherein the server system is operable to:
recover the nonce from the truncated nonce by adding a second set of time bits retrieved from a system time of the server system; and
decrypt the first frame based on the second cryptographic key and the recovered nonce.
|
|||||||||||||||||||||||||||
This application is a continuation of U.S. patent application Ser. No. 15/483,930, filed 10 Apr. 2017, which is a continuation of U.S. patent application Ser. No. 14/919,664, filed 21 Oct. 2015, which claims the benefit of U.S. Provisional Application Ser. No. 62/066,678, filed on 21 Oct. 2014, all of which are incorporated in their entirety by this reference.
This invention relates generally to the computer networking field, and more specifically to new and useful systems and methods for smart device networking.
The modern internet has revolutionized communications by enabling computing devices to transmit large amounts of data quickly over incredibly vast distances. Over time, the internet has expanded beyond computers to include connectivity to a plethora of smart devices—from smartphones to tablets to connected appliances. The Internet of Things (IoT), one of the most recent expansions, brings connectivity to an even wider range of smart devices; but traditional methods of networking are ill suited to the inclusions of these new smart devices. Thus, there is a need in the computer networking field to create new and useful systems and methods for smart device networking.
The following description of the preferred embodiments of the invention is not intended to limit the invention to these preferred embodiments, but rather to enable any person skilled in the art to make and use this invention.
A system 100 for smart device networking includes pluralities of endpoints 110, bridges 120, and routers 130, as shown in
Advances in technology have enabled embedded technology to grow in computational power even as their physical size and cost shrinks, enabling embedded devices to find their way into more and more technological applications. Simultaneously with this development, wireless networking coverage (and thus wireless internet access) has steadily expanded, bringing the possibility of connectivity to many of these embedded devices. Together, these advances have enabled the rise of the Internet of Things (IoT). Research firms estimate that over 26 billion devices will be connected to the IoT by 2020, with some estimates topping 30 billion.
The Internet of Things has applications in almost every field of interest, with some of the most prominent applications finding use in environmental monitoring, infrastructure management, industrial applications, energy management, medical and healthcare systems, and building automation.
Unfortunately, traditional methods for wireless networking are in many ways woefully inadequate to handle IoT connectivity. Most wireless networking protocols are designed for relatively high bandwidths (to meet data transfer requirements of personal computers, tablets, smartphones, etc.) and need at least some amount of backwards compatibility, owing to the well-established position of wireless networking as a communication means for traditional computers. Additionally, these traditional methods are often designed for a relatively small number of devices; it's hard to imagine a home having two hundred personal computers, but if we imagine each sensor, switch, and appliance having connectivity, suddenly that number seems a lot smaller. Due to the compromises inherent in such traditional methods, traditional wireless networking suffers from limited range, complicated configuration, high power consumption requirements, and often limited security capabilities.
The system 100 serves to bring internet connectivity to sensors, actuators, and other devices without these compromises. Based on the principles that a system designed for IoT connectivity should be inexpensive, require a minimum of manual configuration, integrate hardware security, and have high coverage, long range, and low power consumption requirements, the system 100 is designed from the ground up to encourage the proliferation of connected smart devices.
The system 100 enables a flexible topology that allows computing power to be allocated where it is needed most—in some cases, the system 100 may operate to concentrate computing power in the cloud; this may be useful in situations where latency between smart devices and the cloud is not critical and/or in situations where the majority of data processing performed by the system requires a substantial amount of computing power.
However, in many cases, the system 100 may operate to distribute computing power to the edge of the network. Such an operation mode may be optimal for highly data-intensive or highly connected systems where relatively simple data processing can greatly reduce the amount of data that needs to be sent to the cloud; this may result in improved management of cloud processing resources as well as increased battery life at the edge of the network (through optimization of radio use).
Regardless of system operational mode, the use of intelligent endpoints within the system 100 enables easy transitions from one set of allocation parameters to another.
Internet connectivity for a device connected to the system 100 begins at an endpoint no. The endpoint 110 is preferably connected to a single device and enables the device to communicate over a wireless network of the system 100. Each endpoint is preferably associated with an IPv6 address, enabling easy addressing. The endpoint 110 connects wirelessly to one or more bridges 120; the bridges 120 receive data from the endpoint no and pass it on, preferably through the internet, to one or more routers 130. The routers 130 analyze the content of the data and route it to its intended destination. Data is encrypted before leaving the endpoint 110 and remains encrypted until processing at the router 130, minimizing the likelihood of successful interception; and although in many instances the system passes traffic between the bridges 120 and routers 130 over the internet, for sensitive data the system 100 may be run entirely on-premise.
The endpoint 110, as shown in
The endpoint 110 preferably is capable of bidirectional communication, but may additionally or alternatively be capable only of unidirectional communication.
The endpoint 110 preferably includes a device interface 111, a processor 112, and a radio 113. The endpoint 110 may additionally or alternatively include any number of device interfaces 111, processors 112, and radios 113.
The device interface 111 functions to enable communication between the endpoint 110 and a device connected to the system 100. The device interface 111 preferably communicates with the endpoint 110 over one or more data connections. Data transmitted from the device is preferably transmitted as analog or digital electrical signals, but may additionally or alternatively be transmitted in any suitable way (e.g., optically, sonically, RF wirelessly). Data may be transmitted using known bus standards such as I2C or SPI, over JTAG connectors, over GPIO connectors, over serial connections using RS-232 or other standards, or in any suitable manner. Data may also be transmitted as analog signal data to be converted according to instructions provided to the interface 111 or the processor 112, or in any other suitable manner. Data lines connected to the device interface 111 may be unidirectional or bidirectional.
The device preferably communicates with the device interface in according to a known and open standard, but may additionally or alternatively communicate with the device interface in any suitable way. For example, if the endpoint 110 is connected to an analog sensor, the endpoint no may dictate how the data is sampled and processed from the sensor. Likewise, if the endpoint no is connected to an actuator, the endpoint no may dictate what signal is sent to control actuation of the actuator.
The device interface 111 may perform processing before passing data to the processor 112; for example, the device interface in might include an I2C/SPI to USART bridge. As another example, the device interface 111 might include an analog-to-digital converter (ADC); this might be useful in the example where the device is an analog sensor. Additionally or alternatively, this processing may occur at the processor 112.
Endpoints no designed for particular applications preferably include custom device interfaces 111 intended for a specific type of data transmission; endpoints no may additionally or alternatively include general device interfaces in that feature a number of different data transmission options.
The processor 112 functions to process data transmitted or received by the endpoint 110; data processed by the processor 112 may originate from either the device interface 111 or the radio 113 (or from any other suitable source). The processor 112 is preferably a microcontroller, but may additionally or alternatively be any suitable type of microprocessor or other processing unit. The processor 112 preferably processes data according to instructions in stored firmware and/or software, but may additionally or alternatively process data according to any other suitable instructions. In some cases, the processor 112 may simply forward data from the interface 111 to the radio 113 or vice versa, potentially changing only the data format or signaling method. In other cases, the processor 112 may perform more processing on data before sending it or after receiving it; for example, if the processor 112 is connected to an analog temperature sensor and an analog humidity sensor, the processor 112 may sample both sensors at identical time intervals and pass along both readings along with time data.
In one implementation of a preferred embodiment, the processor 112 stores historical data transmitted over the device interface 111 and makes decisions about how to respond to current data based on stored historical data and/or other instructions stored in firmware and/or software. For example, the processor 112 may transmit differential values (potentially after transmitting a first absolute value) for measurements taken by a sensor coupled to the device interface 111. In this example, the processor 112 may only transmit differential values over the PAN radio 113 when they exceed a threshold (e.g., temperature changes by more than 0.1 degrees Celsius). By reducing the number of transmissions made by the PAN radio 113, the processor 112 may extend endpoint 110 battery life. Additionally or alternatively, the processor 112 may perform any suitable processing to reduce the number of transmissions made by the PAN radio 113.
As another example, the processor 112 may store and transmit all of a set of data, but batch the set of data according to properties of said data. For example, the processor 112 may store all readings taken by a sensor coupled to the device interface 111, but transmit those readings only when a trigger (e.g., threshold change over historical value or over historical average exceeded) occurs. Unlike the previous example, this example may not result in substantially less data transmitted, but it still may result in more efficient radio usage.
The response of the processor 112 may be particularly important in cases where a low-latency response by the system 100 to some event is required. In traditional cloud-intelligence systems, the endpoint is often helpless to make decisions when the cloud provides crucial data or instructions too slowly. In some cases, this may be mitigated by pre-storing some responses to certain scenarios at the endpoint, but maintaining these pre-stored responses across endpoints may be a difficult challenge as the complexity of the response increases (and varies at a per-endpoint level).
In one implementation of a preferred embodiment, the processor 112 stores both data patterns (e.g., sets of data received or transmitted over the device interface 111) and instructions received from the router 130 in response to those data patterns (as transmitted to the router 130). In this implementation, the processor 112 may identify repeated instances of data pattern/instruction correlation. After a confidence threshold is met, the processor 112 may use these correlations as backup instructions when instructions from the cloud are not readily available. In this manner, the processor 112 may be able to respond to scenarios that would normally require either manual configuration of the endpoint and/or complex computation without the performance of either manual configuration or complex computation. For endpoints 110 with similar functions, these responses may be shared across endpoints. For example, an endpoint 110 may be coupled to a current monitor that monitors current flowing to a refrigerator, an actuator that activates or deactivates the refrigerator's compressor, and several temperature sensors within the refrigerator. The endpoint 110 regularly transmits data from the current monitor and the temperature sensors to an external server (via the router 130). Sometimes, the refrigerator malfunctions and the compressor needs to be cycled to maintain appropriate temperature in the refrigerator; this is programmed in the external server. Eventually, the endpoint 110 associates a pattern of current reading differences with the compressor cycling command (typically sent by the external server to the endpoint 110, and then accomplished via the actuator). Now, the endpoint 110 can perform that operation automatically if there is a delay (or even just if the typical response is slower than ideal) between the recognition of the particular current reading pattern and the actuation of the compressor actuator. Such pattern recognition may be accomplished using machine learning or any other suitable technique.
The processor 112 may also modify instructions received via the router 130 based on latency and/or other data received by the processor 112. For example, the endpoint 110 may be connected to a robotic arm and a machine vision system. The robotic arm is directed to move to a particular target being imaged by the machine vision system; obviously, the instructions given have a dependence on the range between the arm and the target as imaged. An external system provides instruction to the endpoint 110 to move the arm based on the current position of the arm and the received data from the machine vision system, but during the time the imaging data is sent from the machine vision system and the time the instruction is received at the robotic arm, the target may have moved, resulting in the robotic arm being moved to an inaccurate position. As shown in
A person of ordinary skill in the art will recognize that the techniques described in the preceding examples may be combined in any manner. The processor 112 may process data received or transmitted over the device interface 111 in any manner.
The processor 112 firmware and/or other endpoint 110 firmware are preferably flash-able over the air (OTA), allowing updates to reach the endpoint 110 without manual or individual configuration.
The processor 112 preferably also performs power management for the endpoint 110. In particular, the processor 112 preferably puts the endpoint 110 into a sleep mode after a period of inactivity (or according to a set schedule). The processor 112 is preferably also able to put the endpoint 110 to sleep (putting the device interface 111, processor 112, and radio 113 into low-power consumption modes) according to a command. When the endpoint 110 is sleeping, it preferably draws only a few microamps of current. Upon awakening, the endpoint 110 is immediately able to send and receive data, unless the bridge 120 that the endpoint was connected to is no longer available. In that case, the endpoint 110 preferably automatically connects to an available bridge 120.
The processor 112 preferably also serves to establish connectivity between the endpoint 110 and the bridge 120. When the endpoint 110 is first powered on or wakes up from sleep, the processor 112 preferably directs the endpoint 110 to search for available bridges 120 (over the radio 113). When the endpoint 110 finds an available bridge 120, it preferably sends data to the bridge 120; if the endpoint 110 receives an acknowledgment (e.g., an ACK packet) from the bridge 120, the endpoint has successfully associated with a particular bridge 120. This process is described in more detail in sections discussing connectivity between the endpoint 110 and bridge 120.
The processor 112 may additionally control messaging parameters for the endpoint 110. For example, the endpoint 110 may operate using carrier sense multiple access (CSMA); the endpoint 110 checks to see if another device is transmitting on the endpoint no's transmit channel before transmitting and preferably waits until no other devices are transmitting on the transmit channel to send a message (e.g., listen before talk (LBT)).
The processor 112 may set messaging parameters to aid with power management, for example, the endpoint 110 may wake up at set time intervals, transmit data, and then stay active for a period of time after transmission before shutting off again. This time period is preferably communicated to the router 130 or bridge 120 (or set by the router 130 or the bridge 120), such that the system 100 knows to send any relevant information to the endpoint 110 during its ‘on period’ following data transmission. In one implementation of a preferred embodiment, the endpoint no's on period may be extended; for example, explicitly after receiving “keep awake” flags from the bridge 120, or implicitly during multicast mode transmissions from the bridge 120.
In one implementation of a preferred embodiment, the processor 112 modifies power management parameters (e.g., wake up intervals) based on data received over the device interface 111 and/or data received over the PAN radio 113. For example, the processor 112 may activate the radio 113 more or less based on the differential between sensor measurements received over the device interface 111 (e.g., batching intervals may be longer for sensors reporting lower change than for sensors reporting higher change). As another example, the processor 112 may activate the radio 113 more or less based on the frequency or type of commands sent to the endpoint 110 via the bridge 120. For example, if the primary task of an endpoint 110 is to communicate a particular set of data or perform an action when requested via the bridge 120, the processor 112 may modify wake-up intervals based on how frequently data or action performance is requested. Further, to the extent that the endpoint 110 learns responses over time (e.g., as described in the section regarding data pattern/instruction correlation), the processor 112 may increase periods between wake-up as less instruction may be needed from an external source.
The radio 113 serves to enable wireless connectivity between the endpoint 110 and one or more bridges 120. The radio 113 preferably includes an RF transceiver and communicates using an antenna coupled to the endpoint 110. The antenna may be of a variety of antenna types; for example, patch antennas (including rectangular and planar inverted F), reflector antennas, wire antennas (including dipole antennas), bow-tie antennas, aperture antennas, loop-inductor antennas, ceramic chip antennas, antenna arrays, and fractal antennas.
The radio 113 is preferably a dual-band radio with the first band operating on one of the 868 MHz frequency band and the 915 MHz frequency band, and the second band operating on the 2450 MHz frequency band. Additionally or alternatively, the radio 113 may operate at any suitable number of bands at any suitable frequencies (e.g., 782 and/or 779 MHz).
The radio 113 preferably transmits and receives data according to the IEEE 802.15.4 standard, but may additionally or alternatively transmit and receive data according to any standard (or no standard at all). The radio 113 preferably connects to the bridge 120 wirelessly over a personal area network (PAN) but may additionally or alternatively connect to the bridge 120 in any suitable manner.
The endpoint 110 may additionally include a hardware encryption module (HEM) 114. The HEM 114 is preferably a chip that stores a 256-bit encryption key securely (e.g., the Atmel SHA204) and performs data encryption based on that key, but may additionally or alternatively be any hardware module capable of encrypting transmissions from and/or decrypting transmissions to the endpoint no. The encryption process is described in more detail in sections discussing connectivity between the endpoint 110 and bridge 120.
The endpoint no is preferably integrated fabricated with integrated circuits (ICs) coupled to printed circuit boards (PCBs) but may additionally or alternatively be fabricated in any suitable manner.
The bridge 120 functions to provide connectivity between the endpoint no to the router 130. The bridge 120 preferably creates a personal area network (PAN) to communicate with endpoints no, connects to one or more routers 130 via the internet, and enables traffic to flow between the two. In some variations, the bridge 120 may connect to routers 130 via a local-area network (LAN).
The bridge 120 preferably acts a stateless gateway for the endpoints no. When packets are sent to the bridge 120 from an endpoint 110 on the bridge's PAN, the bridge 120 preferably directs the packet appropriately to a router 130. This may include encapsulating the packet into another packet, modifying the packet header, and/or any other packet processing required for transmission from the bridge 120 to a router 130.
For example, if the packet is an 802.15.4 packet, the bridge 120 may encapsulate that packet into a TCP/IP packet before sending it to the router 130. The packet payloads are preferably encrypted, and the bridge 120 preferably does not perform any decryption; but the headers of the packets are preferably not encrypted. Additionally or alternatively, the packets may be encrypted in any other manner (or not at all), and/or the bridge 120 may perform decryption.
In a variation of a preferred embodiment, the bridge 120 may be capable of storing data, providing or verifying security credentials, and performing compute operations (e.g., allowing offload of computation from the endpoint no and/or other systems).
The bridge 120 preferably includes a PAN radio 121, a processor 122, and a WAN communications module 123, as shown in
The PAN radio 121 functions to create a PAN for communication with one or more endpoints 110. The PAN created by the PAN radio may additionally or alternatively be used for communication with other bridges 120. The PAN radio 121 preferably includes an RF transceiver and communicates using one or more antennas coupled to the PAN radio 121. The antenna may be of a variety of antenna types; for example, patch antennas (including rectangular and planar inverted F), reflector antennas, wire antennas (including dipole antennas), bow-tie antennas, aperture antennas, loop-inductor antennas, ceramic chip antennas, antenna arrays, and fractal antennas.
The PAN radio 121 preferably includes multiple antennas and uses antenna diversity to increase PAN network reliability. The antennas may use one or more types of antenna diversity, including spatial diversity (e.g., physical separation or isolation of antennas), pattern diversity (e.g., using antennas with different radiation patterns), polarization diversity (e.g., using antennas with orthogonal polarizations), and/or transmit/receive diversity (e.g., using separate antennas for receiving and transmitting). The antennas may additionally or alternatively be modifiable (e.g., tunable) to adjust electrical characteristics of the antennas. The antennas may be used as part of multiple-in multiple-out (MIMO) communication.
The PAN radio 121 is preferably a dual-band radio with the first band operating on one of the 868 MHz frequency band and the 915 MHz frequency band, and the second band operating on the 2450 MHz frequency band. Additionally or alternatively, the PAN radio 121 may operate at any suitable number of bands at any suitable frequencies (e.g., 782 and/or 779 MHz).
The PAN radio 121 preferably transmits and receives data according to the IEEE 802.15.4 standard, but may additionally or alternatively transmit and receive data according to any standard (or no standard at all).
The PAN radio 121 preferably establishes a PAN on a single wireless channel in the frequency bands previously mentioned, but may additionally or alternatively establish PANs on multiple wireless channels. The PAN radio 121 is preferably able to hop between channels for a given frequency band (or potentially even across frequency bands) in order to choose channels having a minimum of unwanted noise. The PAN radio 121 may hop channels in response to environmental conditions (e.g., the detection of noise above some threshold, congestion, etc.), may hop channels after a set time interval, and/or may hop between channels in response to any other conditions.
The bridge 120 preferably includes a single PAN radio 121 but may additionally or alternatively include multiple PAN radios 121 in order to increase connectivity options. For example, the bridge 120 may include two 802.15.4 radios or one 802.15.4 radio and one Bluetooth radio.
The processor 122 functions to process data transmitted or received by the bridge 120; data processed by the processor 122 may originate from the PAN radio 121, the WAN comm. module 123, interface 111 or from any other suitable source. The processor 122 is preferably a microcontroller, but may additionally or alternatively be any suitable type of microprocessor or other processing unit. The processor 122 preferably processes data according to instructions in firmware and/or software, but may additionally or alternatively process data according to any other suitable instructions.
The processor 122 preferably performs any change in data format or header format for data passing between the endpoint 110 and the router 130. In one embodiment, the processor 122 preferably encapsulates 802.15.4 packets sent by the endpoint 110 in TCP/IP packets before forwarding the packets to the router 130 and also strips TCP/IP encapsulated packets received from the router 130 before forwarding them to the endpoint 110.
The processor 122 may additionally be used for frame-checking purposes; that is, the bridge 120 may check frames received from endpoints 110 for errors using error checking bits contained within the frames. Additionally or alternatively, frame checking may occur at the router 130.
The processor 122 preferably also performs power management for the bridge 120, including determining when radios are on, which antennas are used, sleep state settings, and any other setting relevant to power management of the bridge 120.
The processor 122 preferably also serves to establish connectivity between the bridge 120 and one or more routers 130. After any connection interruption (including a power-off state), the processor 122 preferably seeks to establish a TCP/IP connection between the bridge 120 and a router 130. If the TCP/IP connection is irreparable, the processor 122 may attempt to establish a multi-hop or mesh connection using its own PAN connection or another PAN to PAN connection, as shown in
The bridge 120 preferably attempts to sustain a TCP/IP connection to at least one router 130 at all times; if the TCP/IP connection is interrupted, the bridge preferably attempts to immediately remedy the interruption. The bridge 120 preferably differentiates between interruptions between the bridge 120 and the router 130 (e.g., an interruption occurring from loss of bridge internet connection) and interruptions at the router 130 (e.g., router failure). In the case that a router 130 has failed, the bridge 120 preferably switches to another router 130.
The WAN communications module 123 functions to connect the bridge 120 to the router 130. The WAN communications module 123 preferably connects the bridge 120 to the router 130 over the internet or other WAN, but may additionally or alternatively connect the bridge 120 to the router 130 over a LAN. The WAN communications module 123 preferably includes a cellular radio, enabling the WAN communications module 123 to communicate with routers 130 over existing cellular networks. The WAN communications module 123 may additionally or alternatively include any other suitable connection hardware to enable connection with routers 130, including Ethernet modules, Wi-Fi radios, Bluetooth radios, and any other WAN or LAN connection module. In a variation of a preferred embodiment, the WAN communications module may include a radio for communicating with another bridge 120 (e.g., over a multi-hop or mesh connection) as shown in
The WAN communications module 123 preferably also enables configuration of the bridge 120. For example, the bridge 120 may be configured locally using an iPhone or Android phone connecting to the bridge over a Bluetooth connection. The bridge 120 may additionally or alternatively include any suitable mechanism to allow configuration from a source other than a router 130; for example, a USB port to allow for connection of a configuring device (e.g., a smartphone, laptop, or dedicated configuration device).
The GPS module 124 functions to provide location data to the bridge 120. The bridge 120 preferably uses location information derived from the GPS module 124 for one or both of two purposes.
The first purpose involves determining appropriate whitespace for the PAN radio 121. The bridge 120 preferably contains data corresponding location with acceptable broadcast spectra, allowing the bridge 120 to operate in multiple regulatory environments without pre-knowledge of the area it will be used in. The bridge 120 preferably checks location using the GPS module before establishing a PAN network to determine allowed broadcast spectra; after the bridge 120 has determined an allowed broadcast spectrum, the bridge 120 preferably broadcasts on that spectrum.
Note that broadcast spectra may be set according to other criteria as well. For example, the bridge 120 may operate in a region where the regulatory environment allows for communication over multiple spectra that the bridge 120 is capable of broadcasting on. In this example, the bridge 120 may scan the allowed broadcast spectra and choose one of the spectra (or more than one) based on the results of the scan (e.g., the bridge 120 chooses to broadcast on the less congested of two broadcast bands).
The second purpose involves determining appropriate router 130 region (discussed in more detail in later sections). The bridge 120 preferably uses GPS information from the GPS module 124, along with data containing router 130 locations or router region data, to determine appropriate routers 130 to connect to. Additionally or alternatively, the bridge 120 may determine appropriate routers 130 to connect to by any other suitable method (e.g., selecting the router with the lowest ping regardless of location).
The bridge 120 may additionally include other equipment for increasing network reliability. For example, the bridge 120 may include a backup battery in case power to the bridge 120 is lost.
The router 130 functions to mediate communication occurring within the system 100. The router 130 is in some ways the ‘brain’ of the system 100; the router 130 determines what communication may occur between an endpoint 110 and another device (whether that device is internal or external to the system 100), performs endpoint no management and addressing, and may even manage bridge 120 operations.
The router 130 preferably operates using a general-purpose computer server as a host, but may additionally or alternatively run on specialized hardware (e.g., switches) or any suitable computing system. The router 130 is preferably located in high-uptime data center along with other servers, but may additionally or alternatively be located in any suitable area.
Routers 130 are preferably organized into regions; these regions preferably correspond to geographic regions but may additionally or alternatively correspond to any other type of region (e.g., regions may be based on population regions). Routers 130 located in a particular region preferably are able to connect to many devices of the system 100 (i.e., bridges 120, and through bridges 120, endpoints 110) with low latency. Decreasing latency may be one of the criteria for determining regions in addition to population and/or geography. Stated alternatively, one of the advantages of locating routers 130 according to regions is that routers 130 of a particular region preferably have lower latency or higher reliability connections to the devices associated with that region than they would if the routers 130 were located in central locations for all regions.
Regions also a play a role in endpoint 110 addressing. Endpoints 110 are preferably assigned virtual IPv6 addresses by routers 130; the IPv6 addresses are preferably generated from both an endpoint 110's unique MAC address and an IPv6 prefix corresponding to the region associated with the endpoint 110. For example, an endpoint 110 with MAC address a1b2.a2b3.a235 in a region associated with an IPv6 prefix of 2001:odb8:85a3:0000 might receive a virtual IPv6 address of 2001:odb8:85a3:0000:0000:a1b2.a2b3.a235, alternatively written as 2001:db8:85a3::a1b2.a2b3.a235.
Information about the endpoints 110 connected to routers 130 in a particular region is preferably stored in a hash table distributed across the routers 130 of that region. Additionally or alternatively, the information (e.g., Endpoint MAC address, last seen time, bridge connection, etc.) may be stored in any suitable location or format. The distributed hash table of a region may include other information relevant to the system 100; for example, bridge 120 channel settings or any other suitable data. Key data (or even all data) from the distributed hash table may be cached in router 130 memory to enable fast access to data.
Regions are preferably designed to have N+1 redundancy, so that if a router 130 in a region fails, that router's responsibility is transferred over to another router 130 in the region. Likewise, the distributed hash table preferably shares this redundancy (that is, it can be completely reconstructed in the event of a router 130 failure). If multiple failures occur across a region, the system 100 preferably enables the transfer of operations from one region to another.
The key server 140 preferably functions to store ‘super secret keys’ associated with endpoints 110 for purposes of encryption. The key server 140, like the routers 130, preferably operates using a general-purpose computer server as a host, but may additionally or alternatively run on specialized hardware (e.g., switches) or any suitable computing system. Unlike the routers 130, the key server 140 is preferably centralized (i.e., not located in the same edge-of-the-internet data centers as the routers 130); additionally or alternatively, key servers 140 may be co-located with routers 130 or may exist in any suitable location. The super secret keys are preferably used as described in following sections; the key server 140 may additionally or alternatively store any other sensitive information related to system 100 security.
The following sections describe methods of communication on the system 100, including network setup routines. Specifically, bridge setup routines, endpoint setup routines, and communication methods (including encryption) will be discussed in respective order.
When a bridge 120 is first connected to the internet, (or other network), the bridge 120 attempts to find a router 130 to connect to. The bridge 120 preferably searches for routers by contacting routers on a list stored within the bridge 120; additionally or alternatively, the bridge 120 may first request such a list from a central server of the system 100. The bridge 120 preferably connects to a router 130 based on the results of contact; for example, a bridge 120 might connect to a router 130 by contacting a list of routers 130 and selecting the one with the lowest response latency. Additionally or alternatively, the bridge 120 may connect to a router 130 based on any other suitable information; for example, the bridge 120 may request connections from a group of routers 130. The routers 130 may then communicate to each other to determine which router 130 the bridge 120 should connect to (e.g., based on router load); that router 130 preferably then responds to the bridge. Other information may also include GPS information from the bridge GPS module 124; for example, the bridge 120 may only request to join or may only join routers 130 associated with a particular geographic region.
Once the bridge 120 has selected a router 130, the bridge 120 preferably opens a TCP/IP socket connection with the router 130. The TCP/IP socket connection is preferably encrypted (e.g., by TLS/SSL). After the TCP/IP connection has been established, the bridge 120 preferably maintains the connection at all times. If the connection is severed for some reason, the bridge 120 preferably immediately attempts to reestablish the connection (described in sections detailing the bridge 120). The bridge 120 may additionally or alternatively open a connection to one or more backup routers 130 (or may simply have them listed as particular backup options to try if the primary router 130 fails). The bridge 120 may additionally or alternatively attempt to connect using multi-hop or mesh networking over a PAN connection. During this process, the bridge 120 may be assigned an identifier in distributed hash tables stored by the routers 130. The bridge 120 may additionally or alternatively provide information about itself; for example, a bridge 120 may transmit its GPS coordinates or results of a radio scan of the area the bridge 120 is located in.
The bridge 120 preferably also begins broadcasting a PAN to allow endpoints 110 to connect to the bridge 120. The bridge 120 may choose the PAN channel and communications settings (e.g., bit rate, channel width, etc.) based on internal rules stored within the bridge 120, additionally or alternatively, the bridge 120 may choose these settings according to instructions from the router 130 the bridge 120 is connected to.
When an endpoint no is powered on, the endpoint no preferably immediately searches for one or more bridges 120 across a wireless spectrum defined by the endpoint no. Once the endpoint no finds a bridge 120 to connect to, the endpoint no preferably sends a network join request to the bridge 120. This network join request is preferably forwarded to a router 130 by the bridge 120. Once the network join request has been received by the router 130, the router 130 preferably uses identifying information stored within the network join request (e.g., the source address in the frame header) to look up the endpoint no in a distributed hash table associated with the router region. If the endpoint no is not found within the router region's distributed hash table, the router 130 will contact routers 130 in other regions to determine if the endpoint no has moved regions; if the endpoint no has moved regions, the distributed hash table of the previous region is preferably updated. In either case, an entry is preferably created within the distributed hash table of the current region if the router 130 accepts the endpoint no's join request. Further, the router 130 preferably then sends a join acknowledgment to the endpoint 110. The router 130 may additionally assign a transmission timeslot to the endpoint 110 (based on other transmission timeslots for a given bridge 120 or group of bridges 120).
While this describes in general the endpoint 110 connection process, the process preferably includes encryption. The encryption protocol for the system 100 preferably enables the system 100 to perform encryption that satisfies the following:
The encryption protocol is preferably based upon AES256 encryption, but may additionally or alternatively use any suitable encryption scheme. In addition to standard AES256 encryption considerations, the encryption scheme is preferably structured such that if any endpoint 110 or bridge 120 were to be reverse-engineered, that the damage would be limited to only that endpoint 110 or bridge 120 (or alternatively, a small set of endpoints 110 or bridges 120). In other words, each device performing encryption preferably has a separate secret key used for generating encryption keys. Alternatively, any number of devices may share secret keys. Secret keys for endpoints 110 are preferably stored within the HEM 114.
As shown in
The system 100 preferably uses an encryption process similar to the above process modified such that the endpoint 110 does not need to generate a new key for each frame (as key generation can be time consuming). The system 100 preferably uses a join key/session key approach based on the above encryption process, as described below.
As shown in
At the router 130, the join key is preferably generated using the same process; the 64-bit nonce is generated by adding the 24 highest bits back to the 8 lowest (i.e., least significant) bits. This addition works as long as the join key is generated within 127 of seconds of the original generation (at the endpoint 110). Generating the nonce in this way preferably substantially limits the opportunity window for potential replay attacks, because any replay attacks must complete within 127 seconds.
The router 130 preferably then generates a second nonce and a second encryption key (referred to as a session key), encrypts a NetJoinAns frame and transmits it along with a precursor based on the second nonce, where it is then decrypted at the endpoint 110 after the endpoint 110 generates the session key.
At this point, the endpoint 110 and router 130 now both have the session key, which may be used to communicate for a set window of time (or even indefinitely). The session key preferably expires after a set time interval, but may additionally or alternatively expire after particular events (e.g., the connection of a certain additional number of devices to the PAN, a security event, or any other event occurring with or related to the system 100).
Note that while the encryption process for communications from the router 130 to the endpoint no is preferably substantially similar to the encryption process used for communications from the endpoint no to the router 130, there may alternatively be some variations; for example, communications from the router 130 may include the full 32-bit time in the precursor (as opposed to the eight least significant bits).
Using a separate join and session key has the advantage that the key for communication is generated fully within the key server 140 (or other part of the system 100 not local to the endpoint 110), which may further increase security over using a key generated at a potentially compromised endpoint 110.
The system 100 preferably never reuses the same key and nonce combination twice; this may create a serious security vulnerability. Each encrypted frame is preferably encrypted with a nonce that never repeats; non-repetition of the nonce is preferably enabled by using a nonce that includes both the current time and an incrementing index. As long as a nonce sends less than 255 frames per second (i.e., as long as the index does not repeat for a given time value), the nonce will not repeat.
The Router and each endpoint will track the frames received from the other side, and record the time/sequence values. This aspect of the nonce may additionally be used for extra security; the router 130 and/or endpoint no can check that the part of the nonce corresponding to time and index always increments (e.g., if the router 130 receives a frame associated with a time value and an index value, the next frame received should have either a higher time value or a higher index value). The router 130 or endpoint no may reject frames without incremented time+index values.
If an endpoint no has previously communicated with a router 130 using a session key, but disconnects from the PAN, the endpoint no may attempt to re-use the previously used session key. The endpoint 110 may accomplish this by sending an ftAssociateReq frame with the random bits of the nonce field set to zero; the router 130 preferably detects the zero value and attempts to decode the frame using a stored session key. Additionally or alternatively, the endpoint 110 may generate a join key for each reconnection.
Example formats for NetJoinAsk frames, NetJoinAns frames, and data frames are as shown in
The above description describes random numbers used in nonce generation. The random numbers used to generate keys are preferably cryptographically secure. The router 130 preferably generates random numbers using the crypto/rand package standard library from the Go language, but may additionally or alternatively use any suitable random number generator. The endpoint no preferably uses a hardware random number generator, such as the one built into the AT86RF233 transceiver chip, which generates random numbers based on observed radio noise. To increase the security of random numbers generated, these random numbers may be used to seed a SHA2 stream of random numbers (as opposed to being used directly by the endpoint no or router 130. Each new batch of random numbers is preferably an SHA digest of the previous batch XOR-ed with 32 bytes of new unpredictable data (e.g., the output of the previously described random number generators).
Messages transmitted in the system 100 may additionally include data integrity checks. Without such checks, data transmitted in the system 100 may be vulnerable to transmission/reception errors as well as certain types of network attacks.
For example, a data frame that has a payload length of 100 bytes is encrypted with AES-256 such that each block has a length of 16 bytes. An attacker could intercept the frame before reception, and alter only the last 68 bytes, leaving the first 32 bytes (i.e., the header and the first encrypted block) unchanged. Then, the attacker could transmit the altered frame to the intended recipient, where the header would be validated and the first block decrypted successfully, but the rest of the received data would be corrupted.
The system 100 may address this issue by adding a checksum or hash to the end of the payload before encrypting; the payload could then be verified against the checksum or hash after decryption. If the checksum or hash did not properly check out, the frame may be discarded. In some implementations of the system 100, NetJoinAsk and NetJoinAns frames include a 4-byte CRC in the header (unencrypted), while data frames include a CRC appended to the payload before encryption.
The system 100 may additionally or alternatively employ any other suitable data security or data integrity mechanisms.
As a person skilled in the art will recognize from the previous detailed description and from the figures and claims, modifications and changes can be made to the preferred embodiments of the invention without departing from the scope of this invention defined in the following claims.
Thompson, Andrew, Haleem, Amir, Gnoske, Eric, Leverett, Blake, Vidales, Mike, Carey, Sean, Wilson, Theo
| Patent | Priority | Assignee | Title |
| 11038964, | Oct 21 2014 | DECENTRALIZED WIRELESS FOUNDATION, INC | Systems and methods for smart device networking |
| 11889351, | Apr 13 2022 | Blockchain-based dynamic cellular network with proof-of-service | |
| 11937165, | Sep 27 2022 | STACKSHARE TECHNOLOGIES LLC | Systems and methods of selectively routing a packet flow |
| Patent | Priority | Assignee | Title |
| 7200684, | Apr 13 2000 | TREND MICRO INCORPORATED | Network data packet classification and demultiplexing |
| 7653813, | Feb 08 2006 | Google Technology Holdings LLC | Method and apparatus for address creation and validation |
| 8000239, | Dec 14 2006 | Oracle America, Inc | Method and system for bandwidth allocation using router feedback |
| 8139589, | Dec 06 2007 | Electronics and Telecommunications Research Institute | Gateway apparatus for providing multi-channel functionality in sensor network, and method and apparatus for interfacing using serial peripheral interface in the gateway apparatus |
| 8213463, | Sep 04 2008 | SAVANT SYSTEMS, INC | Location-based sharing of multimedia control resources |
| 9253811, | Oct 19 2012 | Verizon Patent and Licensing Inc. | Network-assisted device-to-device communication |
| 9270636, | Apr 07 2014 | Oracle International Corporation | Neighbor lookup operations in a network node |
| 9661080, | Oct 21 2014 | DECENTRALIZED WIRELESS FOUNDATION, INC | Systems and methods for smart device networking with an endpoint and a bridge |
| 20070260884, | |||
| 20090147710, | |||
| 20100054275, | |||
| 20140113556, | |||
| 20140287685, | |||
| 20150264134, | |||
| 20150264627, | |||
| 20150288655, | |||
| 20170214620, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Oct 27 2015 | HALEEM, AMIR | HELIUM SYSTEMS, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 042617 | /0771 | |
| Oct 27 2015 | THOMPSON, ANDREW | HELIUM SYSTEMS, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 042617 | /0771 | |
| Oct 27 2015 | GNOSKE, ERIC | HELIUM SYSTEMS, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 042617 | /0771 | |
| Oct 27 2015 | VIDALES, MIKE | HELIUM SYSTEMS, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 042617 | /0771 | |
| Oct 27 2015 | WILSON, THEO | HELIUM SYSTEMS, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 042617 | /0771 | |
| Oct 30 2015 | CAREY, SEAN | HELIUM SYSTEMS, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 042617 | /0771 | |
| Dec 16 2015 | LEVERETT, BLAKE | HELIUM SYSTEMS, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 042617 | /0771 | |
| May 17 2017 | HELIUM SYSTEMS, INC. | (assignment on the face of the patent) | / | |||
| Sep 27 2022 | HELIUM SYSTEMS, INC | DECENTRALIZED WIRELESS FOUNDATION, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 061919 | /0102 |
| Date | Maintenance Fee Events |
| Jun 13 2019 | BIG: Entity status set to Undiscounted (note the period is included in the code). |
| Jan 23 2023 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Date | Maintenance Schedule |
| Jul 23 2022 | 4 years fee payment window open |
| Jan 23 2023 | 6 months grace period start (w surcharge) |
| Jul 23 2023 | patent expiry (for year 4) |
| Jul 23 2025 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Jul 23 2026 | 8 years fee payment window open |
| Jan 23 2027 | 6 months grace period start (w surcharge) |
| Jul 23 2027 | patent expiry (for year 8) |
| Jul 23 2029 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Jul 23 2030 | 12 years fee payment window open |
| Jan 23 2031 | 6 months grace period start (w surcharge) |
| Jul 23 2031 | patent expiry (for year 12) |
| Jul 23 2033 | 2 years to revive unintentionally abandoned end. (for year 12) |