Re: [openssl-users] General approach for keeping a client cert from openssl

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Andy Green
> Sent: Monday, December 19, 2016 19:03
> 
> On Mon, 2016-12-19 at 10:21 -0800, Kyle Hamilton wrote:
> 
> >   There exists what is called an ENGINE interface to offload
> > cryptographic operations to a container.  Right now,
>> https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engine_to_use_
> > indigenous_ECDH_ECDSA_and_HASH_Algorithms seems to be the best
> > documentation available to explain the process of creating it.
> 
> Thanks, I will start with that and try to understand it better.

Note that there's already an ENGINE implementation for PKCS#11, so if your 
hardware supports that you may be able to simply use that code. If not, then 1) 
why doesn't it (providing the standard API is generally a good idea), but 2) it 
may be a useful model.

Michael Wojcik 
Distinguished Engineer, Micro Focus 



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

Re: [openssl-users] General approach for keeping a client cert from openssl

[Andy Green]

On Mon, 2016-12-19 at 10:21 -0800, Kyle Hamilton wrote:

> You cannot keep the certificate from OpenSSL, as that's the piece
> that you share with the remote side.  This contains the public key,
> and the information bound to that public key by the CA.

Right.

> However, you can keep the private key from being seen by OpenSSL.

Yes, this is the game.

>   There exists what is called an ENGINE interface to offload
> cryptographic operations to a container.  Right now,
> https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engine_to_use_
> indigenous_ECDH_ECDSA_and_HASH_Algorithms seems to be the best
> documentation available to explain the process of creating it.  

Thanks, I will start with that and try to understand it better.

> Obviously, depending on the type of key you're using, you will
> probably need to figure out the differences.

Yes, it seems it's basically overloading one or more crypto action, so
we need to match the action to what it wants to do with the cert key. 
But I guess to get started, we can do what we have code for.

Thanks again I will study it.

-Andy

> -Kyle H
> 
> On Mon, Dec 19, 2016 at 3:22 AM, Andy Green  wrote:
> > Hi -
> > 
> > I have a situation coming up that is similar to a client cert being
> > held on a secure key store, like a key vault.
> > 
> > We need to be able to perform TLS communication with a remote
> > server
> > using the key, but without giving the key to OpenSSL.
> > 
> > The "other side" of the "key vault" is smart, and we can run code
> > there, and communicate with it.  So we need to basically proxy
> > OpenSSL
> > operations on the "other side".
> > 
> > I guess this is nothing new under the sun... what's the general
> > approach to integrating this to OpenSSL?
> > 
> > Thanks for any advice.
> > 
> > -Andy
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-us
> > ers
> > 
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] General approach for keeping a client cert from openssl

[Kyle Hamilton]

You cannot keep the certificate from OpenSSL, as that's the piece that you
share with the remote side.  This contains the public key, and the
information bound to that public key by the CA.

However, you can keep the private key from being seen by OpenSSL.  There
exists what is called an ENGINE interface to offload cryptographic
operations to a container.  Right now,
https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engine_to_use_indigenous_ECDH_ECDSA_and_HASH_Algorithms
seems to be the best documentation available to explain the process of
creating it.  Obviously, depending on the type of key you're using, you
will probably need to figure out the differences.

-Kyle H

On Mon, Dec 19, 2016 at 3:22 AM, Andy Green  wrote:

> Hi -
>
> I have a situation coming up that is similar to a client cert being
> held on a secure key store, like a key vault.
>
> We need to be able to perform TLS communication with a remote server
> using the key, but without giving the key to OpenSSL.
>
> The "other side" of the "key vault" is smart, and we can run code
> there, and communicate with it.  So we need to basically proxy OpenSSL
> operations on the "other side".
>
> I guess this is nothing new under the sun... what's the general
> approach to integrating this to OpenSSL?
>
> Thanks for any advice.
>
> -Andy
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] General approach for keeping a client cert from openssl

[Andy Green]

Hi -

I have a situation coming up that is similar to a client cert being
held on a secure key store, like a key vault.

We need to be able to perform TLS communication with a remote server
using the key, but without giving the key to OpenSSL.

The "other side" of the "key vault" is smart, and we can run code
there, and communicate with it.  So we need to basically proxy OpenSSL
operations on the "other side".

I guess this is nothing new under the sun... what's the general
approach to integrating this to OpenSSL?

Thanks for any advice.

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