This "low entropy" mantra is a dud. See this answer for details. The executive summary is: some software, in particular /dev/random, may report a "low entropy" and block for reasons which make no practical sense. The idea of entropy being "exhausted" comes from a mathematical model which has only tenuous links with reality, and may (theoretically) provide any security gain only when the randomness is used for "information theoretically secure" algorithms. Usual algorithms such as RSA or AES are not of these class.
So what you need to do is the following:
- OpenSSL should normally use
/dev/urandom, avoiding the problem. If the problem occurs, it will manifest itself as a "blocking" behaviour (key generation takes an abnormal amount of time, with no CPU used). - If the problem occurs, "refill"
/dev/randomwith fresh pseudo-randomness, which is good enough. Something like:dd if=/dev/urandom of=/dev/random bs=1024 count=64
There is, however, another issue which is not so easy to deal with. Cloud systems are virtual machines, which may run concurrently with other virtual machines on the same hardware. When two execution threads run on two cores of the same CPU, even if they relate to distinct virtual machines, they share the level-1 cache and may potentially spy on each other. The technique involves doing memory accesses in an array which uses the same cache lines as the target code, and reconstructing the target secrets by noticing when some array elements have been evicted from cache.
Working prototypes have been demonstrated in lab conditions. Whether they may be applied in a practical setup depends on a lot of parameters, and is currently unknown. However, it is plausible. The conclusion is that if you do something serious with keys, then you should strive to run on your own hardware, or at least obtain some guarantee from the cloud provider that your virtual machines will not share the same hardware servers as virtual machines from other customers.