This article is more than 1 year old
Entropy drought hits Raspberry Pi harvests, weakens SSH security
Hotfix posted online to shore up Raspbian key generation
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 generator by default, according to a bug report posted to the Pi forums. Ideally, this generator should pour unpredictable numbers into a so-called entropy pool from which cryptographically secure numbers can be obtained – but this doesn't happen, and so the operating system's algorithms end up producing rather predictable "random" numbers.
Crypto keys crafted from these predictable sequences during the machine's first boot-up can be recreated by eavesdroppers, and used to decrypt intercepted SSH connections to reveal login passwords and snoop on terminals.
If the hardware generator was seeding the pool in the first place, the generated keys would be vastly more secure. Here's what the bug reporter had to say:
Raspbian (2015-11-21-raspbian-jessie.zip SHA1: ce1654f4b0492b3bcc93b233f431539b3df2f813) doesn't enable hardware random number generator by default. This causes generation of predictable SSH host keys on the first boot. As soon as the systems starts up systemd-random-seed tries to seed /dev/urandom, but /var/lib/systemd/random-seed is missing, because it hasn't been created yet. /etc/rc2.d/S01regenerate_ssh_host_keys is executed, but /dev/urandom pool doesn't have that much entropy at this point and predictable SSH host keys will be created.
The issue is due to be fixed in the next Raspbian image release, we're told, and users should ensure they upgrade when that's available. In the meantime, people worried about the security of their SSH servers should regenerate their host keys after seeding
/dev/urandom with the hardware random number generator in the Pi's system-on-chip processor.
The commands to do that, and a hotfix patch to address the issue, are given in the aforementioned forum post.
“This is something that’s easily fixed but then relies on Raspberry Pi users to be aware and update their systems,” said Patrick Hilt, CTO of two-factor authentication biz MIRACL (previously known as CertiVox). “If they don’t, it creates a potential weak spot.”
As one person on the message board notes, this issue is not specific to the Raspberry Pi, nor Raspbian; it's just that systems like the Pi are more susceptible. Many Linux distributions stockpile random seed data during installation, and then use that to prime the pool during first boot-up, but Raspbian doesn't work that way – it starts up ready to go straight from the SD card, and thus suffers from low entropy.
As Hilt explained it to us, by the time most Linux systems have finished downloading packages and spinning disks during the install process, they've built up enough entropy – enough random numbers from all that noise – to generate secure keys.
“On a server or desktop computer, entropy isn’t needed until later during system startup and use,” he said.
“By then, based on network traffic and/or user input and other hardware events, there is usually plenty of entropy to go around. In embedded systems the situation can be different especially if random numbers are accessed early in the boot process, and that’s what we’re seeing here with Raspbian.
“It’s imperative, especially in the Internet-of-Things era, for embedded systems developers to be security conscious and design systems in such a way that random numbers are not needed until there is enough entropy and/or the Linux kernel entropy pool is seeded from a hardware random number generator if it is present in the system." ®