A Java implementation of an elliptic curve Cryptosystem

Andrew Burnett, Keith Winters, and Tom Dowling

National Umversityof Ireland, Maynooth
tdowlingf&cs.may.ie

Abstract: We describe a Java implementation of an EIGamal based elliptic curve

cryptosystem. Wc then illustrate tlic use of tiffs implementationin a working prototype.

1. Introduction
Data transmitted across a network is vulnerable to many types of attack. The use of
the Internet as a vehicle for commerce has focussed the minds of both developers and
criminals towards securing information on the Internet. One crucial step in the
process of protecting this data is to encrypt it before transmission using an
appropriate algorithm. There are many cryptographic algorithms and protocols
available to use in an encryption process. Cryptographic algorithms do not in
themselves guarantee security. They need to be used in an appropriate way governed
by a protocol to be effective.
All too often in application development provision of security is an afterthought and
badly implemented. There are various reasons for this but one that is often given by
developers is the problem of how to incorporate cryptographic systems into their
applications easily and without needing an advanced knowledge of the mathematics
behind the systems. A solution to this problem would be the provision of a relatively
simple interface to provide security while hiding the details from users. This interface
should be able to support and swap cryptographic algorithms with ease and support
related cryptographic concepts like key management in an easy to use way. The
interface should also be able to incorporate new cryptographic algorithms as the need
arises.
The objective of this paper is to show how this can be accomplished in Java using the
Java Cryptographic Architecture (JCA) as an interface framework. We will take a
relatively new cryptographic algorithm and follow the JCA framework to develop a
set of Java classes to implement it. We will show how to integrate this cryptographic
system into an existing Java application. The informed cryptographer should note that
this integration is for demonstration purposes only and would need an appropriate
protocol developed to ensure industrial strength security.
The paper is organised as follows. In Section two we describe the elliptic curve based
cryptosystem we wish to implement. Section 3 focuses on the Java Cryptographic
Architecture (JCA) as a framework for implementing cryptographic algorithms. We
concentrate on writing a JCA based implementation of an elliptic curve cryptosystem
in section 4. Section 5 describes how to use our implementation in Java applications.
We finally give some conclusions and future work in section 6.

2. Elliptic curve cryptography

The use of elliptic curve groups over finite fields as a basis for a cryptosystem was
first suggested by Koblitz, [KOB] The elliptic curve approach is a mathematically
richer procedure than standard systems like RSA. The basic units for this
cryptosystem are points (x,y) on an Elliptic curve, E(Fp), of the form
y2 = x 3 + a x + b , with x,y,a,b~Fp ={1,2,3 ....... p - _ , p - 1 }

Principles and Practice of P r o g r a m m i n g in Java 2002 83

 One basic condition for any cryptosystem is that the system is closed, i.e. any
operation on an element of the system results in another element of the system. In
order to satisfy this condition for Elliptic curves it is necessary to construct non-
standard addition and multiplication operations. We omit the details here but the
interested reader can find a detailed discussion in [KOB] or [SMART]. The
algorithm we use is based on the ElGamal asymmetric cipher system, [TAH1R]. We
give a very brief outline of the encryption algorithm here.
In what follows + and * refer to Elliptic curve addition and multiplication. Capitals
represent points on the curve while lower case represent integers. Given a message,
m, we must first choose a large integer, p, and a suitable elliptic curve, E(Fp)
defined as above. We must then embed the message m onto a point, P, on the curve.
This is not as straightforward as it looks and involves the use of quadratic residues
and probabilistic algorithms. Due to space constraints we cannot go into detail but
the interested reader should consult [KOB]. A base point, BP, on the curve is chosen.
A random integer, s, is chosen and kept secret. The point PUBKEY = s*BP is
calculated. The private key is (s,p,BP,a,b), while the public key is
(PUBKEY,p,BP,a,b). Note that the difficulty in obtaining the private key from the
public key is based on the discrete log problem (DLP) for elliptic curves. The DLP
states that given a point A ~ E(Fp), base point BP, it is extremely difficult to find an
integer, a, such that a*BP=A. [GARRETT], contains a discussion of the discrete log
problem.
To encrypt P, a user picks an integer, k, at random and sends the pair of points

(k*BP, P+k*PUBKEY)

To decrypt this message you multiply the first component by the secret key, s, and
subtract from the second component,
(P+ k*PUBKEY ) - s*(k*BP) = P+k*(s*(BP)) - s*(k*BP) = P

We then reverse the embedding process to produce the message, m, from the point P.
This system requires a high level of mathematical abstraction to implement. One
significant practical problem if this system is to be use~l is how can it be packaged
in a user-friendly way so that developers can incorporate it into their applications
with minimal knowledge its inner workings. The next section will describe a Java
based framework to overcome this problem.

. Java C r y p t o g r a p h y Architecture (JCA).

In this section we discuss a Java based fiamework, The Java Cryptography
Architecture (JCA), we will use to implement our elliptic curve cryptosystem The
discussion is based on the treatment of JCA presented in [KNUD].
JCA is a framework that specifies design patterns for designing cryptographic
concepts and algorithms. For example any mathematical algorithm that performs
encryption is called a C i p h e r . The JCA architecture separates concepts from their
implementations. These concepts are encapsulated by classes in the
j ava. security and j a v a x . c r y p t o packages. These classes are called
concept classes. For example the concept of a Cipher is represented by the
j avax. cryp<o. Cipher concept class.

84 Principles and Practice of P r o g r a m m i n g in Java 2002

 JCA relies heavily on the factory method design pattern to supply instances of its
concept classes. A factory method is basically a special kind of static method that
returns an instance of a class. A thorough discussion of the factory method design
pattern appears in [GAMMA]. Tile idea here is that a concept class is asked for an
instance that implements a particular algorithm. This is accomplished using a
getInstance factory method. The following code fragment demonstrates the
process by producing an instance of the Cipher concept class that uses the DES
algorithm:
Cipher cryptobject =Cipher.getInstance("DES") ;
One major advantage of this set up is that to change the cryptographic algorithm used
you need only change the argument in the g e t I n s t a n c e method. We still have not
explained how to implement the algorithms called via these factory methods. This
implementation is accomplished by security providers.
These providers are at the root ofJCA. A provider is a collection of algorithm classes
headed up by a j a v a . s e c u r i t y . P r o v i d e r object. This object keeps a list of all
algorithms supported by the security provider. The system works as follows. When a
factory method is used to request a specific algorithm, it is the provider architecture,
behind the scenes, that supplies the algorithm. The j a v a . s e c u r i t y . S e c u r i t y
class manages security provider> When a progam calls one of the factory methods to
obtain a usefial cryptographic object, the factory method asks the S e c u r i t y class
to provide the object. The S e c u r i t y class, in turn, examines its providers to see if
they contain a match for the concept and algorithm requested. It does this by looking
at the Provider object for each security provider. In the code fragment above the
Security class would poll all its providers to see if any had an implementation of
the DES Cipher, and would return an object if successful. The program is oblivious to
this process. The provider used in this paper was an Austrian implementation called
IAIK. Details appear in [IA1K].
We have briefly described a comprehensive framework for implementing useful
easy to use cryptographic components that can be incorporated into real applications.
If we wish to use our elliptic curve cryptosystem in this way we must follow the JCA
specification and design a security provider to contain our algorithm. This process is
the subject of the next section.
. Writing a JCA compliant security provider for the elliptic curve algorithm
At the time of writing no security provider implementing an elliptic curve
cryptosystem existed to the authors' knowledge It was therefore decided to
implement our own provider. Our objectives were to see how straightforward it
would be to build our own provider and to test how suitable Java really was for
developing cryptographic applications. The Pacility to incorporate many algorithms
into the same JCA based interface leads to more choice for developers when
choosing the right security solutions for their needs.
Specifically, we want to write a suite of classes to support EIGamal based elliptic
curve signatures and Ciphers. A detailed discussion of how to create an EIGamal
provider appears [KNUD]. We extend this to develop our elliptic curve system.
Developing a provider consists of the following four steps,
i) Write a Provider class ii) Write a data Block Handling class
iii) Write Key generating classes iv) Implement the Cipher and Signature classes

Principles and Practice of Programming in Java 2002 85

 The first step in writing a security provider is to define the Provider class. As
mentioned earlier this class is basically a list of algorithm names and corresponding
implementations. The algorithm name is made up of a concept class type and a name.
For example our elliptic curve cipher is defined as follows,
Cipher. ECEG : j c e s t u f f . c r y p t o . E C E G C i p h e r
ECEG will be the argument used by g e t I n s t a n c e methods to invoke our elliptic
curve cipher, ECEGCipher, located in the package j c e s t u f f . c r y p t o . We
define Key Generation and Signature algorithms in a similar fashion. The P r o v i d e r
class must be then installed either dynamically at runtime or statically by editing the
j a v a . s e c u r i t y file in JDK. We have now set up a connection between tiactory
method arguments and classes.
The next problem that arises is the issue of block handling, which refers to the
cipher's ability to deal with variable length data. The encryption algorithms deal with
fixed length blocks of data so any data input to a cipher algorithm must be split up
into manageable blocks. [KNUD] provides a mechanism for buffering and block
handling for a generic C i p h e r . This B l o c k C i p h e r class extends C i p h e r and
implements a simple buffering scheme that chops up input data and feeds it in blocks
to the encryption algorithms. The block size is calculated based on the size of
underlying field used so B l o c k C i p h e r will have to be fed the block size from
Cipher
The next step is the development of classes to generate the Key pairs necessary for
the encryption and decryption processes. We begin by writing a container class
ECEGKey to store the elliptic curve's coefficients, the base point, and the field size.
E C E G P r i v a t e K e y and E C E G P u b l i c K e y both extend ECEGKey and store the
generated private and public keys. ECEGPub 1 i cKe y implements the Pub 1 i cKe y
interface, which is really only used for clarity and type safety so users know what
kind of key they are dealing with. The same applies for ECEGPrivateKey. These
interfaces will be seen in the implementation section below. Finally
E C E G K e y P a i r G e n e r a t o r extends the K e y P a i r G e n e r a t o r concept class and
implements the generation algorithms above to create our keys. Heavy use is made of
the Java B i g I n t e g e r class, which provides many very uset\fl methods tbr large
number generation and manipulation. When the keys are generated they need to be
stored. This raises the problems of key management, distribution, and security.
Ideally a key distribution protocol should be established and implemented. For our
purposes we make use of the K e y M a n a g e r class used by [KNUD]. Basically
K e y M a n a g e r provides the functionality to store Keys in and retrieve keys from
files. In a lot of applications the public keys of many users need to be stored.
K e y M a n a g e r accommodates this by associating a username to each public key and
providing a g e t P u b l i c k e y ( u s e r n a m e ) method to retrieve the public key. Note
there will only ever be one private key in the K e y M a n a g e r . Again the
K e y M a n a g e r class is not a secure Key management process but it suffices for
demonstration purposes.
Our cipher class called E C E G C i p h e r extends B l o c k C i p h e r . The first task of
E C E G C i p h e r is to get the public key for encryption or the private key for
decryption. These keys are fetched in the calling application and passed to the
E C E G C i p h e r object via the C i p h e r method i n i t . We will discuss this process
in the next section. The next task of E C E G C i p h e r is to calculate the block size. The

86 Principles and Practice of P r o g r a m m i n g in Java 2002

 field size is imported from the ECEGKev class and plaintext and ciphertext block
sizes are calculated. BlockCipher then uses these values to block handle the data.
Note that the ciphertext blocks need to be about four times as big as the plaintext
blocks. The next task is to encrypt a block of data using the E n c r y p t B l o c k
method. This method implements the algorithm previously discussed using the public
key already passed to ECEGCipher. When the data has been encrypted the
components of the ciphertext are copied to an output buffer in byte array form.
Decryption is handled similarly. The Signature class, ECDSA is implemented in the
same way following the specification given in [F1PS].
We have now designed our provider. To be a use~l Java component it must have a
relatively simple interface for developers to incorporate it into their applications. We
discuss this process in the next section. The source code for this provider is available
from the authors.
. A d d i n g an Elliptic curve cryptosystem to an application
Our objective in this section is to demonstrate how a JCA based encryption
component can be incorporated into a Java application. The application chosen is for
demonstration purposes only and does not claim to follow a completely secure
cryptographic protocol. The application chosen is a secure hybrid e-mail prototype
application. The term hybrid refers to the cryptographic structure of the prototype.
There are two encryption systems in operation namely a symmetric and asymmetric
encryption component. A symmetric cryptosystem is a system in which two users
share a common private key and use it to encrypt and decrypt data. Symmetric
Cryptosystems are fast but suffer from a ~ndamental problem of key handling and
distribution. Our symmetric component uses the AES system.
An Asymmetric or public key cryptosystem uses two keys, a public key to encrypt
and a private key to decrypt. The public key is published in an electronic "phone
book". This reduces the key load but in general the algorithms are more involved and
slower than symmetric. They are, in general, more secure than symmetric algorithms.
The asymmetric system we use is our ECEG system.
A hybrid system attempts to utilise the strength of both systems. It uses an
asymmetric algorithm to transmit a symmetric key between two users. The users then
use the faster but less secure symmetric key to set up a secure communication. An
adversary would need to break the stronger asymmetric algorithm to obtain this key.
The slower asymmetric system only transports a key so performance is not affected.
The encryption process works as follows. The client composes an email. The email
application generates a symmetric AES key. The email application uses the
symmetric key to encrypt the email message. The email application uses the ECEG
component to encrypt the ArES key. The email application uses the ECDSA signature
component to sign the message, and all this data is dumped in to a
ByteArrayOutputStream, converted to Base 64 and transmitted using SMTP. We will
concentrate on how the email system uses the ECEG component to encrypt a
symmetric key. The code fragment of interest is,
/* Set up a link to the KeyManager file containing all file public keys of recipients */

KeyManager ourKeyManager = KeyManager.getInstance(file location!;

Principles and Practice of Programming in Java 2002 87

 /*Get file recipient's public key. The name of file recipient's public key has been stored in recipname*/

PublicKey recipKey = ourKeyManager.getPublicKey(recipname) ;

/*The Symmetrickey has been generatedand convertedto a bytearm3,, sylnKey. Now encr3'pt .*/
cyferobj= Cipher.getInstance("ECEG") ;
cyferobj.init(Cipher. ENCRYPT MODE, recipkey) ;
byte [] symKeyCiphertext: cyferobj.doFinal(symKey) ;

Note the d o F i n a l method is a C i p h e r method that passes the data to the C i p h e r

object c y f e r o b j that in turn performs an ECEG encryption on it. The result of this
process is a byte array containing the ECEG encrypted symmetric key. This interface
code is all the developer needs to know to implement this cryptographic component.
6. Conclusions and future work

The JCA provides a robust and easily evolved framework for the development of
security products. It provided the flexibility to design user defined systems that fit
neatly into the architecture. The existing range of protocols and algorithms can be
extended with relative ease once the JCA blueprint is followed.
Developers can use these crypto components without detailed knowledge of what lies
beneath the hood which speeds up development time and allows developers to
concentrate on the whole system's security. This architecture together with Java
classes like B i g Z n t e g e r demonstrate the suitability of the Java programming
language for developing strong cryptographic products. Although performance has
not been mentioned the authors found no significant performance issues with the
cryptographic components.
The Elliptic curves chosen were the standard curves recommended in [FIPS].
Choosing appropriate curves is a very complex process and future enhancements to
the ECEG provider include developing classes for creating appropriate Elliptic curves
for ECEG to use.
. References
[GAMMA] Gamma, E., Helm, R., Johnson, R., Vlissides, J., "Design Patterns:
Elements of Reusable Software", Addision-Wesley, 1995.
[GARRETT] P. Garrett, "Making, Breaking Codes", Prentice-Hall, 2001.
[taLK] IAIK documentation, http :/ jcewww, iaik.at products jce "
doctmtentation, javadoc index, html
[FinS] FIPS 186-2, Digital Sig~lature Standard, Federal Information
Processing Standards Publication 186-2, US Dept. of
Commerce/NIST National Institute of Standards and Technology,
1994.
[KNUD] B. Knudsen, "Java Cryptography", O'Reilly, 1998.
[KOB] Koblitz, N., "A course in Number theory and Cryptography",
Springer Verlag, 1994.
[NIST] National Institute of Standards and Technology.
[SMART] I. Blake, G. Seroussi & N. Smart, "Elliptic curves in
cryptography", London Mathematical Society, 1997.
[TAtaR] E1Gamal, T., "A public key cryptosystem and signature scheme
based on discrete logarithms", IEEE Trans. on Information Theory
IT-31, (1985), 473-481.

88 Principles and Practice of Programming in Java 2002