Proposed F19 Feature: Virtio RNG

[Steve Grubb]

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