I am currently working on an app that needs to create GPG key pairs using the gpg
tool. Unfortunately, this tool takes a long time to generate a key pair if there is insufficient entropy/randomness available on the system to do so. A common workaround for this is to install the rng-tools
package as it is called on Debian systems. This allows gpg
to take advantage of true hardware random number generators. Is this safe to use (from a security perspective) on a virtual machine/virtual private server where the OS only has access to virtualized hardware? Will the generated keys be sufficiently random?
- 565
- 3
- 7
- 305
- 1
- 2
- 9
3 Answers
All of this depends on the hardware (physical or virtual) available to your VM. rng-tools can only get entropy from the sources available to it. If your virtual machine has no available sources of entropy for rng-tools to use then you'll be no better off.
Some virtualization systems are however able to make hardware sourced entropy available to guests through a number of mechanisms. In some cases you can pass a hardware device directly to your guest (USB, PCI, whatever) and have rng-tools use this device. In most cases this won't be possible.
The virtio paravirtual drivers expose various IO devices to guest VMs from the hardware controlling domain (Linux kernel running KVM, dom0 in Xen). There's a virtio-rng device that allows for an entropy source to be exposed to guests. From what I can find this is pretty mature on KVM but Xen support looks to be a work in progress: http://wiki.xen.org/wiki/Virtio_On_Xen
While virtio is great, it requires the guest have virtio drivers and thus be aware of the fact that it's a VM (paravirtualized). Newer hardware like Intel IVB and HSW chips have specific CPU instructions that provide random numbers from an on-chip RNG and these can be exposed to guest VMs. You can probe for the availability of these instructions by using CPUID.
This is a brief overview and likely information enough. If you're interested in more details there's an excellent discussion of this topic here: http://log.amitshah.net/2013/01/about-random-numbers-and-virtual-machines/
EDIT: Sorry, I guess I provided a lot of data but never really answered the question. Anyways here's my take on the actual question:
Is this safe to use (from a security perspective) on a virtual machine/virtual private server where the OS only has access to virtualized hardware? Will the generated keys be sufficiently random?
When it comes to security there's nothing more damaging than thinking your configuration is secure when it isn't. Using rng-tools when it provides you with no benefit (has no hardware entropy source source to draw from) has the distinct possibility of making you think you are generating high quality random numbers (keying material?) when in fact you aren't. So I don't think using rng-tools without having an entropy source for it in your VM will make the numbers generated any less random but it may make cause you to think you're generating high quality keys when you actually aren't.
My advice would be to use the rng-tools daemon but only after verifying that you've got an entropy source available for it to use.
- 565
- 3
- 7
-
1But will it harm to run `rngd` when no usable source of entropy is available? Will it feed bad entropy or will it do nothing? – rustyx Jun 04 '18 at 20:42
-
1`rngd` will do nothing if there's no hardware rng. You can verify by looking at the log output. – Brian Minton Apr 07 '20 at 17:32
The other answer is slightly inaccurate.
If you are running on an Ivy Bridge (or newer), or any recent AMD processor then the VM can use the CPU instruction RDRAND
. That's real hardware entropy and it's available to all virtual machines (even in the cloud).
-
3
-
@forest The accepted answer doesn't mention the AMD instruction. I think it makes this answer a border case. – peterh Jun 03 '18 at 03:39
-
@Derek Welcome on the Security SE! You can give only essentially different answers from the already existing ones. A nice tip & trick: answer new questions first :-) – peterh Jun 03 '18 at 03:41
I mostly agree with @flihp, but some "tutorials" here and there suggest to use /dev/urandom as the hardware entropy source.
This is plain wrong since it will inject pseudo-random numbers into the "truly" random source, which in turn will be used to generate more pseudo-random numbers, etc.
In this case I think that using rng-tools will make things worse.
see also: https://wiki.archlinux.org/index.php/Rng-tools and https://lwn.net/Articles/525459/
- 201
- 1
- 4