Has anyone yet removed the random number generator entirely from the Linux
kernel?
I'm currently working on an embedded x86_64 project, and I'm interfacing
witht the TPM2 chip.
There cannot be any software-based psuedo-random number generators on my
device, and so far I've removed three of them:
(1) The built-in PRNG inside OpenSSL
(2) The Intel RDRAND engine inside OpenSSL
(3) The simulator library that goes with the tpm2tss engine for OpenSSL
(tcti-mssim)
The only software-based random-number generator left on my device is inside
the Linux kernel (i.e. the one that feeds /dev/random).
I do realise that there are tools like 'rng-tools' for feeding a hardware
generator into the entropy pool for "/dev/random" -- but this simply isn't
good enough for my project.
I need to remove the PRNG from the Linux kernel and replace it with something
that interfaces directly with the TPM2 chip.
Has this been done before?
On Fri, Nov 08, 2019 at 03:48:02PM -0000, Frederick Gotham wrote:
>
> There cannot be any software-based psuedo-random number generators on my
> device, and so far I've removed three of them:
>
> (1) The built-in PRNG inside OpenSSL
> (2) The Intel RDRAND engine inside OpenSSL
> (3) The simulator library that goes with the tpm2tss engine for OpenSSL
> (tcti-mssim)
Why must there not be a "pseudo-random number generator"? Who made
that rule? What is the goal of not allowing such a thing?
Note that in general, most people would not refer to such things as a
"PRNG", but a Cryptographic Random Number Generator (CRNG). And in
general, it's considered a very good thing put a CRNG in front of a
hardware random number generator for several reasons:
(1) Hardware random number generators, including TPM-based RNG's are
slow, and
(2) using a hardware RNG directly means you are investing all of
your trust in the hardware RNG --- and hardware RNG have been known to
have their share of insecurities.
What makes you so sure that the you can trust the implementation of
the TPM's random number generator?
Far better is to mix multiple entropy sources together, so that if one
happens to be insecure, or has failed in some way, you still will have
protection from the other entropy sources.
> I need to remove the PRNG from the Linux kernel and replace it with something
> that interfaces directly with the TPM2 chip.
>
> Has this been done before?
As far as I know, no, because most people would consider this a
Really, REALLY, **REALLY** bad idea. Note that the TPM2 chip has a
very slow connection to the main CPU, and there are many applications
which will need session keys at a high rate (for example, opening
multiple https connections when browsing a web page), for which the
TPM2 would be totally unsuited.
If you really want to use the TPM2 chip, there are userspace libraries
which will access it directly, and you can see how slow and painful
using the TPM chip really would be....
- Ted
Theodore Y. Ts'o <[email protected]> wrote:
> On Fri, Nov 08, 2019 at 03:48:02PM -0000, Frederick Gotham wrote:
> >
> > There cannot be any software-based psuedo-random number generators on my
> > device, and so far I've removed three of them:
> >
> > (1) The built-in PRNG inside OpenSSL
> > (2) The Intel RDRAND engine inside OpenSSL
> > (3) The simulator library that goes with the tpm2tss engine for OpenSSL
> > (tcti-mssim)
>
> Why must there not be a "pseudo-random number generator"? Who made
> that rule? What is the goal of not allowing such a thing?
I assume the reason is that you have very high security requirements.
If so, replacing PRNGs with something hardware-based may be a
reasonable idea. However, that does not seem entirely clear, given
that well-implemented & well-seeded PRNGs have been shown to
be adequate for crypto purposes, e.g. in Schneier et al's Yarrow
paper.
> Note that in general, most people would not refer to such things as a
> "PRNG", but a Cryptographic Random Number Generator (CRNG). And in
> general, it's considered a very good thing put a CRNG in front of a
> hardware random number generator for several reasons:
>
> (1) Hardware random number generators, including TPM-based RNG's are
> slow, and
>
> (2) using a hardware RNG directly means you are investing all of
> your trust in the hardware RNG --- and hardware RNG have been known to
> have their share of insecurities.
Yes, putting a mixer in front of an HRNG is almost always a good idea.
Since Linux has a built-in mixer, you might as well use that.
> What makes you so sure that the you can trust the implementation of
> the TPM's random number generator?
>
> Far better is to mix multiple entropy sources together, so that if one
> happens to be insecure, or has failed in some way, you still will have
> protection from the other entropy sources.
>
> > I need to remove the PRNG from the Linux kernel and replace it with something
> > that interfaces directly with the TPM2 chip.
Far better, I'd say to arrange for the chip to reseed the random(4) driver.
If you really don't want to ever use any CRNG, then either remove the
/dev/urandom interface or make it a link to /dev/random. I do not
think that is either necessary or a good idea, but it is possible & does
not require messing with the kernel.
> > Has this been done before?
>
> As far as I know, no, because most people would consider this a
> Really, REALLY, **REALLY** bad idea. Note that the TPM2 chip has a
> very slow connection to the main CPU, and there are many applications
> which will need session keys at a high rate (for example, opening
> multiple https connections when browsing a web page), for which the
> TPM2 would be totally unsuited.
>
> If you really want to use the TPM2 chip, there are userspace libraries
> which will access it directly, and you can see how slow and painful
> using the TPM chip really would be....
I'd say using almost anything as your sole entropy source would be
a serious error if security requirements are high. You want at least
two sources both because that leaves you safe if one fails and
because, even if someone discovers some flaw that makes it easy
to attack one source, the presence of the other makes the attack
extremely difficult.
The random(4) driver does collect entropy from interrupts etc.
and, depending on what your machine will be doing, that may
well be all the second source you need.
If you have RDRAND, that would be a fine second source. If
your board has an unused sound card equivalent, then
Denker's Turbid would be another. I'd use either or both if
available.
I've done performance testing, and I can generate 50 kilobytes of
random data in 6.9 seconds using the TMP2 hardware. This is adequate.
The boot-up state of my embedded device is very predictable, and so I
don't want any mathematical algorithms for psudeo-randomness present
on my device. I am cutting them all out.
I don't want to use the TPM2 to feed entropy into the Linux kernel's
PRNG. Instead I wish to remove the PRNG from the kernel and replace it
with a direct call to the TPM2 chip. Performance is not an issue here.