On Friday, February 01, 2013 04:39:17 PM Bill Nottingham wrote: > Given FIPS paranoia about RNG sources, does this have knock-on effects in > the FIPS compliance of guests depending on how it's fed in the host? There is no FIPS problem here. Its more of a common criteria issue. But here is a little back story on it. The UK created this standard: http://www.cesg.gov.uk/publications/Documents/CPA_Security_Characteristic_for_Server_Virtualisation_v1.21.pdf This is the relevant section: "DEP.5.M249: Confirm the entropy available to the network encryption is sufficient. This mitigation is required to counter the exploitation of any loss of entropy in the Guest OS leading to insecure network encryption. At Foundation Grade the deployment is required to use an external entropy source, or use the NIST tests on the raw entropy data to confirm that the entropy being produced within the VM is sufficient. In this context, 'external' means that the entropy was generated from some reliable source of entropy outside the VM (and possibly outside the platform altogether). This includes solutions where the network encryption is terminated outside the VM (for example, using a TLS concentrator). The issue is that the usual sources of entropy on a physical machine (such as disk timings) may not provide the same amount of entropy once virtualised, and the loss of entropy will weaken encryption that relies on it." NIAP picked up on this and its now required. The fear is that virtualization is done based on a scheduler and the delays and timings that are used by the kernel to mine entropy from hardware would have artifacts in it from this scheduler. The fear is that an attacker could use this information to guess what entropy is in the pool by modelling it carefully. Whether or not this is a problem in practice is still being debated. Its just easy to avoid by doing a pass-thru than doing a study and arguing the fear is irrational. It very well may be possible that guests have low quality entropy and that would be bad for generating ssh keys. And for the record...random numbers are not entropy. They have entropy but they are not the same. The reason is because the real entropy is conditioned with a hash function before it hits user space. And in the case of urandom, it may generate its own numbers for a while before getting reseeded with entropy. The upshot of which is you have random numbers, but the entropy content is lower but its still sufficient for cryptographic purposes. Hope this helps... -Steve -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
