Entropy with NeuG

At LinuxCon Japan 2015, Yutaka Niibe presented [PDF] his work on NeuG, a true random-number generator (TRNG) built entirely with free software and which can run on a variety of cheap hardware devices. There are several competing free-software TRNG options on the market these days; NeuG may not generate the fastest stream of random numbers, but it is notable for its flexible hardware support and its simplicity.

Niibe began the session with a brief autobiographical sketch. He has been a long-time GnuPG developer, with much of his work focusing on libgcrypt. Several years ago, he began working on a GnuPG smartcard implementation called Gnuk. The Gnuk project involved designing and building a secure hardware token that he dubbed the FST-01. Along the way, he said, he became convinced that users were in need of a hardware TRNG.

The issue, of course, is that cryptography requires good keys and generating good keys require random numbers. Interest in the subject is on the increase, he said, with projects like the Free Software Foundation's (FSF's) Email Self Defense and the Electronic Frontier Foundation's (EFF's) HTTPS Everywhere but, he reminded the audience, GnuPG is a fundamental part of free-software distribution, too, providing signatures for releases, commits, and packages.

Given the importance of the topic, hardware TRNGs are vital because users have to trust the hardware in order to trust their encryption keys. There may be backdoors in algorithms, he noted, but there may also be backdoors in hardware—as has been alleged about Intel's RDRAND instruction or in cryptographic chips. So he decided to buck the recent trend of building more powerful embedded devices, and set out to develop a TRNG that uses a cheap, general-purpose microcontroller rather than any specialty hardware.

NeuG is the result. The primary focus has been on implementing NeuG as an alternate firmware for the FST-01, he said, but it will run on several other devices. At the moment, there are five, all of which use the STM32F103 microcontroller found on the FST-01. The microcontroller features an ARM Cortex-M3 core running at 72MHz and has full-speed USB 2.0 connectivity. The various boards include between 20 and 64KiB of RAM and between 64 and 512KiB of flash ROM.

The cheapest option is the ST-Link debugger board that ships with ST's STM8S-DISCOVERY kit; it can be had online for less than ten dollars. The FST-01 remains the reference design, though. It includes 20KiB of RAM, 128KiB of ROM, a 12MHz crystal, a status LED, and some additional flash memory. The schematics and circuit-board designs are free as well.

When connected to a Linux PC, the FST-01 appears as /dev/ttyACM0 (or whatever /dev/ttyACM device is available) and also presents a small USB mass-storage device holding a copy of the GPLv3 license and a README file for using the software. The random-number generation works by sampling the microcontroller's two built-in analog-to-digital converters (ADCs). One ADC samples the microcontroller's reference voltage pin and built-in temperature sensor, while the other is tied to two of the microcontroller's analog input pins (both of which are pulled up to the power supply pin). These four signal sources are sampled in various combinations, passed through four rounds of CRC32, then passed through a SHA-256 conditioning function.

The output, Niibe said, is about 256 bits of entropy from every 280 bits sampled. The FST-01 produces around 80KB of entropy per second in this fashion. The NIST SP 800-90B standard defines the conditioning requirements needed to remove sampling bias, he said, and it defines three health checks that one can use to test the quality of the output. The NeuG software includes a Python program to test the device's output, he said, "but if you don't trust me, you can test it with external tools, too." He recommended TestU01 and PractRand, though he cautioned that they can require extremely large data sets for proper analysis.

Normally, he continued, the device is used with the kernel's rng-tools; the NeuG software bundle includes a udev rule and systemd service to feed output into the kernel's entropy pool. But it can be sampled directly, too, with raw samples, CRC32-filtered bits, and fully SHA-256–conditioned output all available. Altogether, the NeuG library is quite compact: the version that ships on the FST-01 is just 1,500 lines of code, including the USB stack, the USB communications device class (CDC) and mass-storage drivers, and a small thread library called Chopstx.

Regarding the performance of the TRNG design, Niibe admitted that many electrical engineers prefer to talk about other, more esoteric entropy sources like avalanche diodes, photon decay, and radio waves. They sound better, he said, but such exotic sources are not usually needed in practice. People also ask him whether NeuG offers any advantage over haveged, to which he replies that haveged may be good enough for many people on its own, but that it is always better to have multiple, independent entropy sources.

An audience member asked how much entropy a system needs. Niibe replied that some people go overboard, but in his opinion it is best to think of entropy like spice. "Don't drink your soy sauce," he said to a collective chuckle from the crowd, "just use a little wasabi if you want to enjoy your sushi."

Others in attendance asked about the use of the microcontroller at the core of the project. Could the code be ported to other microcontrollers, perhaps? And is there any protection against hardware trojans in the microcontroller itself? Niibe replied that the code is quite portable, and could probably be ported to a variety of other microcontrollers if someone is interested.

As for the possibility of hardware trojans, he said that the risk of compromised hardware was the reason he chose a modest, general-purpose part, adding "although now that I've given this talk, I guess the bad guys will start attacking it." But the STM32F103 has been around for eight years or so, he said, so if users are really paranoid, they should just go buy one now (or even try to find an old one) before the spies get to them. He is also occasionally asked why the NeuG uses a TTY with no encryption to deliver its data, he said. His response is that he could implement USB-channel encryption, but he does not think it makes sense to encrypt your USB bus. If the NSA is snooping your internal USB traffic, he said, "I think you're already finished."

Niibe ended the session with a few "further reading" recommendations for those interested in random-number generation. In summary, he said that free software is about controlling one's own computing. Where encryption is concerned, we need something at the center to serve as the anchor point. No one can control the random number sequence, he said, so he would like to see more people use hardware TRNGs, whether they buy one of his or another.

The most direct comparison to NeuG might be Moonbase Otago's OneRNG, which we looked at in January. Both are open hardware in addition to running free software. The OneRNG uses an avalanche diode as its entropy source and its bit rate is estimated at 350Kbps. So users have some decisions to make if they are interested in choosing one or the other—the NeuG may not produce as much entropy, but it may produce enough for daily usage. On the other hand, the OneRNG is a recent Kickstarter product: although shipments have begun, there is only one source for the hardware, as opposed to the five different boards supported by NeuG. Regardless of how those factors weigh out, however, it is good to have multiple options—and options that take substantially different approaches to the problem of random-number generation.

[The author would like to thank the Linux Foundation for travel assistance to attend LCJ 2015.]