3 ms·

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 th

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

otterley 13y ago
How about rngd?
e12e 13y ago
> 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.
- zackelan 13y ago
  > 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...

otterley 13y ago

How about rngd?

e12e 13y ago

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

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