ECC programming in Java Card

V. Gayoso Martı́nez and L. Hernández Encinas

Institute of Physical and Information Technologies (ITEFI)
Spanish National Research Council (CSIC)
Madrid, Spain
Email: {victor.gayoso,luis}@iec.csic.es

Abstract—Elliptic Curve Cryptography (ECC) is a branch ECC applications in Java Card. In order to facilitate the
of public-key cryptography based on the arithmetic of el- understanding of the example, we have included the script
liptic curves. Given its mathematical characteristics, ECC needed to execute it and the console output obtained when
is currently one of the best options for protecting sensitive
information. The lastest version of the Java Card platform running the applet in a simulator.
includes several classes related to elliptic curves. However, The rest of this paper is organized as follows: Section II
potential developers are discouraged by the peculiarities of presents a brief mathematical introduction to elliptic curves.
its programming model and the scarce information available. In Section III, we review some important concepts about
In this work, we present an up to date and extensive review of smart cards. Section IV describes the most relevant charac-
the ECC support in Java Card. In addition to that, we offer to
the reader the complete code of two applications that will allow
teristics of Java Card, including the new features presented
programmers to understand and test the entire application by each version. Section V details the ECC functionality
development process in Java Card. included in the different Java Card releases. In Section VI,
we offer two code examples which demonstrate how to
Keywords-elliptic curves; information security; Java Card;
public key cryptography; smart cards; create digital signatures and produce a shared secret using a
key agreement procedure. Finally, Section VII summarizes
As it is well known, in 1985 Miller [1] and Koblitz our conclusions about this topic.
[2] independently proposed a cryptosystem based on the
ECDLP (Elliptic Curve Discrete Logarithm Problem). This I. E LLIPTIC C URVE C RYPTOGRAPHY
field of cryptography is usually known as ECC (Elliptic
Curve Cryptography). In comparison with other public- An elliptic curve E over the field F is a regular projective
key cryptosystems, ECC uses significantly shorter keys to curve of genus 1 with at least one rational point ([5] and
achieve the same level of security [3]. This makes ECC the [6]). Every elliptic curve admits a canonical equation called
perfect choice for devices with limited resources [4]. the general Weierstrass form. That equation in homogeneous
coordinates is
In 1996, the smart card sector witnessed the appearance of
a new technology named Java Card. Java Card is the smallest Y 2 Z +a1 XY Z +a3 Y Z 2 = X 3 +a2 X 2 Z +a4 XZ 2 +a6 Z 3 ,
of the Java platforms, and it allows to develop and install
a specific type of Java-based application (called applet) in with a1 , a2 , a3 , a4 , a6 ∈ F and ∆ ̸= 0, where ∆ is the
smart cards compliant with the Java Card specifications. discriminant of E.
This card technology is widely used in several sectors, for The homogeneous Weierstrass equation defines a projec-
example in the cell phone and banking industries. In those tive plane curve which has a special point, the point at
sectors security is essential, so the integration of crypto- infinity, which is denoted as O = [0 : 1 : 0]. In principle that
graphic capabilities is a typical application requirement. curve does not have to be elliptic, as it could have singular
Although Java Card is derived from the Java language, points. Due to that fact, the condition ∆ ̸= 0 assures that the
its programming model has several important particularities, curve is regular, which is equivalent to stating that there are
so most Java programmers are not able to develop applets no curve points where the first derivatives of the function
unless they are provided the proper training. Unfortunately, are cancelled [7].
the number of learning resources about this technology In practice, instead of the general Weierstrass equation,
is limited, which makes the development of Java Card two short Weierstrass forms depending on the characteristic
applications a complex and resource-consuming operation of the finite field Fq are typically used:
for most software companies. • If the finite field is a prime field, i.e. F = Fp , where
This contribution analyses the ECC capabilities in every p > 3 is a prime number, the equation defining the
Java Card version released so far, including all the classes (non-supersingular) elliptic curve becomes
and ECC functions implemented. In addition to that, we
provide a complete code example that shows how to develop y 2 = x3 + ax + b.
 Figure 1. Command APDU Figure 2. Response APDU

• If the finite field is a binary field, i.e. F = F2m , where • Data (variable length, optional): information returned
m is an integer number, then the equation of the (non- by the card application.
supersingular) elliptic curve is • SW1 (1 byte): first status byte, which provides general
information about the result of the command execution.
y 2 + xy = x3 + ax2 + b. • SW2 (1 byte): second status byte.

II. S MART CARDS III. JAVA C ARD

A smart card is a plastic card with an embedded chip that The first Java Card specification was presented in Novem-
controls the access to the stored data. The most widespread ber 1996 by engineers working for the French company
communication model for smart cards is composed by the Schlumberger. Their goal was to create a technology that
byte oriented protocol T=0 and the APDU (Application could combine the ease of development provided by the Java
Protocol Data Unit) elements. language and the security features associated to smart cards.
APDUs, built according to the ISO/IEC 7816-3 [8] and Shortly after submitting the first draft of the Java Card API,
7816-4 [9] specifications, are the data packets exchanged Gemplus and Bull joined Schlumberger in order to constitute
between the external application and the card by means of a the Java Card Forum, a consortium created to evolve this
smart card reader. The card operating system is responsible technology.
for analysing any incoming APDU and redirect it to the After the presentation of Java Card 1.0, Sun Microsystems
application it is intended for. The operating system is also began to actively cooperate with those smart card manu-
responsible for retrieving the response data from the card facturers. The result was the announcement in November
application and submit it to the external application using 1997 of Java Card 2.0. This new version represented a
the card reader. major milestone in Java Card, as it provided a mechanism
There are two types of APDUs: command and response. for object-oriented programming and improved the level
Figure 1 shows the format of command APDUs, which of detail in the specification of the application runtime
consist of a header and optionally a body with the following environment.
elements: Due to the need to adapt the capabilities of the Java
• CLA (1 byte): command class. language to the physical limitations of smart cards, since its
• INS (1 byte): specific instruction within the class. inception it became clear that it was impossible to implement
• P1 (1 byte): first parameter associated to the instruction. some of the Java features. For example, the char, double,
It can be used to give more information about the float, and long types were not supported, multithreading
instruction, or as input data. was not allowed, and the dimension of data arrays was
• P2 (1 byte): second parameter associated to the instruc- limited to one.
tion. As in the previous case, it can be used to give more Java Card 2.1 was released in March 1999 and consisted
information about the instruction, or as input data. of three specifications:
• Lc (1 byte, optional): number of bytes in the data field • Java Card API: defines the Java packages available for
of the command. Since its highest value is 0xFF, the programmers.
maximum data length is 255 bytes, although some cards • JCVM (Java Card Virtual Machine): specifies the subset
allow to send 256 bytes using the value 0x00. of the Java language that can be used and the virtual
• Data (variable size, optional): information to be pro- machine needed for the execution of applets.
cessed by the applet. • JCRE (Java Card Runtime Environment): describes the
• Le (1 byte, optional): maximum number of bytes to be applet runtime behaviour.
included in the data field of the response APDU. Java Card 2.2 was released in September 2002, and
In comparison, the format of any response APDU is included the following novelties:
simpler (see Figure 2), as it only includes the following • JCRMI (Java Card Remote Method Invocation) imple-
items: mentation.
 • KeyAgreement class extension to include the key
agreement functions ECDH (Elliptic Curve Diffie Hell-
man) and ECDHC (Elliptic Curve Diffie Hellman with
Cofactor), with the peculiarity that the output of these
functions is not the product u · V of the first user’s
private key u and the second user’s public key V (and
additionally the cofactor in the ECDHC case), but the
result of feeding the first coordinate of the point u · V
to the SHA-1 function [11].
• KeyBuilder class extension, which defines the per-
mitted key lengths for ECC and other cryptosystems.
In the case of elliptic curves over prime fields, the valid
Figure 3. Java Card timeline lengths in Java Card 2.2 were 112, 128, 160, and 192
bits, while in the case of curves defined over binary
fields it was possible to use key lengths of 113, 131,
• Support of up to 4 logical channels. 163, and 193 bits.
• Improvement of the memory resource management. • Signature class extended with the implementation
• New classes for cryptographic algorithms. of ECDSA (Elliptic Curve Digital Signature Scheme)
In March 2006, Sun announced the availability of Java using the hash function SHA-1 [3].
Card 2.2.2, which provided the following improvements: Java Card versions 2.2.1 and 2.2.2 did not incorporate
• Support of up to 20 logical channels. new ECC features. However, Java Card 3.0 included the
• Implementation of new cryptographic algorithms. following novelties:
• New classes for biometric recognition technology. • In elliptic curves over prime fields, key lengths of 224,
Finally, in March 2008 the Java Card 3.0 specification was 256, and 384 bits were available for the first time.
released. With the aim to adapt the Java Card technology • The implementation of the functions ECDH and
to the needs of internet services, for the first time the ECDHC was extended in order to accept new variants
specification was divided into two different editions: in which the output of the function is directly the first
coordinate of the product u · V (optionally with the
• Connected Edition: introduces an enhanced runtime
cofactor), eliminating the use of the SHA-1 function in
environment and a new virtual machine that provides
the final step of the procedure.
network-oriented features such as the support for web
• The implementation of ECDSA permitted to use that
applications using servlets.
digital signature scheme in combination with the SHA-
• Classic Edition: represents an evolution of Java Card
224, SHA -256, SHA-384, and SHA-512 functions.
2.2.2, including not only the correction of errors, but
also several new features like the possibility to use some Finally, the revision version 3.0.4 added the possibility to
of the algorithms described in the NSA (National Secu- use 521-bit keys in curves defined over prime fields.
rity Agency) Suite B document [10]. In the remaining
sections of this contribution, whenever we mention Java V. C ODE EXAMPLES
Card 3.0 we will implicitly refer to the Classic Edition. The JCDK (Java Card Development Kit) is a software
As a summary of the previous information, Figure 3 shows package that includes a complete development environment
the timeline of the different Java Card releases. in which applications written for the Java Card platform can
be developed and tested [12]. The JCDK includes a suite of
IV. ECC IN JAVA C ARD tools along with a reference implementation written in C.
Before JCDK 3.0.2, the reference implementation did
Java Card 2.2 was the first version that included ECC not include support for cryptographic functions. That was
capabilities. More specifically, that version defined the fol- a significant drawback for developers interested in this
lowing elements: technology. Fortunately, starting with JCDK 3.0.2, it was
• New classes ECKey, ECPrivateKey, and possible to use some of the cryptographic functions de-
ECPublicKey for the creation and management of scribed in the Java Card API (more specifically, those listed
public and private keys. Those classes can be used in the Development Kit User Guide pertaining to the JCDK
with elliptic curves defined over prime and binary version in use).
fields. Regarding ECC, the reference implementation in JCDK
• KeyPair class extension to allow the use of ECC key 3.0.2 allows to use the functions ECDH, ECDHC, and
pairs. ECDSA only with curves defined over prime fields. From the
set of key lengths specified in the Java Card API, the ones 42 case (byte)0xD2:
43 processINSD2(apdu);
available in the reference implementation are 112, 128, 160, 44 return;
and 192 bits. For each of those key lengths, the development 45 case (byte)0xD3:
46 processINSD3(apdu);
kit implements one curve. The elliptic curves available in 47 return;
JCDK 3.0.2 are the following curves specified in the SECG 48 default:
49 ISOException.throwIt((short) 0x6661);
SEC 2 standard [13]: secp112r1, secp128r1, secp160k1, and 50 }
secp192k1. 51 }
52
Although the applet development and execution simula- 53 /////////////////////////////////////////////////
tion steps can be performed using the command-line tools 54 // INS D1 - KEY PAIR GENERATION //
55 // Generates a key pair for both users U and V //
provided by the JCDK, Tim Boudreau has developed a 56 // APDU EXAMPLE: 00D1000000 //
connector for the NetBeans IDE (Integrated Development 57 /////////////////////////////////////////////////
58
Environment). Interested readers can obtain the instructions 59 private void processINSD1(APDU apdu)
for its installation at [14]. The minimum version require- 60 {
61 try
ments for installing this plugin are the following ones: 62 {
• NetBeans: 6.8. 63 kpU = new KeyPair(KeyPair.ALG_EC_FP,
64 KeyBuilder.LENGTH_EC_FP_128);
• Java Development Kit: 6. 65 kpU.genKeyPair();
• Java Card Development Kit: 3.0.2. 66 privKeyU = (ECPrivateKey) kpU.getPrivate();
67 pubKeyU = (ECPublicKey) kpU.getPublic();
• Java Card plugin for NetBeans: 1.3. 68
69 kpV = new KeyPair(KeyPair.ALG_EC_FP,
A. Key agreement example 70 KeyBuilder.LENGTH_EC_FP_128);
71 kpV.genKeyPair();
Listing 1 contains the code that we have developed in 72 privKeyV = (ECPrivateKey) kpV.getPrivate();
73 pubKeyV = (ECPublicKey) kpV.getPublic();
order to demonstrate how to generate two pairs of 128-bit 74 }
keys corresponding to users U and V, retrieve the most 75 catch(Exception exception)
76 {
relevant information from them, and generate a shared 77 ISOException.throwIt((short) 0xFFD1);
secret using the key agreement function ECDH. 78 }
79 }
80
81 ///////////////////////////////////////
1 import javacard.framework.*;
82 // INS D2 - PARAMETER DATA RETRIEVAL //
2 import javacard.security.*;
83 // P1: user //
3
84 // Values P1: 01: user U, 02: user V //
4 public class JCDiffieHellman extends Applet
85 // P2: parameter to retrieve //
5 {
86 // Values P2: 01: A, 02: B, 03: P, //
6 byte[] baTemp = new byte[255];
87 // 04: public key, //
7 byte[] baPrivKeyU, baPrivKeyV, baPubKeyU, baPubKeyV;
88 // 05: private key //
8 short len;
89 // APDU EXAMPLE: 00D2020300 //
9
90 ///////////////////////////////////////
10 KeyPair kpU, kpV;
91
11 ECPrivateKey privKeyU, privKeyV;
92 private void processINSD2(APDU apdu)
12 ECPublicKey pubKeyU, pubKeyV;
93 {
13
94 byte buffer[] = apdu.getBuffer();
14 KeyAgreement ecdhU, ecdhV;
95
15
96 try
16 public static void install(byte[] bArray,
97 {
17 short bOffset, byte bLength)
98 switch(buffer[3])
18 {
99 {
19 new JCDiffieHellman();
100 case 0x01: // Parameter A
20 }
101 if(buffer[2]==(byte)0x01)
21
102 len = pubKeyU.getA(baTemp,(short) 0);
22 protected JCDiffieHellman()
103 else
23 {
104 len = pubKeyV.getA(baTemp,(short) 0);
24 register();
105 apdu.setOutgoing();
25 }
106 apdu.setOutgoingLength((short) len);
26
107 apdu.sendBytesLong(baTemp,(short) 0, len);
27 public void process(APDU apdu)
108 break;
28 {
109
29 byte[] buffer = apdu.getBuffer();
110 case 0x02: // Parameter B
30
111 if(buffer[2]==(byte)0x01)
31 if (selectingApplet())
112 len = pubKeyU.getB(baTemp,(short) 0);
32 return;
113 else
33
114 len = pubKeyV.getB(baTemp,(short) 0);
34 if(buffer[ISO7816.OFFSET_CLA] != (byte)0x00)
115 apdu.setOutgoing();
35 ISOException.throwIt((short) 0x6660);
116 apdu.setOutgoingLength((short) len);
36
117 apdu.sendBytesLong(baTemp,(short) 0, len);
37 switch (buffer[ISO7816.OFFSET_INS])
118 break;
38 {
119
39 case (byte)0xD1:
120 case 0x03: // Parameter P
40 processINSD1(apdu);
121 if(buffer[2]==(byte)0x01)
41 return;
122 len = pubKeyU.getField(baTemp, (short) 0); 202
123 else 203 len = pubKeyU.getW(baTemp,(short) 0);
124 len = pubKeyV.getField(baTemp, (short) 0); 204 baPubKeyU = new byte[len];
125 apdu.setOutgoing(); 205 Util.arrayCopyNonAtomic(baTemp,(short)0,
126 apdu.setOutgoingLength((short) len); 206 baPubKeyU, (short)0, len);
127 apdu.sendBytesLong(baTemp,(short) 0,len); 207
128 break; 208 ecdhV = KeyAgreement.getInstance(KeyAgreement.
129 209 ALG_EC_SVDP_DH,false);
130 case 0x04: // Public key 210 ecdhV.init(privKeyV);
131 if(buffer[2]==(byte)0x01) 211 len = ecdhV.generateSecret(baPubKeyU,
132 len = pubKeyU.getW(baTemp,(short) 0); 212 (short)0, len, baTemp, (short)0);
133 else 213
134 len = pubKeyV.getW(baTemp,(short) 0); 214 apdu.setOutgoing();
135 apdu.setOutgoing(); 215 apdu.setOutgoingLength((short) len);
136 apdu.setOutgoingLength((short) len); 216 apdu.sendBytesLong(baTemp,(short) 0, len);
137 apdu.sendBytesLong(baTemp,(short) 0,len); 217 break;
138 break; 218
139 219 default:
140 case 0x05: // Private key 220 throw new IndexOutOfBoundsException();
141 if(buffer[2]==(byte)0x01) 221 }
142 len = privKeyU.getS(baTemp,(short) 0); 222 }
143 else 223 catch(Exception exception)
144 len = privKeyV.getS(baTemp,(short) 0); 224 {
145 apdu.setOutgoing(); 225 ISOException.throwIt((short) 0xFFD2);
146 apdu.setOutgoingLength((short) len); 226 }
147 apdu.sendBytesLong(baTemp,(short) 0,len); 227 }
148 break; 228 }
149
150 default: Listing 1. Java Card ECDH code example.
151 throw new IndexOutOfBoundsException();
152 }
153 } The most important classes and methods that appear in
154 catch(Exception exception)
155 { Listing 1 are the following [15]:
156 ISOException.throwIt((short) 0xFFD2); • install(): method called by the JCRE to create an
157 }
158 } instance of the applet.
159 • register(): method used by the application to
160 ///////////////////////////////////////
161 // INS D3 - SHARED SECRET GENERATION // register this applet instance with the JCRE and to assign
162 // P1: user // the Java Card platform name of the applet as its instance
163 // Values P1: 01: user U, 02: user V //
164 // APDU EXAMPLE: 00D3010000 // AID (Application Identifier) bytes.
165 /////////////////////////////////////// • process(): method called by the JCRE to process
166
167 private void processINSD3(APDU apdu) an incoming APDU command.
168 { • apdu.getBuffer(): returns the APDU content as
169 byte buffer[] = apdu.getBuffer();
170 a byte array.
171 try • apdu.setOutgoing(): method used to set the data
172 {
173 switch(buffer[2]) transfer direction to outbound and to obtain the ex-
174 { pected length of the response (APDU field Le).
175 case 0x01: // Process from U’s standpoint
176 len = privKeyU.getS(baTemp,(short) 0); • apdu.sendBytesLong(): sends the specified bytes
177 baPrivKeyU = new byte[len]; from the output byte array.
178 Util.arrayCopyNonAtomic(baTemp, (short)0,
179 baPrivKeyU, (short)0, len); • KeyPair: container for a key pair.
180 • ECPrivateKey: interface that allows the implemen-
181 len = pubKeyV.getW(baTemp,(short) 0);
182 baPubKeyV = new byte[len]; tation of ECC private keys.
183 Util.arrayCopyNonAtomic(baTemp,(short)0, • ECPublicKey: interface that allows the implementa-
184 baPubKeyV, (short)0, len);
185 tion of ECC public keys.
186 ecdhU = KeyAgreement.getInstance(KeyAgreement. • KeyAgreement: base class for key agreement algo-
187 ALG_EC_SVDP_DH, false);
188 ecdhU.init(privKeyU); rithms.
189 len = ecdhU.generateSecret(baPubKeyV, • genKeyPair(): method that initializes the key ob-
190 (short)0, len, baTemp, (short)0);
191 jects encapsulated in the KeyPair instance in use with
192 apdu.setOutgoing(); new key values.
193 apdu.setOutgoingLength((short) len);
194 apdu.sendBytesLong(baTemp,(short) 0, len); • getPrivate(): returns a reference to the private key
195 break; component of the KeyPair object in use.
196
197 case 0x02: // Process from V’s standpoint • getPublic(): returns a reference to the public key
198 len = privKeyV.getS(baTemp,(short) 0); component of the KeyPair object in use.
199 baPrivKeyV = new byte[len];
200 Util.arrayCopyNonAtomic(baTemp,(short)0, In order to simulate the applet execution, it is necessary
201 baPrivKeyV, (short)0, len);
to use a script with the command APDUs to be sent to the
 → 00D3010000
smart card. Listing 2 shows the content of our script file. ← 248B7E259095F53613641F1DD27DB61768D946
The powerup command prepares the APDUTool utility D79000
for reading command APDUs, so it must be executed → 00D3020000
← 248B7E259095F53613641F1DD27DB61768D946
before any command APDU is sent. In comparison, the D79000
powerdown command ends the APDUTool processing.
For every command APDU in the script, the six bytes that
compose the APDU correspond to the CLA, INS, P1, P2, of his public key is 0x0479D69944F614C7AC9C6B5DF
Lc, and Le fields mentioned in Section III [16]. 66C391AE2F77F04CBF17257CE92F5D791B9B7533
C. Besides, V’s private and public key are 0x835DC74BE
powerup; B36D19C28E6474A4D400E0E and 0x04620044FA38
// Applet selection (AID: C9AA4E15B3F6)
92038A9C3ADB194916E31F01129E2429B92B7503
0x00 0xA4 0x04 0x00 0x06 0xC9 0xAA 0x4E 0x15 0xB3 0xF6 7979D17C1D6CD7, respectively. Finally, the value of the
0x7F;
shared secret is 0x248B7E259095F53613641F1DD27
//Command APDUs DB61768D946D7.
0x00 0xD1 0x00 0x00 0x00 0x7F; B. Digital signature example
0x00 0xD2 0x01 0x01 0x00 0x7F; The code of Listing 3 allows to generate a digital signature
0x00 0xD2 0x01 0x02 0x00 0x7F;
0x00 0xD2 0x01 0x03 0x00 0x7F; associated to the text “ECDSA example”, and to validate the
0x00 0xD2 0x01 0x04 0x00 0x7F; validity of that signature, using a 192-bit key pair.
0x00 0xD2 0x01 0x05 0x00 0x7F;
The goal of using a predefined key pair in the example
0x00 0xD2 0x02 0x01 0x00 0x7F; consists in simulating the data persistence of real smart
0x00 0xD2 0x02 0x02 0x00 0x7F;
0x00 0xD2 0x02 0x03 0x00 0x7F; cards. Besides, instead of codifying the text to be signed,
0x00 0xD2 0x02 0x04 0x00 0x7F; we have developed the applet so it signs the string that
0x00 0xD2 0x02 0x05 0x00 0x7F;
is sent to the card using one of the valid APDUs for this
0x00 0xD3 0x01 0x00 0x00 0x7F; applet. Regarding the verification process, it is necessary to
0x00 0xD3 0x02 0x00 0x00 0x7F;
send to the card both the digital signature and the original
powerdown; text.
Listing 2. Applet execution script.
1 import javacard.framework.*;
The result of running the script is the following sequence 2 import javacard.security.*;
of command and response APDUs: 3
4 public class JCECDSA extends Applet
→ 00A4040006C9AA4E15B3F6 5 {
6
← 9000 7 byte[] baTemp = new byte[255];
→ 00D1000000 8 byte[] baSignature = new byte[255];
← 9000 9 byte[] baText = new byte[255];
→ 00D2010100 10 byte[] baPrivKey = {(byte)0x33, (byte)0x4a,
← FFFFFFFDFFFFFFFFFFFFFFFFFFFFFFFC9000 11 (byte)0x6a, (byte)0xa1, (byte)0xd5, (byte)0x42,
→ 00D2010200 12 (byte)0xc3, (byte)0x12, (byte)0xbd, (byte)0xfa,
← E87579C11079F43DD824993C2CEE5ED39000 13 (byte)0x70, (byte)0x61, (byte)0x99, (byte)0xb4,
→ 00D2010300 14 (byte)0x11, (byte)0xf7, (byte)0xa8, (byte)0xdd,
15 (byte)0xcf, (byte)0xaf, (byte)0x56, (byte)0x3a,
← FFFFFFFDFFFFFFFFFFFFFFFFFFFFFFFF9000 16 (byte)0x7c, (byte)0xb8};
→ 00D2010400 17 byte[] baPubKey = {(byte)0x04, (byte)0x4e,
← 0479D69944F614C7AC9C6B5DF66C391AE2F77F 18 (byte)0x0d, (byte)0xb7, (byte)0xd8, (byte)0x81,
04CBF17257CE92F5D791B9B7533C9000 19 (byte)0x39, (byte)0xee, (byte)0x2a, (byte)0x4c,
→ 00D2010500 20 (byte)0xd4, (byte)0x75, (byte)0x47, (byte)0x6b,
← 595DA05E618DA5A664EF6A931272F5039000 21 (byte)0x62, (byte)0x9c, (byte)0x10, (byte)0x41,
→ 00D2020100 22 (byte)0x9e, (byte)0x3d, (byte)0xa8, (byte)0x35,
← FFFFFFFDFFFFFFFFFFFFFFFFFFFFFFFC9000 23 (byte)0x44, (byte)0x5f, (byte)0x50, (byte)0x4c,
24 (byte)0x55, (byte)0x54, (byte)0x40, (byte)0xc4,
→ 00D2020200 25 (byte)0x16, (byte)0xfa, (byte)0x2d, (byte)0xde,
← E87579C11079F43DD824993C2CEE5ED39000 26 (byte)0xd7, (byte)0x67, (byte)0xf5, (byte)0xea,
→ 00D2020300 27 (byte)0x0d, (byte)0xbc, (byte)0x98, (byte)0x49,
← FFFFFFFDFFFFFFFFFFFFFFFFFFFFFFFF9000 28 (byte)0x7e, (byte)0x95, (byte)0x47, (byte)0xb0,
→ 00D2020400 29 (byte)0xb8, (byte)0x09, (byte)0x63};
← 04620044FA3892038A9C3ADB194916E31F0112 30

9E2429B92B75037979D17C1D6CD79000 31 short len, lenText, lenSignature;

→ 00D2020500 32 boolean result = false;
33
← 835DC74BEB36D19C28E6474A4D400E0E9000 34 KeyPair kp;
35 ECPublicKey pubKey;
36 ECPrivateKey privKey;
As it can be observed, U’s private key is 0x595DA05E 37 Signature ecdsa;
618DA5A664EF6A931272F503, while the serialization 38
39 public static void install(byte[] bArray, 119
40 short bOffset, byte bLength) 120 while (numBytesInput > 0)
41 { 121 {
42 new JCECDSA(); 122 Util.arrayCopyNonAtomic(buffer,
43 } 123 ISO7816.OFFSET_CDATA, baText,
44 124 lenText, numBytesInput);
45 protected JCECDSA() 125 lenText += numBytesInput;
46 { 126 numBytesInput =
47 register(); 127 apdu.receiveBytes(ISO7816.OFFSET_CDATA);
48 } 128 }
49 129
50 public void process(APDU apdu) 130 try
51 { 131 {
52 byte[] buffer = apdu.getBuffer(); 132 ecdsa.init(privKey, Signature.MODE_SIGN);
53 133 len = ecdsa.sign(baText, (short)0, lenText,
54 if (selectingApplet()) 134 baSignature, (short)0);
55 return; 135
56 136 apdu.setOutgoing();
57 if(buffer[ISO7816.OFFSET_CLA] != (byte)0x00) 137 apdu.setOutgoingLength((short) len);
58 ISOException.throwIt((short) 0x6660 ); 138 apdu.sendBytesLong(baSignature, (short) 0, len);
59 139 }
60 switch (buffer[ISO7816.OFFSET_INS]) 140 catch(Exception exception)
61 { 141 {
62 case (byte)0xD1: 142 ISOException.throwIt((short) 0xFFD2);
63 processINSD1(apdu); 143 }
64 return; 144 }
65 case (byte)0xD2: 145
66 processINSD2(apdu); 146 ///////////////////////////////////////////////
67 return; 147 // INS D3 - SIGNATURE VERIFICATION //
68 case (byte)0xD3: 148 // P1: operation //
69 processINSD3(apdu); 149 // Values P1: 01: text load //
70 return; 150 // 02: signature load //
71 case (byte)0xD4: 151 // APDU EXAMPLE: 00D301000401020304 //
72 processINSD4(apdu); 152 // APDU EXAMPLE: 00D3020006010203040506 //
73 return; 153 ///////////////////////////////////////////////
74 default: 154
75 ISOException.throwIt((short) 0x6661 ); 155 private void processINSD3(APDU apdu)
76 } 156 {
77 } 157
78 158 byte buffer[] = apdu.getBuffer();
79 ////////////////////////////////////////// 159 short numBytesInput =
80 // INS D1 - KEY PAIR GENERATION // 160 apdu.setIncomingAndReceive();
81 // Generates a new key pair of 192 bits // 161
82 // APDU EXAMPLE: 00D1000000 // 162 if(buffer[2]==(byte)0x01) // Text load
83 ////////////////////////////////////////// 163 {
84 164 lenText = 0;
85 private void processINSD1(APDU apdu) 165 while (numBytesInput > 0)
86 { 166 {
87 try 167 Util.arrayCopyNonAtomic(buffer,
88 { 168 ISO7816.OFFSET_CDATA, baText,
89 kp = new KeyPair(KeyPair.ALG_EC_FP, 169 lenText, numBytesInput);
90 KeyBuilder.LENGTH_EC_FP_192); 170 lenText += numBytesInput;
91 kp.genKeyPair(); 171 numBytesInput =
92 privKey = (ECPrivateKey) kp.getPrivate(); 172 apdu.receiveBytes(ISO7816.OFFSET_CDATA);
93 privKey.setS(baPrivKey, (short)0, 173 return;
94 (short)baPrivKey.length); 174 }
95 pubKey = (ECPublicKey) kp.getPublic(); 175 }
96 pubKey.setW(baPubKey, (short)0, 176
97 (short)baPubKey.length); 177 if(buffer[2]==(byte)0x02) // Signature load
98 ecdsa = Signature.getInstance( 178 {
99 Signature.ALG_ECDSA_SHA, false); 179 lenSignature = 0;
100 } 180 while (numBytesInput > 0)
101 catch(Exception exception) 181 {
102 { 182 Util.arrayCopyNonAtomic(buffer,
103 ISOException.throwIt((short) 0xFFD1); 183 ISO7816.OFFSET_CDATA, baSignature,
104 } 184 lenSignature, numBytesInput);
105 } 185 lenSignature += numBytesInput;
106 186 numBytesInput =
107 ////////////////////////////////////////////// 187 apdu.receiveBytes(ISO7816.OFFSET_CDATA);
108 // INS D2 - SIGNATURE // 188 return;
109 // DATA: string to be signed // 189 }
110 // APDU EXAMPLE: 00D20000080102030405060708 // 190 }
111 ////////////////////////////////////////////// 191 ISOException.throwIt((short) 0xFFD3);
112 192
113 private void processINSD2(APDU apdu) 193 }
114 { 194
115 byte buffer[] = apdu.getBuffer(); 195 /////////////////////////////////////
116 short numBytesInput = 196 // INS D4 - SIGNATURE VERIFICATION //
117 apdu.setIncomingAndReceive(); 197 // APDU EXAMPLE: 00D4000000 //
118 lenText = 0; 198 /////////////////////////////////////
 → 00D200000D4543445341206578616D706C65
199
← 37303502180B7C83110CE0B7BAC598C9730A11
200 private void processINSD4(APDU apdu)
201 {
3B0449EBB63580206B2F021900E5669C5797A2
202 try D61D2F3EDD292993857ED48BFAECB47C027090
203 { 00
204 ecdsa.init(pubKey, Signature.MODE_VERIFY); → 00D301000D4543445341206578616D706C65
205 result = ecdsa.verify(baText, (short)0, ← 9000
206 lenText, baSignature, (short)0, lenSignature); → 00D3020037303502180B7C83110CE0B7BAC598
207 } C9730A113B0449EBB63580206B2F021900E566
208 catch(Exception exception) 9C5797A2D61D2F3EDD292993857ED48BFAECB4
209 {
210 ISOException.throwIt((short) 0xFFD4);
7C0270
211 } ← 9000
212 → 00D4000000
213 if(result) ← 9000
214 return;
215 else
216 ISOException.throwIt((short) 0xFFD5);
217 }
218 } In the previous example, the user’s private key is 0x33
4A6AA1D542C312BDFA706199B411F7A8DDCFAF56
Listing 3. Java Card ECDSA code example. 3A7CB8, while the serialization of the public key is 0x04
4E0DB7D88139EE2A4CD475476B629C10419E3DA8
In addition to the classes and methods described regarding 35445F504C555440C416FA2DDED767F5EA0DBC98
the key agreement example, the new elements that appear 497E9547B0B80963. Given the input message “ECDSA
in Listing 3 are the following [15]: example”, coded as 0x4543445341206578616D706C6
• Signature: base class for digital signature algo- 5, the signature generated by the procedure is 0x373035
rithms. 02180B7C83110CE0B7BAC598C9730A113B0449EB
• init(): method that initializes the Signature ob- B63580206B2F021900E5669C5797A2D61D2F3EDD
ject with the appropriate key and mode (sign or verify). 292993857ED48BFAECB47C0270.
• sign(): generates the signature of the input data.
• verify(): verifies the signature of the input data
VI. C ONCLUSION
against the supplied signature.
Listing 4 contains the test script for the JCECDSA applet. Java Card is a technology that has benefited from the
success of the Java language. Its object-oriented model
powerup; allows smart card programmers to develop interoperable
// Applet selection (AID: C9AA4E15B3A2)
applets that can be deployed on smart cards independently of
0x00 0xA4 0x04 0x00 0x06 0xC9 0xAA 0x4E 0x15 0xB3 0xA2 their manufacturer. However, Java Card’s learning curve is
0x7F;
steeper than Java’s, so only a minority of Java programmers
0x00 0xD1 0x00 0x00 0x00 0x7F; are attracted to Java Card.
0x00 0xD2 0x00 0x00 0x0D 0x45 0x43 0x44 0x53 0x41 0x20 Regarding ECC, Java Card 2.2 was the first version that
0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x7F; included classes and functions supporting elliptic curves.
0x00 0xD3 0x01 0x00 0x0D 0x45 0x43 0x44 0x53 0x41 0x20 The latest release, Java Card 3.0, has incremented the
0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x7F; support for ECC, offering a range of key lengths suitable
0x00 0xD3 0x02 0x00 0x37 0x30 0x35 0x02 0x18 0x0b 0x7c for any commercial deployment.
0x83 0x11 0x0c 0xe0 0xb7 0xba 0xc5 0x98 0xc9 0x73 In this contribution, we have provided all the information
0x0a 0x11 0x3b 0x04 0x49 0xeb 0xb6 0x35 0x80 0x20
0x6b 0x2f 0x02 0x19 0x00 0xe5 0x66 0x9c 0x57 0x97 needed by any Java programmer to start developing ECC
0xa2 0xd6 0x1d 0x2f 0x3e 0xdd 0x29 0x29 0x93 0x85 applets, including two working examples that allow users
0x7e 0xd4 0x8b 0xfa 0xec 0xb4 0x7c 0x02 0x70 0x7F;
to perform key exchanges with the ECDH algorithm, and
0x00 0xD4 0x00 0x00 0x00 0x7F; digital signatures with the ECDSA procedure.
powerdown; Given the current trends in information security, we
believe that implementing ECC applications in smart cards
Listing 4. Applet execution script.
will be an attractive option for many companies willing to
Below is included the command and response APDU create new security services.
sequence obtained when executing the previous script:

→ 00A4040006C9AA4E15B3A2
ACKNOWLEDGMENT
← 9000
→ 00D1000000 This work has been partially supported by Ministerio
← 9000 de Ciencia e Innovación (Spain) under the grant TIN2011-
22668.
 R EFERENCES
[1] V. S. Miller, “Use of elliptic curves in cryptography,” Lecture
Notes Comput. Sci., vol. 218, pp. 417–426, 1986.

[2] N. Koblitz, “Elliptic curve cryptosytems,” Math. Comp.,

vol. 48, no. 177, pp. 203–209, 1987.

[3] Digital Signature Standard (DSS), NIST Std. FIPS 186-3,

2009.

[4] V. Gayoso Martı́nez, F. Hernández Álvarez, L. Hernández

Encinas, and C. Sánchez Ávila, “Analysis of ECIES and other
cryptosystems based on elliptic curves,” J. Inform. Assurance
and Security, vol. 6, no. 4, pp. 285–293, 2011.

[5] N. Koblitz, Algebraic Aspects of Cryptography. New York,

NY, USA: Springer-Verlag, 1998.

[6] J. H. Silverman, The Arithmetic of Elliptic Curves. New

York, NY, USA: Springer-Verlag, 2nd ed., 2009.

[7] D. Hankerson, A. J. Menezes, and S. Vanstone, Guide to

Elliptic Curve Cryptography. New York, NY, USA: Springer-
Verlag, 2004.

[8] Identification cards – Integrated circuit cards – Part 3:

Cards with contacts – Electrical interface and transmission
protocols, ISO/IEC Std. 7816-3, 3rd ed., 2006.

[9] Identification cards – Integrated circuit cards – Part 4: Or-

ganization, security and commands for interchange, ISO/IEC
Std. 7816-4, 3rd ed., 2013.

[10] National Security Agency. (2005) NSA Suite B cryptog-

raphy. http://www.nsa.gov/ia/programs/suiteb\ cryptography/
index.shtml.

[11] Secure Hash Standard, NIST Std. FIPS 180-4, 2012.

[12] Oracle Corp. (2011) Java Card SDK. http://www.oracle.com/

technetwork/java/javame/javacard/download/devkit/index.
html.

[13] Recommended elliptic curve domain parameters, SECG Std.

SEC 2 version 1.0, 2000, http://www.secg.org/download/
aid-784/sec2-v2.pdf.

[14] Oracle Corp. (2013) Java Card development quick start guide.
https://netbeans.org/kb/docs/javame/java-card.html.

[15] ——. (2011) Java Card Classic platform specification

3.0.4. http://www.oracle.com/technetwork/java/javacard/
specs-jsp-136430.html.

[16] ——. (2001) Developing a Java Card applet. http://www.

oracle.com/technetwork/java/javacard/applet-136808.html.