SYSTEMS AND METHODS FOR SECURE COMMUNICATION OVER A NETWORK USING A LINKING ADDRESS

Abstract

Systems and methods for secure communication over a network using a linking address. Systems for secure communication may include a computer system in electronic communication over a network with a plurality of electronic devices, a database in electronic communication with the computer system, the database configured to electronically store at least a linking address and an associated payload of a data packet, an engine stored on and executed by the computer system, the engine electronically receiving a data packet over the network from a first electronic device, processing the data packet to identify a linking address and a payload, the linking address being at least 32 bit, storing the linking address and payload in the database, electronically receiving a query from a second electronic device, the second electronic device identifying the linking address, and electronically transmitting the data packet over the network to the second electronic device.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims benefit under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 61/997,422 filed Jun. 2, 2014 and U.S. Provisional Patent Application No. 61/997,450 filed Jun. 2, 2014, which are incorporated herein by reference in their entirety and made a part hereof.

FIELD OF THE DISCLOSURE

The present disclosure relates generally to systems and methods for secure communication over a network using a linking address. More specifically, the present disclosure relates to a system and method for secure transmission and storage over a network using one of many linking addresses.

RELATED ART

There are a growing number of electronic devices in communication over the Internet, which together comprise the Internet of Things (IoT). A difficulty of having so many devices in communication over the Internet is providing an efficient, effective, reliable, and scalable way to directly connect all of these devices with one another. Many electronic devices connect to the Internet through various firewalls and routers using a Network Address Translation (NAT) protocol. Communication via NAT does not directly expose the communicating device to the external network environment, which can be problematic when such devices are trying to communicate directly (e.g., when the devices are not connected to servers that have their Internet address exposed).

The Interactive Connectivity Establishment (ICE) protocol (e.g., with Session Traversal Utilities for NAT (STUN)) can be used to assist the direct connection of devices, but this approach does not work in every case (e.g., in 10% of cases). Alternatively, a relaying service could be used (e.g., Traversal Using Relays around NAT (TURN)), which is more reliable, but requires the relaying services to be a trusted party (e.g., to know its individual clients as well as store permissions and session states).

These approaches can result in service fragmentation, as each group of devices (e.g., grouped by vendor, provider, ownership, etc.) has its own connectivity provider due to the required trust relationship. Another disadvantage of these approaches is an increased cost of servicing, as there are substantial resources required on the server side (e.g., processing power, memory, etc.) because reliable connections are stateful.

Further, many systems and devices create periodic or event-driven historical records (e.g., logs) to be stored for subsequent retrieval and analysis. Many available log storage mechanisms form a closed system with mutual trust between the storage mechanism, log generator, and consumer. However, requiring every system to have its own log storage mechanism can be problematic when log generators and consumers are owned by various parties, when it is unknown who the log consumer will be, when there are multiple log consumers, etc. Further, coupling security associations and trust relationships with the log storage mechanism increases the amount of security associations and procedures to set up and maintain. It is impractical for every analytic application to create its own log storage mechanism, or have each device model commit to one particular log storage mechanism at the time of manufacture.

All these problems are exacerbated as the number of clients (e.g., electronic devices, device owners, etc.) increase, such as in an IoT environment.

SUMMARY OF THE INVENTION

In view of the above, there is a need for a system that can provide secure electronic communication and storage over a network that is scalable and reliable, and which uses minimal computer resources and minimal financial resources to setup, maintain, and use.

The present disclosure relates to systems and methods for secure communication over a network using a linking address. In one embodiment, the system for secure communication comprising a computer system in electronic communication over a network with a plurality of electronic devices, a database in electronic communication with the computer system, the database configured to electronically store at least a linking address and an associated payload of a data packet, an engine stored on and executed by the computer system, the engine electronically receiving a data packet over the network from a first electronic device, processing the data packet to identify a linking address and a payload, the linking address being at least 32 bit, storing the linking address and payload in the database, electronically receiving a query from a second electronic device, the second electronic device identifying the linking address, and electronically transmitting the data packet over the network to the second electronic device.

In another embodiment, a method for secure communication comprises electronically receiving, at an engine stored on and executed by a computer system, a data packet from a first electronic device over a network, processing the data packet to identify a linking address and a payload contained therein, the linking address being at least 32 bit, storing the linking address and the associated payload of the data packet in a database, electronically receiving a query from a second electronic device, the second electronic device identifying the linking address, and electronically transmitting the data packet over the network to the second electronic device.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing features of the disclosure will be apparent from the following Detailed Description, taken in connection with the accompanying drawings, in which:

FIG. 1 is a diagram showing an IoT/IP system for secure electronic communication and storage over a network;

FIG. 2 is a diagram illustrating subsystems of the IoT/IP engine;

FIG. 3 is a diagram illustrating electronic communication of an electronic device using the IoT/IP system;

FIG. 4 is a diagram illustrating use of the IoT/IP system across multiple electronic devices;

FIG. 5 illustrates processing steps of the secure communication relay subsystem of the IoT/IP system;

FIG. 6 is a diagram illustrating the processing steps of FIG. 5;

FIG. 7 illustrates processing steps of the secure log storage subsystem of the IoT/IP system; and

FIG. 8 is a diagram showing hardware and software components of the system.

DETAILED DESCRIPTION

The present disclosure relates to a system and method for secure electronic communication and storage over a network. More specifically, the present disclosure relates to an Internet of Things/Internet Protocol (IoT/IP) system to provide secure electronic communication and storage over a network. The IoT/IP system is scalable, reliable, and secure, and uses minimal computer resources (e.g., processing power, memory, etc.) and minimal financial resources to setup, maintain, and use. As a result of using fewer computer resources, the IoT/IP system also improves the functioning of the computer itself, among other advantages. The IoT/IP system provides for secure communication (e.g., electronic transmissions) as well as secure storage (e.g., log storage) by using a unique linking address (e.g., key, pin, token, ID, etc.), where the linking address is one of a very large number of possible linking addresses (e.g., trillions). In other words, the number of linking addresses in use (e.g., by electronic devices) is much less than the number of linking addresses available. This makes the linking address being used impractical (unlikely) to guess or deduce, even using a computerized random address generator. For example, the linking address may be as large or larger than 32 bit, 64 bit, 128 bit, 256 bit, 512 bit, etc. If the ID is 128 bits, the collision probability after 20 trillion pairings is one in a trillion, so the probability of guessing or deducing the relevant active ID (if trillion logs are simultaneously active) is 1 in 10²⁶. Accordingly, the IoT/IP system does not require or use any security associations.

FIG. 1 is a diagram showing an exemplary IoT/IP system for secure electronic communication and storage over a network, indicated generally at 10. The IoT/IP system 10 comprises a computer system 12 (e.g., a server, multiple servers) having a database 14 stored therein or operatively connected thereto and an IoT/IP engine 16. The computer system 12 may be any suitable computer server (e.g., a server with an INTEL microprocessor, multiple processors, multiple processing cores, etc.) running any suitable operating system (e.g., Windows by Microsoft, Linux, etc.). The database 14 may be stored on the computer system 12, or located externally therefrom (e.g., in a separate database server in communication with the IoT/IP system 10). The IoT/IP system 10 is remotely accessible such that the IoT/IP system 10 communicates through a network 20 with one or more of a variety of computer systems 22 (e.g., personal computer system 26a, a smart cellular telephone 26b, a tablet computer 26c, and/or other electronic devices). Network communication may be over the Internet using standard TCP/IP communications protocols (e.g., hypertext transfer protocol (HTTP), secure HTTP (HTTPS), file transfer protocol (FTP), electronic data interchange (EDI), etc.), through a private network connection (e.g., wide-area network (WAN) connection, emails, electronic data interchange (EDI) messages, extensible markup language (XML) messages, file transfer protocol (FTP) file transfers, etc.), or any other suitable wired or wireless electronic communications format and system.

FIG. 2 is a diagram illustrating exemplary subsystems of the IoT/IP engine 16. These include a secure communication relay subsystem 30 and a secure log storage subsystem 32. The secure communication relay subsystem 30 provides anonymous relaying (e.g., in real time) of secure communications between two (or more) electronic devices over a network by utilizing a unique linking address (e.g., previously agreed upon). More specifically, the linking address for the secure communication relay subsystem 30 may be a Remote Conduit Identification (RCID). As mentioned above, the predetermined RCID is so complex (e.g., large) as to be impractical to guess or determine, and the number of unique RCIDs available is much larger than the actual number in use. The secure communication relay subsystem 30 is completely indifferent (e.g., agnostic) to the identities of the electronic devices and the content of the data packet (e.g., electronic communication) being transmitted.

The secure log storage subsystem 32 provides anonymous storage of log entries (or any other type of data) generated from a first log generator electronic device, which can then be accessed by one or more second log consumer electronic devices by using a linking address. The first log consumer electronic device may be the same device as the second log generator electronic device. More specifically, the linking address for the secure log storage subsystem 32 may be a Remote Storage Identification (RSID). The log generator electronic device may transmit log entries to a single RSID, which then may be accessed by one or more log consumer electronic devices. Alternatively, the log generator electronic device may transmit log entries to multiple RSIDs, such that each linking address is exclusive to only one log consumer electronic device. As with the secure communication relay subsystem 30, the RSID is so complex (e.g., large) as to be impractical to guess or deduce the one being used, and the number of unique RSIDs available is much larger than the actual number in use. The secure log storage subsystem 32 is completely indifferent (e.g., agnostic) as to the identities of the electronic devices and the content of the data packet (e.g., log entries) being transmitted and stored. Although log entries are described, the secure log storage subsystem 32 may store any type of electronic data.

The IoT/IP system does not store any confidential information or client information (e.g., registration information, configuration information, hardware address information, etc.), and thus the server of the IoT/IP system does not require protection. In other words, the IoT/IP system (e.g., including each of the secure communication relay subsystem 30 and the secure log storage subsystem 32) has no knowledge of the electronic devices communicating therewith, nor does the IoT/IP system have any knowledge of any security associations of such devices. As a result, the IoT/IP system operates at a very low financial cost and uses minimal computer resources, thereby improving the functioning (e.g., speed) of the computer itself. The IoT/IP system does not require any information or knowledge of any of the electronic devices prior to those devices using the system, thereby avoiding costly authentication systems and procedures (e.g., logins, accounts, etc.). This provides a connectivity infrastructure between many devices (e.g., millions of devices) without any preparation steps and without communicating individual device information.

FIG. 3 is a diagram illustrating an example of electronic communication of an electronic device using the IoT/IP system. More specifically, a first electronic device (e.g., smartlamp 40) communicates locally (e.g., Bluetooth, Bluetooth low energy, Wi-Fi) with a second electronic device (e.g., smartphone 42) using a local communication stack 34 to securely pair the two devices together (e.g., locally authenticate the two devices). During this secure pairing, the two electronic devices agree upon one or more unique linking addresses (e.g., RCID and/or RSID). However, the devices may be securely paired in any of a variety of alternative ways (e.g., preset by the manufacturer). Once a linking address is agreed upon, the two electronic devices (e.g., smartlamp 40 and smartphone 42) can communicate with each other remotely over the Internet using the linking address. More specifically, the smartlamp 40 can transmit a data packet (e.g., communication) to the predetermined RCID of the secure communication relay subsystem 30 (e.g., conduit IoT/IP service). The smartphone 42 can then retrieve the data packet from the secure communication relay subsystem 30 using the RCID (e.g., for real time alerts). The smartlamp 40 can also send (e.g., stream) data packet(s) (e.g., log entry) to the RSID of the secure log storage subsystem 32 (e.g., EStorage IoT/IP service), which stores the data packet at that RSID until subsequently retrieved at a later time, such as by an application programming interface (API) 44 of an electronic device. Though the example of FIG. 3 is shown as being a wireless communications system, any suitable communications system, wireless or wired, may be used.

FIG. 4 is a diagram illustrating an exemplary use of an IoT/IP system across multiple electronic devices. As shown, and as described above, a first electronic device (e.g., smartlamp 40) communicates locally (e.g., using Bluetooth, Bluetooth low energy, Wi-Fi, etc.) with one or more second electronic devices (e.g., local smartphone 42a, local router 46, etc.). More specifically, for example, a smartlamp 40 may communicate locally over a first (wired or wireless) communication link 45a with a smartphone 42a (e.g., to agree on the RCID), the smartlamp 40 may also communicate with a router 46 over a second (wired or wireless) communication link 45b, and the smartphone 42a may communicate with the router 46 over a third (wired or wireless) communication link 45c. Accordingly, the smartlamp 40, smartphone 42a and router 46 are authenticated with one another as trusted devices.

Once locally authenticated, the devices will be able to directly communicate with each other remotely over the Internet 20 via the IoT/IP system. For example, a remote smartphone 42b (which may be a different, or the same smartphone as smartphone 42a when remotely located) may communicate with the IoT/IP engine 16 which communicates with the smartlamp 40 via the local router 46. The system is completely indifferent to the local electronic communication protocol used (e.g., indifferent to NAT protocol). Any number or any type of electronic devices may be used and paired with one another (e.g., smartlamp 40, desktop computer 48, smartphone 50, tablet computer 52, laptop computer, thermostat, lightswitch, electrical socket, garage door opener, etc.) to remotely communicate with each other via the IoT/IP engine 16. From the user perspective, the devices (e.g., smartlamp 40 and smartphone 42a) may directly communicate with each other locally (e.g., using Bluetooth, Wi-Fi, etc.) to determine an agreed upon linking address, and then communicate with one another remotely over the network 20 (e.g., smartlamp 40 and smartphone 42b) using the predetermined linking address. From the user perspective, the devices communicate and operate with one another the same when locally communicating as they do when remotely communicating without any need for online registration (e.g., of the user, the device hardware, and/or any other identifying information). Further, the system may utilize forward secrecy such that if an unauthorized user were to break into the device and/or the IoT/IP system, they would not be able to reconstruct past communications.

FIG. 5 illustrates processing steps 60 of a secure communication relay subsystem of an exemplary IoT/IP system. In step 62, the IoT/IP system receives over a network a data packet (e.g., packet, message, communication, record, etc.) from a first electronic device (e.g., Device A, Device 1, etc.) paired (e.g., synced, authenticated) with a second electronic device (e.g., Device B, Device 2, etc.). The first electronic device and second electronic device are paired such that the devices agree on a Remote Conduit Identification (RCID) (e.g., linking address) and role identifiers (e.g., roles) to distinguish between themselves (e.g., A and B, 1 and 2, etc.). The RCID in various embodiments exists in a very sparse name space and could be a random token, number, a word, a passphrase, a symbol, etc. If an RCID of sufficient complexity (e.g., size, variability, etc.) is used, it will be impractical to guess or deduce the specific RCID being utilized. For example, the RCID may be a token of 128 bits. The two electronic devices could be paired together (e.g., and agree on a common RCID) in any of a variety of suitable ways. For example, the two electronic devices could communicate directly with one another (e.g., using Bluetooth, Wi-Fi, etc.), the two electronic devices could be packaged and sold together such that the devices have been preprogrammed with the common RCID by the manufacturer, and/or the two electronic devices could be registered with a website that syncs the two devices together. Alternatively, a user could manually enter an RCID in each of the devices and/or manually enter a unique passphrase (e.g., word, sentence, etc.) that is processed by a pre-programmed mathematical algorithm to correlate with a RCID (e.g., entering the passphrase on each device gets processed by the same algorithm so that each device independently comes up with the same RCID). The two electronic device may also have established credentials (e.g., shared secrets) that enable secure communication over insecure channels. More specifically, such established credentials enable end-to-end encryption between the devices to protect communications from the IoT/IP system and/or anyone else. In step 64, the IoT/IP system decrypts the data packet if encrypted by a public key of the server of the IoT/IP system. Data packet encryption hides the RCID from observers and prevents interference by third parties (e.g., prevents third parties from learning the RCID). To encrypt the data packet, any of the existing public key schemes can be used (e.g., RSA, Diffie-Hellman (DH), elliptic curve cryptography (ECC), etc). However, as discussed above, the IoT/IP system does not require security associations. Particularly for data packets with end-to-end encryption and authentication with pre-established credentials, securing electronic communication (e.g., traffic) between clients and the IoT/IP system is not required. Encrypting the RCID with the public key of the IoT/IP server and using sparse ID name space ensures that attackers cannot insert malicious traffic or log entries, or pose as legitimate users, thereby preventing targeted denial of service (DoS) attacks and snooping. In step 66, the IoT/IP system then processes the data packet received to identify the RCID, role identifier (e.g., A or B, 1 or 2, etc.), and payload (e.g., encrypted payload). In step 68, the IoT/IP system determines whether the first role is active. Each electronic device (e.g., a first electronic device and a second electronic device) can establish an active status of a role of an RCID with the IoT/IP system (e.g., the server), such as by electronically transmitting an open channel request to the IoT/IP system (e.g., before or with electronic transmission of a data packet). The open channel request could include the RCID, the role, and/or credentials (e.g., a unique blinded certificate) to validate with the IoT/IP system to confirm that the electronic device is authorized to use the IoT/IP system. Once the IoT/IP system validates the open channel request (e.g., including the credentials), the IoT/IP system declares the status of the role (e.g., the first role) of the RCID as active. Once the electronic device establishes an active status of a role of an RCID, the IoT/IP system could record the time the open channel request was received and start a timer. Once a predetermined time period has expired (e.g., two minutes, five minutes, etc.), the IoT/IP system removes the active status (e.g., changes the status of the role to inactive) unless the electronic device maintains the active status. The electronic device can maintain the active status and reset the timer by resubmitting an open channel request (e.g., with credentials) or by successfully transmitting a data packet to a second electronic device as described below. If the first role is not active (e.g., inactive), then the system proceeds to step 76 and drops the data packet. If the first role is active, then in step 70, the IoT/IP system records the IP address of the data packet and/or the time received in the database. In step 72, the IoT/IP system determines whether the second role (e.g., a second electronic device) is active. If so, in step 74, the IoT/IP system forwards the data packet (with the encrypted payload) to the second electronic device. The IoT/IP system in some embodiments encrypts the data packet for transmission to the second electronic device. If not, in step 76, the system drops the data packet. Once received, the second electronic device can then decrypt both the encrypted packet (if encrypted) and the encrypted payload (if encrypted). In this way, the IoT/IP system acts as a relay between the first electronic device and the second electronic device. The IoT/IP system is completely indifferent (e.g., agnostic) as to the identity of the electronic devices, the content of the encrypted payload, the identity of the owner of one or both of the electronic devices, etc. However, because the RCID is so large, the IoT/IP provides the privacy and security necessary for electronic communications over a network.

FIG. 6 is a diagram illustrating exemplary processing steps of FIG. 5. More specifically, as shown, Client A 80 (e.g., first electronic device) and Client B 82 are securely paired such that they agree upon a preset RCID 84. Client A 80 then sends a data packet 88 for Client B 82 over the network to the relay 86 (e.g., the IoT/IP system). The data packet 88 includes the RCID 90 (e.g, the same as preset RCID 84), the role identifier 92 of the sending client (e.g., A if sent from Client A 80, B if sent from Client B 82), and an encrypted payload 94, though as noted above in other embodiments the payload is not encrypted. The relay 86 receives the data packet 88 from Client A 80 and then decrypts the data packet 88 to reveal the RCID 90, the role identifier 82, and the still encrypted payload 94 (which step is not performed if the payload is not encrypted). Client B 82 retrieves the data packet 88 from the relay 86 using the preset RCID 84, and then decrypts data packet 88 and the encrypted payload 94. The relay 86 in some embodiments encrypts the data packet 88 for transmission to Client B 82. In some such embodiments, the encrypted payload 94 of the data packet 88 is never decrypted by the relay 86. The relay 86 only provides data packet decryption, not payload decryption.

FIG. 7 illustrates processing steps 100 of a secure log storage subsystem of an exemplary IoT/IP system. In step 102, the IoT/IP system electronically receives over a network a data packet (e.g., message, communication, record, etc.) from a log generator (e.g., first electronic device) paired (e.g., synced) with one or more log consumers (e.g., second electronic devices). The log generator and log consumer are paired such that the devices agree on a Remote Storage Identification (RSID) (e.g., linking address). The RSID in various embodiments exists in a very sparse name space and could be a random token, number, a word, a passphrase, a symbol, etc. If an RSID should be of sufficient complexity (e.g., size, variability, etc.) is used, that specific RSID being used will be impractical to guess or deduce. For example, the RSID may be a token of 128 bits. The log generator and log consumer (e.g., two electronic devices) may be paired together (e.g., and agree on a common RSID) in any of a variety of ways. For example, the two electronic devices could communicate directly with one another (e.g., using Bluetooth, Wi-Fi, etc.), the two electronic devices could be packaged and sold together such that the devices have been preprogrammed with the common RSID by the manufacturer, and/or the two electronic devices could be registered with a website which syncs the two devices together. Alternatively, a user could manually enter a RSID in each of the devices and/or manually enter a unique passphrase (e.g., word, sentence, etc.) which is processed by a pre-programmed mathematical algorithm to correlate with a RSID (e.g., entering the passphrase on each device gets processed by the same algorithm so that each device independently comes up with the same RSID). Additionally, or alternatively, the log generator could create an RSID upfront, use it to store log entries, and subsequently electronically communicate the RSID to one or more log consumers. Any suitable method of electronic communication may be used, such as secure socket layer (SSL), etc. The two electronic devices may also have established credentials (e.g., shared secrets) that enable secure communication over insecure channels. More specifically, such established credentials enable end-to-end encryption between the devices to protect communications from the IoT/IP system and/or anyone else. In this way, the entire data packet may be encrypted by a first encryption having an RSID and a payload encrypted by a second encryption. Thus, the log entries could be stored encrypted, and only authorized log consumers can decrypt them. In step 104, the IoT/IP system decrypts the data packet received if encrypted by a public key of the server of the IoT/IP system. Data packet encryption hides the RSID from observers and prevents interference by third parties (e.g., prevents third parties from learning the RSID). To encrypt the data packet, any of the existing public key schemes can be used (e.g., RSA, Diffie-Hellman (DH), elliptic curve cryptography (ECC), etc). However, as discussed above, the IoT/IP system does not require security associations. Electronic communications from the log generator and/or the log consumer to the IoT/IP system could be encrypted with the public key of the server of the IoT/IP system. In step 106, the IoT/IP system then processes the data packet received to identify the RSID and payload (e.g., encrypted payload), thereby associating the log entry with the RSID. In step 108, the IoT/IP system records the IP address of the data packet and/or the time received (e.g., adds a timestamp to the data packet) in the database. In step 110, the IoT/IP system stores the packet in a database (e.g., a key-value database). Any of a variety of databases could be used, such as Riak. The storage mechanism provides at least retrieval operation on RSID alone. Additionally, the storage mechanism may also provide retrieval on RSID and a timestamp range, deletion of contents associated with RSID, and/or silent log record dropping (e.g., after age and/or capacity per RSID is reached or exceeded). If the payload is encrypted, any of a variety of procedures for securing information at rest could be used. For example, an encrypted payload could include random salt (e.g., Initialization Vector (IV), etc.), payload length, and/or Initialization Vector with log entry (e.g., encrypted by a stream cipher using shared secret as a key).

In step 112, the IoT/IP system electronically receives a query (e.g., request) from a log consumer. The request includes the RSID and may optionally include query terms (e.g., maximum number of latest entries to be retrieved and/or time of oldest entry to retrieve, etc.). The request may be encrypted with the public key of the server of the IoT/IP system. This encryption hides the RSID from observers and prevents interference by third parties (e.g., prevents third parties from learning the RSID). To encrypt the data packet, any of the existing public key schemes can be used (e.g., RSA, Diffie-Hellman (DH), elliptic curve cryptography (ECC), etc). However, as discussed above, the IoT/IP system does not require security associations. Particularly for data packets with end-to-end encryption and authentication with pre-established credentials, securing electronic communication (e.g., traffic) between clients and the IoT/IP system is not required. Encrypting the RSID with the public key of the IoT/IP server and using sparse ID name space ensures that attackers cannot insert malicious traffic or log entries, or pose as legitimate communications peers or consumers, thereby preventing targeted denial of service (DoS) attacks and snooping. In step 114, the IoT/IP system retrieves the log entries requested (e.g., consistent with the query terms) from the database. In step 116, the IoT/IP system electronically transmits the log entries to the log consumer. If encrypted, the log entry (e.g., payload) remains opaque to third parties. The electronic transmission may include a timestamp and/or be encrypted, such as by the IoT/IP system server and log consumer establishing a one-time shared secret by an public key method (e.g., Diffie-Hellman). In this way, the IoT/IP system acts as a storage between the first electronic device and the second electronic device. The IoT/IP system is completely indifferent (e.g., agnostic) as to the identity of the electronic devices (e.g., log generators, log consumers, etc.), the content of the encrypted log entries, the identity of the owner of one or both of the electronic devices, etc. However, because the RSID range is so large, only the agreed upon parties (e.g., the log generator and the log consumer) can deposit and retrieve log entries. Thereby, the IoT/IP provides the privacy and security necessary for electronic communications over a network. The IoT/IP system (e.g., secure relay communication subsystem, secure log storage subsystem) does not process or store any identifying information about the clients (e.g., electronic devices, owners of electronic devices, etc.). This substantially reduces setup costs, maintenance costs, and data storage requirements. However, as the IoT/IP system does not utilize any identifying information, unrelated parties (e.g., unauthorized users) could attempt to use the IoT/IP system. Accordingly, if desired, to counteract potential abuse or use by unauthorized users (e.g., nonpaying users), each authorized electronic device could be issued a unique blinded certificate. The unique blinded certificate (e.g., bureau document) could be required to be submitted periodically (e.g., with the first log entry, every inactivity timer period, etc.). The unique blinded certificate may be embedded by the manufacturer, issued from online registration, etc. Thus, the IoT/IP system could recognize a valid certificate, but does not associate it with a particular electronic device and/or user. The IoT/IP system may, in some embodiments, monitor for signs of abuse and could blacklist (e.g., ban) any certificates and/or IP addresses found to cause abuse, thereby preventing the IP address or certificate holder from accessing the IoT/IP system. Such signs of abuse could include access to a particular RCID by an IP address where the IP address changes too frequently, or concurrent use of a particular RSID by two devices with the same certificate but different IP addresses, or a third electronic device attempting to use a particular RCID, etc.

Using sparse ID (e.g., linking address, RSID, RCID) name space provides very efficient client-side load balancing and high availability. Assuming N log servers (which do not need to be connected), each client (e.g., generator, consumer, Client A, Client B, etc.) have a list of addresses of all active servers (e.g., Server[N]). To select a server, a client (e.g., generator, consumer, Client A, Client B, etc.) calculates index i=ID mod N (where ID is either RCID or RSID), and both select Server[i]. At least in embodiments where ID is randomly chosen, the load will be evenly distributed over N log servers without any additional procedures. Instead of using ID directly, a hash of ID (e.g., i=hash(ID) mod N) may be used to avoid consequences of potential poor randomness of ID.

Using a hash of the ID can also be used to work around failed log servers. For example, if a log server fails to respond to certain packets as expected (e.g., a response does not arrive), the generator or consumer simply increment RSID by one, and calculate new i=hash(RSID) mod N again, until the server responds.

FIG. 8 is a diagram showing hardware and software components of an exemplary IoT/IP system 200. The system 200 comprises a processing server 202 which may include one or more of a storage device 204, a network interface 208, a communications bus 210, a central processing unit (CPU) (microprocessor) 212, a random access memory (RAM) 214, and one or more input devices 216, such as a keyboard, mouse, etc. The server 202 may also include a display (e.g., liquid crystal display (LCD), cathode ray tube (CRT), etc.). The storage device 204 may comprise any suitable, computer-readable storage medium such as disk, non-volatile memory (e.g., read-only memory (ROM), eraseable programmable ROM (EPROM), electrically-eraseable programmable ROM (EEPROM), flash memory, field-programmable gate array (FPGA), etc.). The server 202 may be a networked computer system, a personal computer, a smart phone, tablet computer etc. The functionality provided by the present disclosure may be provided by an IoT/IP program/engine 206, which may be embodied as computer-readable program code stored on the storage device 204 and executed by the CPU 212 using any suitable, high or low level computing language, such as Python, Java, C, C++, C#, .NET, MATLAB, etc. The network interface 208 may include an Ethernet network interface device, a wireless network interface device, or any other suitable device that permits the server 202 to communicate via the network. The CPU 212 may include any suitable single- or multiple-core microprocessor of any suitable architecture that is capable of implementing and running the IoT/IP engine 206 (e.g., Intel processor). The random access memory 214 may include any suitable, high-speed, random access memory typical of most modern computers, such as dynamic RAM (DRAM), etc.

Having thus described the system and method in detail, it is to be understood that the foregoing description is not intended to limit the spirit or scope thereof. It will be understood that the embodiments of the present disclosure described herein are merely exemplary and that a person skilled in the art may make any variations and modification without departing from the spirit and scope of the disclosure. All such variations and modifications, including those discussed above, are intended to be included within the scope of the disclosure.

Claims

1. A system for secure communication, comprising:

a computer system in electronic communication over a network with a plurality of electronic devices;

a database in electronic communication with the computer system, the database configured to electronically store at least a linking address and an associated payload of a data packet;

an engine stored on and executed by the computer system,

the engine configured and adapted for: electronically receiving a data packet over the network from a first electronic device; processing the data packet to identify a linking address and a payload contained therein, the linking address being at least 32 bit; storing the linking address and the payload in the database; electronically receiving a query from a second electronic device, the second electronic device identifying the linking address; and electronically transmitting the data packet over the network to the second electronic device.

2. The system of claim 1, wherein the linking address is at least 128 bit.

3. The system of claim 1, wherein the engine is indifferent to identifying information of the first electronic device and the second electronic device.

4. The system of claim 1, wherein the first electronic device and the second electronic device are paired with one another such that the linking address is agreed upon prior to the engine receiving the data packet.

5. The system of claim 1, wherein the data packet is encrypted upon receipt by the engine, and the engine decrypts the data packet received from the first electronic device.

6. The system of claim 5, wherein the payload of the decrypted data packet is encrypted.

7. The system of claim 1, wherein the payload is encrypted when received by the engine, and remains encrypted when transmitted to the second electronic device.

8. The system of claim 1, wherein the data packet includes a role identifier.

9. The system of claim 1, wherein the engine encrypts the data packet before transmitting the data packet to the second electronic device.

10. The system of claim 1, wherein the engine receives a unique blinded certificate with the data packet from the first electronic device.

11. A method for secure communication, comprising:

electronically receiving, at an engine stored on and executed by a computer system, a data packet from a first electronic device over a network;

processing the data packet to identify a linking address and a payload contained therein, the linking address being at least 32 bit;

storing the linking address and the associated payload of the data packet in a database;

electronically receiving a query from a second electronic device, the second electronic device identifying the linking address; and

electronically transmitting the data packet over the network to the second electronic device.

12. The method of claim 11, wherein the linking address is at least 128 bit.

13. The method of claim 11, wherein the engine is indifferent to identifying information of the first electronic device and the second electronic device.

14. The method of claim 11, wherein the first electronic device and the second electronic device are paired with one another such that the linking address is agreed upon prior to the engine receiving the data packet.

15. The method of claim 11, further comprising decrypting the data packet.

16. The method of claim 15, wherein the payload of the decrypted data packet is encrypted.

17. The method of claim 11, wherein the payload is encrypted when received by the engine, and remains encrypted when transmitted to the second electronic device.

18. The method of claim 11, wherein the data packet includes a role identifier.

19. The method of claim 11, further comprising encrypting the data packet before transmitting the data packet to the second electronic device.

20. The method of claim 11, wherein the engine receives a unique blinded certificate with the data packet from the first electronic device.

21. A non-transitory computer-readable medium having computer-readable instructions stored thereon which, when executed by a computer system, cause the computer system to perform the steps of:

electronically receiving, at an engine stored on and executed by the computer system, a data packet from a first electronic device over a network;

processing the data packet to identify a linking address and a payload contained therein, the linking address being at least 32 bit;

storing the linking address and the associated payload of the data packet in a database;

electronically receiving a query from a second electronic device, the second electronic device identifying the linking address; and

electronically transmitting the data packet over the network to the second electronic device.

22. The computer-readable medium of claim 21, wherein the linking address is at least 128 bit.

23. The computer-readable medium of claim 21, wherein the engine is indifferent to identifying information of the first electronic device and the second electronic device.

24. The computer-readable medium of claim 21, wherein the first electronic device and the second electronic device are paired with one another such that the linking address is agreed upon prior to the engine receiving the data packet.

25. The computer-readable medium of claim 21, wherein the computer-readable instructions, when executed by a computer system, further cause the computer system to perform the step of decrypting the data packet.

26. The computer-readable medium of claim 25, wherein the payload of the decrypted data packet is encrypted.

27. The computer-readable medium of claim 21, wherein the payload is encrypted when received by the engine, and remains encrypted when transmitted to the second electronic device.

28. The computer-readable medium of claim 21, wherein the data packet includes a role identifier.

29. The computer-readable medium of claim 21, wherein the computer-readable instructions, when executed by a computer system, further cause the computer system to perform the step of encrypting the data packet before transmitting the data packet to the second electronic device.

30. The computer-readable medium of claim 21, wherein the engine receives a unique blinded certificate with the data packet from the first electronic device.