Java and security bits

Elliptic Curve Cryptography in Java

The latest Mustang build 81 available on java.net includes support for an interesting new technology: Elliptic Curve Cryptography (ECC).

Basically, ECC refers to a set of public key cryptosystems. This includes the ECDSA and ECDH algorithms, which are elliptic curve equivalents of DSA and DH. What makes ECC interesting is that it provides the same level of security with much shorter key sizes. For example, a 163 bit ECDSA key is considered to be as strong as a 1024 bit DSA or RSA key. This means memory and bandwidth savings (particularly useful for tiny devices). It also means better performance. Not so much when comparing with 1024 RSA/DSA keys, but the difference becomes very pronounced when moving to the next security level with 2048 bit RSA keys and 233 bit ECC keys (see slide 3 in this presentation). This is relevant because many believe that by 2010 we will need to move to such a longer key size. Finally, ECC is also interesting because it is mandated by some government standards. For more in depth information about ECC, see the SunLabs page or Wikipedia.

For all these reasons, Sun has been a advocate of ECC technology for some time with code contributions to OpenSSL and NSS and more recently an announcement of broad support for ECC in various products. The interesting thing that has happened over the last year is that a number of other companies have also become more interested in ECC. That has lead to the formation of an ad-hoc ECC TLS interoperability forum. This will make sure that all the various ECC enabled products, including Java SE, are able to interoperate.

Getting back to Mustang, what is available now is ECC support in the SunJSSE and SunPKCS11 providers, see bug 6405536. This means that the SunPKCS11 provider now exposes ECDSA Signature, ECDH KeyAgreement, and EC KeyPairGenerator algorithms, if the underlying PKCS#11 token supports them. The SunJSSE provider now supports all the elliptic curve ciphersuites defined in the latest IETF draft, if EC crypto is available from a Java crypto provider such as SunPKCS11. Note that we had some elliptic curve APIs (in the interfaces and spec packages) since JDK 5.0, but they were not used by any part of the JDK itself until now. Also note that although EC is supported by SunPKCS11 and SunJSSE now, we do not have a pure Java ECC implementation yet. That is planned for a future release.

This means that in order to use ECC in Mustang now, you can do something like this:

1. get an ECC enabled PKCS#11 library

2. configure the JDK to use it

3. done

Currently, the only ECC enabled PKCS#11 implementation that I am aware of are the latest builds of NSS. Until NSS 3.11.1 is released, you can use these Windows test binaries of NSS and NSPR posted here. On other platforms, compile NSS yourself following these instructions.

Specifically, assuming you are running Windows, follow the instructions below. They may seem familiar given my recent Java and NSS blog. I am sure Solaris and Linux are able to transpose the instructions for their OS.

1. create a directory for the NSS libraries, say d:\nss and unpack the NSS and NSPR libraries referenced above into that directory. There should be 9 DLL and 2 CHK files in that directory.

2. create a directory for your other test files, say d:\ecctest. Create a SunPKCS11 configuration file called nss.cfg in that directory with the contents

   name = NSS
   nssLibraryDirectory = d:\\nss
   nssDbMode = noDb
   attributes = compatibility
   

3. download the latest Mustang build from java.net and unpack it, say into d:\jdk6.

4. go into the directory D:\jdk6\jre\lib\security and edit the file java.security. Add the line

   security.provider.10=sun.security.pkcs11.SunPKCS11 d:\\ecctest\\nss.cfg
   

   to the section listing the security providers.

5. open a command prompt and go to the d:\ecctest directory. Add the JDK and NSS directories to your path using

   set PATH=D:\jdk6\bin;D:\nss;%PATH%

   The NSS directory needs to be in the path to keep the Windows dynamic linker happy. On Solaris and Linux, you may have to set LD_LIBRARY_PATH to the NSS directory.

That's it! You can now use ECC from Java. This can be verified by running commands such as keytool:

D:\ecctest>keytool -genkeypair -keyalg EC -keysize 256 -keystore ectest.jks -storepass test12 -dname "CN=ECC Test"
Enter key password for 
        (RETURN if same as keystore password):

D:\ecctest>keytool -list -v -keystore ectest.jks -storepass test12

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: mykey
Creation date: Apr 23, 2006
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=ECC Test
Issuer: CN=ECC Test
Serial number: 444c296f
Valid from: Sun Apr 23 18:27:11 PDT 2006 until: Sat Jul 22 18:27:11 PDT 2006
Certificate fingerprints:
         MD5:  48:48:DF:DF:F2:A9:74:D2:83:43:1F:9A:FD:05:3A:A2
         SHA1: 85:D7:0E:33:92:84:A1:38:3E:1E:2D:DF:C8:21:0D:D6:98:06:29:82
         Signature algorithm name: SHA1withECDSA
         Version: 3

Or start a program that uses JSSE. The ECC ciphersuites are enabled automatically if the necessary EC crypto algorithms are available. TLS test clients and servers are listed on the interop page and a JSSE based test server is running on that server as well.

More details about the supported features:

SunPKCS11

• SHA1withECDSA and NONEwithECDSA Signatures, ECDH KeyAgreement, EC KeyPairGenerator, EC KeyFactory

• Named prime and binary polynomial curves defined by NIST, SECG, and ANSI X9.62. Uncompressed points. No support for explicitly encoded curves or compressed points.

SunJSSE

• All EC ciphersuites defined in the latest IETF TLS draft.

• All named curves defined in the latest draft.

• ECDSA_sign client authentication usable with both ECC and traditional RSA/DSA/DH ciphersuites.

• Curve and point format negotiation using the extensions Supported Elliptic Curves and Supported Point Formats.

• No support for point compression, explicitly encoded curves, or client authentication using ECDSA_fixed_ECDH or RSA_fixed_ECDH.

The source for the SunPKCS11 changes is also available from the Mustang download page, for b81 the direct link is this file. See the directories j2se/src/share/classes/sun/security/ec and j2se/src/share/classes/sun/security/pkcs11. Some additional work will follow soon as part of bug 6414980.

Finally, I want to acknowledge a few people that helped get this project into Mustang on time by answering questions and by quickly resolving NSS issues that impacted Java: Vipul Gupta from SunLabs, Nelson Bolyard from the Sun NSS team, and Bob Relyea and Wan-Teh Chang from the Red Hat NSS team.

Update:
I should mention that there is no code in the SunJSSE provider that is specific to SunPKCS11. It should work with any Java crypto provider that implements ECC. What SunJSSE requires is a crypto provider that:

• implements ECC as defined by the classes and interfaces in the packages java.security.spec and java.security.interfaces. The getAlgorithm() method of elliptic curve key objects must return the String "EC"

• supports the Signature algorithms SHA1withECDSA and NONEwithECDSA, the KeyAgreement algorithm ECDH, and a KeyPairGenerator and a KeyFactory for algorithm EC. If one of these algorithms is missing, SunJSSE will not allow EC ciphersuites to be used.

• the crypto provider should support all the SECG curves defined in the TLS ECC specification, section 5.1.1 (see also appendix A). In certificates, points should be encoded using the uncompressed form and curves should be encoded using the namedCurve choice, i.e. using an object identifier. If these requirements are not met, EC ciphersuites may not be negotiated correctly.

I am aware that the BouncyCastle crypto provider includes some ECC support, but I am not sure it meets the requirements spelled out above. Testing it with SunJSSE is on my todo list.

Posted at 17:18 Apr 23, 2006 by Andreas Sterbenz in Java  |  Comments[5]