Entropy drought hits Raspberry Pi harvests, weakens SSH security Raspberry Pis running Raspbian – a flavor of Debian GNU/Linux tuned for the tiny computers – potentially generate weak SSH host keys. This gives man-in-the-middle attackers a sporting chance of decrypting people's secure connections to the devices. The November 2015 release of Raspbian does not use a hardware random number …
So - why is the key-generating script using /dev/urandom (which is susceptible to this problem) instead of /dev/random (which will refuse to yield data unless and until there is sufficient entropy)?
It should be well-known that something as cryptographically sensitive as key generation *must* use /dev/random. Not only would that have avoided generating the weak keys in the first place, but the delay on first boot (until sufficient entropy was available) would have highlighted the lack of HWRNG support.
Completely irrelevant link. OP is correct. When doing something as critical to get right as generating the hosts SSL keys, it doesn't matter if the process blocks for five minutes while the kernel waits for sufficient entropy to give a truly random number.
SSL host key generation should obviously be using /dev/random. Either it responds instantly with good randomness (identical to the best case scenario when using /dev/urandom) or it blocks and eventually responds with hopefully good randomness, given the kernels conservative estimate of entropy.
Using /dev/urandom with a sufficiently seeded pool gives an identical outcome to /dev/random (instant return with good randomness) but in an insufficiently seeded pool, now returns instantly and leads to a predictable key.
File a bug with SSL generation, make it use the correct source of randomness.
"something as cryptographically sensitive as key generation *must* use /dev/random"
"When doing something as critical to get right as generating the hosts SSL keys, it doesn't matter if the process blocks for five minutes while the kernel waits"
The link explains why Chromatix is wrong and you don't have to use /random every time. And it backs its claims with reasoned argument and expert support. It also explains that there are lots of people who don't understand the process and are vocal about it in forums even if they have no better argument than "it should be well-known".
It is therefore most relevant and, correct or incorrect, much more convincing than a blind assertion or syllogistic fallacy like the AC uses (host key generation requires X, Y is key generation therefore Y requires X).
"Using /dev/urandom with a sufficiently seeded pool gives an identical outcome to /dev/random (instant return with good randomness) but in an insufficiently seeded pool, now returns instantly and leads to a predictable key."
Since urandom and random both use the same PRNG, the same broken PRNG in this case, it makes no difference whatsoever how much entropy you seed it with once you have enough. It'll be equally valid or equally broken either way, one is just much more flexible than the superstitious alternative. (And "enough" occurs early in the boot cycle, long before any certificates are generated.)
But you still need to wait for enough entropy after booting, and on the BSDs that's what happens - urandom and random are the same, they both wait for enough entropy after booting then they never block.
The closest thing on Linux is random which also waits for enough entropy after booting (unlike Linux's urandom) but then unfortunately blocks from time to time just because.
"It should be well-known that something as cryptographically sensitive as key generation *must* use /dev/random"
Cause of weirdest "bug" (actually a feature) I've ever seen. Using a Linux Citrix client, connection to server timed out. Unless I got impatient and wiggled the mouse like crazy --- then it worked. Took me a while to figure out what was happening ... :-)
This wasn't an issue before systemd was shoved into everything. Prior to this, the random seed used for /dev/urandom was generated at installation and regenerated at each boot after /dev/urandom was seeded with the previous iteration. systemd - claiming to be a superior means of booting your computer - apparently doesn't do this.
I'm not even sure why systemd is hijacking the generation of this random seed anyway. It's entirely unnecessary, and apparently an inferior implementation on top of that.
Using a hardware random number generator isn't an answer, because nobody knows if those are cryptographically secure. If they aren't, then you can't fix them with a software patch. You also don't know if someone has nobbled it with a cryptographic back door. In other words, from a security standpoint, they're no improvement over the software methods and may possibly be much worse. Current thinking in the Linux kernel group is to blend hardware and software methods together. Software methods can be audited for security, while hardware methods can re-generate themselves faster.
The specific problem here is related to the way that Raspbian is installed. It is however a much wider issue than that. It's a matter of fundamental mathematics that affects all operating systems under the right circumstances. If you are not careful, you can suck the "pool" of random numbers dry if you use them faster than they are generated. This is something that people doing server programming, embedded systems, and running anything in a VM have to be particularly careful of, but which most developers have never heard of.
Think for example of all those VM images you are running as part of your server consolidation project. Are the "random numbers" they are getting random enough, or are you getting something equivalent to what is happening in the story, leaving you with weak cryptographic keys? It's something to think about.
@Anonymous Coward - "Can't hardware RNGs be physically inspected and run through assorted tests?"
How are you going to physically inspect the hardware RNG built into the CPU in your PC or server? Anyone can download the source for Linux and inspect it, but pealing off the package on a sample of CPUs and reverse engineering what's inside is a huge task and not really practical.
You also can't really test if the numbers are truly random. You might think you could just take a sample of numbers from them and compare them for randomness, but according to the mathematicians who knows this sort of thing, it won't work. They might look random, but they could be slightly biased in a non-obvious way, but which an attacker who had the algorithm could break. Think for example if the NSA had Intel put a cryptographic back door in each Intel CPU. They wouldn't make the output easily predictable. Instead, they would make it weaker in a way known to them which would allow them to break keys with less effort. That is, they would effectively have part of the key and just have to use brute force to crack the rest.
This is why the Linux kernel developers have said they cannot rely completely on the hardware RNG. They mix hardware and software methods together. Software methods are more secure, while hardware RNGs can output new keys faster. If you mix the two together, you get what amounts to the best of both.
Some people have built hardware RNGs which use basic physics and which plug into a USB port. Those are probably as good as you can get. As for the ones built into CPUs, even if they don't have a deliberate back door in them, nobody really knows if they are free of design defects which weaken the randomness of the output.
"How are you going to physically inspect the hardware RNG built into the CPU in your PC or server?"
Get another one from the same lot and use whatever physical methods are available: decapping, X-rays, whatever. Barring a state-level custom job (which would then take everything into consideration and basically be directly up against The Man, who would be able to take counter-countermeasures), one should be enough to inspect the whole line due to economies of scale, so the risk of tampering with a production model is the fact some resourceful paranoid only has to be lucky once.
Therein lies the problem. You rather glossed over just how difficult (hence unlikely) "decapping, X-rays, whateve"ing a modern high density chip, to unpick the workings of its (p?)RNG actually is, there AC. When/if it's ever done it'd be nothing more than a moot "oopsie, little errata there, still, no harm was done" occurring many years to late to serve any useful purpose.
Using something like a Lava Lamp (done back in the 1990s, in fact) as a hardware RNG generator (yes, that particular example has issues) addresses the question of "black box" hardware. I'm sure that there are other, open source based hardware RNG standards that could be developed... the idea that hard-coded closed source silicon is the only reasonable source of randomness is false.
Well in the IoT there is no reason why a lava lamp couldn't be a RNG generator for all devices in a 'house', yes it introduces a pairing requirement, but that isn't a real stumbling block because any new IoT gismo will have to be paired with a management system...
"May possibility be much worse"
Not so. If you XOR a random byte with any number of non-random bytes, you will get a random byte. You can cat text, the complete works of Shakespeare, or whatever, to /dev/random and not "harm" the entropy. Dual_EC_DRBG was never a threat to Linux because it wasn't the only source of entropy.
Raspberry pi has a true hardware RNG based on thermal noise amplification, but it's slow as balls.
@Dan 55 , I like understated way in which you express your "trust" into security aspect of design of a common ADSL home router
On more serious note, using randomness source not designed for strict cryptographical criteria in such context is recipe for poor outcome. And if DHCP server embedded into common ADSL home router does indeed fit into such criteria, then I what I can see behind the window are not birds, but miniature flying pigs with beaks attached.
Go off laughing about how a broken random number generator is such a huge fail, and debian, raspbery pi foundation are all clueless idiots, post xcd cartoons about random rolls of dice etc etc, like everyone did when there was a bug in Sonys random number generator?
It's seems not, as this is a hipster project, not a product with Microsoft stoking the fires of fanboy hate.
Don't own a Pi but isn't the OS image typically burned to SD by a wee app/script called "n00bs" (or something similar)?
If so, WTH isn't N00bs harvesting a great slug of entropy from wherever it can claw it on the system on which it is run, stirring it about a bit perhaps, then dumping it into /var/lib/systemd/random-seed as it fashions the boot medium? Shirley "we don't run a typical installer cos it's an image dump see guv" is a piss poor excuse for whatever installer you do provide not doing its job?
Depends on how the installation is done. If it's done by a block image, then you'd have to inject the seed into the image in a location that may not be consistent; IOW, that can be dangerous. That's one reason Android updates from Lollipop and up (I think; definitely from Marshmallow) use block images; they're more tamper-resistant.
Could be FAT. Could be ext(x). Could be imaged using a system that doesn't grok the image's filesystem. That's the thing with these block images. They work below the filesystem layer. And you can't trust a first-run situation, either, because it could be headerless, isolated, and basically without any reliable source of entropy with which to seed an RNG (and since we're talking first boot from a cold-boot situation, all the hardware including the CPU will be starting from a zero state making them useless for entropy).
... depends on how your RPi got Raspbian Jessie installed.
AFAICT this is only a problem if you wiped the SD card and installed Jessie from scratch.
I didn't do that. Instead, I tweaked the apt configuration so it pointed at jessie instead of wheezy and then then did an normal upgrade (full procedure described below). If you've done the same, you won't see this problem because the copy of /var/lib/systemd/random-seed that was used by Wheezy is still there and will be used by Jessie when needed.
For those who need it, here's the upgrade procedure I used.
1 Modify the file /etc/apt/sources.list. Change "wheezy" to "jessie" in the first line, so it reads
"deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free rpi"
2 Modify the file /etc/apt/sources.list.d/raspi.list. Change "wheezy" to "jessie" in the first line and add " ui" to the end of that line, so it reads
"deb http://archive.raspberrypi.org/debian jessie main ui"
3 Create the directory /home/pi/.config/autostart by typing "mkdir /home/pi/.config/autostart" in a terminal. (Note the . in front of config.)
4 Type "sudo apt-get update" in a terminal to update the apt index files.
5 Type "sudo apt-get -y dist-upgrade" to start the upgrade process. This will take a couple of hours.
Reboot once the upgrade has finished you will see several messages about "Calling CRDA to update world regulatory domain". Wait until these stop and then login at the command prompt as the pi user. If the GUI doesn't start automatically, type "startx" at the command prompt. The desktop will take several minutes to launch as files are updated; the screen will go black, but just wait for it to finish.
Once the desktop has loaded, open a terminal window and type "sudo apt-get install rc-gui alacarte". This installs the new packages - respectively, the new GUI version of raspi-config and the Alacarte menu editor.
>... depends on how your RPi got Raspbian Jessie installed.
Whether this is a problem or not, depends upon what exactly you are using your RPi for; remember the RPi was put together as an education tool that will be frequently turned on and off (hence reboot time becomes important) and not as a commercial IoT platform...
A 'random' number generator that relies on something called system entropy that may or may not be time dependant and may or may not depend on how much the user has wiggled the mouse is NO FUCKING USE TO ANYBODY. Fix the random number generator, don't blame the devs for holding it wrong.
So what's the solution? A hardware generator can be subtly subverted, and a software one can't work properly from a zero state. Since these are imaged, not installed, possibly on a system that can't understand the imaged filesystem, it would be very difficult to inject a seed. And you can't trust the first boot since it could occur in a low- or even zero-entropy (zero as far as the system can employ) environment.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
