You Can Now Tell Linux At Boot-Time If You Don't Trust Your CPU Random Number Generator

[jpg44]

That's far from safe, humans are notoriously bad at generating random input.

There are two parts to RNG, getting initial randomness (entropy), and then an psuedo RNG algorithm to make more random numbers out of that.

It has been the case random mouse movements or random banging on the keyboard were best available for entropy. I would suspect, though, keyboard input is not reliable unless the user is told to generate it randomly by banging on the keyboard. This is because hardware entropy is not found on consumer devices. A human CAN BE A good source of entropy if they are told to be non random and make a lot of random input!

There are other mechanisms for entropy, people have tried lava lamps, fish aquariums, hamster cages, background RF noise, etc.

[CochainComplex]

That's far from safe, humans are notoriously bad at generating random input.

...make them drunk ...then the outcome is better

[dweigert]

SGI used to use a camea pointed at a bunch of LavaLamps. I have some USB entropy generators, I sure as hell don't trust the CPUs at this point.

[bachchain]

If you're at the point where you're disabling parts of your CPU over trust issues, then you've already lost.

[carewolf]

I imagine the absolute safest bet is to always use multiple sources of entropy. I may be a bit of a layman when it comes to Random Number Generators, but my understanding is that it's easy to add entropy but very difficult (or impossible) to remove it. So the more you add, the harder it is to guess - even if you know the exact state of some of the entropy used.

Exactly even adding untrusted entropy can only improve security, not worsen it, so this patch is homeopathy.

[L_A_G]

yeah, right. Intel plants a hidden OS into their processors for decades and nobody bats an eye. But when a little talk about possible flawed random generators whispered - everyone looses their mind.

People were pretty pissed off or worried about it when it became publicly known and they came up with a way to disable it last year, so you're either not really up to date on the subject or just being an idiot. The thing about proprietary hardware functions like this is that you can never really verify that they are doing what they're supposed to be doing the way you can audit software, particularly open source software. Hence when they're related to something as security critical as RNGs, they are always going to a threat to at least some extent.

[DrYak]

yeah, right. Intel plants a hidden OS into their processors for decades and nobody bats an eye.

As pointed by other, it was never "hidden". I was at best not widely advertised because it initially mostly targetted sys-admins with lights-out-management features.
Then Mission Creep happenned to the point that this things is everywhere on Intel hardware and the machine can barely boot without it.

The recent fuss was about :
- yet another wave of exploits against that system.
- enthusiasts getting fed up with the above and finding way to strip it to the bare strict minimum necessary to get the system booting and disabling any other useless feature
- Some big names (including Dell) embracing the above as a solution to get rid of the security posed by exploits.

But when a little talk about possible flawed random generators whispered - everyone looses their mind.

I has been already demoed that you could upload a micro-code that intentionally disrupts the random generator in a way that completely kills all randomness

(at that point in time, the linux kernel mixed rdrand randonmess with more trusted randomness using a simple XOR instruction. The microcode patched the RDRAND in such a way that leverage that the trusted randomness was already waiting in a known register, so RDRAND always returned a number that once XORed gives a constant answer. That's partially why, since then, the entropy mixing has been getting a tiny bit more complicated than just stream XORing two sources on the fly).

It is provably attackable. Even if you use the "patched firmware where the ME engine only boots the main board and completely disconnects", you could be vulnerable if somebody tricked you into installing the malicious microcode update. (e.g.: say you're in a rush to install the mitigation into the latest Spectre du jour. But somebody has compromised the cache you use to install from).

There are two parts to RNG, getting initial randomness (entropy), and then an psuedo RNG algorithm to make more random numbers out of that.

That's for urandom (And also on BSDs), the non blocking one, used for non critical stuff (it seeds in some entropy in its pool when it can, otherwise it just keep generating pseudo numbers from the pool. After a long enough run between reseeds, if you've extracted enough numbers, you might do some analysis of this string of numbers, make an educated guess at the state of the pool and get a chance at guessing the next output that it will provide. It really becomes a (predictable) pseudo random generator - basically just like an random Mersenne Twister, but with a much more complex internal state than just a pair of large numbers).

random, the blocking API, only consumes entropy, and never generates anything out of thin air, there's only post-processing of the data to convert it into something more passable (e.g.: remove any bias that the true random source could have).. The number (should) always be non-predictable.
In practice they would be as long as there's enough entropy in the pool (that's why it can block while waiting for more entropy to arrive, otherwise if it didn't it could become eventually predictable like the above - to keep with my Mersenne Twister metaphore - it's like if after every couple of rounds, a pair completely new prime numbers where selected thank to the true random pool, so you can never get enough information to guess what these numbers are, it waits (blocks) until the prime number change again before continuing.).

In practice, the system used to respectively pseudo generate new numbers (urandom) or just condition the entropy (random) tend to be strong cryptographic functions (Chacha20, currently).
So even guessing urandom is hard in practice. (The "pseudo" part is only theoretically pseudo).


On BSD, and BSD-derived OSes (like Mac OS X), it's a bit different, they are betting the farm on their cryptographic function being good enough.
random *can* deplete the pool and thus devolve into something predictable, but the devs count on the cryptographic function being good enough to not actually get predicted in practice.

Linux doesn't count on this, and the system stops if there is risk that it's asked to provide number faster than the true random entropy is fed.

That's far from safe, humans are notoriously bad at generating random input.

It has been the case random mouse movements or random banging on the keyboard were best available for entropy. I would suspect, though, keyboard input is not reliable unless the user is told to generate it randomly by banging on the keyboard.

The trick is, it's not the actual input which is mostly relied on (too much bias in the keyboard sequence, and mouse input is basically "left-right-left-right").

It's the *timing* between the input event which is a lot useful because humans aren't able to precisely keep a rythm down to nanoseconds.

This is because hardware entropy is not found on consumer devices.

It is found on consumer devices.

The RDRAND-type instructions on most hardware use a true-random physical source.
Then they run it through several step on their crypto engine to condition it.
It's a micro-coded instruction (remember the oversimplified metaphore about modern x86 being a CISC micro-code running on a RISC hardware).
There's risk that depending on the current micro-code, the CPU might end up doing something nefarious during the conditioning step (do pseudo-random number generation based on a password known to an attacker, completely break the random function, etc.)

Even computer as old as the Commodore 64 used to have a true random generator (the joysticks' chip ADC reading electrical noise).
The PC is the exception here (only somewhat recent chipset and slightly more recent processors have started featuring it, your trusty old 386/486/Pentium doesn't have any such standard source built-in, it's up to you to add hardware to make up your own true source).

There are other mechanisms for entropy, people have tried lava lamps, fish aquariums, hamster cages, background RF noise, etc.

While we are at it, there are small USB device, some done in opensource fashion, that do use true physical random source to provide or complement the CPU's:

ChaosKey, OneRNG, InfiniteNoise, etc.

[kpedersen]

If you're at the point where you're disabling parts of your CPU over trust issues, then you've already lost.

Yep, I certainly feel that we have already lost. Now it is just damage control