See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/301413826

Developing ECC applications in Java Card

Conference Paper · December 2013

DOI: 10.1109/ISIAS.2013.6947743

CITATION READS
1 1,360

2 authors, including:

Víctor Gayoso Martínez

Spanish National Research Council
55 PUBLICATIONS   315 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Securing Internet of things View project

Modelization of Malware View project

All content following this page was uploaded by Luis Hernandez Encinas on 04 July 2016.

The user has requested enhancement of the downloaded file.

 Developing ECC applications 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 provide a complete code example that shows how to develop
of public-key cryptography based on the arithmetic of el- ECC applications in Java Card. In order to facilitate the
liptic curves. Given its mathematical characteristics, ECC understanding of the example, we have included the script
is currently one of the best options for protecting sensitive
information. The lastest version of the Java Card platform needed to execute it and the console output obtained when
includes several classes related to elliptic curves. However, running the applet in a simulator.
potential developers are discouraged by the peculiarities of The rest of this paper is organized as follows: Section II
its programming model and the scarce information available. presents a brief mathematical introduction to elliptic curves.
In this work, we present an up to date and extensive review of In Section III, we review some important concepts about
the ECC support in Java Card. In addition to that, we offer to
the reader the complete code of an application that will allow smart cards. Section IV describes the most relevant charac-
programmers to understand and test the entire application teristics of Java Card, including the new features presented
development process in Java Card. by each version. Section V details the ECC functionality
Keywords-elliptic curves; information security; Java Card; included in the different Java Card releases. In Section VI,
public key cryptography; smart cards we offer a complete code example which demonstrates how
to generate a key pair and create a shared secret using a key
I. I NTRODUCTION agreement procedure. Finally, Section VII summarizes our
As it is well known, in 1985 Miller [1] and Koblitz conclusions about this topic.
[2] independently proposed a cryptosystem based on the
II. E LLIPTIC C URVE C RYPTOGRAPHY
ECDLP (Elliptic Curve Discrete Logarithm Problem). This
field of cryptography is usually known as ECC (Elliptic An elliptic curve E over the field F is a regular projective
Curve Cryptography). In comparison with other public- curve of genus 1 with at least one rational point ([5] and
key cryptosystems, ECC uses significantly shorter keys to [6]). Every elliptic curve admits a canonical equation called
achieve the same level of security [3]. This makes ECC the the general Weierstrass form. That equation in homogeneous
perfect choice for devices with limited resources [4]. coordinates is
In 1996, the smart card sector witnessed the appearance of
Y 2 Z +a1 XY Z +a3 Y Z 2 = X 3 +a2 X 2 Z +a4 XZ 2 +a6 Z 3 ,
a new technology named Java Card. Java Card is the smallest
of the Java platforms, and it allows to develop and install with a1 , a2 , a3 , a4 , a6 ∈ F and ∆ 6= 0, where ∆ is the
a specific type of Java-based application (called applet) in discriminant of E.
smart cards compliant with the Java Card specifications. The homogeneous Weierstrass equation defines a projec-
This card technology is widely used in several sectors, for tive plane curve which has a special point, the point at
example in the cell phone and banking industries. In those infinity, which is denoted as O = [0 : 1 : 0]. In principle that
sectors, security is essential, so the integration of crypto- curve does not have to be elliptic, as it could have singular
graphic capabilities is a typical application requirement. points. Due to that fact, the condition ∆ 6= 0 assures that the
Although Java Card is derived from the Java language, curve is regular, which is equivalent to stating that there are
its programming model has several important particularities, no curve points where the first derivatives of the function
so most Java programmers are not able to develop applets are cancelled [7].
unless they are provided the proper training. Unfortunately, In practice, instead of the general Weierstrass equation,
the number of learning resources about this technology two short Weierstrass forms depending on the characteristic
is limited, which makes the development of Java Card of the finite field Fq are typically used:
applications a complex and resource-consuming operation • If the finite field is a prime field, i.e. F = Fp , where
for most software companies. p > 3 is a prime number, the equation defining the
This contribution analyses the ECC capabilities in every (non-supersingular) elliptic curve becomes
Java Card version released so far, including all the classes
and ECC functions implemented. In addition to that, we y 2 = x3 + ax + b.
 • If the finite field is a binary field, i.e. F = F2m , where Shortly after submitting the first draft of the Java Card API,
m is an integer number, then the equation of the (non- Gemplus and Bull joined Schlumberger in order to constitute
supersingular) elliptic curve is the Java Card Forum, a consortium created to evolve this
technology.
y 2 + xy = x3 + ax2 + b. After the presentation of Java Card 1.0, Sun Microsystems
III. S MART CARDS began to actively cooperate with those smart card manu-
facturers. The result was the announcement in November
A smart card is a plastic card with an embedded chip that
1997 of Java Card 2.0. This new version represented a
controls the access to the stored data. The most widespread
major milestone in Java Card, as it provided a mechanism
communication model for smart cards is composed by the
for object-oriented programming and improved the level
byte oriented protocol T=0 and the APDU (Application
of detail in the specification of the application runtime
Protocol Data Unit) elements.
environment.
APDUs, built according to the ISO/IEC 7816-3 [8] and
Due to the need to adapt the capabilities of the Java
7816-4 [9] specifications, are the data packets exchanged
language to the physical limitations of smart cards, since its
between the external application and the card by means of a
inception it became clear that it was impossible to implement
smart card reader. The card operating system is responsible
some of the Java features. For example, the char, double,
for analysing any incoming APDU and redirect it to the
float, and long types were not supported, multithreading
application it is intended for. The operating system is also
was not allowed, and the dimension of data arrays was
responsible for retrieving the response data from the card
limited to one.
application and submit it to the external application using
Java Card 2.1 was released in March 1999 and consisted
the card reader.
of three specifications:
There are two types of APDUs: command and response.
• Java Card API: defines the Java packages available for
Command APDUs consist of a header and optionally a body
with the following elements: programmers.
• JCVM (Java Card Virtual Machine): specifies the subset
• CLA (1 byte): command class.
of the Java language that can be used and the virtual
• INS (1 byte): specific instruction within the class.
machine needed for the execution of applets.
• P1 (1 byte): first parameter associated to the instruction.
• JCRE (Java Card Runtime Environment): describes the
It can be used to give more information about the
applet runtime behaviour.
instruction, or as input data.
Java Card 2.2 was released in September 2002, and
• P2 (1 byte): second parameter associated to the instruc-
included the following novelties:
tion. As in the previous case, it can be used to give more
information about the instruction, or as input data. • JCRMI (Java Card Remote Method Invocation) imple-

• Lc (1 byte, optional): number of bytes in the data field mentation.

of the command. Since its highest value is 0xFF, the • Support of up to 4 logical channels.

maximum data length is 255 bytes, although some cards • Improvement of the memory resource management.

allow to send 256 bytes using the value 0x00. • New classes for cryptographic algorithms.

• Data (variable size, optional): information to be pro- In March 2006, Sun announced the availability of Java
cessed by the applet. Card 2.2.2, which provided the following improvements:
• Le (1 byte, optional): maximum number of bytes to be • Support of up to 20 logical channels.
included in the data field of the response APDU. • Implementation of new cryptographic algorithms.

In comparison, the format of any response APDU is • New classes for biometric recognition technology.

simpler, as it only includes the following items: Finally, in March 2008 the Java Card 3.0 specification was
• Data (variable length, optional): information returned released. With the aim to adapt the Java Card technology
by the card application. to the needs of internet services, for the first time the
• SW1 (1 byte): first status byte, which provides general specification was divided into two different editions:
information about the result of the command execution. • Connected Edition: introduces an enhanced runtime
• SW2 (1 byte): second status byte. environment and a new virtual machine that provides
network-oriented features such as the support for web
IV. JAVA C ARD applications using servlets.
The first Java Card specification was presented in Novem- • Classic Edition: represents an evolution of Java Card
ber 1996 by engineers working for the French company 2.2.2, including not only the correction of errors, but
Schlumberger. Their goal was to create a technology that also several new features like the possibility to use some
could combine the ease of development provided by the Java of the algorithms described in the NSA (National Secu-
language and the security features associated to smart cards. rity Agency) Suite B document [10]. In the remaining
 sections of this contribution, whenever we mention Java in which applications written for the Java Card platform can
Card 3.0 we will implicitly refer to the Classic Edition. be developed and tested [12]. The JCDK includes a suite of
tools along with a reference implementation written in C.
V. ECC IN JAVA C ARD 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
• KeyAgreement class extension to include the key
set of key lengths specified in the Java Card API, the ones
agreement functions ECDH (Elliptic Curve Diffie Hell- available in the reference implementation are 112, 128, 160,
man) and ECDHC (Elliptic Curve Diffie Hellman with and 192 bits. For each of those key lengths, the development
Cofactor), with the peculiarity that the output of these kit implements one curve. The elliptic curves available in
functions is not the product u · V of the first user’s JCDK 3.0.2 are the following curves specified in the SECG
private key u and the second user’s public key V (and SEC 2 standard [13]: secp112r1, secp128r1, secp160k1, and
additionally the cofactor in the ECDHC case), but the secp192k1.
result of feeding the first coordinate of the point u · V Although the applet development and execution simula-
to the SHA-1 function [11]. tion steps can be performed using the command-line tools
• KeyBuilder class extension, which defines the per-
provided by the JCDK, Tim Boudreau has developed a
mitted key lengths for ECC and other cryptosystems. connector for the NetBeans IDE (Integrated Development
In the case of elliptic curves over prime fields, the valid Environment). Interested readers can obtain the instructions
lengths in Java Card 2.2 were 112, 128, 160, and 192 for its installation at [14]. The minimum version require-
bits, while in the case of curves defined over binary ments for installing this plugin are the following ones:
fields it was possible to use key lengths of 113, 131, • NetBeans: 6.8.

163, and 193 bits . • Java Development Kit: 6.

• Signature class extended with the implementation • Java Card Development Kit: 3.02.

of ECDSA (Elliptic Curve Digital Signature Scheme) • Java Card plugin for NetBeans: 1.3.

using the hash function SHA-1 [3]. Listing 1 contains the code that we have developed in
Java Card versions 2.2.1 and 2.2.2 did not incorporate order to demonstrate how to generate two pairs of 128-bit
new ECC features. However, Java Card 3.0 included the keys corresponding to users U and V, retrieve the most
following novelties: relevant information from them, and generate a shared
secret using the key agreement function ECDH.
• In elliptic curves over prime fields, key lengths of 224,
256, and 384 bits were available for the first time.
1 import javacard.framework.*;
• The implementation of the functions ECDH and
2 import javacard.security.*;
ECDHC was extended in order to accept new variants 3
4 public class JCDiffieHellman extends Applet
in which the output of the function is directly the first 5 {
coordinate of the product u · V (optionally with the 6 byte[] baTemp = new byte[255];
7 byte[] baPrivKeyU, baPrivKeyV, baPubKeyU, baPubKeyV;
cofactor), eliminating the use of the SHA-1 function in 8 short len;
the final step of the procedure. 9
10 KeyPair kpU, kpV;
• The implementation of ECDSA permitted to use that
11 ECPrivateKey privKeyU, privKeyV;
digital signature scheme in combination with the SHA- 12 ECPublicKey pubKeyU, pubKeyV;
13
224, SHA -256, SHA-384, and SHA-512 functions. 14 KeyPair kp;
Finally, the revision version 3.0.4 added the possibility to 15 ECPublicKey pubKey;
16 ECPrivateKey privKey;
use 521-bit keys in curves defined over prime fields. 17
18 KeyAgreement ecdhU, ecdhV;
19
VI. C ODE EXAMPLE 20 public static void install(byte[] bArray,
21 short bOffset, byte bLength)
The JCDK (Java Card Development Kit) is a software 22 {
package that includes a complete development environment 23 new JCDiffieHellman();
 24 } 104 case 0x01: // Parameter A
25 105 if(buffer[2]==(byte)0x01)
26 protected JCDiffieHellman() 106 len = pubKeyU.getA(baTemp,(short) 0);
27 { 107 else
28 register(); 108 len = pubKeyV.getA(baTemp,(short) 0);
29 } 109 apdu.setOutgoing();
30 110 apdu.setOutgoingLength((short) len);
31 public void process(APDU apdu) 111 apdu.sendBytesLong(baTemp,(short) 0, len);
32 { 112 break;
33 byte[] buffer = apdu.getBuffer(); 113
34 114 case 0x02: // Parameter B
35 if (selectingApplet()) 115 if(buffer[2]==(byte)0x01)
36 return; 116 len = pubKeyU.getB(baTemp,(short) 0);
37 117 else
38 if(buffer[ISO7816.OFFSET_CLA] != (byte)0x00) 118 len = pubKeyV.getB(baTemp,(short) 0);
39 ISOException.throwIt((short) 0x6660); 119 apdu.setOutgoing();
40 120 apdu.setOutgoingLength((short) len);
41 switch (buffer[ISO7816.OFFSET_INS]) 121 apdu.sendBytesLong(baTemp,(short) 0, len);
42 { 122 break;
43 case (byte)0xD1: 123
44 processINSD1(apdu); 124 case 0x03: // Parameter P
45 return; 125 if(buffer[2]==(byte)0x01)
46 case (byte)0xD2: 126 len = pubKeyU.getField(baTemp, (short) 0);
47 processINSD2(apdu); 127 else
48 return; 128 len = pubKeyV.getField(baTemp, (short) 0);
49 case (byte)0xD3: 129 apdu.setOutgoing();
50 processINSD3(apdu); 130 apdu.setOutgoingLength((short) len);
51 return; 131 apdu.sendBytesLong(baTemp,(short) 0,len);
52 default: 132 break;
53 ISOException.throwIt((short) 0x6661); 133
54 } 134 case 0x04: // Public key
55 } 135 if(buffer[2]==(byte)0x01)
56 136 len = pubKeyU.getW(baTemp,(short) 0);
57 ///////////////////////////////////////////////// 137 else
58 // INS D1 - KEY PAIR GENERATION // 138 len = pubKeyV.getW(baTemp,(short) 0);
59 // Generates a key pair for both users U and V // 139 apdu.setOutgoing();
60 // APDU EXAMPLE: 00D1000000 // 140 apdu.setOutgoingLength((short) len);
61 ///////////////////////////////////////////////// 141 apdu.sendBytesLong(baTemp,(short) 0,len);
62 142 break;
63 private void processINSD1(APDU apdu) 143
64 { 144 case 0x05: // Private key
65 try 145 if(buffer[2]==(byte)0x01)
66 { 146 len = privKeyU.getS(baTemp,(short) 0);
67 kpU = new KeyPair(KeyPair.ALG_EC_FP, 147 else
68 KeyBuilder.LENGTH_EC_FP_128); 148 len = privKeyV.getS(baTemp,(short) 0);
69 kpU.genKeyPair(); 149 apdu.setOutgoing();
70 privKeyU = (ECPrivateKey) kpU.getPrivate(); 150 apdu.setOutgoingLength((short) len);
71 pubKeyU = (ECPublicKey) kpU.getPublic(); 151 apdu.sendBytesLong(baTemp,(short) 0,len);
72 152 break;
73 kpV = new KeyPair(KeyPair.ALG_EC_FP, 153
74 KeyBuilder.LENGTH_EC_FP_128); 154 default:
75 kpV.genKeyPair(); 155 throw new IndexOutOfBoundsException();
76 privKeyV = (ECPrivateKey) kpV.getPrivate(); 156 }
77 pubKeyV = (ECPublicKey) kpV.getPublic(); 157 }
78 } 158 catch(Exception exception)
79 catch(Exception exception) 159 {
80 { 160 ISOException.throwIt((short) 0xFFD2);
81 ISOException.throwIt((short) 0xFFD1); 161 }
82 } 162 }
83 } 163
84 164 ///////////////////////////////////////
85 /////////////////////////////////////// 165 // INS D3 - SHARED SECRET GENERATION //
86 // INS D2 - PARAMETER DATA RETRIEVAL // 166 // P1: user //
87 // P1: user // 167 // Values P1: 01: user U, 02: user V //
88 // Values P1: 01: user U, 02: user V // 168 // APDU EXAMPLE: 00D3010000 //
89 // P2: parameter to retrieve // 169 ///////////////////////////////////////
90 // Valores P2: 01: A, 02: B, 03: P, // 170
91 // 04: public key, // 171 private void processINSD3(APDU apdu)
92 // 05: private key // 172 {
93 // APDU EXAMPLE: 00D2020300 // 173 byte buffer[] = apdu.getBuffer();
94 /////////////////////////////////////// 174
95 175 try
96 private void processINSD2(APDU apdu) 176 {
97 { 177 switch(buffer[2])
98 byte buffer[] = apdu.getBuffer(); 178 {
99 179 case 0x01: // Process from U’s standpoint
100 try 180 len = privKeyU.getS(baTemp,(short) 0);
101 { 181 baPrivKeyU = new byte[len];
102 switch(buffer[3]) 182 Util.arrayCopyNonAtomic(baTemp, (short)0,
103 { 183 baPrivKeyU, (short)0, len);
184 0x00 0xD2 0x02 0x03 0x00 0x7F;
185 len = pubKeyV.getW(baTemp,(short) 0); 0x00 0xD2 0x02 0x04 0x00 0x7F;
186 baPubKeyV = new byte[len]; 0x00 0xD2 0x02 0x05 0x00 0x7F;
187 Util.arrayCopyNonAtomic(baTemp,(short)0,
188 baPubKeyV, (short)0, len); 0x00 0xD3 0x01 0x00 0x00 0x7F;
189 0x00 0xD3 0x02 0x00 0x00 0x7F;
190 ecdhU = KeyAgreement.getInstance(KeyAgreement.
191 ALG_EC_SVDP_DH, false); powerdown;
192 ecdhU.init(privKeyU);
193 len = ecdhU.generateSecret(baPubKeyV, Listing 2. Applet execution script.
194 (short)0, len, baTemp, (short)0);
195 The result of running the script is the following sequence
196 apdu.setOutgoing();
197 apdu.setOutgoingLength((short) len); of command and response APDUs:
198 apdu.sendBytesLong(baTemp,(short) 0, len);
199 break; → 00A4040006C9AA4E15B3F6
200 ← 9000
201 case 0x02: // Process from V’s standpoint → 00D1000000
202 len = privKeyV.getS(baTemp,(short) 0);
203 baPrivKeyV = new byte[len];
← 9000
204 Util.arrayCopyNonAtomic(baTemp,(short)0, → 00D2010100
205 baPrivKeyV, (short)0, len); ← FFFFFFFDFFFFFFFFFFFFFFFFFFFFFFFC9000
206 → 00D2010200
207 len = pubKeyU.getW(baTemp,(short) 0); ← E87579C11079F43DD824993C2CEE5ED39000
208 baPubKeyU = new byte[len]; → 00D2010300
209 Util.arrayCopyNonAtomic(baTemp,(short)0, ← FFFFFFFDFFFFFFFFFFFFFFFFFFFFFFFF9000
210 baPubKeyU, (short)0, len); → 00D2010400
211
212 ecdhV = KeyAgreement.getInstance(KeyAgreement.
← 0479D69944F614C7AC9C6B5DF66C391AE2F77F
213 ALG_EC_SVDP_DH,false); 04CBF17257CE92F5D791B9B7533C9000
214 ecdhV.init(privKeyV); → 00D2010500
215 len = ecdhV.generateSecret(baPubKeyU, ← 595DA05E618DA5A664EF6A931272F5039000
216 (short)0, len, baTemp, (short)0); → 00D2020100
217 ← FFFFFFFDFFFFFFFFFFFFFFFFFFFFFFFC9000
218 apdu.setOutgoing(); → 00D2020200
219 apdu.setOutgoingLength((short) len); ← E87579C11079F43DD824993C2CEE5ED39000
220 apdu.sendBytesLong(baTemp,(short) 0, len);
221 break;
→ 00D2020300
222
← FFFFFFFDFFFFFFFFFFFFFFFFFFFFFFFF9000
223 default: → 00D2020400
224 throw new IndexOutOfBoundsException(); ← 04620044FA3892038A9C3ADB194916E31F0112
225 } 9E2429B92B75037979D17C1D6CD79000
226 } → 00D2020500
227 catch(Exception exception) ← 835DC74BEB36D19C28E6474A4D400E0E9000
228 { → 00D3010000
229 ISOException.throwIt((short) 0xFFD2);
230 }
← 248B7E259095F53613641F1DD27DB61768D946
231 } D79000
232 } → 00D3020000
← 248B7E259095F53613641F1DD27DB61768D946
Listing 1. Java Card code example. D79000

As it can be observed, U’s private key is 0x595DA05E

In order to simulate the applet execution, it is necessary 618DA5A664EF6A931272F503, while the serialization
to use a script with the command APDUs to be sent to of his public key is 0x0479D69944F614C7AC9C6B5DF
the smart card. Listing 2 shows the content of our script file. 66C391AE2F77F04CBF17257CE92F5D791B9B7533
C. Besides, V’s private and public key are 0x835DC74BE
//Test script B36D19C28E6474A4D400E0E and 0x04620044FA38
powerup;
92038A9C3ADB194916E31F01129E2429B92B7503
7979D17C1D6CD7, respectively. Finally, the value of the
// Applet selection (instance ID: C9AA4E15B3F6)
0x00 0xA4 0x04 0x00 0x06 0xC9 0xAA 0x4E 0x15 0xB3 0xF6
shared secret is 0x248B7E259095F53613641F1DD27
0x7F; DB61768D946D7.
//Command APDUs VII. C ONCLUSION
0x00 0xD1 0x00 0x00 0x00 0x7F; Java Card is a technology that has benefited from the
0x00 0xD2 0x01 0x01 0x00 0x7F;
success of the Java language. Its object-oriented model
0x00 0xD2 0x01 0x02 0x00 0x7F; allows smart card programmers to develop interoperable
0x00 0xD2 0x01 0x03 0x00 0x7F;
0x00 0xD2 0x01 0x04 0x00 0x7F;
applets that can be deployed on smart cards independently of
0x00 0xD2 0x01 0x05 0x00 0x7F; their manufacturer. However, Java Card’s learning curve is
0x00 0xD2 0x02 0x01 0x00 0x7F;
steeper than Java’s, so only a minority of Java programmers
0x00 0xD2 0x02 0x02 0x00 0x7F; are attracted to Java Card.
 Regarding ECC, Java Card 2.2 was the first version that [12] Oracle Corp., Java Card SDK, 2013, http://www.oracle.com/
included classes and functions supporting elliptic curves. technetwork/java/javame/javacard/download/devkit/index.
The latest release, Java Card 3.0, has incremented the html.
support for ECC, offering a range of key lengths suitable [13] Standards for Efficient Cryptography Group, Recommended
for any commercial deployment. elliptic curve domain parameters, SECG SEC 2 version 1.0,
In this contribution, we have provided all the information 2000, http://www.secg.org/download/aid-784/sec2-v2.pdf.
needed by any Java programmer to start developing ECC
applets. Given the current trends in information security, we [14] Oracle Corp., Java Card Development Quick Start Guide,
2013, https://netbeans.org/kb/docs/javame/java-card.html.
believe that implementing ECC applications in smart cards
will be an attractive option for many companies willing to
create new secure services.

ACKNOWLEDGMENT
This work has been partially supported by Ministerio
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] National Institute of Standards and Technology, Digital Sig-

nature Standard (DSS), NIST, Federal Information Processing
Standard Publication, 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] Institute of Electrical and Electronics Engineers, Identification

cards – Integrated circuit cards – Part 3: Cards with contacts
– Electrical interface and transmission protocols, ISO/IEC
7816-3, 3rd ed., 2006.

[9] ——, Identification cards – Integrated circuit cards – Part

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

[10] National Security Agency, NSA Suite B cryptography, NSA,

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

[11] National Institute of Standards and Technology, Secure

Hash Standard, NIST, Federal Information Processing
Standard Publication, FIPS 180-4, 2012. [Online]. Available:
http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf

View publication stats