3 ms·

> 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 ne

> 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.

e12e 13y ago
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...

e12e 13y ago

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...