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: Gary Lin
Subject: Re: [PATCH v8 16/22] tpm2: Support authorized policy
Date: Tue, 6 Feb 2024 14:12:11 +0800

On Mon, Feb 05, 2024 at 08:48:53AM +0000, James Bottomley wrote:
> 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.
> 
Hmmm, I overlooked this part.

> 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)
> 
The default template of SRK is inherited from the original TPM patches.
Besides, we got some opinions against ECC during internal review, so RSA
remains default. As for grub2, there is an option for the SRK algorithm:

https://github.com/lcp/grub2/blob/tpm2-unlock-v9/grub-core/tpm2/module.c#L134-L145
https://github.com/lcp/grub2/blob/tpm2-unlock-v9/grub-core/tpm2/args.c#L79-L138

So that the user can choose the preferred SRK algorithm like this:

tpm2_key_protector_init -a ECC_NIST_P256 -T sealed.tpm

Although the user still can specify the SRK template with the persistent
handles, I'd try not to occupy those handles since those are limited
resources. Is it possible to relax the standard a bit to allow the SRK 
algorithm to be chosen?

Thanks,

Gary Lin

> >  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]