Lattice mesh

Abstract

To provide a system and method for a lattice mesh.SOLUTION: A system for a lattice mesh comprises an interface and a processor. The interface is configured to receive a request to register from a host, wherein the request to register includes a key and a set of asset IDs that the host wishes to claim. The processor is configured to sign the key to generate a resource authority (RA) certificate signed key with an RA certificate; update an asset database with the RA certificate signed key; distribute the RA certificate signed host public key through a network; and provide the host with the RA certificate signed key. In some embodiments, the system further comprises a memory that is coupled to the processor and configured to provide the processor with instructions.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] [Cross - Reference to Related Applications] This application claims priority to U.S. Provisional Patent Application No. 62 / 683,533, filed on Jun. 11, 2018, entitled "AUTONOMOUS SENSOR SYSTEM ARCHITECTURE AND INTERFACE", which is hereby incorporated by reference in its entirety.

Background Art

[0002] Networks of devices are typically considered to be secure and not vulnerable to attacks due to the failure of a given node. However, if a node is put at risk in this case, it then becomes a network security issue when it can secretly explore the data traffic passing through the node and other information stored on the node. Additionally, networks are also typically designed to provide stable communication, leading to problems where network traffic is lost or not carried.

Brief Description of the Drawings

[0003] The following detailed description and the accompanying drawings disclose various embodiments of the present invention.

[0004]

Figure 1

[0005]

Figure 2

[0006]

Figure 3A

[0007]

Figure 3B

[0008]

Figure 3C

[0009]

Figure 3D

[0010]

Figure 4

[0011]

Figure 5A

[0012]

Figure 5B

[0013]

Figure 5C

[0014]

Figure 5D

[0015]

Figure 5E

[0016]

Figure 6

[0017]

Figure 7

[0018]

Figure 8

[0019] The present invention can be implemented in various ways, including as a process, as an apparatus, as a system, as a composition of matter, as a computer program product incorporated in a computer-readable storage medium, and / or as a processor configured to execute instructions stored in and / or provided by a memory coupled to the processor, such as a processor. In this specification, these implementations, or any other form the present invention may take, may sometimes be referred to as techniques. Generally, the order of the steps of the disclosed processes may be varied within the scope of the present invention. Components such as processors or memories described as being configured to perform tasks are implemented as general components temporarily configured to perform the tasks at a given time or as special components manufactured to perform the tasks, unless otherwise specified. 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 the accompanying drawings that illustrate the principles of the invention. While the invention is described in relation to such embodiments, the invention is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the invention encompasses numerous alternative forms, modifications, and equivalent forms. To enable a thorough understanding of the present invention, numerous specific details are set forth in the following description. These details are provided for purposes of illustration, and the present invention may be practiced in accordance with the claims even if some or all of these specific details are absent. To avoid unnecessarily obscuring the present invention, technical subject matter known in the technical field related to the present invention is not described in detail.

[0021] Disclosed is a system for a lattice mesh. The system includes an interface and a processor. The interface is configured to receive a registration request from a host, and the registration request includes a key and a set of asset IDs that the host desires. The processor is configured to sign the key, generate an RA certificate signature key using a resource authority (RA) certificate, update an asset database using the RA certificate signature key, distribute an RA certificate signature host public key through a network, and provide the RA certificate signature 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 communicating within the lattice mesh. Node-to-node communication is enabled for both point-to-point mode and messages having target destinations for a public mechanism where a message can target multiple destinations. The security of the communication is designed such that when a node is put at risk, important messages cannot be retrieved from the network using the at-risk node. Further, the network prioritizes real-time data despite changes in the performance of network links. 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 a channel is available.

[0023] The lattice mesh is improved compared to other networks due to improved security. The network is designed to overcome unstable communication links and the possibility that nodes may be put at risk. The lattice mesh uses a security system that secures messages, secures routes, and secures the backfilling of messages waiting to be transmitted through the network to overcome potential problems.

[0024] FIG. 1 is a configuration diagram illustrating an embodiment of a mesh network. In the example shown, the mesh network includes a plurality of nodes (e.g., mesh node 100, mesh node 102, mesh node 104, mesh node 106, mesh node 108, mesh node 108, mesh node 110, mesh node 112, collection sink node 114, mesh node 116, etc.). Host node 118 comprises a new device or sensor or tower that requests to join the mesh network. Host node 118 discovers mesh node 116 and requests to join the network. The mesh network notifies host node 118 of the hub's address, or host node 118 has the hub's address pre-loaded. Host node 118 communicates with hub 120 and registers with the resource agency operating 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 if transmission cannot be completed. The backfill database serves as a repository for later providing data between nodes.

[0025] FIG. 2 is a configuration diagram illustrating an embodiment of a hub. In some embodiments, the hub of FIG. 2 is used to implement the hub 120 of FIG. 1. In the illustrated example, the hub 200 includes a resource authority 202. The 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. The resource authority 202 operates on the hub 200. In some embodiments, the hub 200 operates on a central cloud-based server or virtual machine. The CA 204 serves as a certificate authority for the system and responds to registration requests from new devices. The CA 204 also enables a service to authenticate a device and verify whether the device is allowed on the system's mesh network. The CA 204 can be self-signed or have a trust delegated to it from a higher-level certificate authority. The key store 206 holds the public keys of hosts allowed on the network and assigns a unique numerical host ID to the hosts. In some embodiments, the key store 206 uses a hardware security module (HSM) 214 not only to prevent key material from being exposed based on software but also to provide tamper resistance to physically compromised nodes. In some embodiments, for the RA 202, a cloud-based HSM can be used to store keys and sign new asset DBs and host certificates. The asset DB 208 stores mappings of hosts (e.g., a list of host public key → host ID → asset ID). Additionally, the asset DB 208 is used to ensure that asset IDs are unique across the entire system. In some examples, the asset DB 208 is called a host map.

[0026] In some embodiments, the asset DB 208 includes a signed monotonically increasing version number that can be used to securely determine whether to use a neighboring asset DB. For example, a host can query a neighbor to determine which version number of the neighboring asset DB is greater than the version number the neighbor has. In response to a neighbor having an asset DB with a greater version number, the host node can cause the neighbor to transfer the asset DB to itself and store the asset DB with the higher version number instead of the currently stored, lower version of the asset DB at the host node.

[0027] The mapping of the host public key → (host ID, [asset ID]) is signed by the RA 202 and is used throughout the system for naming and addressing purposes. The map 210 from the host to the requests includes the mapping between the host and the requests the host can make. The 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 can be utilized even when a wireless communication link (e.g., LTE, cellular, WiFi, etc.) to the central hub is not available.

[0028] Figure 3A is a configuration 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 example shown, the 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 networks. The mesh node 300 includes a host service 302. The host service 302 operates on the mesh node 300 using a processor and handles a routing gossip service that distributes not only the RA's asset DB but also host-signed statements regarding network reachability and service discovery information. The host service 302 also publishes and subscribes to a latency-sensitive chronological message stream (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 itself. The RA assigns a unique numerical host ID for each permitted public key. The 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 a local host or another local subnetwork) to a public / subscribe and HTTP / 2 proxy to make public / subscribe requests and perform one or more secure remote procedure calls (RPCs). The assets have an associated asset ID and a set of asset characteristics (e.g., a drone, an unattended ground sensor (UGS), a tower, etc.). Each asset characteristic corresponds to a list consisting of the provided RPC services and the created public / subscribe topic names.

[0029] FIG. 3B is a configuration diagram illustrating an embodiment of a host node. In some embodiments, host node 310 is used to implement host node 118 of FIG. 1. In the illustrated example, host node 310 is a node that is attempting to become a mesh node in addition to joining a mesh network, and may include drones, observation stations (e.g., towers), small autonomous sensors (e.g., sensors, “dust” sensors, etc.), helicopters, or any suitable number of mesh networks. Host node 310 includes host service 312. Host service 312 operates on host node 310 using a processor and handles a routing gossip service that distributes not only the RA's asset DB but also host-signed statements regarding network reachability and service discovery information. Host service 312 also publishes and subscribes to a latency-sensitive chronological message stream (including video data) from different types of assets (e.g., other mesh nodes on a mesh network, nodes on a subnetwork, etc.). Host service 312 operates a single network service and has a unique private / public key pair that identifies itself. The RA assigns a unique numerical host ID for each permitted public key. Host node 310 may operate one or more assets locally connected to host node 310, in which case host node 310 maintains a locally routable connection (e.g., via a local host or another local subnetwork) to a public / subscribe and HTTP / 2 proxy to make a public / subscribe request 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, UGS, tower, etc.). Each asset characteristic corresponds to a list consisting of the provided RPC services and the created public / subscribe topic names.

[0030] Figure 3C is a configuration diagram illustrating an embodiment of a collection sink node. In some embodiments, the 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 that is attempting to become a mesh node in addition to joining the mesh network, and may include drones, observation stations (e.g., towers), small autonomous sensors (e.g., sensors, “dust” sensors, etc.), helicopters, or any suitable number of mesh networks. The host node 310 includes a host service 312. The host service 312 operates on the host node 310 using a processor and handles a routing gossip service that distributes not only the RA's asset DB but also host-signed statements regarding network reachability and service discovery information. The host service 312 also publishes and subscribes to a latency-sensitive chronological message stream (including video data) from different types of assets (e.g., other mesh nodes on the mesh network, nodes on the subnet, etc.). The host service 312 operates a single network service and has a unique secret key / public key pair that identifies itself. The RA assigns a unique numerical host ID for each permitted public key. The host node 310 may operate one or more assets locally connected to the host node 310, in which case the host node 310 maintains a locally routable connection (e.g., via the local host or another local subnet) to the public / subscribe and HTTP / 2 proxy to make public / subscribe requests and perform one or more secure remote procedure calls (RPCs). The assets have an associated asset ID and a set of asset characteristics (e.g., drones, UGS, towers, etc.). Each asset characteristic corresponds to a list consisting of the provided RPC services and the created public / subscribe topic names.

[0031] FIG. 3D is a configuration diagram illustrating an embodiment of a host service. In some embodiments, host service 330 is used to implement host service 302 of FIG. 3A, or host service 312 of FIG. 3B, or host service 322 of FIG. 3C. In the illustrated example, host service 330 includes a registration requester 332, a key store 334, an asset database 336, and an asset database sharer 338. The registration requester 332 can generate a registration request in the mesh network in response to initially discovering one or more local mesh nodes, or in response to adding or deleting new assets associated with the node on which the host service is operating. In some embodiments, the RA public key is pre-pinned to each host, enabling the host node to identify the appropriate RA for registration. The key store 334 holds the host's private key that assigns a unique numerical host ID to each host permitted on the network. In some embodiments, the key store 334 uses a hardware security module (HSM) 340 not only to prevent key material from being exposed to danger based on software, but also to provide tamper resistance to nodes that have been physically exposed to danger. In some embodiments, a removable HSM can be attached to the host node to store and distribute the private key material and sign new host attestations. The asset DB 336 stores the mapping of the host (e.g., to a list of host public key → host ID → asset ID). Additionally, the asset DB 336 is used to ensure that the asset ID is unique across the entire system. The asset DB 336 is referred to as the host map. The mapping of host public key → (host ID, [asset ID]) is signed by the RA and used throughout the system for naming and addressing purposes. The 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 can be used even when wireless communication links to a central hub (e.g., LTE, cellular, WiFi, etc.) are unavailable.In some embodiments, the asset ID sharer 338 can determine whether a neighboring node has a version of the asset DB that is newer than the current asset DB stored as part of the host service 330.

[0032] Figure 4 is a flowchart illustrating an embodiment of the registration process. In some embodiments, the host node (e.g., host node 118 in FIG. 1) uses the process of FIG. 4 to register with a mesh network (e.g., a mesh network composed of a plurality of mesh nodes such as 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 FIG. 1). In some embodiments, to prevent an attacker from adding a spoofing device to the system, exposing a node to danger, and changing the traffic from an asset to a node exposed to danger or the direction of traffic between nodes, the host node must carefully examine the registration process when requesting to join the mesh network. In the illustrated example, at 400, a registration request regarding the mesh network is received. For example, a resource authority (e.g., of a hub node) receives a request from a host node that desires to join the mesh network. In some embodiments, the host node discovers local nodes of the mesh network that it can identify, uses one or more of the local mesh nodes, and conveys the request to join the mesh network to the appropriate resource authority. In some embodiments, the registration process involves the host performing a secure RPC to the RA using 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, i.e., for example, the host asset is removed (e.g., due to software updates, hardware updates, unplugging the asset, etc.), or the user remotely removes the asset after verifying the right to remove the asset. When there is a change in the assets associated with the host, a new asset DB is distributed. At 402, the host node public key is received.For example, when a link to a resource authority is established (e.g., in response to a request for a public key from the resource authority), the host node provides it 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 authority signs the host node public key using an RA certificate. At 406, a list of assets associated with the host node is received. For example, the resource authority requests a list of assets associated with the host node related to a request to join the mesh network or requested by that host node, or the list of assets is received along with the request to join the mesh network. At 408, the assets in the list of assets are added to the DB. For example, each of the assets in the list of assets is added to an asset DB associated with a host identifier. At 410, the asset database is distributed through the mesh network. For example, the asset database is gossiped or distributed through the network. At 412, a certificate with the host public key signed by the RA is provided to the host. For example, the certificate is then received by the host, and the host can use the certificate to connect to the mesh network using a mutually authenticated TLS (transport layer security) connection. Using both the signed public key and the host assets added to the host node and the asset database, the host node can initiate secure RPCs with other nodes in the mesh network and read messages delivered to itself. When other mesh nodes receive communication from other host nodes, they verify that the host's public key is signed by the RA, that the host is permitted on the mesh network, and that the serial number of the certificate does not exist in the revocation list in the asset database. Whenever an asset is added to a host node, the registration process is restarted. The asset, once approved, is added to the asset database associated with the host (e.g., related to the host public key or any other appropriate host identifier), and the asset database is distributed through the mesh network using a gossip or distribution protocol.

[0033] In some embodiments, the asset database (DB) includes a signed monotonically increasing version number that can be used to securely determine whether to use a neighboring asset DB. For example, a host can query a neighbor to determine which version number of the neighboring asset DB is greater than the version number the neighbor has. In response to the neighbor having an asset DB with a larger version number, the host node can cause the neighbor to transfer the asset DB to itself and store the higher version number asset DB instead of the currently stored lower version of the asset DB at the host node.

[0034] FIG. 5A is a configuration diagram illustrating an embodiment of mesh network communication. In some embodiments, the mesh nodes of FIG. 5A (e.g., mesh node A500, mesh node B502, and mesh node C504) 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 C504 sends a first RPC506 to mesh node B502 to establish communication. Mesh node C504 sends a second RPC508 to mesh node A500 to establish communication.

[0035] Figure 5B is a diagram illustrating an embodiment of a communication channel. In some embodiments, the communication channel illustrated in Figure 5B is used in the communication between mesh node C504 and mesh node B502 of Figure 5A. In the illustrated example, Transmission Control Protocol (TCP) communication is used in the communication between two mesh nodes (e.g., mesh node C → mesh node B). The communication hosts a mutually authenticated Transport Layer Security (TLS) connection. Inside the TLS connection, a stream-oriented multiplexer operates three types of streams, namely, 1) distribution or gossip / Pubsub traffic that operates a single messaging framing protocol, 2) HC2 (HTTP / 2 plaintext) for locally terminated 1-hop RPC traffic, and 3) simple packet forwarding of TLS traffic to facilitate multi-hop end-to-end encrypted RPC connections (e.g., communication from mesh node C → mesh node A). The header in the multiplexer protocol includes Quality of Service (QoS) information, and for multi-hop RPCs, the header includes routing information regarding the intended destination. The multi-hop connection is encrypted end-to-end so that intermediate nodes cannot eavesdrop on the content and each endpoint can mutually authenticate. This is achieved by the endpoint nodes establishing TLS / AES-GCM (Transport Layer Security Advanced Encryption Standard Galois Counter Mode) using the certificates provided by the RA. The certificates include RA-signed host IDs so that hosts cannot impersonate each other.To provide QoS, each host maintains a single TCP connection or a quick UDP internet connection (QUIC) to the next-hop peer of each host. The TCP connection multiplexes multiple streams over the TCP connection to enable coarse prioritization at the stream level.

[0036] FIG. 5C is a diagram illustrating an embodiment of a communication channel. In some embodiments, the mesh nodes of FIG. 5C (e.g., mesh node A510, mesh node B512, and mesh node C514) 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 C514 has a TCP connection 516 to mesh node B512. Mesh node B512 has a TCP connection 518 to mesh node A510. TLS connection 522 connects mesh node C514 and mesh node B512 for communication. TLS connection 520 connects mesh node C514 and mesh node A510 for communication.

[0037] In some embodiments, the RA distributes a bearer token in the form of a JSON web token (JWT). The bearer token is a mechanism for verifying that a client has permission to perform certain operations without the services in the system having to synchronously check with the central office. The JWT is a set of claims in JSON (JavaScript Object Notation) format that is signed using encryption with an RA certificate encoded in base64. The service can verify the claims in the JWT by using the RA certificate to check the payload signature. The claims include a resource identifier (e.g., resource / asset / abce1234) and an operation (e.g., pubsub:browse) or permission. The JWT is given by the hub during registration and must be refreshed periodically (by the hub exchanging the old JWT for a new one).

[0038] In some embodiments, the system uses a signed asset DB and host manifest to provide naming and addressing for the system. For example, 3e.host.local is mapped to host ID 3e, 5fe.asset.local is mapped to asset ID 5fe, and ptu.8b2.asset.local is mapped to the feature "ptu" operating on asset ID 8b2.

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

[0040] FIG. 5E is a diagram illustrating an embodiment of communication in a grid mesh. In the illustrated example, the communication endpoint of node 3 requests node 1, which is the communication endpoint, to desire that node 3 communicate directly between nodes. The point-to-point communication request is sent towards node 1, for example, 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 that relay the request to the final destination of the publisher node along the route. Node 1 then receives the request and determines whether node 3, which is the requesting node, is permitted to communicate (for example, query the asset DB to confirm whether node 3 is permitted to communicate with node 1, or query the RA to confirm whether node 3 is permitted to communicate with node 1, or any other appropriate authorization list or authorization mechanism). In response to being authorized, provide the host public key to the subscriber of node 3 via node 2 along the route. When receiving a data stream from the asset of node 1 (for example, a camera provides a video stream to node 1), the publisher of node 1 signs and encrypts the data stream in a message (for example, a signed and encrypted message (SEM)) using the current host public key. Note that the host public key is updated periodically (for example, not only changed at node 1 but also redistributed to other nodes or provided to nodes in response to a communication request). In some cases, the host public key is distributed via asset DB distribution. The message of node 1 is provided to the subscriber by node 2 by publishing the SEM relayed to the subscriber of node 3. Node 3 decrypts the published SEM using the host public key received when requesting to transmit and / or receive the key database.

[0041] FIG. 6 is a flowchart illustrating an embodiment of a process for publishing on a mesh network. In some embodiments, the process of FIG. 6 is used to publish messages through 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 some embodiments, in order to ensure the delivery of pub / sub (publish / subscribe) messages using multicast (i.e., the message appears only once per edge of the graph of nodes used for message delivery), it is required that the intermediate pub / sub nodes be able to decrypt messages going to other nodes, so separate streams per subscription cannot be used. To achieve this, each pub / sub message is individually decrypted using a topic group key. The group key is used to encrypt and authenticate the created message. To securely obtain the topic group key, the client pub / sub node requests one group key from the server pub / sub node via RPC. The RPC specifies the key Id used to decrypt the message and a bearer token proving that the client has access. The server then verifies the request using the RA certificate, and the client is granted access to the group key if it is allowed to access the topic. The group key must have a relatively short lifetime (on the order of tens of minutes) and must be periodically rotated to ensure that a node loses read access rights within a reasonable time by revoking the node's access rights to the topic. The group key comprises not only the shared secret provided to the AES-GCM encryption mode for encrypting the message data, but also the public key of a short-lived key pair. AES-GCM creates a "tag" that serves the role of HMAC, and the HMAC is signed by the secret key of the key pair in this case to provide non-repudiation properties, i.e., to prevent other hosts with access to the group key from forging the message.In some embodiments, requests for the pub / sub service use the resource identifier "resource / asset / ${assetId}" and the permission "permission / pubsub / view".

[0042] In the illustrated example, at 600, a request to join a public group from a client is received. For example, a generation node receives a request to join a public group regarding a topic from a client or a mesh node. At 602, a group key is determined. For example, the group key is determined by querying the asset DB regarding the authorization first provided by the RA. At 604, it is determined whether the client is permitted access to the topic of the group. For example, the RA queries the database as to whether the client or mesh node has permission or access rights to a given topic related to the public group. In response to the client not being permitted access to the topic of the group, the process ends. In response to the client being permitted access to the topic of the group, at 606, the group key is provided to the client. For example, the group key is provided to the client, or to the mesh node to be transmitted to the client. At 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 the message at the client or the mesh node. At 610, it is determined whether it is time to rotate the token. For example, the token should be rotated frequently to allow for a reasonable time response to revocation of access privileges (e.g., within tens of minutes, in time, in seconds, or to conform to the network and network usage). In response to the determination that it is time to rotate the token, control is passed to 602. In response to the determination that it is not time to rotate the token, at 612, it is determined whether there is another group message. In response to there being another group message, control is passed to 608. In response to there not being another group message, control is passed to 610.

[0043] In some embodiments, the pub / sub request is at the asset level, enabling the bearer to read all the topics created by the asset.

[0044] In some embodiments, an asset may wish to subscribe to a subset of the messages obtained 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 starting to subscribe, 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 against the keys. Using this framework, basic geofiltering using geo-hashes is possible. The metadata associated with a message can include a unique key (e.g., a key related to the creator of the message, a key related to a time / date stamp, etc.), a media type (e.g., protobuf (Protocol Buffer), blob (Binary Large Object), file type, e.g., video file (MPEG (Moving Picture Experts Group), MP4 (MPEG-4), etc.), text file, image file, pdf file, etc.), and / or a timestamp. For messages based on images, the pub / sub message should be able to encode the image as a chunked MPEG stream for efficient transfer and storage.

[0045] In some embodiments, each host creates a signed attestation list consisting of assets (signed by the RA and the host) and properties (signed only by the host). The properties are strings that describe the RPC service and the grouping of the created topics. In the host attestation list, the host can also include a list of string metadata tags that can be used for discovery by the rest of the system. When publishing a message, the asset includes not only the topic name but also a list of metadata tags for each message. The topic metadata tags can include information useful for filtering. Intermediate nodes involved in multiple join routings can combine replicated joins 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 metadata.

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

[0047] In some embodiments, the pub / sub service stores data so that it can answer historical queries (e.g., start streaming or publishing from a past time). 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., in a fixed storage device such as a hard drive).

[0048] Figure 7 is a flowchart illustrating an embodiment of a process for receiving messages. In some embodiments, the process of Figure 7 is used to receive private messages or published group messages. 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 from a client or a point-to-point communication link to an asset database is provided to the asset database. At 702, a group key or a 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 a message has not been received, control passes to 704. In response to a determination that a message has been received, at 705, it is determined whether to continue transmitting the message. In response to a determination that the message should be continued to be transmitted, at 712, the message is continued to be transmitted, and at 714, it is determined whether the message is addressed to the host. In response to the message being addressed to the host, control passes to 706. In response to the message not being addressed to the host, control passes to 708. In response to a determination that the message should not be continued to be transmitted, control passes 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, the message is stored in the backfill database. In some embodiments, the node does not have a backfill database, and after decrypting the message, control passes 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 passes to 704. In response to a determination not to store in the backfill database, control passes to 704. In the case of a normal node, the group key or the host public key is stored in memory, and when the fixed storage device is exposed to danger, the group key or the host public key is not stored in the fixed storage device so that the encrypted message cannot be decrypted using the stored key.In some cases, the node includes a data sink. The data sink is selected because it is considered to be secure.

[0049] FIG. 8 is a flowchart illustrating an embodiment of a process for transmitting a message. In some embodiments, the process of FIG. 8 is used to transmit a private message or a published 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 a host public key is received. For example, a group key or a host public key is received from an asset database. At 804, it is determined whether a message to be transmitted is available. In response to a determination that a message to be transmitted is not available, control passes to 804. In response to a determination that a message to be transmitted is available, at 806, the message is encrypted using the group key or the 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 a message and is periodically alternated. The host public key is an asymmetric key stored on a hardware security module and is never alternated (a given host is assigned a single host public key at manufacturing time). The host public key is used to sign messages issued by the host so that other nodes that can access the group key (when other nodes want to read the message) cannot forge the message. At 808, the message is transmitted and control passes to 804. For example, the message is sent to a destination along a routing route or is published to a network. Note that only the generating node can publish to a public group.

[0050] In some embodiments, the system is designed to provide security such that when a single node is exposed to danger, an attacker cannot access other components. In some embodiments, the system prevents a node from reading messages / RPCs destined for other nodes that are being routed through the node. In some embodiments, the system prevents a node from being able to modify messages / RPCs destined for other nodes that are being routed through another node in a way that makes them undetectable. In some embodiments, the system prevents a node from being able to change the direction of messages / RPCs destined for other nodes (i.e., affect the entries in the routing table) to any given node.

[0051] In some embodiments, the system allows a node to reject services for any message / RPC passing 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 destined for the node. In some embodiments, the system allows a node to send messages that impersonate other nodes. In some embodiments, the system allows a node to join messages that the node can see. In some embodiments, the system allows a node to examine in detail the destinations of all messages / PCs passing through the node.

[0052] In some embodiments, the keys use Elliptic Curve Digital Signature Algorithm (ECDSA) on the National Institute of Standard 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, in which case the pinned key can only be changed by physically accessing the host. In some embodiments, each host is assigned a hardware-based key pair at manufacture that cannot be changed unless hardware modifications are made. A host is identified using its public key, also known as the host identifier of the public key.

[0054] In some embodiments, the RA maintains a centralized list of host IDs of authorized members. This list is updated through the registration process and distributed across the network. If a host becomes compromised (e.g., receives an indication that the host has been put at risk), the RA can revoke the active certificates issued from that host. Until the certificate expires, the serial number of the revoked certificate is included in the signed host list. Each host advertises a statement regarding other hosts that the host can reach at the same time as the expiration. The statement is signed with the host's private key. An edge with one signed statement is called a "candidate edge". An edge with two mutual statements is called a "routable edge". Only routable edges are active within the network.

[0055] In some embodiments, the architecture is designed to limit the damage that a compromised node can cause. For example, a compromised node may be able to generate as many candidate edges as possible. However, if other proper hosts cannot reach the compromised node, the proper hosts do not generate statements regarding the candidate edges of the compromised node, and no routable edges are generated at all. Thus, a compromised node is limited to generating edges with proper nodes that the node can reach.

[0056] In some embodiments, routes within the lattice 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 be signed. Once established, the link is locally stored in the routing table. The damage to the routing table that a malicious node can cause is limited to the nodes that the malicious node can actually reach directly. The idea is that a malicious node cannot advertise, for example, that it is directly connected to every node in the network, in which case it cannot discard all packets and, as a result, disrupt the network. Note that when a node is at risk, an attacker may still put at risk the applications running on the node. However, these attacks may be protected against using best practices of standard operating systems (such as ensuring that applications run as users following the principle of least privilege).

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

[0058] In some embodiments, backfill is used to refer to the process of locally recording data on a node so that historical data becomes available. This historical data is moved around the network so that the historical data becomes locally accessible to other nodes. It is desirable for backfill to have no or little impact on the pub / sub system. Persistent data is prioritized in the system, and backfill operates using the bandwidth remaining after handling all persistent pub / sub subscriptions. Data for a node that has been moved to another node is stored at the node in case the node is put at risk. If node B is given access rights to node A and stores encrypted data on disk, the key used by node B to decrypt data from A is time-limited. The key is stored in memory (e.g., not in a non-volatile storage area). This ensures that if an attacker puts node B at risk, the attacker can only view the time-limited window of historical data. A pub / sub multicast delivery mechanism is used to deliver backfilled data. If multiple nodes are interested in 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, and since the data has already been transmitted for persistent pub / sub, there is no need to retransmit the data for backfill. Historical data stored on a device cannot be read by an attacker who controls any given node.

[0059] In some embodiments, the dispatch server uses backfilling to recover data from nodes that occurred during a period of poor or no network connectivity so that the data is ultimately available to the user. In some embodiments, one or more dispatch servers operate on the network, and some of the dispatch servers are introduced towards the edge of the network and may be at risk of being put at risk.

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

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

[0062] In some embodiments, the RA defines a set of "collection sinks", which are hosts within the network that need access to backfill data. The RA assigns each node a set of collection sinks within a HostList (host list) that the RA signs. All nodes store the past group keys encrypted at rest using the collection sink public key assigned to them, using PGP or a similar framework where each collection sink is the recipient. In this case, the PGP-encrypted group keys become available through the backfill service to all nodes.

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

[0064] In some embodiments, the historical data stored on the captured device is not accessible to an attacker without further exposing the collection sink assigned to the device to danger. The attacker can still read the current group key from the RAM, but since the group key was recently rotated, the attacker is restricted from viewing the data produced. In some embodiments, the original device does not need to be accessible to access the backfilled data, only access to one of the collection sink's secret keys is required. This is because intermediate nodes can cache not only the encrypted group key but also the encrypted messages. In some embodiments, the collection sink must be pre-specified, which means that when the collection sink is added, the creator node did not include the collection sink in its PGP recipient list, so the data cannot be backfilled. In some embodiments, the RA needs to be able to always keep track of the status of the collection sink, assign a collection sink to a host, and maintain the key pair regarding the collection sink.

[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.

Claims

1. A system comprising: An interface, Serves a request to join a mesh network messaging group, Receive a group key or host public key an interface configured as follows: one or more processors, Determine if the message was received, responsive to the message being received, determining whether the message should be sent; in response to determining that the message should not be sent, decrypting the message using the group key or the host public key; determining whether to store the message in a backfill database; storing the message in the backfill database in response to a determination to store the message in the backfill database; one or more processors configured to A system comprising:

2. A system according to claim 1, The one or more processors are further configured to, in response to determining not to store the message in the backfill database, determine whether a new message has been received.

3. A system according to claim 1, The group key is received from an asset database.

4. A system according to claim 1, The one or more processors are further configured to determine whether a new message has been received in response to determining that the message has not been received.

5. A system according to claim 1, The one or more processors are further configured to transmit the message in response to determining that the message should be transmitted.

6. A system according to claim 5, The one or more processors are further configured to determine whether the message is destined for a host.

7. The system according to claim 6, the one or more processors are further configured to, in response to determining that the message is destined for the host, decrypt the message using the group key or the host public key.

8. A method comprising: Providing a request to join a mesh network messaging group; receiving a group key or a host public key; determining whether the message was received; and In response to the message being received, determining whether the message should be sent; in response to determining that the message should not be sent, decrypting the message using the group key or the host public key; determining whether to store the message in a backfill database; storing the message in the backfill database in response to a determination to store the message in the backfill database; A method comprising:

9. The method of claim 8, further comprising: In response to determining not to store the message in the backfill database, the method includes determining whether a new message has been received.

10. The method of claim 8, The method wherein the group key is received from an asset database.

11. The method of claim 8, further comprising: In response to determining that the message has not been received, the method includes determining whether a new message has been received.

12. The method of claim 8, further comprising: In response to determining that the message should be sent, sending the message.

13. The method of claim 12, further comprising: determining whether the message is destined for a host.

14. The method of claim 13, further comprising: In response to determining that the message is destined for the host, decrypting the message using the group key or the host public key.

15. One or more computer-readable storage media configured to store program instructions, comprising: The program instructions are executable by one or more processors, and cause the one or more processors to: Submit a request to join a mesh network messaging group, Receive a group key or host public key, Determine if the message was received, In response to the message being received, determining whether the message should be transmitted; decrypting the message using the group key or the host public key in response to determining that the message should not be sent; causing a backfill database to determine whether the message should be stored; in response to determining to store the message in the backfill database, causing the message to be stored in the backfill database; One or more computer-readable storage media.

16. One or more computer-readable storage media according to claim 15, The one or more computer-readable storage media, wherein the program instructions further cause the one or more processors to determine whether a new message has been received in response to determining not to store the message in the backfill database.

17. One or more computer-readable storage media according to claim 15, One or more computer-readable storage media, wherein the group key is received from an asset database.

18. One or more computer-readable storage media according to claim 15, One or more computer-readable storage media wherein the program instructions further cause the one or more processors to transmit the message in response to determining that the message should be transmitted.

19. One or more computer-readable storage media according to claim 15, One or more computer-readable storage media, wherein the program instructions further cause the one or more processors to determine whether the message is destined for a host.

20. One or more computer-readable storage media according to claim 19, The program instructions further cause the one or more processors to decrypt the message using the group key or the host public key in response to determining that the message is destined for the host.

Images