TLDR; PRNG seeds in the cloud are somewhat predictable. Because sshd generates the keys on boot it's possible to guess the private key on a fraction of the cloud hosts.
Ubuntu 14.04LTS solves the problem by adding a new source of entropy. They add a early-boot (before sshd) service that fetches data from an external server. In short: `curl http://some-server > /dev/urandom`
EDIT: Looking for the default server but launchpad seems to be down. Ideally it would be a trusted source like the cloud provider themselves.
Nope. Linux systems don't need EGD: the in-kernel gatherers do everything the user-space EGD daemon would, and better. The problem they're aiming to solve is that some things (like first-boot ssh key generation) are running so early that the in-kernel gatherers haven't produced anything yet, so a user-space daemon couldn't do any better.
(disclaimer: I wrote EGD)
This sort of "early remote entropy fetch" could work well in an EC2-like environment, where there's a mature box with its own well-seeded entropy pool nearby (e.g. the physical host of the new VM), close enough that we can talk to it without an eavesdropper hearing the seed.
We really do need network-proximity for this: encryption wouldn't help you. If the attacker knew the complete state of your client, they could deduce your "random" DH session key, and then learn the seed you were trying to transfer. You either need an unobserved conversation, or a pre-shared secret (and if you have that, you could just use it as the seed).
> We really do need network-proximity for this: encryption wouldn't help you.
That was my first thought on reading the article - they do connect via ssl/tls to a daemon and get 64 bytes of entropy. But how much good entropy would you need to complete a secure tls handshake?
Granted, it should be less than for generating some private key(s) -- but this still feels a little (too) hand-wave-y for me.
I certainly appreciate the effort (both writing the simple client and server, and highlighting the problem (more)).
Looks like a great thing to run on vm hosts, though.
> That was my first thought on reading the article - they do connect via ssl/tls to a daemon and get 64 bytes of entropy. But how much good entropy would you need to complete a secure tls handshake?
It certainly doesn't mitigate the attack completely, but it does reduce it to a narrower window of time, so I think that's a step in the right direction.
Before - given 1000 machines in EC2, running the same AMI, it seems like you have a better-than-expected chance of predicting the SSH host keys (or other sensitive "random" data that was generated on first boot) of a fair number of those machines.
With this - given those same 1000 machines in EC2, you would have to eavesdrop on the network traffic of each one, at the time of its first boot, to have a reasonable chance of guessing the state of the internal entropy pool.
Seems like a reasonable[1] approach would be to have a custom handshake using pre-generated pre-shared secrets (using eg AES-GCM ?). You'd probably want separate keys pr vm though -- which I suppose defeats the point (If you can do that, just give each vm its ssh/ssl-key(s) from "outside"...).
Perhaps it is possible to do something along these lines with TLS-PSK? If we assume a goal of no random session keys for the setup, I guess it would still be possible to a) sniff the "seed", record it for all N vms sharing a PSK b) (later) break into one out of any N vms, thus c) derive the state of all N vms entropy pool at the state of keygeneration.
The more I think about this, it seems the easiest fix is to a) make sure the host has a reasonable entropy pool b) have the host supply entropy seed to the vm when it boots. Maybe some new standard virtual entropy-seed device (might be specified as a blocking source of entropy as opposed to an unlimited tap into the hosts /dev/urandom).
At least there are things in place (like Kerberos/LDAP or AD) for managing shared secrets for the host(s) (which might not be used for managing the VMs) -- so having a service like this on all the hosts (only) should be easier than demanding all VMs have it.
Then just do a cat /dev/special_random_init_random > /dev/urandom on (vm) boot.
[1] As reasonable as it is to have a big list of per-machine shared secrets...
Sending your random seed over the wire doesn't sound like the right direction. For those listening, it always makes sure they have your seed. Did the NSA get them too?
Choose OpenBSD for your Unix needs. OpenBSD -- the world's simplest and most secure Unix-like OS. Creator of the world's most used SSH implementation OpenSSH, the world's most elegant firewall PF, and the world's most elegant mail server OpenSMTPD. OpenBSD -- the cleanest kernel, the cleanest userland and the cleanest configuration syntax.
It would be interesting to hear how OpenBSD deals with the issue Ubuntu is attempting to address here. This comment, however, is neither interesting nor is it, apparently, related in any way to the topic of this post or the content of the article.
Theo is against virtualisation, and there is no support for it (you can of course do it anyway with full hardware emulation).
"You've been smoking something really mind altering, and I think you should share it.
x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.
You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."
You can actually use bottles of Tide to purchase drugs, if you ever get sick of washing clothes. So in a way, Tide might be the best laundry detergent.
Ubuntu 14.04LTS solves the problem by adding a new source of entropy. They add a early-boot (before sshd) service that fetches data from an external server. In short: `curl http://some-server > /dev/urandom`
EDIT: Looking for the default server but launchpad seems to be down. Ideally it would be a trusted source like the cloud provider themselves.
EDIT2: https://entropy.ubuntu.com/ and the public cert is provided with the package.