The Raspberry Pi’s Hardware Random Number Generator | Hacker News Reader

The Raspberry Pi’s Hardware Random Number Generator

scruss.com

136 pointsDanBC68 comments

It may well be that small hardware could be better for generating keys, as it is much easier to audit the total system, and I'd trust it more than an Intel processor with known remote patching capabilities.

If you're security-sensitive then it could be good having a small, dedicated system like the Pi, and make sure that your private key never leaves it.

If you don't trust a chip vendor's remote patching, there's nothing you can trust on the chip cryptographically at all.

Are there any possible realistic solutions to the trusted hardware issue?

Design and build it yourself?

Wait a second, wouldn't this statement imply that things like cert-pinning and PFS are completely useless?

Does skepticism of remote patching while trust of the original chip not protect you against being specially targeted if you assume that the chips aren't being wholesale manufactured with back doors built in?

Yes, if you think the NSA has backdoored all mainstream Intel chips, then certificate pinning and forward secrecy are not particularly meaningful.

That's not really what I was getting at though.

Let's say I don't think the NSA has backdoored all the mainstream fablines, but have reason to fear being individually targeted, and assume that the NSA has the power to coerce cooperation from Intel. In that case, would skepticism of post-purchase remote patching not be prudent?

(I mentioned PFS and CP because I perceive them as paradigmatically analogous to the threat model I described - suppose that not ALL of DDG's queries are MITM'd, and yours weren't when you first connected, but you're afraid of the NSA MITMing the queries coming from your connection starting at some date after you made your initial connection to DDG's server, when they start targeting you. If you trust the initial connection, then CP prevents that. Or, again, post facto to you starting to use DDG, the NSA could obtain DDG's SSL private key and decrypt your queries, but if you use PFS, then this is mitigated.

So in each case, it seems, whatever trust you have in the initial transaction -- be it a SSL cert presentation, the particular SSL sessions based on it, or just the purchase of your hardware -- being malice-free, then in each case the pinning/PFS/lack of remote patching abilities guarantees the extension of this trust indefinitely, and prevents the other party from going back after the fact and screwing you, it locks the trust in, so to speak.)

(I realized after typing this that I actually have no idea what specifically remote chipset patching refers to or how it's performed, but I assume that it's what it sounds like.) :-/

The article is a bit vague about what exactly they're trying to say. What was unexpected? I read it three times before I decided they're comparing a lousy homegrown software RNG to the Pi's hardware RNG, which turns out to be good. Yes? Why would that be unexpected?

The way I read it was that it is surprising that it is there at all.

Apparently a lot of android devices don't have one, and don't have time to collect pseudo random data for their software rng to make secure certificates when you boot it for the first time, which posses a security risk for android devices.

That's how I read the article in relation to recent news.

Actually most ARM processors do have a hardware RNG, just that few companies write a driver for them

The impression I got was that the existence of a hardware random number generator was unexpected.

The rest was just demonstrating that it works, and produces pretty reliable random output. In order to do that, they used a standard tool that tests randomness. But it's nice to make sure your randomness test tool is actually good; so using it on a known-bad RNG, and seeing that it does fail, is a good way to demonstrate that.

Especially confusing is when the article suddenly says "This is not random". But oh what it means is that the upcoming part of the article, on a completely different topic from the Pi, is not random.

I wrote the article.

I'm guessing not everyone on HN is a huge fan of “Strictly Ballroom”, as the title is a key quote for dance movie otaku. It was also a weak joke about testing for random numbers; I'm imagining a little subroutine in a constant state of surprise when it encounters the next random number.

While I'm not sure if I implemented it correctly, RANDU isn't some ‘lousy homegrown software RNG’. It was the standard RNG for IBM mainframes in the late 1960s.

Does anyone have a link for a spec for the RNG? Specifically, where does it get its entropy from? Couldn't find it in the source link. Only mention I could find is a vague mention of "thermal noise" which could mean anything.

I found the link on Reddit. They're asking similar questions.

So far Reddit hasn't got any answers; someone posted a link to a mailing list. Here's a similar link. (https://lkml.org/lkml/2013/3/24/144)

> This adds a driver for random number generator present on Broadcom BCM2835 SoC, used in Raspberry Pi and Roku 2 devices.

Here's a github for the blob source (https://github.com/raspberrypi/linux/blob/rpi-3.6.y/drivers/...)

It's a frustrating lack of information. :-/

(I posted here partly because of the Intel RdRand stuff the other day, but also RPis are fun and this could be a fun experiment.)

The only use for a binary blob that purports to a be a secure RNG is to feed it to /dev/random.

It isn't a binary blob, it is a blob of hardware gates. The RNG is interfaced with simple MMIO and just four memory mapped registers.

Some of these comments are particularly worrying:

    /* double speed, less random mode */
    #define RNG_RBG2X               0x2
    /* the initial numbers generated are "less random" so will be discarded */
    #define RNG_WARMUP_COUNT      0x40000

A black box random number generator with some numbers being vaguely "less random"? That seems like an exceedingly poor idea.

I'm not sure that's worrying. Remember, this is hardware. Hardware takes time to turn on and get into a steady state. Many hardware random number generators are based on thermal noise. But in order to get in the correct range for the values to flip, you need to wait for the circuit to warm up to operating temperature.

A classic source of white noise is to reverse-bias a diode or the base-emitter junction of a transistor[1]. This produces shot noise[2] though, which is independent of temperature, so I guess it's not what they are using.

[1] http://darrenyates.com.au/electronics/archives/40 [2] http://en.wikipedia.org/wiki/Shot_noise

The SoC datasheet has this to say about the RNG http://pastehtml.com/view/crkxyohmp.rtxt Which is not particularly helpful.

How it works is basically undocumented although I hear the RPi engineers believe it uses some sort of thermal noise as the source for entropy.

Broadcom do have HWRNG patents though...

https://www.google.co.uk/patents/US6748495 https://www.google.co.uk/patents/US8229108

Bah. Both those patents are just basically traditional linear feedback shift register systems, plus some fudging to try and make the results better.

A good number of Intel processors have hardware rngs.

http://software.intel.com/en-us/articles/intel-digital-rando...

Of course they're not on $35 boards, but the server machines you are using may already have this.

Intel's RDRAND is mentioned in the article as well, near the end. I suspect this article is doing so well because of the recent realization of Intel's involvement with the NSA, and the high potential for backdoors to be included in such a technology.

Broadcom is a similarly huge USA company in ARM computers & networking, are we sure they haven't been involved with the NSA either?

We can't be sure, but it should be much easier to audit a small system like Pi, rather than an Intel processor that, above all, can be remotely patched.

Intel processor can be remotely patched?! Then why did Intel spend $475m to fix the FDIV bug?

I'm going to go out on a limb and suggest that the FDIV bug - or heck, even the much more recent (1997!) F00F bug - might not be so contemporary or represent the state of the art of Intel processors.

Presumably they learnt from their mistake, the Pentium Pro was the first generation where the microcode could be updated.

(An ancient /. article, byte article it links to is dead: http://slashdot.org/story/00/10/27/126258/upgrade-your-penti...)

Huh? Much easier to audit a Broadcom SOC? Than what, auditing deliberately obfuscated hardware designs like the modern DirecTV smartcards?

The idea that it's in any sense easy to "audit" the Raspberry Pi's hardware is head-explodey. No you can't.

This is pure back-rationalization. You like the Raspberry Pi. You don't like Intel Corporation. So you come up with a reason why the R-Pi's hardware RNG might be more trustworthy than than the hardware RNG in a modern Intel computer. It's a crazy reason, not least because the R-Pi's core is produced by another giant semiconductor company.

Being naturally suspicious, I can't help wondering why the Broadcom chip on the Raspberry Pi doesn't have full technical specs publicly available. Seriously, why not?

Their customers are device makers, not small time developers or end users. They just don't want to disclose the information to people without various agreements (and hard sales leads) in place.

http://www.inquisitr.com/618772/raspberry-pi-tops-1-million-...

For this particular chip, you'd think they'd make an exception. But nooooooo.... Can't have those damned hackers actually knowing the register names, addresses and bit functions. That would be unthinkable.

Do hw rng's get a test suite certificate(NIST's?), like a Swiss watch, or like a optical sextant's `Certificate of Errors'? Tables of mean, standard deviation, etc, for expected physical dependent parameters(what: speed? temp? ...)?

Here are the NIST recommendations referenced in the FIPS 140-2 approved RNG appendix:

http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A...

Thank you. For the last few days, I've been looking for the The NIST Statistical Test Suite, not in C#, have you a link?

Sorry, I just found the above from a quick google search for "FIPS 140-2 rng" which I noticed referenced in the rngtester output in the article.

Is there a way to seed /dev/urandom and /dev/random from it?

Rng-tools [1], mentioned in the article, can use a hardware rng's output as input to the kernel's prng. However, it needs to be configured correctly to avoid potential problems [2].

[1] http://www.gnu.org/software/hurd/user/tlecarrour/rng-tools.h...

[2] https://news.ycombinator.com/item?id=6040975

For those looking for something a little less than formal perfection (whatever that really is), FM receivers can be a useful source of rands.

Discussion: http://www.ciphersbyritter.com/NEWS5/FMRNG.HTM

What barriers keep thermal random number generators from being widely available? Or are they actually?

Though I can't speak to they're adoption in actual hardware, thermal noise generators are apparently a common way to generate random numbers (https://en.wikipedia.org/wiki/Hardware_random_number_generat...). I would be interested to hear details on how the pi's generator works.

Sometimes they're not very good. Sometimes they're just very expensive.

There are a range of different hardware devices available on various plugin boards. And processors have started to include them as well.

Here's a very old (1997?) examination of 3 hardware devices: (http://www.robertnz.net/true_rng.html) and he has some nice information here too: (http://www.robertnz.net/hwrng.htm)

Here's my list of recent reading, not all of it relevant.

(http://csrc.nist.gov/groups/ST/toolkit/rng/documents/nissc-p...)

(http://www.paulm.org/random.html)

(http://www.cryptography.com/public/pdf/IntelRNG.pdf)

Build one yourself: (http://www.labbookpages.co.uk/electronics/hwRNG.html)

Here's a list of devices:

(http://www.westphal-electronic.com/)

(http://www.trng98.se/shop/index.php)

(http://www.comscire.com/)

(http://www.idquantique.com/random-number-generators/products...)

(http://www.letech.jpn.com/)

And someone upthread posted a link to EntropyKey.

Thanks, very helpful.

Perhaps this is a new application for the pi? A dedicated entropy appliance could be useful

Heh, there was a company that offered just such a beast, basically a network socket and an API to fetch a random number. I thought it was a really subtle joke (like that time I carried around a Diet Coke as my Halloween costume) but once people connected the dots between "Ok, you care so much about a cryptographically secure random number generator you buy an appliance that does nothing else, and then you talk to it over the network..."

As I was building IR beacons for mobile robots at the time, it led me to suggest an IR LED that was connected to a thermal emission source, then you could pick up random numbers by sampling the IR spectrum for a some period of time in your area. At least that way you don't know when the randomness was sampled (well not exactly), and your sniffer has to capture all radiated IR in all directions to ensure it has a complete history if it wants to back correlate it. Harder but still not as simple as just putting it in your machine. (which if you care enough you will do)

Similar in spirit to SGI's Lavarand [1]

[1] http://web.archive.org/web/19971210213248/http://lavarand.sg...

Awesome. Thank you for sharing that.

You'd use radioactive decay:

http://www.fourmilab.ch/hotbits/

You could probably do it with the radioactive source in a smoke detector.

Check out http://www.entropykey.co.uk/

I have one of these, they work well and are relatively inexpensive. I am particularly impressed by the design.

For random dice generation: http://gamesbyemail.com/News/DiceOMatic

It might even replace the use of atomic vector plotters suspended in a nice hot cup of tea.

What I found unexpected about the Raspberry Pi, was that the CPU chip is closed - very little data available on what's in it. Suddenly 'discovered' hardware RNG being a case in point.

That's why I use the BeagleBoard.

Here is my proposed RNG for network devices that don't generate much entropy of their own:

  strace -Tiv -ttt nice curl -Lv --raw $URL 2>&1 | shasum | dd bs=1 count=2 2>/dev/null

Possible values of $URL might be https://news.google.com, https://en.wikipedia.org/wiki/Special:Random, or the Twitter Firehose. :)

If you are connected to the internet, why not get your randomness from http://www.random.org/ ?

This thread is a joke, right?

What's a joke?

There is nothing ridiculous about using network timing as random, that's how /dev/random already works.

There is nothing ridiculous about using random.org, though that should be https.

> There is nothing ridiculous about using random.org, though that should be https.

Everything is wrong about this.

• You can not trust SSL to protect your source of entropy.

• You can not trust an external, unverified source of entropy.

Pretend for a moment that you have isolated hardware with no trusted random sources. And this hardware already depends on large secret binary blobs to run at all. At this point trust is already hard, and random.org is a hell of a lot better than nothing. If you mix network jitter with external randomness sources that's just about the best possible job you can do. Neither half is perfect but they help.

Every linux distro has /dev/random as a good, cryptographically secure source of randomness that is refilled by as many sources as possible. It can and has been audited by many developers to ensure this. The main issue you will have is having multiple identical instances of a linux VM built from a single source, or something like that.

Alternatively, you suggest a sole remote source over a public internet connection. Assuming an eavesdropper, the source could be compromised or the strength of the resulting cipher be reduced. Assuming a malicious entity with network control, you're pretty much screwed.

If you don't trust your hardware, you can't be working with encryption.

Software can only do so much without good hardware sources. A small embedded box, barred from networking, has roughly zero entropy available. But if you combine microsecond network timings, only vulnerable to local attack, with third party random data that is safe from mitm, you get resonably good random numbers. Don't use it to generate a root certificate, but it'll work for general purposes.

> Don't use it to generate a root certificate, but it'll work for general purposes.

"General purposes" is exceedingly hard to quantify.

How about this: it's much easier for an attacker to physically compromise the device than it is for them to attack your network AND attack random.org.

Is that not good enough? It's about as secure as your average desktop. You can't make a device more secure than the access to it, and there is no such thing as perfect security.

I was waiting for someone to offer offsets to Pi. (Pick a number, count that many digits of Pi, start using the rest of the digits as your RNG numbers.)

So OK, the Pi has a thermal RNG. Next question - does this: http://www.damninteresting.com/random-event-generators-predi... (and google for related articles) supposedly only happen for some types of hardware RNGs? Nuclear decay based RNGs? Or all types - thermal, semiconductor shot noise, wind-chimes or whatever?

Sounds like a candidate for large scale experiment.

Reply on news.ycombinator.com