System and method for distribution of key generation data in a secure network

Abstract

Systems, methods, and computing devices are provided for distribution of cryptographic key generation data in a secure network including a security server and one or more clients. The method includes receiving or generating indexed random data, communicating at least a portion of the indexed random data to one of the clients, and receiving or communicating an index of a portion of the indexed random data to be shared with the client, the portion of the indexed random data being used to generate a cryptographic key for encrypted communications between the client and another client. In some cases, the above is repeated for each client, and the indexed random data is unique for each client.

Description

[Technical Field]

[0001] The following relates to data communication systems and encryption used in such systems, and more particularly to systems and methods for distribution of key generation data in secure networks. [Background technology]

[0002] Symmetric and asymmetric cryptography for digital communications often assume that a hypothetical adversary is computationally constrained. A classic example is the widely used Rivest-Shamir-Adleman (RSA) asymmetric scheme, which assumes that factoring the product of two large prime numbers is computationally infeasible. Against an adversary who possesses the factors, communication between the parties involved is completely insecure. However, an efficient quantum algorithm for factoring large integers (Shor's algorithm) is feasible on a cryptographically relevant quantum computer (CRQC). Shor's algorithm can break RSA, Diffie-Hellman key exchange, and elliptic curve cryptosystems, resulting in a significant risk to public key infrastructures (PKIs). While CRQCs are not yet available, malicious eavesdroppers can easily memorize currently exchanged data in case new protocol breakthroughs are deployed, and technological advances make current theoretical exploits or the emergence of CRQCs practical. Summary of the Invention [Means for solving the problem]

[0003] In one particular aspect, a method is provided for distributing cryptographic key generation data in a secure network, the secure network including a security server and one or more clients, the method including receiving or generating indexed random data, communicating at least a portion of the indexed random data to one of the clients, and receiving or communicating an index of a portion of the indexed random data to be shared with the client, the portion of the indexed random data being used to generate a cryptographic key for encrypted communication between the client and another client.

[0004] In certain cases of the methods, the method further includes deleting the portion of the indexed random data shared with the client after the portion has been used for the encrypted communication.

[0005] In another case of the method, the indexed random data is used to generate a symmetric encryption key for encrypted communication between the client and another client.

[0006] In yet another case of the method, receiving the indexed random data occurs only if the security server is present in the associated Security Hub, and communicating the portion of the indexed random data to one of the clients occurs only if the client is served by the associated Security Hub.

[0007] In yet another case of the method, receiving the indexed random data includes physical delivery of hardware, quantum key distribution, symmetric encryption using a pre-shared key, or asymmetric encryption, and communicating a portion of the indexed random data to one of the clients includes physical delivery of hardware, quantum key distribution, symmetric encryption using a pre-shared key, or asymmetric encryption.

[0008] In yet another case of the method, receiving the indexed random data, communicating at least a portion of the indexed random data to one of the clients, and communicating an index of the portion of the indexed random data to be shared with the client are repeated for each client, and the indexed random data is unique for each client.

[0009] In yet another case of the method, the method further includes generating a cryptographic key by combining a portion of the indexed random data associated with each respective user having the same index.

[0010] In yet another case of the method, the secure network includes a plurality of security servers, and the method further includes, at each security server, receiving key shares for a secret sharing protocol from a client, the key shares encrypted using a first one-time key derived from indexed random data associated with the client and the respective security server; decrypting the key shares using the first one-time key; encrypting the key shares using second one-time keys generated from indexed random data associated with other clients and the respective security servers; and communicating the key shares encrypted with the second one-time key to the other clients.

[0011] In yet another case of the method, the first one-time key and the second one-time key are encrypted using one-time pad encryption.

[0012] In yet another case of the method, the key shares are part of a Shamir secret sharing scheme or a threshold secret sharing scheme.

[0013] In yet another case of the method, the method further includes encrypting the key shares using a third one-time use key generated from indexed random data associated with the additional client and the respective security server, and communicating the key shares encrypted with the third one-time use key to the additional client.

[0014] In another aspect, a computing device for distribution of cryptographic key generation data in a secure network is provided, the computing device comprising a security server or distributor in the secure network, the secure network further comprising one or more client devices, the computing device comprising a processor and memory, the memory storing computer instructions that, when executed by the processor, cause the processor to receive or generate indexed random data, communicate at least a portion of the indexed random data to one of the clients, and receive or communicate an index of a portion of the indexed random data to be shared with the client, the portion of the indexed random data being used for cryptographic key generation for encrypted communication between the client and another client.

[0015] In certain cases of the computing device, the instructions further include deleting the portion of the indexed random data shared with the client after the portion has been used for the encrypted communication.

[0016] In another case of a computing device, the indexed random data is used to generate a symmetric encryption key for encrypted communications between the client and another client.

[0017] In yet another case of a computing device, receiving the indexed random data occurs only if a security server is present in the associated Security Hub, and communicating a portion of the indexed random data to one of its clients occurs only if the client is served by the associated Security Hub.

[0018] In yet another case of a computing device, receiving the indexed random data includes physical delivery of hardware, quantum key distribution, symmetric encryption using a pre-shared key, or asymmetric encryption, and communicating a portion of the indexed random data to one of the clients includes physical delivery of hardware, quantum key distribution, symmetric encryption using a pre-shared key, or asymmetric encryption.

[0019] In yet another case of a computing device, receiving the indexed random data, communicating at least a portion of the indexed random data to one of the clients, and communicating an index of the portion of the indexed random data to be shared with the client is repeated for each client, and the indexed random data is unique for each client.

[0020] In yet another case of the computing device, the instructions further include generating a cryptographic key by combining a portion of the indexed random data associated with each respective user having the same index.

[0021] In yet another case of a computing device, the secure network includes multiple security servers, and the instructions, executed at each security server, further include receiving key shares for a secret sharing protocol from a client, the key shares encrypted using a first one-time key derived from indexed random data associated with the client and the respective security server; decrypting the key shares using the first one-time key; encrypting the key shares using second one-time keys generated from indexed random data associated with other clients and the respective security servers; and communicating the key shares encrypted with the second one-time key to the other clients.

[0022] In yet another case of a computing device, the first one-time key and the second one-time key are encrypted using one-time pad encryption.

[0023] In yet another case of a computing device, the key shares are part of a Shamir secret sharing scheme or a threshold secret sharing scheme.

[0024] In yet another case of the computing device, the instructions further include encrypting the key shares using a third one-time use key generated from indexed random data associated with the additional client and the respective security server, and communicating the key shares encrypted with the third one-time use key to the additional client.

[0025] These and other aspects are considered and described herein. The foregoing summary describes exemplary aspects of methods and computing devices to aid those skilled in the art in understanding the following detailed description.

[0026] The embodiments are better understood with reference to the following drawings. [Brief explanation of the drawings]

[0027] [Figure 1] 1 illustrates a conceptual diagram of an exemplary computing environment for distribution of key generation data in a secure network, according to one embodiment. [Figure 2] 1 illustrates a conceptual diagram of a system for distribution of key generation data in a secure network, according to one embodiment. [Figure 3] 1 illustrates a flow chart of a method for distribution of key generation data in a secure network, according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0028] For simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. Additionally, numerous specific details are set forth to provide a thorough understanding of the embodiments described herein. However, it will be understood by those skilled in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the embodiments described herein. Likewise, the description should not be considered to limit the scope of the embodiments described herein.

[0029] Unless the context indicates otherwise, various terms used throughout this specification may be read and understood as follows: "Or" as used throughout is inclusive even when written "and / or," and singular articles and pronouns used throughout include their plurals, and vice versa. Similarly, pronouns indicating a gender include their counterparts, and thus pronouns should not be understood as limiting anything described herein to a single gender use, implementation, performance, etc. Additional definitions for terms may be set forth herein, and as will be understood upon reading this specification, those definitions may apply to the examples preceding and following those terms.

[0030] Any module, unit, component, server, computer, terminal, or device illustrated herein that executes instructions may include or otherwise have access to a computer-readable medium, such as a storage medium, computer storage medium, or data storage device (removable or non-removable). Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include RAM, ROM, EEPROM, flash memory, or other memory technologies. Any such computer storage medium may be part of a device or may be accessible or connectable to a device. Furthermore, unless the context clearly indicates otherwise, any processor or controller described herein may be implemented as a single processor or multiple processors. Multiple processors may be collocated or distributed, and any processing function referred to herein may be performed by one or multiple processors, even if a single processor is illustrated. Any methods, applications, or modules described herein may be implemented using computer-readable / executable instructions stored or otherwise maintained by such computer-readable media and executed by one or more processors.

[0031] In this disclosure, the following terms are used:

[0032] Client - A computing device capable of receiving and storing pre-shared random data (PSRD) and initiating requests for key generation or secret sharing with other clients via any number of security servers.

[0033] PSRD Distributor - A computing device or system dedicated to the secure distribution of PSRDs from the Security Hub to clients, typically within a specific geographic region.

[0034] Post-Quantum Cryptography (PQC) - Asymmetric cryptographic algorithms designed to be resistant to attacks by quantum computers.

[0035] PSRD - Pre-Shared Random Data.

[0036] QKD(Quantum Key Distribution) - Quantum key distribution.

[0037] Quantum Secure Channel (QSC) - A communications channel that is secured in a way that is resistant to attacks by both classical and quantum computers.

[0038] Security Hub - A group consisting of a Security Server and, in some cases, one or more PSRD Distributors.

[0039] Security Server - A server or cluster of servers that manages the core operations of sharing the PSRD and facilitating secure communication between clients for exchanging symmetric keys or secrets.

[0040] Quantum-secure key distribution approaches have crucial differences compared to asymmetric solutions and have applications in network security, end-user device security, and embedded systems: such approaches can be effectively coded to run on computationally constrained devices where the demands of asymmetric cryptography may be too great.

[0041] This embodiment may also be generally compatible with asymmetric encryption, so that asymmetric encryption via post-quantum cryptography (PQC) may be used to transport the PSRD.

[0042] Quantum key distribution (QKD) is also a quantum-secure key distribution system. It relies on the foundations of quantum mechanics, in contrast to traditional public-key cryptography, which relies on the computational intractability of certain mathematical functions. The main drawback of quantum key distribution is a problem often referred to as the rate-distance limitation. Significantly increasing the bit rate or range of QKD is currently considered infeasible without quantum repeaters. This generally limits QKD to regional or metropolitan area networks (MANs), or to ground-to-satellite QKD.

[0043] Current attempts to overcome the above limitations widely use trusted relay architectures. Trusted relays offer a simple way to overcome the distance limitation without significantly increasing the complexity of the QKD architecture. The main drawback of trusted relays is that they rely on a series of intermediate nodes. Importantly, these nodes must be trusted. In basic implementations, the compromise of any one relay in the chain of relays compromises the entire system. If the required throughput is held constant, the number of trusted relays required for a QKD network increases linearly with the distance between nodes.

[0044] FIG. 1 illustrates a diagram of an exemplary computing environment according to this embodiment. The computing environment includes PSRD distributors 10, each associated with one security server 20. In FIG. 1, a first PSRD distributor 10 is located in region 1, and a second PSRD distributor 10 is located in region 2. The subsystem consisting of a security server 20 and all its PSRD distributors 10 is referred to as a security hub 30. In the exemplary computing environment of FIG. 1, there are three security hubs 30 (indicated by the "x3" notation). Thus, a computing environment can provide one or more active security hubs 30, and the presence of multiple security hubs 30 provides substantial benefits, as described herein. A PSRD distributor 10 shares a large amount of unallocated pre-shared random data (PSRD) with its associated security hubs 30. When the PSRD distributor 10 allocates and delivers a portion of a PSRD to a client 40, the PSRD distributor 10 notifies the security server 20 of the index of the PSRD to be delivered to the client 40. Communication between the PSRD distributor 10 and the client 40 can be performed using either QKD or physical delivery. In other cases, such communication can involve symmetric encryption algorithms using pre-shared keys (if such pre-shared keys exist between the PSRD distributor 10 and the client 40) or asymmetric encryption techniques. Any pair or group of clients 40 can, if they wish, use encryption that provides complete secrecy, such as One Time Pad (OTP) encryption, and secret sharing to achieve key distribution that can be used for encryption and authentication, i.e., to secure the QSC 50.

[0045] The purpose of the clients 40 is to generate identical symmetric encryption keys in an information-theoretically secure manner, or computationally securely if standard symmetric or asymmetric encryption is used to deliver the PSRD or protocol messages. Note that any number of clients 40 are allowed in the system, and each client 40 may be connected to any of the available PSRD distributors 10.

[0046] As described herein, the link between the PSRD distributor 10 and the clients 40 in Figure 1 is used to transmit pre-shared random data between the PSRD distributor 10 and the clients 40. The link between the clients 40 represents a communication channel secured by an encryption key provided by the embodiments described herein.

[0047] The communications network may be any suitable communications architecture, e.g., the Internet, a wide-area network (WAN), a local-area network (LAN), a mobile communications structure, etc. The communications link may be any suitable communications approach, e.g., a landline, a wireless connection, a short-range communications connection, or other form of communications. The computing devices in the environment may be any suitable type of computing device, e.g., a desktop computer, a laptop computer, a tablet, a smartphone, a wearable device, an internet-of-things (IoT) device, a server, a distributed computing system, dedicated hardware, etc.

[0048] This embodiment provides an approach for distributing encryption keys between clients 40 without the need for the clients 40 to pre-share or pre-exchange any information with each other. This embodiment utilizes a service provider, the security hub 30. Each security hub 30 has a hierarchical structure consisting of a single security server 20 and, in some cases, one or more PSRD distributors 10. In some cases, the functionality or location of the PSRD distributor 10 may be combined with the security server 20.

[0049] 2, a diagram of a computing device 150 for distribution of key generation data in a secure network is shown, according to one embodiment. Computing device 150 may execute on or be part of PSRD distributor 10 and / or security server 20 and may comprise a single computing device or multiple devices with associated shared storage. In other cases, components of computing device 150 may be distributed among two or more computer systems, which may be distributed locally or remotely, for example, using cloud computing resources.

[0050] FIG. 2 illustrates various physical and logical components of a computing embodiment of computing device 150. As shown, computing device 150 has multiple physical and logical components, including processor(s) 152 (comprising one or more processors), random access memory (RAM) 154, user interface 156, network interface 160, non-volatile storage 162, and local bus 164, which allows CPU 152 to communicate with other components. CPU 152 executes an operating system and various modules, as described in more detail below. RAM 154 provides relatively responsive volatile storage to CPU 152. User interface 156 allows an administrator or user to provide input via input devices, such as a mouse, touchscreen, or keyboard. User interface 156 also outputs information to an output device, such as a display. Network interface 160 enables communication with network 20 or with other computing devices and servers located remotely from computing device 150. Non-volatile storage 162 stores the operating system and programs, including computer-executable instructions for implementing the operating system and modules, as well as any data used by these services. Additional stored data may be stored in database 166. During operation of computing device 150, the operating system, modules, and associated data may be retrieved from non-volatile storage 162 and placed in RAM 154 to facilitate execution.

[0051] In one embodiment, computing device 150 further includes multiple concept modules 170 executing on one or more processors 152 , including a data module 172 , a client module 174 , and an authentication module 176 .

[0052] The PSRD distributor 10 delivers a unique table of indexed random data, called the Pre-Shared Random Data (PSRD), to the clients 40. In general, to be maximally secure, the generation and management of PSRDs should adhere to strict constraints of randomness, confidentiality and related security, erasure before use in case of potential tampering, and secure erasure if copied, transferred, or used. The purpose of the PSRD distributor 10 is to facilitate the sharing of PSRDs between clients 40 and the security server 20. In most cases, the PSRD distributor 10 is geographically located to be more convenient for the set of clients 40. Delivery of a PSRD from a PSRD distributor 10 to a client 40 may occur in several different ways, including physical delivery of tamper-proof or tamper-evident hardware, sealed tamper-evident QR codes, quantum key distribution (QKD) technology, electronic delivery using symmetric encryption (such as Advanced Encryption Standards) that loses information-theoretic security properties, or PQC-protected encryption that further reduces security guarantees. Furthermore, the same PSRD distributor 10 may deliver a PSRD to different clients 40 in different ways. For example, a PSRD distributor 10 may deliver a PSRD to one client 40 using QKD and to another client 40 via physical delivery of tamper-evident hardware. A security hub 30 may use any one or more of its PSRD distributors 10 to deliver a PSRD to a given client 40. In some cases, PSRD distributors 10 may need to be geographically located in the same region due to range, geographic, administrative, and / or logistical constraints in order to deliver PSRDs to clients 40. Security server 20 may be geographically located anywhere in the world.

[0053] In particular, a PSRD is a private table of indexed random data generated from a high-quality source of randomness, such as a quantum random number generator. With a PSRD properly indexed, two parties sharing the same PSRD table can identify values ​​in the PSRD by referencing only the index.

[0054] The security server 20 receives or otherwise possesses a copy of all PSRDs delivered to clients 40 by the PSRD distributor 10. This exchange of PSRDs between the security server 20 and the PSRD distributor 10 can occur before or after the PSRDs are delivered to clients 40 by the PSRD distributor 10.

[0055] If the exchange occurs before the PSRD is delivered to the client 40, either the security server 20 or the PSRD distributor 10 generates a large amount of unallocated random data, appropriately indexed, and delivers an exact copy to the other party. Using the associated index for such data, the PSRD distributor 10 informs the security server 20 which portion of the initial unallocated random data has been delivered, or vice versa, before the PSRD distributor 10 delivers the PSRD to the client 40. If the exchange occurs after the PSRD is delivered to the client 40, the PSRD distributor 10 delivers to the security server 20 an exact copy of the PSRD that will be delivered to a particular client 40. The exchange of data between the security server 20 and the PSRD distributor 10 occurs via physical delivery using tamper-proof hardware, QKD, a combination of the two, or any other sufficiently secure means.

[0056] Each client 40 shares a PSRD with each of one or more security servers 20, either through direct transmission of the PSRD from the security server 20 or through transmission of the PSRD using any of the PSRD distributors 10 in the same security hub 30 as the security server 20. Each security server 20 belongs to a separate security hub 30 and therefore has its own set of PSRD distributors 10. When a client 40 shares a PSRD with a security server 20, the client 40 can be considered to be currently served by that security hub 30. In one example, consider two clients 40, referred to as Alice and Bob, that are served by a common set of one or more security hubs 30. This configuration allows Alice and Bob to exchange symmetric keys. The symmetric keys can be generated using any suitable approach, such as the Advanced Encryption Standard (AES) or ChaCha20.

[0057] For example, one or more security servers 20 may be used, in which multiple first private tables are each shared with Alice and each of the security servers 20, and multiple second private tables are each shared with Bob and each of the security servers 20. The first private table contains random data values ​​with associated indexes, and the second private table contains other random data values ​​with associated indexes different from those in the first private table. The values ​​in the first private table are not shared with Bob, and the values ​​in the second private table are not shared with Alice. In such an example, Bob receives an index each associated with a value in one of the second private tables, each index received from a respective security server 20 having a second private table with which it shares those values. Each index is associated with a value that matches an indexed value in one of the first private tables received by the same respective security server 20 from Alice. A common key is generated for secure communication by combining the indexed values ​​of the second private table, and the common key is authenticated using an authentication protocol. In certain instances, the methods described herein may be used.

[0058] In addition to the examples above, other encryption techniques with perfect confidentiality may be used by any group of clients 40 and security server 20 to generate symmetric encryption keys.

[0059] Each PSRD distributor 10 is the center of a region network connected to clients 40 for delivery of pre-shared random data (PSRD). The PSRD can be generated via a high-quality entropy source, such as a quantum random number generator (QRNG). The PSRD is generated by either the PSRD distributor 10 or the security server 20. In either case, a copy of the PSRD is delivered to the other party using the approach described herein. Thus, if the PSRD is generated by the PSRD distributor 10, a copy is then transmitted to the security server 20. If the PSRD is generated by the security server 20, the PSRD is then transmitted to one of the PSRD distributors 10, and is generally repeated for each PSRD distributor 10. In this manner, each PSRD distributor 10 shares a unique copy of the PSRD with the security server 20.

[0060] A PSRD need not be assigned to a particular client 40 when it is created. Alternatively, a PSRD may be unassigned when it is created, although this does not preclude it from being assigned to a particular client 40 when it is created. Each copy of an unassigned PSRD is stored on both the security server 20 and one of the PSRD distributors 10 until either one of them assigns the copy and delivers that portion of the PSRD to each of the clients 40. The PSRD is indexed so that portions of the PSRD can be easily identified and referenced. Techniques for delivering a PSRD to clients 40 are described herein.

[0061] Delivery of additional unallocated PSRD may occur before the existing unallocated PSRD is depleted.

[0062] For example, PSRDs may be transferred between the security server 20 and the PSRD distributor 10, and vice versa, using any of the following mechanisms: QKD, Physical delivery using a secure storage medium, preferably tamper-proof, possibly using a secure key transmission device such as a key loader or key filler; Electronic transfer, if a pre-shared key already exists between the two parties (but in many cases this is not information-theoretically secure, even if asymmetric encryption is not used), Electronic transmissions using asymmetric cryptographic algorithms, including PQC, that are quantum-resistant but generally not information-theoretically secure and may have other weaknesses, including vulnerability to quantum attacks, among other issues; or · Any combination of the above.

[0063] When a new client 40 joins the system, the PSRD distributor 10 or security server 20 can provide a copy of the PSRD (or a copy of a portion of the PSRD) to the client 40. The PSRD can be transmitted to the client 40 in any of the following ways (but is not limited to): QKD, Physical delivery using a secure storage medium, preferably tamper-proof, possibly using a secure key transmission device such as a key loader or key filler; Electronic transfer, if a pre-shared key already exists between the two parties (but in many cases this is not information-theoretically secure, even if asymmetric encryption is not used), Electronic transmissions using asymmetric cryptographic algorithms, including PQC, which are quantum-resistant but generally not information-theoretically secure and may have other weaknesses, including vulnerability to quantum attacks, among other issues; Tamper-evident sealed QR code or similar visually encoded means, or · Any combination of the above.

[0064] Whenever data is sent by the PSRD distributor 10 to a client 40, the security server 20 is notified of the PSRD index sent to the client 40, and the data may be deleted or otherwise marked as used from the PSRD distributor 10's data store. When the security server 20 delivers a PSRD (or a portion of a PSRD) to a client 40, the security server 20 notifies the PSRD distributor 10 of the PSRD index sent to the client 40, and the data may be deleted or marked as used from the PSRD distributor 10's data store. In most cases, consistent with the single-use key principle, data is deleted to ensure that only copies exist on the client 40 and security server 20 that use this data. Multiple copies of the same PSRD stored unnecessarily outside of these two locations may increase the risk of a breach to the system without providing any benefit. Note that communication between the PSRD distributor 10 and the security server 20, even if using a secure protocol, may occur over an insecure channel. In either case, the only information that needs to be transmitted is the index of the PSRD assigned to the client 40. This communication should be authenticated, but may also be encrypted using a portion of the PSRD shared between the PSRD distributor 10 and the security server 20.

[0065] The client 40 can perform the same operation with each of multiple security hubs 30. The client 40 can share random data (PSRD) with the security server 20 in one or more security hubs 30, and key generation can use such data.

[0066] The key generation may be performed using any suitable approach, for example: A PSRD table shared between a first client, called Alice, and security server 1, security server 2, ..., security server N is defined as H A 1,H A 2,…,H A N The PSRD tables shared between the second client, called Bob, and security server 1, security server 2, ..., security server N are named H. B 1,H B 2,…,H B N Alice and Bob share a common key K AB In some cases, any security server may wish to share K AB In one embodiment, the key generation phase may include five parts: "peer identity establishment," "share generation," "share distribution," "key reconstruction," and "key verification," which together may be collectively referred to as a "generic distributed symmetric key exchange" or "generic protocol."

[0067] During the first part, called "Peer Identity Establishment," Alice and Bob establish the authenticity of each other's identities. Authentication of identities between Alice and Bob and the security server is typically the result of the PSRD generation and distribution phase. Any DSKE client can use the protocol to query other clients' identities from each security server, which performs the authentication, and the DSKE client validates the identity claims by the security server using information-theoretically secure message tags. Security servers that provide identity information about DSKE clients that conflict with the consensus are excluded from the protocol by the querying DSKE client. In this way, the initial authentication between a DSKE client and a security hub can be propagated throughout the system to mutually authenticate DSKE clients and to allow each DSKE client to know the identifiers used by each security server for other DSKE clients.

[0068] During the second part, called “share generation”, Alice generates N shares S1, S2, …, S of the final key S. N A pre-agreed family of (N,k) secret sharing schemes is used to generate H. Share S1 is associated with security server 1, share S2 is associated with security server 2, and so on. k is the smallest number of these shares from which it is possible to reconstruct the key S that will be shared between Alice and Bob. To generate the key shares that will be used to deliver the key to Bob, Alice first determines the length of the key to be generated, i.e., m, the number of bits in the key that Alice wants to share with Bob. Then, for each i∈{1,2,…,N}, Alice simply calculates H A i An unused sequence R of m+l bits that can be the first unused sequence in A i H A iis selected from. The integer l is the length in bits of the parameter h for the family of universal hash functions used in this protocol for generating the key tag. Thus, Alice reaches N strings of bits such as R A i = [H A ij , H A ij+1 , H A ij+2 , …, H A ij+m+l-1 , where j is the index into the table H A i and, optionally, the index of the first bit not previously used in the DSKE protocol. In general, due to the ability of compromised security hubs to modify the share Si of the secret in transit that contains a portion of the l bits of the secret parameter h, the family of universal hash functions used to generate the key tag is chosen using the property that the security against key tag forgery maintains strength in the context of the particular secret sharing scheme chosen.

[0069] Starting from the N strings R A i , Alice constructs N shares named Y i for i ∈ {1, 2, …, N} and sends them to the security server. Alice arbitrarily selects k security servers for which Y i = R A i is set and uses this as the share for security server i. If k = N, all the shares are already generated. If k < N, Alice uses these k shares and then uses the secret sharing scheme to construct the remaining N - k shares so that the secret can be reconstructed from any k of these shares. At this point, Alice has one share Y i for each i ∈ {1, 2, …, N}.

[0070] During the third part, called “share delivery”, for each i∈{1, 2,…, N}, Alice assigns H A i Bit R from A i ,N,k,, the ordered index of the sequence (which may, for example, simply be the starting index and length), along with Bob’s identity, a unique key identifier (which may, for example, include an index to the running key), and a key tag (if generated). Alice then uses the coordinates X for Shamir’s secret sharing scheme. i Alice can also encode auxiliary information such as A i Nk shares Y not generated from i , R A i and encrypts it using the one-time pad Z as the encrypted share Z that Alice includes in her message. A i (for example,

number

[0071] Upon successful verification of the message from Alice, each security server then sends its share Y i(In the example, Y is determined by a message from Alice. i =R A i or

number

number

[0072] For each key instruction message received by Bob from security server i, Bob verifies that security server i is a member of an acceptable set (e.g., a pre-agreed set of N security hubs, or otherwise a security hub known to serve both Alice and Bob). Bob performs the same sequence of operations as performed by security server i, i.e., verifies that Alice is an accepted identifier and that N and k (encoded in the message) are each within the acceptable range. Additionally, Bob checks for duplicate indices, verifies the message tag, decrypts each share, and generates H B i Mark the index to as used. Messages that are non-conforming in any respect are discarded. At the end of this phase, Bob has successfully received multiple shares s.

[0073] During the fourth part, called "key reconstruction," Bob has enough information to either reconstruct a set of candidates for secret S or abort the protocol. If the number of shares s received by Bob is less than k, Bob aborts the protocol. Otherwise, Bob reconstructs candidate secrets from each subset of k shares with consistent protocol parameters (including the key tag, if present) using the associated (N,k) secret sharing scheme.

[0074] During the fifth part, called "Key Verification," Bob either chooses a candidate for S, which represents the final key shared with Alice, or aborts the protocol. First, Bob matches all reconstructed candidate secrets against key tags applicable to the subset of k shares from which they were derived and eliminates any candidate secrets that do not match. If the number of compromised security hubs is less than k, none of the candidate secrets will be known to the adversary, and as a result, the adversary will be unable to create a tag that Bob accepts, leaving only one candidate key, possibly from multiple share combinations. If two or more distinct candidates remain, Bob aborts the protocol. If Bob has only one candidate left, it must be S, and Alice and Bob complete the protocol properly as intended using the shared key.

[0075] Once random data is shared between the client 40 and the security server 20, information-theoretically secure delivery of the symmetric key can be achieved, for example, by perfect secrecy and secret sharing encryption, examples of which are the five parts described herein: "peer identity establishment," "share generation," "share distribution," "key reconstruction," and "key verification." One-time pad encryption for the transfer of secret data from one security server to a client, or vice versa, is an example of perfect secrecy encryption. The use of a threshold secret sharing scheme (e.g., Shamir's secret sharing scheme) can be used to prevent any security server 20 from having any knowledge of the secret agreed upon between clients 40. In one example, for any two or more clients 40 that share a PSRD with a common set of security servers 20, the clients 40 are in a position to use approaches such as those described herein over classical communication channels (e.g., over the Internet) for secure communication. In the example of FIG. 1, any client 40 in domain 1 can use this embodiment to share a key with any client 40 in domain 2 in an information-theoretically secure manner. For example, using the generic protocol described herein, in which a PSRD is shared between a client 40 (a user device in the incorporated reference) and a security server 20 via a security hub (a privacy provider in the incorporated reference). The various regions may be geographically separated by large distances. In this way, the security hub 30 of this embodiment advantageously enables geographic expansion in an efficient manner while maintaining the required security properties.

[0076] In an exemplary application of this embodiment, the generic protocol described herein can be generalized to allow any form of encryption and authentication to be used for the messages and key instructions communicated. These messages can include secret shares sent by a first client 40 to the security server 20 for corresponding messages that the security server 20 communicates to a second client 40. For example, such messages can be encrypted and authenticated using standard implementations of symmetric block ciphers using the PSRD associated with the first client 40 or the PSRD associated with the second client 40 as the key, respectively. This example can also include situations where several encryption and authentication schemes are used in tandem, e.g., to achieve multiple encryptions.

[0077] In another example, for any two or more clients 40 that share a PSRD with a common set of security servers 20, one of the clients 40, e.g., Alice, can send key shares constructed using a secret sharing protocol (e.g., Shamir's secret sharing scheme) to another client 40, e.g., Bob. The PSRD can be shared through the security servers 20, e.g., using one-time pad encryption with a one-time key derived from the PSRD shared with the security servers 20. Each security server 20 decrypts the key shares using the same key used by Alice, which is also derived from the indexed PSRD. Each security server 20 then encrypts the key shares with the key derived from the PSRD shared with Bob, e.g., using one-time pad encryption and information-theoretically secure authentication, and sends the encrypted and authenticated message to Bob, who can in turn decrypt the message in a similar manner. Thus, Bob expects to receive and decrypt a number of key shares equal to the number of security servers 20 selected by Alice. Bob can thus reconstruct the private key by appropriately combining the key shares using the same secret sharing scheme used by Alice (in this example, Shamir's secret sharing scheme).

[0078] In another exemplary application of this embodiment, the generic protocol described herein may be generalized to allow for alternative secret sharing schemes. For example, Shamir's secret sharing scheme may be replaced by a different threshold secret sharing scheme, including one that assigns different weights to the shares known to individual security hubs 30.

[0079] In this example, a first client 40, say Alice, can request that each security server 20 simultaneously send a share to two or more other designated clients 40, say Bob and Carol. In this case, the security server 20 can send a share to each of the designated clients 40. In this way, Alice can exchange secrets with multiple other clients 40 simultaneously.

[0080] Further in this example, the first client 40 can request that each security server 20 send it a share, and one of the other designated clients 40 can be the first client 40. In this manner, the selective storage and later retrieval of the resulting encrypted shares can be used to facilitate secure management of sensitive data, for example, to manage securely encrypted data backups.

[0081] In general, for any two or more clients 40 that share a PSRD with a common set of security servers 20, the clients can generate information-theoretically secure symmetric keys using methods such as those described in the generic protocol described herein. As described in the generic protocol, the requirement is for the group of clients to share a private table of random data with multiple privacy providers, which in this example include the security servers 20 (and more broadly, the security hub 30) to which the private table is delivered.

[0082] The structure of the security hub 30, including the security server 20, and the PSRD distributor 10 provides important advantages for the scalability of the key distribution system and the integration of technologies such as quantum key distribution. In fact, if the security hub 30 included one security server 20 and no PSRD distributor 10, the security server would be responsible for distributing PSRDs to clients, leveraging possible quantum key distribution on a local scale. Furthermore, the security server 20 may need to physically deliver the PSRD to a very distant location, which increases the risk or cost of transmitting the PSRD. Therefore, the security server 20 would generally benefit greatly from the establishment of a PSRD distributor 10 responsible for distributing PSRDs to local clients using one of the techniques described herein. Furthermore, to save costs and increase security, the PSRD distributor 10 would benefit from the possibility of pre-generating a large number of PSRDs before any client 40 submits a request and distributing identical copies of this large number of PSRDs to the security server 20. This avoids the challenge of transporting PSRDs from the PSRD distributor 10 to the security server 20 on a client-by-client basis, and instead aggregates large numbers of PSRDs into a single transport, which can then be used to communicate the index of the PSRD assigned to the client 40 in an information-theoretically secure manner.

[0083] Referring to FIG. 3, a method for distributing key generation data in a secure network 300 is shown in accordance with one embodiment. At block 302, a data module 172, as part of one of the PSRD distributors 10, receives pre-shared random data (PSRD) from or provides a PSRD to the security server 20. The PSRD includes indexed random data. At block 304, the client module 174 transmits at least a portion of the pre-shared random data to the client 40. At block 306, the server module 176 communicates an index of the portion of the pre-shared random data shared with the client 40. At block 308, the data module 172 deletes the portion of the pre-shared random data shared with the client 40.

[0084] In some instances of this embodiment, applications may be advantageously implemented such that secret data exchanged between clients 40 can be used by these clients 40 as symmetric keys to cryptographically secure communications between the parties. A practical example of such an application includes a secure communication application on a smartphone, with delivery of a PSRD encoded as a QR code in a sealed, tamper-evident package and replenished online in encrypted form. A further practical example of such an application includes a point-to-point link encryptor in a secure network. A further practical example of such an application includes secure storage of data in a data backup scheme or secure storage of data held in a shared escrow scheme. A further practical example of such an application includes an IoT device that first incorporates a PSRD and then subsequently replenishes it online in encrypted form. These merely represent examples, and this embodiment may be applied to a wide range of potential applications in the cryptography space. In particular, this embodiment can simplify key management logistics with significant benefits of scalability, while adding resistance to quantum computing attacks, which has shown advantages over other approaches, such as PKI.

[0085] While the above has been described with reference to certain specific embodiments, various modifications to these embodiments will become apparent to those skilled in the art without departing from the spirit and scope of the invention as outlined in the appended claims.

Claims

1. 1. A method for distributing cryptographic key generation data in a secure network, the secure network including a security server and one or more clients, the method comprising: receiving or generating indexed random data; communicating at least a portion of the indexed random data to one of the clients; receiving or communicating an index of a portion of the indexed random data to be shared with the client, the portion of the indexed random data being used to generate a cryptographic key for encrypted communications between the client and another client; A method comprising:

2. 2. The method of claim 1, further comprising deleting the portion of the indexed random data shared with the client after the portion is used for the encrypted communication.

3. 2. The method of claim 1, wherein the indexed random data is used to generate a symmetric encryption key for the encrypted communication between the client and the other client.

4. 2. The method of claim 1, wherein receiving the indexed random data occurs only if the security server is present in an associated security hub, and communicating the portion of the indexed random data to one of the clients occurs only if the client is serviced by the associated security hub.

5. 10. The method of claim 1, wherein receiving the indexed random data comprises physical delivery of hardware, quantum key distribution, symmetric encryption using a pre-shared key, or asymmetric encryption, and communicating a portion of the indexed random data to one of the clients comprises physical delivery of hardware, quantum key distribution, symmetric encryption using a pre-shared key, or asymmetric encryption.

6. 2. The method of claim 1, wherein receiving the indexed random data, communicating at least a portion of the indexed random data to one of the clients, and communicating the index of the portion of the indexed random data shared with the client are repeated for each client, and the indexed random data is unique for each client.

7. 7. The method of claim 6, further comprising generating the encryption key by combining a portion of the indexed random data associated with each respective user having a corresponding index.

8. The secure network includes a plurality of security servers, and the method comprises, at each security server: receiving a key share for a secret sharing protocol from the client, the key share encrypted using a first one-time key extracted from the indexed random data associated with the client and each of the security servers; decrypting the key share using the first one-time key; encrypting the key share using a second one-time key generated from the indexed random data associated with the other client and each of the security servers; communicating the key share encrypted with the second one-time key to the other client; The method of claim 6 further comprising:

9. 9. The method of claim 8, wherein the first one-time key and the second one-time key are encrypted using one-time pad encryption.

10. The method of claim 8 , wherein the key shares are part of a Shamir secret sharing scheme or a threshold secret sharing scheme.

11. 9. The method of claim 8, further comprising: encrypting the key shares using a third one-time key generated from the indexed random data associated with an additional client and each of the security servers; and communicating the key shares encrypted with the third one-time key to the additional client.

12. 1. A computing device for distribution of cryptographic key generation data in a secure network, the computing device comprising a security server or distributor in the secure network, the secure network further comprising one or more client devices, the computing device comprising a processor and a memory, the memory, when executed by the processor, causing the processor to: receiving or generating said indexed random data; communicating at least a portion of the indexed random data to one of the clients; receiving or communicating an index of a portion of the indexed random data to be shared with the client, the portion of the indexed random data being used to generate a cryptographic key for encrypted communications between the client and another client; A computing device that stores computer instructions that cause the device to perform the following:

13. 13. The computing device of claim 12, wherein the instructions further comprise deleting a portion of the indexed random data shared with the client after the portion is used for the encrypted communication.

14. 13. The computing device of claim 12, wherein the indexed random data is used to generate a symmetric encryption key for the encrypted communication between the client and the other client.

15. 13. The computing device of claim 12, wherein receiving the indexed random data occurs only if the security server is present in an associated security hub, and communicating a portion of the indexed random data to one of the clients occurs only if the client is serviced by the associated security hub.

16. 13. The computing device of claim 12, wherein receiving the indexed random data comprises physical delivery of hardware, quantum key distribution, symmetric encryption using a pre-shared key, or asymmetric encryption, and communicating a portion of the indexed random data to one of the clients comprises physical delivery of hardware, quantum key distribution, symmetric encryption using a pre-shared key, or asymmetric encryption.

17. 13. The computing device of claim 12, wherein receiving the indexed random data, communicating at least a portion of the indexed random data to one of the clients, and communicating the index of the portion of the indexed random data to be shared with the client are repeated for each client, and the indexed random data is unique for each client.

18. 13. The computing device of claim 12, wherein the instructions further comprise generating the encryption key by combining a portion of the indexed random data associated with each respective user having a corresponding index.

19. the secure network includes a plurality of security servers, and the instructions are executed on each security server; receiving a key share for a secret sharing protocol from the client, the key share encrypted using a first one-time key extracted from the indexed random data associated with the client and each of the security servers; decrypting the key share using the first one-time key; encrypting the key share using a second one-time key generated from the indexed random data associated with the other client and each of the security servers; communicating the key share encrypted with the second one-time key to the other client; 20. The computing device of claim 18, further comprising:

20. 20. The computing device of claim 19, wherein the first one-time key and the second one-time key are encrypted using one-time pad encryption.

21. 20. The computing device of claim 19, wherein the key shares are part of a Shamir secret sharing scheme or a threshold secret sharing scheme.

22. 20. The computing device of claim 19, wherein the instructions further comprise: encrypting the key shares using a third one-time key generated from the indexed random data associated with an additional client and each of the security servers; and communicating the key shares encrypted with the third one-time key to the additional client.

Images