From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: David Woodhouse <dwmw2@infradead.org>, linux-integrity@vger.kernel.org
Cc: Mimi Zohar <zohar@linux.ibm.com>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Subject: Re: [PATCH 6/8] security: keys: trusted: add PCR policy to TPM2 keys
Date: Mon, 09 Dec 2019 10:03:11 -0800 [thread overview]
Message-ID: <1575914591.31378.11.camel@HansenPartnership.com> (raw)
In-Reply-To: <c2de442430dc0e6cd8e66af8479f6cc382545ac5.camel@infradead.org>
On Mon, 2019-12-09 at 10:18 +0000, David Woodhouse wrote:
> On Sat, 2019-12-07 at 21:12 -0800, James Bottomley wrote:
> > This commit adds the ability to specify a PCR lock policy to TPM2
> > keys. There is a complexity in that the creator of the key must
> > chose either to use a PCR lock policy or to use authentication. At
> > the current time they can't use both due to a complexity with the
> > way authentication works when policy registers are in use. The way
> > to construct a pcrinfo statement for a key is simply to use the
> > TPMS_PCR_SELECT structure to specify the PCRs and follow this by a
> > hash of all their values in order of ascending PCR number.
> >
> > For simplicity, we require the policy name hash and the hash used
> > for the PCRs to be the same. Thus to construct a policy around the
> > value of the resettable PCR 16 using the sha1 bank, first reset the
> > pcr to zero giving a hash of all zeros as:
> >
> > 6768033e216468247bd031a0a2d9876d79818f8f
> >
> > Then the TPMS_PCR_SELECT value for PCR 16 is
> >
> > 03000001
> >
> > So create a new 32 byte key with a policy policy locking the key to
> > this value of PCR 16 with a parent key of 81000001 would be:
> >
> > keyctl new 32 keyhandle=0x81000001 hash=sha1
> > pcrinfo=030000016768033e216468247bd031a0a2d9876d79818f8f" @u
>
> OK... but I've love to see a more formal definition of this binary
> format, as part of the "standard" we allegedly have for the overall
> ASN.1 representation.
It's actually defined in the TPM2 command manual ... it's basically the
policy commands you send to the TPM ordered so they can be directly
hashed.
However, I agree a standards definition would be good. This format
doesn't support TPM2_PolicyOr directly (and the command manual is
silent on how it should be supported), so that's going to have to be
defined in the standard anyway.
[...]
> > +int tpm2_encode_policy(struct tpm2_policies *pols, u8 **data, u32
> > *len)
> > +{
> > + u8 *buf = kmalloc(2 * PAGE_SIZE, GFP_KERNEL);
> > + u8 *work = buf + PAGE_SIZE, *ptr;
> > + int i;
> > +
> > + if (!buf)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < pols->count; i++) {
> > + u8 *seq_len, *tag_len;
> > + u32 cmd = pols->code[i];
> > + int l;
> > +
> > + /*
> > + * cheat a bit here: we know a policy is < 128
> > bytes,
> > + * so the sequence and cons tags will only be two
> > + * bytes long
> > + */
> > + *work++ = _tag(UNIV, CONS, SEQ);
> > + seq_len = work++;
> > + *work++ = _tagn(CONT, CONS, 0);
> > + tag_len = work++;
> > + asn1_encode_integer(&work, cmd);
> > + *tag_len = work - tag_len - 1;
> > + *work++ = _tagn(CONT, CONS, 1);
> > + tag_len = work++;
> > + asn1_encode_octet_string(&work, pols->policies[i],
> > + pols->len[i]);
> > + *tag_len = work - tag_len - 1;
> > + l = work - seq_len - 1;
> > + /* our assumption about policy length failed */
> > + if (WARN(l > 127,
> > + "policy is too long: %d but must be <
> > 128", l)) {
> > + kfree(buf);
> > + return -EINVAL;
> > + }
> > + *seq_len = l;
>
>
>
> You're not even using your own sequence encoding here, because it
> only works when you know the length in advance. How about setting
> *seq_len to 0x80 to start with, for an indeterminate length.
I already did that in the asn.1 patch, so I've updated this one to use
it.
> Then in the happy case where it is <128, just go back and fill it in
> as you currently do. Otherwise append 0x00 0x00 as the end marker.
That doesn't work ... the format of these octet strings is likely to
have two zeros together, so they *have* to be definite length encoded.
> None of this has to be DER, does it?
None of what? The policy? the DER format is already in use so we
can't change it.
> <Insert more whining about PAGE_SIZE assumptions and buffer
> overflows>
OK, OK, I fixed that too.
James
next prev parent reply other threads:[~2019-12-09 18:03 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-08 5:06 [PATCH 0/8] Fix TPM 2.0 trusted keys James Bottomley
2019-12-08 5:07 ` [PATCH 1/8] security: keys: trusted: flush the key handle after use James Bottomley
2019-12-09 8:31 ` David Woodhouse
2019-12-09 15:38 ` James Bottomley
2019-12-08 5:08 ` [PATCH 2/8] lib: add asn.1 encoder James Bottomley
2019-12-09 8:50 ` David Woodhouse
2019-12-09 15:46 ` James Bottomley
2019-12-09 22:05 ` Matthew Garrett
2019-12-09 22:43 ` James Bottomley
2019-12-08 5:09 ` [PATCH 3/8] oid_registry: Add TCG defined OIDS for TPM keys James Bottomley
2019-12-09 8:55 ` David Woodhouse
2019-12-09 16:21 ` James Bottomley
2020-06-19 20:45 ` Wiseman, Monty (GE Research, US)
2020-06-19 22:50 ` Jerry Snitselaar
2020-06-20 15:36 ` James Bottomley
2020-06-23 1:17 ` Jarkko Sakkinen
2019-12-08 5:10 ` [PATCH 4/8] security: keys: trusted: use ASN.1 tpm2 key format for the blobs James Bottomley
2019-12-09 10:04 ` David Woodhouse
2019-12-09 16:31 ` James Bottomley
2019-12-08 5:11 ` [PATCH 5/8] security: keys: trusted: Make sealed key properly interoperable James Bottomley
2019-12-09 10:09 ` David Woodhouse
2019-12-09 17:23 ` James Bottomley
2019-12-08 5:12 ` [PATCH 6/8] security: keys: trusted: add PCR policy to TPM2 keys James Bottomley
2019-12-09 10:18 ` David Woodhouse
2019-12-09 18:03 ` James Bottomley [this message]
2019-12-09 18:44 ` David Woodhouse
2019-12-09 19:11 ` James Bottomley
2019-12-25 17:08 ` Ken Goldman
2019-12-08 5:13 ` [PATCH 7/8] security: keys: trusted: add ability to specify arbitrary policy James Bottomley
2019-12-08 5:14 ` [PATCH 8/8] security: keys: trusted: implement counter/timer policy James Bottomley
2019-12-09 20:20 ` [PATCH 0/8] Fix TPM 2.0 trusted keys Jarkko Sakkinen
2019-12-09 20:57 ` 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=1575914591.31378.11.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=dwmw2@infradead.org \
--cc=jarkko.sakkinen@linux.intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).