Re: Fwd: ECDH Engine

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

Re: Fwd: ECDH Engine

Alexander Gostrer
Hi Doug,

David suggested to contact you.
We are writing an openssl ECDH engine. All private keys are in the hardware (including ephemeral keys). I found that the DH_METHOD has both (*generate_key) and (*compute_key) methods while the ECDH_METHOD has just the (*compute_key) method. 

We would like (once the engine is completed) to use standard SSL_accept() etc calls. But the compute_key() returns shared secret based on previously generated public/private key pair and the public key is already sent to a peer). Is there a hook to replace the public key before it is sent out? Any ideas/plans about adding this hook into the code?

Thank you,
Alex Gostrer.

On Tue, Oct 6, 2015 at 7:54 AM, David Woodhouse <[hidden email]> wrote:
On Tue, 2015-10-06 at 07:52 -0700, Alexander Gostrer wrote:
> Yeah, with ECDSA we have no problems. We thought about submitting a
> patch but the code is pretty complicated and we weren't sure that we
> completely understand it. Also we wanted to stick with the stable
> version.

You need to fix it in HEAD first. Then we can talk about backporting to
older versions.

>  Do you have Doug's email? Don't want to spam other people.

Probably best to use the opensc mailing list.
[hidden email]

--
dwmw2




------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: ECDH Engine

Douglas E Engert
I see you sent the same message to the openssl-dev list yesterday, but no one has responded yet.

OpenSC has a engine_pkcs11 that can do ECDSA, but no one has added ECDH yet. The main reason was that until OpenSSL-1.0.2 the routines in ECDSA_METHOD that needed to be replaced were not exposed, and
it took years for the OpenSSL people to finally do something about this. They added ECDSA_METHOD_set_sign and ECDSA_METHOD_set_sign.

I am afraid it might be years until the ECDH has the extra routines need to work with an engine. To get the
ECDSA_METHOD changes into OpenSSL I had to get the engine working using the ecdsa/ec_locl.h header file
to show what was actually needed.


On 10/6/2015 12:37 PM, Alexander Gostrer wrote:
> Hi Doug,
>
> David suggested to contact you.
> We are writing an openssl ECDH engine. All private keys are in the hardware (including ephemeral keys). I found that the DH_METHOD has both (*generate_key) and (*compute_key) methods while the
> ECDH_METHOD has just the (*compute_key) method.

Your have the ephemeral keys in hardware? Won't that require a different ephemeral key for every active connection?

A key is a key, and there is a EC_KEY_generate_key defined in ec.h, that will work for ECDSA or ECDH.
But the ability to generate_key may also need to be exposed if you need to have the ephemeral keys created on the card.
I have not looked at what this would take.

>
> We would like (once the engine is completed) to use standard SSL_accept() etc calls. But the compute_key() returns shared secret based on previously generated public/private key pair and the public
> key is already sent to a peer). Is there a hook to replace the public key before it is sent out? Any ideas/plans about adding this hook into the code?

Not sure how to answer this.

>
> Thank you,
> Alex Gostrer.
>
>
>     On Tue, Oct 6, 2015 at 7:54 AM, David Woodhouse <[hidden email] <mailto:[hidden email]>> wrote:
>
>         On Tue, 2015-10-06 at 07:52 -0700, Alexander Gostrer wrote:
>          > Yeah, with ECDSA we have no problems. We thought about submitting a
>          > patch but the code is pretty complicated and we weren't sure that we
>          > completely understand it. Also we wanted to stick with the stable
>          > version.
>
>         You need to fix it in HEAD first. Then we can talk about backporting to
>         older versions.
>
>          >  Do you have Doug's email? Don't want to spam other people.
>
>         Probably best to use the opensc mailing list.
>         [hidden email] <mailto:[hidden email]>
>
>         --
>         dwmw2
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Full-scale, agent-less Infrastructure Monitoring from a single dashboard
Integrate with 40+ ManageEngine ITSM Solutions for complete visibility
Physical-Virtual-Cloud Infrastructure monitoring from one console
Real user monitoring with APM Insights and performance trend reports
Learn More http://pubads.g.doubleclick.net/gampad/clk?id=247754911&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: ECDH Engine

Alexander Gostrer
Hi Doug,

On Tue, Oct 6, 2015 at 6:00 PM, Douglas E Engert <[hidden email]> wrote:
I see you sent the same message to the openssl-dev list yesterday, but no one has responded yet.
 
Yes, they do not response too fast :(. Looks like I will need to learn the TLS protocol and all its options. 

OpenSC has a engine_pkcs11 that can do ECDSA, but no one has added ECDH yet. The main reason was that until OpenSSL-1.0.2 the routines in ECDSA_METHOD that needed to be replaced were not exposed, and
it took years for the OpenSSL people to finally do something about this. They added ECDSA_METHOD_set_sign and ECDSA_METHOD_set_sign.

I am afraid it might be years until the ECDH has the extra routines need to work with an engine. To get the
ECDSA_METHOD changes into OpenSSL I had to get the engine working using the ecdsa/ec_locl.h header file
to show what was actually needed.

We use the stable branch and we still need to use the ecdsa/ec_locl.h and other internal header files for the ECDSA.  


On 10/6/2015 12:37 PM, Alexander Gostrer wrote:
> Hi Doug,
>
> David suggested to contact you.
> We are writing an openssl ECDH engine. All private keys are in the hardware (including ephemeral keys). I found that the DH_METHOD has both (*generate_key) and (*compute_key) methods while the
> ECDH_METHOD has just the (*compute_key) method.

Your have the ephemeral keys in hardware? Won't that require a different ephemeral key for every active connection?

You mean if the server has few open connections then we get into a problem of luck of the hardware space? We didn't think about it for a reason...  Probably ephemeral keys in hardware will work on the client only. And will limit it to one active connection only. I see your point.

A key is a key, and there is a EC_KEY_generate_key defined in ec.h, that will work for ECDSA or ECDH.
But the ability to generate_key may also need to be exposed if you need to have the ephemeral keys created on the card.
I have not looked at what this would take.

Right but EC_KEY_generate_key() does not have a hook inside: it will generate a key in the software. There are hooks in EVP_KEY (EVP_PKEY_METHOD in ec_pmeth.c) but the SSL code calls ECC_KEY stuff only.

>
> We would like (once the engine is completed) to use standard SSL_accept() etc calls. But the compute_key() returns shared secret based on previously generated public/private key pair and the public
> key is already sent to a peer). Is there a hook to replace the public key before it is sent out? Any ideas/plans about adding this hook into the code?

Not sure how to answer this.

By any chance do you know who has the best knowledge of SSL/TLS implementation of openssl and will want to answer few questions?
 

>
> Thank you,
> Alex Gostrer.
>
>
>     On Tue, Oct 6, 2015 at 7:54 AM, David Woodhouse <[hidden email] <mailto:[hidden email]>> wrote:
>
>         On Tue, 2015-10-06 at 07:52 -0700, Alexander Gostrer wrote:
>          > Yeah, with ECDSA we have no problems. We thought about submitting a
>          > patch but the code is pretty complicated and we weren't sure that we
>          > completely understand it. Also we wanted to stick with the stable
>          > version.
>
>         You need to fix it in HEAD first. Then we can talk about backporting to
>         older versions.
>
>          >  Do you have Doug's email? Don't want to spam other people.
>
>         Probably best to use the opensc mailing list.
>         [hidden email] <mailto:[hidden email]>
>
>         --
>         dwmw2
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Full-scale, agent-less Infrastructure Monitoring from a single dashboard
Integrate with 40+ ManageEngine ITSM Solutions for complete visibility
Physical-Virtual-Cloud Infrastructure monitoring from one console
Real user monitoring with APM Insights and performance trend reports
Learn More http://pubads.g.doubleclick.net/gampad/clk?id=247754911&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel


------------------------------------------------------------------------------
Full-scale, agent-less Infrastructure Monitoring from a single dashboard
Integrate with 40+ ManageEngine ITSM Solutions for complete visibility
Physical-Virtual-Cloud Infrastructure monitoring from one console
Real user monitoring with APM Insights and performance trend reports
Learn More http://pubads.g.doubleclick.net/gampad/clk?id=247754911&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: ECDH Engine

Alexander Gostrer


On Tue, Oct 6, 2015 at 6:43 PM, Alexander Gostrer <[hidden email]> wrote:
Hi Doug,

On Tue, Oct 6, 2015 at 6:00 PM, Douglas E Engert <[hidden email]> wrote:
I see you sent the same message to the openssl-dev list yesterday, but no one has responded yet.
 
Yes, they do not response too fast :(. Looks like I will need to learn the TLS protocol and all its options. 

OpenSC has a engine_pkcs11 that can do ECDSA, but no one has added ECDH yet. The main reason was that until OpenSSL-1.0.2 the routines in ECDSA_METHOD that needed to be replaced were not exposed, and
it took years for the OpenSSL people to finally do something about this. They added ECDSA_METHOD_set_sign and ECDSA_METHOD_set_sign.

I am afraid it might be years until the ECDH has the extra routines need to work with an engine. To get the
ECDSA_METHOD changes into OpenSSL I had to get the engine working using the ecdsa/ec_locl.h header file
to show what was actually needed.

We use the stable branch and we still need to use the ecdsa/ec_locl.h and other internal header files for the ECDSA.  


On 10/6/2015 12:37 PM, Alexander Gostrer wrote:
> Hi Doug,
>
> David suggested to contact you.
> We are writing an openssl ECDH engine. All private keys are in the hardware (including ephemeral keys). I found that the DH_METHOD has both (*generate_key) and (*compute_key) methods while the
> ECDH_METHOD has just the (*compute_key) method.

Your have the ephemeral keys in hardware? Won't that require a different ephemeral key for every active connection?

You mean if the server has few open connections then we get into a problem of luck of the hardware space? We didn't think about it for a reason...  Probably ephemeral keys in hardware will work on the client only. And will limit it to one active connection only. I see your point.

If the openssl keeps the shared secret with the connection handle then the ephemeral key is not needed once the connection is established. Then each new connection will have a different shared secret even between the same peers. So our approach will not allow to reuse ephemeral keys. I don't know if reusing keys is a strong requirement of TLS - need to read documentation :(.
 

A key is a key, and there is a EC_KEY_generate_key defined in ec.h, that will work for ECDSA or ECDH.
But the ability to generate_key may also need to be exposed if you need to have the ephemeral keys created on the card.
I have not looked at what this would take.

Right but EC_KEY_generate_key() does not have a hook inside: it will generate a key in the software. There are hooks in EVP_KEY (EVP_PKEY_METHOD in ec_pmeth.c) but the SSL code calls ECC_KEY stuff only.

>
> We would like (once the engine is completed) to use standard SSL_accept() etc calls. But the compute_key() returns shared secret based on previously generated public/private key pair and the public
> key is already sent to a peer). Is there a hook to replace the public key before it is sent out? Any ideas/plans about adding this hook into the code?

Not sure how to answer this.

By any chance do you know who has the best knowledge of SSL/TLS implementation of openssl and will want to answer few questions?
 

>
> Thank you,
> Alex Gostrer.
>
>
>     On Tue, Oct 6, 2015 at 7:54 AM, David Woodhouse <[hidden email] <mailto:[hidden email]>> wrote:
>
>         On Tue, 2015-10-06 at 07:52 -0700, Alexander Gostrer wrote:
>          > Yeah, with ECDSA we have no problems. We thought about submitting a
>          > patch but the code is pretty complicated and we weren't sure that we
>          > completely understand it. Also we wanted to stick with the stable
>          > version.
>
>         You need to fix it in HEAD first. Then we can talk about backporting to
>         older versions.
>
>          >  Do you have Doug's email? Don't want to spam other people.
>
>         Probably best to use the opensc mailing list.
>         [hidden email] <mailto:[hidden email]>
>
>         --
>         dwmw2
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Full-scale, agent-less Infrastructure Monitoring from a single dashboard
Integrate with 40+ ManageEngine ITSM Solutions for complete visibility
Physical-Virtual-Cloud Infrastructure monitoring from one console
Real user monitoring with APM Insights and performance trend reports
Learn More http://pubads.g.doubleclick.net/gampad/clk?id=247754911&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel



------------------------------------------------------------------------------
Full-scale, agent-less Infrastructure Monitoring from a single dashboard
Integrate with 40+ ManageEngine ITSM Solutions for complete visibility
Physical-Virtual-Cloud Infrastructure monitoring from one console
Real user monitoring with APM Insights and performance trend reports
Learn More http://pubads.g.doubleclick.net/gampad/clk?id=247754911&iu=/4140
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel