Increasing Entropy with Crypto4A

Have you ever thought about the increasing disorder in your life? Sure, it may seem like things are constantly getting crazier every time you turn around, but did you know that entropy is always increasing in the universe? It’s a Law of Thermodynamics!

The idea that organized systems want to fall into disorder isn’t too strange when you think about it. Maintaining order takes a lot of effort and disorder is pretty easy to accomplish by just giving up. Anyone with a teenager knows that the amount of disorder that can be accomplished in a bedroom is pretty impressive.

One place where we don’t actually see a lot of disorder is in the computing realm. Computers are based on the idea that there is order and rationality in everything that we do. This is so prevalent that finding a way to be random is actually pretty hard. Computer programmers have tried a number of ways to come up with random number generators that take a variety of inputs into the formula and come up with something that looks sufficiently random. For most people just wanting the system to guess a number between 1 and 100 it’s not too bad. But when it comes to really, really large numbers like the ones used in cryptography, those pseudorandom numbers aren’t good enough.

This All Looks So Familiar…

One of the reasons for this comes down to good old fashioned efficiency. In the old days computers programmers could rely on people to generate pseudorandom input. By sampling mouse clicks or delay between computer keyboard keystrokes you could easily come up with a number that looks nice and random. However, we’ve taken people out of the loop now. Thanks to the cloud and automation and any one of a number of new ways to reduce human input we’ve managed to remove mouse clicks and keystrokes.

That’s fine for running scripts and programs. It’s even good for building things at a huge scale. But it’s really bad when you need something that looks relatively random. And it’s really, really bad when your program relies on that randomness to keep you secure. Kind of like key generation in Public Key Cryptography (PKI).

A group of security researchers working for the National Institute of Standards and Technology (NIST) found out a few years ago that public keys were starting to collide at greater rates than random chance. The study, conducted in 2012, found that 5% of HTTPS and 10% of SSH public keys were duplicates. A collision in a hashing algorithm is when two inputs produce the same output, which renders that hashing function broken. In PKI, having a two different inputs output the same public key is really bad, because it could lead to key collisions that impact a variety of service.

What caused it? As it turns out, lack of orderly disorder. Because automation and non-human interaction have led to other pseudorandom inputs being used in key generation it appeared to the researchers that the same inputs were being used all over the place. That meant that a lot of the public keys that were being generated were being done in such as way as to make collisions more likely. When you look at how many things are relying on automated sources to generate keys it can be quite scary. Think about a smart lightbulb or other IoT device that’s trying to generate pseudorandom input from a CPU that’s just big enough to turn things on. Now imagine that CPU multiplied by the number of smart lightbulbs out there. Not a pleasant thought, is it?

Disorder In The Court

This fascinating discussion came from an interview I had with Bruno Couillard, the President and CTO of Crypto4A. Crypto4A is a company that provides Entropy-as-a-Service. What exactly does that mean?

Crypto4A has an appliance they call QAOS. QAOS is designed to give you the best possible disorder that you can get. It does this the old fashioned way. Instead of trying to use software as a Random Number Generator (RNG) QAOS instead uses hardware sources to generate entropy for their RNG. This includes a quantum RNG, which produces high quality disorder that’s difficult to fake any other way.

QAOS is designed to feed software with entropy to generate randomness sufficient to prevent PKI public key collisions. The software developers can follow the NIST guidelines on EaaS to have the program call an entropy source. QAOS, acting as that entropy source, will seed the RNG on the target system with good randomness and allow it to generate good keys. This could also be configured in the kernel of the OS to call a system like QAOS on boot and start the seed value with a good amount of random entropy in the case of old programs that can’t be modified to call anything other than a system-based RNG source like /dev/random/.

Tom’s Take

The NIST guidelines around EaaS are constantly evolving, but the idea that companies are already racing to fill the void that has been created by insufficient randomness in cryptography is telling. When you think about nth the number of devices that are going to be using PKI for secure communications, the need for something like Crypto4A QAOS is pretty clear. If we are going to rely on automated systems to run our daily lives, we need to have the resources in place to ensure they have a solid foundation of randomness to build on.

PKI Uncovered – My Review

Security is a very important element in today’s network. The number of people trying to penetrate and disrupt you network is growing by the day, both internally and externally. The consolidation of servers into the data center is especially bothersome, as it tends to place your high-priority targets into one location.  It’s very important to find a way to keep that data secure from as many intruders as possible.

The trend recently has been to use virtual private networks (VPNs) to secure communications between users and critical data sources. Whether it be a remote access VPN for teleworkers or an internal VPN for HIPAA or PCI compliance, securing data with an encrypted tunnel is the fastest and easiest method of protection. However, in many cases the administrators use inherently insecure on non-scalable methods of VPN authentication, such as pre-shared keys (PSK). PSK works well with very small deployments or with very static equipment that requires few changes or little turnover/replacement. The main problem with using PSK is that it doesn’t scale very well, plus the method of distribution leaves a lot be desired.  You write the PSK down in a file for someone to configure and it’s just as insecure as writing it down on a sticky note. In order to really have a secure and scalable design, you must involve a public key infrastructure (PKI) at some point. I was somewhat familiar with PKI from my security training, but my depth of knowledge at implementing it on Cisco equipment was rather shallow.

As luck would have it, Cisco Press asked for volunteers to review books and I jumped at the chance. Imagine my surprise when a shiny new book showed up on my desk. PKI Uncovered is a new book from Cisco Press that looks to give the average Cisco enginee….rock star a crash course in PKI and the many implementations it has in the networking space. What follows is my review of this book.

PKI Uncovered Cover - Image courtesy of Cisco Press

The first section is an overview of PKI basics for the non-security people. If you are a CISSP, CCSP, or any other conglomeration of security acronyms, these chapters will be review.  The importance of using PKI, along with the differentiations between it and symmetric key encryption are laid out. As well, the hierarchy of certification authorities (CA) are laid out with great detail. Once we get past the review, it’s time to delve into the nuts and bolts of implementation.

The second section of the book looks at specific deployment scenarios where PKI would be useful. Chapter 5 is the generic model that the other chapters build on, so the most basic ideas of deployment and chaining CAs are presented. In the following chapters, more specific needs are addressed, from large scale implementations of PKI used with GETVPN in site-to-site design to remote access with ASAs and IOS VPN. As well, more application focused examples on 802.1x NAC and CUCM phone security are presented. These chapters give great examples to follow along with as well as detailed output of the process at each step. The troubleshooting sections at the end of each chapter are also well written, and could be very useful if you find yourself staring down a real head scratcher.   The final two chapters are presented more as a case study where the previous examples are used to illustrate deployments with Cisco Virtual Office or Cisco Security Manager.  They help tie everything together and allow you to see the building blocks in action.

Tom’s Take

Overall, I found this book a very quick and easy read. It clocks in at less than 250 pages, which is practically a white paper.  It never assumes that you are a PKI expert and does a great job of letting you wade in before you get to the real meat of the example deployments.

The middle of the book will be the most used section, dog-eared and well-worn from hours of reference. I think this will be how I use it the most, as a quick reference guide for my future PKI deployments.  It’s a simple matter to work through the configuration examples and make sure your output matches the generous output examples. The case studies at the end are less compelling, as I doubt I’ll find myself in those kinds of deployment scenarios any time soon.

Overall, I’d recommend this as one to pick up if you have any desire to learn about PKI and its implementation on Cisco devices or feel that you’ll be implementing it any time in the immediate future.

If you’d like to pick up a copy, you can find it on or at


This book was provided to me by Cisco Press at no cost for evaluation. It came with no promise of consideration for a review. The ideas and opinions expressed in this review are mine and mine alone and provided freely for the use and consideration of my audience.