Abstract:
A system for securely moving data from one location to another exchanges key material between the locations. The system enables cryptosystems to use key material distributed over a quantum channel.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application claims priority to U.S. Provisional Application 61/475,875, filed Apr. 15, 2011, the contents of which are incorporated by reference. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    This invention is in the field of information security, and relates in particular to cryptographic key generation, quantum key distribution, distributed key management, and redundant storage. 
         [0003]    Conventional key management systems first generate or import key material on one node before replicating the key material to a redundant or backup node. These systems use database or file backup or replication to move key material between nodes. These systems rely on computational security to protect key material transferred between nodes, and are unable to efficiently manage key material for use with the one-time pad cipher. 
       BRIEF SUMMARY OF THE INVENTION 
       [0004]    The present invention provides a cryptographic key management system incorporating key generation, information theoretic secure key distribution, and redundant storage. The system provides efficient management and delivery of key material for a one-time pad cipher, as well as other conventional ciphers. 
         [0005]    In a preferred embodiment we provide a system for secure transfer of data for creation of encryption keys from a first system to a second system. The first system includes a random number generator, preferably operating in the quantum region, which provides bits representing random number. A quantum key distributor is coupled to the random number generator for receiving the bits representing random numbers and transmitting them to a second system. A quantum channel connects the quantum key distributor to the second node to enable transfer of the bits representing random numbers to the second node. The quantum channel operates in the quantum regime of light, allowing it to enable detection of interference with the quantum channel, e.g. by a third party attempting to compromise the information. A key storage in the first node stores encryption keys generated from the random numbers, and a key management system is coupled to the key storage for interfacing the first system with a system invoking the first system. 
         [0006]    The invention also enables a method of transmitting data securely between a first communications device coupled to a first encryption system and connected by a potentially unsecure channel to a second communications device which in turn is coupled to a second encryption system. Preferably the method includes steps of receiving data at the first communications device and obtaining a first key identifier and associated first key material from a key manager in the first encryption system. Then a step is performed of using the first key material to encrypt the data received at the first communications device to provide encrypted data. The encrypted data and the first key identifier are transmitted over the potentially unsecure channel to the second communications device. 
         [0007]    At the second communications device, the first key identifier is extracted from the transmitted data. Then using the first key identifier, corresponding first key material is retrieved from the second encryption system. Using the first key material, the encrypted data is decrypted. Because the first encryption system communicates with the second encryption system over a quantum channel connecting a first quantum key distributor in the first encryption system with a second quantum key distributor in the second node, the transfer of bits representing the retrieved random number may be sent to the second node in a secure manner. The quantum channel operating in the quantum regime of light to enables detection of interference with the quantum channel. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]      FIG. 1  is a block diagram of the quantum key distribution key management system; 
           [0009]      FIG. 2  is a more detailed block diagram of the key storage blocks shown in  FIG. 1 ; 
           [0010]      FIG. 3  is a block diagram of the key management blocks; 
           [0011]      FIG. 4  illustrates a technique for encrypting and authenticating data between two networks connected over an untrusted connection; and 
           [0012]      FIG. 5  illustrates a technique for protecting data using a quantum key distribution system. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0013]      FIG. 1  is a functional block diagram of a preferred embodiment of a quantum key distribution and key management system. The QKD key management system  100  consists of two nodes  102  and  112  which are coupled to server interfaces  120  and  126 , respectively. The two nodes  102  and  112  are connected by communication channels—a quantum channel  140 , a classical channel  138 , a key management channel  136 , and a key storage channel  150 . The quantum channel  140  is a channel through which quantum states of light encoded with random bits are transmitted from node to node. The quantum channel is a conduit that facilitates the transport of light between the nodes. It may, for example, be an optical dark fibre link or a free-space connection. The classical channel  138  is a conventional communication channel, for example, as might be found in an Ethernet based local area network, a Wi-Fi link, a FibreChannel link, or similar communications channel. The key management channel  136  is also a conventional communication channel like that of channel  138 , but one over which key management information is provided. Messages exchanged over the classical channel  138  and the key management channel  136  are protected by a Message Authentication Code (MAC) to ensure the integrity of messages between two nodes  102  and  112 . These codes are also used to authenticate the identity of the sending node. A communications channel  150  is also provided between the key storage in node  102  and node  112 . Messages over this channel are also authenticated using MACs. 
         [0014]    Node  102  includes a random bit generator (RBG)  110 . The random bit source provides random bits for use as key material. Node  112  also includes a source of random bits  109 . In some implementations of the invention, this source is used to generate key material. In the preferred embodiment, random bit generator  110  provides cryptographically strong random bits—knowledge of the current state of the RBG is insufficient to retrieve previously generated outputs, and observation of RBG outputs is insufficient to predict future outputs. Examples of a sufficiently secure random bit source are described in “A generator for unique quantum random numbers based on vacuum states,” C. Gabriel, C. Wittmann, D. Sych, R. Dong, W. Mauerer, U. L. Andersen, C. Marquardt and G. Leuchs, Nature Photonics, vol. 4, no. 10, pp. 711-715, 2010; and in “Real time demonstration of high bitrate quantum random number generation with coherent laser light,” T. Symul, S. M. Assad and P. K. Lam, Appl. Phys. Lett. 98, 231103, 2011. The contents of each of these documents is incorporated by reference herein. 
         [0015]    Quantum key distribution (QKD) blocks  108  and  118  provide for quantum key distribution. Each block provides a quantum channel interface  128  and  132 , and a classical channel interface  130  and  134 . The quantum channel interface  128  on the transmitting node  102  is implemented as an electro-optical modulator that converts an electrical signal into an optical signal. The quantum channel interface  132  on the receiving node  112  is implemented as a photo-detector that converts an optical signal into an electrical signal. The classical channel interfaces  130  and  134  are system calls that relay data through the operating system&#39;s network stack onto network interface cards (NICs). Quantum key distribution  108  receives a stream of random bits from the random bit source  110 . These bits are encoded onto quadrature observables of the quantum states of light, and then transmitted to QKD node  118  over the optical quantum channel  140 . The receiving QKD node  118  makes measurements of the quadrature observables of the received quantum states of light using homodyne detectors. 
         [0016]    The quantum channel  140  is characterised by analysing a subset of the data transmitted from QKD node  108  and received by QKD node  118 . This subset consists of elements randomly selected using input from the random bit generator  109 —addressing information transmitted from node  118  to node  108  over the classical channel  138  enables node  108  to select an identical subset. This characterisation results in estimates of channel parameters: the attenuation of the signal, the variance of the signal and the noise added to the signal by its passage through the channel. Other parameters are pre-computed for a given set of hardware: the optical insertion loss at the receiving QKD node  118 , the dark noise on the photodetectors at the receiving QKD node  118 . These parameters are used to compute an upper bound on the information available to any eavesdropper. This bound is used together with the mutual information between the two QKD nodes  108 , 118  and the efficiency of the error correction algorithm (a precomputed value) in order to derive the informational advantage of the QKD nodes  108 , 118  over possible eavesdroppers. This bound is used to drive a series of manipulations (post-selection, error correction and privacy amplification) of the shared key that results in a subset of the key about which no eavesdropper has information. 
         [0017]    Operational messages relating to these manipulations (as well as to the earlier characterisation step) are transmitted over the classical channel  138 . Messages on this channel are authenticated and integrity protected using message authentication codes. The messages may also be encrypted. The QKD nodes  108  and  118  produce information-theoretically secure key material which is transferred to the key storage facilities  106  and  116  in each node. 
         [0018]    Our implementation of quantum key distribution builds on published theoretical and experimental work. See, e.g., “No-switching quantum key distribution using broadband modulated coherent light,” A. M. Lance, T. Symul, V. Sharma, C. Weedbrook, T. C. Ralph and P. K. Lam, Phys. Rev. Lett. 95, 180503, 2005; “Experimental demonstration of post-selection-based continuous-variable quantum key distribution in the presence of Gaussian noise,” T. Symul, D. A. Alton, S. M. Assad, A. M. Lance, C. Weedbrook, T. C. Ralph and P. K. Lam, Phys. Rev. 76 A (R), 030303, 2007; and “Quantum Cryptography Without Switching,” C. Weedbrook, A. M. Lance, W. P. Bowen, T. Symul, T. C. Ralph and P. K. Lam, Phys. Rev. Lett. 93, 170504 , 2004. The contents of each of these documents is incorporated by reference herein. 
         [0019]    The key storage blocks  106  and  116  shown in  FIG. 1  provide storage for key material obtained from the respective QKD function blocks  108  and  118 .  FIG. 2  is a functional block diagram illustrating these components in more detail. Each key storage block contains a database  202  and  222  which stores key material  204  and  224 , and descriptive metadata  206  and  226  in a persistent manner. Key material arrives in the key storage block  106  and  116  from the QKD block  108  and  118 . It is received by controlling software  200  and  220 . The software components in each node coordinate their activities over a communications channel  150 . The communications protocol ensures that the key material  204  and  224 , and metadata  206  and  226 , remain synchronised. The descriptive metadata  206  and  226  provides information about the volume and location of the stored key material. 
         [0020]    Key material is extracted from the key store when required by the key management blocks  104  and  114 . Extraction requires the exchange of metadata over the communications channel  150  to keep both nodes synchronised. For an additional layer of data integrity assurance, the nodes exchange hashes of the extracted key material. Equality of these values reduces the probability of asymmetric data corruption. 
         [0021]    The key management blocks  104  and  114  shown in  FIG. 1  provide external clients with an interface to the key storage  106  and  116 .  FIG. 3  is a functional block diagram illustrating the key management blocks  104  and  114  in more detail. Each key management block  104  and  114  controls two sets of keys: a first set  361  and  371  is used to protect and process, respectively, communications from block  104  to block  114 , while the second set  381  and  351  is used to protect and process, respectively communications from block  114  to block  104 . Preferably each set of keys resides in a discrete region of system memory. 
         [0022]    Each key management block contains a function  350  and  370  that retrieves fixed-size chunks of key material from the key storage  106  and  116 . The key material is placed into a pool of available processing keys  352  and  372 . Messages exchanged over the key management channel  136  cause corresponding keys to be placed in the protecting key pools  362  and  382 . The causal relationship enforces the condition that every key available for protection is also available for processing. 
         [0023]    When external client software running on one node desires to protect (e.g: encrypt) a message to the peer node, the client requests a key identifier be assigned to it. The key management logic  104  and  114  assigns the first key identifier from the pool of available processing keys  362  and  372  and transmits the assignment to the peer node over the communications channel  136 . The sending node moves the assigned key to a pool of issued protection keys  363  and  373 , while the receiving node moves the assigned key into a pool of issued processing keys  353  and  383 . Upon each key entering a pool of issued keys  353 ,  363 ,  373  and  383 , it is associated with an expiry time. Should the key not be removed from the pool before its expiry time is reached, the key is recycled as described below. 
         [0024]    Once it has a key identifier, the sending client requests enough key material to protect its message from the chunk of key material associated with that identifier. The key management logic  104  and  114  removes the consumed key material from the material associated with the key identifier. The key is then moved into the pool of used protecting keys  364  and  374 . 
         [0025]    External client software desiring to process (e.g: decrypt) a message must be in possession of a key identifier. The client passes this key identifier to the key management logic  104  and  114 . The key management block searches for a matching key in the pool of issued processing keys  353  and  383  and the pool of available processing keys  352  and  382 . Synchronisation of the key generation process guarantees that the key is present in one of the two pools. 
         [0026]    Once a matching key is found, the requested volume of key material is returned to the, client and the key is passed into the pool of used decryption keys  354  and  384 . These pools are monitored by the software  360  and  380  responsible for key reuse as discussed next. 
         [0027]    of used keys to be reused. Such reuse prevents the waste of any unused portions of a chunk of key material. Given a fixed rate of key generation, this parsimony allows the system to support higher key request rates. Keys for reuse are drawn from the pools of used keys  354 ,  364 ,  374  and  384  and from issued keys  353 ,  363 ,  373  and  383  which have expired. Reuse is performed by replacing the consumed portion of the key with material drawn from the key storage  106  and  116 . The key is then processed in the same manner as newly generated keys, that is, as described above. 
         [0028]    The system of our invention provides several advantages over prior art systems. For example, key material is jointly generated on both nodes and does not require subsequent replication. The distribution of raw key material and its transformation into secure key material is done in an information theoretically secure manner. The system efficiently manages and distributes key material for use with one-time pad ciphers as well as with conventional cipher algorithms. 
         [0029]    Next we describe two examples of use of the invention. A first example concerns protecting data in transit between physically disparate nodes. The other example is of protecting data resident within a single node. 
         [0030]    Key data managed by the invention can be used to encrypt and authenticate data between two networks connected over an untrusted connection.  FIG. 4  illustrates how the invention provides this facility between two networks. Traffic from the first network  451  is routed into the red (secure) port  406  of a link encryptor  402 . This port is implemented using an Ethernet card which is bridged to an Ethernet-level virtual network device  455 . 
         [0031]    Traffic arriving on the virtual device  455  is read by software  454  running inside the link encryptor  402 . This software  454  obtains a key identifier and associated key material from the key manager in node  102 . The key material is used to encrypt the traffic, using either one-time pad or a traditional cipher algorithm. The ciphertext and the associated key identifier may be augmented with a message digest or other form of message authentication. The ciphertext, the key identifier and any authentication information are transmitted from the link encryptor&#39;s (insecure) black port  410 , which is connected to an untrusted network—the second network  441 . 
         [0032]    The message is received by the (insecure) black port  414  of the peer link encryptor  404 . Software  444  within the link encryptor  404  verifies the message against any included authentication tokens. It then extracts the key identifier and retrieves the indicated key material from the key management component  112 . The key material is used to decrypt the enciphered traffic, producing plaintext. This text is injected into an Ethernet-level virtual network interface  445  which is bridged to the (secure) red port  408  of link encryptor  404 . This results in the traffic from the first network arriving on the second network  441 . 
         [0033]    The above method is bidirectional. Traffic from the second network  441  enters link encryptor  404  over the red port  408  and is bridged to a virtual Ethernet device  445 . The traffic is encrypted using a key acquired from the QKD node  112 . The enciphered traffic and a key identifier are transmitted from the black port  414  of link encryptor  404  over an untrusted network. The ciphertext arrives on the black port  410  of link encryptor  402  and is bridged through a virtual Ethernet device  454  to software. The software extracts the key identifier and retrieves the appropriate key material from the QKD node  102 . This key material is used to decrypt the ciphertext and the resulting plaintext is then transmitted out of the red port  406  to the trusted network  451 . 
         [0034]      FIG. 5  illustrates a second example of how our system can be used to protect data residing in a storage medium such as a hard disk drive, disk array, tape drive, storage area network or similar facility. Data stored in the data storage system  502  is secured using cryptographic cipher algorithms. The necessary key material is extracted from a quantum key distribution node  112  and stored in a separate storage system  512 . The quantum key management system uses a second QKD node  102  and an administrative link  520  to replicate the key material within a secondary storage system  528  which can be used for archival, redundancy, escrow or recovery purposes. The replication process is information-theoretically secure. 
         [0035]    The replication provides robust protection for the stored data. Because the cryptographic material necessary to access the data is stored in an external system  512 , compromise of the system  502  does not necessarily compromise the protected data. Furthermore, failure of system  512  does not render the protected data inaccessible because the cryptographic key material needed to retrieve the data may instead be sourced from the secondary system  528 . The role of the key management system in this implementation is twofold. First, it assures that the key material replication at node  528  is secure. Second it assures that the key material was created using the high quality entropy provided by the random bit generator within that node. A hypothetical eavesdropper cannot compromise the system by attacking the links  520 ,  138  and  140  because sensitive material is not transmitted across these links. In addition, the random bit generator within the node protects the system against predictive attacks that exploit inadequate entropy. Vulnerability to such attacks is a known problem in security systems. 
         [0036]    The data storage system  502  supports a data client interface  504  and a key management client interface  508 , both of which facilitate communication over a classical network. The primary key storage system  512  supports a key server interface  510 , a QKD client interface  514  and an administrative interface  518 , all of which enable communication over a classical network. The secondary key storage system  528  also supports a key server interface  530 , a QKD client interface  526  and an administrative interface  522 , each of which connects the system to a classical network 
         [0037]    The data storage system is connected to a secondary key storage system  528  by the secondary key server interface  530 . Different operational modes utilise this interface in different ways. For example, the secondary key server interface  530  can be closed to outside connections unless the primary key storage system  512  fails, in which case an administrator may open this interface to enable communication between the data storage system  502  and the key replication facility  528 . Alternatively, the system could be configured to automatically failover to the secondary key storage system  528  in the event that the primary key storage system  512  fails. 
         [0038]    Key management client interface  508  connects to the key server interface  510  via a trusted communication channel  506 . In event of the failure of the primary key storage system  512 , it may instead connect to the key server interface  530  via a trusted communication channel  512 . Note that depending on the mode of operation channel  512  may be established only as required. 
         [0039]    The key storage system  512  uses the quantum key distribution client interface  514  to connect to the server interface  126  of a QKD node  112  via a trusted communication channel  516 . The secondary key storage system  528  uses its QKD client interface  526  to connect to the server interface  120  of a peer QKD node  102  via a trusted communication channel  524 . The two key storage nodes exchange administrative information using interfaces  518  and  522  to a potentially untrusted channel  520 . 
         [0040]    Data enters and leaves the data storage system  502  through a client interface  504 . The client provides both database requests and identity authentication to system  502 . When storing data, the storage system  502  uses the key management client interface  508  to request a key identifier and associated key material from the primary key storage system  512 . In turn, system  512  uses the QKD client interface  514  to obtain a key identifier and associated key material from the QKD node  102 , via channel  516  and server interface  126 . System  512  stores this key material, its key identifier, and the client identity. It then uses the administrative channel  520  to inform the secondary key storage system of the chosen key identifier/client identity. The secondary system  528  will then request the key material corresponding to this identifier from QKD node  102  via channel  524  and server interface  120 . It also stores the relevant key material, key identifier and client identity. 
         [0041]    Internally, the data storage system  502  stores the data and protects it. The protection uses the key material obtained from the QKD node to perform one or more cryptographic operations such as encryption, message authentication, message digest, or digital signature. The key identifier is stored alongside the protected data, but the key material is not. Thus, future access to the data requires using the key management client  508  and the stored key identifier to re-obtain the necessary key material to access the protected data. 
         [0042]    When requesting data, the data system  502  provides the required key identifier to the key storage  512 , along with the identity of the client making the request. The key storage  512  will look up the key identifier/client combination, ensure that the client has the permissions required to access this key material and then send the key material to system  502 . This will enable  502  to access the cryptographically protected data and fulfil the client request. The QKD key management system  100  ensures that key material requested from each QKD node  102  and  112  is consistent, replicated, and synchronised. Thus, the key stores  512  and  528  store identical key material and either may service requests for a particular key identifier. 
         [0043]    The preceding has been a description of preferred embodiments of the invention. It should be appreciated that various implementation details have been provided to enable a better understanding of the invention whose scope is set forth in the appended claims.