Re: [PATCH] tpm: Disable TCG_TPM2_HMAC by default

[Jarkko Sakkinen <jarkko.sakkinen@iki.fi>]

On Fri, Aug 15, 2025 at 08:58:06PM +0300, Jarkko Sakkinen wrote:
> On Fri, Aug 15, 2025 at 08:52:35PM +0300, Jarkko Sakkinen wrote:
> > On Fri, Aug 15, 2025 at 08:45:48PM +0300, Jarkko Sakkinen wrote:
> > > On Fri, Aug 15, 2025 at 10:06:36AM -0700, Chris Fenner wrote:
> > > > On Fri, Aug 15, 2025 at 9:27 AM Jarkko Sakkinen <jarkko.sakkinen@iki.fi> wrote:
> > > > 
> > > > > I'll with shoot another proposal. Let's delete null primary creation
> > > > > code and add a parameter 'tpm.integrity_handle', which will refers to
> > > > > persistent primary handle:
> > > > 
> > > > I'm not yet sure I understand which handle you mean, or what you're
> > > > proposing to do with it. Could you elaborate?
> > > 
> > > Primary key persistent handle.
> > > 
> > > In tpm2_start_auth_session() there's
> > > 
> > > 	/* salt key handle */
> > > 	tpm_buf_append_u32(&buf, null_key);
> > > 
> > > Which would become
> > > 
> > > 	/* salt key handle */
> > > 	tpm_buf_append_u32(&buf, integrity_handle);
> > > 
> > > And in beginning of exported functions from tpm2-sessions.c:
> > > 
> > > 	if (!integrity_handle)
> > > 		return 0;
> > > 
> > > And delete from same file:
> > > 
> > > 	1. tpm2_create_*()
> > > 	2. tpm2_load_null()
> > > 
> > > That way the feature makes sense and does not disturb the user who don't
> > > want it as PCRs and random numbers will be integrity proteced agains an
> > > unambiguous key that can be certified.
> > 
> > E.g., for example that will unquestionably harden IMA exactly for the
> > same reasons why some user space software might to choose to use HMAC
> > based integrity protection.
> > 
> > At data center, there's guards and guns but for appliences, but there
> > is also the market appliances, home server products etc. They are not
> > mobile but neither they are protected in the same as e.g., a data
> > center is.
> > 
> > This is not to admit that right now the feature is no good to anyone
> > but in a selected set of use cases with this modification it would
> > make e.g., IMA's security *worse* than it would be with the feature
> > enabled.
> 
> One product example would be "blockchain node as a box" i.e., it carries
> momentary value inside. I could imagine this type of products exist or
> to be created (especially given proof-of-stake blockchains).
> 
> In such product, you don't have much to measure but you wan to take all
> of the security that you have to harden the protection of that small
> amount of data.

I'm happy to make patch next week for this change too. So probably this
where I align myself to. It's just the best average IMHO. Everyone gets
exactly what they want, right?

BR, Jarkko