grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v8 16/22] tpm2: Support authorized policy


From: James Bottomley
Subject: Re: [PATCH v8 16/22] tpm2: Support authorized policy
Date: Mon, 05 Feb 2024 08:48:53 +0000
User-agent: Evolution 3.42.4

On Mon, 2024-02-05 at 15:27 +0800, Gary Lin via Grub-devel wrote:
> On Wed, Jan 17, 2024 at 04:13:17PM +0800, Gary Lin wrote:
> > On Tue, Jan 16, 2024 at 10:39:45AM -0500, James Bottomley wrote:
> > > On Tue, 2024-01-16 at 17:20 +0800, Gary Lin via Grub-devel wrote:
> > > [...]
> > > > (*1)
> > > > https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html
> > > > (*2) https://github.com/okirch/pcr-oracle
> > > 
> > > Just a curiosity question, but have you tested the
> > > interoperability of
> > > pcr-oracle keys?  It looks like you got the ASN header straight
> > > from
> > > openssl_tpm2_engine, so it should all just work, but verifying
> > > that the
> > > seal/unseal and sign_tpm2_policy commands from
> > > openssl_tpm2_engine:
> > > 
> > > https://build.opensuse.org/package/show/security:tls/openssl_tpm2_engine
> > > 
> > > can be used to create sealed keys for this code would nicely
> > > verify
> > > that.
> > > 
> > I have to admit that the interoperability is not considered since
> > the
> > sealed key is designed to be only valid in a short window and
> > capped
> > after load linux kernel. However, it'd be nice to verify the format
> > with
> > other programs like openssl_tpm2_engine.
> > 
> > My playground of grub2 is an openSUSE Tumbleweed VM and
> > openssl_tpm2_engine is available. Will check if the key file from
> > pcr-oracle works for openssl_tpm2_engine.
> > 
> I did quick check, and the major difference between pcr-oracle and
> openssl_tpm2_engine is the assumption of SRK. pcr-oracle choose RSA
> 2048 or above for the SRK template while openssl_tpm2_engine assumes
> ECC to be used as SRK,

Right that's because the standard says you have to (in section 3.1.6):

   If a permanent handle (MSO 0x40) is specified then the
   implementation MUST run TPM2_CreatePrimary on the handle using the
   TCG specified Elliptic Curve template [TCG-Provision] (section 7.5.1
   for the Storage and other seeds or 7.4.1 for the endorsement seed)
   for the NIST P-256 curve and use the primary key so generated as the
   parent.

It was for two reasons: 1) so we all derive the same parent for
interoperability and 2) because some TPMs take forever to derive an RSA
primary (my current one takes 7s and my previous one took 50s)

>  and openssl_tpm2_engine failed to unseal the key file
> created by pcr-oracle. Anyway, at least 'signed_tpm2_policy' can list
> the signed polices in the key.

Bus is there a reason we shouldn't be fully interoperable?

James




reply via email to

[Prev in Thread] Current Thread [Next in Thread]