Implementation of ECC/ECDSA Cryptography Algorithms Based on Java Card Jin-Hee Han*, Young-Jin Kim**, Sung-Ik Jun*, Kyo-Il Chung***, Chang-Ho Seo**** IC Card OS Research Team, ETRI*, Biometrics Technology Research Team, ETRI**, Information Security Basic Department, ETRI*** Department of Mathematics, Kongju National Univ.**** E-mail: (hanjh, sijun)@etri.re.kr*,
[email protected]**,
[email protected]***,
[email protected]**** Abstract This paper describes implementations and test results of Elliptic Curve Cryptography (ECC) and Elliptic Curve Digital Signature Algorithm (ECDSA) algorithms based on Java card. 163-Bit ECC guarantees as secure as 1024Bit Rivest-Shamir-Adleman (RSA) public key algorithm, which has been frequently used until now. According to our test results, 163- bit ECC processing time is about five times fast compared with 1024-bit RSA and amount of resource usages of ECC is smaller than RSA. Therefore, ECC is more appropriate for use on secure devices such as smart cards and wireless devices with constrained computational power consumption and memory resources.
piece of software that can execute programs (applets) written in the Java language. These Java card applets are written in a similar way to the “normal” Java applets, but due to the limited memory and computing power of the smart card, only a small subset of the language features are supported. Figure 1 shows the Java card architecture. hGX
hGY
p
hGZ
…7
hGu
j GhwpSG }vwGhwpSG
jGm
qGjGhwpVm }Gt
uGt
qjyl
vGz o
1. Introduction 1.1. Java card overview Starting in 1996, Schlumberger, a smart card manufacturer, demonstrated a Java-based smart card by adding a light-weight Java bytecode interpreter to a smart card’s OS (Operating System) and downloading Java class files, which were converted to a smaller, proprietary format. The original OS functionality was used to download, manage, and execute the application code and its data. In October 1996, Sun Microsystems issued a first Java card specification. The specification limited its description to the Java card’s general goals and architecture: it should provide support for a Java-language subset and offer APIs (Application Programming Interface) for smart cardspecific functions like cryptographic operations [1][5]. Afterwards, Sun issued Java Card 2.0 specification, which is more essential and concrete, in 1997, and Java Card 2.1 specification in 1999. In addition, Java Card 2.2 specification will be issued very soon. If you want to write a Java application that should run on a smart card, you can use a smart card that is compliant to the Java card API specification. A Java card, as all common smart cards, has a Central Processing Unit (CPU), Read Only Memory (ROM) and Electrically Erasable and Programmable ROM (EEPROM). The card operating system consists of a Java Card Virtual Machine (JCVM), a
Figure 1. Java card architecture For the communication between smart cards and the outside world, the client–server model is used. The messages are transferred by Application Protocol Data Units (APDU), which is the communication protocol, specified in ISO 7816. The card always waits for a command APDU from a terminal, executes the requested command, and replies with an adequate response APDU. The header is always present in the command APDU. If there are no errors, a response APDU should always be returned, even if they contain no data (status words are always present). Command and response APDU’s are built as shown in Table 1. Java card applications are called applets. Applets are identified and selected by an Application IDentifier (AID), and multiple applets can reside on one card. Because applet objects exist for the life of the card, once installed an applet lives on the card forever [4][5]. Table 1. Command and response APDU Command APDU Header Lc Data Le CLA INS P1 P2 CLA: Class byte (command-ID), INS: Instruction, P1, P2: Parameter, Lc: Length of command data, Data: Command data, Le: Length of expected data
(a) Command APDU
Data
SW1
Data: Response data, SW1, SW2: Status Word
(b) Response APDU
Proceedings of the 22 nd International Conference on Distributed Computing Systems Workshops (ICDCSW’02) 0-7695-1588-6/02 $17.00 © 2002 IEEE
SW2
1.2. ECC With the need for information security in today’s digital systems both acute and growing, cryptography has become one of their critical components. Cryptographic services are required across a variety of platforms in a wide range of applications such as secure access to private networks, electronic commerce, and health care. In 1985, Neil Koblitz and Victor Miller independently proposed the ECC, whose security depends on the difficulty of mathematical problem for their security, actually the discrete logarithm problem, over the points on an elliptic curve. ECC can be used to provide both a digital signature scheme and an encryption scheme. Advantages of ECC are storage efficiencies, bandwidth savings, and computational efficiencies. Therefore, an implementation of ECC is particularly beneficial in applications where bandwidths, processing capacity, power availability, or storage are constrained. Also, ECC provide the highest strength per bit among cryptosystems known today [2][3].
2. ECC and ECDSA Implementation
Next Generation IC (Integrated Circuit) Card (NGICC) was used to implement ECC and ECDSA. NGICC, which ETRI is developing, follows Java card 2.1.1 specification and uses a 32-bit ARM7TDMI microprocessor. Besides, NGICC supports various cryptographic algorithms. Figure 2 describes cryptographic algorithms, which are implemented in NGICC. oGmGpU
p TGhwp
wGr G hGpU
tk\
kzh
zohTX
ypwltkTX]W kGzG hGpU
ljkzh
{Tklz ljj
yzh
zllk
zGr G hGpU
qGjG}Gt jGvGz
qGj o
yzhG j
2.2. ECC for Java card 2.2.1. ECC API. Since ECC API was not specified in Java card 2.1 specification, we designed ECC API. ECC API consists of private ⋅ public key generation part, ECC encryption, decryption part, and initialization part [6]. Classes and interfaces related with ECC algorithm on Java Card API are following as: javacard.security.Key javacard.security.PublicKey javacard.security.PrivateKey javacard.security.KeyBuilder javacard.security.ECCPrivateKey javacard.security.ECCPublicKey
The following is newly additional classes based on Java Card API. javacardx.crypto.Cipher javacardx.crypto.ECC javacardx.crypto.ECCPrivateKey_IM javacardx.crypto.ECCPublicKey_IM
Figure 3 shows ECC and ECDSA interface and input /output parameter value among API, VM, OS, and H/W.
2.1. NGICC environment
q j hwp
implemented as coprocessor cryptographic module [8], the applet provider can use this RSA and ECC API’s to utilize cryptographic coprocessor, which connect with VM, Chip OS (COS), and H/W. API-JCVM-COS-H/W interface helps on applet to access card’s cryptographic functions.
{Gklz
ljj j
j Gj
Figure 2. Cryptographic algorithms of NGICC As shown in Figure 2, Message Digest Algorithm (MD5), RIPEMD-160, Secure Hash Algorithm (SHA-1) are implemented as hashing functions, Digital Signature Algorithm (DSA), ECDSA as signature algorithm, and Triple-Data Encryption Standard (TDES), SEED as secret key algorithms. SEED can be used for providing confidentiality at electronic commerce, and it is proposed for standardization in KOREA. On the contrary, RSA, ECC implemented as public key algorithms. Actually, core function of RSA and ECC is
2.2.2. ECC encryption/decryption. In case of ECC encryption, card brings a public key (Q=kBP) of the counterpart and computes kAkBP using random variable kA. Then, ECC crypto module is in charge of scalar multi-application. Since P is a base point on the elliptic curve and it is represented as a (x, y) coordinate, input message (M) should be converted to (x, y) coordinate on the elliptic curve (PM). And then, ECC crypto-module computes (PM + kA(kBP)), return the result value to COS. After the encryption process is over, COS passes the cryptogram (kAP, PM + kA(kBP)) to JCVM. On the contrary, in case of decryption, the input message is (kBP, PM + kB(dP)). At first, COS extracts kBP from the input message and ECC crypto-module computes dkBP by using private key d. And then COS subtracts dkBP from the input message and computes the original input message (M) from PM. After the decryption process is finished, COS passes the input message M to JCVM. Functions about key generation, encryption and decryption of ECC API are shown below. public void init(Key key, byte opmode) throws CryptoException{ this.state = opmode; if (state == Cipher.MODE_ENCRYPT){ ((ECCPublicKey_IM)key).getECCcurve(E, (short)0); ((ECCPublicKey_IM)key).getQpoint(Q, (short)0); ((ECCPublicKey_IM)key).getBasepoint(P, (short)0); ((ECCPublicKey_IM)key).getOrder(n, (short)0); ((ECCPublicKey_IM)key).getPolyprime(pp, (short)0); ((ECCPublicKey_IM)key).getRandom(k, (short)0); } else if(state == Cipher.MODE_DECRYPT){ ((ECCPrivateKey_IM)key).getSKey(d, (short)0); } }
Proceedings of the 22 nd International Conference on Distributed Computing Systems Workshops (ICDCSW’02) 0-7695-1588-6/02 $17.00 © 2002 IEEE
wSGlSGxSGSGSGSGt GSGj
hwp
. %
jGljjG O PG wSGlSGxSGSGSGSGtGOSGjPGG
qj}t
cljje
721 0
0
h
j GOwPG zGO}PG
. %
/ %
721 . %
jGljkzhGOPG wSGlSGxSGSGSGSGtGOSGjPGG
721 721 . # / % %
j GOwPG zGO}PG
cljkzhe
% #1% -23 4 -2 - # -21% j GOwPG zGO}PG
jvz
% 45/6 ( *3 721 # ( * - " 4 5/6 3 4 8 ,$
251! # 4
yGG
oV~
! ! " # $% #
! # &' #
! # &( # ) *+ ! ! " # $% #,
-
Figure 3. ECC and ECDSA interface public short doFinal(byte[] inBuff, short inOffset, short inLength, byte[] outBuff, short outOffset) throws CryptoException{ short i=0; if(state == Cipher.MODE_ENCRYPT) { NativeMethods.timerstart(); i = NativeMethods.ECCENC(inBuff, inOffset, inLength, outBuff, outOffset, E, P, Q, n, pp, k); NativeMethods.timerend(); return i;} else if(state == Cipher.MODE_DECRYPT){ NativeMethods.timerstart(); i = NativeMethods.ECCDEC(inBuff, inOffset, inLength, outBuff, outOffset, d); NativeMethods.timerend(); return i;} return i; }
Card itself or host computer can generate private or public key for ECC algorithm by using Random Number Generator (RNG) In addition, card or ECC crypto coprocessor defines fixed values, such as elliptic curve (E), base point (P), order (n), and polynomial prime value (pp). In our simulation, we used E, P, n, and pp values which coprocessor defines. And the remainder keys such as public key of the counterpart (Q), random variable (k) and private key of the card (d) are generated and sent to the card by host computer. Besides, we designed native interface for ECC, ECDSA algorithms and time measurement. Since ECC and ECDSA algorithms are implemented in COS, H/W crypto module, applet developer cannot access ECC, ECSDA algorithms through Java API without ECC and ECDSA native interfaces. Native methods are useful in three cases: 1. For accessing features of an underlying host platform that are not accessible through the Java API. 2. For accessing a legacy system or using an already existing library that is not written in Java. 3. For speeding up the performance of a program by implementing time-critical code as native methods.
2.3. ECDSA for Java card
2.3.1. ECDSA API. We designed an ECDSA API as the same form of DSA API. The ECDSA API consists of private ⋅ public key generation part, signature, verification part, and initialization part [6]. Classes and interfaces related on ECC algorithm on Java Card API are following as: javacard.security.Signature javacard.security.Key javacard.security.PublicKey javacard.security.PrivateKey javacard.security.KeyBuilder javacard.security.ECDSAPrivateKey javacard.security.ECDSAPublicKey
The following is newly additional classes based on Java Card API. javacardx.crypto.ECDSA javacardx.crypto.ECDSAPrivateKey_IM javacardx.crypto.ECDSAPublicKey_IM
2.3.2. ECDSA signature/verification. Since SHA-1 algorithm has already developed for hash algorithm, we used SHA–1 algorithm for ECDSA. Figure 4 describes SHA-1 API interface and SHA-1 function in COS layer. At the time of ECDSA signature, card computes dP using its private key d, and converts input message into 160-bit hash value by using SHA-1 algorithm. And then signature value r and s are generated by ECC crypto module and COS. After signature process is over, COS returns result value (M||r||s) to JCVM. On the other hand, in ECDSA verification, card extracts r and s value from input message (M||r||s), and computes v using a public key (Q=kBP) of the counterpart. If the value of v is equal to that of r, card sends 0x00 to the host. Value 0x00 means verification is successful. If verification command is failed, card sends 0x01 to the host. Functions about key generation, encryption and decryption of ECDSA API are as follows.
Proceedings of the 22 nd International Conference on Distributed Computing Systems Workshops (ICDCSW’02) 0-7695-1588-6/02 $17.00 © 2002 IEEE
public void init(Key key, byte opmode) throws CryptoException{ this.state = opmode; if (state == Signature.MODE_SIGN){ ((ECDSAPrivateKey_IM)key).getOrder(n, (short)0); ((ECDSAPrivateKey_IM)key).getSKey(d, (short)0); ((ECDSAPrivateKey_IM)key).getBasePoint(P, (short)0); ((ECDSAPrivateKey_IM)key).getRV(k,(short)0);} else if(state == Signature.MODE_VERIFY){ ((ECDSAPublicKey_IM)key).getBasePoint(P,(short)0); ((ECDSAPublicKey_IM)key).getQPoint(Q, (short)0);} } public short sign(byte[] inBuff, short inOffset, short inLength, byte[] sigBuff,short sigOffset) throws CryptoException{ short i=0; length[0] = (byte)inLength; NativeMethods.timerstart(); i = NativeMethods.ECDSASIGN(inBuff, inOffset, inLength, sigBuff, sigOffset, P, d, k, n, length); NativeMethods.timerend(); return i;} public boolean verify(byte[] inBuff, short inOffset, short inLength, byte[] sigBuff, short sigOffset, short sigLength) throws CryptoException{ boolean i; length[0] = (byte)inLength; NativeMethods.timerstart(); i = NativeMethods.ECDSAVERIFY(inBuff, inOffset, inLength, sigBuff, sigOffset, P, Q, length); NativeMethods.timerend(); return i;}
3. Experiments Experiment environment is represented in Figure 4. o
zG
hwk| j
unpjj Gj
jhk
wG
F8L
pV
pV
vG
vG
m
jGz
{G
t TG pjl
m
w
w
n
n
h
h
ljj
unpjjGl
XUGjGGG GhwpNGGG GGGGTGUGG YUGjGUGGGGGjvzGGqj}t GGGGTGGG ZUGkGGGGGunpjjGG GGGtTpjlG
Figure 4. Experiment environment Host computer is used to generate mask.c and test files. ECC and ECDSA crypto API’s and test applets have to be complied and converted to adapt to a card environment. So, they are compiled and converted by compiler and converter. The result file, that is mask.c, includes information about ECC and ECDSA crypto API’s and their test applets. And then, mask.c file is re-compiled with files about COS and JCVM. As a result, test file is generated. Finally, test file is downloaded into the NGICC emulator host computer sends command APDU through Card and NGICC board sends response APDU via CAD to the host computer after processing the command APDU. ECC and ECDSA test APDU script and encryption /decryption, signature/verification result values are shown below [7]. ;Select ECC Test Applet [R/W:CARD] 00 A4 04 00 0A A00000006203010C0601 [R/W8CARD] 9000 ;Receive input message [R/W:CARD] C0 10 00 00 04 61766364 [R/W8CARD] 9000
: 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8
;Receive 48 bytes counterpart public key (Q) [R/W CARD] C0 30 01 00 18 0000000461476015A13441AE072F29DC0FA1FCE23C2223A0 [R/W CARD] 9000 [R/W CARD] C0 30 02 00 18 0000000065EAD6D1519DB913E6F719709D51399D9DD636CD [R/W CARD] 9000 ;Receive 24 bytes random variable [R/W CARD] C0 50 00 00 18 0000000091C9DC3A946A9206B48710CB56E1698980CBCA09 [R/W CARD] 9000 ;Receive 24 bytes secret key [R/W CARD] C0 60 00 00 18 000000011B2419EDDCFE099A68CFDA7AF8E9BE219114AEBD [R/W CARD] 9000 ;Public key generation [R/W CARD] C0 80 00 00 00 [R/W CARD] 9000 ;Encryption by ECC [R/W CARD] C0 A0 00 00 00 [R/W CARD] 9000 ;Send encrypted data to the host [R/W CARD] C0 D0 01 00 18 [R/W CARD] 00000000A9EBECEC1330B6CCA653356C93F403F1F2C1C6BC 9000 [R/W CARD] C0 D0 02 00 18 [R/W CARD] 000000004B5F5933E1B6F822984848A5B23C0FB3BC6E3BFD 9000 [R/W CARD] C0 D0 03 00 18 [R/W CARD] 000000029349173E8CF13DF838761CD062A212FD17935071 9000 [R/W CARD] C0 D0 04 00 18 [R/W CARD] 00000005E21D10642326B4A9CBD8E11455F2AF277F74DCD6 9000 ;Private key generation [R/W CARD] C0 70 00 00 00 [R/W CARD] 9000 ;Decryption by ECC [R/W CARD] C0 B0 00 00 00 [R/W CARD] 9000 ;Send decrypted data to the host [R/W CARD] C0 C0 00 00 04 [R/W CARD] 61766364 9000 ;Select ECDSA Test Applet [R/W CARD] 00 A4 04 00 0A A00000006203010C0901 [R/W CARD] 9000 ;Receive input message [R/W CARD] F0 10 00 00 04 61766364 [R/W CARD] 9000 ;Receive 24bytes secret key [R/W CARD] F0 30 00 00 18 000000000000000000000000000000003456123400000004 [R/W CARD] 9000 ;Receive 24bytes random variable [R/W CARD] F0 40 00 00 18 000000000000000000000000000000003456123400000004 [R/W CARD] 9000 ;Receive 24bytes order value [R/W CARD] F0 80 00 00 18 000000000000000000000000000000000000000000000003 [R/W CARD] 9000 ;Receive 48bytes counterpart public key (Q) [R/W CARD] F0 50 01 00 18 00000001A094329691C8A02B06EA02EF3606601E76B1A12C [R/W CARD] 9000 [R/W CARD] F0 50 02 00 18 000000028A2CF3AFE161F9FE10E9DD92A5D38E6557AB35A6 [R/W CARD] 9000 ;Private key generation [R/W CARD] F0 60 00 00 00 [R/W CARD] 9000 ;Data signature by ECDSA [R/W CARD] F0 A0 00 00 00 [R/W CARD] 9000 ;Send signature value to the host [R/W CARD] F0 D0 01 00 1A [R/W CARD] 6176636400000001A094329691C8A02B06EA02EF3606601E76B1 9000 [R/W CARD] F0 D0 02 00 1A [R/W CARD] A12C000000008DB8AE2BC2B888D34013B4FCC948225852BC2C56 9000 ;Public key generation [R/W CARD] F0 70 00 00 00 [R/W CARD] 9000 ;Data verification by ECDSA [R/W CARD] F0 B0 00 00 00 [R/W CARD] 9000 ;Send verified data to the host (0 : success, 1 : fail) [R/W CARD] F0 C0 00 00 04 [R/W CARD] 00000000 9000
4. Results In this experiment, we used 163-bit polynomial basis ECC algorithm. In addition, E, P, n, and pp values that coprocessor defines and Q, k and d received from the host computer for the purpose of testing ECC, and ECDSA. However, NGICC can create new key pairs and random variable in ECC, ECDSA based public key systems by using RNG. For example, test results of ECDSA are as follows:
Proceedings of the 22 nd International Conference on Distributed Computing Systems Workshops (ICDCSW’02) 0-7695-1588-6/02 $17.00 © 2002 IEEE
;//ECDSA Test ;Receive input message [R/W CARD] F0 10 00 00 04 61766364 [R/W CARD] 9000 ;Receive 24bytes secret key [R/W CARD] F0 30 00 00 18 000000000000000000000000000000003456123400000004 [R/W CARD] 9000 ;Generate 24bytes random variable by using RNG [R/W CARD] F0 40 00 00 00 [R/W CARD] 9000 ;Receive 24bytes order value [R/W CARD] F0 80 00 00 18 000000000000000000000000000000000000000000000003 [R/W CARD] 9000 ;Receive 48bytes counterpart public key (Q) [R/W CARD] F0 50 01 00 18 00000001A094329691C8A02B06EA02EF3606601E76B1A12C [R/W CARD] 9000 [R/W CARD] F0 50 02 00 18 000000028A2CF3AFE161F9FE10E9DD92A5D38E6557AB35A6 [R/W CARD] 9000 ;Private key generation [R/W CARD] F0 60 00 00 00 [R/W CARD] 9000 ;Data signature by ECDSA [R/W CARD] F0 A0 00 00 00 [R/W CARD] 9000 ;Send signature value to the host [R/W CARD] F0 D0 01 00 1A [R/W CARD] 6176636400000000A58DCDB389320EE0EB8C32A631081FA53620 9000 [R/W CARD] F0 D0 02 00 1A [R/W CARD] 02B10000000268837165DD886A6DFD8CC49CCF6964293EBB8077 9000 ;Public key generation [R/W CARD] F0 70 00 00 00 [R/W CARD] 9000 ;Data verification by ECDSA [R/W CARD] F0 B0 00 00 00 [R/W CARD] 9000 ;Send verified data to the host (0 : success, 1 : fail) [R/W CARD] F0 C0 00 00 04 [R/W CARD] 00000000 9000 ;***************************************************************************** ;Generate secret key of the card by using RNG [R/W CARD] F0 90 00 00 00 [R/W CARD] 9000 ;Generate public key of the card [R/W CARD] F0 E0 00 00 00 [R/W CARD] 9000 ;Send public key of the card to the host [R/W CARD] F0 F0 01 00 18 [R/W CARD] 0000000479D8E90509C687D5CA93F4F5D864B3DC7B365ACE 9000 [R/W CARD] F0 F0 02 00 18 [R/W CARD] 00000004758A6C15BB7972CD4D82894C32482BE03287DB74 9000
: 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8 : 8
: 8 : 8 : 8 : 8 Table 2 shows processing time of ECC and ECDSA and RSA algorithms implemented on NGICC. NGICC acts 13MHz clock rate in order to test ECC, ECDSA and RSA. Table 2. Processing time
ECC ECDSA
Processing Time (msec, 13MHz) Encryption Decryption (Signature) (Verification) 43.244 46.828 101.297
241.526
ECC crypto module requires less computational overhead than RSA and also number of gates of ECC is much less than RSA. That is, ECC is more efficient and needs less memory. Consequently, ECC is more appropriate for use on secure devices such as Java card with constrained power consumption and memory resources. And also, ECDSA can be used for authorizing certificated systems when the card user purchases the goods using electronic commerce because it takes a shorten signature generation time. The security issue of malicious party who tries to tap or to retrieve private key from card is important item to consider and solve. The private key in a public-key pair must be kept secret. For true non-repudiation, the private key must be completely inaccessible to all other parties. Because of the complexity of the computation required,
generating keys on the card is inefficient and typically impractical. However, with ECC, the time needed to generate a key pair is so short that even a device with the very limited computing power of a smart card can generate the key pair, provided a good RNG is available. In our card, the faster key generation offered by RNG makes the secure on-the-fly key generation practical.
5. Conclusions The security and portability of Java cards provide a safe, reliable, and effective way to ensure e-business and to enable a broad range of new application. However, Java Card represents one of the smallest computing platforms today. In other words, a major factor influencing the design and implementation of Java Card is the limited availability of computing resources. In this paper, we design and implement Java Card crypto API classes about the ECC and ECDSA for NGICC, and simulate them on emulator board. According to our test results, we are confident that ECC and ECDSA algorithms are beneficial to smart card. And smart card, which implements ECC and ECDSA algorithms, will provide users with strengthened security and convenience.
References [1] Michael Caentsch, "Java Card-From Hype to Reality", IEEE Concurrency, pp.36-43, Oct.-Dec., 1999. [2] Menezed, A., van Oorschot, P., Vanstone, S., Handbook of Applied Cryptography, CRC Press, 1997. [3] Tommi Elo, "A Software Implementation of ECDSA on a Java Smart Card", Master's Thesis, Helsinki University of Technology, March 2000. [4] Sun Microsystems, Inc., Java Card Applet Developers Guide, August 30, 1999. [5] Chen, Zhiqun, Java Card Technology for Smart Cards, Addison-wesley, 2000 [6] Sun Microsystems, Inc., Java Card TM 2.1 Application Programming Interface Specification, June 7, 1999. [7] Sun Microsystems, Inc. Java Card TM 2.1.1 Development Kit User's Guide, 2001. [8] YongJe Choi, HoWon KIm, MooSeop Kim, YoungSoo Park, and Kyoil Chung, “Design of Elliptic Curve Cryptographic Coprocessor over Binary Fields for the IC Card”, ITC-CSCC, July 2001, pp. 299 - 302./
Proceedings of the 22 nd International Conference on Distributed Computing Systems Workshops (ICDCSW’02) 0-7695-1588-6/02 $17.00 © 2002 IEEE
