External Symmetric Encryption Key Transfer for Seat Belt

Abstract

The trusted node in the network performs the transfer of the symmetric encryption key outside the safety belt to the user device. The first trusted node receives a request from the first user device to transfer the symmetric encryption key to the first user device and the second user device that are a pair of user devices. The first trusted node transfers the second symmetric encryption key to the second user device via the trusted node. The first trusted node receives the confirmation of the transfer of the second symmetric encryption key. In response to the confirmation of the transfer, the first trusted node transfers the first symmetric encryption key to the first user device.

Description

Technical Field

[0001] This embodiment relates to the field of cryptographic communication systems and cryptographic communication in a network. Background Art

[0002] Encryption and decryption are commonly used for cryptographic communication over various networks. Typical encrypted communication uses symmetric keys to encrypt and decrypt data between two points. These keys are typically derived from a Diffie-Hellman negotiation when starting to exchange data using the same link. With sufficient computing power, eavesdropping on a data link would allow an attacker to deduce the symmetric key from the exchange. So far, this danger has been limited to theory, but the emergence of quantum computers has made this brute-force attack vulnerability a reality.

[0003] QKD (Quantum Key Distribution) systems are currently being developed to provide both parties with symmetric keys with strong physical guarantees against eavesdropping. The practical use of QKD systems is currently limited by distance limitations and the fact that they can only operate as a pair of devices (Alice / Bob) and cannot extend the network to multiple pairs of Alice / Bob. Summary of the Invention

[0004] Disclosed is a method for out-of-band symmetric encryption key transfer for seat belts. A first trusted node in a network receives a request. The request comes from a first user device in a pair of user devices. The request is to transfer a symmetric encryption key to the pair of user devices. The first trusted node transfers a second symmetric encryption key in the symmetric encryption key to a second user device in the pair of user devices. The symmetric encryption key is transferred via other trusted nodes in the network. The first trusted node receives an acknowledgment from one of the other trusted nodes in the network. The acknowledgment is that the second symmetric encryption key in the symmetric encryption key has been transferred to the second user device in the pair of user devices. The first trusted node transfers a first symmetric encryption key in the symmetric encryption key to the first user device in the pair of user devices. The transfer is in response to the acknowledgment that the second symmetric encryption key in the symmetric encryption key has been transferred to the second user device in the pair of user devices.

[0005] A tangible non - transitory computer - readable medium is disclosed. Instructions are on the medium, which when run by a processor cause the processor to execute a method. A first trusted node in a network receives a request from a first user device. The request is to transfer a symmetric encryption key to the first user device and a second user device. A second symmetric encryption key is transferred from the first trusted node to the second user device. The key is transferred via trusted nodes in the network. At the first node, an acknowledgement is received from one of the trusted nodes in the network. This is an acknowledgement of transferring the second symmetric encryption key to the second user device. A first symmetric encryption key is transferred from the first trusted node in the network. The first symmetric encryption key and the second symmetric encryption key are symmetric to each other. In response to the acknowledgement of transferring the second symmetric encryption key to the second user device, the first symmetric encryption key is transferred to the first user device.

[0006] An apparatus for out - of - band symmetric encryption key transfer is disclosed. The apparatus has a plurality of nodes of a network for forming trusted nodes in a peer - to - peer or mesh network. A first trusted node, being one of the trusted nodes, receives a request from a first user device to transfer a symmetric encryption key to the first user device and a second user device. The first trusted node transfers a second symmetric encryption key to the second user device. The key is transferred from the first trusted node via the trusted nodes. The first trusted node receives an acknowledgement of transferring the second symmetric encryption key to the second user device. The acknowledgement is received from one of the trusted nodes. The first trusted node transfers a first symmetric key to the first user device. The first symmetric key is symmetric with the second symmetric encryption key. The transfer is in response to the acknowledgement of transferring the second symmetric encryption key to the second user device.

[0007] In conjunction with the accompanying drawings, other aspects and advantages of the embodiments will become apparent from the following detailed description, which illustrates by way of example the principles of the described embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In conjunction with the accompanying drawings, the described embodiments and their advantages can be best understood by reference to the following description. Without departing from the spirit and scope of the described embodiments, these drawings in no way limit any changes in form and detail that those skilled in the art can make to the described embodiments.

[0009] Figure 1 A system for out - of - band transfer of cryptographic keys according to the present embodiment is depicted. TX1 to TX7 represent TrustedXchange Nodes (TX nodes). U1 to U4 represent users of the system. A system that can provide additional encryption keys is also described, similar but not limited to QKD Alice / Bob pairs.

[0010] Figure 2The TX node information collection loop (“chat with neighbors”) is depicted from the perspective of node TX1 and is applicable to Figure 1 an embodiment of a network of TX nodes.

[0011] Figure 3 Depicts the out-of-band encryption key (“Parcel”) transfer in a mesh of TX nodes according to this embodiment.

[0012] Figure 4 Depicts an embodiment of a path calculation process that is applicable to Figure 1 an embodiment of an out-of-band symmetric key transfer system and Figure 3 the embodiment of parcel transfer depicted in DETAILED DESCRIPTION

[0013] Importantly, there is an additional key pair that is transferred outside of the channel used for data exchange. Separating the data and key transfer channels makes a brute force quantum computer attack nearly impossible. Combining the keys transferred inline by traditional methods with the out-of-band keys using the systems and methods described herein allows for a low-profile deployment on existing networks while significantly increasing the resistance of the encryption channel to attacks.

[0014] Various embodiments of the systems disclosed herein eliminate restrictions on distance and network expansion, operate with or without a QKD system, and introduce a self-organizing mesh network with Trusted Xchange Nodes (i.e., trusted exchange nodes or TX nodes) with adaptive routing and fault tolerance, which can also benefit from additional in-transit key encryption from available QKD Alice / Bob pairs.

[0015] A cryptographic communication system with key transfer implemented on various networks including mesh networks and point-to-point networks is described herein. The TX nodes in the network are connected via TLS (Transport Layer Security) with strong encryption and mutual authentication, which is client verification of the server and server verification of the client, where the client and server are defined according to TLS communication.

[0016] TX nodes communicate and cooperate to discover neighbors, generate keys according to user requests, pass the key(s) to the requested TX node(s), confirm the delivery of the key(s), find the best delivery route, and find another route and repeat the process if one of the adjacent TX nodes is inaccessible. In embodiments with features that can be separated, varied, or combined differently, the key is an encryption symmetric key (or symmetric encryption key), the network is a mesh network or a point-to-point network, and / or the key can be additionally encrypted by an external key in each hop-to-hop transmission. The external key can be generated by the connected QKD Alice / Bob pair in one or more network hops or all network hops (e.g., each symmetric key being passed is wrapped by an external key on that particular hop). Some embodiments perform out-of-band symmetric key delivery in combination with point-to-point communication. Some embodiments perform path optimization according to various criteria, such as minimizing hops, or the availability of external keys, or the availability of external QKD keys. Adjacent nodes in the network can establish trust and become trusted nodes in a mesh network or a point-to-point network through one or more mechanisms, including one-way or two-way exchanges or verifying certificates or tokens. Other mechanisms or protocols for establishing trust, constructing a mesh network or a point-to-point network, and pre-configuring nodes to trust each other can be easily designed in accordance with the teachings herein.

[0017] Figure 1 A system for out-of-band delivery of cryptographic keys according to this embodiment is depicted. TX1 through TX7 represent TrustedXchange Nodes (i.e., trusted exchange nodes or TX nodes 106, 108, 110, 112, 114, 116, 118), and U1 through U4 represent users of the corresponding user devices 102, 120, 104, 122 of the system. Two user devices use the encryption keys received through out-of-band delivery to perform in-band cryptographic (i.e., encrypting, decrypting) communication with each other. A system that can provide additional encryption keys is also described, similar but not limited to QKD Alice / Bob pairs. The point-to-point or mesh network includes Figure 1TX nodes 106, 108, 110, 112, 114, 116, 118 shown separately in the figure, and these nodes communicate with their neighbors in a point-to-point mode. This communication is encrypted by TLS with both client-server and server-client certificate verification. TX nodes only communicate with neighbors configured by the system administrator and belonging to the same certificate authority. Generally speaking, more than two TX nodes are involved, and they can create a mesh network. Some TX nodes 108, 110, 112, 114 may not have user devices attached to them and only act as transit nodes for forwarding or routing, for example. The important function is that the system as a whole can achieve fault tolerance and allows secondary encryption to be performed using external keys from a limited range of QKD Alice / Bob pairs. The point-to-point or mesh network, and more specifically, the TX nodes 106, 108, 110, 112, 114, 116, 118 in the network, perform the process of passing cryptographic keys between any given pair of user devices 102, 120, 104, 122 connected to the network. In various embodiments, processors running software, firmware, hardware, and various combinations thereof can perform various actions of this process and other processes. In various embodiments, the connections in the point-to-point or mesh network can be one-to-one (e.g., end TX nodes), many-to-one, or many-to-many.

[0018] TX nodes 106, 108, 110, 112, 114, 116, 118 communicate with their pre-configured neighbors periodically, extracting information about the neighbors' neighbors and all connected user devices. Thus, in the case of a mesh setup, each TX node 106, 108, 110, 112, 114, 116, 118 maintains a near-real-time map of all nodes and all active user devices in the mesh, while only requesting information from the allowed neighbors. If a new TX node / user device is added / removed by the system administrator or some nodes become inaccessible, the map changes automatically.

[0019] In one case, one of the user devices 102, for example U1, requests one or more keys. U1 also specifies another user device 104, for example U3, that should receive the same one or more keys. The request for the key is sent to the TX node 106 to which the user device 102 is connected, which is TX1 in this example. The key request is executed according to mutually agreed-upon specifications and can include TLS encryption and certificate verification, and can be executed via, for example, a REST API (Representational State Transfer Application Programming Interface). As another variant, it can be executed via serial communication in a format agreed upon by the user device and the TX node.

[0020] Upon receiving a request, the TX node 106 (TX1 in this example) generates the requested key(s) and prepares to pass it to U3 first before returning the key to the requesting user device 102 (U1). TX1 looks up the name of the TX node 116 to which U3 is connected, which is TX6 in this example. TX1 only allows communication with its preconfigured neighbors, and in this case, the TX nodes 108 TX2 and 112 TX4 calculate the next hop based on their current node mapping. In this example, the TX node 106 TX1 will discover several paths of equal length - that is, TX2 and TX4 will have the same weight. In other examples, the paths can have different weights. In this example, if the previous key transfer transaction was executed via TX2, TX1 will perform a load balancing operation and send the generated key to TX4, and vice versa. The internal data block is called a packet and has a destination TX node label attached to it. After receiving the packet from TX1, TX4 will perform a similar calculation of the next hop and find that TX4 only has one alternative - that is, the TX node 114 TX5. The operation of optimal path calculation and potential load balancing is performed for each transitional TX node (hop) until the packet reaches its destination TX node 116 (TX6 in this example). Each TX node in the chain keeps the connection to the previous peer open during this transaction, so any potential errors are immediately returned within the context of this transaction. Upon successfully delivering the packet with the key to TX6, TX1 returns a success code and closes the connection. Each previous TX node performs the same operation until the success code reaches the originator (TX1 in this example). Upon receiving the success code, TX1 finally returns the requested key(s) to the U1 user device 102. With the key(s) successfully delivered to TX6, U3 can now request the key(s) after the key(s) are erased from TX6. After the time of the packet transfer transaction has elapsed, the transferred key is not stored in the transitional TX nodes.

[0021] The system can be configured such that TX nodes supplied with additional encryption keys receive path priority, for example, by assigning a greater weight to such paths. In the case of additional keys, for example, from a QKD Alice / Bob pair, the TX nodes use these keys on both sides of that particular hop to additionally encrypt / decrypt the packet. In various embodiments, such quantum key encryption and decryption can occur at one hop, two or more hops, or at each and every hop of the packet along the path.

[0022] In various embodiments, a TX node that generates a key based on a transfer request can obtain key material from a preconfigured RNG (random number generator) system including, but not limited to, a QKD system or a dedicated QRNG (quantum random number generator), from an internal hardware RNG, or from a standard software entropy-based RNG, or generate a key.

[0023] Figure 2 An embodiment of an information collection loop (“communicating with peers”) is depicted from the perspective of TX node 106TX1. Each node 106, 108, 110 in the network must have a unique name. In this example, node TX1 is preconfigured by a system administrator such that TX1 is allowed to communicate with nodes TX2 and TX3. The exchange is implemented via a REST API over TLS with both client-server and server-client certificate verification. TX1 in this example runs an independent “communicate” thread for each peer node it is configured to communicate with. TX1 initiates a REST “EST interval communicate” request to TX2 and TX3 at a preset interval T. Each TX node generates a one-time UUID (universally unique identifier) that persists for the duration of the TX node process and is replaced when the process restarts. There is no long-term storage for this UUID. This UUID is supplied along with the TX node name side to each response to the “communicate” request. In this example, TX1 receives information from each of its peers, which is structured as an array of ([TX name, TX UUID] -> array(peer names), array(user device names)), but other ways of organizing and recording this information can be readily designed in accordance with the teachings herein. TX1 then creates a memory structure for looking up where the user devices are located and which TX nodes know which peers. TX1 also checks for changes to the UUID associated with the TX name and replaces the appropriate lookup slot when the UUID has changed. If TX1 does not find that specific UUID in the response within T×2 time, TX1 also marks the TX name / UUID pair as “stale”. The absence of this UUID for more than T×2 time indicates that the TX node under consideration is inaccessible and must be avoided during path calculation. In Figure 2In the example, all other nodes perform similar REST "communication" requests with each other, thus building a total picture of the TX node network while communicating only with the allowed peers. Since the TX nodes are opposite to each other, each TX node 106, 108, 110 retains its own copy of the collective memory. If the UUID / TX name pair is not found within the T×11 time frame, the TX node under consideration will be completely removed from the picture. Otherwise, it has the opportunity to be marked as an operating node again. It is easy to design various other time frames or tests for removing nodes from the network and / or restoring them to the network according to the teachings herein.

[0024] The runtime UUID refresh method is chosen for various embodiments because it does not rely on the concept of global time that additionally needs to be maintained on the TX node network. Each TX node 106, 108, 110 only relies on its own clock to calculate the "expiration" timeout, and each TX node clock can deviate significantly without affecting interoperability and the collective memory. In some embodiments, no timestamps are exchanged in the "conversation" requests / responses.

[0025] The GET method of the REST API is chosen as the most secure, so even if an "imposter" TX node somehow passes the certificate verification, the "imposter" TX node cannot inject incorrect information into the collective memory by only pushing incorrect information.

[0026] Therefore, path finding enables a TX node to receive a package with a key for delivery and find the next best peer TX node to give the package to the TX node created in the memory based on the current TX node network picture.

[0027] In some versions, there is no permanent storage of network memory on any TX node.

[0028] The approximate time for a reconfigured TX node to propagate on the network is bracketed between T×L and T×L×2, where L is the chain length from TX1 (as in Figure 2 the example) to the TX node under consideration. Therefore, the propagation time in the network is linearly related to the length of the TX node chain.

[0029] On the other hand, since the next-hop calculation occurs immediately on the current TX node that retains the package with the key and needs to find the next hop, regardless of the other nodes' knowledge of the current state of the network, the time to mark a node (i.e., a TX node) as "failed" is not important. Relative to this node, this time is constant and is bracketed between T and T×2.

[0030] Figure 3Depicts out-of-band encryption key ("package") delivery in the mesh of TX nodes 106, 108, 110, 112, 114, 116 according to this embodiment. The example also covers the rare case where the TX node 116TX6 has recently had a problem (or become unavailable) and thus information about the failure has not been propagated through the above-mentioned mesh "communication".

[0031] According to Figure 3 the example in, the TX node mesh is configured as follows: TX1 communicates with TX4; TX4 communicates with TX1 and TX5; TX5 communicates with TX2 and TX6; TX2 communicates with TX5 and TX3; TX3 communicates with TX2 and TX6; TX6 communicates with TX5 and TX3.

[0032] The user device 102U1 requests an encryption key from the TX node 106TX1 and also specifies its corresponding user device 120U2, which should receive the same key(s). U1 then waits for a response. TX1 generates the requested key(s) and generates a package. TX1 looks up in TX1's current node mapping the TX node 110 to which U2 is connected. This TX node 110 happens to be TX3. Thus, the package is formed with the final destination specified as TX3. As step 1, TX1 then sends the package to its only peer TX4 and waits for a response. In step 2, TX4 sends the package to TX5 in exactly the same way and waits for a response.

[0033] TX4 and TX5 also happen to receive additional symmetric encryption keys from external devices - for example, quantum keys from a QKD Alice / Bob pair. Thus, in addition to the TLS layer for communication, the package itself is encrypted using this quantum key.

[0034] TX5 normally learns that its peer TX6 has a problem by performing communication within a time interval T, but in this very rare case, TX6 has difficulties or becomes unavailable within the time frame bracketed by 0 and T. Thus TX5 still considers its peer TX6 to be operational and has equal path load balancing opportunities between TX2 and TX6. If TX6 is ultimately selected as the next hop, then in step 3, TX5 sends the package to TX6. An error response 302 (or timeout) occurs (response arrow), and then in step 4, TX5 sends the package to its other peer TX2 and waits for a response. In step 5, TX2 sends the package to TX3 and waits for a response.

[0035] TX3 discovers that the package destination matches its name and performs operations according to the method, for example, through an application programming interface (API) for (one or more) user device key transfer. The package is deleted immediately after the (one or more) keys are retrieved by the user device 120U2.

[0036] TX3 then returns a successful response 304 (response arrow) to TX2 and closes the transaction. TX2 returns a successful response 306 to TX5 and closes the transaction. TX5 returns a successful response 308 to TX4 and closes the transaction. TX4 returns a successful response 310 to TX1 and closes the transaction. TX1 gives the (one or more) keys to the waiting user device 102U1 according to the method for (one or more) user device key transfer (e.g., through the API) and closes the transaction.

[0037] A typical transfer will involve TX5 learning about the TX6 problem from the communication and marking TX6 as invalid. This learning also propagates across all nodes of the mesh via the communication as described above. In this typical case, the package transfer path will consist of steps 1, 2, 4, and 5 - completely avoiding step 3.

[0038] Package transfer is implemented using the REST method "Method T" with steps. The package is never stored in an HDD (hard disk drive) or other storage memory while on its way to the user device and is deleted from the memory immediately after being retrieved by the user device.

[0039] Typically, the user device and its associated TX node perform both client / server and server / client certificate verification and / or connect via other highly secure links, which can be implemented via, for example, a serial interface.

[0040] Figure 4 An embodiment of the path calculation process is depicted, which is applicable to Figure 1 an embodiment of an out-of-band symmetric key transfer system and Figure 3 the embodiment of package transfer depicted in Figure 4 In the example of

[0041] TX1 creates an instant mapping using step 1, which consists of all possible destinations, the peers of TX1 accessible through these destinations, and the number of hops required to transfer to a specific destination via a specific peer. Failed TX nodes are excluded from the mapping.

[0042] TX1 then uses step 2 to filter out all irrelevant records, so only TX6 remains as the destination. In Figure 4 the example of Figure 4 , it generates 2 records with equal hop counts. So TX1 switches to the load balancing mode and alternately sends the packages to TX2 and TX4 in a round-robin manner.

[0043] As the original mapping obtained from the communication changes, the instant hop mapping that is newly generated each time a package is delivered also changes. As an example, when TX2 receives a package destined for TX6, TX2 performs the same calculation, which obtains all the nodes and its copy of the current mapping of its peer nodes obtained via the communication, and converts the mapping into all possible destination mappings with hop counts (now just relative to TX node 108TX2 (itself)), and then filters it out by the destination TX6. This will generate the TX6->TX3->2 and TX6->TX5->2 alternatives, which again trigger the load balancing round-robin between TX3 and TX5. One alternative will be selected, and the next same step will result in delivering the package to TX node 116TX6.

[0044] Based on the latest information obtained from the communication as described above, at each package delivery, the path calculation occurs independently on each TX node 106, 108, 110, 112, 114, 116, 118.

[0045] The above embodiments, examples, and scenarios can be generalized to further embodiments, in which a request to pass a symmetric encryption key to a user device is received at a TX node that is not directly connected to the user device but communicates with the (one or more) user devices through other (one or more) TX nodes. The TX node that receives the request for the symmetric encryption key from the user device passes one of the symmetric encryption keys to another specified user device, receives the confirmation of the delivery, and then passes the other symmetric encryption key to the user device that requested the key, all through the TX nodes.

[0046] The foregoing description refers to specific exemplary embodiments. However, it is obvious that various modifications and changes can be made to it without departing from the broader spirit and scope. Therefore, the specification and the drawings are considered to be illustrative rather than restrictive.

Claims

1. A method for out-of-band symmetric encryption key transfer for seat belts, comprising: At a first trusted node in a network, receiving a request from a first user device in a user device pair to transfer a symmetric encryption key to the user device pair, translating, by the first trusted node, the request into an instruction for generating the symmetric encryption key in response to receiving the request, transferring, in response to receiving the request, one of the symmetric encryption keys to a second user device in the user device pair, confirming the transfer of one of the symmetric encryption keys to the second user device in the user device pair, and transferring the other of the symmetric encryption keys to the first user device in the user device pair after confirming the transfer in response to receiving the request; At the first trusted node, generating a first symmetric encryption key and a second symmetric encryption key in the symmetric encryption keys in response to receiving the request, wherein, since the generation precedes the transfer, neither the first user device nor the second user device in the user device pair has one of the symmetric encryption keys; Via a trusted node in the network, transferring the second symmetric encryption key in the symmetric encryption keys from the first trusted node to the second user device in the user device pair in response to receiving the request; At the first trusted node, receiving, from one of the trusted nodes in the network, a confirmation of transferring the second symmetric encryption key in the symmetric encryption keys to the second user device in the user device pair in response to receiving the request at the first trusted node; and In response to a confirmation of transferring the second symmetric encryption key in the symmetric encryption keys to the second user device in the user device pair in response to receiving the request at the first trusted node, transferring the first symmetric encryption key in the symmetric encryption keys from the first trusted node in the network to the first user device in the user device pair.

2. The method according to claim 1, wherein the first symmetric encryption key and the second symmetric encryption key in the symmetric encryption keys are guaranteed by the trusted node to be transferred only to the first user device and the second user device in the user device pair.

3. The method according to claim 1, wherein transferring the second symmetric encryption key in the symmetric encryption keys includes transferring the second symmetric encryption key in the symmetric encryption keys between nodes preconfigured to trust each other as trusted nodes via the network.

4. The method according to claim 1, wherein the trusted nodes in the network include nodes in a peer-to-peer or mesh network, and the peer-to-peer or mesh network is each in a one-to-one, one-to-many or many-to-many configuration.

5. The method according to claim 1, further comprising: Performing an instant optimal path search during the transfer of the first symmetric encryption key and the second symmetric encryption key of the symmetric encryption key.

6. The method according to claim 1, further comprising: Perform immediate load balancing during the transfer of the second symmetric encryption key of the symmetric encryption key.

7. The method according to claim 1, further comprising: Generate a quantum key and transfer the quantum key to each of two or more trusted nodes in the network.

8. The method according to claim 1, further comprising: During the transfer of the first symmetric encryption key and the second symmetric encryption key of the symmetric encryption key, encrypt each of one or more node-to-node transmissions using the quantum key.

9. The method according to claim 1, further comprising: Perform immediate optimal path finding based on the availability of the quantum key during the transfer of the first symmetric encryption key and the second symmetric encryption key of the symmetric encryption key.

10. A tangible non-transitory computer-readable medium having instructions thereon that, when run by a processor, cause the processor to perform a method, the method comprising: At a first trusted node in a network, receive a request from a first user device to transfer a symmetric encryption key to the first user device and a second user device, translate the request by the first trusted node into an instruction for generating the symmetric encryption key in response to receiving the request, transfer one of the symmetric encryption keys to the second user device in response to receiving the request, confirm the transfer of one of the symmetric encryption keys to the second user device, and transfer the other of the symmetric encryption keys to the first user device after confirming the transfer in response to receiving the request; At the first trusted node, generate a first symmetric encryption key and a second symmetric encryption key in response to receiving the request, wherein since the generation of the symmetric encryption key takes precedence over the transfer, neither the first user device nor the second user device has one of the symmetric encryption keys; Via a trusted node in the network, transfer the second symmetric encryption key from the first trusted node to the second user device in response to receiving the request; At the first trusted node, receive from one of the trusted nodes in the network a confirmation of the transfer of the second symmetric encryption key to the second user device in response to receiving the request at the first trusted node; and In response to a confirmation of the transfer of the second symmetric encryption key to the second user device in response to receiving the request at the first trusted node, transfer the first symmetric encryption key from the first trusted node in the network to the first user device, the first symmetric encryption key and the second symmetric encryption key being symmetric to each other.

11. The tangible non-transitory computer-readable medium according to claim 10, wherein the method further comprises: Pre-configure the nodes in the network to trust each other as trusted nodes in a mesh network or a peer-to-peer network.

12. The tangible non-transitory computer-readable medium according to claim 10, wherein the method further comprises: Perform immediate optimal path finding in the network.

13. The tangible non-transitory computer-readable medium according to claim 10, wherein the method further comprises: Performing immediate load balancing in the network.

14. The tangible non-transitory computer-readable medium according to claim 10, wherein the method further comprises: Generating a quantum key in two or more adjacent trusted nodes; And Using the quantum key to encrypt and decrypt the first symmetric encryption key or the second symmetric encryption key.

15. An apparatus for out-of-band symmetric encryption key transfer for a seatbelt, comprising: Multiple nodes of a network to form trusted nodes in a peer-to-peer or mesh network; And A first trusted node among the trusted nodes for: Receiving a request from a first user device to transfer a symmetric encryption key to the first user device and a second user device, the first trusted node translating the request into an instruction for generating the symmetric encryption key in response to receiving the request, transferring one of the symmetric encryption keys to the second user device in response to receiving the request, confirming the transfer of one of the symmetric encryption keys to the second user device, and transferring the other of the symmetric encryption keys to the first user device after confirming the transfer in response to receiving the request; At the first trusted node, generating a first symmetric encryption key and a second symmetric encryption key in response to receiving the request, wherein since the generation precedes the transfer, neither the first user device nor the second user device has one of the symmetric encryption keys; Via the trusted nodes, transferring the second symmetric encryption key from the first trusted node to the second user device in response to receiving the request; Receiving, from one of the trusted nodes, a confirmation of the transfer of the second symmetric encryption key to the second user device in response to receiving the request at the first trusted node; and In response to the confirmation of the transfer of the second symmetric encryption key to the second user device in response to receiving the request at the first trusted node, transferring the first symmetric encryption key from the first trusted node to the first user device, the first symmetric encryption key and the second symmetric encryption key being symmetric.

16. The apparatus according to claim 15, wherein the trusted node further: Performs immediate optimal path finding in the peer-to-peer or mesh network.

17. The apparatus according to claim 15, wherein the trusted node further: Performs immediate load balancing in the network.

18. The apparatus according to claim 15, wherein the trusted node further: Generates a quantum key in two or more adjacent trusted nodes; and Uses the quantum key to encrypt and decrypt the first symmetric encryption key or the second symmetric encryption key during the transfer.

19. The apparatus according to claim 15, wherein the trusted node further: During the transmission of the first symmetric encryption key and the second symmetric encryption key, encryption and decryption using a quantum key are used for each node-to-node transmission.

20. The apparatus according to claim 15, wherein the trusted node further: During the transmission of the first symmetric encryption key and the second symmetric encryption key, perform an immediate optimal path search based on the availability of the quantum key.

Images