ELLIPTIC CURVE CRYPTOGRAPHY: JAVA ...

ELLIPTIC CURVE CRYPTOGRAPHY: JAVA IMPLEMENTATION ISSUES ´ V. Gayoso Mart´ınez, C. S´anchez Avila

J. Espinosa Garc´ıa, L. Hern´andez Encinas

E.T.S.I. Telecomunicaci´on Univ. Polit´ecnica de Madrid C/ Ciudad Universitaria, s/n 28040, Madrid, Espa˜na [email protected], [email protected]

Instituto de F´ısica Aplicada C.S.I.C. C/ Serrano, 144 28006, Madrid, Espa˜na javier.espinosa,[email protected]

ABSTRACT Elliptic Curve Cryptography (ECC) is based in one of the hardest arithmetic problems, the elliptic curve discrete logarithm problem, making ECC a reliable cryptographic technique. In addition to this advantage, ECC requires shorter keys compared to other public key algorithms, which suggests its use in low-end systems such as smart cards because of its efficiency and limited hardware requirements. Currently the leading smart card technology is Java Card. Though both Java 2 Standard Edition (J2SE) 5.0 and Java Card (JC) 2.2.1 include classes and interfaces making ECC available to Java programs, they are not complete, making it necessary to use additional, non-standard packages if the programmer wants to use ECC for different operations (digital signature, data encryption and decryption, etc.). In the present work, we provide a complete review of the state of the art of ECC in J2SE and Java Card, with a complete list of operations available in both standard implementations and proprietary packages.

In 1985, Koblitz [5] and Miller [7] independently proposed a cryptosystem based on elliptic curves, whose security relies on the ECDLP problem. ECC can be applied to data encryption and decryption, as well as to generate and verify digital signatures. As in the case of IFP and DLP module a large prime number, no algorithm is known that solves the ECDLP in an efficient way. Moreover, the ECDLP is regarded by some authors as the hardest of the three problems. Although some operations take more time in the ECC system compared to other public-key systems, as the key size is smaller some studies suggest that there are no practical differences in performance between ECC and RSA. 2. ELLIPTIC CURVE CRYPTOGRAPHY 2.1. Elliptic curve definition An elliptic curve E over the finite field K is defined as follows, also known as the Weierstrass equation ([4] and [10]): y 2 + a1 xy + a3 y = x3 + a2 x2 + a4 x + a6 ,

1. PUBLIC-KEY CRYPTOGRAPHY Since the development of public-key cryptography by Diffie and Hellman in 1976 [2], several cryptosystems have been proposed. Some of those cryptosystems were not well designed and as time passes they have proved not reliable, and for some others their complexity did not allow efficient implementations. Precisely efficiency and complexity are the most important features to be requested to a cryptosystem, depending both on the mathematical problem on which it is based. Three of the problems considered computationally infeasible to solve are the integer factorization problem (IFP), the discrete logarithm problem (DLP) and the elliptic curve discrete logarithm problem (ECDLP).

where a1 , a2 , a3 , a4 , a6 ∈ K and ∆ 6= 0, being ∆ the discriminant of E that can be calculated in the following way:  ∆ = −d22 d8 − 8d34 − 27d26 + 9d2 d4 d6     d2 = a21 + 4a2  d4 = 2a4 + a1 a3   d6 = a23 + 4a6   2 2 2  d8 = a1 a6 + 4a2 a6 − a1 a3 a4 + a2 a3 − a4 Condition ∆ 6= 0 assures the curve is “smooth”, i.e. there cannot exist curve points with two or more different tangent lines. However, the Weierstrass equation is not used in practice. Instead of it, depending on the characteristic of K, this equation can be greatly simplified. If the characteristic of K is other than 2 or 3, then the proper change of variables transform the Weierstrass equation into the curve:

y 2 = x3 + ax + b. If the characteristic of K is exactly 2 or 3, depending on the value of a1 , it is possible to work with the following simplified equations: (K = 2, a1 6= 0) (K = 2, a1 = 0)
K = 3, a21 6= −a2
K = 3, a21 = −a2

y 2 + xy = x3 + ax2 + b y 2 + cy = x3 + ax + b y 2 = x3 + ax2 + b y 2 = x3 + ax + b.

In elliptic curve cryptography two types of finite fields Fq with q = pm elements are used: prime finite fields Fp (where p is an odd prime and m = 1) and binary finite fields F2m (where p = 2 and m can be any integer higher than 1). 3. RELATED STANDARDS Either in the environment of RSA or ECC, any theoretical finding cannot be used directly, as it is necessary to define data structures and related procedures over the information. Currently there are three inmediate applications for ECC in cryptography, as it is described in next paragraphs. 3.1. ECDSA (Elliptic Curve Digital Signature Algorithm) FIPS 186-2 [3] describes all the algorithms and digital signature schemes that can be used by any agency of the U.S. government. Currently those algorithms are DSA, RSA and ECDSA. ECDSA is the elliptic curve variant of the Digital Signature Algorithm (DSA). NIST and ANSI X9.62 have set minimum keysize requirements of 1024 bits for RSA and DSA and 160 bits for ECC, corresponding to a symmetric block cipher key size of 80 bits. NIST has published a list of recommended elliptic curves for protection of 5 different symmetric keysizes (80, 112, 128, 192, 256). In general, ECC over a binary field requires an asymmetric keysize twice that of the corresponding symmetric key. ECDSA scheme is also included in IEEE 1363 and ISO/IEC 15946-2 standards. As a comparison, texts with a 1024 bit RSA key produce a digital signature of 128 bytes, whilst the same text signed with a 192 bit ECDSA key generates a digital signature of 48 bytes. 3.2. ECIES (Elliptic Curve Integrated Encryption Scheme) The most extended encryption/decryption scheme based on ECC is ECIES, proposed by Abdalla, Bellare and Rogaway in 1998 [1], being a variant of the ElGamal scheme. ECIES can be found at ANSI X9.63, ISO/IEC 15946-3 and IEEE 1363 standards.

A new version named ECIES-KEM has been proposed recently [9]. This version includes modifications in order to prevent “benign maleability” issues, so it is foreseen that the new version will become part of the standard. As an example, a symetric key encrypted with a 1024 bits RSA key produces an output of 128 bytes compared with the output of 84 bytes if the encryption is performed with ECIES. 3.3. ECDH (Elliptic Curve Diffie-Hellman) The main objective of key exchange protocols is to put in contact two or more entities communicating through an open and presumably insecure channel, sharing a secret key that will provide data confidentiality and integrity to any information exchanged. By the term ECDH we refer to key exchange schemes based on the Diffie-Hellman mechanism applied to elliptic curves, such as the STS (station-to-station) protocol, included in the ANSI X9.63 standard or ECMQV (Elliptic Curve Menezes- Qu-Vanstone) [6], included in ANSI X9.63, IEEE 1363 and ISO/IEC 15946-3 standards and which provides protection against an active attacker. 3.4. Commercial adoption On February 16th 2005, the NSA (National Security Agency) announced that it had decided to adopt ECC as part of a U.S. government standard in securing sensitivebut-unclassified information. The NSA has recommended a group of algorithms called Suite B, including ECMQV and ECDH for key agreement, and the ECDSA for digital signatures. Certicom, currently the major commercial proponent of ECC, owns over 130 patents and has licensed the technology to the NSA. 4. JAVA LANGUAGE Since its appearance in 1990s, the Java language has experienced a constant growth regarding the number of programmers and commercial deployments, being massively used in web and corporate applications. As a result of its continous evolution, several versions for specific target platforms have appeared: J2EE (Java 2 Enterprise Edition) for advanced servers, J2SE (Java 2 Standard Edition) for desktop computers, J2ME (Java 2 Mobile Edition) for handsets and PDAs and JC (Java Card) for smart cards. In the Java architecture, the Security API (built around the java.security package) is one of the main interfaces of the language. The first version of the Security API for the development version Java Development Kit (JDK) 1.1 introduced the Java Cryptography Architecture (JCA),

which allows the generation of digital signatures and message digests. In the following versions, J2SE extended the JCA functionality, including a provider architecture which allows multiple and interoperable cryptographic implementations. More specifically, Java Cryptography Extension (JCE) provides implementations for encryption, key agreement and generation as well as MAC algorithms. JCE was originally an optional package, but since J2SE 1.4 it is included in the core J2SE distribution. Algorithm independence is achieved by means of “engines” or cryptographic services, along with the classes implementing such functionality. Before J2SE 5.0, the JCA/JCE environment did not include specific classes for elliptic curve cryptography. Users willing to use those algorithms were forced to use software from third parties. From J2SE 5.0 release onwards, some classes and interfaces have been included in order to facilitate providers the ECC support. Those additions can be found at the java.security package. 5. JAVA IMPLEMENTATIONS There are several libraries and criptographic modules in the market that can be used for the development of security programs. The most important are: • Botan (http://botan.randombit.net/intro.html) • Bouncy Castle (www.bouncycastle.org) • Cryptix (www.cryptix.org) • cryptlib (www.cryptlib.orion.co.nz) • Crypto++ (ourceforge.net/projects/cryptopp) • IAIK (jce.iaik.tugraz.at) • libecc (libecc.sourceforge.net) Due to native code performance, most of the implementations are developed in C/C++ or directly in assembly language. However, as far as the aim of this paper is to review the state of the art of ECC implementations using the Java language, we will focus in the following libraries: Bouncy Castle, Cryptix and IAIK. 5.1. Bouncy Castle Legion of the Bouncy Castle, a group of volunteers and cryptography enthusiasts, has developed several Java implementations. Its latest release (1.29) includes a lightweight cryptographic API, a provider for the JCE and JCA, a clean room implementation of the JCE 1.2.1, a library for reading and writing encoded ASN.1 objects and different generators/processors for X.509 certificates, S/MIME and CMS, OpenPGP, etc.

Regarding ECC, Bouncy Castle supports both ECDSA and ECDH, creation of ECDSA certificate requests, encoding of public and private keys in accordance with SEC 1 [8] and a draft implementation of ECIES. As a drawback, this version still does not include the ECIES-KEM variant. Evaluating the level of support (both for encryption and signature operations) and its continous evolution, Bouncy Castle is probably one of the best cryptographic packages that can be found over the internet, not only for ECC but also for other algorithms as RSA, AES, etc. 5.2. Cryptix Cryptix is another open code library for the development of Java applications using cryptographic algorithms. Although its main projects Cryptix JCE and Cryptix OpenPGP are actively maintained, with new contributions in recent months, other projects as Cryptix Elliptix are suspended since 1999. However, it is still interesting to study the level of development achieved by the Cryptix Elliptix package in order to compare it to other implementations. Its goal was to provide a Java implementation of IEEE 1363, ANSI X9.62 and X9.63 standards. In the latest version available, the package supported arithmethic operations over Fp (with projective coordinates) and over F2m (with affine coordinates over polynomial bases). Support for curve parameter generation was planned but was not finally implemented. High level operations (e.g. digital signature generation and verification) were also intended but were not available in the latest release. 5.3. IAIK The Institute for Applied Information Processing and Communications of the Graz University has developed a set of cryptographic tools based on Java. Among those tools are IAIK-JCE (main module including RSA, DES, AES, Blowfish and other algorithms), IAIK-iSaSiLk (TLS 1.0 and SSL 3.0 implementations) and IAIK-ECC, to name only a few. Release 1.0 of the IAIK Elliptic Curve Cryptography (ECC) Library presents the following features: • ECDSA and ECDH algorithms according to ANSI X9.62 and IEEE 1363 standards. • Arithmetic over prime and binary finite fields. Regarding binary fields only polynomial base representation is used due to patent limitations. • Elliptic curve arithmetic with affine and projective coordinates. • Wide list of parameters that can be extended. • ECDSA integration into JCE/JCA architecture.

• Digital signature and public/private key ASN.1 encoding. IAIK software is free for educational and research purposes, which makes it another good option for the development of cryptographic Java applications. 6. JAVA CARD Java Card is a framework for the programming and execution of applications in smart cards developed by Sun with the support from several smart card providers. JC 2.1.1 constitues the core of most of the SIM and UICC cards used in GSM and UMTS mobile devices. JC 2.2.1 is the new version which includes several references to ECC. Two packages of the JC specification are directly related to cryptographic functions: javacardx.security and javacardx.crypto. Whereas javacard.security includes the algorithms needed for the generation of message digests, digital signatures and key exchange sessions, the package javacardx.crypto contains functionality with exporting restrictions. More specifically, this package includes classes for the encryption and decryption of data. The javacard.security package distributed in JC 2.2.1 includes the ECPrivateKey and ECPublicKey interfaces that, along with the Signature class (which defines the value ALG ECDSA SHA) allows the generation of 20 byte hashes that can be signed using the ECDSA algorithm. Key types allowed are TYPE EC FP PUBLIC for Fp fields and TYPE EC F2M PUBLIC for F2m fields. Definition for private keys is equivalent. Regarding key generation using the KeyBuilder class in JCE, lenghts of 112, 128, 160 and 192 bits can be selected for the field Fp , whilst for the field F2m options are 113, 131, 163 and 193 bits. However, even considering the great advance in JC 2.2.1 compared to JC 2.1.1 in terms of ECC support, it is still not possible to perform encryption and decryption operations in the same way as with RSA algorithm, which by using the value ALG RSA NOPAD allows this procedure. Although proprietary classes can be added by smart card manufacturers, interoperability issues among different suppliers prevent this kind of solutions, which makes extremely necessary to complete ECC support in future versions of the Java Card platform. 7. CONCLUSIONS During the last years, Java has been one of the technologies with a fastest growth. Cryptographic capabillities were added first to the J2SE/J2EE platform and then to Java Card. In J2SE, from version 5.0 it is possible to make implementations adapted to the JCA/JCE framework including

elliptic curve functionality. However, it is still possible to use lightweight APIs provided by different suppliers, which can be a good option if the developer must work with J2SE versions prior to the 5.0 release. Regarding Java Card, although in the 2.2.1 release several classes and interfaces have been added in order to perform ECDSA and ECDH operations, it is still necessary to define methods and constants that allow implementing encryption functionalities. Until then, developers willing to use ECIES will have to use proprietary implementations. Among the independent implementations developed outside the standardization bodies for Java, Bouncy Castle and IAIK outstand above the rest. Both of them provide high quality implementations and can be used free of charge in non commercial applications. 8. REFERENCES [1] Abdalla, M., Bellare, M. and Rogaway, P., “DHAES: an encryption scheme based on the Die-Hellma problem”, Contribution to IEEE P1363, 1998. [2] Diffie, W. and Hellman, M.E., “New directions in cryptography”, IEEE Transactions in Information Theory, volume IT-22, pages 644-654, November 1976. [3] FIPS 186-2, Digital Signature Standard (DSS), National Institute for Standards and Technology, 2000. [4] Hankerson, D., Menezes, A. J. and Vanstone, S., Guide to Elliptic Curve Cryptography, Springer-Verlag, 2004. [5] Koblitz, N., “Elliptic curve cryptosystems”, Mathematics of Computation, number 48, pages 203-209, 1987. [6] Menezes, A., Qu, M. and Vanstone, S., “Some new key agreement protocols providing implicit authentication”, Preproceedings of Workshops on Selected Areas in Cryptography, 1995. [7] Miller, V.S., “Use of elliptic curves in cryptography”, Advances in Cryptology - Proceedings of CRYPTO’85, Springer Verlag Lecture Notes in Computer Science 218, pages 417-426, 1986. [8] SEC1, “Elliptic Curve Cryptography”, Standards for Efficient Cryptography Group, Available from www.secg.org/collateral/sec1.pdf, 2000. [9] Shoup, V., “A proposal for an ISO standard for public key encryption”, v2.1, preprint, 2001. [10] Silverman, J., The Arithmetic of Elliptic Curves, Springer-Verlag, 1992.