Can quantum solve cybersecurity’s entropy challenge?

Written by Garrett Bekker, Senior Research Analyst, Security – 451 Research

Random numbers are used for just about every type of cryptographic operation, including generating SSH keys and public/private key pairs as part of a PKI system. The quality of random numbers is measured by entropy. Full-entropy random numbers are completely random, with no meaningful patterns, while low-entropy random numbers may result in the possibility of forthcoming values being predicted.

Without entropy, cryptographic functions such as encryption are rendered essentially useless. An encryption key is just a random number that can’t be guessed, so if the encryption key is the same every time, it can be predicted and therefore defeated. In a replay attack, for example, all an attacker would have to do is replay a snapshot and they could predict a key.

Common methods used to generate random numbers include pseudorandom number generators, as well as hardware-based random number generators that rely on physical processes to generate randomness, such as mouse movements or fan noise. Trusted platform modules (TPMs) and hardware security modules (HSMs) can also generate their own random numbers.

The challenge with most existing methods of producing random numbers is that they result from deterministic processes or algorithms, which makes them predictable, at least in theory.

It is critical that entropy be constantly generated, monitored and replenished, particularly for high-volume environments that cycle through encryption keys constantly. Some environments are more challenging than others when it comes to generating entropy: for example, ephemeral keys for implementing TLS within a software-defined perimeter (SDP) offering, or IoT devices that have very little processing power with which to produce their own entropy.

And new areas of technology such as cloud-native environments expose the challenge of generating entropy on two fronts. The first is that many new computing environments rely heavily on virtualization or containers that are abstracted away from the underlying hardware they run on. The second is that new instances and workloads are spun up and down at massive scale, which in turn can require massive amounts of entropy to scale, along with new demands for encryption keys.

Similarly, embedded devices or systems typically don’t have enough moving parts to generate sufficient entropy on their own. Other emerging use cases for entropy pools include 5G scenarios, quantum key distribution, or edge deployments of software-defined networking functionality.

In general, systems for generating entropy can be grouped into two categories: blocking and non-blocking. In a blocking system (such as /dev/random in Linux systems), any processes that require entropy will be ‘blocked’ until more entropy is generated in the system. This can slow down application performance, a phenomenon known as ‘entropy starvation,’ in some cases for up to several hours. In a non-blocking system (such as /dev/urandom in Linux), if not enough entropy is available, the system will essentially ‘fudge it’ with deterministic randomness, which removes application bottlenecks – by eliminating the need to wait for entropy – but results in lower entropy and lower security. The net result is that the available ‘pool’ of entropy often forces firms to choose between performance and security.

These challenges are putting data at risk and impacting the performance of systems. Technologies are beginning to emerge that leverage the latest in quantum technology and can help solve the entropy problem. One approach is to use the high levels of entropy that can be obtained from quantum devices, and combine them with tools to inject this entropy into your systems. Quantum random number generators can now deliver entropy at very high rates (in some cases up to 1G/s). When coupled with applications to monitor the entropy of a system, they can fully address the entropy starvation challenge, constantly replenishing entropy without relying on /dev/u/random.