On Wed, Sep 16, 2020 at 12:52:14PM -0700, James Bottomley wrote:
> On Tue, 2020-09-15 at 12:09 +0300, Jarkko Sakkinen wrote:
> > On Sat, Sep 12, 2020 at 10:26:41AM -0700, James Bottomley wrote:
> > > In TPM 1.2 an authorization was a 20 byte number. The spec
> > > actually recommended you to hash variable length passwords and use
> > > the sha1 hash as the authorization. Because the spec doesn't
> > > require this hashing, the current authorization for trusted keys is
> > > a 40 digit hex number. For TPM 2.0 the spec allows the passing in
> > > of variable length passwords and passphrases directly, so we should
> > > allow that in trusted keys for ease of use. Update the 'blobauth'
> > > parameter to take this into account, so we can now use plain text
> > > passwords for the keys.
> > >
> > > so before
> > >
> > > keyctl add trusted kmk "new 32
> > > blobauth=f572d396fae9206628714fb2ce00f72e94f2258f"
> > >
> > > after we will accept both the old hex sha1 form as well as a new
> > > directly supplied password:
> > >
> > > keyctl add trusted kmk "new 32 blobauth=hello keyhandle=81000001"
> > >
> > > Since a sha1 hex code must be exactly 40 bytes long and a direct
> > > password must be 20 or less, we use the length as the discriminator
> > > for which form is input.
> > >
> > > Note this is both and enhancement and a potential bug fix. The TPM
> > > 2.0 spec requires us to strip leading zeros, meaning empyty
> > > authorization is a zero length HMAC whereas we're currently passing
> > > in 20 bytes of zeros. A lot of TPMs simply accept this as OK, but
> > > the Microsoft TPM emulator rejects it with TPM_RC_BAD_AUTH, so this
> > > patch makes the Microsoft TPM emulator work with trusted keys.
> > >
> > > Fixes: 0fe5480303a1 ("keys, trusted: seal/unseal with TPM 2.0
> > > chips")
> > > Signed-off-by: James Bottomley
> > > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
> > > Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx>
> >
> > I created a key:
> >
> > $ sudo ./tpm2-root-key
> > 0x80000000
> > $ sudo ./tpm2-list-handles
> > 0x80000000
> > $ keyctl add trusted kmk "new 32 blobauth=hello keyhandle=0x80000000"
> > <keyctl usage>
>
> Well, you're getting that because the command isn't complete ... you
> need a keyring specifier at the end, like @u. However, even with that
> there's a bug in the code that would cause this to return EINVAL: the
> blobauth handler has a return 0 where it should have a break ... I
> think that happened as a result of the v6 rework which split up the if
> ... else if ... else chain. The result is the processing of options
> terminates at blobauth, so if it's last, as I've been testing with,
> everything is fine. If it's first as you specify, none of the options
> following the blobauth get processed. I'll fix this up and add an @u
> to the commit message.
Ugh, it's true, missing @u from the tail :-) And I was looking for a long
time old test script and this and wondering where is the difference...
Fix those so that we can finally merge this :-)
>
> James
>
/Jarkko
