linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Ken Goldman <kgold@linux.ibm.com>
Cc: linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH v4 0/7] add integrity and security to TPM2 transactions
Date: Wed, 24 Oct 2018 08:34:16 +0100	[thread overview]
Message-ID: <1540366456.3008.8.camel@HansenPartnership.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1810240303560.8524@jsakkine-mobl1>

On Wed, 2018-10-24 at 03:06 +0300, Jarkko Sakkinen wrote:
> On Mon, 22 Oct 2018, Ken Goldman wrote:
> > Does this design assume that there was at time zero no monitoring?
> > This would permit some shared secret to be established.
> > 
> > Or does it assume that the interception may have been present from
> > the first boot?  If so, how is the first shared secret established.
> > Salting using the EK is the usual method, but this requires walking
> > the EK certificate chain and embedding the TPM vendor CA
> > certificates in the kernel.
> 
> Kernel gets the public portion EK and uses its own key pair in its
> own end so everything should be good, right?

Only if we pass it in.  The kernel can't run an X509 proof on the EK
certificate, which is how you verify the EK:  Usually the X509 cert is
RSA, and for speed and efficiency we're salting with Elliptic Curve
keys, so we'd have to derive the RSA EK primary (which can take up to
60 seconds), verify the same public key as the cert and then chain up
to the manufacturer. Then we'd have to use the RSA keys (so a lot more
code) because we can't trust the TPM not to lie about the RSA public
key but then substitute it's own EC primary. We really don't want to be
trying to do all that on boot.

James


  reply	other threads:[~2018-10-24  7:34 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-22  7:33 [PATCH v4 0/7] add integrity and security to TPM2 transactions James Bottomley
2018-10-22  7:35 ` [PATCH v4 1/7] tpm-buf: create new functions for handling TPM buffers James Bottomley
2018-10-23 19:12   ` Jarkko Sakkinen
2018-10-23 19:16   ` Jarkko Sakkinen
2018-10-22  7:36 ` [PATCH v4 2/7] tpm2-sessions: Add full HMAC and encrypt/decrypt session handling James Bottomley
2018-10-22 22:19   ` Ard Biesheuvel
2018-10-23  7:01     ` James Bottomley
2018-10-23 10:08       ` Ard Biesheuvel
2018-10-24  8:40         ` Jarkko Sakkinen
2018-10-23 23:48   ` Jarkko Sakkinen
2018-10-24  9:31     ` James Bottomley
2018-10-25 15:56       ` Jarkko Sakkinen
2018-10-22  7:37 ` [PATCH v4 3/7] tpm2: add hmac checks to tpm2_pcr_extend() James Bottomley
2018-10-22  7:37 ` [PATCH v4 4/7] tpm2: add session encryption protection to tpm2_get_random() James Bottomley
2018-10-22  7:38 ` [PATCH v4 5/7] trusted keys: Add session encryption protection to the seal/unseal path James Bottomley
2018-10-24  0:03   ` Jarkko Sakkinen
2018-10-22  7:39 ` [PATCH v4 6/7] tpm: add the null key name as a tpm2 sysfs variable James Bottomley
2018-10-22  7:40 ` [PATCH v4 7/7] tpm2-sessions: NOT FOR COMMITTING add sessions testing James Bottomley
2018-10-22 13:53 ` [PATCH v4 0/7] add integrity and security to TPM2 transactions Ken Goldman
2018-10-22 14:18   ` James Bottomley
2018-10-22 15:50     ` Ken Goldman
2018-10-22 15:55       ` James Bottomley
2018-10-24  0:13     ` Jarkko Sakkinen
2018-10-24  7:41       ` James Bottomley
2018-10-25 15:39         ` Jarkko Sakkinen
2018-10-24  0:06   ` Jarkko Sakkinen
2018-10-24  7:34     ` James Bottomley [this message]
2018-10-25 16:53       ` Ken Goldman
2018-10-23 23:51 ` Jarkko Sakkinen
2018-10-24  7:43   ` James Bottomley
2018-10-25 15:42     ` 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=1540366456.3008.8.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=kgold@linux.ibm.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /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).