Theodore Y. Ts'o <tytso@xxxxxxx> 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.
