Lattice mesh

Abstract

To provide a system for a grid mesh with improved security. [Solution] In a system for a grid mesh, a hub node includes an interface and a processor. The interface receives a registration request from a host node. The registration request includes a key and a set of asset IDs that the host node wishes to claim. The processor signs the key, generates a resource authority (RA) certificate using the RA certificate, updates an asset database using the RA certificate signing key, distributes the RA certificate signing host public key over the network, and provides the RA certificate signing key to the host node. The system may further include a memory coupled to the processor and configured to provide instructions to the processor.

Description

[Technical Field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] This application claims priority to U.S. Provisional Patent Application No. 62 / 683,533, filed June 11, 2018, entitled "AUTONOMOUS SENSOR SYSTEM ARCHITECTURE AND INTERFACE," which is hereby incorporated by reference in its entirety. [Background technology]

[0002] Networks of devices are typically considered secure and not vulnerable to attacks due to the corruption of a given node. However, if the node is compromised, then data traffic passing through the node and other information stored on the node can be secretly spied upon, creating a network security issue. Furthermore, networks are also typically designed to provide stable communications, leading to problems with network traffic being lost or not being delivered. [Brief explanation of the drawings]

[0003] Various embodiments of the present invention are disclosed in the following detailed description and the accompanying drawings.

[0004] [Figure 1] FIG. 1 is a block diagram illustrating an embodiment of a mesh network.

[0005] [Figure 2] FIG. 1 is a block diagram illustrating an embodiment of a hub.

[0006] [Figure 3A] FIG. 1 is a block diagram illustrating an embodiment of a mesh node.

[0007] [Figure 3B] FIG. 1 is a block diagram illustrating an embodiment of a host node.

[0008] [Figure 3C] FIG. 2 is a block diagram illustrating an embodiment of a collection sink node.

[0009] [Figure 3D] FIG. 1 is a block diagram illustrating an embodiment of a host service.

[0010] [Figure 4] 1 is a flow diagram illustrating an embodiment of a registration process.

[0011] [Figure 5A] FIG. 1 is a block diagram illustrating an embodiment of mesh network communication.

[0012] [Figure 5B] FIG. 1 illustrates an embodiment of a communication channel.

[0013] [Figure 5C] FIG. 1 illustrates an embodiment of a communication channel.

[0014] [Figure 5D] FIG. 1 illustrates an embodiment of communication in a grid mesh.

[0015] [Figure 5E] FIG. 1 illustrates an embodiment of communication in a grid mesh.

[0016] [Figure 6] 1 is a flow diagram illustrating an embodiment of a process for publishing on a mesh network.

[0017] [Figure 7] 1 is a flow diagram illustrating an embodiment of a process for receiving a message.

[0018] [Figure 8]1 is a flow diagram illustrating an embodiment of a process for transmitting a message. DETAILED DESCRIPTION OF THE INVENTION

[0019] The present invention may be implemented in various ways, including as a process, an apparatus, a system, an article of matter, a computer program product embodied in a computer-readable storage medium, and / or as a processor, such as a processor configured to execute instructions stored in and / or provided by a memory coupled to the processor. These implementations, or any other form the present invention may take, may be referred to herein as techniques. In general, the order of steps of disclosed processes may be varied within the scope of the present invention. Unless otherwise specified, components such as processors or memories described as configured to perform a task may be implemented as general components temporarily configured to perform the task at a given time, or as specialized components manufactured to perform the task. As used herein, the term “processor” refers to one or more devices, circuits, and / or processing cores configured to process data, such as computer program instructions.

[0020] A detailed description of one or more embodiments of the present invention is provided below along with accompanying figures that illustrate the principles of the invention. While the present invention will be described in connection with such embodiments, the present invention is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the present invention encompasses numerous alternatives, modifications, and equivalents. In order to provide a thorough understanding of the present invention, numerous specific details are set forth in the following description. These details are provided for illustrative purposes, and the present invention may be practiced according to the claims even without some or all of these specific details. For clarity, technical subjects that are well known in the art related to the present invention have not been described in detail so as not to unnecessarily obscure the present invention.

[0021] A system for a grid mesh is disclosed. The system includes an interface and a processor. The interface is configured to receive a registration request from a host, the registration request including a key and a set of asset IDs that the host wishes to claim. The processor is configured to sign the key and generate a resource authority (RA) certificate signing key using an RA certificate, update an asset database using the RA certificate signing key, distribute the RA certificate signing host public key over a network, and provide the RA certificate signing key to the host. In some embodiments, the system further includes a memory coupled to the processor and configured to provide instructions to the processor.

[0022] The lattice mesh system includes a security mechanism for communication within the lattice mesh. Inter-node communication for messages with targeted destinations is possible in both point-to-point mode and open mode, where messages can be targeted to multiple destinations. Communication security is designed to prevent compromised nodes from being used to retrieve important messages from the network. Furthermore, the network prioritizes real-time data despite varying network link performance. The network also ensures security by establishing secure routing using point-to-point authorization. The network also strategically caches data flowing within the network so that data can be transmitted when channels are available.

[0023] A trellis mesh is an improvement over other networks due to its improved security. The network is designed to overcome unstable communication links and the possibility of nodes becoming compromised. A trellis mesh overcomes these potential problems by using a security system that secures messages, secures routes, and secures the backfilling of messages waiting to be sent through the network.

[0024] FIG. 1 is a block diagram illustrating an embodiment of a mesh network. In the illustrated example, the mesh network includes multiple nodes (e.g., mesh node 100, mesh node 102, mesh node 104, mesh node 106, mesh node 108, mesh node 110, mesh node 112, collection sink node 114, mesh node 116, etc.). Host node 118 comprises a new device, sensor, or tower requesting to join the mesh network. Host node 118 discovers mesh node 116 and requests it to join the network. The mesh network notifies host node 118 of the address of a hub, or host node 118 is preloaded with the address of a hub. Host node 118 contacts hub 120 and registers with a resource station running on hub 120. Collection sink node 114 comprises a mesh node that includes a backfill database. The backfill database stores data passing through the network and stores the data when a transmission cannot be completed. The backfill database acts as a repository so that data can be later provided between nodes.

[0025] FIG. 2 is a block diagram illustrating an embodiment of a hub. In some embodiments, the hub of FIG. 2 is used to implement hub 120 of FIG. 1. In the illustrated example, hub 200 includes a resource authority (RA) 202. Resource authority (RA) 202 includes a certificate authority (CA) 204, a key store 206, an asset database (DB) 208, a host-to-request map 210, and an asset database sharer 212. Resource authority 202 runs on hub 200. In some embodiments, hub 200 runs on a central cloud-based server or virtual machine. CA 204 acts as a certificate authority for the system and responds to registration requests by new devices. CA 204 also allows services to authenticate devices and verify whether to allow them on the system's mesh network. CA 204 can be self-signed or can have trust delegated to it from a higher-level certificate authority. Key store 206 holds the public keys of allowed hosts on the network and assigns unique numeric host IDs to hosts. In some embodiments, key store 206 uses a hardware security module (HSM) 214 to provide tamper resistance for physically compromised nodes as well as to prevent software-based compromise of keying material. In some embodiments, RA 202 can use a cloud-based HSM to store keys and sign new asset DBs and host certificates. Asset DB 208 stores a mapping of hosts (e.g., host public key → host ID → list of asset IDs). Asset DB 208 is also used to ensure that asset IDs are unique across all systems. In some instances, asset DB 208 is referred to as a host map.

[0026] In some embodiments, asset DB 208 includes a signed, monotonically increasing version number that can be used to securely determine whether a neighbor's asset DB should be used. For example, a host can query a neighbor to see which version number of the neighbor's asset DB is higher than the version number the neighbor has. In response to a neighbor having an asset DB with a higher version number, the host node can transfer the asset DB from the neighbor to itself and store the higher version number asset DB in place of the current, lower version asset DB currently stored on the host node.

[0027] The host public key → (host ID, [asset ID]) mapping is signed by RA 202 and is used throughout the system for naming and addressing purposes. Host-to-request map 210 contains the mapping between hosts and the requests they can make. An asset database sharer 212 is used to securely distribute, or gossip, the asset DB to other nodes in the system so that the host map is available even when a wireless communication link (e.g., LTE, cellular, WiFi, etc.) to a central hub is not available.

[0028] FIG. 3A is a block diagram illustrating an embodiment of a mesh node. In some embodiments, a mesh network 300 is used to implement the mesh nodes of FIG. 1 (e.g., mesh node 100, mesh node 102, mesh node 104, mesh node 106, mesh node 108, mesh node 110, mesh node 112, collection sink node 114, and mesh node 116). In the illustrated example, mesh node 300 may comprise a drone, an observation station (e.g., a tower), a small autonomous sensor (e.g., a sensor, a "dust" sensor, etc.), a helicopter, or any other suitable number of mesh nodes. Mesh node 300 includes a host service 302. Host service 302 runs on mesh node 300 using a processor and handles a routing and gossip service that distributes host-signed assertions about network reachability and service discovery information as well as an asset database for RAs. The host service 302 also publishes and subscribes to latency-sensitive, time-ordered message streams (including video data) from different types of assets (e.g., other mesh nodes on the mesh network, nodes on a subnetwork, etc.). The host service 302 operates a single network service and has a unique private / public key pair that identifies it. The RA assigns a unique numeric host ID for each authorized public key. A mesh node 300 may operate one or more assets locally connected to the mesh node 300, in which case the mesh node 300 maintains a locally routable connection (e.g., via localhost or another local subnet) to a publish / subscribe and HTTP / 2 proxy to make publish / subscribe requests and perform one or more secure remote procedure calls (RPCs). An asset has an associated asset ID and a set of asset characteristics (e.g., drone, unattended ground sensor (UGS), tower, etc.). Each asset characteristic corresponds to a list of offered RPC services and produced publish / subscribe topic names.

[0029] FIG. 3B is a block diagram illustrating an embodiment of a host node. In some embodiments, a host node 310 is used to implement the host node 118 of FIG. 1. In the illustrated example, the host node 310 is a node attempting to join a mesh network and become a mesh node. The host node 310 may comprise a drone, an observation station (e.g., a tower), a small autonomous sensor (e.g., a sensor, a "dust" sensor, etc.), a helicopter, or any suitable number of mesh network devices. The host node 310 includes a host service 312. The host service 312 runs on the host node 310 using a processor and handles a routing and gossip service that distributes the RA's asset database as well as host-signed assertions about network reachability and service discovery information. The host service 312 also publishes and subscribes to latency-sensitive, time-ordered message streams (including video data) from different types of assets (e.g., other mesh nodes on the mesh network, nodes on sub-networks, etc.). The host service 312 operates a single network service and has a unique private / public key pair that identifies itself. The RA assigns a unique numeric host ID for each authorized public key. A host node 310 may operate one or more assets connected locally to the host node 310, where the host node 310 maintains a locally routable connection (e.g., via localhost or another local subnet) to a publish / subscribe and HTTP / 2 proxy to make publish / subscribe requests and fulfill one or more secure remote procedure calls (RPCs). An asset has an associated asset ID and a set of asset characteristics (e.g., drone, UGS, tower, etc.). Each asset characteristic corresponds to a list of offered RPC services and produced publish / subscribe topic names.

[0030] FIG. 3C is a block diagram illustrating an embodiment of a collection sink node. In some embodiments, a host node 320 is used to implement the collection sink node 114 of FIG. 1. In the illustrated example, the host node 310 is a node attempting to join the mesh network and become a mesh node. The host node 310 may comprise a drone, an observation station (e.g., a tower), a small autonomous sensor (e.g., a sensor, a "dust" sensor, etc.), a helicopter, or any suitable number of mesh network devices. The host node 310 includes a host service 312. The host service 312 runs on the host node 310 using a processor and handles a routing and gossip service that distributes not only the RA's asset database but also host-signed assertions about network reachability and service discovery information. The host service 312 also publishes and subscribes to latency-sensitive, time-ordered message streams (including video data) from different types of assets (e.g., other mesh nodes on the mesh network, nodes on subnetworks, etc.). The host service 312 operates a single network service and has a unique private / public key pair that identifies itself. The RA assigns a unique numeric host ID for each authorized public key. A host node 310 may operate one or more assets connected locally to the host node 310, where the host node 310 maintains a locally routable connection (e.g., via localhost or another local subnet) to a publish / subscribe and HTTP / 2 proxy to make publish / subscribe requests and fulfill one or more secure remote procedure calls (RPCs). An asset has an associated asset ID and a set of asset characteristics (e.g., drone, UGS, tower, etc.). Each asset characteristic corresponds to a list of offered RPC services and produced publish / subscribe topic names.

[0031] FIG. 3D is a block diagram illustrating an embodiment of a host service. In some embodiments, host service 330 is used to implement host service 302 of FIG. 3A, host service 312 of FIG. 3B, or host service 322 of FIG. 3C. In the illustrated example, host service 330 includes registration requestor 332, key store 334, asset database 336, and asset database sharer 338. Registration requestor 332 can issue a registration request to the mesh network in response to initially discovering one or more local mesh nodes or in response to adding or removing a new asset associated with the node on which the host service is operating. In some embodiments, an RA public key is pre-pinned to each host, allowing the host node to identify the appropriate RA for registration. Key store 334 holds the host's private key, which assigns a unique numeric host ID to each host authorized on the network. In some embodiments, the key store 334 uses a hardware security module (HSM) 340 to provide tamper resistance for physically compromised nodes, as well as to prevent software-based compromise of keying material. In some embodiments, a removable HSM can be attached to a host node to store and distribute private keying material and sign new host assertions. The asset DB 336 stores a mapping of hosts (e.g., host public key → host ID → list of asset IDs). The asset DB 336 is also used to ensure that asset IDs are unique across the system. The asset DB 336 is called the host map. The host public key → (host ID, [asset ID]) mapping is signed by the RA and used throughout the system for naming and addressing purposes. An asset database sharer 338 is used to securely distribute, or gossip, the asset DB to other nodes in the system so that the host map is available even when a wireless communication link (e.g., LTE, cellular, WiFi, etc.) to a central hub is not available.In some embodiments, the asset ID sharer 338 can determine whether a nearby node has a newer version of the asset DB than the current asset DB stored as part of the host service 330 .

[0032] 4 is a flow diagram illustrating an embodiment of a registration process. In some embodiments, the process of FIG. 4 is used by a host node (e.g., host node 118 of FIG. 1) to register with a mesh network (e.g., a mesh network composed of multiple mesh nodes, such as mesh nodes of FIG. 1, e.g., mesh node 100, mesh node 102, mesh node 104, mesh node 106, mesh node 108, mesh node 110, mesh node 112, collection sink node 114, and mesh node 116). In some embodiments, to prevent an attacker from adding deceptive equipment to the system or compromising a node and redirecting traffic from an asset to or between compromised nodes, the host node must carefully scrutinize the registration process when requesting to join the mesh network. In the illustrated example, at 400, a registration request for the mesh network is received. For example, a resource station (e.g., a hub node) receives a request from a host node wishing to join the mesh network. In some embodiments, the host node discovers local nodes in the mesh network that it can identify and uses one or more of the local mesh nodes to communicate a request to join the mesh network to the appropriate resource authority. In some embodiments, the registration process involves the host making a secure RPC to the RA with the request. In some embodiments, the request is triggered by adding a new asset to the host. In some embodiments, the request is triggered by deleting an asset from the host; for example, a host asset is removed (e.g., due to a software update, hardware update, unplugging the asset, etc.), or a user remotely removes an asset after verifying authorization to remove the asset. Any changes to the assets associated with the host result in a new asset DB being distributed. At 402, the host node public key is received.For example, the host node provides the public key once a link to the resource station is established (e.g., in response to a request for the public key from the resource station), either as part of a request to join the mesh network or as a separate communication. At 404, the host node public key is signed. For example, the resource station signs the host node public key using the RA certificate. At 406, a list of assets associated with the host node is received. For example, the resource station requests a list of assets associated with or requested by the host node in connection with the request to join the mesh network, or the list of assets is received along with the request to join the mesh network. At 408, the assets in the asset list are added to the DB. For example, each asset in the asset list is added to the asset DB associated with the host identifier. At 410, the asset database is distributed throughout the mesh network. For example, the asset database is gossiped or distributed throughout the network. At 412, a certificate with the host public key signed by the RA is provided to the host. For example, the certificate can then be received by the host, which can use it to connect to the mesh network using a mutually authenticated transport layer security (TLS) connection. Using the signed public key and both the host node and the host assets added to the asset database, the host node can initiate secure RPCs with other nodes in the mesh network and read messages delivered to it. When other mesh nodes receive communications from other host nodes, they verify that the host's public key is signed by the RA to verify that the host is authorized on the mesh network and that the certificate's serial number is not present in the signature revocation list in the asset database. Whenever an asset is added to a host node, the registration process is restarted. Once the asset is approved, it is added to the asset database associated with the host (e.g., associated with the host public key or any other suitable host identifier), and the asset database is distributed throughout the mesh network using a gossip or distribution protocol.

[0033] In some embodiments, an asset database (DB) includes a signed, monotonically increasing version number that can be used to securely determine whether a neighbor's asset DB should be used. For example, a host can ask a neighbor which version number of the neighbor's asset DB is higher than the version number the neighbor has. In response to the neighbor having an asset DB with a higher version number, the host node can have the asset DB transferred from the neighbor to itself and store the higher version number asset DB in place of the current, lower version asset DB currently stored on the host node.

[0034] 5A is a block diagram illustrating an embodiment of mesh network communication. In some embodiments, the mesh nodes of FIG. 5A (e.g., mesh node A 500, mesh node B 502, and mesh node C 504) are the mesh nodes of FIG. 1 (e.g., mesh node 100, mesh node 102, mesh node 104, mesh node 106, mesh node 108, mesh node 110, mesh node 112, collection sink node 114, mesh node 116). In the illustrated example, mesh node C 504 sends a first RPC 506 to mesh node B 502 to establish communication. Mesh node C 504 sends a second RPC 508 to mesh node A 500 to establish communication.

[0035] FIG. 5B illustrates an embodiment of a communication channel. In some embodiments, the communication channel illustrated in FIG. 5B is used in communication between mesh node C 504 and mesh node B 502 of FIG. 5A. In the illustrated example, transmission control protocol (TCP) communication is used in communication between the two mesh nodes (e.g., mesh node C → mesh node B). The communication hosts a mutually authenticated transport layer security (TLS) connection. Within the TLS connection, a stream-oriented multiplexer operates three types of streams: 1) distribution or gossip / pubsub traffic operating a single messaging framing protocol; 2) HC2 (HTTP / 2 plaintext) for locally terminated one-hop RPC traffic; and 3) simple packet forwarding of TLS traffic to facilitate multi-hop end-to-end encrypted RPC connections (e.g., mesh node C → mesh node A communication). In the multiplexer protocol, the header contains quality of service (QoS) information, and for multi-hop RPCs, the header contains routing information about the intended destination. The multi-hop connection is encrypted end-to-end so that intermediate nodes cannot eavesdrop and so that each endpoint can authenticate each other. This is achieved by the endpoint nodes establishing TLS / AES-GCM (transport layer security advanced encryption standard Galois counter mode) using certificates provided by the RA. The certificate contains RA-signed host identities so that hosts cannot impersonate each other.To provide QoS, each host maintains a single TCP connection or quick User Datagram Protocol (UDP) internet connection (QUIC) to each host's next-hop peer. The TCP connection multiplexes multiple streams over the TCP connection, allowing for coarse-grained prioritization at the stream level.

[0036] 5C is a diagram illustrating an embodiment of a communication channel. In some embodiments, the mesh nodes of FIG. 5C (e.g., mesh node A 510, mesh node B 512, and mesh node C 514) are the mesh nodes of FIG. 1 (e.g., mesh node 100, mesh node 102, mesh node 104, mesh node 106, mesh node 108, mesh node 110, mesh node 112, collection sink node 114, mesh node 116). In the illustrated example, mesh node C 514 has a TCP connection 516 to mesh node B 512. Mesh node B 512 has a TCP connection 518 to mesh node A 510. A TLS connection 522 connects mesh node C 514 and mesh node B 512 for communication. A TLS connection 520 connects mesh node C 514 and mesh node A 510 for communication.

[0037] In some embodiments, the RA distributes bearer tokens in the form of JSON web tokens (JWTs). Bearer tokens are a mechanism for services in the system to verify that a client has permission to perform certain actions without having to synchronously check with a central authority. A JWT is a set of claims in JSON (JavaScript Object Notation) format that are base64 encoded and cryptographically signed using the RA certificate. A service can verify a claim in a JWT by verifying the payload signature using the RA certificate. The claim comprises a resource identifier (e.g., resources / assets / abce1234) and an action (e.g., pubsub:view) or permission. The JWT is provided by the hub during registration and must be periodically refreshed (by exchanging the old JWT for a new one with the hub).

[0038] In some embodiments, the system uses signed asset DB and host assertions to provide naming and addressing for the system. For example, 3e.host.local maps to host ID 3e, 5fe.asset.local maps to asset ID 5fe, and ptu.8b2.asset.local maps to property "ptu" running on asset ID 8b2.

[0039] FIG. 5D is a diagram illustrating an embodiment of communication in a lattice mesh. In the illustrated example, a subscriber at node 3 requests from a publisher that node 3 receive messages published by the publisher. The join request is sent to the publisher at node 1, e.g., to node 2 along the route to reach node 1. Node 2 receives the request and forwards it to node 1 along the route. In some cases, there are multiple nodes along the route that relay the request to its final destination at the publisher node. The publisher at node 1 then receives the request and determines whether the requesting subscriber, node 3, is authorized to join (e.g., by querying an asset DB to see if the subscriber at node 3 is authorized to subscribe to messages published by node 1, or by querying an RA to see if the subscriber at node 3 is authorized to subscribe to messages published by node 1, or any other suitable authorization list or mechanism). In response to being authorized, the publisher provides the group key to the subscriber at node 3 via node 2 along the route. When receiving a data stream from an asset at node 1 (e.g., a camera provides a video stream to node 1), the publisher at node 1 signs and encrypts the data stream into a message (e.g., a signed encrypted message (SEM)) using the current group key. Note that the group key is periodically updated (e.g., changed at the publishing node 1, but also redistributed to subscriber nodes or provided to subscriber nodes in response to join or rejoin requests). Node 1 provides its subscribers with an SEM by publishing it, which is relayed by node 2 to the subscriber at node 3. The subscriber at node 3 decrypts the published SEM using the group key it received when it subscribed to the publisher's public stream.

[0040] FIG. 5E illustrates an embodiment of communication in a lattice mesh. In the illustrated example, a communication endpoint at node 3 requests that node 3 communicate directly with node 1. The point-to-point communication request is sent to node 1, e.g., node 2 along the route to reach node 1. Node 2 receives the request and forwards it to node 1 along the route. In some cases, there are multiple nodes along the route that relay the request to its final destination at the publisher node. Node 1 then receives the request and determines whether the requesting node, node 3, is authorized to communicate (e.g., by querying an asset DB to see if node 3 is authorized to communicate with node 1, or by querying an RA to see if node 3 is authorized to communicate with node 1, or any other suitable authorization list or mechanism). In response to being authorized, node 1 provides the host public key to node 3's subscriber via node 2 along the route. When receiving a data stream from an asset at node 1 (e.g., a camera provides a video stream to node 1), the publisher at node 1 signs and encrypts the data stream into a message (e.g., a signed and encrypted message (SEM)) using the current host public key. Note that the host public key is periodically updated (e.g., not only changed at node 1, but also redistributed to other nodes or provided to nodes in response to communication requests). In some cases, the host public key is distributed via asset DB distribution. Node 1's message is provided to the subscriber by publishing an SEM that is relayed by node 2 to the subscriber at node 3. Node 3 decrypts the published SEM using the host public key it received when requesting to communicate and / or receive the key database.

[0041] Figure 6 is a flow diagram illustrating an embodiment of a process for publishing on a mesh network. In some embodiments, the process of Figure 6 is used to publish messages through the mesh nodes of Figure 1 (e.g., mesh node 100, mesh node 102, mesh node 104, mesh node 106, mesh node 108, mesh node 110, mesh node 112, collect-sink node 114, mesh node 116). In some embodiments, to ensure that pub / sub (publish / subscribe) messages are delivered using multicast (i.e., a message appears only once per edge of the graph of nodes used for message delivery), a separate stream per subscription cannot be used, since it requires that intermediate pub / sub nodes be able to decrypt messages bound for other nodes. To accomplish this, each pub / sub message is individually decrypted using a topic group key. The group key is used to encrypt and authenticate forged messages. To securely obtain a topic group key, a client pub / sub node requests one from the server pub / sub node via RPC. The RPC specifies a keyId to use to decrypt the message and a bearer token that proves the client has access. The server then verifies the request using the RA certificate, and the client is given access to the group key if it is allowed to access the topic. The group key should have a relatively short lifetime (on the order of tens of minutes) and should be rotated periodically to ensure that revoking a node's access to the topic causes it to lose read access in a reasonable amount of time. The group key comprises the public key of an ephemeral key pair as well as a shared secret that is provided to the AES-GCM encryption mode for encrypting message data. AES-GCM creates a "tag" that serves as an HMAC; the HMAC, in this case, is signed with the private key of the key pair to provide non-repudiation, i.e., to prevent other hosts with access to the group key from forging messages.In some embodiments, a request for pub / sub service uses the resource identifier "resources / asset / ${assetId}" and the permission "allow / pubsub / view."

[0042] In the illustrated example, at 600, a request to join a public group is received from a client. For example, a generating node receives a request from a client or mesh node to join a public group related to a topic. At 602, a group key is determined. For example, the group key is determined by querying an asset DB regarding the authorization initially provided by the RA. At 604, it is determined whether the client is authorized to access the group topic. For example, the RA queries a database whether the client or mesh node has permission or access to a given topic related to the public group. In response to the client not being authorized to access the group topic, the process ends. In response to the client being authorized to access the group topic, at 606, the group key is provided to the client. For example, the group key is provided to the client or mesh node to transmit to the client. In 608, a group message including metadata is published. For example, the group message is published using the group key including metadata that can be used to appropriately filter messages at the client or mesh node. In 610, it is determined whether it is time to rotate the token. For example, tokens should be rotated frequently to allow a reasonable time response to revoking access privileges (e.g., tens of minutes, hours, seconds, or as appropriate for the network and network usage). In response to a determination that it is time to rotate the token, control is passed to 602. In response to a determination that it is not time to rotate the token, it is determined at 612 whether another group message is present. In response to another group message being present, control is passed to 608. In response to another group message not being present, control is passed to 610.

[0043] In some embodiments, the pub / sub request is at the asset level, allowing the bearer to read all topics that the asset produces.

[0044] In some embodiments, an asset may wish to subscribe to a subset of messages from a topic (e.g., a drone may be commanded to follow a trajectory from a tower). To allow this, each message exposes unencrypted metadata that can be used for filtering. When initiating a subscription, the metadata can specify a set of filters to apply to the message. The metadata is a map of keys to a set of values, and the filters allow for exact or prefix matches on the keys. Using this framework, basic geo-filtering using geo-hashes is possible. Metadata associated with a message can include a unique key (e.g., a key associated with the message's creator, a key associated with a time / date stamp, etc.), a media type (e.g., a protobuf (Protocol Buffer), a blob (Binary Large Object), a file type, e.g., a video file (e.g., a moving picture experts group (MPEG), MPEG-4 (MP4), etc.), a text file, an image file, a pdf file, etc.), and / or a timestamp. For image-based messages, the pub / sub message should be able to encode the image as a chunked MPEG stream for efficient transport and storage.

[0045] In some embodiments, each host creates a signed assertion list consisting of assets (signed by the RA and the host) and properties (signed only by the host). Properties are strings that describe the RPC service and grouping of topics created. In the host assertion list, the host can also include a list of string metadata tags that can be used for discovery purposes by the rest of the system. When publishing messages, the assets include not only the topic name but also a list of metadata tags for each message. The topic metadata tags can contain information useful for filtering. Intermediate nodes involved in routing multiple subscriptions can combine duplicate subscriptions using prefix matching. In some embodiments, homomorphic encryption is used to encrypt and perform prefix matching on the tags to remove the ability of intermediate routing nodes to eavesdrop when filtering the metadata.

[0046] In some embodiments, the pub / sub service can publish messages to a topic, where the topic is a (topic ID, asset ID) tuple. In some embodiments, the pub / sub service can subscribe to messages on any topic when specifying a topic (topic ID, asset ID) tuple, a delivery type (e.g., complete / backfilled, latest, last message, etc.), and a time to start (e.g., 0 start from the beginning of the stream, -1 start from "now", start messages at a specified time, etc.). In some embodiments, the pub / sub service can unsubscribe from messages on any topic (e.g., specified using a topic ID, asset ID that is also a tuple).

[0047] In some embodiments, the pub / sub service stores data so that historical queries can be answered (e.g., start streaming or publishing from a time in the past). In some embodiments, the hub node stores all data in a database. In some embodiments, other nodes in the system store each of the data (e.g., on permanent storage such as a hard drive).

[0048] FIG. 7 is a flow diagram illustrating an embodiment of a process for receiving a message. In some embodiments, the process of FIG. 7 is used to receive a private message or a public group message. In the illustrated example, at 700, a request to join a public group is provided from a client or a point-to-point communication link. For example, a request to join a public group is provided to an asset database from a client or a point-to-point communication link to the asset database. At 702, a group key or host public key is received. For example, a group key is received from an asset database. At 704, it is determined whether a message has been received. In response to a determination that the message has not been received, control is passed to 704. In response to a determination that the message has been received, it is determined at 705 whether to continue sending the message. In response to a determination that the message should continue sending, it continues sending the message at 712 and determines at 714 whether the message is destined for the host. In response to the message being destined for the host, control is passed to 706. In response to the message not being destined for the host, control is passed to 708. In response to a determination that the message should not continue to be sent, control is passed to 706. At 706, the message is decrypted using the group key. At 708, it is determined whether the message should be stored in a backfill database. For example, if the node is a collection sink node, it stores the message in the backfill database. In some embodiments, the node does not have a backfill database, and after decrypting the message, control is passed from 706 to 704. In response to a determination to store in the backfill database, at 710 the decrypted message is stored in the backfill database and control is passed to 704. In response to a determination not to store in the backfill database, control is passed to 704. For a typical node, the group key or host public key is stored in memory and is not stored in persistent storage such that if the persistent storage is compromised, the stored key cannot be used to decrypt the encoded message.In some cases, a node comprises a data sink, which is selected because it is believed to be secure.

[0049] FIG. 8 is a flow diagram illustrating an embodiment of a process for transmitting a message. In some embodiments, the process of FIG. 8 is used to send a private message or a public group message. In the illustrated example, at 800, a request to join a public group is provided from a client or a point-to-point communication link. For example, a request to join a public group is provided to an asset database from a client or a point-to-point communication link to the asset database. At 802, a group key or host public key is received. For example, a group key or host public key is received from the asset database. At 804, it is determined whether a message to be sent is available. In response to a determination that a message to be sent is not available, control is passed to 804. In response to a determination that a message to be sent is available, at 806, the message is encoded using the group key or host public key. For example, the message is encrypted using the group key or signed using the host public key. An important difference to note between the group key and the host public key is that the group key is a symmetric key used to encrypt / decrypt messages and is periodically rotated. The host public key is an asymmetric key that is stored on a hardware security module and is never rotated (a given host is assigned a single host public key at the time of manufacture). The host public key is used to sign messages that the host originates, so that other nodes with access to the group key (which other nodes access when they want to read messages) cannot forge messages. At 808, the message is sent, and control passes to 804. For example, the message is sent along a routing route to its destination, or published to the network. Note that only the generating node can publish to the public group.

[0050] In some embodiments, the system is designed to provide security so that if a single node is compromised, an attacker cannot access other components. In some embodiments, the system prevents a node from reading messages / RPCs destined for other nodes that are routed through the node. In some embodiments, the system prevents a node from undetectably modifying messages / RPCs destined for other nodes that are routed through another node. In some embodiments, the system prevents messages / RPCs intended for other nodes from being redirected to any given node (i.e., affecting routing table entries).

[0051] In some embodiments, the system allows a node to deny service to any message / RPC that passes through the node, even if the message / RPC is destined for another node. In some embodiments, the system allows a node to intercept messages / RPCs that are destined for the node. In some embodiments, the system allows a node to send messages that impersonate the node. In some embodiments, the system allows a node to subscribe to messages that the node can see. In some embodiments, the system allows a node to scrutinize the destination of all messages / RPCs that pass through the node.

[0052] In some embodiments, the keys use Elliptic Curve Digital Signature Algorithm (ECDSA) on the National Institute of Standards and Technology (NIST) P-256 curve with a compressed public key size of 33 bytes and a signature size of 64 bytes.

[0053] In some embodiments, the RA has a key pair and each host pins the RA public key, where the pinned key can only be changed with physical access to the host. In some embodiments, each host is assigned a hardware-based key pair at manufacturing time that cannot be changed without hardware modification. Hosts are identified using their public key, also known as the public key host identifier.

[0054] In some embodiments, the RA maintains a centralized list of authorized member host IDs. This list is updated through a registration process and distributed throughout the network. If a host becomes harmful (e.g., receives an indication that the host has been compromised), the RA can revoke any active certificates issued by that host. The serial number of the revoked certificate is included in the signed host list until the certificate's expiration date is reached. Each host advertises assertions about other hosts that it can reach upon its expiration date. The assertions are signed with the host's private key. An edge with one signed assertion is called a "candidate edge." An edge with two mutual assertions is called a "routable edge." Only routable edges are active in the network.

[0055] In some embodiments, the architecture is designed to limit the damage that a harmful node can cause. For example, a harmful node may spawn as many candidate edges as possible; however, if other legitimate hosts cannot reach the harmful node, the legitimate hosts will not spawn assertions about the harmful node's candidate edges, and no routable edges will be spawned. Thus, a harmful node is limited to spawning edges with legitimate nodes that it can reach.

[0056] In some embodiments, routes in a grid mesh network are created by signed assertions of mutual reachability. For a link to be created in the routing table, both sides of the link must agree and both sides must sign. Once established, the link is stored locally in the routing table. The damage that a malicious node can inflict on the routing table is limited to nodes that the malicious node can actually reach directly. The idea is that a malicious node, for example, cannot advertise that it is directly connected to every node in the network and therefore cannot drop all packets, thereby corrupting the network. Note that if a node is compromised, an attacker can still compromise applications running on the node. However, standard operating system best practices (such as ensuring that applications run as users that adhere to the principle of least privilege) can be used to protect against these attacks.

[0057] In some embodiments, the routing table with routable edges comprises: T2 → T1 T2 → T3 T1 → T2 The link between T1 and T2 is a routable edge because both T1 and T2 have signed assertions about mutual reachability. T3 is a candidate edge. The routing table contains entries for the order of the edges in the network, rather than the order of the hosts, as a traditional routing table would have.

[0058] In some embodiments, backfilling is used to refer to the process of recording data locally on a node so that historical data is available. This historical data is moved around the network so that the historical data is locally accessible to other nodes. Backfilling desirably has little or no impact on the pub / sub system. Persistent data is prioritized in the system, and backfilling operates using the bandwidth remaining after handling all surviving pub / sub subscriptions. A node's data that has been moved to another node is stored in the node if the node is compromised. If node B is given access to node A and stores encrypted data on disk, the key that node B uses to decrypt the data from A is time-limited. The key is stored in memory (e.g., not in non-ephemeral storage). This ensures that if an attacker compromises node B, they will only be able to see a time-limited window of the historical data. The pub / sub multicast delivery mechanism is used to deliver the backfilled data. If multiple nodes are interested in the backfill data, the data only needs to be transmitted once along each edge between the nodes. Data delivered through persistent pub / sub is also stored by intermediate nodes, eliminating the need to transmit data again for backfilling since the data has already been transmitted for persistent pub / sub. Historical data stored on the device cannot be read by an attacker who gains control of any given node.

[0059] In some embodiments, the dispatch server uses backfilling to recover data from nodes that occurred during periods of poor or no network connectivity so that the data is eventually available to users. In some embodiments, one or more dispatch servers operate on a network, and some of the dispatch servers may be deployed towards the edge of the network and may be potentially exposed to compromise.

[0060] In some embodiments, the global tracker uses network connectivity and quality of service data to globally refine all routes, and can perform track fusion (e.g., combine two separate tracks into one) in the face of unreliable network routes.

[0061] In some embodiments, backfill traffic is routed through the network as an RPC stream with its pub / sub at a lower priority. The data provided by the RPC backfill service is the same data that flows through the persistent pub / sub network (e.g., signed and encrypted messages encrypted using a group key). This allows intermediate nodes to store persistent pub / sub data and use it to fulfill backfill data requests. Because the data is encrypted and signed using the group key, nodes can answer backfill service RPCs on behalf of other nodes rather than requiring a secure RPC tunnel to the originator.

[0062] In some embodiments, the RA defines a set of "collection sinks," which are hosts in the network that need access to backfill data. The RA assigns each node a set of collection sinks in a HostList (signed by the RA in this case). All nodes use PGP or a similar framework (where each collection sink is a recipient) to store their historical group keys, encrypted at rest with their assigned collection sink public keys. In this case, the PGP-encrypted group key is made available through the backfill service to all nodes.

[0063] In some embodiments, to ensure significant throughput when a node uses a hardware storage module, the collection sink generates a separate collection sink public / private key pair when it registers with an RA and stores the public key portion encrypted on disk at rest using the device's private key (stored in the hardware storage module). The collection sink provides a collection sink public key when it registers with an RA. This public key can then be listed in the HostList as the collection sink's public key. On startup, the collection sink decrypts the collection sink private key, stores it in memory, and can use it to decrypt the group key to access the backfilled data.

[0064] In some embodiments, historical data stored on the captured device is inaccessible to an attacker without the attacker also compromising the collection sink assigned to the device. The attacker can still read the current group key from RAM, but is limited from viewing the forged data because the group key was recently rotated. In some embodiments, the original device does not need to be accessible to access the backfilled data; it only needs access to one of the collection sink's private keys. This is because intermediate nodes can cache encrypted messages as well as encrypted group keys. In some embodiments, the collection sink must be pre-defined, which means that the collection sink cannot backfill data because the creator node did not include the collection sink in its PGP recipient list when it was added. In some embodiments, the RA needs to be able to keep track of collection sinks, assign collection sinks to hosts, and maintain key pairs for collection sinks.

[0065] Although the foregoing embodiments have been described in some detail for clarity of understanding, the present invention is not limited to the details provided. There are many alternative ways to implement the present invention. The disclosed embodiments are illustrative and not restrictive. The present invention can also be realized as the following application examples. [Application example 1] 1. A system for a lattice mesh, comprising: an interface configured to receive a registration request from a host, the registration request including a key and a set of asset IDs that the host wishes to claim; 1. A processor, comprising: signing the key to generate an RA certificate signing key using the RA certificate; updating an asset database with said RA certificate signing key; Distributing the RA certificate signing key over the network; Providing the host with the RA certificate signing key and a processor configured as A system comprising: [Application example 2] A system as described in Application Example 1, wherein a message is encoded using a group key or a host public key in the asset database, and encoding the message comprises encrypting the message using the group key or signing the message using the host public key. [Application example 3] A system according to Application Example 2, wherein the message is transmitted to another node or is published to multiple nodes after encoding. [Application example 4] The system of application example 1, wherein the message is decrypted using a key group key or a host public key in the asset database. [Application example 5] The system according to application example 4, wherein the message is sent specifically to one node or published to multiple nodes. [Application Example 6] A system according to application example 1, wherein the interface and the processor belong to a hub. [Application Example 7] A system according to application example 6, wherein the hub includes a resource station. [Application Example 8] A system according to application example 7, wherein the resource authority includes a certificate authority. [Application Example 9] The system according to application example 7, wherein the resource station includes a key store. [Application Example 10] 11. The system of claim 10, wherein the key store stores keys in a hardware security module. [Application Example 11] The system according to application example 7, wherein the resource station includes an asset database. [Application Example 12] 10. The system of claim 7, wherein the resource station includes a host-to-request map. [Application Example 13] The system according to application example 7, wherein the resource station includes an asset database sharer. [Application Example 14] A system according to application example 1, wherein the host includes a host service. [Application Example 15] A system according to application example 14, wherein the host service includes a registration request source. [Application Example 16] A system as described in Application Example 14, wherein the host service includes a key store. [Application Example 17] 17. The system of claim 16, wherein the key store stores keys in a hardware security module. [Application Example 18] A system as described in Application Example 14, wherein the host service includes an asset database. [Application Example 19] A system as described in Application Example 14, wherein the host service includes an asset database sharer. [Application Example 20] 1. A method for a lattice mesh, comprising: receiving a registration request from a host, the registration request including a host public key and a set of asset IDs that the host wishes to claim; using a processor to sign the key to generate an RA certificate signing key using an RA certificate; updating an asset database with the RA certificate signing key; distributing the RA certificate signing key over a network; providing the host with the RA certificate signing key; A method for providing the above. [Application Example 21] 1. A computer program product for a lattice mesh, the computer program product being embodied in a tangible computer-readable storage medium; receiving a registration request from a host, said registration request including a key and a set of asset IDs that the host wishes to claim; signing the key to generate an RA certificate signing key using an RA certificate; updating an asset database with the RA certificate signing key; distributing the RA certificate signing key over the network; and providing the host with the RA certificate signing key. 20. A computer program product comprising computer instructions for:

Claims

1. 1. A system for a lattice mesh, comprising: an interface configured to receive a request from a client to join a public group; 1. A processor, comprising: Determine the group key, determining whether the client is authorized to access the public group topics; providing the group key to the client in response to the client being granted access to the topic of the public group; Publish a group message with metadata, The group message is published using the group key, the group key including group key metadata for filtering messages at client nodes, the group key metadata including multiple keys that allow exact match or prefix match for filtering published group messages; determining whether it is time to rotate the group key; determining a new group key in response to it being time to rotate the group key; determining whether another group message exists in response to determining that it is not time to rotate the group key; In response to determining that another group message does not exist, determining whether it is time to rotate the group key. and a processor configured as A system comprising:

2. 10. The system of claim 1, The system wherein the group key is determined by querying an asset database regarding authorizations initially provided by a resource authority.

3. 10. The system of claim 1, The system, wherein determining whether the client is authorized to access the topic of the public group includes querying a topic database whether the client has permission to access the topic of the public group.

4. 10. The system of claim 1, The system, wherein providing the group key to the client includes transmitting the group key to the client.

5. 10. The system of claim 1, The system, wherein the metadata includes unencrypted filtered data.

6. 10. The system of claim 1, The system, wherein the metadata includes encrypted filtered data.

7. 10. The system of claim 1, A system, wherein a key of the plurality of keys is associated with one or more of a message creator, a time stamp, a date stamp, a media type, a topic type, and a file type.

8. 10. The system of claim 1, wherein the time for rotating the group key comprises every 10 minutes N times.

9. 10. The system of claim 1, The system, wherein the time to rotate the group key comprises every N hours.

10. 10. The system of claim 1, The system, wherein the time to rotate the group key comprises every N seconds.

11. 10. The system of claim 1, The system, wherein determining the group key includes determining a key Id to use to decrypt messages and a bearer token that proves the client has access.

12. 10. The system of claim 1, The group message is encrypted using the group key.

13. 10. The system of claim 1, The group message is signed with a private key to prevent other hosts with access to the group key from forging messages.

14. 1. A method for a lattice mesh, comprising: receiving a request from a client to join a public group; determining, using a processor, a group key; determining whether the client is authorized to access the public group topics; providing the group key to the client in response to the client being granted access to the topic of the public group; publishing a group message including metadata, the group message being published using the group key, the group key including group key metadata for filtering messages at client nodes, the group key metadata including multiple keys that allow exact or prefix match for filtering the published group message; determining whether it is time to rotate the group key; determining a new group key in response to it being time to rotate the group key; determining whether another group message is present in response to determining that it is not time to rotate the group key; determining whether it is time to rotate the group key in response to determining that another group message does not exist; A method comprising:

15. A computer program for a grid mesh, comprising: The ability to receive requests from clients to join public groups, determining a group key using a processor; determining whether the client is authorized to access the public group topics; providing the group key to the client in response to the client being granted access to the topic of the public group; a function for publishing a group message including metadata, the group message being published using the group key, the group key including group key metadata for filtering messages at client nodes, the group key metadata including multiple keys that allow exact or prefix matches for filtering the published group message; determining whether it is time to rotate the group key; determining a new group key in response to the time to rotate the group key; and determining whether another group message exists in response to determining that it is not time to rotate the group key. determining whether it is time to rotate the group key in response to determining that another group message does not exist; A computer program that makes the computer realize the above.

Images