From: James Bottomley <James.Bottomley@HansenPartnership.com> To: Jarkko Sakkinen <email@example.com>, "Safford, David (GE Global Research, US)" <firstname.lastname@example.org> Cc: Ken Goldman <email@example.com>, Mimi Zohar <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "open list:ASYMMETRIC KEYS" <email@example.com>, "open list:CRYPTO API" <firstname.lastname@example.org>, open list <email@example.com> Subject: Re: [PATCH] KEYS: asym_tpm: Switch to get_random_bytes() Date: Mon, 14 Oct 2019 12:29:57 -0700 [thread overview] Message-ID: <1571081397.3728.9.camel@HansenPartnership.com> (raw) In-Reply-To: <20191014190033.GA15552@linux.intel.com> On Mon, 2019-10-14 at 22:00 +0300, Jarkko Sakkinen wrote: > On Wed, Oct 09, 2019 at 12:11:06PM +0000, Safford, David (GE Global > Research, US) wrote: > > > > > From: Jarkko Sakkinen <firstname.lastname@example.org> > > > Sent: Tuesday, October 8, 2019 7:54 PM > > > To: Ken Goldman <email@example.com> > > > Cc: Safford, David (GE Global Research, US) <firstname.lastname@example.org > > > >; Mimi > > > Zohar <email@example.com>; firstname.lastname@example.org; > > > email@example.com; open list:ASYMMETRIC KEYS > > > <firstname.lastname@example.org>; open list:CRYPTO API <linux- > > > email@example.com>; open list <firstname.lastname@example.org> > > > Subject: EXT: Re: [PATCH] KEYS: asym_tpm: Switch to > > > get_random_bytes() > > > > > > On Wed, Oct 09, 2019 at 02:49:35AM +0300, Jarkko Sakkinen wrote: > > > > On Mon, Oct 07, 2019 at 06:13:01PM -0400, Ken Goldman wrote: > > > > > The TPM library specification states that the TPM must comply > > > > > with NIST SP800-90 A. > > > > > > > > > > https://trustedcomputinggroup.org/membership/certification/tp > > > > > m-certified-products/ > > > > > > > > > > shows that the TPMs get third party certification, Common > > > > > Criteria EAL 4+. > > > > > > > > > > While it's theoretically possible that an attacker could > > > > > compromise both the TPM vendors and the evaluation agencies, > > > > > we do have EAL 4+ assurance against both 1 and 2. > > > > > > > > Certifications do not equal to trust. > > > > > > And for trusted keys the least trust solution is to do generation > > > with the kernel assets and sealing with TPM. With TEE the least > > > trust solution is equivalent. > > > > > > Are you proposing that the kernel random number generation should > > > be removed? That would be my conclusion of this discussion if I > > > would agree any of this (I don't). > > > > > > /Jarkko > > > > No one is suggesting that. > > > > You are suggesting changing the documented behavior of trusted > > keys, and that would cause problems for some of our use cases. > > While certification may not in your mind be equal to trust, it is > > equal to compliance with mandatory regulations. > > > > Perhaps rather than arguing past each other, we should look into > > providing users the ability to choose, as an argument to keyctl? > > > > dave > > I'm taking my words back in the regression part as regression would > need really a failing system. Definitely the fixes tag should be > removed from my patch. > > What is anyway the role of the kernel rng? Why does it exist and when > exactly it should be used? This exactly where the whole review > process throughout the "chain of command" failed misserably with > tpm_asym.c. > > The commit message for tpm_asym.c does not document the design choice > in any possible way and still was merged to the mainline. > > Before knowning the answer to the "existential" question we are > somewhat paralyzed on moving forward with trusted keys (e.g. > paralyzed to merge TEE backend). > > Your proposal might make sense but I don't really want to say > anything since I'm completely cluesless of the role of the kernel > rng. Looks like everyone who participated to the review process of > tpm_asym.c, is too. The job of the in-kernel rng is simply to produce a mixed entropy pool from which we can draw random numbers. The idea is that quite a few attackers have identified the rng as being a weak point in the security architecture of the kernel, so if we mix entropy from all the sources we have, you have to compromise most of them to gain some predictive power over the rng sequence. The point is not how certified the TPM RNG is, the point is that it's a single source and if we rely on it solely for some applications, like trusted keys, then it gives the attackers a single known point to go after. This may be impossible for script kiddies, but it won't be for nation states ... are you going to exclusively trust the random number you got from your chinese certified TPM? Remember also that the attack doesn't have to be to the TPM only, it could be the pathway by which we get the random number, which involves components outside of the TPM certification. James
next prev parent reply other threads:[~2019-10-14 19:30 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-26 17:16 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 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 [this message] 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=1571081397.3728.9.camel@HansenPartnership.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] KEYS: asym_tpm: Switch to get_random_bytes()' \ /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
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).