[tpm2] Re: Pipe the TMP2 directly into /dev/random

[tpm2] Re: Pipe the TMP2 directly into /dev/random

[Frederick Gotham]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

Sweet mother of divine Jesus Christ and the twelve apostles.

Forgive me, but my patience is wearing thin as I have posted this idea on
several forums and been meet with the same response every time.

I shall now use all caps to convey my annoyance.

IF ONE IS OKAY WITH THE SPEED AT WHICH RANDOM BITS CAN BE RETRIEVED FROM
THE TMP2, THEN.... Can we please put together some code so that the TPM2
can feed directly into /dev/null.

Frederick


On Friday, December 13, 2019, Steven Clark <davolfman(a)gmail.com> wrote:

> This is probably a much worse idea than you think it is.  Historically TPM
> 2.0 communication has been kinda slow and only improved in some relatively
> recent kernels.  The general theory that seems to apply to the kind of
> entropy mixing the kernel does is that entropy is conserved and that faulty
> sources just don't add entropy. And thanks to the mixing they can't
> manipulate the pool enough for an attack. Given there are stirring
> commands, even the TPM RNG is probably not collecting real entropy all that
> fast, so it would probably become a PRNG in slow hardware on a slow bus if
> used as the only RNG.
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1431 bytes --]

[tpm2] Re: Pipe the TMP2 directly into /dev/random

[Steven Clark]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

If you want it you will probably have to code it yourself.  A start would
be to disable the kernel's existing entropy gathering.  Then turn off
entropy gathering and crediting for other alternate sources such as rdrand.
Then turn rng_core.default_quality permanently to 1000 to accept TPM RNG
entropy as real entropy.

Or tear out the entire kernel random infrastructure and rebuild it from
scratch. It is not just a simple character device module and hasn't been
for who knows how long.

The easy answer is to just use the rng_core.default_quality=1000 boot
option and accept that your TPM output is getting mixed with other stuff to
make it even more random.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 785 bytes --]

[tpm2] Re: Pipe the TMP2 directly into /dev/random

[Steven Clark]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

This is probably a much worse idea than you think it is.  Historically TPM
2.0 communication has been kinda slow and only improved in some relatively
recent kernels.  The general theory that seems to apply to the kind of
entropy mixing the kernel does is that entropy is conserved and that faulty
sources just don't add entropy. And thanks to the mixing they can't
manipulate the pool enough for an attack. Given there are stirring
commands, even the TPM RNG is probably not collecting real entropy all that
fast, so it would probably become a PRNG in slow hardware on a slow bus if
used as the only RNG.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 637 bytes --]

[tpm2] Re: Pipe the TMP2 directly into /dev/random

[Frederick Gotham]

[-- Attachment #1: Type: text/plain, Size: 251 bytes --]

I want to get random bits from the TPM2 and nowhere else.


On Friday, December 13, 2019, Roberts, William C <
william.c.roberts(a)intel.com> wrote:

>
>
> IIUC the kernel pulls in many sources of entropy including the tpm2 if
> present.
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 474 bytes --]

[tpm2] Re: Pipe the TMP2 directly into /dev/random

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]



> -----Original Message-----
> From: Frederick Gotham [mailto:cauldwell.thomas(a)gmail.com]
> Sent: Friday, December 13, 2019 3:54 AM
> To: tpm2 <tpm2(a)lists.01.org>
> Subject: [tpm2] Pipe the TMP2 directly into /dev/random
> 
> Hi
> 
> I realise that we can use rng-tools to use the TPM2 to seed the random number
> generator built into the Linux kernel.
> 
> What I'd like to ask though, is if anyone has done any work connecting
> /dev/random directly to the TPM2 so that there's no software pseudo-
> randomness at all.
> 
> If this hasn't been done, would anyone like to work on it with me?

IIUC the kernel pulls in many sources of entropy including the tpm2 if
present.

> 
> Frederick
> _______________________________________________
> tpm2 mailing list -- tpm2(a)lists.01.org
> To unsubscribe send an email to tpm2-leave(a)lists.01.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s