Introduction

The Entropy Key is a small, unobtrusive and easily installed USB stick that generates high-quality random numbers, or entropy, which can improve the performance, security and reliability of servers. It can also be used with scientific, gambling and lottery applications, or anywhere where good random numbers are needed. Devices such as the Entropy Key are sometimes called True Random Number Generators. It has been developed by UK-based Simtec Electronics, a design consultancy and manufacturing partner with 20 years of experience in designing and building high-speed, high-performance electronics with a speciality in embedded ARM-based designs.

The Entropy Key contains two high-quality noise generators, and an ARM Cortex CPU that actively measures, checks and confirms all generated random numbers, before encrypting them and sending them to the server. It also actively detects attempts to corrupt or sway the device. It aims towards FIPS-140-2 Level 3 compliance with some elements of Level 4, including tamper-evidence, tamper-proofing, role-based authentication, and environmental attacks. If it detects that one of its two generators has failed, may be about to fail, or if it detects a physical attack, it will automatically shut down.

How the Entropy Key helps your security

The Entropy Key generates a constant stream of very high-quality random numbers, ready to be mixed into the entropy already collected by your computer. The quality of the numbers passes randomness tests such as Diehard and Dieharder, chi and est. This means that when your computer requires random numbers, which is usually for very security-sensitive tasks such as certificate and key creation, administration, VPN access, and even customer-facing web requests, the data used to secure them is even stronger. The Entropy Key also makes it extremely difficult for any attacker to discover what random data has been used, even if they have physical access to the Entropy Key.

How the Entropy Key helps performance and reliability

Operating systems such as Linux have a built-in pool of random data that they top up from devices like the Entropy Key and other such sources. Applications that require random data, such as web servers, VPN servers and clients, administration tools and such, then read from this pool. The problem is that the pool is of fixed size (just 4kB) and as standard has limited entropy input. If an application tries to read from the pool, and there is not enough data to satisfy its request, the application is frozen in limbo until enough entropy has been collected to fill the pool to the point of being able to satisfy the request, leading to delays in the delivery of services. Worse, this frozen state reduces the ability of the operating system to generate its own random data, as their collectors are based on the timings of activity. The Entropy Key keeps this pool topped up, meaning even at busy times for your server, the pool is full or very nearly full, leading to faster response times and fewer difficult-to-diagnose service pauses. And if a single Entropy Key doesn't provide enough to keep your busy server stoked with entropy, then you can just plug another in.

Examples of how quickly entropy is consumed

(click for larger)

In the above graph, we can see that the available entropy on this server was at (or at least, very close) to 4096 bits, the maximum that was configured. On removal of the Entropy Key, it almost instantly drops to well below 512 bits. The server in question is serving web sites and email for a few dozen domains, and has plenty of background processes running for accounting, which help generate entropy by creating significant I/O load approximately every five minutes. The mail server handles many TLS-encrypted email connections (both SMTP and IMAP), and initialising these connections consumes huge amounts of entropy. Additionally, under modern distributions of Linux, every process start consumes entropy in order to randomise dynamic linking order. As such, shell scripts fired from cron jobs often consume surprising quantities.

At this point, the performance of software requiring high-quality entropy from /dev/random will suffer as there is insufficient for it to provide, and the security of software reading from /dev/urandom will suffer due to the lack of fresh entropy being injected into the system.

Note that while most of the entropy consumed on this server is read through /dev/urandom, under Linux this shares the same pool of entropy as /dev/random, reducing the available bits as it is used, until a watermark point at which /dev/urandom simply rehashes its contents rather than introducing new entropy. This is more clearly demonstrated on the following graph.

(click for larger)

On this graph we show the same on a typical Linux desktop machine running typical office software (word processor, mail client, web browser), but not in active use. The entropy does not drop as rapidly as on the server above, but it does give an insight to the workings of /dev/random and /dev/urandom. Almost all the software running on this desktop will be using /dev/urandom, and the entropy pool shrinks to reflect this. However, as entropy is gathered from other sources (such as interrupts), the available entropy slowly increases over the period of 2 to 3 minutes, at which point it hits the watermark where it is acceptable for /dev/urandom to freshen itself with real entropy rather than rehashing old entropy, and it suddenly drops again, creating a saw-tooth pattern.

Where can I get one?

You can order them from this website; just click the 'Shop' link at the top of the page. If you require a bulk order, or are interested in reselling Entropy Keys, then please contact our sales team. The details are on the Contact Us page.