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

[James Bottomley]

On Tue, 2016-12-13 at 22:28 +, David Woodhouse wrote:
> On Tue, 2016-12-13 at 13:09 +, Dr. Stephen Henson wrote:
> > The reason for that is that the PEM forms which contain
> > the key algorithm in the PEM header were considered legacy types 
> > and new methods should use PKCS#8 instead. So there was no way to 
> > set legacy PEM decoders to discourage their use.
> > 
> > In this case the reason is different: the header doesn't contain 
> > the algorithm type but a string which an ENGINE can handle. So it 
> > isn't a "legacy format" but a custom one.
> > 
> > So if we wanted to go down this route all that is needed to get a 
> > form of this functionality is a function to set the PEM decoder in
> > EVP_PKEY_ASN1_METHOD.
>
> I am not entirely averse to the idea of saying that TPM, at least as
> of 2.0, should have a wrapped-key storage format which is based in
> PKCS#8 rather than doing its own thing.

So the proposal is to have a TPM specific value for PrivateKeyAlgorithm
(which would have to be proposed as an OID) and use PrivateKeyInfo for
the key?  That could be made to work.

The slight fly in the ointment that's worrying me is that I need a key
format that works for pkcs#11 tokens as well.  The problem here is that
TPM keys don't have an id or a label and that's pretty much a
requirement of using a pkcs#11 token, so the pkcs#11 code has to be
able to set these attributes on the key files.  I was originally
thinking of putting them into the PEM header with a pkcs11- prefix.  I
suppose I can do the same with the attributes and some manufactured OID
prefix with the CKA_ parameters we're interested in as a suffix but
it's messy.

James


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Tue, Dec 13, 2016, David Woodhouse wrote:

> On Tue, 2016-12-13 at 13:09 +, Dr. Stephen Henson wrote:
> > The reason for that is that the PEM forms which contain
> > the key algorithm in the PEM header were considered legacy types and new 
> > methods
> > should use PKCS#8 instead. So there was no way to set legacy PEM decoders to
> > discourage their use.
> > 
> > In this case the reason is different: the header doesn't contain the 
> > algorithm
> > type but a string which an ENGINE can handle. So it isn't a "legacy format"
> > but a custom one.
> > 
> > So if we wanted to go down this route all that is needed to get a form of 
> > this
> > functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD.
> 
> I am not entirely averse to the idea of saying that TPM, at least as of
> 2.0, should have a wrapped-key storage format which is based in PKCS#8
> rather than doing its own thing.
> 

If you go the PKCS#8 route then it would presumably be the unencrypted form.
One way to handle things would be to assign an OID for TPM and have an ASN.1
module unwrap the thing and return an EVP_PKEY structure.

That would work with any version of OpenSSL without modification if the ENGINE
included a TPM ASN.1 EVP_PKEY_ASN1_METHOD.

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

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

[David Woodhouse]

On Tue, 2016-12-13 at 13:09 +, Dr. Stephen Henson wrote:
> The reason for that is that the PEM forms which contain
> the key algorithm in the PEM header were considered legacy types and new 
> methods
> should use PKCS#8 instead. So there was no way to set legacy PEM decoders to
> discourage their use.
> 
> In this case the reason is different: the header doesn't contain the algorithm
> type but a string which an ENGINE can handle. So it isn't a "legacy format"
> but a custom one.
> 
> So if we wanted to go down this route all that is needed to get a form of this
> functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD.

I am not entirely averse to the idea of saying that TPM, at least as of
2.0, should have a wrapped-key storage format which is based in PKCS#8
rather than doing its own thing.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Tue, Dec 13, 2016, Dr. Stephen Henson wrote:

> 
> So if we wanted to go down this route all that is needed to get a form of this
> functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD.
> 

Note however that this currently assumes the data between the PEM headers is
base64 encoded and it passes the decoded version to the relevant handler. So
if the data is of a textual form instead it cannot (currently) be handled but
that could be changed.

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

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

[Dr. Stephen Henson]

On Wed, Nov 30, 2016, James Bottomley wrote:

> 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:
> 

I can see a couple of problems with this approach.

Firstly the BIO containing the private key may not be seekable: that is
BIO_reset() might not rewind it to the start. This could happen with a BIO
chain, a socket or a pipe for example. 

The second problem is that the file might contain multiple private keys so
(say) if you're reading the second private key in a file a reset will end up
taking you back to the beginning.

However the required functionality to support custom PEM key forms actually
largely already exists in OpenSSL so significant changes are not required if
we want to go down this route.

To see what I mean consider an existing format such as an RSA key which has
-BEGIN RSA PRIVATE KEY- at the start. When the PEM file is parsed in
PEM_read_bio_PrivateKey() it sees that the header ends in "PRIVATE KEY" and
then attempts to look up the key string: "RSA" in this case. It then
passes the decoded contents of the PEM file to the relavent algorithm ASN.1
method by looking for one that handles the appropriate string. Although all
current methods use ASN.1 for the private key data this shouldn't be necessary.

So for RSA this is rsa_ameth.c and the function is old_rsa_priv_decode. This
takes the encoded data and returns an EVP_PKEY structure containing the key.

So in theory if you wanted to handle a key of the form:

-BEGIN TPM PRIVATE KEY-
-END TPM PRIVATE KEY

you just create an almost empty ASN.1 method which handles the string "TPM"
and which only contains the PEM decoder. An ENGINE can also contain its own
custom methods so you could include an ENGINE which contains the relevant
handler. This would require no changes to OpenSSL to work.

There is however a snag. The relevant structure (EVP_PKEY_ASN1_METHOD) is
opaque and there is currently no way to set the pem decoder for a custom
string (the field is called "old_priv_decode"): only methods which are part of
OpenSSL can do that. The reason for that is that the PEM forms which contain
the key algorithm in the PEM header were considered legacy types and new methods
should use PKCS#8 instead. So there was no way to set legacy PEM decoders to
discourage their use.

In this case the reason is different: the header doesn't contain the algorithm
type but a string which an ENGINE can handle. So it isn't a "legacy format"
but a custom one.

So if we wanted to go down this route all that is needed to get a form of this
functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD.

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

Re: [openssl-dev] Typo in BUF_reverse manual

[Dmitry Belyavsky]

Sorry, my fault :(

On Tue, Dec 13, 2016 at 12:11 PM, Matt Caswell  wrote:

>
>
> On 12/12/16 18:11, Dmitry Belyavsky wrote:
> > Dear Matt,
> > Shouldn't the fix also be applied to 1.1.0 branch?
>
> Err, it was?
>
> Matt
>
> >
> > On Mon, Dec 12, 2016 at 3:44 PM, Dmitry Belyavsky  > > wrote:
> >
> > Hello Matt,
> >
> > https://github.com/openssl/openssl/pull/2075
> > 
> >
> > On Mon, Dec 12, 2016 at 3:17 PM, Matt Caswell  > > wrote:
> >
> > Could you open that as an issue in GitHub? Or even better a PR
> > to fix it ;-)
> >
> > Thanks
> >
> > Matt
> >
> >
> > On 12/12/16 12:16, Dmitry Belyavsky wrote:
> > > Hello!
> > >
> > > I found a typo in the BUF_reverse manual
> > >
> > (https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_
> ex.html  >)
> > >
> > > The manual says:
> > >
> > > BUF_reverse() reverses size bytes at in into out. If out is
> > NULL, the
> > > array is reversed in-place.
> > >
> > > But in fact in-place reverse is done when the in ptr is NULL.
> > >
> > > Thank you!
> > >
> > > --
> > > SY, Dmitry Belyavsky
> > >
> > >
> > --
> > openssl-dev mailing list
> > To unsubscribe:
> > https://mta.openssl.org/mailman/listinfo/openssl-dev
> > 
> >
> >
> >
> >
> > --
> > SY, Dmitry Belyavsky
> >
> >
> >
> >
> > --
> > SY, Dmitry Belyavsky
> >
> >
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Typo in BUF_reverse manual

[Matt Caswell]

On 12/12/16 18:11, Dmitry Belyavsky wrote:
> Dear Matt, 
> Shouldn't the fix also be applied to 1.1.0 branch?

Err, it was?

Matt

> 
> On Mon, Dec 12, 2016 at 3:44 PM, Dmitry Belyavsky  > wrote:
> 
> Hello Matt,
> 
> https://github.com/openssl/openssl/pull/2075
> 
> 
> On Mon, Dec 12, 2016 at 3:17 PM, Matt Caswell  > wrote:
> 
> Could you open that as an issue in GitHub? Or even better a PR
> to fix it ;-)
> 
> Thanks
> 
> Matt
> 
> 
> On 12/12/16 12:16, Dmitry Belyavsky wrote:
> > Hello!
> >
> > I found a typo in the BUF_reverse manual
> >
> (https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_ex.html 
> )
> >
> > The manual says:
> >
> > BUF_reverse() reverses size bytes at in into out. If out is
> NULL, the
> > array is reversed in-place.
> >
> > But in fact in-place reverse is done when the in ptr is NULL.
> >
> > Thank you!
> >
> > --
> > SY, Dmitry Belyavsky
> >
> >
> --
> openssl-dev mailing list
> To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-dev
> 
> 
> 
> 
> 
> -- 
> SY, Dmitry Belyavsky
> 
> 
> 
> 
> -- 
> SY, Dmitry Belyavsky
> 
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev