5

is /dev/random any good in AWS EC2 for use in making a shared key that will be passed over a secure channel? i am concerned that a launched instance would have not much entropy to begin with. what if i delay using it for a couple minutes to get random EBS delays for more entropy?

edit:

i will not be logging in to these instances. one instance will generate a key and place it (in hex) in a tag. another instance will get the key from that tag and set up a VPN between them. maybe there is a way to use PKC for this although the path to/from tags is https, which AWS depends on for login passwords.

edit2:

i guess timing to access the EC2 API can be another source of entropy.

Skaperen
  • 315
  • 2
  • 11
  • 2
    Please take a look at http://security.stackexchange.com/a/3939/33. Your question is not quite a duplicate because of the cloud element (though I believe the answer will be "it doesn't matter"), however as that answer I linked shows you should be using `urandom`, not `random`. – AviD May 26 '15 at 11:55
  • 1
    The issue of entropy in virtualized environments has been discussed in [Managing keys generated with insufficient entropy](https://security.stackexchange.com/questions/89813/managing-keys-generated-with-insufficient-entropy) and [VM production server and low entropy](https://security.stackexchange.com/questions/86859/vm-production-server-and-low-entropy), you may find interesting information here regarding how to estimate your current entropy, how to cope with it and what limitations you may encounter. – WhiteWinterWolf May 26 '15 at 12:54

1 Answers1

3

The potential problem with cloud machines and randomness is VM cloning; see this. Any decent Linux system will be able to produce high-quality randomness from /dev/urandom at any point after boot, regardless of whether it sits in the cloud or not. However, if a VM is cloned, then the two machines will start at the same internal state, and there is no safety mechanism that can be included in the OS for that, because, by definition, the guest OS is not aware of the cloning.

It is technically feasible, for Amazon, to push fresh randomness in each newly cloned instance (it suffices to update the "seed file" in the clone). I don't know if they do it. If they do not (or if you cannot find some written documentation that says that they do), then you may have to do the reseeding yourself. Though simply waiting for a few minutes of network activity should inject enough entropy, it is both faster and arguably safer to force it yourself. Assuming that you are accessing the Amazon EC2 instance through SSH from your laptop/desktop, and that your laptop/desktop uses Linux too, then it becomes a simple matter of doing this once:

dd if=/dev/urandom bs=20 count=1 | ssh TheEC2MachineName 'cat > /dev/random'

and voilà! 20 fresh bytes of strong randomness added to the VM entropy pool. You can then proceed with all your crypto things on the VM right away.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • the instances will be launched from the same image, so they will be like clones. about the only entropy will be the instance ID and the time of launch. – Skaperen May 27 '15 at 09:44
  • if i generate the key after the OS initializes then in theory all the I/O timing (EBS delays in my case of using AWS EC2) could add a little more entropy. – Skaperen May 27 '15 at 09:50