Support for ECParameters with explicit (not named) parameter spec

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

Support for ECParameters with explicit (not named) parameter spec

Max Fichtelmann
Hello,

currently sun.security.util.ECParameters.engineInit(byte[]) is limited to parse named curves. A commented block outlining parsing of explicit parameters is included below throwing "only named ECParameters supported". That comment block seems to be unchanged from at least jdk6 up until jdk10.

Is there any Plan to implement this at some time? Since I am needing to implement it anyway, how could I provide that change?

Kind Regards,

Max Fichtelmann



procilon IT-Logistics GmbH
Leipziger Straße 110
04425 Taucha bei Leipzig
www.procilon.de



procilon IT-Systems GmbH & Co. KG
Amtsgericht Leipzig HRA 16016
Persönlich haftende Gesellschafterin:
procentauri Beteiligungs- und Verwaltungsgesellschaft mbH
Geschäftsführer Steffen Scholz, Amtsgericht Leipzig, Handelsregister HRB 25771

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten.
Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts,
eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt.
Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information.
If you have received this e-mail in error, you are hereby notified that any review,
copying, or distribution of it is strictly prohibited.
Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

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

Re: Support for ECParameters with explicit (not named) parameter spec

Adam Petcher

On 12/6/2017 7:24 AM, Max Fichtelmann wrote:

Hello,

currently sun.security.util.ECParameters.engineInit(byte[]) is limited to parse named curves. A commented block outlining parsing of explicit parameters is included below throwing "only named ECParameters supported". That comment block seems to be unchanged from at least jdk6 up until jdk10.

Is there any Plan to implement this at some time? Since I am needing to implement it anyway, how could I provide that change?

I don't know of any plan to implement this feature. Modern RFCs only allow named curves here, so this feature doesn't seem to be very valuable. Can you share why you want to parse specified EC domain parameters? Sharing the motivation behind your enhancement may help you find a sponsor for it.

You can find the instructions for contributing here[1]. I suggest you discuss the change a bit more before spending any time preparing a patch. Also, make sure you sign the contributor agreement before sending any code. 

[1] http://openjdk.java.net/contribute/


Kind Regards,

Max Fichtelmann



procilon IT-Logistics GmbH
Leipziger Straße 110
04425 Taucha bei Leipzig
www.procilon.de



procilon IT-Systems GmbH & Co. KG
Amtsgericht Leipzig HRA 16016
Persönlich haftende Gesellschafterin:
procentauri Beteiligungs- und Verwaltungsgesellschaft mbH
Geschäftsführer Steffen Scholz, Amtsgericht Leipzig, Handelsregister HRB 25771

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten.
Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts,
eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt.
Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information.
If you have received this e-mail in error, you are hereby notified that any review,
copying, or distribution of it is strictly prohibited.
Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

Reply | Threaded
Open this post in threaded view
|

Re: Support for ECParameters with explicit (not named) parameter spec

Xuelei Fan-2
In reply to this post by Max Fichtelmann
On 12/6/2017 4:24 AM, Max Fichtelmann wrote:
> Hello,
>
> currently sun.security.util.ECParameters.engineInit(byte[]) is limited
> to parse named curves. A commented block outlining parsing of explicit
> parameters is included below throwing "only named ECParameters
> supported". That comment block seems to be unchanged from at least jdk6
> up until jdk10.
>
What's the requirement for unnamed parameter spec? For TLS or just basic
crypto operation?  Would you mind have an example about the use of it?


> Is there any Plan to implement this at some time? Since I am needing to
> implement it anyway, how could I provide that change?
>
Please refer to the "How to contribute" doc in OpenJDK:
     http://openjdk.java.net/contribute/

Regards,
Xuelei

> Kind Regards,
>
> Max Fichtelmann
>
>
>
> *procilon IT-Logistics GmbH*
> Leipziger Straße 110
> 04425 Taucha bei Leipzig
> www.procilon.de
> <https://www.procilon.de?utm_source=email&utm_medium=mail_disclaimer&utm_campaign=mail_disclaimer_proTECTr-app_1215>
>
> ------------------------------------------------------------------------
> procilon IT-Systems GmbH & Co. KG
> Amtsgericht Leipzig HRA 16016
> Persönlich haftende Gesellschafterin:
> procentauri Beteiligungs- und Verwaltungsgesellschaft mbH
> Geschäftsführer Steffen Scholz, Amtsgericht Leipzig, Handelsregister HRB
> 25771
> ------------------------------------------------------------------------
> Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige
> vertrauliche Informationen enthalten.
> Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine
> Kenntnisnahme des Inhalts,
> eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt.
> Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail.
> Vielen Dank.
> ------------------------------------------------------------------------
> This e-mail may contain trade secrets or privileged, undisclosed, or
> otherwise confidential information.
> If you have received this e-mail in error, you are hereby notified that
> any review,
> copying, or distribution of it is strictly prohibited.
> Please inform us immediately and destroy the original transmittal. Thank
> you for your cooperation.
Reply | Threaded
Open this post in threaded view
|

Antwort: Re: Support for ECParameters with explicit (not named) parameter spec

Max Fichtelmann
We use a HSM to generate ECDSA Keys and are required to use the curve brainpoolP256r1.

Although the HSM does not specifically support brainpool, it is possible to generate these keys by providing the specific Curve Parameters. These curve parameters are then saved in CKA_EC_PARAMS - the PKCS11 Object for the public key looks like this (several attributes omitted):

  CKA_CLASS CKO_PUBLIC_KEY
  CKA_TOKEN true
  CKA_PRIVATE false
  CKA_KEY_TYPE CKK_EC
  CKA_ID length 20
    { 06223B39 9F887A9D CA547DAD 3E1CC1DD 675D6D1E }
  CKA_KEY_GEN_MECHANISM CKM_EC_KEY_PAIR_GEN
  CKA_EC_PARAMS length 227 (1816 bits)
    { 0x30, 0x81, 0xE0, 0x02, 0x01, 0x01, 0x30, 0x2C, 0x06, 0x07, 0x2A, 0x86,
      0x48, 0xCE, 0x3D, 0x01, 0x01, 0x02, 0x21, 0x00, 0xA9, 0xFB, 0x57, 0xDB,
      0xA1, 0xEE, 0xA9, 0xBC, 0x3E, 0x66, 0x0A, 0x90, 0x9D, 0x83, 0x8D, 0x72,
      0x6E, 0x3B, 0xF6, 0x23, 0xD5, 0x26, 0x20, 0x28, 0x20, 0x13, 0x48, 0x1D,
      0x1F, 0x6E, 0x53, 0x77, 0x30, 0x44, 0x04, 0x20, 0x7D, 0x5A, 0x09, 0x75,
      0xFC, 0x2C, 0x30, 0x57, 0xEE, 0xF6, 0x75, 0x30, 0x41, 0x7A, 0xFF, 0xE7,
      0xFB, 0x80, 0x55, 0xC1, 0x26, 0xDC, 0x5C, 0x6C, 0xE9, 0x4A, 0x4B, 0x44,
      0xF3, 0x30, 0xB5, 0xD9, 0x04, 0x20, 0x26, 0xDC, 0x5C, 0x6C, 0xE9, 0x4A,
      0x4B, 0x44, 0xF3, 0x30, 0xB5, 0xD9, 0xBB, 0xD7, 0x7C, 0xBF, 0x95, 0x84,
      0x16, 0x29, 0x5C, 0xF7, 0xE1, 0xCE, 0x6B, 0xCC, 0xDC, 0x18, 0xFF, 0x8C,
      0x07, 0xB6, 0x04, 0x41, 0x04, 0x8B, 0xD2, 0xAE, 0xB9, 0xCB, 0x7E, 0x57,
      0xCB, 0x2C, 0x4B, 0x48, 0x2F, 0xFC, 0x81, 0xB7, 0xAF, 0xB9, 0xDE, 0x27,
      0xE1, 0xE3, 0xBD, 0x23, 0xC2, 0x3A, 0x44, 0x53, 0xBD, 0x9A, 0xCE, 0x32,
      0x62, 0x54, 0x7E, 0xF8, 0x35, 0xC3, 0xDA, 0xC4, 0xFD, 0x97, 0xF8, 0x46,
      0x1A, 0x14, 0x61, 0x1D, 0xC9, 0xC2, 0x77, 0x45, 0x13, 0x2D, 0xED, 0x8E,
      0x54, 0x5C, 0x1D, 0x54, 0xC7, 0x2F, 0x04, 0x69, 0x97, 0x02, 0x21, 0x00,
      0xA9, 0xFB, 0x57, 0xDB, 0xA1, 0xEE, 0xA9, 0xBC, 0x3E, 0x66, 0x0A, 0x90,
      0x9D, 0x83, 0x8D, 0x71, 0x8C, 0x39, 0x7A, 0xA3, 0xB5, 0x61, 0xA6, 0xF7,
      0x90, 0x1E, 0x0E, 0x82, 0x97, 0x48, 0x56, 0xA7, 0x02, 0x01, 0x01 }
  CKA_EC_POINT length 67 (536 bits)
    { 0x04, 0x41, 0x04, 0x05, 0x2C, 0x86, 0x09, 0x68, 0x17, 0x6E, 0x8D, 0x13,
      0xE8, 0xE8, 0x0E, 0x74, 0x08, 0x42, 0xBF, 0xD6, 0xFE, 0xE2, 0x8A, 0xBB,
      0x74, 0xC7, 0x0A, 0x6E, 0x8A, 0x10, 0x8A, 0x4E, 0x78, 0xA0, 0xDD, 0x14,
      0xC2, 0x82, 0x9D, 0xF5, 0xB0, 0x65, 0xF4, 0x94, 0xB4, 0xDF, 0x3E, 0x13,
      0xF9, 0x44, 0x96, 0x9F, 0x66, 0x3B, 0x6D, 0x5A, 0x87, 0xE7, 0xC8, 0x69,
      0x29, 0x57, 0xD0, 0x68, 0xE4, 0x2A, 0x2A }

When using SunPKCS11 to load the KeyPair, ECParams is used with the value of CKA_EC_PARAMS which then fails.

So there are not many options I see - either patching JDK or getting the HSM-Vendor to add support for brainpool...

Thank you very much for the swift reply and the contribution link.




Von:        Xuelei Fan <[hidden email]>
An:        Max Fichtelmann <[hidden email]>, [hidden email]
Datum:        06/12/2017 16:52
Betreff:        Re: Support for ECParameters with explicit (not named) parameter spec




On 12/6/2017 4:24 AM, Max Fichtelmann wrote:
> Hello,
>
> currently sun.security.util.ECParameters.engineInit(byte[]) is limited
> to parse named curves. A commented block outlining parsing of explicit
> parameters is included below throwing "only named ECParameters
> supported". That comment block seems to be unchanged from at least jdk6
> up until jdk10.
>
What's the requirement for unnamed parameter spec? For TLS or just basic
crypto operation?  Would you mind have an example about the use of it?


> Is there any Plan to implement this at some time? Since I am needing to
> implement it anyway, how could I provide that change?
>
Please refer to the "How to contribute" doc in OpenJDK:
   
http://openjdk.java.net/contribute/

Regards,
Xuelei

> Kind Regards,
>
> Max Fichtelmann
>
>
>
> *procilon IT-Logistics GmbH*
> Leipziger Straße 110
> 04425 Taucha bei Leipzig
>
www.procilon.de
> <
https://www.procilon.de?utm_source=email&utm_medium=mail_disclaimer&utm_campaign=mail_disclaimer_proTECTr-app_1215>
>
> ------------------------------------------------------------------------
> procilon IT-Systems GmbH & Co. KG
> Amtsgericht Leipzig HRA 16016
> Persönlich haftende Gesellschafterin:
> procentauri Beteiligungs- und Verwaltungsgesellschaft mbH
> Geschäftsführer Steffen Scholz, Amtsgericht Leipzig, Handelsregister HRB
> 25771
> ------------------------------------------------------------------------
> Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige
> vertrauliche Informationen enthalten.
> Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine
> Kenntnisnahme des Inhalts,
> eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt.
> Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail.
> Vielen Dank.
> ------------------------------------------------------------------------
> This e-mail may contain trade secrets or privileged, undisclosed, or
> otherwise confidential information.
> If you have received this e-mail in error, you are hereby notified that
> any review,
> copying, or distribution of it is strictly prohibited.
> Please inform us immediately and destroy the original transmittal. Thank
> you for your cooperation.







procilon IT-Logistics GmbH
Leipziger Straße 110
04425 Taucha bei Leipzig
www.procilon.de



procilon IT-Systems GmbH & Co. KG
Amtsgericht Leipzig HRA 16016
Persönlich haftende Gesellschafterin:
procentauri Beteiligungs- und Verwaltungsgesellschaft mbH
Geschäftsführer Steffen Scholz, Amtsgericht Leipzig, Handelsregister HRB 25771

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten.
Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts,
eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt.
Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information.
If you have received this e-mail in error, you are hereby notified that any review,
copying, or distribution of it is strictly prohibited.
Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

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

Re: Support for ECParameters with explicit (not named) parameter spec

Adam Petcher

On 12/6/2017 11:39 AM, Max Fichtelmann wrote:

We use a HSM to generate ECDSA Keys and are required to use the curve brainpoolP256r1.

Although the HSM does not specifically support brainpool, it is possible to generate these keys by providing the specific Curve Parameters. These curve parameters are then saved in CKA_EC_PARAMS...
<snip>
When using SunPKCS11 to load the KeyPair, ECParams is used with the value of CKA_EC_PARAMS which then fails.

So there are not many options I see - either patching JDK or getting the HSM-Vendor to add support for brainpool...

I think this problem is pretty good motivation for enhancing this code to support specified domain parameters. So if you are going to write code to fix this, please consider submitting a patch.

There may be another way to fix this problem without patching the JDK. You could develop (or locate) a JCA provider including an AlgorithmParameters service for "EC" that has this desired functionality. Install[1] this provider with a preference higher than SunEC, and it will be used to decode the CKA_EC_PARAMS. But note that this may also change other (unrelated) crypto behavior in your application. 

[1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#ProviderInstalling
Reply | Threaded
Open this post in threaded view
|

Re: Support for ECParameters with explicit (not named) parameter spec

Bernd Eckenfels-4
It is however very likely that the HSM does not accept/allow/implement arbitrary curves which it does not know how to handle and optimize the arithmetics. Especially not when it also needs to create points. (And some vendors sell them for a premium...)

Safenet HSMs seem to only accept parameters if opt in (which turns FIPS mode off) - and those curves can be used for a limited set of mechanisms. But then again they also claim to offer named brainpool curves in recent firmwares..

Gruss
Bernd
--
http://bernd.eckenfels.net

From: security-dev <[hidden email]> on behalf of Adam Petcher <[hidden email]>
Sent: Wednesday, December 6, 2017 8:38:35 PM
To: [hidden email]
Subject: Re: Support for ECParameters with explicit (not named) parameter spec
 

On 12/6/2017 11:39 AM, Max Fichtelmann wrote:

We use a HSM to generate ECDSA Keys and are required to use the curve brainpoolP256r1.

Although the HSM does not specifically support brainpool, it is possible to generate these keys by providing the specific Curve Parameters. These curve parameters are then saved in CKA_EC_PARAMS...
<snip>
When using SunPKCS11 to load the KeyPair, ECParams is used with the value of CKA_EC_PARAMS which then fails.

So there are not many options I see - either patching JDK or getting the HSM-Vendor to add support for brainpool...

I think this problem is pretty good motivation for enhancing this code to support specified domain parameters. So if you are going to write code to fix this, please consider submitting a patch.

There may be another way to fix this problem without patching the JDK. You could develop (or locate) a JCA provider including an AlgorithmParameters service for "EC" that has this desired functionality. Install[1] this provider with a preference higher than SunEC, and it will be used to decode the CKA_EC_PARAMS. But note that this may also change other (unrelated) crypto behavior in your application. 

[1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#ProviderInstalling