LWN: Comments on "Random numbers for embedded devices"

Definitely not speaking for my employer, but here goes..

nix — Sat, 18 Aug 2012 21:37:19 +0000

Really? That noise is often fearfully non-random and highly correlated, and anyone with a radio transmitter or indeed any electrical device can introduce new patterning. It's... not a good noise source on its own (though obviously it contains noise, so it could probably contribute *some* entropy.)

Definitely not speaking for my employer, but here goes..

kjp — Sat, 18 Aug 2012 16:32:03 +0000

Use an FM or TV tuner and use the white noise for entropy. I'd trust that.

Definitely not speaking for my employer, but here goes..

mina86 — Sun, 05 Aug 2012 04:14:06 +0000

We should trust them because we all know that Intel would never release buggy hardware like random number generator or, oh I don't know, a floating point unit.

MAC address as random input?

farnz — Thu, 26 Jul 2012 12:18:36 +0000

More accurately, it adds an extra IP that changes regularly; you still have the permanent IP that you would have if you didn't enable privacy extensions, but you also have a temporary IP that changes, and that is used in preference to your permanent IP for outgoing connections.

The idea is that if you give me your permanent IP, I can connect to you. If you don't, the only IP of yours I know about is your temporary IP, which changes regularly - so while it's fine for the duration of communication you initiated, it's not useful in a few days time.

MAC address as random input?

nix — Thu, 26 Jul 2012 08:01:06 +0000

Quite. This is one reason why the BSDs et al don't bother with an entropy estimate: as long as there's *some* entropy, you're fine, and if it's wrong, you're very much not fine.

(I like the entropy estimator for a much more selfish reason: collecting randomness from some sources can be quite expensive, and we can use the entropy estimator as a high-water-mark to indicate that there's no point whatsoever providing more randomness because nobody's read much since we last shoved a bunch in. We could do much the same thing with a simple counter of "bytes read from /dev/*random by other users since last entropy fed in by a /dev/random writer", but that leaks information about those other users and might be considered ugly. The BSDs don't have a counter like this, and it makes the ekeyd ridiculously costly on those platforms because it has to pull entropy from the key and remix it for /dev/random all the time, even if the system is otherwise totally idle.)

MAC address as random input?

pjm — Wed, 25 Jul 2012 21:37:48 +0000

Another thing to note is that it doesn't hurt to add lots of attacker-known data to the pool, so long as there's at least k bits of attacker-unknown data also in the pool. So using the MAC address by default is fine if there are some systems where attackers don't trivially know the value.

MAC address as random input?

kleptog — Wed, 25 Jul 2012 18:45:38 +0000

Note that the default varies by implementation. Various versions of windows default to privacy extensions.

Privacy extensions means your IP changes regularly, usually once a day. For servers you don't want that, but for client PCs the tradeoff is different. If it bugs you you can set the IP address yourself.

Note the link-local address always includes your MAC address, but that address never leaves the LAN, and everyone on your LAN needs your MAC address anyway to talk to you.

Definitely not speaking for my employer, but here goes..

nix — Tue, 24 Jul 2012 16:59:50 +0000

Alternatively, we could take the unwhitened output and just feed it into /dev/random (since the /dev/[u]random entropy pools will take care of doing the whitening for us).

This is exactly what the Entropy Key's daemon does. There's no point in engaging in whitening and the like, since the key already does all of that (mixing together the output of two RNGs, making sure they are not correlated, and the like) and the daemon just asks the key 'are you broken?' and stops feeding entropy into /dev/random if it says it is.

MAC address as random input?

BenHutchings — Mon, 23 Jul 2012 19:14:56 +0000

By default, the local part of the IPv6 address is the MAC address with 16 constant bits in the middle. There is an option to use 'privacy extensions' which means the local part is randomised (sysctl net.ipv6.conf.all.use_tempaddr; Documentation/networking/ip-sysctl.txt).

Definitely not speaking for my employer, but here goes..

tytso — Mon, 23 Jul 2012 17:19:26 +0000

Of course there could be hardware products that would meet an independent auditability criteria. It would require a completely open hardware design where the only thing that is done in hardware is a noise diode, and the minimal circuitry to convert the analog signal into a digital one. A quick google search reveraled something like this that could perhaps be used as a basis of such an implementation:

https://mywebspace.wisc.edu/lnmaurer/web/minirng/minirng....

Add a simple USB interface so it can be plugged into a laptop or a server, but the key point is that it's a open hardware design, using basic commodity parts whose operation can be easily verified.

Then what we do in open source software is all of the hard work of analyzing the raw output of the hardware circuit, to make sure it hasn't failed, and then all of the whitening using AES, etc. Alternatively, we could take the unwhitened output and just feed it into /dev/random (since the /dev/[u]random entropy pools will take care of doing the whitening for us).

Random numbers for embedded devices

tytso — Mon, 23 Jul 2012 17:14:14 +0000

The expensive (i.e., cryptographic) operations are already in get_random_bytes(). What we do amortized across multiple interrupts is a few xors, a rotate, and some memory accesses into a per-CPU memory pool. So the bulk of the cost is already paid by the processes that need random numbers.

MAC address as random input?

Max.Hyre — Sat, 21 Jul 2012 22:42:10 +0000

This may just exemplify a little learning being a dangerous thing, but doesn't IPv6 put the MAC address in the packet header? If so, ungood.

Definitely not speaking for my employer, but here goes..

nix — Sat, 21 Jul 2012 13:48:25 +0000

Precisely my point. Or, rather, they do meet my needs, but my needs do not include having this stuff contribute to the entropy estimate. I can't trust that it is truly entropy. That doesn't mean it won't help keep your random numbers look random, of course: it still mixes into the pool.

Random numbers for embedded devices

PaXTeam — Sat, 21 Jul 2012 08:38:10 +0000

concerned/interested readers might want to check out the latent_entropy plugin featured in the latest PaX patch. the idea is very simple: each basic block of boot-only functions is instrumented to compute a random function (based on add/xor/rol, hi Halvar :) whose output is then fed into the input/nonblocking pools after each initcall. tests show that even an allnoconfig amd64 kernel under qemu produces a few bits of entropy. at this point i'm interested in real field tests with embedded systems, so feel free to contribute :).

Definitely not speaking for my employer, but here goes..

dlang — Sat, 21 Jul 2012 05:56:06 +0000

you don't have to 'wait' if you are willing to trust the /dev/urandom source, you only have to wait if you insist on getting a 'guarantee' that you are getting true randomness as opposed to just the best that the system can do.

The system will use the hardware RNG to modify the output of /dev/random and /dev/urandom, the only thing is that it doesn't increment the "guaranteed randomness available" counter.

realistically, I don't think it makes sense for anyone to depend on /dev/random and the 'available entropy' counter, the few cases that have super strict randomness guarantee requirements should just have a separate source of randomness

think of this as improving the quality of /dev/urandom rather than failing to get the full randomness of the hardware RNG

Definitely not speaking for my employer, but here goes..

DavidJohnston — Sat, 21 Jul 2012 03:22:04 +0000

Then I suspect no hardware product will meet your needs.

Definitely not speaking for my employer, but here goes..

DavidJohnston — Sat, 21 Jul 2012 03:11:41 +0000

>Could you provide links to the papers, algorithms and design source code ?
The design source code isn't available. There's a lot more to designing chip RTL at 22nm than just the implementation of the algorithms, so I'm not at liberty to reveal the source code.

I'm working towards making some C code available that models the design. This served as part of the design validation (it helps show model equivalence and calibrate entropy estimates) but could also answer a lot of the detail questions people have about the nature of the raw entropy.

Patrick OKeef has done an efficient job of linking to all the information that is out there. https://sites.google.com/site/intelrdrand/references

You might find Jesse Walker's talk, particularly the stuff at the end on the Ornstein-Uhlenback process (which nicely models ES) informative. http://www.ists.dartmouth.edu/docs/walker_ivy-bridge.pdf

The Intel Developer Forum talk should be out there somewhere. If not I can send it.

These guys performed external review. They did get to see the source code and had access to raw data and the engineers. Fortunately for us they didn't find anything too horrendous. The paper is here: http://www.cryptography.com/public/pdf/Intel_TRNG_Report_...

I described the details of the conditioning algorithms here: http://software.intel.com/en-us/forums/showthread.php?t=1...

There's more on the way, but we have to write it first.

Definitely not speaking for my employer, but here goes..

nix — Fri, 20 Jul 2012 12:39:52 +0000

Links to proof that what's in the CPU matches that design would be necessary too, before this can be trusted. The point about those sources that currently contribute to the entropy estimate is that they are only those sources which an external observer can see cannot be controlled or predicted by an attacker. Something impossible to inspect buried inside your CPU by a major corporation is... not worthy of the same degree of trust.

It's not even worthy of the same degree of trust as, say, the Simtec Entropy Key, because at least Simtec is a small company and you can in theory get to know the people who did the work and become as sure as you wish that they did not get nobbled by the secret services -- though even that entropy is somewhat less trustworthy than environmental entropy not derived from a necessarily-opaque IC. Intel? It's a behemoth, and we know it therefore does business with all sorts of people. Who knows what pressures may have been brought to bear?

This isn't saying that I think pressures *were* brought to bear on Intel to nobble their RNGs -- it's just that had they *been* brought to bear, the design would have looked just like we see now (as the nobbling would happen later in the process, with less risk of public exposure), and the CPUs that resulted would have looked from the outside *just like the ones we see now* except that their 'random' numbers would be predictable by a suitably-privileged outside attacker. So we cannot distinguish between those cases, so cannot grant the entropy derived from those CPUs the same definitely-unpredictable status as entropy derived from environmental noise.

(This is not, of course, unique to Intel. I consider uninspectable RNGs and binary crypto blobs from all vendors untrustworthy, but larger vendors are probably less trustworthy than smaller ones, regardless of the quality of their engineering or employees, simply because they are easier for the security services to quietly nobble.)

Definitely not speaking for my employer, but here goes..

Aissen — Fri, 20 Jul 2012 08:55:40 +0000

Compared to the treatment of most CPU logic, Intel has been extraordinarily open with the design on the RNG, exposing the full algorithmic details and opening the design for external review. I've yet to see an comparable expositions of why we should believe the Kernel entropy gathering code achieves a well defined min-entropy.

Could you provide links to the papers, algorithms and design source code ?

Definitely not speaking for my employer, but here goes..

DavidJohnston — Fri, 20 Jul 2012 06:04:58 +0000

The argument that the random numbers from the RdRand instruction cannot be trusted, compared to the kernel RNG algorithms that extract entropy from interrupt timing doesn't really hold water. Especially in light of the recent studies showing the lack of boot time entropy.

To suggest that users 'wait' for entropy to be available from the kernel when their platform provides copious amounts of entropy before the first instruction has executed suggests that it is the kernel that is the problem, not the platform or user behavior.

When a user has paid for and deployed a RdRand capable machine that solves their boot time entropy problem, it is not in that user's interests that a paranoid design philosophy in the kernel leads to the user getting no entropy, rather than the 150MB/s+ that the platform can provide. They need the random numbers, not advice on who to trust and they should get those numbers if they trust the platform they run their software on.

Lack of entropy has been a problem that has dogged computer security for decades. Now that we are in sight of a comprehensive solution in hardware, the right approach for the kernel is to facilitate high bandwidth access to entropy through the /dev/[u]random interfaces, drawing from the underlying hardware.

The right approach for application software is to dispense with slow, large attack surface libraries and kernel calls and use the instruction based sources directly, rendering themselves immune from a large class of side channel and memory based attacks that can be raised against software entropy extractors and PRNGs. Existing and new software might continue to use /dev/[u]random, but where security and performance are a goal, RdRand and AES-NI are simply better.

The primary goal of RdRand is to make the platform entropy problem simply go away. In time it will, but we are in a position to speed the process by making the right design decisions, so the non cryptographers stand a chance of their security software working for them.

Random numbers for embedded devices

pr1268 — Fri, 20 Jul 2012 00:53:57 +0000

That might make get_random_bytes() very expensive (relatively speaking). My suggestion is that the mixing operations happen only when the entropy pool gets below a low-water mark (but then again perhaps this might make the RNG a little more vulnerable; I'm not totally sure about this).

Random numbers for embedded devices

cpeterso — Thu, 19 Jul 2012 15:19:12 +0000

Can the expensive mixing operations be moved to get_random_bytes(), so the mixing is only done when needed and the cost is paid by the caller, not interrupt handlers?

Random numbers for embedded devices

ilmari — Thu, 19 Jul 2012 09:50:13 +0000

The "not adding entropy" refers to not incrementing the kernel's estimate of the amount of entropy in the pool, since the data being mixed in isn't really very random.

Random numbers for embedded devices

rbrito — Thu, 19 Jul 2012 03:33:21 +0000

I just skimmed some of the patches (not the rest of the code, which may mean that I'm missing context), but what is reason for having the pool initialized to something while not adding entropy, as mentioned in the commit message of Ted's patch number 4?