linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: "Safford, David (GE Global Research, US)" <david.safford@ge.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	"Wiseman, Monty (GE Global Research, US)" <monty.wiseman@ge.com>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	"open list:ASYMMETRIC KEYS" <keyrings@vger.kernel.org>,
	"open list:CRYPTO API" <linux-crypto@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] KEYS: asym_tpm: Switch to get_random_bytes()
Date: Fri, 4 Oct 2019 21:27:11 +0300	[thread overview]
Message-ID: <20191004182711.GC6945@linux.intel.com> (raw)
In-Reply-To: <BCA04D5D9A3B764C9B7405BBA4D4A3C035F2A22E@ALPMBAPA12.e2k.ad.ge.com>

On Fri, Oct 04, 2019 at 01:26:58PM +0000, Safford, David (GE Global Research, US) wrote:
> As the original author of trusted keys, let me make a few comments.
> First, trusted keys were specifically implemented and *documented* to
> use the TPM to both generate and seal keys. Its kernel documentation
> specifically states this as a promise to user space. If you want to have 
> a different key system that uses the random pool to generate the keys,
> fine, but don't change trusted keys, as that changes the existing promise
> to user space. 

TPM generating keys (i.e. the random number) would make sense if the key
would never leave from TPM (that kind of trusted keys would not be a
bad idea at all).

> There are many good reasons for wanting the keys to be based on the
> TPM generator.  As the source for the kernel random number generator
> itself says, some systems lack good randomness at startup, and systems
> should preserve and reload the pool across shutdown and startup.
> There are use cases for trusted keys which need to generate keys 
> before such scripts have run. Also, in some use cases, we need to show
> that trusted keys are FIPS compliant, which is possible with TPM
> generated keys.

If you are able to call tpm_get_random(), the driver has already
registered TPN as hwrng. With this solution you fail to follow the
principle of defense in depth. If the TPM random number generator
is compromissed (has a bug) using the entropy pool will decrease
the collateral damage.

> Second, the TPM is hardly a "proprietary random number generator".
> It is an open standard with multiple implementations, many of which are
> FIPS certified.
> 
> Third, as Mimi states, using a TPM is not a "regression". It would be a
> regression to change trusted keys _not_ to use the TPM, because that
> is what trusted keys are documented to provide to user space.

For asym-tpm.c it is without a question a regression because of the
evolution that has happened after trusted keys. For trusted keys
using kernel rng would be improvement.

/Jarkko

  reply	other threads:[~2019-10-04 18:27 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26 17:16 [PATCH] KEYS: asym_tpm: Switch to get_random_bytes() Jarkko Sakkinen
2019-09-28 18:05 ` Jerry Snitselaar
2019-10-01 20:54   ` Jarkko Sakkinen
2019-10-02 14:00 ` Mimi Zohar
2019-10-03 11:41   ` Jarkko Sakkinen
2019-10-03 11:43     ` Jarkko Sakkinen
2019-10-03 13:02     ` Mimi Zohar
2019-10-03 17:58       ` Jarkko Sakkinen
2019-10-03 18:53         ` Mimi Zohar
2019-10-03 21:51           ` Jarkko Sakkinen
2019-10-03 21:57             ` Jarkko Sakkinen
2019-10-03 22:08               ` Mimi Zohar
2019-10-03 23:59                 ` James Bottomley
2019-10-04 18:22                   ` Jarkko Sakkinen
2019-10-04 18:24                     ` James Bottomley
2019-10-04 18:33                       ` Jerry Snitselaar
2019-10-04 18:42                         ` James Bottomley
2019-10-04 20:07                           ` Jerry Snitselaar
2019-10-04 20:11                             ` Jerry Snitselaar
2019-10-04 22:11                               ` James Bottomley
2019-10-06  0:38                                 ` Mimi Zohar
2019-10-06 23:52                                   ` Jarkko Sakkinen
2019-10-07 18:08                                     ` Mimi Zohar
2019-10-04 18:20                 ` Jarkko Sakkinen
2019-10-03 22:10               ` Jarkko Sakkinen
2019-10-04 13:26           ` Safford, David (GE Global Research, US)
2019-10-04 18:27             ` Jarkko Sakkinen [this message]
2019-10-04 18:30               ` Jarkko Sakkinen
2019-10-04 19:56               ` Safford, David (GE Global Research, US)
2019-10-07  0:05                 ` Jarkko Sakkinen
2019-10-07 22:13                   ` Ken Goldman
2019-10-08 23:49                     ` Jarkko Sakkinen
2019-10-08 23:53                       ` Jarkko Sakkinen
2019-10-09  7:10                         ` Pascal Van Leeuwen
2019-10-09  7:33                         ` Jarkko Sakkinen
2019-10-09  7:41                           ` Jarkko Sakkinen
2019-10-09  8:09                             ` Pascal Van Leeuwen
2019-10-14 19:11                               ` Jarkko Sakkinen
2019-10-09  8:02                           ` Pascal Van Leeuwen
2019-10-09 12:11                         ` Safford, David (GE Global Research, US)
2019-10-14 19:00                           ` Jarkko Sakkinen
2019-10-14 19:29                             ` Jarkko Sakkinen
2019-10-14 19:29                             ` James Bottomley
2019-10-16 11:00                               ` Jarkko Sakkinen
2019-10-16 12:34                                 ` James Bottomley
2019-10-16 16:25                                   ` Jarkko Sakkinen
2019-10-16 19:10                                     ` James Bottomley
2019-10-17 12:52                                       ` Sumit Garg
2019-10-17 12:58                                         ` James Bottomley
2019-10-17 18:04                                       ` Jarkko Sakkinen
2019-10-21 11:39                                         ` Jarkko Sakkinen
2019-10-29  8:42                                           ` Jarkko Sakkinen
2019-10-29 14:58                                             ` James Bottomley
2019-10-31 21:03                                               ` Jarkko Sakkinen
2019-10-18  7:32                                   ` Janne Karhunen
2019-10-03 18:02       ` Jarkko Sakkinen
2019-10-03 18:15         ` Jarkko Sakkinen
2019-10-07 10:33     ` Janne Karhunen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191004182711.GC6945@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=david.safford@ge.com \
    --cc=dhowells@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=monty.wiseman@ge.com \
    --cc=stable@vger.kernel.org \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).