From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: linux-integrity@vger.kernel.org, Mimi Zohar <zohar@linux.ibm.com>,
David Woodhouse <dwmw2@infradead.org>,
keyrings@vger.kernel.org
Subject: Re: [PATCH v7 4/6] security: keys: trusted: use ASN.1 TPM2 key format for the blobs
Date: Mon, 09 Mar 2020 22:08:23 +0000 [thread overview]
Message-ID: <1583791703.6009.3.camel@HansenPartnership.com> (raw)
In-Reply-To: <1583762386.3429.6.camel@HansenPartnership.com>
On Mon, 2020-03-09 at 06:59 -0700, James Bottomley wrote:
> On Sun, 2020-03-08 at 00:00 +0200, Jarkko Sakkinen wrote:
> > On Wed, Mar 04, 2020 at 06:27:42PM -0800, James Bottomley wrote:
> > > Modify the TPM2 key format blob output to export and import in
> > > the ASN.1 form for TPM2 sealed object keys. For compatibility
> > > with prior trusted keys, the importer will also accept two TPM2B
> > > quantities representing the public and private parts of the
> > > key. However, the export via keyctl pipe will only output the
> > > ASN.1 format.
> > >
> > > The benefit of the ASN.1 format is that it's a standard and thus
> > > the exported key can be used by userspace tools
> > > (openssl_tpm2_engine, openconnect and tpm2-tss-engine). The
> > > format includes policy specifications, thus it gets us out of
> > > having to construct policy handles in userspace and the format
> > > includes the parent meaning you don't have to keep passing it in
> > > each time.
> > >
> > > This patch only implements basic handling for the ASN.1 format,
> > > so keys with passwords but no policy.
> > >
> > > Signed-off-by: James Bottomley
> > > <James.Bottomley@HansenPartnership.com>
> >
> > Not yet sure but I get
> >
> > keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha1
> > pcrinfo\x03000001 6768033e216468247bd031a0a2d9876d79818f8f" @u
> > add_key: No such device
>
> What's the last hex string? Is there supposed to be a command
> preceding it (like blobauth since there's 40 hex chars?).
>
> > After applying 1/6-4/6.
>
> As you guessed for most of the rebases I've been testing the whole
> set of patches. Let me wind back to 4/6 and have a look.
>
> > At this point I'm assuming that I've made mistake somewhere, which
> > is entirely possible.
>
> Heh, don't bet on it, I should be able to reconstruct the environment
> today and try it out.
OK, I got the environment constructed, and everything seems to work
fine for me.
However, there is still a problem with the patch. It appears in going
from v4->v5 two additional patches got folded into this one:
[PATCH v4 5/9] security: keys: trusted: Make sealed key properly
interoperable
[PATCH v4 6/9] security: keys: trusted: add PCR policy to TPM2 keys
I'll see if I can disentangle them otherwise the commit log saying we
don't add policy is completely wrong.
James
WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: linux-integrity@vger.kernel.org, Mimi Zohar <zohar@linux.ibm.com>,
David Woodhouse <dwmw2@infradead.org>,
keyrings@vger.kernel.org
Subject: Re: [PATCH v7 4/6] security: keys: trusted: use ASN.1 TPM2 key format for the blobs
Date: Mon, 09 Mar 2020 15:08:23 -0700 [thread overview]
Message-ID: <1583791703.6009.3.camel@HansenPartnership.com> (raw)
In-Reply-To: <1583762386.3429.6.camel@HansenPartnership.com>
On Mon, 2020-03-09 at 06:59 -0700, James Bottomley wrote:
> On Sun, 2020-03-08 at 00:00 +0200, Jarkko Sakkinen wrote:
> > On Wed, Mar 04, 2020 at 06:27:42PM -0800, James Bottomley wrote:
> > > Modify the TPM2 key format blob output to export and import in
> > > the ASN.1 form for TPM2 sealed object keys. For compatibility
> > > with prior trusted keys, the importer will also accept two TPM2B
> > > quantities representing the public and private parts of the
> > > key. However, the export via keyctl pipe will only output the
> > > ASN.1 format.
> > >
> > > The benefit of the ASN.1 format is that it's a standard and thus
> > > the exported key can be used by userspace tools
> > > (openssl_tpm2_engine, openconnect and tpm2-tss-engine). The
> > > format includes policy specifications, thus it gets us out of
> > > having to construct policy handles in userspace and the format
> > > includes the parent meaning you don't have to keep passing it in
> > > each time.
> > >
> > > This patch only implements basic handling for the ASN.1 format,
> > > so keys with passwords but no policy.
> > >
> > > Signed-off-by: James Bottomley
> > > <James.Bottomley@HansenPartnership.com>
> >
> > Not yet sure but I get
> >
> > keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha1
> > pcrinfo=03000001 6768033e216468247bd031a0a2d9876d79818f8f" @u
> > add_key: No such device
>
> What's the last hex string? Is there supposed to be a command
> preceding it (like blobauth since there's 40 hex chars?).
>
> > After applying 1/6-4/6.
>
> As you guessed for most of the rebases I've been testing the whole
> set of patches. Let me wind back to 4/6 and have a look.
>
> > At this point I'm assuming that I've made mistake somewhere, which
> > is entirely possible.
>
> Heh, don't bet on it, I should be able to reconstruct the environment
> today and try it out.
OK, I got the environment constructed, and everything seems to work
fine for me.
However, there is still a problem with the patch. It appears in going
from v4->v5 two additional patches got folded into this one:
[PATCH v4 5/9] security: keys: trusted: Make sealed key properly
interoperable
[PATCH v4 6/9] security: keys: trusted: add PCR policy to TPM2 keys
I'll see if I can disentangle them otherwise the commit log saying we
don't add policy is completely wrong.
James
next prev parent reply other threads:[~2020-03-09 22:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-05 2:27 [PATCH v7 0/6] TPM 2.0 trusted keys with attached policy James Bottomley
2020-03-05 2:27 ` James Bottomley
2020-03-05 2:27 ` [PATCH v7 1/6] lib: add ASN.1 encoder James Bottomley
2020-03-05 2:27 ` James Bottomley
2020-03-05 16:20 ` James Bottomley
2020-03-05 16:20 ` James Bottomley
2020-03-06 19:10 ` Jarkko Sakkinen
2020-03-06 19:10 ` Jarkko Sakkinen
2020-03-05 2:27 ` [PATCH v7 2/6] oid_registry: Add TCG defined OIDS for TPM keys James Bottomley
2020-03-05 2:27 ` James Bottomley
2020-03-05 2:27 ` [PATCH v7 3/6] security: keys: trusted: fix TPM2 authorizations James Bottomley
2020-03-05 2:27 ` James Bottomley
2020-03-06 19:52 ` Jarkko Sakkinen
2020-03-06 19:52 ` Jarkko Sakkinen
2020-03-05 2:27 ` [PATCH v7 4/6] security: keys: trusted: use ASN.1 TPM2 key format for the blobs James Bottomley
2020-03-05 2:27 ` James Bottomley
2020-03-06 20:03 ` Jarkko Sakkinen
2020-03-06 20:03 ` Jarkko Sakkinen
2020-03-07 22:00 ` Jarkko Sakkinen
2020-03-07 22:00 ` Jarkko Sakkinen
2020-03-09 13:59 ` James Bottomley
2020-03-09 13:59 ` James Bottomley
2020-03-09 22:08 ` James Bottomley [this message]
2020-03-09 22:08 ` James Bottomley
2020-03-05 2:27 ` [PATCH v7 5/6] security: keys: trusted: add ability to specify arbitrary policy James Bottomley
2020-03-05 2:27 ` James Bottomley
2020-03-05 2:27 ` [PATCH v7 6/6] security: keys: trusted: implement counter/timer policy James Bottomley
2020-03-05 2:27 ` James Bottomley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1583791703.6009.3.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=dwmw2@infradead.org \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.