[RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

classic Classic list List threaded Threaded
81 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

[RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

James Bottomley
[David Woodhouse told me that openssl-dev is a closed list, so the
original messages got trashed.  This is a resend with apologies to
David and Peter]

One of the principle problems of using TPM based keys is that there's
no easy way of integrating them with standard file based keys.  This
proposal adds a generic method for handling file based engine keys that
can be loaded as PEM files.  Integration into the PEM loader requires a
BIO based engine API callback which the first patch adds.  The second
patch checks to see if the key can be loaded by any of the present
engines.  Note that this requires that any engine which is to be used
must be present and initialised via openssl.cnf.

I'll also post to this list the patch to openssl_tpm_engine that makes
use if this infrastructure so the integration of the whole can be seen.
 It should also be noted that gnutls has had this functionality since
2012.

The patch was done against 1.0.2h for easier testing and you can try it
and the openssl_tpm_engine out (if you run openSUSE) here:

https://build.opensuse.org/project/show/home:jejb1:Tumbleweed

James

---

James Bottomley (2):
  engine: add new flag based method for loading engine keys
  pem: load engine keys

 crypto/engine/eng_int.h  |  1 +
 crypto/engine/eng_pkey.c | 38 ++++++++++++++++++++++++++++++++++++++
 crypto/engine/engine.h   | 26 ++++++++++++++++++++++++++
 crypto/pem/pem_pkey.c    |  5 +++++
 4 files changed, 70 insertions(+)

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Blumenthal, Uri - 0553 - MITLL
My apologies – I don’t fully understand “file based engine keys”. I thought the keys were either on a hardware device (a TPM, a PKCS#11-accessible HSM or smartcard, etc), or in a file. If a key is in a file – it’s not an “engine key”.

What am I missing, and what’s your use case(s)?

Regards,
Uri


On 11/16/16, 10:46 AM, "openssl-dev on behalf of James Bottomley" <[hidden email] on behalf of [hidden email]> wrote:

    [David Woodhouse told me that openssl-dev is a closed list, so the
    original messages got trashed.  This is a resend with apologies to
    David and Peter]
   
    One of the principle problems of using TPM based keys is that there's
    no easy way of integrating them with standard file based keys.  This
    proposal adds a generic method for handling file based engine keys that
    can be loaded as PEM files.  Integration into the PEM loader requires a
    BIO based engine API callback which the first patch adds.  The second
    patch checks to see if the key can be loaded by any of the present
    engines.  Note that this requires that any engine which is to be used
    must be present and initialised via openssl.cnf.
   
    I'll also post to this list the patch to openssl_tpm_engine that makes
    use if this infrastructure so the integration of the whole can be seen.
     It should also be noted that gnutls has had this functionality since
    2012.
   
    The patch was done against 1.0.2h for easier testing and you can try it
    and the openssl_tpm_engine out (if you run openSUSE) here:
   
    https://build.opensuse.org/project/show/home:jejb1:Tumbleweed
   
    James
   
    ---
   
    James Bottomley (2):
      engine: add new flag based method for loading engine keys
      pem: load engine keys
   
     crypto/engine/eng_int.h  |  1 +
     crypto/engine/eng_pkey.c | 38 ++++++++++++++++++++++++++++++++++++++
     crypto/engine/engine.h   | 26 ++++++++++++++++++++++++++
     crypto/pem/pem_pkey.c    |  5 +++++
     4 files changed, 70 insertions(+)
   
    --
    openssl-dev mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
   

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Richard Levitte - VMS Whacker-2
If I understand correctly, the intention is to avoid having to use
ENGINE_load_private_key() directly or having to say '-keyform ENGINE'
to the openssl commands, and to avoid having to remember some cryptic
key identity to give with '-key'.  Instead of all that, just give the
name of a .pem file with '-key' and if that file contains some kind of
magic information that the engine can understand, it will dig out a
reference to the hw protected key.

Many years ago, I was thinking of something along the same lines, but
with a .pem file that would just have a few headers, holding the name
of the intended engine and the key identity, something like this:

    -----BEGIN PRIVATE KEY-----
    X-key-id: flarflarflar
    X-key-engine: foo
    -----END PRIVATE KEY-----

The intent was that the PEM code would be massaged to recognise these
headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
with those data and that would be it.

James, did I catch your intention about right?  I think that's
essentially what e_tpm.c does for loading keys, right?

Cheers,
Richard ( gotta love to see someone use "flarflarflar" as a key id ;-) )

In message <[hidden email]> on Wed, 16 Nov 2016 15:56:05 +0000, "Blumenthal, Uri - 0553 - MITLL" <[hidden email]> said:

uri> My apologies – I don’t fully understand “file based engine keys”. I thought the keys were either on a hardware device (a TPM, a PKCS#11-accessible HSM or smartcard, etc), or in a file. If a key is in a file – it’s not an “engine key”.
uri>
uri> What am I missing, and what’s your use case(s)?
uri> —
uri> Regards,
uri> Uri
uri>
uri>
uri> On 11/16/16, 10:46 AM, "openssl-dev on behalf of James Bottomley" <[hidden email] on behalf of [hidden email]> wrote:
uri>
uri>     [David Woodhouse told me that openssl-dev is a closed list, so the
uri>     original messages got trashed.  This is a resend with apologies to
uri>     David and Peter]
uri>    
uri>     One of the principle problems of using TPM based keys is that there's
uri>     no easy way of integrating them with standard file based keys.  This
uri>     proposal adds a generic method for handling file based engine keys that
uri>     can be loaded as PEM files.  Integration into the PEM loader requires a
uri>     BIO based engine API callback which the first patch adds.  The second
uri>     patch checks to see if the key can be loaded by any of the present
uri>     engines.  Note that this requires that any engine which is to be used
uri>     must be present and initialised via openssl.cnf.
uri>    
uri>     I'll also post to this list the patch to openssl_tpm_engine that makes
uri>     use if this infrastructure so the integration of the whole can be seen.
uri>      It should also be noted that gnutls has had this functionality since
uri>     2012.
uri>    
uri>     The patch was done against 1.0.2h for easier testing and you can try it
uri>     and the openssl_tpm_engine out (if you run openSUSE) here:
uri>    
uri>     https://build.opensuse.org/project/show/home:jejb1:Tumbleweed
uri>    
uri>     James
uri>    
uri>     ---
uri>    
uri>     James Bottomley (2):
uri>       engine: add new flag based method for loading engine keys
uri>       pem: load engine keys
uri>    
uri>      crypto/engine/eng_int.h  |  1 +
uri>      crypto/engine/eng_pkey.c | 38 ++++++++++++++++++++++++++++++++++++++
uri>      crypto/engine/engine.h   | 26 ++++++++++++++++++++++++++
uri>      crypto/pem/pem_pkey.c    |  5 +++++
uri>      4 files changed, 70 insertions(+)
uri>    
uri>     --
uri>     openssl-dev mailing list
uri>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
uri>    
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Dr. Stephen Henson
On Wed, Nov 16, 2016, Richard Levitte wrote:

> If I understand correctly, the intention is to avoid having to use
> ENGINE_load_private_key() directly or having to say '-keyform ENGINE'
> to the openssl commands, and to avoid having to remember some cryptic
> key identity to give with '-key'.  Instead of all that, just give the
> name of a .pem file with '-key' and if that file contains some kind of
> magic information that the engine can understand, it will dig out a
> reference to the hw protected key.
>
> Many years ago, I was thinking of something along the same lines, but
> with a .pem file that would just have a few headers, holding the name
> of the intended engine and the key identity, something like this:
>
>     -----BEGIN PRIVATE KEY-----
>     X-key-id: flarflarflar
>     X-key-engine: foo
>     -----END PRIVATE KEY-----
>
> The intent was that the PEM code would be massaged to recognise these
> headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
> with those data and that would be it.
>

Yes me too. Though if you're doing that something like "ENGINE PRIVATE KEY"
or "OPENSSL ENGINE PRIVATE KEY" as just "PRIVATE KEY" is associated with
PKCS#8.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Blumenthal, Uri - 0553 - MITLL
Thank you! I think I understand. (Sounds like an ugly and hardly necessary complication to me – not to mention that there might not be a filesystem to keep those around, but…)

Regards,
Uri


On 11/16/16, 5:06 PM, "openssl-dev on behalf of Dr. Stephen Henson" <[hidden email] on behalf of [hidden email]> wrote:

    On Wed, Nov 16, 2016, Richard Levitte wrote:
   
    > If I understand correctly, the intention is to avoid having to use
    > ENGINE_load_private_key() directly or having to say '-keyform ENGINE'
    > to the openssl commands, and to avoid having to remember some cryptic
    > key identity to give with '-key'.  Instead of all that, just give the
    > name of a .pem file with '-key' and if that file contains some kind of
    > magic information that the engine can understand, it will dig out a
    > reference to the hw protected key.
    >
    > Many years ago, I was thinking of something along the same lines, but
    > with a .pem file that would just have a few headers, holding the name
    > of the intended engine and the key identity, something like this:
    >
    >     -----BEGIN PRIVATE KEY-----
    >     X-key-id: flarflarflar
    >     X-key-engine: foo
    >     -----END PRIVATE KEY-----
    >
    > The intent was that the PEM code would be massaged to recognise these
    > headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
    > with those data and that would be it.
    >
   
    Yes me too. Though if you're doing that something like "ENGINE PRIVATE KEY"
    or "OPENSSL ENGINE PRIVATE KEY" as just "PRIVATE KEY" is associated with
    PKCS#8.
   
    Steve.
    --
    Dr Stephen N. Henson. OpenSSL project core developer.
    Commercial tech support now available see: http://www.openssl.org
    --
    openssl-dev mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
   

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

David Woodhouse-7
In reply to this post by Richard Levitte - VMS Whacker-2
On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:

>
> Many years ago, I was thinking of something along the same lines, but
> with a .pem file that would just have a few headers, holding the name
> of the intended engine and the key identity, something like this:
>
>     -----BEGIN PRIVATE KEY-----
>     X-key-id: flarflarflar
>     X-key-engine: foo
>     -----END PRIVATE KEY-----
>
> The intent was that the PEM code would be massaged to recognise these
> headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
> with those data and that would be it.
>
> James, did I catch your intention about right?  I think that's
> essentially what e_tpm.c does for loading keys, right?
Right. The TPM engine currently uses ----BEGIN TSS KEY BLOB-----; I
added that a few years back (it used to just dump the binary blob
instead). Both the TPM ENGINE and GnuTLS will load those files, as
noted at http://www.infradead.org/openconnect/tpm.html

The problem is that applications have to jump through special hoops to
recognise the files and invoke the engine (and there's a special API in
GnuTLS too). It would be good if the appropriate engine could be
invoked *automatically*, so the crypto library just does the right
thing without all the applications even having to *know* about it.
(Just like GnuTLS will automatically Just Work in many situations when
presented with a PKCS#11 URI instead a filename, as OpenSSL also
should, but doesn't yet.)

However, the contents of the PEM file should *not* be OpenSSL-specific
and have engine names; I objected to James's original incarnation of
this, which had something like -----BEGIN tpm ENGINE PRIVATE KEY-----
and had the "tpm" engine automatically loaded on demand. It needs to be
 something generic. Which means engines need to indicate *which* PEM
headers they can grok. And maybe the solution to this will tie in with
the general fixes we need for "normal" key files, so that applications
can Just Work with all of those too (qv¹).

Once the dust settles on TPMv2.0 we should probably put together an I-D
for the TPM-wrapped blob PEM files. And I should definitely add
something about them to ¹.

--
dwmw2

¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Blumenthal, Uri - 0553 - MITLL
In reply to this post by James Bottomley
Frankly, I think this approach of specially-encoded PEM or DER files telling the app what key to ask from the engine is madness, compared to the straightforward URI approach (no pun intended :).

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: David Woodhouse
Sent: Monday, November 21, 2016 08:43
To: Richard Levitte; [hidden email]
Reply To: [hidden email]
Cc: James Bottomley
Subject: Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:

>
> Many years ago, I was thinking of something along the same lines, but
> with a .pem file that would just have a few headers, holding the name
> of the intended engine and the key identity, something like this:
>
>     -----BEGIN PRIVATE KEY-----
>     X-key-id: flarflarflar
>     X-key-engine: foo
>     -----END PRIVATE KEY-----
>
> The intent was that the PEM code would be massaged to recognise these
> headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
> with those data and that would be it.
>
> James, did I catch your intention about right?  I think that's
> essentially what e_tpm.c does for loading keys, right?
Right. The TPM engine currently uses ----BEGIN TSS KEY BLOB-----; I
added that a few years back (it used to just dump the binary blob
instead). Both the TPM ENGINE and GnuTLS will load those files, as
noted at http://www.infradead.org/openconnect/tpm.html

The problem is that applications have to jump through special hoops to
recognise the files and invoke the engine (and there's a special API in
GnuTLS too). It would be good if the appropriate engine could be
invoked *automatically*, so the crypto library just does the right
thing without all the applications even having to *know* about it.
(Just like GnuTLS will automatically Just Work in many situations when
presented with a PKCS#11 URI instead a filename, as OpenSSL also
should, but doesn't yet.)

However, the contents of the PEM file should *not* be OpenSSL-specific
and have engine names; I objected to James's original incarnation of
this, which had something like -----BEGIN tpm ENGINE PRIVATE KEY-----
and had the "tpm" engine automatically loaded on demand. It needs to be
something generic. Which means engines need to indicate *which* PEM
headers they can grok. And maybe the solution to this will tie in with
the general fixes we need for "normal" key files, so that applications
can Just Work with all of those too (qv¹).

Once the dust settles on TPMv2.0 we should probably put together an I-D
for the TPM-wrapped blob PEM files. And I should definitely add
something about them to ¹.

--
dwmw2

¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Nikos Mavrogiannopoulos-2
In reply to this post by David Woodhouse-7
On Mon, 2016-11-21 at 13:42 +0000, David Woodhouse wrote:

> Right. The TPM engine currently uses ----BEGIN TSS KEY BLOB-----; I
> added that a few years back (it used to just dump the binary blob
> instead). Both the TPM ENGINE and GnuTLS will load those files, as
> noted at http://www.infradead.org/openconnect/tpm.html
> The problem is that applications have to jump through special hoops
> to
> recognise the files and invoke the engine (and there's a special API
> in
> GnuTLS too). It would be good if the appropriate engine could be
> invoked *automatically*, so the crypto library just does the right
> thing without all the applications even having to *know* about it.
> (Just like GnuTLS will automatically Just Work in many situations
> when
> presented with a PKCS#11 URI instead a filename, as OpenSSL also
> should, but doesn't yet.)

Note that for TPM wrapped keys, there was no new API introduced for
gnutls. The intention is to access such keys using a special URI [0].
However, since tpm2.0 is a completely different beast, I no longer
believe on direct TPM support, without a PKCS#11 wrapper.

[0]. https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01

regards,
Nikos

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

James Bottomley
In reply to this post by David Woodhouse-7
On Mon, 2016-11-21 at 13:42 +0000, David Woodhouse wrote:

> On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
> >
> > Many years ago, I was thinking of something along the same lines,
> > but with a .pem file that would just have a few headers, holding
> > the name of the intended engine and the key identity, something
> > like this:
> >
> >     -----BEGIN PRIVATE KEY-----
> >     X-key-id: flarflarflar
> >     X-key-engine: foo
> >     -----END PRIVATE KEY-----
> >
> > The intent was that the PEM code would be massaged to recognise
> > these headers and would then use ENGINE_by_id() /
> > ENGINE_load_private_key() with those data and that would be it.
> >
> > James, did I catch your intention about right?  I think that's
> > essentially what e_tpm.c does for loading keys, right?
Yes, that's right.  When any SSL program sees a TPM wrapped key, it
should just do the right thing if it has the engine capability without
needing the user to add any options to the command line.

> Right. The TPM engine currently uses ----BEGIN TSS KEY BLOB-----; I
> added that a few years back (it used to just dump the binary blob
> instead). Both the TPM ENGINE and GnuTLS will load those files, as
> noted at http://www.infradead.org/openconnect/tpm.html
>
> The problem is that applications have to jump through special hoops
> to recognise the files and invoke the engine (and there's a special
> API in GnuTLS too). It would be good if the appropriate engine could
> be invoked *automatically*, so the crypto library just does the right
> thing without all the applications even having to *know* about it.
> (Just like GnuTLS will automatically Just Work in many situations
> when presented with a PKCS#11 URI instead a filename, as OpenSSL also
> should, but doesn't yet.)
>
> However, the contents of the PEM file should *not* be OpenSSL
> -specific and have engine names; I objected to James's original
> incarnation of this, which had something like
>  -----BEGIN tpm ENGINE PRIVATE KEY-----
> and had the "tpm" engine automatically loaded on demand. It needs to
> be  something generic. Which means engines need to indicate *which*
> PEM headers they can grok. And maybe the solution to this will tie in
> with the general fixes we need for "normal" key files, so that
> applications can Just Work with all of those too (qv¹).
Right, I forgot to add in the blurb that I'm looking for a mechanism
that all SSL implementations could follow, so it can't be tied to
anything specific in openSSL (like the engine name).  I modelled it on
gnutls because that has the same "just works(tm)" characteristic that I
was looking for.

> Once the dust settles on TPMv2.0 we should probably put together an I
> -D for the TPM-wrapped blob PEM files. And I should definitely add
> something about them to ¹.

Once we agree, I'll be happy to write up something.  We can use the pem
header concept to extend this format if it becomes necessary.

James

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Richard Levitte - VMS Whacker-2
In reply to this post by Blumenthal, Uri - 0553 - MITLL
I'm leaning in that direction as well.

Speaking of URIs, you might be interested in some work I did last
week, which would do good to get a bit of external scrutiny.

https://github.com/openssl/openssl/pull/1961 (for URI decoding)
https://github.com/openssl/openssl/pull/1962 (a STORE module that
essentially uses a URI and tries to fetch certs, keys, crls, ... from
it)

Please have a look.

Cheers,
Richard

In message <[hidden email]> on Mon, 21 Nov 2016 13:50:43 +0000, "Blumenthal, Uri - 0553 - MITLL" <[hidden email]> said:

uri> Frankly, I think this approach of specially-encoded PEM or DER files telling the app what key to ask from the engine is madness, compared to the straightforward URI approach (no pun intended :).
uri>
uri> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
uri>   Original Message  
uri> From: David Woodhouse
uri> Sent: Monday, November 21, 2016 08:43
uri> To: Richard Levitte; [hidden email]
uri> Reply To: [hidden email]
uri> Cc: James Bottomley
uri> Subject: Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
uri>
uri> On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
uri> >
uri> > Many years ago, I was thinking of something along the same lines, but
uri> > with a .pem file that would just have a few headers, holding the name
uri> > of the intended engine and the key identity, something like this:
uri> >
uri> >     -----BEGIN PRIVATE KEY-----
uri> >     X-key-id: flarflarflar
uri> >     X-key-engine: foo
uri> >     -----END PRIVATE KEY-----
uri> >
uri> > The intent was that the PEM code would be massaged to recognise these
uri> > headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
uri> > with those data and that would be it.
uri> >
uri> > James, did I catch your intention about right?  I think that's
uri> > essentially what e_tpm.c does for loading keys, right?
uri> ‎
uri> Right. The TPM engine currently uses ----BEGIN TSS KEY BLOB-----; I
uri> added that a few years back (it used to just dump the binary blob
uri> instead). Both the TPM ENGINE and GnuTLS will load those files, as
uri> noted at http://www.infradead.org/openconnect/tpm.html
uri>
uri> The problem is that applications have to jump through special hoops to
uri> recognise the files and invoke the engine (and there's a special API in
uri> GnuTLS too). It would be good if the appropriate engine could be
uri> invoked *automatically*, so the crypto library just does the right
uri> thing without all the applications even having to *know* about it.
uri> (Just like GnuTLS will automatically Just Work in many situations when
uri> presented with a PKCS#11 URI instead a filename, as OpenSSL also
uri> should, but doesn't yet.)
uri>
uri> However, the contents of the PEM file should *not* be OpenSSL-specific
uri> and have engine names; I objected to James's original incarnation of
uri> this, which had something like -----BEGIN tpm ENGINE PRIVATE KEY-----
uri> and had the "tpm" engine automatically loaded on demand. It needs to be
uri> something generic. Which means engines need to indicate *which* PEM
uri> headers they can grok. And maybe the solution to this will tie in with
uri> the general fixes we need for "normal" key files, so that applications
uri> can Just Work with all of those too (qv¹).
uri>
uri> Once the dust settles on TPMv2.0 we should probably put together an I-D
uri> for the TPM-wrapped blob PEM files. And I should definitely add
uri> something about them to ¹.
uri>
uri> --
uri> dwmw2
uri>
uri> ¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

David Woodhouse-7
In reply to this post by Blumenthal, Uri - 0553 - MITLL
On Mon, 2016-11-21 at 13:50 +0000, Blumenthal, Uri - 0553 - MITLL
wrote:
> Frankly, I think this approach of specially-encoded PEM or DER files
> telling the app what key to ask from the engine is madness, compared
> to the straightforward URI approach (no pun intended :).

Right. There are two separate things that the TPM can do for keys.

There is storage in the TPM itself, and you can reference a key therein
by its UUID. In Nikos's draft, and in GnuTLS, you end up with something
like tpmkey:uuid=7f468c16-cb7f-11e1-824d-b3a4f4b20343;storage=user

To use a PEM file for that does seem like madness; I agree.

However, Nikos's draft also supports a URI of the form:
 tpmkey:file=/foo/bar/key.pem

This, I do not like. It runs entirely contrary to my assertion in
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html that
applications should Just Bloody Work with whatever file they're handed,
without needing to be *told* what the file contains.

Besides, it requires files in the form described by the Portable Data
section of the TSS (1.2) spec. That's a SEQUENCE with a blob type
(which is mostly redundant as in this case we're always talking about
key blobs), the blob length (which is entirely redundant) and then the
actual blob as an OCTET STRING. I don't know of any tool which actually
creates such files.

The -----BEGIN TSS KEY BLOB----- PEM files which are created and used
by both GnuTLS and OpenSSL TPM engine contain *just* the OCTET STRING
containing the blob itself.

I assert that if the application is given such a PEM blob (by filename,
or just text embedded in a configuration file, or whatever), then it
MUST NOT require any further information about the contents of that
blob, except perhaps a password.

I have updated my draft with a section about TPM keys:
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.4.4

We should probably consolidate Nikos's now-expired draft with a
documentation of the -----BEGIN TSS KEY BLOB----- PEM format, as well
as bringing it up to date with the v2.0 specifications as appropriate.

I'd *like* to think that we can punt it to PKCS#11 at least for TPM2,
but I'm not sure. PKCS#11 doesn't make it easy to deal with the fact
that there can be multiple PINs for the various keys in the chain, and
doesn't easily cope with the fact that the key material might not be
stored in the TPM and accessible by reference; it actually has to be
*loaded*. I do not want to inflict another horror like nss-pem on the
world... :)

--
dwmw2
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Richard Levitte - VMS Whacker-2
In reply to this post by James Bottomley
In message <[hidden email]> on Mon, 21 Nov 2016 08:05:47 -0800, James Bottomley <[hidden email]> said:

James.Bottomley> On Mon, 2016-11-21 at 13:42 +0000, David Woodhouse wrote:
James.Bottomley> > On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
James.Bottomley> > >
James.Bottomley> > > Many years ago, I was thinking of something along the same lines,
James.Bottomley> > > but with a .pem file that would just have a few headers, holding
James.Bottomley> > > the name of the intended engine and the key identity, something
James.Bottomley> > > like this:
James.Bottomley> > >
James.Bottomley> > >     -----BEGIN PRIVATE KEY-----
James.Bottomley> > >     X-key-id: flarflarflar
James.Bottomley> > >     X-key-engine: foo
James.Bottomley> > >     -----END PRIVATE KEY-----
James.Bottomley> > >
James.Bottomley> > > The intent was that the PEM code would be massaged to recognise
James.Bottomley> > > these headers and would then use ENGINE_by_id() /
James.Bottomley> > > ENGINE_load_private_key() with those data and that would be it.
James.Bottomley> > >
James.Bottomley> > > James, did I catch your intention about right?  I think that's
James.Bottomley> > > essentially what e_tpm.c does for loading keys, right?
James.Bottomley>
James.Bottomley> Yes, that's right.  When any SSL program sees a TPM wrapped key, it
James.Bottomley> should just do the right thing if it has the engine capability without
James.Bottomley> needing the user to add any options to the command line.

Mm...  I'm not sure I agree with the method, passing a BIO for the
key_id.  I would much rather have seen a patch where OpenSSL's PEM
module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob
from it, securing it somehow (since key_id is expected to be be NUL
terminated) and pass that to the engine.

James.Bottomley> > Once the dust settles on TPMv2.0 we should probably put together an I
James.Bottomley> > -D for the TPM-wrapped blob PEM files. And I should definitely add
James.Bottomley> > something about them to ¹.
James.Bottomley>
James.Bottomley> Once we agree, I'll be happy to write up something.  We can use the pem
James.Bottomley> header concept to extend this format if it becomes necessary.

My vote goes to a URI based spec rather than bastardising PEM files.
I understand this kinda throws years of developmemt out the window,
but there you have it.

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

David Woodhouse-7
On Tue, 2016-11-22 at 13:48 +0100, Richard Levitte wrote:
> Mm...  I'm not sure I agree with the method, passing a BIO for the
> key_id.  I would much rather have seen a patch where OpenSSL's PEM
> module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob
> from it, securing it somehow (since key_id is expected to be be NUL
> terminated) and pass that to the engine.

Agreed.

> My vote goes to a URI based spec rather than bastardising PEM files.
> I understand this kinda throws years of developmemt out the window,
> but there you have it.

I think we need both. We need the URI for the keys stored *in* the TPM
where we just need to reference them. And we need (non-bastardised) PEM
files with TPM-wrapped key blobs. The latter is what the engine
supports right now (by filename only).


--
dwmw2
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Salz, Rich
In reply to this post by Richard Levitte - VMS Whacker-2
> would much rather have seen a patch where OpenSSL's PEM module is
> tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, securing

Yes, that would be much more consistent with the existing OpenSSL code which -- like it or not -- works that way.

> My vote goes to a URI based spec rather than bastardising PEM files.

Sure, if you can figure out which URI scheme to use; there are many of them. :)

        /r$

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Richard Levitte - VMS Whacker-2
In reply to this post by David Woodhouse-7
In message <[hidden email]> on Tue, 22 Nov 2016 11:57:42 +0000, David Woodhouse <[hidden email]> said:

dwmw2> On Mon, 2016-11-21 at 13:50 +0000, Blumenthal, Uri - 0553 - MITLL
dwmw2> wrote:
dwmw2> > Frankly, I think this approach of specially-encoded PEM or DER files
dwmw2> > telling the app what key to ask from the engine is madness, compared
dwmw2> > to the straightforward URI approach (no pun intended :).
dwmw2>
dwmw2> Right. There are two separate things that the TPM can do for keys.
dwmw2>
dwmw2> There is storage in the TPM itself, and you can reference a key therein
dwmw2> by its UUID. In Nikos's draft, and in GnuTLS, you end up with something
dwmw2> like tpmkey:uuid=7f468c16-cb7f-11e1-824d-b3a4f4b20343;storage=user
dwmw2>
dwmw2> To use a PEM file for that does seem like madness; I agree.
dwmw2>
dwmw2> However, Nikos's draft also supports a URI of the form:
dwmw2>  tpmkey:file=/foo/bar/key.pem
dwmw2>
dwmw2> This, I do not like. It runs entirely contrary to my assertion in
dwmw2> http://david.woodhou.se/draft-woodhouse-cert-best-practice.html that
dwmw2> applications should Just Bloody Work with whatever file they're handed,
dwmw2> without needing to be *told* what the file contains.

Not sure I follow...  'file=/foo/bar/key.pem' is just a path /
parameter that the 'tpmkey' handler is free to interpret in whatever
way it sees fit.  For me as a user, it's just a string.  For all I
care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ=='
That doesn't say anything about the contents of /foo/bar/key.pem, not
more than file:/foo/bar/key.pem does, or even if there actually is a
file /foo/bar/key.pem.  Maybe I misunderstand what you're after...

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

David Woodhouse-7
In reply to this post by Salz, Rich
On Tue, 2016-11-22 at 12:54 +0000, Salz, Rich wrote:
> > would much rather have seen a patch where OpenSSL's PEM module is
> > tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, securing
>
> Yes, that would be much more consistent with the existing OpenSSL
> code which -- like it or not -- works that way.

Yeah. Although I'd note that the OpenSSL code only works that way for
PEM files. I really want to make it work the same way for DER files
too. There's an *attempt* in d2i_AutoPrivateKey() but that doesn't
handle encrypted PKCS#8 IIRC. Or PKCS#12. And the app still shouldn't
have to call different functions for PEM vs. DER files anyway.

> > My vote goes to a URI based spec rather than bastardising PEM files.
>
> Sure, if you can figure out which URI scheme to use; there are many
> of them. :)

For TPM I am not aware of any scheme other than the one set out in
https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01

--
dwmw2
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

David Woodhouse-7
In reply to this post by Richard Levitte - VMS Whacker-2
On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote:
>
> Not sure I follow...  'file=/foo/bar/key.pem' is just a path /
> parameter that the 'tpmkey' handler is free to interpret in whatever
> way it sees fit.  For me as a user, it's just a string.  For all I
> care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ=='
> That doesn't say anything about the contents of /foo/bar/key.pem, not
> more than file:/foo/bar/key.pem does, or even if there actually is a
> file /foo/bar/key.pem.  Maybe I misunderstand what you're after...

Where files are involved, I do not want the application to be told:
 pkcs8:/foo/bar/key
 pkcs1:/foo/bar/key
 pkcs12:/foo/bar/key or
 tpmkey:/foo/bar/key

I only want the application to be told "/foo/bar/key"

It should work out what the contents are for *itself*. Whether they be
PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.

And if the string it's given *isn't* a filename but is instead a
PKCS#11 URI or a TPM URI according to Nikos's spec, that should Just
Work too.

User pass string identifying key. Application Just Work™. dwmw2 happy.

--
dwmw2
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Richard Levitte - VMS Whacker-2
In reply to this post by David Woodhouse-7
In message <[hidden email]> on Tue, 22 Nov 2016 13:09:18 +0000, David Woodhouse <[hidden email]> said:

dwmw2> On Tue, 2016-11-22 at 12:54 +0000, Salz, Rich wrote:
dwmw2> > > would much rather have seen a patch where OpenSSL's PEM module is
dwmw2> > > tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, securing
dwmw2> >
dwmw2> > Yes, that would be much more consistent with the existing OpenSSL
dwmw2> > code which -- like it or not -- works that way.
dwmw2>
dwmw2> Yeah. Although I'd note that the OpenSSL code only works that way for
dwmw2> PEM files. I really want to make it work the same way for DER files
dwmw2> too. There's an *attempt* in d2i_AutoPrivateKey() but that doesn't
dwmw2> handle encrypted PKCS#8 IIRC. Or PKCS#12. And the app still shouldn't
dwmw2> have to call different functions for PEM vs. DER files anyway.

Just let me shamelessly mention my STORE effort again ;-)
Among others, it does attempt to solve that very problem (in the
'file' scheme handler).

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Richard Levitte - VMS Whacker-2
In reply to this post by David Woodhouse-7
In message <[hidden email]> on Tue, 22 Nov 2016 13:12:14 +0000, David Woodhouse <[hidden email]> said:

dwmw2> On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote:
dwmw2> >
dwmw2> > Not sure I follow...  'file=/foo/bar/key.pem' is just a path /
dwmw2> > parameter that the 'tpmkey' handler is free to interpret in whatever
dwmw2> > way it sees fit.  For me as a user, it's just a string.  For all I
dwmw2> > care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ=='
dwmw2> > That doesn't say anything about the contents of /foo/bar/key.pem, not
dwmw2> > more than file:/foo/bar/key.pem does, or even if there actually is a
dwmw2> > file /foo/bar/key.pem.  Maybe I misunderstand what you're after...
dwmw2>
dwmw2> Where files are involved, I do not want the application to be told:
dwmw2>  pkcs8:/foo/bar/key
dwmw2>  pkcs1:/foo/bar/key
dwmw2>  pkcs12:/foo/bar/key or
dwmw2>  tpmkey:/foo/bar/key
dwmw2>
dwmw2> I only want the application to be told "/foo/bar/key"

Ah, yeah, ok, so basically have OpenSSL support the "TSS KEY BLOB" PEM
type would be a way to go, wouldn't you say?  That, or add functionality
to have PEM content handlers added dynamically, one for each PEM
content type.
Just please, that "pass the BIO" hack...  sorry, I'm not a supporter.

dwmw2> It should work out what the contents are for *itself*. Whether they be
dwmw2> PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.

Yeah, got it...  my thinking was on a tachnical level, that
'whatever.pem' would have to be handled by OpenSSL itself (or in URI
terms, by the 'file' scheme handler), while 'tpmkey:file=whatever.pem'
would be handled by the 'tpmkey' scheme handler, which is a different
story to me.

I dunno about you, but to me, the URI scheme is not the same as an
indication of what contents I'll get.  But i guess that's a matter of
interpretation.

dwmw2> And if the string it's given *isn't* a filename but is instead a
dwmw2> PKCS#11 URI or a TPM URI according to Nikos's spec, that should Just
dwmw2> Work too.

You *do* indicate those with a URI scheme, though ;-)

dwmw2> User pass string identifying key. Application Just Work™. dwmw2 happy.

:-)

Cheers,
Richard ( who'd be *much* happier if his fingers didn't constantly
          want to typ tmpkey ;-) )

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

David Woodhouse-7
On Tue, 2016-11-22 at 14:32 +0100, Richard Levitte wrote:

> In message <[hidden email]> on Tue, 22 Nov 2016 13:12:14 +0000, David Woodhouse <[hidden email]> said:
>
> dwmw2> On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote:
> dwmw2> >
> dwmw2> > Not sure I follow...  'file=/foo/bar/key.pem' is just a path /
> dwmw2> > parameter that the 'tpmkey' handler is free to interpret in whatever
> dwmw2> > way it sees fit.  For me as a user, it's just a string.  For all I
> dwmw2> > care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ=='
> dwmw2> > That doesn't say anything about the contents of /foo/bar/key.pem, not
> dwmw2> > more than file:/foo/bar/key.pem does, or even if there actually is a
> dwmw2> > file /foo/bar/key.pem.  Maybe I misunderstand what you're after...
> dwmw2>
> dwmw2> Where files are involved, I do not want the application to be told:
> dwmw2>  pkcs8:/foo/bar/key
> dwmw2>  pkcs1:/foo/bar/key
> dwmw2>  pkcs12:/foo/bar/key or
> dwmw2>  tpmkey:/foo/bar/key
> dwmw2>
> dwmw2> I only want the application to be told "/foo/bar/key"
>
> Ah, yeah, ok, so basically have OpenSSL support the "TSS KEY BLOB" PEM
> type would be a way to go, wouldn't you say?  That, or add functionality
> to have PEM content handlers added dynamically, one for each PEM
> content type.
> Just please, that "pass the BIO" hack...  sorry, I'm not a supporter.
I think the number of "new" PEM formats is going to be vanishingly
small, and it's OK to have knowledge of them hard-coded in OpenSSL
rather than having a fully dynamic mechanism.

Doing it dynamically would be painful — either the appropriate engine
needs to be loaded already, or we need a mapping from PEM 'BEGIN'
string to the engine name somehow.

> dwmw2> It should work out what the contents are for *itself*. Whether they be
> dwmw2> PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.
>
> Yeah, got it...  my thinking was on a tachnical level, that
> 'whatever.pem' would have to be handled by OpenSSL itself (or in URI
> terms, by the 'file' scheme handler), while 'tpmkey:file=whatever.pem'
> would be handled by the 'tpmkey' scheme handler, which is a different
> story to me.

Yes, they end up being routed to the same engine via entirely different
paths. Both need resolving, and we need not to conflate the two.

--
dwmw2
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
12345