linux-kernel - Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151003103540.GA10220@intel.com>
Date:	Sat, 3 Oct 2015 13:35:40 +0300
From:	Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:	"Fuchs, Andreas" <andreas.fuchs@....fraunhofer.de>
Cc:	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	David Safford <safford@...ibm.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Howells <dhowells@...hat.com>,
	"open list:KEYS-TRUSTED" <linux-security-module@...r.kernel.org>,
	"tpmdd-devel@...ts.sourceforge.net" 
	<tpmdd-devel@...ts.sourceforge.net>,
	"open list:KEYS-TRUSTED" <keyrings@...r.kernel.org>,
	James Morris <james.l.morris@...cle.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM
 2.0 chips

On Sat, Oct 03, 2015 at 01:26:55PM +0300, Jarkko Sakkinen wrote:
> On Sat, Oct 03, 2015 at 10:00:59AM +0000, Fuchs, Andreas wrote:
> > Hi Jarkko,
> > 
> > [snip]
> > 
> > diff --git a/security/keys/trusted.h b/security/keys/trusted.h
> > index ff001a5..fc32c47 100644
> > --- a/security/keys/trusted.h
> > +++ b/security/keys/trusted.h
> > @@ -12,6 +12,13 @@
> >  #define TPM_RETURN_OFFSET              6
> >  #define TPM_DATA_OFFSET                        10
> > 
> > +/* Transient object handles start from 0x80000000 in TPM 2.0, which makes it
> > + * a sane default.
> > + */
> > +
> > +#define TPM1_SRKHANDLE 0x40000000
> > +#define TPM2_SRKHANDLE 0x80000000
> > +
> >  #define LOAD32(buffer, offset) (ntohl(*(uint32_t *)&buffer[offset]))
> >  #define LOAD32N(buffer, offset)        (*(uint32_t *)&buffer[offset])
> >  #define LOAD16(buffer, offset) (ntohs(*(uint16_t *)&buffer[offset]))
> > 
> > This TPM2_SRKHANDLE is unfortunately wrong.
> > 
> > Transient handles are assigned and returned by the TPM following the
> > commands TPM2_CreatePrimary, TPM2_LoadObject and TPM2_ContextLoad. You
> > can only use transient handles as returned by the TPM in order to
> > refer to the corresponding object created inside the TPM via these
> > commands. They can never assumed to be constant. The fact that TPMs
> > return 0x80000000 for the first loaded Object and 0x80000001 for the
> > second is merely a coincidence... ;-)
> > 
> > TPM2 also has no (single) SRK anymore. You have to create your own SRK
> > / Storage Primary Keys via TPM2_CreatePrimary and use the transient
> > handle returned from there. This however requires SH-authorization,
> > usually via Policy IMHO, so not easy to manage. So IMHO, this might be
> > something for the future but for the moment relying on a persistent
> > key would be better...
> > 
> > For persistent SRKs it should become a convention to have those
> > around. Those handles start with 0x81000000 and the SRKs (or Storage
> > primary Keys) shall live within 0x81000000 to 0x8100FFFF (see
> > http://www.trustedcomputinggroup.org/resources/registry_of_reserved_tpm_20_handles_and_localities)
> > 
> > I'd recommend to rely on the existence of a handle inside this range
> > with an empty auth-value. So maybe install a persistent SRK to
> > 0x81000000 via TPM2_EvictControl and then use this from within the
> > kernel for anything following.
> > P.S. You should check for the key's TPMA_OBJECT to have fixedTPM SET.
> > I don't know if there is an actual test for owner-generated SRK
> > testing. I'll ask around though...
> > 
> > Note: you can query for handles in this range via
> > TPM2_GetCapability(TPM_CAP_HANDLES, 0x81000000) and then look for
> > fitting keys.
> > 
> > 
> > Feel free to discuss other approaches.
> 
> I'm fully aware of all what you said. My take was to use 0x800000000 as
> a default value if you don't the handle ID explicitly in 'description'
> parameter of the add_key() syscall.

I don't know how much you've done user space code that uses TPM2 chip.
I'm not saying I've written a lot of it but here's my experience.

In Haswell/PTT you can have 3 transient handles at a time. How you use
them is as follows:

1. Load/create your data to TPM filling transient handles starting from
   0x80000000.
2. Do your sealing/unsealing/whatever.
3. Flush transient handles.

For single handle use cases transient handle is in practice always
0x80000000 so it's very convenient to have that as the default value.

I think you are looking at this too much from specification point of
view. I've chosen the approach that is most convenient to use even
though the handle does not have exactly the same semantics as with TPM
1.x.

> > Cheers,
> > Andreas
> 
> /Jarkko

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/