developing and applying to set with java-cardcaislab.kaist.ac.kr/lecture/2001/spring/ice525/... ·...

Security and E-payment System Confidential Term Project Final Report 2001 Spring Semester

1

© “Enigma”: Cho Won Chul, Kim Hee Dae, Lee Jung Hwun, Yoon Won Jung

Security and E-payment System 2001, Spring Semester Term Project Final Report

““DDeevveellooppiinngg aanndd AAppppllyyiinngg ttoo SSEETT wwiitthh JJaavvaa--ccaarrdd””

Team Name: Enigma Members: Cho Won Chul

Kim Hee Dae Lee Jung Hwan Yoon Won Jung

Submit Date: June 14, 2001


2


LLiisstt ooff CCoonntteennttss

1. Introduction Objective????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 5

2. E-payment System

2.1 What is E-payment system ????????????????????????????????????????????????????????????????????????????????????????????????????????????? 6

2.2 Comparison of E-payment system protocols ??????????????????????????????????????????????????????????????????????????? 6

2.2.1 SSL ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 6

2.2.2. SET ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 9

2.2.3 C-SET ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????10

2.2.4. Interoperability : SET/ C-SET, SSL/SET ?????????????????????????????????????????????????????????????????????? 12

2.2.5 Others : algorithm, biometric. ??????????????????????????????????????????????????????????????????????????????????????????? 16

3. SET

3.1 Definition ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 17

3.2 Background of SET ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 17

3.3 History of SET ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 17

3.4 Future of SET ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 18 3.5 Certificates ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 18

3.6 Transactions ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 18

3.7 Encryption Process ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 19 3.8 Three Parts to the SET System ???????????????????????????????????????????????????????????????????????????????????????????????????? 20

3.9 Secure Transmission Schemes in SET Protocol ????????????????????????????????????????????????????????????????????????????? 20

3.10 Essential Security Requirements in SET ???????????????????????????????????????????????????????????????????????????????? 21 3.11 Entities of SET protocol in Cyber shopping ????????????????????????????????????????????????????????????????????????????????? 21

3.12 Overview of main Messages in SET ?????????????????????????????????????????????????????????????????????????????????????????????? 22

4. JAVACARD

4.1 Smart Card Hardware???????????????????????????????????????????????????????????????????????????????????????????????????????????????? 23 4.1.1 Smart Card Contact Points ????????????????????????????????????????????????????????????????????????????????????????????? 23

4.1.2 Smart Card Central Processing Unit ?????????????????????????????????????????????????????????????????????????????? 24


3


4.1.3 Smart Card Coprocessors ???????????????????????????????????????????????????????????????????????????????????????????????? 24

4.2 Smart Card Communication data units) ??????????????????????????????????????????????????????????????????????????????? 24 4.2.1 APDU Protocol ???????????????????????????????????????????????????????????????????????????????????????????????????????????????? 24

4.3 Smart Card Operating Systems ???????????????????????????????????????????????????????????????????????????????????????????????? 25 4.4 Java Card Technology ???????????????????????????????????????????????????????????????????????????????????????????????????????????????? 26

4.4.1 java Card Virtual Machine(JCVM) ?????????????????????????????????????????????????????????????????????????????????? 27

4.4.2 Java card runtime environment(JCRE) ???????????????????????????????????????????????????????????????????????????? 28

4.4.3 Java Card API ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 28

4.4.4 Applet Program Installation ???????????????????????????????????????????????????????????????????????????????????????????? 29 5. Implementation of Java Card

5.1 Scenario ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 30 5.2 Java Card Program ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 30

6. E-payment Application in SET ????????????????????????????????????????????????????????????????????????????????????????????????????????? 37 7. Conclusion and further more ????????????????????????????????????????????????????????????????????????????????????????????????????????????? 38 Appendix (Source code )

1. Server.java ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 40 2. Crytotest.java ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 42 3. Client.java, ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 52

Reference ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 63


4


LLiisstt ooff FFiigguurree

< Figure 2-1> C-SET/SET ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 12

< Figure 2-2> C-SET/SET??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 13

< Figure 2-3> Hybrid SET/SSL model??????????????????????????????????????????????????????????????????????????????????????????????????????????????? 14

< Figure 2-4> Exchanging message in Hybrid SET/SSL model ?????????????????????????????????????????????????????????????????????? 15

< Figure 3-1> Entities of SET protocol in Cyber shopping?????????????????????????????????????????????????????????????????????????????? 21

< Figure 3-2> Overview of main Messages in SET??????????????????????????????????????????????????????????????????????????????????????????? 22

< Figure 4-1> Java Card Contact Point???????????????????????????????????????????????????????????????????????????????????????????????????????????? 24

< Figure 4-2> Send APDU?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 25

< Figure 4-3> Response APDU?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 25

< Figure 4-4> Java Card File System ??????????????????????????????????????????????????????????????????????????????????????????????????????????????? 26

< Figure 4-5> JCVM ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 27

< Figure 4-6> JCRE Structure ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 28

< Figure 4-7> Java Card Program Installation Process ?????????????????????????????????????????????????????????????????????????????????? 29

< Figure 5-1> Dual Signature Process ??????????????????????????????????????????????????????????????????????????????????????????????????????????????? 33

< Figure 5-2> Payment Information Encryption ????????????????????????????????????????????????????????????????????????????????????????????? 34

< Figure 5-3> Verify Dual Signature ???????????????????????????????????????????????????????????????????????????????????????????????????????????????? 35


5


1. Introduction

As we enter the second millennium we experience one of the most important changes in our lives-the move to an

Internet-based society. Almost everything will be changed at home, in school, at work., in the government-even in our

leisure activities. Some changes are already here and they are spreading around the globe. Others are just beginning.

One of the most significant changes is in the manner we conduct business especially in how we manage the

marketplace and commerce.

Electronic commerce describes the manner in which transactions take place over networks, mostly the Internet. It is

the process of electronically buying and selling goods, services, and information.

How about the payment in EC? We have face on many difficult problems to solve this kind of transaction. Now the

importance of E-payment system is one of hot issues in Electronic Commerce. So our team wants to introduce the

overall E-payment system and some implementation using Smart-card.

Our main objective this project is following:

- Describing typical electronic payment systems for EC

- Comparing the relationship between SSL and SET protocols

- Classifying and describing the types of Smart Card used for payments

- Describing the characteristics of Java Card

- Implementing Java Smart Card applying to SET

To achieve these objectives we have studied many related topics especially Java-card encryption. So here we would

like to introduce our compositions. The topic is like following:

- E-payment system and it’s protocol; SSL, SET, C-SET, SET/ C-SET, SSL/SET, etc.

- More SET

- JAVACARD

- Implementation of Java Card

- E-payment Application in SET


6


2. E-payment System 2.1 What is E-payment system ?

E-payment system is the new payment methods with the emergence of electronic commerce on the Internet.

Secure payment systems are critical to the success of EC.

There are four essential security requirements for safe electronic payments. (Authentication, Encryption, Integrity,

Non-repudiation)

The key security schemes adopted for electronic payment systems are encryption.

Security schemes are adopted in protocols like SSL and SET.

2.2 Comparison of E-payment system protocols

2.2.1. SSL

? Concept

Short for Secure Sockets Layer, a protocol developed by Netscape for transmitting private documents via the Internet.

SSL works by using a private key to encrypt data that is transferred over the SSL connection. Both Netscape Navigator

and Internet Explorer support SSL, and many Web sites use the protocol to obtain confidential user information, such

as credit card numbers. SSL is an open, nonproprietary protocol. It has been submitted to the W3 Consortium (W3C)

working group on security for consideration as a standard security approach for World Wide Web browsers and

servers on the Internet.

Taher Elgamal was one of the developers of Secure Sockets Layer. Currently, he is president of the Information

Security Group for The Kroll-O'Gara Company. "The primary use of SSL is in virtually all the encrypted e-commerce

credit-card transactions today. SSL consists of both the handshake – the negotiation that convinces the browser and the

server that they both support the methods that they agreed on -- and the secure pipe to make sure that people cannot

attack SSL itself," he says.

By convention, Web pages that require an SSL connection start with https: instead of http:, and provide data

encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. The

secure environment for SSL is created through the use of public key cryptography, which consists of the encryption

(scrambling) and decryption (unscrambling) of information. Public key cryptography allows anyone to send an

encrypted message to a designated recipient, using what is known as a public key. The recipient then uses a private

key to decrypt the message. Therefore, only the designated recipient has the ability to read the message.


7


SSL comes in two strengths, 40-bit and 128-bit, which refer to the length of the "session key" generated by every

encrypted transaction. The longer the key, the more difficult it is to break the encryption code. Most browsers support

40-bit SSL sessions, and the latest browsers, including Netscape Communicator 4.0, enable users to encrypt

transactions in 128-bit sessions – trillions of times stronger than 40-bit sessions. Global companies that require

international transactions over the web can use global server certificates program to offer strong encryption to their

customers.

? Characteristics

The primary goal of the SSL Protocol is to provide privacy and reliability between two communicating applications.

The protocol is composed of two layers. At the lowest level, layered on top of some reliable transport protocol (e.g.,

TCP[TCP]), is the SSL Record Protocol. The SSL Record Protocol is used for encapsulation of various higher level

protocols. One such encapsulated protocol, the SSL Handshake Protocol, allows the server and client to authenticate

each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits

or receives its first byte of data. One advantage of SSL is that it is application protocol independent. A higher level

protocol can layer on top of the SSL Protocol transparently.

The SSL protocol provides connection security that has three basic properties:

o The connection is private. Encryption is used after an initial handshake to define a secret key.

Symmetric cryptography is used for data encryption (e.g., DES[DES], RC4[RC4], etc.)

o The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g.,

RSA[RSA], DSS[DSS], etc.).

o The connection is reliable. Message transport includes a message integrity check using a keyed

MAC. Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations

? working and Handshake

Working:

SSL works through encryption, specifically, public key encryption. This is a technique that uses a pair of asymmetric

keys for encryption and decryption. Each pair of keys consists of a public key and a private key. The public key is

made public by distributing it widely. The private key is never distributed; it is always kept secret.

Data that is encrypted with the public key can be decrypted only with the private key. Conversely, data encrypted with

the private key can be decrypted only with the public key. This asymmetry is the property that makes public key

cryptography so useful. The primary goal of the SSL Protocol is to provide privacy and reliability between two

communicating applications. The protocol is composed of two layers. At the lowest level, layered on top of some

reliable transport protocol (e.g., TCP[TCP]), is the SSL Record Protocol. The SSL Record Protocol is used for

encapsulation of various higher level protocols. One such encapsulated protocol, the SSL Handshake Protocol, allows

the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before


8


the application protocol transmits or receives its first byte of data. One advantage of SSL is that it is application

protocol independent. A higher level protocol can layer on top of the SSL Protocol transparently.

Privacy is guaranteed through encryption. Although information can still be intercepted by a third party, they will be

unable to read them as they have no access to the encryption key. Integrity is also ensured through encryption. If

information is received that will not decrypt properly then the recipient knows that the information has been tampered

with during transmission. Authentication is provided through digital certificates. Digital certificates provide the basis

for secure electronic transactions as they enable all participants in a transaction to quickly and easily verify the identity

of the other participants.

Handshaking:

The SSL protocol uses a combination of public-key and symmetric key encryption. Symmetric key encryption is much

faster than public-key encryption, but public-key encryption provides better authentication techniques. An SSL session

always begins with an exchange of messages called the SSL handshake. The handshake allows the server to

authenticate itself to the client using public-key techniques, then allows the client and the server to cooperate in the

creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows.

Optionally, the handshake also allows the client to authenticate itself to the server.

Here in detail are the steps taken during a SSL transaction:

1. The client sends a request for a document to be transmitted using the HTTPS protocol by prefixing

the URL with "https".

2. The server sends its certificate to the client.

3. The client checks if the certificate was issued by a Certificate Authority (CA) it trusts. If not, it gives

the user the option to continue or to terminate the transaction.

4. The client compares the information in the certificate with the information it just received

concerning the site: its domain name and its public key. If the information matches, the client accepts

the site as authenticated.

5. The client tells the server what ciphers, or encryption algorithms, it can communicate with.

6. The server chooses the strongest common cipher and informs the client.

7. The client generates a private (or session) key using the agreed cipher.

8. The client then encrypts the session key using the server's public key and sends it to the server.

9. The server receives the encrypted session key and decrypts it with its private key.

10. The client and the server then use the session key for the rest of the transaction.

It is important to note that both client and server authentication involve encrypting some piece of data with one key of

a public-private key pair and decrypting it with the other key. In the case of server authentication, the client encrypts

the premaster secret with the server's public key. Only the corresponding private key can correctly decrypt the secret,

so the client has some assurance that the identity associated with the public key is in fact the server with which the


9


client is connected. Otherwise, the server cannot decrypt the premaster secret and cannot generate the symmetric keys

required for the session, and the session will be terminated.

In the case of client authentication, the client encrypts some random data with the client's private key--that is, it creates

a digital signature. The public key in the client's certificate can correctly validate the digital signature only if the

corresponding private key was used. Otherwise, the server cannot validate the digital signature and the session is

terminated.

The SSL protocol runs above TCP/IP and below higher-level protocols such as HTTP or IMAP. It uses TCP/IP on

behalf of the higher-level protocols, and in the process allows an SSL-enabled server to authenticate itself to an SSL-

enabled client, allows the client to authenticate itself to the server, and allows both machines to establish an encrypted

connection.

2.2.2. SET (more specific description in next chapter)

? Concept

SET is the Secure Electronic Transaction protocol developed by Visa and MasterCard specifically for enabling secure

credit card transactions on the Internet. Like SSL, SET allows for the merchant's identity to be authenticated via digital

certificates. However, SET also allows for the merchant to request users authenticate themselves through digital

certificates. This makes it much more difficult for someone to use a stolen credit card. A further advantage of SET is

that the merchant has no access to credit card numbers and thus another source of fraud is eliminated.

SET is exempt from the US cryptographic export restrictions and unlike SSL can therefore use strong, 128 bits

encryption for credit card numbers world-wide. In order to gain this exemption, the use of strong encryption has to be

limited to the financial information only and does not include other elements of the transaction, for example details of

the goods being bought and the delivery address.

It uses digital certificates to ensure the identities of all parties involved in a purchase and encrypts credit card

information before sending it across the Internet.

? Difference with SSL and advantage

To begin with, it's an entirely different kind of transaction. Once you initiate an SSL session with a commerce site, the

transaction isn't any different than when you give your credit card to a clerk in a department store. They tell you the

price, you say OK, and you wait while the clerk attempts to validate your card and the purchase amount with the bank

card company. If it's approved, the clerk prints out a receipt, which you sign, keeping a copy for your records.

With SET, the bank card company gets involved in the middle of the transaction, essentially acting as middleman.

Theoretically, when you enter your card in an online SET transaction, the commerce site might never see your actual

credit card number. Instead, that info would go to the financial institution, who would verify the card and the amount,

then make payment to the commerce site, all in exchange for a fee, of course.


10


What are the advantages of SET? Well, we're speaking theoretically here, since SSL is actually up and running and

SET isn't. With that proviso out of the way, SET could offer more security for online transactions, by adding the

mandatory authentication between buyer and seller, using digital certificates. It could also speed up the payment

settlement process, since the financial institutions are involved up front, rather than after the fact. It might also increase

privacy, since you wouldn't necessarily be sharing your credit card number with online retailers, but with your

financial institution (which presumably already knows your card.)

2.2.3. C-SET

C-SET stands for "Chip-Secure Electronic Transaction" which means "system for providing secure electronic

payment transactions over the Internet using Smart-Cards". The name was chosen in February 1996, for several

reasons:

- to emphasize that the protocol is based on the SET (Secure Electronic Transaction) protocol defined by

MasterCard and VISA, and incorporates all of its principles,

- to indicate that the SET protocol has been adapted to Smart-Card technology, or rather, to show that it has been

extended to include a physical level of security (something that SET had expressly left out). Only the use of card

readers and black boxes can provide real security.

The Anglo-Saxon abbreviation C-SET was then adopted by the French banking commu nity.

? Various fraud risks

? Invalid card carrier: the customer provides an invalid card number, or a real number which isn't his. The hacker

can usually be traced by means of the name and delivery address provided (assuming they are correct!), but in doing so

the merchant might incur substantial investigation costs, perhaps even legal costs. In some circumstances, this can

result in a loss for the merchant. Should a real number be used, this is also bound to result in a contestation by the

genuine card holder, with ensuing damage to the reputation of the card, the bank and the merchant.

? Invalid merchant: here, a hacker sets up an Internet server allegedly to sell goods, but delivers nothing and

vanishes after a few weeks, having recorded all the card numbers, with the intention of using them fraudulently

elsewhere. A variation on this involves a hacker tapping into the Web site of a genuine merchant and reading off the

card numbers as they are uploaded by unwitting customers. The genuine merchant delivers the goods ordered to its

customers, so there are no immediate complaints, and this form of fraud can therefore last for much longer before

anyone notices it. In both cases, there is a risk of loss to the bank of the "defrauded" customer, and a risk of losing

credibility in the eyes of customers.

? "Trojan horse" viruses: viruses are programs in their own right which can be transmitted by means of an

infected diskette, through a local network, an FTP download, a message received with an attachment, or simply by


11


viewing an Internet Web page (via Java applets or Active X). Some viruses, known as "Trojan horses" (which are

luckily still extremely rare, though this might not last), can lie dormant in your system, awaiting specific events such

as the inputting of a sequence of numbers from the keyboard, which might constitute a card number, or the shifting of

a non-encrypted card number along the computer's internal bus, or the detection of an X509-standard file which might

constitute a customer certificate, etc. Once detected, the data in question is recorded pending a period of inactivity of

the host computer (lunch-time, or even the middle of the night) whereupon the virus can trigger and establish an

Internet connection (by switching on the computer if need be, as is possible on the latest models, and by disabling the

"firewall" protection systems of corporate networks which often only filter incoming accesses), and send an e-mail to

the hacker, containing the intercepted data. The hacker can then pretend to be the real customer. The financial risk is

the same as with the "invalid merchant" case.

? "non-WYSIWYG" viruses: refers to viruses which are capable of displaying on-screen different information

from that used in the actual payment under way. For example, the true price of the item ordered is displayed, but a sum

ten times larger is sent to the merchant. These viruses could be used to generate illicit profits for fraudulent merchants

(who would then disappear less than a fortnight later, before customers start complaining), or more likely cause

disruptions in dealings with bona fide merchants, leading to a loss of credibility in the system among users. To date,

there have been no known cases of such a virus.

SET security provides some protection against the above risks. C-SET security, on the other hand, provides total

protection against them.

? Distinguishing features of C-SET relative to SET

SET is a protocol which was devised by MasterCard, VISA and various US parties with a strong vested interest in the

Internet, in order to secure payments made by cards over the Internet. Customers do not physically use their cards;

instead, they make use of a pre-allocated "SET certificate". This certificate is recorded on the hard drive of a

customer's computer, or on a diskette. C-SET is a protocol, but primarily an architecture, defined by Groupement des

Cartes Bancaires. The C-SET protocol is an adaptation of the SET protocol, enabling the integration of a physical

level of security (something which SET itself does not provide), using Smart-Cards, secure Smart-Card readers, and

"Electronic Commerce Black Boxes":

The key distinguishing feature of C? -SET is that the bank card and its chip are used in a physical sense.

The ? secure card readers come in the form of a box shaped like a calculator, and incorporating a dual-position

Smart-Card reader: AFNOR for reading B0'-type cards (such as the bank cards currently issued in France) and ISO for

reading EMV cards (for future applications). They also incorporate a numerical keypad and a display. Finally, they

come with internal software, and an RSA encryption module to verify or issue signatures, and check the authenticity of

the software used. The internal software is uploaded in a secure manner, which will open the way for the integration of

other applications, such as Home Banking, access control, the secure downloading of information into Smart-Cards,

etc. It will also enable a smooth transition towards the use of EMV-standard cards. Finally, a system checks that the


12


carrier software is authentic (i.e. certified by the bank) and offers a facility to trace any attempts to subvert the system.

Such card readers may eventually be integrated into the standard design of micro-computers by manufacturers (into

keyboards, for example). In order to be operational, the card readers will have to be approved by Groupement des

Cartes Bancaires.

The ? Electronic Commerce Black Boxes are secure encryption units, based on the banking Black Boxes currently

in use in France, and adapted for use with TCP/IP networks and with RSA encryption.

Finally, we should point out that the C? -SET architecture incorporates 2 fundamental categories of equipment:

"Internet Remote Payment Controllers" and "Translators".

The Internet Remote Payment Controllers are devices tha? t act as an Internet Payment Gateway and Remote

Payment Controllers. The Internet Payment Gateway is a firewall and manages the C-SET protocol like does a

Payment Gateway in a SET architecture but while controlling the chip-data. The Remote Payment Controllers are the

same than those used to secure payment via Minitel (a semi-graphical terminal very well used in France for remote

retailing and on - line services).

The ? Translators control international flows by acting as Secure Bridges between France and abroad to convert C-

SET transactions in SET and reverse if necessary.

2.2.4. Interoperability

? SET/ C-SET: C-SET for Cardholder and SET for Merchant / SET for Cardholder, C-SET for Merchant

Is the C-SET secure system compatible with the SET secure system? Yes. The Translator located at Europay

France will ensure full inter-operability with SET, both for international payments made by foreigners using SET on

French Web sites (see Figure 2-1) and for international payments made by French nationals equipped with a card

reader and a Smart-Card on Web sites abroad (see Figure 2-2).

<Figure 2-1>


13


<Figure 2-2>

Furthermore, the Translator acts as a Secure Bridge enabling the use in France of French keys, even for international

payments (where the merchant's private RSA key is abroad), thus complying with French law. C-SET is THE ONLY

solution offering this facility.

? SSL/SET : Hybrid SSL/SET architecture

Concept

This architecture would combine the benefits of SET with the simplic ity of SSL. Clients and merchants could continue

to use their SSL applications, while the SET services are assured on the bank side. This solution necessarily relies on a

payment intermediary to manage the conversions between SET and SSL and to act as the proxy and guarantor of its

clients (consumers and merchants) to SET certification authorities. For example, the payment intermediary could

manage the SET certificates for customers and save them from the concomitant administrative loads. At the same time,

the intermediary would guarantee the authenticity of those that it represents with respect to each other as well as with

respect to the SET authorities. The intermediary could also play the role of a gateway SET/SSL. In this case, the client

and merchant would talk to the payment intermediary on a channel secured by SSL. However, the intermediary would

use the protocol SET to communicate with the payment gateway.

Hybrid SET/SSL model

<Figure 2-3> presents the hybrid SET/SSL model. In this configuration, the payment intermediary plays the roles of

SSL server with respect to the client and the merchant, Web host for the merchant, and SSL certification authority for

both.


14


<Figure 2-3>

From the SET viewpoint, the payment intermediary acts as the merchant’s agent and will be the merchant as far as the

SET payment gateway is concerned. The intermediary will have two pairs of private/public keys, one pair for the

exchange of data encryption keys and the other for signing the transmitted data. Since it has the role of SSL

certification authority for the merchant and the client, it will own a third pair of private/public keys and an SSL

certificate.

Transaction Flows

A transaction includes four parts

1. SSL Session between the client and the intermediary

The client visits the merchant’s site and chooses the desired article. He or she then clicks on the link to the mercahnt’s

Web page and ends up on the server of the payment intermediary. After establishing an SSL session with the

intermediary server, the client fills out an order form, which includes the client name, order details, name of the

merchant, transaction amount, etc., and particularly the number of the bank card to be charged. The merchant does not

have access to the client’s card number.

The certificate from the payment intermediary to the client contains the SSL certificate of the intermediary. The return

Certificate message from the client includes the client’s SSL certificate that the intermediary has issued.

Acquirer Bank

Payment

intermediary

(SSL Server and

Client

SET Payment

Gateway

Bank Card

Network

SET Certification

Authority

Internet

Issuer Bank

SET

SET

SET

SSL SSL

Merchant


15


The intermediary next establishes another SSL session with the merchant. Once the communication has been secured,

the intermediary transfers to the merchant a payment order without financial details or possibly without the purchaser

identity. The merchant analyzes this request; if it is accepted, the merchant informs the intermediary of its acceptance,

according to the application protocol established between the intermediary and the merchant. Once the intermediary is

satisfied with the validity of the response, it initiates a SET communication with the SET payment gateway.

2. Payment Authorization

In this phase of the transaction, the intermediary behaves exactly as a merchant in the SET protocol, exchanging the

messages shown in <Figure2-4>.

<Figure 2-4>

Using the data collected from both the client and the merchant, the payment intermediary forms the authorization

request AuthReq, and signs it with the private key of the merchant. If the client is SET-certified the dual signature of

SET is constructed with the client private key; otherwise, the intermediary could use its own signature key.

If the response is contained in AuthRes, the intermediary alerts the merchant that payment authorization has been

obtained for delivery of goods to the client. Simultaneously, it signals to the client that the financial transaction has

been authorized.

3. Notification of the Merchant and the Client

In this phase, the payment intermediary informs the client and the merchant of the authorization results using the SSL

session already established.

4. Financial Settlement

Once the goods have been shipped, the merchant sends the intermediary a request for settlement (clearance). The

Internet

Cardholder

SET payment gateway

Merchant

SSL

SSL

SSL

Payment Intermediary

AuthReq

AuthRes

CapReq CapRes


16


exchanges follow the application protocol established between the intermediary and the merchant and are transported

over a session secured by SSL. Having received the merchant’s request, the payment intermediary reconfigures it into

the SET CapReq Message, which is directed toward the SET payment gateway. The response in the CapRes is

converted back to the format common with the merchant and sent in a session by SSL.

2.2.5. Others : algorithm, biometric

There are some implementation Constraints like memory and limited computing power. To develop the high capacity

products takes high costs. The solution about these constraints is meeting with Elliptic Curve Cryptosystem. It

provide less EEPROM and shorter transmission time, scalability, mo coprocessor, and on card key generation.

Another technique is using biometric method.

Fingertip sensor on smart card provide authentication by sensor, self – activate and self – destroy system. Fingertip

sensor on Card Reader provide smart card stores finger print information and finger print verification on card reader.

The SSL protocol, widely deployed today on the Internet, has helped create a basic level of security sufficient for most

to conduct business over the Web. SSL is implemented in most major Web browsers used by consumers, as well as in

merchant server software, which supports seller's virtual storefront in cyberspace. Hundreds of millions of dollars are

already changing hands when cybershoppers enter their credit card numbers on Web pages secured with SSL

technology. The SSL protocol is a powerful tool for the secure distribution of information, but does not address all of

the risks associated with sending and accepting transactions over the Internet. For example, SSL establishes a secure

session between a browser and a server. During the period when the browser is logged onto an SSL server,

authentication between the browser and the server takes place. However, SSL does not authenticate the parties who are

using that software. Thus, while cardholders using SSL can submit payment information free from the prying eyes of a

third party, there is no way of verifying the identity of the online storefront that they are visiting. There are many pilot

schemes running using the SET protocol, but mainstream adoption has been slower than predicted. The main reasons

behind this are the growing acceptance of SSL for secure credit card transactions and the complexity and cost of the

SET system.

In this project we will mainly deal with SET protocol because this SET is not only the basic concept to transact with

multiple entities with, but also our object of this project is imple menting SET with javacard. And we want to suggest

more simple improved SET in the later chapter.


17


3. SET

3.1 Definition SET is the Secure Electronic Transaction protocol developed by Visa and MasterCard specifically for enabling secure

credit card transactions on the Internet. Like SSL, SET allows for the merchant's identity to be authenticated via digital

certificates. However, SET also allows for the merchant to request users authenticate themselves through digital



SET is exempt from the US cryptographic export restrictions and unlike SSL can therefore use strong, 128 bit

encryption for credit card numbers world-wide. In order to gain this exemption, the use of strong encryption has to be

limited to the financial information only and does not include other elements of the transaction, for example details of

the goods being bought and the delivery address.

It uses digital certificates to ensure the identities of all parties involved in a purchase and encrypts credit card

information before sending it across the Internet.

3.2 Background of SET

Visa and MasterCard joined forces to develop a single standard to secure payment card transactions over insecure

networks. They released the first draft of the standards last summer, and since then they have been working feverishly

to educate potential users and software developers. The final version of the specification came out May 31, and Secure

Electronic Transactions (SET)-compliant applications should appear by the end of the year. Other major card brands,

including American Express and NOVUS (Discover), have also endorsed the SET standard. SET's goals are to provide

confidentiality, authentication, and integrity of payment card transmissions. To do this, SET uses a variety of

cryptographic techniques, including encryption, digital signatures, and certificates.

3.3 History of SET

1995 .2 SEPP(Secure Electronic Payment Protocol)announcement by MasterCard, Netscape, IBM, GTE

1995 .2 STT(Secure Transaction Technology) announce by VISA, Microsoft

1996.1 SET announcement by VISA, MasterCard, GTE, IBM,Microsoft, Netscape, SAIC, Terisa, VeriSign

1996 .8 SET 0.0 Spec. announecment

1997 .5 SET 1.0 Spec. announce

1998 .1 SET 1.0 I14Y(Interoperability, 14 char. between I and Y)is going on


18


3.4 Future of SET As you can see, SET messages can be quite complex, and the specified key sizes (1,024- and 2,048-bit) are quite

secure for now; but that in itself is not enough to guarantee security. As we've learned from the experiences of

Netscape and others, the devil is in the details when it comes to implementing cryptographic algorithms. On paper,

SET has gone a long way toward making payment card purchases more secure than they've ever been. For more

information on SET, see either MasterCard's Web site, at

3.5 Certificates The first thing all SET participants need -- cardholders, card issuers, merchants, and "acquirers" (like an issuer, but for

merchants) -- is a set of public/private key pairs. Once you've generated these, you must get your public key

guaranteed in a certificate issued by a trusted third party or certificate authority. The certificate authority's certificate is

in turn guaranteed by another certificate authority, up a hierarchy of trust that culminates in a "root" certificate

authority. Should any certificate become compromised (including the root), the standard has procedures in place to

revoke and reissue certificates.

To help maintain security, cardholder certificates contain a one-way hashed value of the card number, expiration date,

and a secret value generated by the cardholder's software. The information cannot be recovered directly from the

certificate, but the cardholder can prove the certificate is his or hers by providing account information. For most

cardholders, their certificate authority will be the same company that issues their card. How a certificate authority

verifies the identity of the certificate holder is outside the scope of the standard, but the process is likely to be similar

to opening an account at a bank.

The developers of the SET standard are aware that most cardholders don't know, or care, about certificates right now,

and educating them and building the infrastructure to issue and maintain large numbers of certificates takes time. As a

result, they have allowed "interim" implementations to temporarily forgo issuing cardholder certificates (all other

certificates are required). In this case, messages back to the cardholder (order status, for example) are not encrypted,

but the integrity of messages from the cardholder is still ensured by the use of a message digest.

3.6 Transactions Now armed with the necessary keys and certificates, a cardholder can start adding to his or her debt. Most SET

transactions consist of two rounds of requests and responses. First, the requester and responder exchange certificates

and verify each other's authentication information. Then, if the first round succeeds, the actual request and response

take place.

Let's say you've decided what you want to buy, your software has completed the round of certificate exchanges

successfully, and now you're ready to send your purchase on its way. From the certificate exchange, you have the


19


merchant's public key, the payment processor's key, and a unique transaction identifier issued by the merchant. How

does SET deliver your purchase securely?

First, you create the necessary order information (OI) and payment instructions (PI). Both include the merchant-

assigned transaction identifier. Next, you apply a one-way hashing function to make digests of both the order

information and payment instructions. Then you create a "dual signature." This allows both the merchant and payment

processor to independently verify that your payment instructions and order information belong together without

requiring either processor to see the other's data. SET's dual signature is a digest of the concatenation of the OI and PI

message digests, encrypted with your private key. For better encryption/decryption performance, you select a random

symmetric key and encrypt the payment instructions with it; and, finally, you encrypt the random symmetric key and

your account number with the payment processor's public key. When you're done, you have a message containing:

?? OI, including the merchant's transaction identifier

?? A digest of the order information

?? PI, including merchant's transaction identifier, encrypted with a random symmetric key

?? A digest of the payment instructions

?? A dual signature: digest (OI digest + PI digest) encrypted with your private key

?? Your account number plus the random symmetric key encrypted with the payment processor's public key.

3.7 Encryption Process In a typical SET transaction, there is information that is private between the customer and the merchant (such as the

items being ordered) and other information that is private between the customer and the bank (such as the customer's

credit card number). SET allows both kinds of

private information to be included in a single, digitally signed transaction.

Information intended for the bank is encrypted using the bank's public key whilst information for the merchant is

encrypted with the merchant's public key. This means that the merchant has no access to the credit card details and

thus a source of fraud is eliminated.

In addition to this encryption, both sets of information are digitally signed. Finally these two signatures are combined

to produce one signature that covers the whole transaction.

In detail, the steps that are taken are:

1. The customer selects the items to be purchased, and pushes the "purchase" button.

2. The browser will send an initial message to the webserver, a SET-PDU.

3. The server will respond, and will contain the merchant’s digital certificate, assuring the customer of

the merchant’s authentication.

4. The customer’s software examines the message, and then the customer creates a purchase order

which will include the sensitive credit card information. The cardholder encrypts the purchase order

with a single new key that is generated. Then the key is encrypted with the gateway’s public key.


20


Now only the gateway can read the single key and therefore decrypt the purchasing information.

5. Merchant receives the purchase order, and decrypts it, and authenticates the customer. Now the

merchant sends an authorization request message to the gateway.

6. The gateway decrypts the information, and authenticates the merchant. Then it decrypts the purchase

order, and authenticates the customer.

7. The gateway now checks the company that issued the credit card. This ensures the card’s validity

and limit, and finalizes the purchase.

8. The gateway receives the authorization from the credit card company, and sends a response message

to the merchant.

9. The merchant sends a confirmation of the customer’s order to the customer. The process is finished!!

3.8 Three Parts to the SET System The three parts to the SET system are: the " wallet" on the user's computer; a commerce server that runs at the

merchant's Web site; and the payment server that runs at the merchant's bank. Although future versions of Microsoft's

Internet Explorer and Netscape's Navigator will come with SET wallets pre-installed, currently users need to download

and install a wallet on their computers. During the installation process the user provides credit card details and obtains

user name and PIN to provide secure access to the wallet. The installation process also produces a public and private

key for the user. The user also has to obtain a digital certificate from their bank or certificate agency (CA) for each

credit card.

To use SET, users select products from the merchant's Web site and then elect to pay via SET by pressing an on-screen

button. This automatically starts the wallet program. The user then selects which credit card to use, and the wallet and

the merchant's server exchange certificates. If these are accepted, the wallet then encrypts and transmits the purchase

details to the merchant. Although the purchase details include the encrypted credit card information, the merchant can

not read them. Instead he passes this on to the bank's payment server which debits the users credit card and passes the

payment to the merchant.

3.9 Secure Transmission Schemes in SET Protocol

▶Sender’s Computer

1. The message is hashed to a prefixed length of message digest.

2. The message digest is encrypted with the sender’s private signature key, and a digital signature is created.

3. The composition of message, digital signature, and Sender’s certificate is encrypted with the symmetric key which

is generated at sender’s computer for every transaction. The result is an encrypted message. SET protocol uses the

DES algorithm instead of RSA for encryption because DES can be executed much faster than RSA.

4. The Symmetric key itself is encrypted with the receiver’s public key which was sent to the sender in advance.

The result is a digital envelope.


21


▶Receiver’s Computer

5. The encrypted message and digital envelope are transmitted to receiver’s computer via the Internet.

6. The digital envelope is decrypted with receiver’s private exchange key.

7. Using the restored symmetric key, the encrypted message can be restored to the message, digital signature, and

sender’s certificate.

8. To confirm the integrity, the digital signature is decrypted by sender’s public key, obtaining the message digest.

9. The delivered message is hashed to generate message digest.

10.he message digests obtained by steps 8 and 9 respectively, are compared by the receiver to confirm whether there

was any change during the transmission. This step confirms the integrity.

3.10 Essential Security Requirements in SET Authentication: A way to verify the buyer’s identity before payments are made Integrity: Ensuring that information

will not be accidentally or maliciously altered or destroyed, usually during transmission Encryption: A process of

making messages indecipherable except by those who have an authorized decryption key Non-repudiation:

Merchants need protection against the customer’s unjustifiable denial of placed orders, and customers need protection

against the merchants’ unjustifiable denial of past payment

3.11 Entities of SET protocol in Cyber shopping

<Figure 3-1>

I

Customer x Customer y

With Digital Wallets Certificate Authority

Electronic Shopping Mall Merchant Credit Card

Brand

Payment Gateway


22


3.12 Overview of main Messages in SET

<Figure 3-2>

Cardholder

Registration

Purchase

Request

Payment

Authorization

Payment

Capture

Merchant

Registration

Authorization

Request

Response

Capture Request

Response

Capture

Request

Certificat

Certificate

Request

Certificat

Request to Verity the

information

Respons

Respons

Authorization

Request

Clearing Request

Authorization

Request

Respons

Acquirer

Card CA Issue

Merchant CA

Payment

Gateway

Purchase

Response

Purchase

Request

:Over the Internet :Over Financial Network


23


4. JAVACARD

Java Card 은 Sun 사의 Java 기술을 메모리의 한계를 갖는 스마트 카드나 다른 디바이스상에서 구현될

수 있도록 규격이 정해져 있다. Java Card API 는 어떤 스마트 카드 플랫폼에서 자바 카드 기술로

구현된 응용 프로그램을 다른 플랫폼에서 동작하도록 한다. Java Card Application Environment

(JCAE)는 전세계 90%의 스마트 카드 제조 능력을 갖는 회사들에게 OEM 방식으로 라이센싱되어 있다.

아래와 같은 Java Card 기술의 이점이 있다.

?? Platform Independent - Java card API로 작성된 Java Card 애플랫은 JCAE를 이용하는 어떠한

카드상에서도 동작한다.

?? Multi-Application Capable - Multiple applications can run on a single card. 하나의 카드상에

서 여러 응용 프로그램을 동작시킬 수 있다.

?? Post-Issuance of Applications - 카드를 발행한 후에도 응용프로그램을 설치하는 하는 것이

가능하다. 이러한 기능으로 카드 발행회사는 고객의 변경 요구를 적극적으로 수용할 수 있다.

?? Flexible - 객체지향적 기술이 자바 카드 기술에 적용되어 프로그램을 작성하는데 상당히 유연

하다.

?? Compatible with Existing Smart Card Standards - 자바카드 API는 ISO7816과 같은 국제 표준

과 Europay/Master Card/Visa (EMV)과 같은 산업 표준과 호환성이 있다.

4.1 Smart Card Hardware

스마트 카드는 8개의 Contact Point 와 Embedded CPU, ROM, RAM, EEPROM 등으로 구성되어 있다.

4.1.1 Smart Card Contact Points

스마트 카드는 8개의 Contact Point가 있다. 그림<4-1>와 같이 기능이 각 포인터별로 할당되어 있다.

Contact Point의 크기와 위치는 ISO7816에 규정되어 있다.

- Vcc point : 칩의 전원을 공급한다. 3에서 5볼트의 전압이 공급된다.

- RST point : 마이크로 프로세스를 리셋하기 위한 접점이다.

- CLK point : 마이크로 프로세스의 내부 클럭을 공급하는 접점이다.

- GND point : 기준 전압을 공급하기 위한 접점이다.

- Vpp point : Optional 접점으로 지금은 사용되지 않는다.

- I/O point : 스마트 카드와 리더기간에 명령(Command)과 데이터 전송을 위하여 Half-duplex

mode로 이용된다.


24


- RFU points : 미래에 사용될 목적으로 Reserved 된 접점이다.

<Figure 4-1> Java Card Contact Point

4.1.2 Smart Card Central Processing Unit

스마트 카드에서 대부분의 CPU는 8-bit microcontroller이다. 보통 Motorola의 6805나 Intel의

8051 명령어를 사용한다. 클럭 주파수는 5MHz이며, 내부에 Clock multiplier가 있어 최대 40MHz까

지 동작하는 것도 있다. 최근에 스마트 카드는 16bit나 32bit micro -controller를 사용하여 계산능력

을 향상시키는 경우도 있다.

4.1.3 Smart Card Coprocessors

보안 관련 응용 프로그램을 이용하는 스마트 카드는 Coprocessor를 이용한다. Cryptographic

coprocessor 는 CPU의 계산 능력을 보강시켜 주어 modular arithmetic 과 large-integer 계산 등

RSA 알고리즘을 이용한 응용 프로그램을 위하여 사용한다.

4.2 Smart Card Communication

스마트 카드는 CAD(Card Acceptance Device)에 삽입되어 다른 컴퓨터(Host)와 연결된다. CAD는

Reader기와 Terminal 등이 있다. Host와 Card 사이는 half-duplex로 APDU(application protocol

data units)로 불리는 데이터 패킷을 이용하여 통신한다.

4.2.1 APDU Protocol

APDU Protocol은 ISO7816-4에 규정되어 있다. APDU 메시지는 두 가지 종류가 있다. 첫째, Host가

Card에 보내는 Command APDU로 Figure<4-2> 와 같이 구조를 가지며, 둘째, Card 가 Host의 응


25


답으로 Figure<4-3>와 같은 구조를 가지는 Response APDU로, 메시지 패킷을 Host에 전송하는 것

이다.

Mandatory Header Optional Body

CLA INS P1 P2 Lc Data field Le

<Figure 4-2> Send APDU

Optional Boay Mandatory Trailer

Data field SW1 Sw2

<Figure 4-3> Response APDU

Command APDU의 데이터 구조는 다음과 같다.

- CLA(class of instruction) : Command 와 Response APDU의 종류를 표시한다.

- INS(instruction code) : Command APDU의 명령의 종류를 표시한다.

- P1, P2 : 함수의 parameter역할을 한다.

- Lc : 전송하는 Data의 사이즈를 바이트 단위로 표시한다

- Data field : 전송하고자 하는 데이터

- Le : 받고자 하는 Response APDU의 데이터 사이즈

Response APDU의 데이터 구조는 다음과 같다.

- Data field : 전송받는 Data

- SW1, SW2 : Command APDU의 처리결과를 나타내는 Status Words.

4.3 Smart Card Operating Systems

스마트 카드의 O.S는 ISO7816-4의 규격에 있는 최신 파일 시스템을 지원한다. ISO7816-4는


26


Figure<4-4>와 같이 계층적인 파일 시스템으로, 다음과 같은 세가지 종류의 파일을 지원한다.

- Master File(MF) : 파일 시스템의 Root 파일로써, dedicated files 과 elementary files을 포함한

다. 스마트카드에는 MF파일이 하나만 있다.

- Dedicated File(DF) : 스마트 카드의 디렉토리 파일로써 다른 DF와 elementary file을 가지고 있

다.

- Elementary File(EF) : EF는 데이터 파일로 다른 파일을 가지지 못한다. 데이터 파일의 종류는

transparent file, linear fixed, linear variable, cyclic fixed 등이 있다.

<Figure 4-4> Java Card File System

4.4 Java Card Technology

자바 카드의 기술요소는 다음과 같은 세 부분으로 나눌 수 있다.

- Java Card 2.1 Virtual Machine(JCVM)

- Java Card 2.1 Runtime Environment(JCRE)

- Java Card 2.1 Application Programming Interface(API)

MF

DF

DF

EDF

E

E

E


27


자바카드에 사용되는 자바 언어는 자원의 제한 때문에 일반 Computer에서 사용되는 기능을 모두 다

이용할 수 없으며 다음과 같이 한정된 범위 안에서 개발이 이루어진다. .

Supported Java Features Unsupported Java Features

- Small primitive data types: Boolean,

byte, short

- One-dimensional arrays

- Java packages, classes, interfaces,

and exceptions

- Java object-oriented features:

inheritance, virtual methods,

overloading and dynamic object

creation, access scope, and binding

rules

- The int keyword and 32-bit integer

data type support are optional

- Large primitive data types : long,

double, float

- Characters and strings

- Multidimensional arrays

- Dynamic class loading

- Security manager

- Garbage collection and finalization

- Threads

- Object serialization

- Object cloning

4.4.1 java Card Virtual Machine(JCVM)

JCVM은 일반적인 Java Virtual Machine과는 달리 <Figure 4-5>와 같이 Off-card virtual machine과

on-card virtual machine으로 나뉜다. Off-card VM의 Converter는 application class 와 관련 api

class를 모아 CAP(converted applet) 파일로 바꾼다. 이 바뀐 CAP 파일이 Java Card의 EEPROM에

다운로드되어 on-card virtual machine에서 해석(interpreter)한다.

Converter Interpr

eter

Off-card VM On-card VM

CAP

File

class

files


28


<Figure 4-5> JCVM

4.4.2 Java card runtime environment(JCRE)

JCRE는 자바카드 내부에서 수행되는 시스템 Component 들로 구성되어 있다.

<Figure 4-6> JCRE Structure

Figure<4-6>에서와 같이 JCRE는 O.S, Native Functions, Java Card Virtual Machine(JCVM), Java

card application framework classes(APIs), Industry-specific extensions 및 Class 등으로 구성되어

있다. Native Function은 low-level communicatio n protocol, memory 관리, cryptographic 등을 지원

한다.

4.4.3 Java Card API

Java Card의 API는 다음과 같은 3개의 주요 패키지와 1개의 확장 패키지가 있다.

- java.lang.

- javacard.framwork


29


- javacard.security

- javacardx.cryto

4.4.4 Applet Program Installation

Java Card Interperter 자신은 CAP 파일을 load하지 못한다. 자바 Technology에서 CAP 파일을 다운

로드하여 인스톨하는 것은 installer라는 Component의 몫이다. 이 Installer는 자바 카드 내에 있으면

서, Off-card installation Program과 함께 다운로드 및 Install을 담당한다. 그림 Figure<4-7>에서 처

럼 Off-card installation Program은 CAP 파일을 CAD를 통해 카드 안에 있는 On-card installer에게

전송한다. On-card Installer는 이 이진파일을 스마트 카드내의 메모리에 기록하고 이미 카드에 있는

클래스와 연결시키며, 데이터 구조를 초기화하여, 내부 JCRE에서 이용가능토록 한다.

<Figure 4-7> Java Card Program Installation Process

runtime environment

class

files

converter

CAP

file

off-card

installation

CAD

On-card

Installer

interpreter

class

files

class

files


30


5. Implementation of Java Card

5.1 Scenario

우리 팀은 다음과 같은 최소한 장비를 이용한 SET 프로토콜을 구현하기 위한 시나리오를 작성하였다.

- Cyberflex Java Card 1 ea

- Schlumberger Card Reader 1 ea

- Host System 1ea

가정 1 : SET 프로토콜을 구현하기 위해서는 Card Holder의 RSA Key 1 쌍과 Payment Gateway 1 쌍, 모두

2 쌍의 Key를 가져야 하나, 사용 가능한 것은 한 쌍 뿐이었어 동일한 Key를 사용하였다.

가정 2: Dual Signature의 생성은 CardHolder에서, 확인은 Merchant에서, Payment 정보의 확인 및 대칭키의

복호는 Payment Gateway에서 수행해야 한다. 이를 위해서 Crytography 알고리즘을 수행할 수 있는

Merchant 및 Payment Gateway를 구성했어야 했으나, 물리적, 시간적 제한으로 모든 Cryptography 알고리

즘은 Java Card에서 수행했다.

5.2 Java Card Program

Java Card 에 구현한 프로그램은 기본적으로 Schlumberger 사에서 제공하는 기본적인 예제 프로그램인

CryptoTest.java를 기반으로 하여 필요한 추가적인 기능들을 추가하였다. 여기에서는 기본적인 Code만

간략히 설명하며 자세한 내용은 첨부한 파일을 참조하면 된다.

Java Card 가 제공하는 클래스 패키지를 다음과 같이 import한다.

import javacard.framework.*;

import javacardx.framework.*;

import javacardx.crypto.*;

자바 프로그램은 다음과 같이 javacard.framework.Applet 클래스를 상속받아 클래스를 만든다.

public class CryptoTest extends javacard.framework.Applet {

변수 초기화

… … … … … … … ..


31


private CryptoTest() {

… … … … … … … … …

}

… … … … … … … … … … …

… … … … … … … … … … .

}

RSA의 Private Key는 1024 bit의 CRT 형식으로 static byte array 변수 rsaPrivateKey 에 , Public Key 는 변수

rsaPublicKey, 3DES 대칭키는 tripleDESKey 에 저장시켰다

//Private Key definition static byte[] rsaPrivateKey = //Note this is 338 bytes long and is a 1024 bit CRT formatted Private key { (byte)0xC2, (byte)0x01, (byte)0x05,

… … … … … … … … … … … … … … … … . (byte)0x0B, (byte)0x9C, (byte)0xC5

}; //Public Key definition static byte[] rsaPublicKey = //Note this is 140 bytes long and is a modulus exponent formatted 1024 bit Public key {(byte)0xC1, (byte)0x01, (byte)0x05,

… … … … … … … … … … … … … … .. … … … … … … … … … … … … … … .. (byte)0x01, (byte)0x00, (byte)0x01,

}; //3DES Key definition static byte[] tripleDESKey = //Note this is the triple DES key definition {(byte)0x38, (byte)0x12, (byte)0xA4, (byte)0x19, (byte)0xC6, (byte)0x3B, (byte)0xE7, (byte)0x71, (byte)0xAD, (byte)0x9F,

(byte)0x61, (byte)0xFE, (byte)0xFA, (byte)0x20, (byte)0xCE, (byte)0x63 };

Java Card의 애플랫 프로그램의 각종 자원 및 Ojbect를 생성 및 메모리에 할당하기 위한 작업을

CryptoTest() method에서 수행한다.

private CryptoTest() { pin = new OwnerPIN(PinTryLimit, MaxPinSize);// Initialise the PIN data // Initialise objects sha1buf = new byte[20]; // Result of SHA operations go here des3key = new DES3_Key(); // Make a new triple DES object sha = new Sha1MessageDigest(); // instantiate sha object RSAPublicKey = new RSA_PublicKey((short)1024);

RSAPrivateKey = new RSA_CRT_PrivateKey((short)1024);//allocate private keㅛ register();

} // end of the constructor

Install Method는 애플렛 인스탄스를 생성하기 위한 마지막 단계로 기본적으로 JCRE에 의해 호출된다.

이 함수는 Java Application의 main함수와 동일한 기능을 수행한다.


32


// Install method public static void install(APDU apdu){ // create a CryptoTest applet instance new CryptoTest(); } // end of install method

Java Card의 Applet은 selection이 되기 전까지는 suspended 상태로 있다 . JCRE가 SELECT APDU와 Applet

의 AID를 받으면 Applet Selection이 이루어 진다. Select method는 JCRE의 호출로 TRUE를 return한다. public boolean select() { // reset validation flag in the PIN object to false pin.reset(); // returns true to JCRE to indicate that the applet // is ready to accept incoming APDUs. return true; }// end of select method

APDU command를 받으면 , JCRE는 현재 Applet의 process method를 호출한다. 이 process method에서

APDU의 INS를 decoding 하여 Host가 요구하는 다양한 Crypto 알고리즘을 수행한다.

public void process(APDU apdu) { // APDU object carries a byte array (apduBuffer) to // transfer incoming and outgoing APDU header // and data bytes between card and CAD apduBuffer = apdu.getBuffer();

switch (apduBuffer[ISO.OFFSET_INS]) { case SHATest: RunTest9(apdu); return;

case RSAEnc: RunTest10(apdu); return; case RSADec: RunTest11(apdu); return; case PinCheck: CheckThePin(apdu); return;

case SETTest: RunSETTest(apdu); return; case KeyEnc: RunKeyEnc(apdu); return;

case SendCert: RunSendCert(apdu); return; case VerDual: RunVerDual(apdu); return; case VerPay: RunVerPay(apdu); return;

case DecSym: RunDecSym(apdu); return; default: ISOException.throwIt (ISO.SW_INS_NOT_SUPPORTED); }

} // end of process method

Card 소지자를 확인하기 위하여 일반카드에 비밀번호에 해당하는 PIN의 확인을 수행한다. 만약 PIN이

미리 내장된 값과 일치하지 않으면 다른 기능을 수행하는 함수들이 비정상적인 종료로 더 이상의 동작

을 하지 않는다.

// CheckThePIN method

// Takes an input of 4 bytes and checks to see if it is the actual 'mypin' set above private void CheckThePin(APDU apdu) { short byteRead = (short)(apdu.setIncomingAndReceive()); if (byteRead != 4) ISOException.throwIt(ISO.SW_WRONG_LENGTH);


33


if (pin.check(apduBuffer, (short)APDUDATA, (byte)4) == false){ ISOException.throwIt(SW_WRONG_PIN); }

} // end of CheckThePin method

RunSETTest method는 Host로부터 입력받은 Order 및 Payment Information을 이용하여 Dual Signature를 만

드는 함수이다. Dual Signature를 생성하는 Process는 다음 Figure <5-1>과 같다.

<Figure 5-1> Dual Signature Process

// RunSETTest method // Takes an input message from the incomming APDU // and make disital dual signature and concatenate to other information. // It then sends the result back. private void RunSETTest(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); // read apdu buffer

Order

Information Payment

Instructions

Hash Hash

OI Digest PI Digest

OI Digest PI Digest

Hash

OP Digest

Cardholder’s

Private Signature Key

Dual Signature

Encrypt


34


short byteRead = (short)(apdu.setIncomingAndReceive()); // make new allocation digest message // hash order information to 20 bytes digest sha.generateDigest(apduBuffer, (short)APDUDATA, (short)30, apduBuffer, (short)APDUDATA); // hash payment information to 20 byte digest sha.generateDigest(apduBuffer, (short)(APDUDATA + 30), (short)30, apduBuffer, (short)(APDUDATA +20)); // make new allocation op digest message buffer

sha.generateDigest(apduBuffer, (short)APDUDATA, (short)40, apduBuffer, (short)(APDUDATA+40));

// perfom the encryption

RSAPrivateKey.cryptoUpdate(apduBuffer, (short)(APDUDATA+40), (short)20, apduBuffer, (short)(APDUDATA+40));

// Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)168); apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)168);

}

RunKeyEnc method는 Card Holder의 Payment Information은 tripleDEC key로, 이 대칭키는 Payment Gateway

의 Public Key로 Encrypt하여 Host에 전달한다. 자세한 프로세스는 Figure <5-2>과 같다.

<Figure 5-2> Payment Information Encryption

Encrypt E(PI,S1)

Symmetric key

(S1)

Cardholder

Account

Encrypt

Payment

Gateway

Public Key

Payment

Information


35


private void RunKeyEnc(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); // read apdu buffer short byteRead = (short)(apdu.setIncomingAndReceive()); // Takes Payment Information and encrypts it using triple DES Key. des3key.setKey(tripleDESKey, (short)0); des3key.encryptECB(apduBuffer, (short)APDUDATA, (short)32, apduBuffer, (short)APDUDATA); short i; for(i = 0; i < (short)16; i++) apduBuffer[(short)APDUDATA + (short)32 + i] = (byte)i; // encript Symmetric information and Cardholder's account Information // by using payment gateway's public key.

RSAPublicKey.cryptoUpdate(apduBuffer, (short)(APDUDATA + 32), (short)16, apduBuffer, (short)(APDUDATA + 32));

// Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)160); apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)160); }

RunVerDual method와 RunVerPay method의 프로세스는 그림 Figure<5-3>과 같으며, 원래 Merchant Server가

수행해야 하는 알고리즘이지만 프로젝트의 하드웨어 제약으로 Java Card 내에서 수행하도록 구성하였다 .

<Figure 5-3> Verify Dual Signature

Decrypt Hash

Cardholder

Public Signature Key

compare

OI & PI Digest

Dual Signature


36


private void RunVerDual(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); // perform the decryption

RSAPublicKey.cryptoUpdate(apduBuffer, (short)APDUDATA, (short)128, apduBuffer, (short)(APDUDATA));

// Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)128); apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)128); } private void RunVerPay(APDU apdu){ // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); // perform the decryption

RSAPrivateKey.cryptoUpdate(apduBuffer, (short)(APDUDATA), (short)128, apduBuffer, (short)(APDUDATA));

// Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)128); apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)128); }


37


6. E-payment Application in SET

We want to here to show how the developed program work at the SET. Here we would like to introduce simplified

SET. In improved protocol there aren’t issue. We combined the issue company and bank. It is more simple previous

SET protocol, and the goal by using this mechanism is to achieve multiple purposes. By using this improved

mechanism the smartcarrd can be used independently with no certification, it can be used within just stored value. Also,

it provide some certification and authentication through the bank. Of course there needed dual signature for hiding

order information or payment information.

The main implementation is like following:

Cardholder Registration

- Certificate Request to CA

Read from Card reader (Authentication)

Purchase Request (simultaneously)

- to Issuer to get the certificate

- to Merchant

Design the protocol using DES-3,RSA,etc.

Purchase Response to Client

Authorization Request to gateway

Capture Request to gateway

Response processing

- to Client, Payment, CA

Request to Verify the Certificate

- Response from Card Holder

- Request to Issue

Merchant Registration

- Authorization Request (to

Acquirer)

- response to Merchant

Authorization process

- request to Issue

- response to Merchant

Capture process

- request to Issue

Merchant Authorization process

- response to CA

Verify Card Holder information

- send confirm to CA

Authorization process

- response to Gateway

Capture process

- clearing request from gateway

- bill to client

Client

Merchant

PG

CA

ISSUE

Acquirer


38


7. Conclusion and further more

We have introduced here the overview of E-payment system and main protocol:

E-payment system is the new payment methods with the emergence of electronic commerce on the Internet. Secure

payment systems are critical to the success of EC. There are four essential security requirements for safe electronic

payments.(Authentication, Encryption, Integrity, Non-repudiation) The key security schemes adopted for electronic

payment systems are encryption. Security schemes are adopted in protocols like SSL and SET.

Secure Sockets Layer, a protocol developed by Netscape for transmitting private documents via the Internet. SSL

works by using a private key to encrypt data that is transferred over the SSL connection. Both Netscape Navigator and

Internet Explorer support SSL, and many Web sites use the protocol to obtain confidential user information, such as

credit card numbers. SSL is an open, nonproprietary protocol. It has been submitted to the W3 Consortium (W3C)

working group on security for consideration as a standard security approach for World Wide Web browsers and servers

on the Internet. The primary goal of the SSL Protocol is to provide privacy and reliability between two communicating

applications. The protocol is composed of two layers. At the lowest level, layered on top of some reliable transport

protocol (e.g., TCP[TCP]), is the SSL Record Protocol. The SSL Record Protocol is used for encapsulation of various

higher level protocols.

SET is the Secure Electronic Transaction protocol developed by Visa and MasterCard specifically for enabling

secure credit card transactions on the Internet. Like SSL, SET allows for the merchant's identity to be authenticated via

digital certificates. However, SET also allows for the merchant to request users authenticate themselves through digital



SET is exempt from the US cryptographic export restrictions and unlike SSL can therefore use strong, 128 bit

encryption for credit card numbers world-wide. With SET, the bank card company gets involved in the middle of the

transaction, essentially acting as middleman. Theoretically, when you enter your card card in an online SET transaction,

the commerce site might never see your actual credit card number. Instead, that info would go to the financial

institution, who would verify the card and the amount, then make payment to the commerce site, all in exchange for a

fee, of course.

C-SET stands for "Chip-Secure Electronic Transaction" which means "system for providing secure electronic

payment transactions over the Internet using Smart-Cards". SET is a protocol which was devised by MasterCard,

VISA and various US parties with a strong vested interest in the Internet, in order to secure payments made by cards

over the Internet. Customers do not physically use their cards; instead, they make use of a pre-allocated "SET

certificate". This certificate is recorded on the hard drive of a customer's computer, or on a diskette. C-SET is a

protocol, but primarily an architecture, defined by Groupement des Cartes Bancaires. The C-SET protocol is an

adaptation of the SET protocol, enabling the integration of a physical level of security (something which SET itself

does not provide), using Smart-Cards, secure Smart-Card readers, and "Electronic Commerce Black Boxes”.


39


And we also have introduced the interoperability like SET/ C-SET, SSL/SET and Others method like algorithm,

biometric.

Our projected focused on the SET, so we introduced SET protocol, more deeply, and suggest more improved SET

protocol. In improved protocol there aren’t issue. We combined the issue company and bank. It is more simple

previous SET protocol, and the goal by using this mechanism is to achieve multiple purposes. By using this improved

mechanism the smart-card can be used independently with no certification, it can be used within just stored value. Also,

it provides some certification and authentication through the bank. Of course there needed dual signature for hiding

order information or payment information.

Lastly we implemented with Java-Card encryption algorithm so as to apply it to the improved SET. The sour code that

we have developed in appendix.

In this project we have leaned following;

. Understanding Smart card and SET protocol using Java-card

. Learning about encryption and decryption techniques of Java-card

. Understanding E-payment system using encryption and decryption of order and signature information between

each entity under the assumption of server-client network based on SET protocol.

If further more studying is asked to us, we want to program various encryption techniques, and to design more

improved model based on SET.


40


Appendix (Source code )

1. Server.java

// Set up a Server that will receive packets from a // client and send packets to a client. import java.io.*; import java.net.*; import java.awt.*; import java.awt.event.*; import javax.swing.*; import javacard.framework.*; import javacardx.framework.*; import javacardx.crypto.*; public class Server extends JFrame { private JTextArea display; private DatagramPacket sendPacket, receivePacket; private DatagramSocket socket; public Server() { super( "Server" ); display = new JTextArea(); getContentPane().add( new JScrollPane( display), BorderLayout.CENTER ); setSize( 400, 300 ); show(); try { socket = new DatagramSocket( 5000 ); } catch( SocketException se ) { se.printStackTrace(); System.exit( 1 ); } }

Client Server


41


public void waitForPackets() { while ( true ) { try { // set up packet byte data[] = new byte[ 1000 ]; receivePacket = new DatagramPacket( data, data.length ); // wait for packet socket.receive( receivePacket ); // process packet display.append( "\nPacket received:" + "\nFrom host: " + receivePacket.getAddress() + "\nHost port: " + receivePacket.getPort() + "\nLength: " + receivePacket.getLength() + "\nContaining:\n\t"); //new String( receivePacket.getData(), 0, // receivePacket.getLength() ) ); byte[] receiveData = receivePacket.getData(); for(int i=0; i < receivePacket.getLength(); i++){ display.append(Integer.toHexString(receiveData[i] & 0xff)); if(i%20 == 19) display.append("\n"); } // echo information from packet back to client display.append( "\n\nEcho data to client..."); sendPacket = new DatagramPacket( receivePacket.getData(), receivePacket.getLength(), receivePacket.getAddress(), receivePacket.getPort() ); socket.send( sendPacket ); display.append( "Packet sent\n" ); display.setCaretPosition( display.getText().length() ); } catch( IOException io ) { display.append( io.toString() + "\n" ); io.printStackTrace(); } } } public static void main( String args[] ) { Server app = new Server(); app.addWindowListener( new WindowAdapter() { public void windowClosing( WindowEvent e ) { System.exit( 0 ); } } ); app.waitForPackets(); } }


42


2. CryptoTest.java

// Author : Neville Pattinson // Copyright : Schlumberger APC, Austin, Texas. // email : [email protected] // Date : October 21st 1999 // Version : 2.1 // Applet for exercising DES, Triple DES and RSA in Cyberflex Access applets. // Should be used in conjuction with CryptoTest.fcn in APDU Manager. // // Triple DES, DES Enc/dec only supported on cards with GetData return byte 9 = 0x0C. // Tests 2,4,5,6,8 all fail on cards with GetData return byte 9 = 0x0B. // // *Requires a PIN of 12345678 to be presented before any test will run* // Test1 is a DES Encryption using a Byte array Key cast to a DES_Key. // Test2 is a DES Encryption/Decryption using a Byte array Key cast to a DES_Key. // Test3 is a DES Encryption using DES Key (01) in file 0011. // Test4 is a DES Encryption/Decryption using DES Key (01) in file 0011. // Test5 is a triple DES Encryption/Decryption using a Byte array Key cast to a DES3_Key // Test6 is a triple DES MAC/VerifyMAC using a Byte array Key cast to a DES3_Key. // Test7 is a DES MAC/Verif yMAC on 24 bytes using a Byte array Key cast to a DES_Key. // Test8 ia a DES encryption/Decryption in CBC mode of a 24 byte message. // Test9 is a SHA digest from XX bytes to 20. Where XX is in the range 1 to 256 // Test10 is a 1024bit RSA Private Key Encryption operation on message input // Test11 is a 1024bit RSA Public Key Decryption on cryptogram import javacard.framework.*; import javacardx.framework.*; import javacardx.crypto.*; public class CryptoTest extends javacard.framework.Applet { /* constants declaration */ // code of CLA byte in the command APDU header final byte CryptoTest_CLA =(byte)0x03; // Codes of INS byte in the command APDU header // N.B. Odd values are not allowed under ISO spec. final byte Test1 = (byte) 0x10; final byte Test2 = (byte) 0x20; final byte Test3 = (byte) 0x30; final byte Test4 = (byte) 0x33; final byte Test5 = (byte) 0x50; final byte TDMACTest = (byte) 0x52; final byte DMACTest = (byte) 0x54; final byte DEncTEst = (byte) 0x56; final byte SHATest = (byte) 0x58; final byte RSAEnc = (byte) 0x32; final byte RSADec = (byte) 0x34; final byte SETTest = (byte) 0x36; final byte KeyEnc = (byte) 0x38; final byte SendCert = (byte) 0x3a; final byte VerDual = (byte) 0x3b; final byte VerPay = (byte) 0x3c; final byte DecSym = (byte) 0x3d; final byte PinCheck = (byte) 0x40; final byte CLA_F0 = (byte) 0xF0; final byte PinTryLimit = (byte)0x0A;// maximum number of incorrect tries before the PIN is blocked final byte MaxPinSize = (byte)0x04;// maximum size of PIN allowed final short SW_WRONG_PIN = (short) 0x6BBB;// Error returnd if PIN not correctly presented final short VERIFY_BAD = (short) 0x6CCC; // Error returnd for MAC or Signature Verify failure final short APDUDATA = (short) ISO.OFFSET_CDATA; // Define apdu buffet offset for data. //Private Key definition


43


static byte[] rsaPrivateKey = //Note this is 338 bytes long and is a 1024 bit CRT formatted Private key { (byte)0xC2, (byte)0x01, (byte)0x05, (byte)0xC2, (byte)0x41, (byte)0x00, (byte)0xC5, (byte)0xD7, (byte)0x20, (byte)0x28, (byte)0xFA, (byte)0xA7, (byte)0x91, (byte)0x55, (byte)0x23, (byte)0xE2, (byte)0x0D, (byte)0xE4, (byte)0x28, (byte)0x7C, (byte)0x65, (byte)0xB7, (byte)0x18, (byte)0x59, (byte)0xD9, (byte)0x0D, (byte)0xBA, (byte)0xE7, (byte)0xCF, (byte)0x6A, (byte)0xF1, (byte)0xE3, (byte)0x10, (byte)0xC3, (byte)0x7E, (byte)0x48, (byte)0x0D, (byte)0xBC, (byte)0x76, (byte)0x7B, (byte)0x04, (byte)0x86, (byte)0xB6, (byte)0x7F, (byte)0xCD, (byte)0x6C, (byte)0x84, (byte)0x1A, (byte)0x0B, (byte)0x86, (byte)0xB9, (byte)0x96, (byte)0xAA, (byte)0x83, (byte)0x68, (byte)0x63, (byte)0x3C, (byte)0x4D, (byte)0x43, (byte)0x84, (byte)0xB8, (byte)0x6D, (byte)0x48, (byte)0xAA, (byte)0xC4, (byte)0xC9, (byte)0x1B, (byte)0x50, (byte)0x47, (byte)0x49, (byte)0xC2, (byte)0x41, (byte)0x00, (byte)0xC9, (byte)0x5E, (byte)0x4A, (byte)0x08, (byte)0x0E, (byte)0xDC, (byte)0xA5, (byte)0x45, (byte)0x90, (byte)0x1C, (byte)0x52, (byte)0xF8, (byte)0x3E, (byte)0xB0, (byte)0x6B, (byte)0x8F, (byte)0xCF, (byte)0xEA, (byte)0xA8, (byte)0xF5, (byte)0x1E, (byte)0xAD, (byte)0xD3, (byte)0x82, (byte)0x52, (byte)0x30, (byte)0x43, (byte)0x04, (byte)0x9C, (byte)0x25, (byte)0x 63, (byte)0x87, (byte)0x37, (byte)0x20, (byte)0x64, (byte)0x3F, (byte)0x16, (byte)0xB0, (byte)0x50, (byte)0xCC, (byte)0x38, (byte)0x06, (byte)0x1B, (byte)0xDF, (byte)0xE6, (byte)0x78, (byte)0xC3, (byte)0x99, (byte)0xF7, (byte)0xC4, (byte)0x3F, (byte)0x95, (byte)0x81, (byte)0xE0, (byte)0x77, (byte)0x5C, (byte)0xA3, (byte)0x78, (byte)0xB8, (byte)0x9C, (byte)0x8D, (byte)0x9B, (byte)0x46, (byte)0x5D, (byte)0xC2, (byte)0x41, (byte)0x00, (byte)0x7F, (byte)0xDE, (byte)0x17, (byte)0x36, (byte)0xDA, (byte)0x18, (byte)0x1E, (byte)0xEF, (byte)0xD0, (byte)0x50, (byte)0xBD, (byte)0x2C, (byte)0x57, (byte)0xBE, (byte)0x10, (byte)0x7B, (byte)0x08, (byte)0x7D, (byte)0xC6, (byte)0xC7, (byte)0xF5, (byte)0x76, (byte)0xA2, (byte)0x59, (byte)0x35, (byte)0x7D, (byte)0xEA, (byte)0xB0, (byte)0x73, (byte)0xE6, (byte)0x51, (byte)0xEB, (byte)0xD3, (byte)0x07, (byte)0xDD, (byte)0x73, (byte)0x56, (byte)0x8B, (byte)0x76, (byte)0x46, (byte)0x3F, (byte)0xAE, (byte)0x0A, (byte)0xB9, (byte)0xA3, (byte)0xE3, (byte)0x0D, (byte)0x71, (byte)0xFB, (byte)0xFE, (byte)0x55, (byte)0x02, (byte)0xF6, (byte)0xB6, (byte)0x4D, (byte)0xC2, (byte)0x79, (byte)0x64, (byte)0xFD, (byte)0x28, (byte)0xBB, (byte)0x13, (byte)0x23, (byte)0xB2, (byte)0xC2, (byte)0x41, (byte)0x00, (byte)0xA3, (byte)0x8D, (byte)0xA3, (byte)0xED, (byte)0x9C, (byte)0xC2, (byte)0x18, (byte)0xB8, (byte)0x9D, (byte)0x10, (byte)0x8D, (byte)0x51, (byte)0x58, (byte)0x52, (byte)0xF6, (byte)0xB7, (byte)0xB5, (byte)0xEE, (byte)0xD9, (byte)0x2C, (byte)0xAB, (byte)0x9E, (byte)0x65, (byte)0xEF, (byte)0xD0, (byte)0x86, (byte)0x59, (byte)0xDE, (byte)0x73, (byte)0xB0, (byte)0x57, (byte)0x82, (byte)0xBD, (byte)0x24, (byte)0x17, (byte)0xEA, (byte)0xD2, (byte)0x46, (byte)0xB7, (byte)0x69, (byte)0x85, (byte)0x90, (byte)0x0E, (byte)0x85, (byte)0x53, (byte)0x3A, (byte)0x06, (byte)0x3E, (byte)0xDA, (byte)0x76, (byte)0x67, (byte)0x6C, (byte)0xAC, (byte)0x6B, (byte)0xB5, (byte)0x17, (byte)0xCB, (byte)0x62, (byte)0x39, (byte)0x8A, (byte)0xD4, (byte)0x04, (byte)0xBA, (byte)0xD9, (byte)0xC2, (byte)0x41, (byte)0x00, (byte)0x44, (byte)0x03, (byte)0x03, (byte)0xB0, (byte)0x1B, (byte)0x0C, (byte)0xED, (byte)0x09, (byte)0x44, (byte)0xB6, (byte)0x3C, (byte)0x53, (byte)0xBA, (byte)0x20, (byte)0xAE, (byte)0x03, (byte)0xA1, (byte)0xAE, (byte)0xD9, (byte)0x28, (byte)0x09, (byte)0x17, (byte)0x9E, (byte)0xC3, (byte)0x7A, (byte)0x6C, (byte)0xF0, (byte)0x85, (byte)0xC3, (byte)0x13, (byte)0x61, (byte)0xBD, (byte)0x4E, (byte)0xA2, (byte)0x33, (byte)0x19, (byte)0x97, (byte)0xD9, (byte)0x2F, (byte)0x40, (byte)0xFA, (byte)0x7F, (byte)0x1D, (byte)0xB5, (byte)0x0E, (byte)0xCB, (byte)0xA5, (byte)0x0D, (byte)0x00, (byte)0xC1, (byte)0x18, (byte)0xD4, (byte)0xAF, (byte)0x4C, (byte)0x18, (byte)0x24, (byte)0x82, (byte)0xD6, (byte)0x08, (byte)0x4C, (byte)0x60, (byte)0x0B, (byte)0x9C, (byte)0xC5 }; //Public Key definition static byte[] rsaPublicKey = //Note this is 140 bytes long and is a modulus exponent formatted 1024 bit Public key { (byte)0xC1, (byte)0x01, (byte)0x05, (byte)0xC0, (byte)0x81, (byte)0x00, (byte)0x9B, (byte)0x9E, (byte)0xC6, (byte)0x74, (byte)0x65, (byte)0x5A, (byte)0xBC, (byte)0xBA, (byte)0xC6, (byte)0xB0, (byte)0x5D, (byte)0x3C, (byte)0x24, (byte)0x3C, (byte)0x90, (byte)0x59, (byte)0x7D, (byte)0x5B, (byte)0x6D, (byte)0x03, (byte)0x7B, (byte)0xAD, (byte)0x9A, (byte)0xB4, (byte)0x58, (byte)0xFE, (byte)0x80, (byte)0x22, (byte)0xEC, (byte)0xF0, (byte)0xAB, (byte)0x84, (byte)0xF9, (byte)0x07, (byte)0x84, (byte)0x91, (byte)0xE2, (byte)0x08, (byte)0xA6, (byte)0x9B, (byte)0xED, (byte)0xD7, (byte)0x45, (byte)0xC9, (byte)0xDD, (byte)0xBF, (byte)0xF8, (byte)0x7A, (byte)0x8B, (byte)0xE1, (byte)0x17, (byte)0xCD, (byte)0x3D, (byte)0xD3, (byte)0x6F, (byte)0xB2, (byte)0x59, (byte)0x0C, (byte)0x0E, (byte)0x47, (byte)0x0B, (byte)0x8E, (byte)0x83, (byte)0xC5, (byte)0x0F, (byte)0xAF, (byte)0xD8, (byte)0x21, (byte)0x0C, (byte)0xD1, (byte)0x0B, (byte)0xB4, (byte)0x24, (byte)0x8D, (byte)0x66, (byte)0xAC, (byte)0x93, (byte)0xA3, (byte)0xE4, (byte)0x61, (byte)0xEF, (byte)0x26, (byte)0x50, (byte)0x1C, (byte)0x30, (byte)0xED, (byte)0x73, (byte)0xF1, (byte)0x92, (byte)0xD8, (byte)0x2C, (byte)0xC6, (byte)0x38, (byte)0xD4, (byte)0x6D, (byte)0x81, (byte)0x48, (byte)0x2B, (byte)0xCC, (byte)0x42, (byte)0xF8, (byte)0x60, (byte)0x61, (byte)0xAD, (byte)0x8D, (byte)0x 7F, (byte)0x8D, (byte)0x6D, (byte)0x87, (byte)0xBF, (byte)0x7D, (byte)0x1C, (byte)0x61, (byte)0x2B, (byte)0xC0, (byte)0x42, (byte)0x47, (byte)0xDB, (byte)0xDD, (byte)0xC9, (byte)0x3F, (byte)0x07, (byte)0x23, (byte)0xE1, (byte)0x3D, (byte)0xDA, (byte)0xDB, (byte)0x85,


44


(byte)0xC0, (byte)0x04, (byte)0x00, (byte)0x01, (byte)0x00, (byte)0x01, }; //PIN Key definition static byte[] pinString = //Note this is the PIN { (byte)0x12, (byte)0x34, (byte)0x56, (byte)0x78 }; //DES Key definition static byte[] singleDESKey = //Note this is the DES key definition { (byte)0x38, (byte)0x12, (byte)0xA4, (byte)0x19, (byte)0xC6, (byte)0x3B, (byte)0xE7, (byte)0x71 }; //3DES Key definition static byte[] tripleDESKey = //Note this is the triple DES key definition { (byte)0x38, (byte)0x12, (byte)0xA4, (byte)0x19, (byte)0xC6, (byte)0x3B, (byte)0xE7, (byte)0x71, (byte)0xAD, (byte)0x9F, (byte)0x61, (byte)0xFE, (byte)0xFA, (byte)0x20, (byte)0xCE, (byte)0x63 }; static byte[] sendDataBuf = new byte[180]; /* instance variables declaration */ byte apduBuffer[]; // APDU buffer byte sha1buf[]; // sha1 output buffer byte ICV[]; // Initial Chaining Vector for CBC operations DES byte ICV3[]; // Initial Chaining Vector for CBC operations 3DES OwnerPIN pin; // Pin Object DES_Key deskey; // DES key object from byte array DES DES_Key deskey2; // DES Key object from file 0011 DES3_Key des3key; // 3 des key object from byte array // Sha1MessageDigest sha; // SHA1 object (Sha1MessageDigest broken) MessageDigest sha; // Alternative SHA1 object RSA_CRT_PrivateKey RSAPrivateKey;//Private Key object RSA_PublicKey RSAPublicKey; // Public Key object private CryptoTest() { pin = new OwnerPIN(PinTryLimit, MaxPinSize);// Initialise the PIN data // pin.updateAndUnblock(pinString, (short)0, (byte)4); // Load and make the PIN active. // Initialise objects sha1buf = new byte[20]; // Result of SHA operations go here ICV = new byte[8]; // ICV for DES is an 8 byte array ICV3 = new byte[16]; // ICV for 3DES must be declared at 16 bytes (bug in card) deskey = new DES_Key(); // Make a new Des Key object deskey2 = new DES_Key((short) 1); // Reference DES Key in file 0011 des3key = new DES3_Key(); // Make a new triple DES object sha = new Sha1MessageDigest(); // instantiate sha object RSAPublicKey = new RSA_PublicKey((short)1024); // make a new RSA public key object RSAPrivateKey = new RSA_CRT_PrivateKey((short)1024);//allocate private key //Set the Private key in managable chunks as we cannot setkey of 338 all at once due to ram limitations. RSAPrivateKey.setKey(rsaPrivateKey, (short)0, (short)0, (short)70); RSAPrivateKey.setKey(rsaPrivateKey, (short)70, (short)70, (short)67); RSAPrivateKey.setKey(rsaPrivateKey, (short)137, (short)137, (short)67); RSAPrivateKey.setKey(rsaPrivateKey, (short)204, (short)204, (short)67); RSAPrivateKey.setKey(rsaPrivateKey, (short)271, (short)271, (short)67); //Set the Public key in managable chunks RSAPublicKey.setKey(rsaPublicKey, (short)0, (short)0, (short)6); RSAPublicKey.setKey(rsaPublicKey, (short)6, (short)6, (short)128); RSAPublicKey.setKey(rsaPublicKey, (short)134, (short)134, (short)6); register(); } // end of the constructor // Install method public static void install(APDU apdu){


45


// create a CryptoTest applet instance new CryptoTest(); } // end of install method public boolean select() { // reset validation flag in the PIN object to false pin.reset(); // returns true to JCRE to indicate that the applet // is ready to accept incoming APDUs. return true; }// end of select method public void process(APDU apdu) { // APDU object carries a byte array (apduBuffer) to // transfer incoming and outgoing APDU header // and data bytes between card and CAD apduBuffer = apdu.getBuffer(); // Filter out the initial Select APDU for CLA=00 card if ((apduBuffer[ISO.OFFSET_CLA] == ISO.CLA_ISO) && (apduBuffer[ISO.OFFSET_INS] == ISO.INS_SELECT)){ ISOException.throwIt(ISO.SW_NO_ERROR); } // Filter out the initial Select APDU for CLA=F0 card if ((apduBuffer[ISO.OFFSET_CLA] == CLA_F0) && (apduBuffer[ISO.OFFSET_INS] == ISO.INS_SELECT)){ ISOException.throwIt(ISO.SW_NO_ERROR); } switch (apduBuffer[ISO.OFFSET_INS]) { case Test1: RunTest1(apdu); return; case Test2: RunTest2(apdu); return; case Test3: RunTest3(apdu); return; case Test4: RunTest4(apdu); return; case Test5: RunTest5(apdu); return; case TDMACTest: RunTest6(apdu); return; case DMACTest: RunTest7(apdu); return; case DEncTEst: RunTest8(apdu); return; case SHATest: RunTest9(apdu); return; case RSAEnc: RunTest10(apdu); return; case RSADec: RunTest11(apdu); return; case PinCheck: CheckThePin(apdu); return; case SETTest: RunSETTest(apdu); return; case KeyEnc: RunKeyEnc(apdu); return; case SendCert: RunSendCert(apdu); return; case VerDual: RunVerDual(apdu); return; case VerPay: RunVerPay(apdu); return; case DecSym: RunDecSym(apdu); return; default: ISOException.throwIt (ISO.SW_INS_NOT_SUPPORTED); } } // end of process method // CheckThePIN method // Takes an input of 4 bytes and checks to see if it is the actual 'mypin' set above private void CheckThePin(APDU apdu) { short byteRead = (short)(apdu.setIncomingAndReceive()); if (byteRead != 4) ISOException.throwIt(ISO.SW_WRONG_LENGTH); if (pin.check(apduBuffer, (short)APDUDATA, (byte)4) == false){ ISOException.throwIt(SW_WRONG_PIN); } } // end of CheckThePin method // RunTest1 method // Takes an input 8 byte message from the incomming APDU and encrypts it using a DES key. // Response APDU sends the original message (8 bytes)plus the encrypted block(8 bytes) private void RunTest1(APDU apdu) {


46


// access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); if (byteRead != 8) ISOException.throwIt(ISO.SW_WRONG_LENGTH); // DES encrypt // Original message (0-7); Encrypted message (8-15)) deskey.setKey(singleDESKey, (short)0); deskey.encryptECB(apduBuffer, (short)APDUDATA, (short)8, apduBuffer, (short)(APDUDATA+8)); // Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)16); // at offset 0 send 16 byte of data in the buffer apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)16); } // end of RunTest1 method // RunTest2 method // Takes an input 8 byte message from the incomming APDU and encrypts it using // a DES Key. It then decrypts it using the same DES Key. // Response APDU sends the original message (8 bytes)plus the encrypted block(8 bytes) plus the decrypted Message (8 bytes) private void RunTest2(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); if (byteRead != 8) ISOException.throwIt(ISO.SW_WRONG_LENGTH); // DES encrypt/decrypt test // Original message (0-7); Encrypted message (8-15); Decrypted message (16-23) deskey.setKey(singleDESKey, (short)0); deskey.encryptECB(apduBuffer, (short)APDUDATA, (short)8, apduBuffer, (short)(APDUDATA+8)); deskey.decryptECB(apduBuffer, (short)(APDUDATA+8), (short)8, apduBuffer, (short)(APDUDATA+16)); // Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)24); // at offset 0 send 24 byte of data in the buffer apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)24); } // end of RunTest2 method // RunTest3 method // Takes an input 8 byte message from the incomming APDU and encrypts it using // DES Key 01 in file 0011. It then decrypts it using the same DES Key. // Response APDU sends the original message (8 bytes)plus the encrypted block(8 bytes) private void RunTest3(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); i f (byteRead != 8) ISOException.throwIt(ISO.SW_WRONG_LENGTH); // DES encrypt // Original message (0-7); Encrypted message (8-15)) deskey2.encryptECB(apduBuffer, (short)(APDUDATA), (short)8, apduBuffer, (short)(APDUDATA+8));


47


// Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)16); // at offset 0 send 16 byte of data in the buffer apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)16); } // end of RunTest3 method // RunTest4 method // Takes an input 8 byte message from the incomming APDU and encrypts it using // DES Key 01 in file 0011. It then decrypts it using the same DES Key. // Response APDU sends the original message (8 bytes)plus the encrypted block(8 bytes) plus the decrypted Message (8 bytes) private void RunTest4(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); if (by teRead != 8) ISOException.throwIt(ISO.SW_WRONG_LENGTH); // DES encrypt/decrypt test // Original message (0-7); Encrypted message (8-15); Decrypted message (16-23) deskey2.encryptECB(apduBuffer, (short)APDUDATA, (short)8, apduBuffer, (short)(APDUDATA+8)); deskey2.decryptECB(apduBuffer, (short)(APDUDATA+8), (short)8, apduBuffer, (short)(APDUDATA+16)); // Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)24); // at offset 0 send 24 byte of data in the buffer apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)24); } // end of RunTest4 method // RunTest5 method // Takes an input 8 byte message from the incomming APDU and encrypts it using // triple DES Key. It then decrypts it using the same triple DES Key. // Response APDU sends the original message (8 bytes)plus the encrypted block(8 bytes) plus the decrypted Message (8 bytes) private void RunTest5(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); if (byteRead != 8) ISOException.throwIt(ISO.SW_WRONG_LENGTH); // triple DES encrypt/decrypt test // Original message (0-7); Encrypted message (8-15); Decrypted message (16-23) des3key.setKey(tripleDESKey, (short)0); des3key.encryptECB(apduBuffer, (short)APDUDATA, (short)8, apduBuffer, (short)(APDUDATA+8)); des3key.decryptECB(apduBuffer, (short)(APDUDATA+8), (short)8, apduBuffer, (short)(APDUDATA+16)); // Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)24); // at offset 0 send 24 byte of data in the buffer apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)24); } // end of RunTest5 method // RunTest6 method // Takes an input 24 byte message from the incomming APDU and MACs it using // triple DES Key. It then Verifys the MAC using the same triple DES Key. // Response APDU sends the message MAC (8 bytes) plus if verified (1 byte =01) private void RunTest6(APDU apdu) { // access authentication


48


if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); if (byteRead != 24) ISOException.throwIt(ISO.SW_WRONG_LENGTH); des3key.setKey(tripleDESKey, (short)0); des3key.setICV(ICV3, (short)0); // Allocate the ICV location (8 or 16 bytes actually used!) des3key.clearICV(); // Make the ICV for CBC operations = 0 apdu.waitExtension(); des3key.generateMAC(apduBuffer, (short)APDUDATA, (short)24, apduBuffer, (short)(APDUDATA+24), (short)8); apdu.waitExtension(); if (des3key.verifyMAC(apduBuffer, (short)(APDUDATA+24), (short)8, apduBuffer, (short)(APDUDATA), (short)24)) { apduBuffer[APDUDATA+32] = 1; // Mac verified } else { apduBuffer[APDUDATA+32] = 0; // MAC failed } // Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)9); // at offset 0 send 9 byte of data in the buffer apdu.sendBytesLong(apduBuffer, (short)(APDUDATA+24), (short)9); } // end of RunTest6 method // RunTest7 method // Takes an input 24 byte message from the incomming APDU and MACs it using // a DES Key. It then Verifys the MAC using the same DES Key. // 9000 for good and 6CCC for bad private void RunTest7(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); if (byteRead != 24) ISOException.throwIt(ISO.SW_WRONG_LENGTH); deskey.setKey(singleDESKey, (short)0); deskey.setICV(ICV, (short)0); // Allocate the ICV location deskey.clearICV(); // Make the ICV for CBC operations = 0 apdu.waitExtension(); deskey.generateMAC(apduBuffer, (short)APDUDATA, (short)24, apduBuffer, (short)(APDUDATA+24), (short)8); apdu.waitExtension(); boolean result = deskey.verifyMAC(apduBuffer, (short)(APDUDATA+24), (short)8, apduBuffer, (short)APDUDATA, (short)24); if (result == false) ISOException.throwIt(VERIFY_BAD); // MAC failed } // end of RunTest7 method // RunTest8 method // Takes an input 24 byte message from the incomming APDU and Encrypts it using // a DES Key. It then Decrypts the the cryptogram using the same DES Key. // Response APDU sends the message (24 bytes) plus Cryptogram (24 bytes) plus decrypted message (24 bytes)) private void RunTest8(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); if (byteRead != 24) ISOException.throwIt(ISO.SW_WRONG_LENGTH);


49


deskey.setKey(singleDESKey, (short)0); deskey.setICV(ICV, (short)0); // Allocate the ICV location deskey.clearICV(); // Make the ICV for CBC operations = 0 apdu.waitExtension(); deskey.encryptCBC(apduBuffer, (short)APDUDATA, (short)24, apduBuffer, (short)(APDUDATA+24) ); apdu.waitExtension(); deskey.decryptCBC(apduBuffer, (short)(APDUDATA+24), (short)24, apduBuffer, (short)(APDUDATA+48)); apdu.waitExtension(); // Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)72); // at offset 0 send 72 byte of data in the buffer apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)72); } // end of RunTest8 method // RunTest9 method // Takes an input message from the incomming APDU and SHA digests it. // It then sends the 20 byte digest back. // Response APDU sends the digest (20 bytes) private void RunTest9(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); sha.generateDigest(apduBuffer, (short)APDUDATA, (short)byteRead, sha1buf, (short)0); //sha.sha1Block(mybuf, (short)0, (byte)0x80, sha1buf, (short)0);//broken in card! // Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)20); // at offset 0 send 20 byte of data in the buffer apdu.sendBytesLong(sha1buf, (short)0, (short)20); } // end of RunTest9 method // RunTest10 method // Takes an input message from the incomming APDU and encrytpts it using an RSA Private Key. // It then sends the encryption back. // Response APDU sends the encrypted result private void RunTest10(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException. throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); // perfom the encryption RSAPrivateKey.cryptoUpdate(apduBuffer, (short)APDUDATA, (short)byteRead, apduBuffer, (short)APDUDATA); // Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)128); // at offset 0 send 128 byte of data in the buffer apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)128); } // end of RunTest10 method // RunTest11 method // Takes an input message from the incomming APDU // and decrypts it using an RSA Public Key. // It then sends the result back. private void RunTest11(APDU apdu) { // access authentication


50


if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); // perform the decryption RSAPublicKey.cryptoUpdate(apduBuffer, (short)APDUDATA, (short)byteRead, apduBuffer, (short)APDUDATA); // Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)128); // at offset 0 send x byte of data in the buffer apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)128); } // end of RunTest11 method // RunSETTest method // Takes an input message from the incomming APDU // and make disital dual signature and concatenate to other information. // It then sends the result back. private void RunSETTest(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); // read apdu buffer short byteRead = (short)(apdu.setIncomingAndReceive()); // make new allocation digest message // hash order information to 20 bytes digest sha.generateDigest(apduBuffer, (short)APDUDATA, (short)30, apduBuffer, //sendDataBuf, (short)APDUDATA); //0); // hash payment information to 20 byte digest sha.generateDigest(apduBuffer, (short)(APDUDATA + 30), (short)30, apduBuffer, //sendDataBuf, (short)(APDUDATA +20)); // make new allocation op digest message buffer sha.generateDigest(apduBuffer, (short)APDUDATA, (short)40, apduBuffer, (short)(APDUDATA+40)); // perfom the encryption RSAPrivateKey.cryptoUpdate(apduBuffer, (short)(APDUDATA+40), (short)20, apduBuffer, (short)(APDUDATA+40)); // Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)168); apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)168); } // end of RunTest11 method private void RunKeyEnc(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); // read apdu buffer short byteRead = (short)(apdu.setIncomingAndReceive());


51


// Takes Payment Information and encrypts it using triple DES Key. des3key.setKey(tripleDESKey, (short)0); des3key.encryptECB(apduBuffer, (short)APDUDATA, (short)32, apduBuffer, (short)APDUDATA); short i; for(i = 0; i < (short)16; i++) apduBuffer[(short)APDUDATA + (short)32 + i] = (byte)i;//tripleDESKey[i]; // for(;i < (short)20; i++) // apduBuffer[(short)APDUDATA + (short)32 + i] = (byte)i; // encript Symmetric information and Cardholder's account Information // by using payment gateway's public key. RSAPublicKey.cryptoUpdate(apduBuffer, (short)(APDUDATA + 32), (short)16, apduBuffer, (short)(APDUDATA + 32)); // Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)160); apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)160); } private void RunSendCert(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); // read apdu buffer short i; for(i = 0; i < (short)140; i++) apduBuffer[(short)APDUDATA + i] = rsaPublicKey[i]; // Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)140); apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)140); } private void RunVerDual(APDU apdu) { // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); // perform the decryption RSAPublicKey.cryptoUpdate(apduBuffer, (short)APDUDATA, (short)128, apduBuffer, (short)(APDUDATA)); // Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)128); apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)128); } private void RunVerPay(APDU apdu){ // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); // perform the decryption


52


RSAPrivateKey.cryptoUpdate(apduBuffer, (short)(APDUDATA), (short)128, apduBuffer, (short)(APDUDATA)); // Send results apdu.setOutgoing(); // indicate the number of bytes in the data field apdu.setOutgoingLength((short)128); apdu.sendBytesLong(apduBuffer, (short)APDUDATA, (short)128); } private void RunDecSym(APDU apdu){ // access authentication if ( ! pin.isValidated() ) ISOException.throwIt (ISO.SW_PIN_REQUIRED); short byteRead = (short)(apdu.setIncomingAndReceive()); des3key.setKey(apduBuffer, (short)APDUDATA); des3key.decryptECB(apduBuffer, (short)(APDUDATA+16), (short)32, apduBuffer, (short)(APDUDATA)); }

} // end of class CryptoTest

3. Client.java // Set up a Client that will send packets to a // server and receive packets from a server. import java.io.*; import java.net.*; import java.awt.*; import java.awt.event.*; import javax.swing.*; import java.applet.*; import java.lang.String; import slb.iop.*; import javacard.framework.*; import javacardx.framework.*; import javacardx.crypto.*; public class Client extends JFrame implements ActionListener { private JTextField oI, pI; private JLabel loI, lpI,lpin; private JTextArea display; private JButton connect, disconnect, enter, verdual, verpay; private JPasswordField pinField; private DatagramPacket sendPacket, receivePacket; private DatagramSocket socket; private byte receiveData[]; SmartCard sCard = new SmartCard(); IOP sIOP = new IOP(); public Client() { super( "Client" ); Container c = getContentPane(); c.setLayout( new FlowLayout() );


53


loI = new JLabel("Order Information"); c.add(loI); o I = new JTextField(30); c.add(oI); lpI = new JLabel("Payment Information"); c.add(lpI); pI = new JTextField(30); c.add(pI); lpin = new JLabel("PIN"); c.add(lpin); pinField = new JPasswordField(10); c .add(pinField); ButtonHandler handler = new ButtonHandler(); connect = new JButton("Connect"); c.add(connect); connect.addActionListener(handler); disconnect = new JButton("Disconnect"); c.add(disconnect); d isconnect.addActionListener(handler); enter = new JButton("Enter"); c.add(enter); enter.addActionListener(handler); verdual = new JButton("VerDual"); c.add(verdual); verdual.addActionListener(handler); // verpay = new JButton("VerPay"); // c.add(verpay); // verpay.addActionListener(handler); display = new JTextArea(12,30); c.add(new JScrollPane(display)); setSize( 480, 400 ); show(); t ry { socket = new DatagramSocket(); } catch( SocketException se ) { se.printStackTrace(); System.exit( 1 ); } } public void waitForPackets() { while ( true ) { t ry { // set up packet byte data[] = new byte[ 1000 ]; receivePacket = new DatagramPacket( data, data.length ); // wait for packet socket.receive( receivePacket ); // process packet display.append( "\nPacket received:" + "\nFrom host: " + receivePacket.getAddress() + "\nHost port: " + receivePacket.getPort() + "\nLength: " + receivePacket.getLength() + "\nContaining:\n\t"); // new String( receivePacket.getData(), 0, // receivePacket.getLength() ) ); receiveData = new byte[receivePacket.getLength()]; receiveData = receivePacket.getData(); for(int i=0; i < receivePacket.getLength() ; i++){ display.append(Integer.toHexString(((int)receiveData[i] & 0xff)));


54


if(i%20 == 19) display.append("\n"); } display.setCaretPosition( display.getText().length() ); } catch( IOException exception ) { display.append( exception.toString() + "\n" ); exception.printStackTrace(); } } } public void actionPerformed( ActionEvent e ) { t ry { display.append( "\nSending packet containing: " + e . g e t A c t ionCommand() + "\n" ); String s = e.getActionCommand(); byte data[] = s.getBytes(); sendPacket = new DatagramPacket( data, data.length, InetAddress.getLocalHost(), 5000 ); socket.send( sendPacket ); display.append( "Packet sent\n" ); display.setCaretPosition( display.getText().length() ); } catch ( IOException exception ) { display.append( exception.toString() + "\n" ); exception.printStackTrace(); } } public static void main( String args[] ) { Client app = new Client(); app.addWindowListener( new WindowAdapter() { public void windowClosing( WindowEvent e ) { System.exi t ( 0 ); } } ) ; app.waitForPackets(); } private class ButtonHandler implements ActionListener{ public void actionPerformed(ActionEvent e) { String s = ""; if(e.getSource() == connect){ s = "Connect " + e.getActionCommand(); display.append(s); setConnect(); } else if(e.getSource() == disconnect) { connect(); s = "Disconnect " + e.getActionCommand(); } e lse i f(e.getSource() == enter) {


55


s = "Enter " + e.getActionCommand(); setEnter(); } else if(e.getSource() == verdual) { s = "VerDual " + e.getActionCommand(); verDual(); } else if(e.getSource() == verpay) { s = "VerPay " + e.getActionCommand(); verPayment(); } } } private void verDual(){ short retvalue[]; byte CLA,INS,P1,P2; int iArray[]; String s; // Digital Signature try { CLA = (byte)0x03; INS = (byte)0x34; P1 = (byte)0; P2 = (byte)0; display.append("\nDecription Dual Digital Signature\n"); int i; iArray = new int[128]; for(i=0;i<128;i++){ iArray[i] = receiveData[180+i] & 0xff; display.append(Integer.toHexString(iArray[i])); if(i%20 == 19) display.append("\n"); } display.setCaretPosition( display.getText().length() ); retvalue = new short[128]; retvalue = sCard.SendCardAPDU(CLA,INS,P1,P2,iArray,128); //1); int iErrorCode = sCard.GetLastErrorCode(); if (iErrorCode != 0x9000) { s=sCard.GetErrorMessage(); display.append("SendCardAPDU: " + s + "\n"); System.out.println(iErrorCode); } else { display.append("\nData Good\n"); if (retvalue != null) { System.out.println(retvalue.length); for( i=0; i<retvalue. length; i++){ display.append(Integer.toHexString((int)retvalue[i])); if(i%20 == 19) display.append("\n"); } display.setCaretPosition( display.getText().length() ); } }


56


} catch (slbException b) {s = b.getMessage(); display.append("Connect: " + s+ "\n");} // Order Information & Payment Information Hash try { CLA = (byte)0x03; INS = (byte)0x58; P1 = (byte)0; P2 = (byte)0; display.append("\nOrder Info & Payment Info Hash\n"); int i; iArray = new int[40]; for(i=0;i<40;i++){ iArray[i] = receiveData[140+i] & 0xff; display.append(Integer.toHexString(iArray[i])); if(i%20 == 19) display.append("\n"); } retvalue = new short[20]; retvalue = sCard.SendCardAPDU(CLA,INS,P1,P2,iArray,20); //1); int iErrorCode = sCard.GetLastErrorCode(); if (iErrorCode != 0x9000) { s=sCard.GetErrorMessage(); display.append("SendCardAPDU: " + s + "\n"); System.out.println(iErrorCode); } else { display.append("\nHash Data Good\n"); if (retvalue != null) { System.out.println(retvalue.length); f o r ( i=0 ; i< re tva lue.length;i++){ display.append(Integer.toHexString((int)retvalue[i])); if(i%20 == 19) display.append("\n"); } } display.setCaretPosition( display.getText().length() ); } } catch (slbException b) {s = b.getMessage(); display.append("Connect: " + s+ "\n");} } private void verPayment(){ short retvalue[]; byte CLA,INS,P1,P2; int iArray[]; String s; // Get RSA try { CLA = (byte)0x03; INS = (byte)0x32; P1 = (byte)0; P2 = (byte)0; display.append("\nRSA Private Key Decription of 3DES Key \n");


57


int i; iArray = new int[128]; for(i=0;i<128;i++){ iArray[i] = receiveData[339+i] & 0xff; display.append(Integer.toHexString(iArray[i])); if(i%20 == 19) display.append("\n"); } display.setCaretPosition( display.getText().length() ); retvalue = new short[128]; retvalue = sCard.SendCardAPDU(CLA,INS,P1,P2,iArray,128); int iErrorCode = sCard.GetLastErrorCode(); if (iErrorCode != 0x9000) { s=sCard.GetErrorMessage(); display.append("SendCardAPDU: " + s + "\n"); System.out.println(iErrorCode); } else { display.append("Data Good\n"); if (retvalue != null) { System.out.println(retvalue.length); display.append( "Return Data:\n"); fo r ( i=0 ; i<128 ; i++) { display.append(Integer.toHexString((int)retvalue[i])); if(i%20 == 19) display.append("\n"); } d i sp l ay . append ( " \n"); } } } catch (slbException b) {s = b.getMessage(); display.append("Connect: " + s+ "\n");} } private void setEnter(){ short retvalue[]; byte CLA,INS,P1,P2; int iArray[]; byte bArray[]; byte dataArray[] = new byte[468]; String OrderString, PaymentString; String PINString, s; PINString = new String(pinField.getPassword()); // Get RSA try { CLA = (byte)0x03; INS = (byte)0x3a; P1 = (byte)0; P2 = (byte)0; display.append("Get Card Holder's Public Key" + "\n"); int i; iArray = new int[0]; retvalue = new short[140]; retvalue = sCard.SendCardAPDU(CLA,INS,P1,P2,iArray,140); int iErrorCode = sCard.GetLastErrorCode(); if (iErrorCode != 0x9000) { s=sCard.GetErrorMessage(); display.append("SendCardAPDU: " + s + "\n");


58


System.out.println(iErrorCode); } else { display.append("Data Good\n"); if (retvalue != null) { byte sBytes[] = new byte[retvalue.length]; System.out.println(retvalue.length); for (i = 0; i < retvalue.length; i++) { sBytes[i] = (byte)(retvalue[i] & 0xff); display.append(Integer.toHexString((int)retvalue[i])); dataArray[i] = sBytes[i]; if(i%20 == 19) display.append("\n"); } } display.setCaretPosition( display.getText().length() ); } } catch (slbException b) {s = b.getMessage(); display.append("Connect: " + s+ "\n");} // try dual signature try { CLA = (byte)0x03; INS = (byte)0x36; P1 = (byte)0; P2 = (byte)0; display.append("Dual Signature" + "\n"); int i; iArray = null; retvalue = null; iArray = new int[60]; retvalue = new short[168]; OrderString = oI.getText(); int length = OrderString.length(); if(length == 0) { display.append("Enter Oder Information\n"); return; } iArray = new int[60]; //byte bArray[]; bArray = OrderString.getBytes(); if(length < 30) { for(i=0;i<length;i++) iArray[i] = (int) bArray[i] & 0xff; for(;i<30;i++) iArray[i] = 0; } else { for(i=0;i<30;i++) iArray[i] = (int) bArray[i] & 0xff; }


59


PaymentString = pI.getText(); length = PaymentString.length(); if(length == 0) { display.append("Enter Payment Information\n"); return; } bArray = PaymentString.getBytes(); if(length < 30) { for(i=0;i<length;i++) iArray[30+i] = (int) bArray[i] & 0xff; for(;i<30;i++) iArray[30+i] = 0; } else { for(i=0;i<30;i++) iArray[30+i] = (int) bArray[i] & 0xff; } retvalue = sCard.SendCardAPDU(CLA,INS,P1,P2,iArray,168); int iErrorCode = sCard.GetLastErrorCode(); if (iErrorCode != 0x9000) { s=sCard.GetErrorMessage(); display.append("SendCardAPDU: " + s + "\n"); System.out.println(iErrorCode); } else { display.append("Data Good\n"); if (retvalue != null) { byte sBytes[] = new byte[retvalue.length]; System.out.println(retvalue.length); for (i = 0; i < retvalue.length; i++) { sBytes[i] = (byte)(retvalue[i] & 0xff); dataArray[i+140] = sBytes[i]; display.append(Integer.toHexString((int)retvalue[i])); if(i%20 == 19) display.append("\n"); } display.setCaretPosition( display.getText().length() ); } } } catch (slbException b) {s = b.getMessage(); display.append("Connect: " + s+ "\n");} // Key Encription try { CLA = (byte)0x03; INS = (byte)0x38; P1 = (byte)0; P2 = (byte)0; display.append("Key Encription" + "\n"); int i; // Payment Information iArray = null;


60


retvalue = null; iArray = new int[30]; retvalue = new short[160]; for(i =0; i < 30;i++) iArray[i] = 0xaa; retvalue = sCard.SendCardAPDU(CLA,INS,P1,P2,iArray,160); int iErrorCode = sCard.GetLastErrorCode(); if (iErrorCode != 0x9000) { s=sCard.GetErrorMessage(); display.append("SendCardAPDU: " + s + "\n"); System.out.println(iErrorCode); } else { display.append("Data Good\n"); if (retvalue != null) { byte sBytes[] = new byte[retvalue.length]; System.out.println(retvalue.length); for (i = 0; i < retvalue.length; i++) { sBytes[i] = (byte)(retvalue[i] & 0xff); dataArray[i+140+168] = sBytes[i]; display.append(Integer.toHexString((int)retvalue[i])); if(i%20 == 19) display.append("\n"); //System.out.print(i + ":" + sBytes[i] + " "); } display.setCaretPosition( display.getText().length() ); } } } catch (slbException b) {s = b.getMessage(); display.append("Connect: " + s+ "\n");} try { display.append( "\nSending packet\n" ); //String s = e.getActionCommand(); //byte data[] = s.getBytes(); sendPacket = new DatagramPacket( dataArray, dataArray.length, InetAddress.getLocalHost(), 5000 ); socket.send( sendPacket ); display.append( "Packet sent\n" ); display.setCaretPosition( display.getText().length() ); } catch ( IOException exception ) { display.append( exception.toString() + "\n" ); exception.printStackTrace(); } } int iAID[] = {0x11,0x11,0x11,0x11,0x11,0x11}; private void setConnect(){ short retvalue[]; byte CLA,INS,P1,P2; int iArray[]; byte bArray[]; String PINString, s; PINString = new String(pinField.getPassword());


61


if(connect()) { iArray = new int[4]; try { CLA = (byte)0x03; INS = (byte)0x40; P1 = (byte)0; P2 = (byte)0; int length = PINString.length(); if (length != 8) display.append("Length must be 8.\n"); else { display.append("String PIN" + PINString + "\n"); for (int i = 0; i < 4; i++) { s = PINString.substring(i*2,(i*2)+2); iArray[i] = Integer.valueOf(s, 16).intValue(); System.out.println(iArray[i]); } display.append("Validating PIN...\n"); sCard.SendCardAPDU(CLA,INS,P1,P2, iArray,0); int iErrorCode = sCard.GetLastErrorCode(); if (iErrorCode != 0x9000) { if (iErrorCode == 0x6BBB) display.append("Wrong PIN\n"); else { s=sCard.GetErrorMessage(); display.append("SendCardAPDU: " + s + "\n"); System.out.println(iErrorCode); } } else { display.append("PIN Validated...\n"); } } } catch (slbException b) {s = b.getMessage(); display.append("Connect: " + s+ "\n");} } } public boolean connect() { boolean bRet; String s; int numReaders; String rs[] = null; rs = sIOP.ListReaders(); if (!sIOP.Connect(sCard, rs[0],false)) { display.append("Unable to connect to card.\n"); return false; } try { display.append("Connected. Selecting root\n"); bRet = sCard.SelectCardlet(iAID); if (!bRet) { s=sCard.GetErrorMessage();


62


display.append("SelectCardlet: " + s + "\n"); return false; } else { display.append("Cardlet selected!\n"); } } catch (slbException b) { s = b.getMessage(); display.append("Connect: " + s + "\n"); } return true; } }


63


RReeffeerreennccee

1. Cyberflex Access Software Developer’s Kit Guide 2. Cyberflex Access Programmer’s Guide 3. A developer’s Guide to Schumberger Smart Card Middlerware 4. Schlumberger Reflex 72 Installation Manual 5. Java Card Forum http://www.javacardforum.org 6. “How to write OpenCard card services for Java Card applets” http://www.javaworld.com/javaworld/jw-10-1998/jw-10-javadev.html 7. Schlumberger User Discussion Forums http://www.flexfrum.com 8. Smart Card Application Development Using Java, Uwe Hansman, Martin S. Nicklous,

Thomas Schack, Frank Seliger 9. Protocols for Secure electronic Commerce, Mostafa Hashem Sherif, CRC Press, 2000 10. Java Card technology for smart cards: architecture and programmer's guide, Chen Zhiqun,

Addison-Wesley, 2000 11. http://ktwww.kotel.co.kr/smart/ 12. http://www.smartcardcentral.com

developing and applying to set with java-cardcaislab.kaist.ac.kr/lecture/2001/spring/ice525/... ·...

Documents