| Message ID | 20191015124702.633-1-jarkko.sakkinen@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | tpm: Salt tpm_get_random() result with get_random_bytes() | expand |
On Tue, Oct 15, 2019 at 03:47:02PM +0300, Jarkko Sakkinen wrote: > Salt the result that comes from the TPM RNG with random bytes from the > kernel RNG. This will allow to use tpm_get_random() as a substitute for > get_random_bytes(). TPM could have a bug (making results predicatable), > backdoor or even an inteposer in the bus. Salting gives protections > against these concerns. Seems like a dangerous use case, why would any kernel user that cared about quality of randomness ever call a tpm_* API to get quality random data? Jason
On Tue, Oct 15, 2019 at 3:50 PM Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote: > > Salt the result that comes from the TPM RNG with random bytes from the > kernel RNG. This will allow to use tpm_get_random() as a substitute for > get_random_bytes(). TPM could have a bug (making results predicatable), > backdoor or even an inteposer in the bus. Salting gives protections > against these concerns. The current issue in the randomness from my point of view is that encrypted filesystems, ima etc in common deployments require high quality entropy just few seconds after the system has powered on for the first time. It is likely that people want to keep their keys device specific, so the keys need to be generated on the first boot before any of the filesystems mount. Issue is wider than the tpm alone. Tpm is not generally present in the mobile (or even embedded-) systems, but the kernel entropy pool is. Kernel entropy pool on the other hand normally takes ages to initialize, and it is initialized from a source (interrupt timestamps) that does not classify as high-quality entropy. Thus, in the default configurations the first boot cannot proceed as there is no entropy to generate keys from and the boot cannot be paused or the entropy collection ends. I have a hunch that to get past this deadlock many people end up using very, very low quality entropy present at the krng at that time. Solving this properly should be in everyone's interests. This is a bad trap. I'm personally working around this by using multiple entropy sources to feed the kernel entropy pool directly from the hwrng driver initialization function(s) before we enter the userspace. Maybe we could create a KConfig option that forces people to consciously choose from the trust sources present in the system which ones are to be used to feed the krng before we enter the userspace. It would be mandatory to choose one or more sources rather than us silently running them into a trap. During the boot some sort of message should be displayed telling the user how the krng actually got initialized. There is lot of junk happening on the console early on, but this absolutely vital piece of information is completely hidden - that you have to read from the source. -- Janne
On Tue, Oct 15, 2019 at 02:04:50PM -0300, Jason Gunthorpe wrote: > On Tue, Oct 15, 2019 at 03:47:02PM +0300, Jarkko Sakkinen wrote: > > Salt the result that comes from the TPM RNG with random bytes from the > > kernel RNG. This will allow to use tpm_get_random() as a substitute for > > get_random_bytes(). TPM could have a bug (making results predicatable), > > backdoor or even an inteposer in the bus. Salting gives protections > > against these concerns. > > Seems like a dangerous use case, why would any kernel user that cared > about quality of randomness ever call a tpm_* API to get quality > random data? This is related to this discussion: https://lore.kernel.org/linux-integrity/CAE=NcrY3BTvD-L2XP6bsO=9oAJLtSD0wYpUymVkAGAnYObsPzQ@mail.gmail.com/T/#t I could also move this to the call site. /Jarkko
On Wed, Oct 16, 2019 at 10:02:01AM +0300, Janne Karhunen wrote: > On Tue, Oct 15, 2019 at 3:50 PM Jarkko Sakkinen > <jarkko.sakkinen@linux.intel.com> wrote: > > > > Salt the result that comes from the TPM RNG with random bytes from the > > kernel RNG. This will allow to use tpm_get_random() as a substitute for > > get_random_bytes(). TPM could have a bug (making results predicatable), > > backdoor or even an inteposer in the bus. Salting gives protections > > against these concerns. > > The current issue in the randomness from my point of view is that > encrypted filesystems, ima etc in common deployments require high > quality entropy just few seconds after the system has powered on for > the first time. It is likely that people want to keep their keys > device specific, so the keys need to be generated on the first boot > before any of the filesystems mount. This patch does not have the described issue. Which call sites are you talking about? /Jarkko
On Wed, Oct 16, 2019 at 01:38:05PM +0300, Jarkko Sakkinen wrote: > On Tue, Oct 15, 2019 at 02:04:50PM -0300, Jason Gunthorpe wrote: > > On Tue, Oct 15, 2019 at 03:47:02PM +0300, Jarkko Sakkinen wrote: > > > Salt the result that comes from the TPM RNG with random bytes from the > > > kernel RNG. This will allow to use tpm_get_random() as a substitute for > > > get_random_bytes(). TPM could have a bug (making results predicatable), > > > backdoor or even an inteposer in the bus. Salting gives protections > > > against these concerns. > > > > Seems like a dangerous use case, why would any kernel user that cared > > about quality of randomness ever call a tpm_* API to get quality > > random data? > > This is related to this discussion: > > https://lore.kernel.org/linux-integrity/CAE=NcrY3BTvD-L2XP6bsO=9oAJLtSD0wYpUymVkAGAnYObsPzQ@mail.gmail.com/T/#t > > I could also move this to the call site. But I hear you anyway. I think for trusted keys the best strategy would be to do exactly this: 1. Generate one random value with get_random_bytes_arch() 2. Generate another with backend specific technology (we have now two TPM and TEE) if an RNG available. 3. Xor the values together. /Jarkko
On Wed, Oct 16, 2019 at 1:41 PM Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote: > > > get_random_bytes(). TPM could have a bug (making results predicatable), > > > backdoor or even an inteposer in the bus. Salting gives protections > > > against these concerns. > > > > The current issue in the randomness from my point of view is that > > encrypted filesystems, ima etc in common deployments require high > > quality entropy just few seconds after the system has powered on for > > the first time. It is likely that people want to keep their keys > > device specific, so the keys need to be generated on the first boot > > before any of the filesystems mount. > > This patch does not have the described issue. My understanding was that you wanted to make the tpm_get_random() an alternative to get_random_bytes(), and one reason why one might want to do this is to work around the issues in get_random_bytes() in early init as it may not be properly seeded. But sure, if you this wasn't among the problems being solved then forget it. -- Janne
On Wed, Oct 16, 2019 at 01:43:22PM +0300, Jarkko Sakkinen wrote: > On Wed, Oct 16, 2019 at 01:38:05PM +0300, Jarkko Sakkinen wrote: > > On Tue, Oct 15, 2019 at 02:04:50PM -0300, Jason Gunthorpe wrote: > > > On Tue, Oct 15, 2019 at 03:47:02PM +0300, Jarkko Sakkinen wrote: > > > > Salt the result that comes from the TPM RNG with random bytes from the > > > > kernel RNG. This will allow to use tpm_get_random() as a substitute for > > > > get_random_bytes(). TPM could have a bug (making results predicatable), > > > > backdoor or even an inteposer in the bus. Salting gives protections > > > > against these concerns. > > > > > > Seems like a dangerous use case, why would any kernel user that cared > > > about quality of randomness ever call a tpm_* API to get quality > > > random data? > > > > This is related to this discussion: > > > > https://lore.kernel.org/linux-integrity/CAE=NcrY3BTvD-L2XP6bsO=9oAJLtSD0wYpUymVkAGAnYObsPzQ@mail.gmail.com/T/#t > > > > I could also move this to the call site. > > But I hear you anyway. > > I think for trusted keys the best strategy would be to do > exactly this: > > 1. Generate one random value with get_random_bytes_arch() > 2. Generate another with backend specific technology (we > have now two TPM and TEE) if an RNG available. > 3. Xor the values together. Feels like something the random core should handle - maybe some way to say 'my trust model requires trust in this RNG' and then the random core can more heavily weight data from that RNG Jason
On Wed, Oct 16, 2019 at 02:16:20PM +0300, Janne Karhunen wrote: > On Wed, Oct 16, 2019 at 1:41 PM Jarkko Sakkinen > <jarkko.sakkinen@linux.intel.com> wrote: > > > > > get_random_bytes(). TPM could have a bug (making results predicatable), > > > > backdoor or even an inteposer in the bus. Salting gives protections > > > > against these concerns. > > > > > > The current issue in the randomness from my point of view is that > > > encrypted filesystems, ima etc in common deployments require high > > > quality entropy just few seconds after the system has powered on for > > > the first time. It is likely that people want to keep their keys > > > device specific, so the keys need to be generated on the first boot > > > before any of the filesystems mount. > > > > This patch does not have the described issue. > > My understanding was that you wanted to make the tpm_get_random() an > alternative to get_random_bytes(), and one reason why one might want > to do this is to work around the issues in get_random_bytes() in early > init as it may not be properly seeded. But sure, if you this wasn't > among the problems being solved then forget it. I'm trying to get a framework on how rng's should be used in the kernel. There doesn't seem to be one. /Jarkko
On Wed, Oct 16, 2019 at 01:09:08PM -0300, Jason Gunthorpe wrote: > On Wed, Oct 16, 2019 at 01:43:22PM +0300, Jarkko Sakkinen wrote: > > On Wed, Oct 16, 2019 at 01:38:05PM +0300, Jarkko Sakkinen wrote: > > > On Tue, Oct 15, 2019 at 02:04:50PM -0300, Jason Gunthorpe wrote: > > > > On Tue, Oct 15, 2019 at 03:47:02PM +0300, Jarkko Sakkinen wrote: > > > > > Salt the result that comes from the TPM RNG with random bytes from the > > > > > kernel RNG. This will allow to use tpm_get_random() as a substitute for > > > > > get_random_bytes(). TPM could have a bug (making results predicatable), > > > > > backdoor or even an inteposer in the bus. Salting gives protections > > > > > against these concerns. > > > > > > > > Seems like a dangerous use case, why would any kernel user that cared > > > > about quality of randomness ever call a tpm_* API to get quality > > > > random data? > > > > > > This is related to this discussion: > > > > > > https://lore.kernel.org/linux-integrity/CAE=NcrY3BTvD-L2XP6bsO=9oAJLtSD0wYpUymVkAGAnYObsPzQ@mail.gmail.com/T/#t > > > > > > I could also move this to the call site. > > > > But I hear you anyway. > > > > I think for trusted keys the best strategy would be to do > > exactly this: > > > > 1. Generate one random value with get_random_bytes_arch() > > 2. Generate another with backend specific technology (we > > have now two TPM and TEE) if an RNG available. > > 3. Xor the values together. > > Feels like something the random core should handle - maybe some way to > say 'my trust model requires trust in this RNG' and then the random > core can more heavily weight data from that RNG Yeah, I think. I'll study these emails threads and RNG implementation a bit when I have more time. Now I think I lack some knowledge to say anything educated so better to take a step back and go back to the drawing board. Thank you for the suggestion. /Jarkko
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index 7f105490604c..a135b1cd5a17 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -22,6 +22,7 @@ #include <linux/poll.h> #include <linux/slab.h> #include <linux/mutex.h> +#include <linux/random.h> #include <linux/spinlock.h> #include <linux/suspend.h> #include <linux/freezer.h> @@ -431,16 +432,24 @@ int tpm_pm_resume(struct device *dev) EXPORT_SYMBOL_GPL(tpm_pm_resume); /** - * tpm_get_random() - get random bytes from the TPM's RNG + * tpm_get_random() - Get random bytes from the TPM's RNG * @chip: a &struct tpm_chip instance, %NULL for the default chip * @out: destination buffer for the random bytes * @max: the max number of bytes to write to @out * - * Return: number of random bytes read or a negative error value. + * Get random bytes from the TPM's RNG and salt the result with the same amount + * of bytes from the kernel RNG. Salting allows to call this function as a + * substitute for get_random_bytes() where appropriate. + * + * Return: + * number of random bytes on success, + * -errno on error */ int tpm_get_random(struct tpm_chip *chip, u8 *out, size_t max) { + u8 salt[TPM_MAX_RNG_DATA]; int rc; + int i; if (!out || max > TPM_MAX_RNG_DATA) return -EINVAL; @@ -455,6 +464,14 @@ int tpm_get_random(struct tpm_chip *chip, u8 *out, size_t max) rc = tpm1_get_random(chip, out, max); tpm_put_ops(chip); + + if (rc > 0) { + get_random_bytes(salt, rc); + + for (i = 0; i < rc; i++) + out[i] ^= salt[i]; + } + return rc; } EXPORT_SYMBOL_GPL(tpm_get_random);
Salt the result that comes from the TPM RNG with random bytes from the kernel RNG. This will allow to use tpm_get_random() as a substitute for get_random_bytes(). TPM could have a bug (making results predicatable), backdoor or even an inteposer in the bus. Salting gives protections against these concerns. Cc: David Safford <david.safford@ge.com> Cc: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-)