diff mbox series

tpm: Salt tpm_get_random() result with get_random_bytes()

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

Commit Message

Jarkko Sakkinen Oct. 15, 2019, 12:47 p.m. UTC
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(-)

Comments

Jason Gunthorpe Oct. 15, 2019, 5:04 p.m. UTC | #1
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
Janne Karhunen Oct. 16, 2019, 7:02 a.m. UTC | #2
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
Jarkko Sakkinen Oct. 16, 2019, 10:38 a.m. UTC | #3
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
Jarkko Sakkinen Oct. 16, 2019, 10:41 a.m. UTC | #4
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
Jarkko Sakkinen Oct. 16, 2019, 10:43 a.m. UTC | #5
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
Janne Karhunen Oct. 16, 2019, 11:16 a.m. UTC | #6
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
Jason Gunthorpe Oct. 16, 2019, 4:09 p.m. UTC | #7
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
Jarkko Sakkinen Oct. 16, 2019, 4:23 p.m. UTC | #8
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
Jarkko Sakkinen Oct. 17, 2019, 4:21 p.m. UTC | #9
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 mbox series

Patch

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);