All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-integrity@vger.kernel.org
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	David Woodhouse <dwmw2@infradead.org>,
	keyrings@vger.kernel.org
Subject: Re: [PATCH v4 5/9] security: keys: trusted: Make sealed key properly interoperable
Date: Mon, 06 Jan 2020 21:58:18 +0000	[thread overview]
Message-ID: <482ad14deb25b1323c0079fb120fdf0ffd0724b3.camel@linux.intel.com> (raw)
In-Reply-To: <20191230173802.8731-6-James.Bottomley@HansenPartnership.com>

On Mon, 2019-12-30 at 09:37 -0800, James Bottomley wrote:
> The current implementation appends a migratable flag to the end of a
> key, meaning the format isn't exactly interoperable because the using
> party needs to know to strip this extra byte.  However, all other
> consumers of TPM sealed blobs expect the unseal to return exactly the
> key.  Since TPM2 keys have a key property flag that corresponds to
> migratable, use that flag instead and make the actual key the only
> sealed quantity.  This is secure because the key properties are bound
> to a hash in the private part, so if they're altered the key won't
> load.
> 
> Backwards compatibility is implemented by detecting whether we're
> loading a new format key or not and correctly setting migratable from
> the last byte of old format keys.
> 
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>

I'll stop review here as I'm now quite confident that in high-level
this going to right direction.

For remaining patches:

- Be more explict with the tools. That will also give a framework to
  easily test the patches.
- Same remarks for the code formatting as I gave to earlier.

/Jarkko

WARNING: multiple messages have this Message-ID (diff)
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-integrity@vger.kernel.org
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	David Woodhouse <dwmw2@infradead.org>,
	keyrings@vger.kernel.org
Subject: Re: [PATCH v4 5/9] security: keys: trusted: Make sealed key properly interoperable
Date: Mon, 06 Jan 2020 23:58:18 +0200	[thread overview]
Message-ID: <482ad14deb25b1323c0079fb120fdf0ffd0724b3.camel@linux.intel.com> (raw)
In-Reply-To: <20191230173802.8731-6-James.Bottomley@HansenPartnership.com>

On Mon, 2019-12-30 at 09:37 -0800, James Bottomley wrote:
> The current implementation appends a migratable flag to the end of a
> key, meaning the format isn't exactly interoperable because the using
> party needs to know to strip this extra byte.  However, all other
> consumers of TPM sealed blobs expect the unseal to return exactly the
> key.  Since TPM2 keys have a key property flag that corresponds to
> migratable, use that flag instead and make the actual key the only
> sealed quantity.  This is secure because the key properties are bound
> to a hash in the private part, so if they're altered the key won't
> load.
> 
> Backwards compatibility is implemented by detecting whether we're
> loading a new format key or not and correctly setting migratable from
> the last byte of old format keys.
> 
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>

I'll stop review here as I'm now quite confident that in high-level
this going to right direction.

For remaining patches:

- Be more explict with the tools. That will also give a framework to
  easily test the patches.
- Same remarks for the code formatting as I gave to earlier.

/Jarkko


  reply	other threads:[~2020-01-06 21:58 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-30 17:37 [PATCH v4 0/9] TPM 2.0 trusted keys with attached policy James Bottomley
2019-12-30 17:37 ` James Bottomley
2019-12-30 17:37 ` [PATCH v4 1/9] lib: add asn.1 encoder James Bottomley
2019-12-30 17:37   ` James Bottomley
2020-01-06 18:09   ` Jarkko Sakkinen
2020-01-06 18:09     ` Jarkko Sakkinen
2020-01-07  0:17     ` James Bottomley
2020-01-07  0:17       ` James Bottomley
2019-12-30 17:37 ` [PATCH v4 2/9] oid_registry: Add TCG defined OIDS for TPM keys James Bottomley
2019-12-30 17:37   ` James Bottomley
2019-12-30 17:37 ` [PATCH v4 3/9] security: keys: trusted fix tpm2 authorizations James Bottomley
2019-12-30 17:37   ` James Bottomley
2020-01-06 21:45   ` Jarkko Sakkinen
2020-01-06 21:45     ` Jarkko Sakkinen
2020-01-06 21:48     ` Jarkko Sakkinen
2020-01-06 21:48       ` Jarkko Sakkinen
2020-01-07  1:08     ` James Bottomley
2020-01-07  1:08       ` James Bottomley
2020-01-08 16:19       ` Jarkko Sakkinen
2020-01-08 16:19         ` Jarkko Sakkinen
2019-12-30 17:37 ` [PATCH v4 4/9] security: keys: trusted: use ASN.1 tpm2 key format for the blobs James Bottomley
2019-12-30 17:37   ` James Bottomley
2020-01-06 21:53   ` Jarkko Sakkinen
2020-01-06 21:53     ` Jarkko Sakkinen
2019-12-30 17:37 ` [PATCH v4 5/9] security: keys: trusted: Make sealed key properly interoperable James Bottomley
2019-12-30 17:37   ` James Bottomley
2020-01-06 21:58   ` Jarkko Sakkinen [this message]
2020-01-06 21:58     ` Jarkko Sakkinen
2019-12-30 17:37 ` [PATCH v4 6/9] security: keys: trusted: add PCR policy to TPM2 keys James Bottomley
2019-12-30 17:37   ` James Bottomley
2019-12-30 17:38 ` [PATCH v4 7/9] security: keys: trusted: add ability to specify arbitrary policy James Bottomley
2019-12-30 17:38   ` James Bottomley
2019-12-30 17:38 ` [PATCH v4 8/9] security: keys: trusted: implement counter/timer policy James Bottomley
2019-12-30 17:38   ` James Bottomley
2019-12-30 17:38 ` [PATCH v4 9/9] security: keys: trusted: add password based authorizations to policy keys James Bottomley
2019-12-30 17:38   ` James Bottomley
2019-12-31 16:05 ` [PATCH v4 0/9] TPM 2.0 trusted keys with attached policy Jarkko Sakkinen
2019-12-31 16:05   ` Jarkko Sakkinen

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=482ad14deb25b1323c0079fb120fdf0ffd0724b3.camel@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dwmw2@infradead.org \
    --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.