How to roll my own hardware RNG?

Question

I am considering building a hardware RNG myself using cheap parts. Is this a good idea and safe enough?

• Random sources: amplified Zener noise from one randomly chosen 1N4728A Zener diode and amplified reverse current of a randomly chosen SS9014 transistor.
• Random stream generating: The two amplified signals are further amplified and biased with one LM324 chip and sent to analog input pins of an Arduino, and the full 10-bit ADC readings are used as the random source.
• Whitening and stream mixing: how to do this on the Arduino's ATmega328P microcontroller?
• Uplink: USB Serial.

Anyone have knowledge on how the whitening and stream mixing can be done? And how to evaluate the security of this system?

Answer 1

The question fails to mention a functionality that must be part of any secure True RNG (as the question aims to build): supervision.

Supervision is responsible to detect a failure of the "Random sources" or "stream generating" stages (hereafter unconditioned source), and in that event reliably prevent use of what the "Whitening and stream mixing" (hereafter conditioning) outputs.

Experience and reasoning show that effective supervision is of paramount importance for security. Wear, build defects, and deliberate attacks against unconditioned sources result into sources that e.g. output a stream of constant bits, or that repeat in a very short cycle, or that reproduce the noise on the power supply, or can be controlled by an adversary beaming smurfons. Should this happen, the conditioning would produce apparently random output that

• Stands a fair chance to be the same from one use to another. This is the archetypal disaster leading to private keys being identical on many devices (thus not secret as they should), or otherwise vulnerable (example: smartfacts) even without knowing the details of the RNG
• Or at least, is vulnerable to attack by one knowing the conditioning, and able to guess the output of the unconditioned source, perhaps by influencing it.

True RNG supervision comprises a test that determines misbehavior of the unconditioned source, and the mechanism (alarm management) acting upon that (like: inactivate everything until the next power cycle). FIPS 140 uses the name "power-up test" and did not mandate further supervision, but the need for supervision actually extends to whenever the RNG might be used: failures and attacks are not bound to strike at power-up!

Supervision also faces a functional requirement of not generating false alarms at a rate that would hamper use of the device. This makes statistical random number generator tests (or at least, their usual parametrization) ill-suited to build supervision. That's because such tests are typically designed to have a quantified and sizable probability of failure for a truly random input, when even 0.01% failure is typically intolerable for mass-produced devices without human operator. Moreover, a practical test must tolerate whatever deviation from uniformly random is expected from its unconditioned source when healthy, and that's heavily dependent of the unconditioned source.

The imperious necessity to tailor supervision to source has been overlooked. Until a change notice in late 2002, FIPS 140 mandated tests (in particular monobit and poker tests) that could not tolerate a small bias or bit cross-correlation. Conformance of a practical device required pre-conditioning of the unconditioned source, in turn making the test less effective, and totally ineffective for a cryptographically strong pre-conditioning. Because FIPS 140 has long been the only public standard specifying test of TRNGs, that mistake is deeply entrenched in literature and standards on secure TRNGs.

---

A modern, minimal practical approach fro a secure TRNG with supervision as above:

• A theoretical model of the unconditioned source must be made, including a target min-entropy rate $r$ (a quantity without unit, in range $(0,1)$, specifying how much true entropy there is per bit output).
• The conditioning must be cryptographically secure under the hypothesis that the unconditioned source meets its target $r$. That could mean feeding a Cryptographically Secure Pseudo Random Number Generator $256/r$ bits before it can output anything.
• The test in the supervision must catch, with high likelihood, any failure mode of the unconditioned source that can be anticipated to occur according to the model and would bring the unconditioned source below its target $r$; and then prevent use of the output of the conditioning.
• Yet the availability of the output must match operational requirements.

There may be other requirements, like detecting a failure/attack of the conditioning, recovering from compromise of the conditioning's state.. that complicate the conditioning.

---

Rough sketch for an appropriate model and conditioning in the question's context: we can model the hardware (when working properly) as a noise source followed by a 10-bit ADC at frequency $2f$ usable to digitize signal from DC to a certain upper frequency commensurate with $f$, with the source noise having an average voltage excursion of say 1/32 full scale at that $f$ (for some loose definition of that). The ADC is 10-bit, with a specified non-linearity of 4 steps.

Thus when things are working properly, each pair of 10-bit samples (drawn over an interval $1/f$, or more due to, say, interrupts) carries at least $10-\log_2(32)-\log_2(4)=3$ bits of entropy ($r=\dfrac3{20}$ when we count bits output by the ADC). This means we are confident that $256/r=2707$ bits or 271 samples have 256 bits of entropy. We take a factor of two for leeway in the (currently unspecified) test, and use 342 samples, that is 748 bytes when representing a sample as 2 bytes. Acquires that, hash it with SHA-256 (quite easy on an Arduino), and we have 256 bits that we can affirm indistinguishable from random, if our source including ADC is not defective (that is, meets at least half its target $r$) and the program is running correctly.

Note: We are talking of a sampling rate $2f$ about 10kHz according to this. The LM324 is rated at about 1MHz Gain×BandWidth Product @5V, thus up to a gain of roughly 100, that amplifier is unlikely to limit the bandwidth.

Note: I have intentionally grossly oversimplified and ignored large constant factors, but (I hope) erred on the safe side (lowering $r$), except for the "1/32 full scale" assumption which depends on the unstated schematic.

As often, defining the test is the hard part (to be continued).

---

We can't define a useful test of an entropy source without some model thereof. Argument: Assume a Cryptographicaly Secure Pseudo-RNG. Seed it once by a fixed constant. By definition of Secure in this context, the output is practically indistinguishable from truly independent random bits without knowledge of the constant. This is an insecure source, since it is easily predictable for one knowing the fixed constant. Yet no test exists able to give any indication of this.

Answer 2

So, you need to do a two-part work. First, you need to make 2+ hardware sensors of an entropy of a different kind. Use the Geiger tube counter [ http://kripton2035.free.fr/geiger-repositor.html ] , avalanche noise generator [ http://www.cryogenius.com/hardware/rng/ ] and when you'll make an ARM microcontroller act as a USB device - make an AM(NOT FM) radio and de-tune it and attach it to the controller's ADC input. Use STM32F4 chips if you need a cheap implementation. Second part of work - the algorithm itself. Use your mathematical skills, but at first I do recommend you to make all the sensors available as a raw inputs via COM port protocol via STM ARM chip. Use raw data to play with mixing algorithm on your PC and try to run some open randomness benchmarks aka "white noise benchmarks" ( use /dev/google to find them ). Feel free to contact me if You have any further questions - we're making a PCB now with full HWRNG onboard

Answer 3

http://www.syntax-k.de/projekte/fhreefish/

XORing the two bitstreams should be fine for mixing, by the piling-up lemma.

XORing the output of that with the PRNG in the library above (or any other CSPRNG) would provide whitening. Or just send blocks of the output to Skein (or Keccak if you can find a fast implementation for AVR...)

One thing to be sure you do is continually test for correlation of the two input bitstreams. Correlation would indicate undesirable external influence, and would keep the bias through the XORing of the two bitstreams. That's potentially bad.

Answer 4

The general answer for rolling your own cryptographic primitives in a production system is "don't do it" because it's hard and success depends on long experience. I think the same principle applies here.

If you're doing this to learn something about HWRNG systems, do it, but don't use it for anything that matters. If you're doing it to use it in a real system that people might rely on, I have to question why you'd try to reinvent the wheel when hardware RNGs are widely available and cheap. Even those I've heard grumblings of how good a RNG source they are.

Answer 5

I've actually built such a thing myself, using a design based on the circuit given here:

https://web.jfet.org/hw-rng.html

As described there I used a MAX232 line driver to get the > 18V in the schematic, hooked it up to an Arduino and managed to get some good random numbers at 115200 baud over the Arduino's USB/serial interface. I couldn't get the random data out any faster though. I did whitening by using the von Neumann algorithm (get pairs of bits, throw away pairs which aren't the same). Managed to get very good random numbers that passed FIPS 140-2 and Robert G. Brown's dieharder suite of statistical tests (successor to George Marsaglia's original Diehard suite). Took a good, long time to get enough random data from the circuit to do the dieharder tests though, which need many megabytes of such data, and 14 kilobytes per second seems to be the absolute limit of an Arduino's I/O.

I tried to get the same circuit hooked up to a PIC microcontroller to make a standalone module that goes straight to USB, but figuring out how to program and wire up the PIC to make it look like a USB device when plugged into a host computer was more work than I had time or money to do. Modern PCs are hell for interfacing simple hardware. Here's the circuit I used there, showing how to hook up a MAX232:

https://i.stack.imgur.com/wTRZC.jpg

There are good reasons to try to do this sort of thing yourself. The biggest problem with a hardware RNG is the matter of trust. How can you be reasonably certain that a "hardware RNG" you bought off the shelf isn't actually a phony one with output that statistically looks random, but is actually predictable to someone with the right keys? The only real way to make sure is to actually check the hardware and firmware. But how can you check anything if the hardware is sealed in epoxy, and full of tiny, inscrutable surface mount components?