codeblog code is freedom — patching my itch

October 22, 2009

TPM as RNG

Filed under: Debian,Security,Ubuntu,Ubuntu-Server — kees @ 10:43 pm

I was reminded about some TPM coding I’d done to get random bytes from the pRNG on my TPM-enabled system from Matt Domsch’s recent post. I’m not fully convinced that the pRNG of the TPM is an appropriate source of entropy, but it does pass my simple FIPS-140-2 test.

I had to find the Intel TPM docs to figure out how to enable TPM on my system. It was under “Advanced / Peripherals”. I was expecting it under “Security”, like every other BIOS I’d seen. After that:

$ sudo apt-get install trousers tpm-tools
...
$ sudo modprobe tpm_tis
$ dmesg | grep -i tpm
[676618.167313] tpm_tis 00:07: 1.2 TPM (device-id 0xFE, rev-id 70)
$ sudo service trousers start
...
$ tpm_version
TPM 1.2 Version Info:
Chip Version: 1.2.2.16
Spec Level: 2
Errata Revision: 1
TPM Vendor ID: WEC
TPM Version: 01010000
Manufacturer Info: 57454300
$ ./tpm-getrand | hexdump -C
00000000 61 07 23 ff 71 3e 25 e8 f0 d5 de a7 a3 07 21 dc |a.#.q>%.......!.|

I could run rngd with a named pipe, but it’d be nice to have a new driver that could run a command instead to get the next 20000 bits.

UPDATE: I’ve implemented this in rngd now.

© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

3 Comments

  1. I’ve written the same in shell, as a proof of concept, and will probably
    be combining MirBSD cprng(8) (which does truerand as dæmon), tpmrng (the
    shell prototype) and a *SIMPLE* (only read packets and put them into the
    kernel pool, until the Lua dæmon can be run) http://www.entropykey.co.uk/
    client into one dæmon that can even be put on the installer.

    I’ve read through all the TPM specs I could find re. its RNG functions
    and found that:

    • output function is most probably SHA-1 for most of them; the standard
    specifies that the TPM is allowed to answer with blocks of the SHA-1
    output size even if requested larger blocks

    • while a TPM *may* have a HW RNG on it, it *may* also be some different
    kind, even a PRNG, as long as the internal state can NEVER be recovered
    either by the user or by the manufacturer after it is sealed at the end
    of the production process, even with StirRandom

    This basically means that, while it may not be a HW RNG, it’s good enough
    for at least *some* bits during runtime of a system, and, when added to
    the kernel main entropy pool, helps but can’t hurt (due to mixing).

    Comment by mirabilos — October 23, 2009 @ 1:53 am

  2. Bug #542599

    Comment by Jo Shields — October 23, 2009 @ 12:12 pm

  3. In his comment above Mirabilos has kindly summarized information from section 4.2.5 “Random Number Generator” in Part 1 “Design Principles” in the TPM spec v1.2 Level 2 Revision 103 [phew]. You can find it at http://www.trustedcomputinggroup.org/resources/tpm_main_specification if you want to read it yourself (Kees provided a link above).

    Thanks for the informative post Kees!

    -Tyler

    Comment by Tyler Oderkirk — March 24, 2010 @ 7:45 pm

Powered by WordPress