Random Seeds in Ubuntu 14.04 LTS Cloud Instances
blog.dustinkirkland.com
blog.dustinkirkland.com
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.
(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).
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.
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.
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...
"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."
Shameless.