All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Prestwood <prestwoj@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-integrity@vger.kernel.org
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	David Woodhouse <dwmw2@infradead.org>,
	keyrings@vger.kernel.org
Subject: Re: [PATCH v5 4/6] security: keys: trusted: use ASN.1 TPM2 key format for the blobs
Date: Thu, 27 Feb 2020 00:20:38 +0000	[thread overview]
Message-ID: <f9b64fe39eb71a1560ca2d1887238d0b4f9f111a.camel@gmail.com> (raw)
In-Reply-To: <1582761736.4245.12.camel@HansenPartnership.com>

> > I have been using your set of patches in order to get this ASN.1
> > parser/definition. I am implementing an asymmetric key parser/type
> > TPM2
> > keys for enc/dec/sign/verify using keyctl. Note that this
> > implementation goes in crypto/asymmetric_keys/, and your patches
> > sit
> > in
> > security/keys/trusted-keys/.
> > 
> > Currently I am just including "../../security/keys/trusted-
> > keys/{tpm2key.asn1.h,tpm2-policy.h}" in order to use the ASN.1
> > parser
> > to verify my keys, but this obviously isn't going to fly.
> > 
> > Do you (or anyone) have any ideas as to how both trusted keys and
> > asymmetric keys could share this ASN.1 parser/definition? Some
> > common
> > area that both security and crypto could include? Or maybe there is
> > some common way the kernel does things like this?
> 
> Actually TPM2 asymmetric keys was also on my list.  I was going to
> use
> the existing template and simply move it somewhere everyone could
> use. 
> I also think you need the policy parser pieces because at least one
> implementation we'd need to be compatible with supports key policy.

In terms of policy, I haven't looked into that at all for asymmetric
keys. I do already have enc/dec/sign/verify asymmetric key operations
all working, and used your ASN1 template for parsing (just copied it
into asymmetric_keys for now). Since the asymmetric operations use HMAC
sessions I didn't see much carry over from your patches (but this could
change if policy stuff gets introduced).

This will go in the eventual RFC soon but while I have you here:

I also implemented key wrapping. Exposing this as a keyctl API may take
some rework, hopefully with some help from others in this subsystem. As
it stand now you have to padd a key pair, then do a (new) pkey_wrap
operation on it. This returns a DER with the wrapped TPM2 key. This
required modifying the public_key type, which I really did not like
since it now depends on TPM. Not sure if the route I went is gonna fly
without tweaking, but this is all new to me :) Again, some guidance for
how this should be is needed.

Before I send these patches I need to get some testing done on real
TPM2 hardware. So far its just been emulation. But these patches should
be coming very soon.

Thanks,
James


 

> 
> Regards,
> 
> James
> 

WARNING: multiple messages have this Message-ID (diff)
From: James Prestwood <prestwoj@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-integrity@vger.kernel.org
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	David Woodhouse <dwmw2@infradead.org>,
	keyrings@vger.kernel.org
Subject: Re: [PATCH v5 4/6] security: keys: trusted: use ASN.1 TPM2 key format for the blobs
Date: Wed, 26 Feb 2020 16:20:38 -0800	[thread overview]
Message-ID: <f9b64fe39eb71a1560ca2d1887238d0b4f9f111a.camel@gmail.com> (raw)
In-Reply-To: <1582761736.4245.12.camel@HansenPartnership.com>

> > I have been using your set of patches in order to get this ASN.1
> > parser/definition. I am implementing an asymmetric key parser/type
> > TPM2
> > keys for enc/dec/sign/verify using keyctl. Note that this
> > implementation goes in crypto/asymmetric_keys/, and your patches
> > sit
> > in
> > security/keys/trusted-keys/.
> > 
> > Currently I am just including "../../security/keys/trusted-
> > keys/{tpm2key.asn1.h,tpm2-policy.h}" in order to use the ASN.1
> > parser
> > to verify my keys, but this obviously isn't going to fly.
> > 
> > Do you (or anyone) have any ideas as to how both trusted keys and
> > asymmetric keys could share this ASN.1 parser/definition? Some
> > common
> > area that both security and crypto could include? Or maybe there is
> > some common way the kernel does things like this?
> 
> Actually TPM2 asymmetric keys was also on my list.  I was going to
> use
> the existing template and simply move it somewhere everyone could
> use. 
> I also think you need the policy parser pieces because at least one
> implementation we'd need to be compatible with supports key policy.

In terms of policy, I haven't looked into that at all for asymmetric
keys. I do already have enc/dec/sign/verify asymmetric key operations
all working, and used your ASN1 template for parsing (just copied it
into asymmetric_keys for now). Since the asymmetric operations use HMAC
sessions I didn't see much carry over from your patches (but this could
change if policy stuff gets introduced).

This will go in the eventual RFC soon but while I have you here:

I also implemented key wrapping. Exposing this as a keyctl API may take
some rework, hopefully with some help from others in this subsystem. As
it stand now you have to padd a key pair, then do a (new) pkey_wrap
operation on it. This returns a DER with the wrapped TPM2 key. This
required modifying the public_key type, which I really did not like
since it now depends on TPM. Not sure if the route I went is gonna fly
without tweaking, but this is all new to me :) Again, some guidance for
how this should be is needed.

Before I send these patches I need to get some testing done on real
TPM2 hardware. So far its just been emulation. But these patches should
be coming very soon.

Thanks,
James


 

> 
> Regards,
> 
> James
> 


  reply	other threads:[~2020-02-27  0:20 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-30 10:18 [PATCH v5 0/6] TPM 2.0 trusted keys with attached policy James Bottomley
2020-01-30 10:18 ` James Bottomley
2020-01-30 10:18 ` [PATCH v5 1/6] lib: add ASN.1 encoder James Bottomley
2020-01-30 10:18   ` James Bottomley
2020-01-30 10:18 ` [PATCH v5 2/6] oid_registry: Add TCG defined OIDS for TPM keys James Bottomley
2020-01-30 10:18   ` James Bottomley
2020-01-30 10:18 ` [PATCH v5 3/6] security: keys: trusted fix tpm2 authorizations James Bottomley
2020-01-30 10:18   ` James Bottomley
2020-02-25 16:48   ` Jarkko Sakkinen
2020-02-25 16:48     ` Jarkko Sakkinen
2020-02-26 15:15     ` Jarkko Sakkinen
2020-02-26 15:15       ` Jarkko Sakkinen
2020-02-27  0:58     ` James Bottomley
2020-02-27  0:58       ` James Bottomley
2020-02-27 16:19       ` Jarkko Sakkinen
2020-02-27 16:19         ` Jarkko Sakkinen
2020-02-27 16:21         ` James Bottomley
2020-02-27 16:21           ` James Bottomley
2020-02-27 17:49           ` James Bottomley
2020-02-27 17:49             ` James Bottomley
2020-03-02 11:08             ` Jarkko Sakkinen
2020-03-02 11:08               ` Jarkko Sakkinen
2020-01-30 10:18 ` [PATCH v5 4/6] security: keys: trusted: use ASN.1 TPM2 key format for the blobs James Bottomley
2020-01-30 10:18   ` James Bottomley
2020-02-03 16:54   ` James Prestwood
2020-02-03 16:54     ` James Prestwood
2020-02-27  0:02     ` James Bottomley
2020-02-27  0:02       ` James Bottomley
2020-02-27  0:20       ` James Prestwood [this message]
2020-02-27  0:20         ` James Prestwood
2020-02-27  0:54         ` James Bottomley
2020-02-27  0:54           ` James Bottomley
2020-02-27 17:19           ` James Prestwood
2020-02-27 17:19             ` James Prestwood
2020-02-27 20:19             ` James Bottomley
2020-02-27 20:19               ` James Bottomley
2020-02-27 20:26               ` James Bottomley
2020-02-27 20:26                 ` James Bottomley
2020-02-27 20:44                 ` James Prestwood
2020-02-27 20:44                   ` James Prestwood
2020-02-27 20:57               ` James Prestwood
2020-02-27 20:57                 ` James Prestwood
2020-07-12 21:38                 ` Ken Goldman
2020-07-12 21:38                   ` Ken Goldman
2020-07-12 21:54                   ` James Bottomley
2020-07-12 21:54                     ` James Bottomley
2020-03-02 19:00               ` James Prestwood
2020-03-02 19:00                 ` James Prestwood
2020-01-30 10:18 ` [PATCH v5 5/6] security: keys: trusted: add ability to specify arbitrary policy James Bottomley
2020-01-30 10:18   ` James Bottomley
2020-01-30 10:18 ` [PATCH v5 6/6] security: keys: trusted: implement counter/timer policy James Bottomley
2020-01-30 10:18   ` James Bottomley
2020-02-20 20:17 ` [PATCH v5 0/6] TPM 2.0 trusted keys with attached policy Jarkko Sakkinen
2020-02-20 20:17   ` 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=f9b64fe39eb71a1560ca2d1887238d0b4f9f111a.camel@gmail.com \
    --to=prestwoj@gmail.com \
    --cc=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.