Randomness is the cornerstone upon which cryptographic standards are built. It is used to generate the keys and seeds used in cryptographic schemes. The challenge related to the generation of randomness is the generation of truly random data. Current techniques rely on deterministic approaches – hardware utilizing classical physics, and any available inputs that might add some level of unpredictability – which leads to the generation of pseudo-random data in the vast majority of the cases. Failure to ensure sufficient randomness in cryptographic processes can lead to real-world attacks on otherwise secure systems. This even extends to quantum random number generators which is why there is a need to develop schemes for true randomness.
Conversely, quantum generation of randomness harnesses the power of the non-deterministic nature of quantum mechanics. Generating quantum random numbers can be built in many ways, as has been illustrated by the various approaches used to date, including beam splitters with detectors, vacuum fluctuations in coherent light, and squeezed coherent light mechanisms, among others. Despite the fact that these methods are non-deterministic, they lack the ability for an end user to guarantee that the device is working correctly. This ability in a device (sometimes known as device independence or more commonly, as certifiably quantum generation) is at the heart of the qRNG, Ironbridge, used in our solution.
Ironbridge generates randomness through a quantum process evaluated as quantum verifiable which utilizes a test for the violation of a Bell Inequality, or a higher order test of a Mermin Inequality on a NISQ machine. Such a violation, along with various other security tests, are taken as mathematical proof that the output could have only come from a quantum source and is non-deterministic and thus maximally random for a physical system. For the experiments in this paper, a quantum computer was used to generate the entropy.
Given the distributed nature of a blockchain, ideally each entity running a node should have its own local source of quantum entropy: a qRNG device. However, it was not feasible to provide each node with its own qRNG for our pilot, so we used a central source of quantum entropy. As discussed throughout this paper, current cryptographic schemes used in SSL/TLS are not quantum-safe, so using them to distribute the entropy would have broken the quantum-safeness at the start.
We decided instead to design a protocol that allowed nodes to create a quantum safe tunnel between themselves and the entropy distribution point to ensure that this communication could be considered quantum safe. In order to do this, the entropy source creates a first key, splits it into several parts, and delivers it to the node through various TLS channels. Nodes have a time out to receive the key, recompose it, and use it to authenticate against the entropy source.
Over the last 20 years, the OpenSSL API has become the de-facto cryptographic framework for applications that use TLS/SSL, providing capabilities such as:
The OpenSSL applications and libraries also provide the following functions:
Because quantum computing will impact the security of asymmetric cryptographic algorithms such as RSA and ECDSA, the following changes within OpenSSL are required:
IronBridge Platform facilitates the move to OpenSSL with entropy provided for:
This approach facilitates easy integration into computer security layers within the operating system while still being compatible with most of the existing infrastructure. The IronBridge Service Agent provides post quantum encapsulated key management for the secure entropy tunnel back to the IronBridge Platform. The component provides users with the ability to enforce customer security policies with regard to maximum key lifetimes by automatically providing configurable key cycling capability.
As mentioned before, every blockchain node should ideally have its own source of quantum entropy. For our pilot, LACChain nodes did not have a local source of quantum entropy so it was necessary to establish a quantum-safe connection between the external source (the IronBridge platform) and each of the nodes. As the quantum entropy is necessary to generate the post-quantum keys that allow establishment of a quantum-safe connection, we could not use post-quantum cryptography to protect this first channel.
Therefore, we designed a protocol that begins with the distribution of a post-quantum key from the IronBridge platform to the LACChain nodes. This key is split into N parts and delivered through different TLS channels. Once the LACChain node is in possession of all the N parts, it reconstructs the key and uses it to establish a first connection with the quantum entropy source. This key is only used once, and afterwards it is immediately discarded.
CQC IronBridge provides certified quantum generated entropy for cryptographic use, delivering stronger classical cryptography and the highest strength post-quantum cryptography within customer’s cryptographic ecosystems. Ironbridge’s patent-pending device independent certification mathematically proves every random number is the outcome of a quantum process without trusting the generation process before customer use.
Once this first post-quantum key is used to establish the first secure connection between the LACChain node and the entropy source, they initiate a second process to renegotiate a working KEM keypair using the post-quantum algorithm, McEliece, in line with the NIST round three submission (after NIST round four submissions, McEliece remains as a candidate for standardization). This allows for the establishment of a quantum-safe connection between the entropy source and the nodes which allows the LACChain nodes to start requesting quantum entropy on demand, as illustrated in Figure 1.