On Mon, Oct 14, 2019 at 10:00:33PM +0300, Jarkko Sakkinen wrote: > On Wed, Oct 09, 2019 at 12:11:06PM +0000, Safford, David (GE Global Research, US) wrote: > > > > > From: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> > > > Sent: Tuesday, October 8, 2019 7:54 PM > > > To: Ken Goldman <kgold@xxxxxxxxxxxxx> > > > Cc: Safford, David (GE Global Research, US) <david.safford@xxxxxx>; Mimi > > > Zohar <zohar@xxxxxxxxxxxxx>; linux-integrity@xxxxxxxxxxxxxxx; > > > stable@xxxxxxxxxxxxxxx; open list:ASYMMETRIC KEYS > > > <keyrings@xxxxxxxxxxxxxxx>; open list:CRYPTO API <linux- > > > crypto@xxxxxxxxxxxxxxx>; open list <linux-kernel@xxxxxxxxxxxxxxx> > > > 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/tpm-certi > > > > > fied-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. As a ABI backwards compatibility workaround I'd agree most likely agree with you. As a guideline for new features there should be a framework on how to decide what to do. /Jarkko
