Did you know your system might have a TPM chip that can act as a hardware random number generator (RNG)? Me neither, until recently.

If you’ve ever been generating a GPG, or other cryptographic key, and had to wait for the kernel to fill it’s random entropy pool, then you’ll find this really useful. Doubly-so if you’ve ever been generating keys on a headless server and been amused at the message suggesting you move the mouse or type on the keyboard to generate some entropy. Uhh… Right. This can turn an operation that should take a few seconds into one that takes several minutes or more.

TPM, or Trusted Platform Module is a standard interface that does a bunch of different things - none of which we really care about for Linux except the RNG. TPM is common on corporate laptops and desktops, but even some consumer grade hardware has a TPM chip built-in or one can be added. I have a Linux server built on an MSI motherboard and found it supports a TPM daughterboard which costs under $20.

How do I know if my system supports TPM? It’s pretty simple to check. Do a “dmesg | grep -i tpm” (after a recent boot so boot-time output is still available). Then, based on the output:

  1. Disabled or unavailable: This is good news. It means the kernel found a TPM module, but it’s disabled in your BIOS. How to enable it is entirely BIOS and system dependent, but you should be able to figure it out. Only enable the base TPM support, nothing else.

  2. No output: This probably means your hardware doesn’t have TPM support. You can try weeding through all the BIOS options in hopes that it’s just disabled such that the kernel couldn’t detect it, but likely this is not good news. Double check that the tpm kernel module is loaded with lsmod. If not, try probing the kernel modules, as described below.

  3. Active: If the output shows a device-id or other output suggesting that a TPM device was detected, then you are golden. Here’s an example output from a Lenovo Thinkstation: “tpm_tis 00:05: 1.2 TPM (device-id 0x1A, rev-id 16)”.

You’ll need to have kernel modules for tpm and tpm_rng loaded. On all the systems I’ve had with TPM support, I found tpm already loaded, but had to add tpm_rng to /etc/modules so it loads at boot. To manually probe these, do “sudo modprobe tpm” and “sudo modprobe tpm_rng”, and use “lsmod | grep tpm” to see what modules are loaded.

Ok, so now you’ve got a working hardware RNG, but it’s not doing anything by default. We need to use rng-tools to feed this source into the kernel entropy pool. On Debian, all I had to do was “sudo aptitude install rng-tools” with no further configuration.

To check that it’s working:

  • Look for rng-tools/rngd messages in your logs.
  • Check for loaded kernel modules, as discussed above.
  • Check for /dev/hwrng.
  • Check the size of the entropy pool via “cat /proc/sys/kernel/random/entropy_avail” - if it’s working, this value will always be above around 2000 or so.

If I don’t have a TPM device can I still use rng-tools to feed entropy to the kernel? rng-tools supports additional hardware sources, and you can certainly give them a try - I have yet to have a system with the needed CPU or hardware support aside from TPM, but you just might.

Lastly, don’t be tempted to feed rng-tools using /dev/urandom. You’ll find a lot of tutorials out on the net suggesting setting this up so you don’t have to wait for entropy. This is a bad idea - /dev/urandom will never block, but it’s source of entropy is a weak pseudo-random number generator. If you are generating encryption keys and want secure ones, it’s better to wait for the entropy pool to fill on it’s own than use a weak source!