Re: Handling of entropy during boot
On Tuesday, 18 December 2018 20:11:58 CET you wrote:
> On Mon, Dec 17, 2018 at 09:46:42PM +0100, Stefan Fritsch wrote:
> > There is a random seed file stored by systemd-random-seed.service that
> > saves entropy from one boot and loads it again after the next reboot. The
> > random seed file is re-written immediately after the file is read, so the
> > system not properly shutting down won't cause the same seed file to be
> > used again. The problem is that systemd (and probably
> > /etc/init.d/urandom, too) does not set the flag that allows the kernel to
> > credit the randomness and so the kernel does not know about the entropy
> > contained in that file. Systemd upstream argues that this is supposed to
> > protect against the same OS image being used many times [3]. (More links
> > to more discussion can be found at [4]).
>
> This is an issue which Debian should be deciding more than systemd,
> since the issues involved involve how the entire OS is packaged and
> installed.
I definitely agree with that.
> That being said, the issues involved are subtle.
>
> The decision to not credit any randomness for the contents of
> /var/lib/systemd/random-seed is definitely the conservative thing to
> do. One of the issues is indeed what happens if the OS image gets
> reused. And it's not just for Virtual Machines, but it can also be an
> issue any time an image is cloned --- for example, in some kind of
> consumer electronic device. Another question is that has to be
> considered is whether you trust that random-seed file hasn't been
> tampered with or read between it was written and when the system is
> next booted. For example, if the "Targetted Access Organization" at
> NSA, or its equivalent at German BND, or Chinese MSS, etc., were to
> intercept a specific device, and read the random-seed file, they
> wouldn't need to make any changes to the devices (which might, after
> all, be detectable). If the OS were to blindly trust the random-seed
> file as having entropy that can't be guessed by an adversary, this
> kind of attack becomes possible.
>
> Now, should Debian care about this particular attack?
I think some other questions should be considered first. Did Debian protect
from these attacks in the past? The answer is clearly no. Now, should we break
the systems of those people who keep their random-seed file secret and don't
clone their OS image, in order to offer some protection to other people? This
is really what we need to answer first, and in my opinion, we should try very
hard not to break the systems of those users. And I see no other way than to
credit the random seed file with entropy.
> If the kernel is only going to be used by a VM, you have to trust the
> Host OS provider, and if you're paranoid enough that you doubt Intel's
> ability to resist being suborned by the NSA, you're probably going to
> be even more concerned of the hosting/cloud provider from being in bed
> with the its local government authorities. So what the default should
> be for Google's "Cloud Optimized OS" is pretty obvious. The COS
> kernel trusts RDRAND, and this avoids any delays in the boot process
> waiting for the random number to be securely initialized --- because
> we trust RDRAND.
RDRAND is not the answer here, simply because not all architectures have it.
Do Raspberry Pis have a HW-RNG? I am pretty sure that they don't. My
cubietruck definitely does not. Therefore the question what to do with RDRAND
is not related to the question above, as it does not prevent breaking people's
systems.
> That being said, there are some thing we can do that can help
> regardless of what the default ends up being, and how we enable users
> or image installers to change the default. For example, at least
> every day, or perhaps sooner (and maybe once an hour if the device is
> powered by the AC mains) the contents of the random-seed file should
> be refreshed. The reason for that is that if the system has been up
> for weeks or month, and the user reboots the system by forcing power
> down or if the kernel crashes, or if the user is in too much of a
> hurry to wait for a clean shutdown sequence, and runs something like
> "echo b > /proc/sysrq-trigger", there is an increased chance that the
> random-seed file may have been snooped sometime in the past
> week/month/quarter.
One could also make it harder for an attacker to regenerate key material from
a system where he knows the seed file. For example, if there is a RTC one could
put the boot time and all serial numbers / MAC addresses that one can find into
an expensive function like PBKDF2 or bcrypt and feed the result to the random
seed. This way, even if the attacker has an approximate knowledge of most of
that information, he would still need to spend quite a bit of computing power
to get all the possible random seeds that could be used. If the number of
rounds in the function depends on timing, like do as many rounds as possible
in 1 second, things like the load of the VM host and the temperature of the
CPU will also play a role in the result. A sha sum of dmesg would probably
also help, because it contains a lot of timings that also depend on the load
of the VM host.
> > A refinement of the random seed handling could be to check if the
> > hostname/
> > virtual machine-id is the same when saving the seed, and only credit the
> > entropy if it is unchanged since the last boot.
>
> This is a good idea, but.... how you set the virtual machine-id is
> very cloud/hosting provider specific. Also, very often, in many cloud
> environments, the hostname is not set until after the network is
> brought up, since they end up querying the hostname for the VM via the
> metadata server.
The real solution for a cloud system is of course to use virtio-rng. If one
goes with the expensive function above, one could maybe skip it or at least
greatly reduce the number of rounds if virtio-rng is present. That way, cloud
providers would have at least some motivation to provide it, because it would
reduce their CPU load.
Reply to: