The Secure and Multiple Payment System Based on the Mobile Phone Platform
(Preliminary version)
Q. Zhang, J. N. B. Moita, K. Mayes and K. Markantonakis
Smart Card Centre Information Security Group, Royal Holloway, University of London {q.zhang, j.n.brites-moita, keith.mayes, k.markantonakis}@rhul.ac.uk
Abstract. In this paper, a secure proximity payment system based on the characteristics of the mobile phone is proposed. By combining the convenience and portability of the mobile phone with the strength of on-card-matching fingerprint authentication and public key infrastructure, we constructed a powerful, secure and practical payment system for both micro and macro payment methods. The first method is a simple, fast and efficient method for an electronic purse transaction whilst the second is aimed at higher value transactions such as credit card purchases.
1 Introduction
Payment methods have evolved from the physical exchange of notes and coins, to writing checks, through to transferring payment card details either in person, over the phone or the Internet. This evolution has involved a shift from the physical transference of tangible tokens of value to an exchange of information between parties. The introduction of e-commerce has further digitized the payment process, whereby payment details are sent over open networks with no physical contact between the buyer and the seller. This has evolved still further with the concept of mobile transactions referred to as m-commerce. The recent development of high-speed mobile phone networks has greatly enhanced this new channel for commerce, while more sophisticated mobile devices are enabling the virtual exchange of payment information known as proximity payments. Although the shift from physical to virtual payments has brought enormous benefits to consumers and merchants, it has put extra pressure on payment service providers, including banks, card companies and also mobile phone operators, to provide more robust security for their payment systems. Therefore the drive to develop a trustworthy and practical payment solution has become a high priority for these parties. In seeking this solution, we must examine the core technical and business needs for successful mobile payments and three principal requirements stand out, namely security, convenience and efficiency. Security: Security is paramount. An insecure payment system will not be acceptable to both merchants and customers. Usually, the security requirements can be considered as four main elements i.e.
2
Authentication: allows the payment provider (that is, the issuer) to determine that the person using the payment product is the authorized user. Confidentiality: ensures that unauthorized parties do not have access to sensitive payment data that might be used later for fraudulent purposes. Data integrity: ensures that payment data is not altered after the time the user agrees to the terms of the transaction. Non-repudiation: binds the parties to the transaction so that they cannot later deny their participation. Convenience: Research has shown that consumers are attracted to products and services that are simple to use and do not require major shifts in habit. Any mobile payment system must fulfill these requirements. Efficiency: The efficiency depends on the computation time and resources for each subprocess as well as the cost of the payment. The transaction time is particularly crucial for the customer who will not tolerate a long wait to complete a payment process. Increasing the number of parties involved in the payment process or over complicating the process will also adversely influence the speed and cost of the system. The objective of this paper is to propose and critically review a mobile proximity payment system, satisfying above requirements. The remainder of this paper is organized as follows: Section 2 presents some background and justification to our work and briefly reviews essential technologies and components that are exploited within the proposed system solution. Section 3 comprehensively describes our proposed payment system. Section 4 provides details of the practical implementation. Finally, we provide some concluding remarks and directions for further research.
2 Background and Justification
In the early stages of this work it was necessary to consider whether there would be interest in its conclusions and whether there were in reality system components that could be adapted and exploited to develop a biometrically enabled mobile payment solution. The following sections summarize the justification for the work and the critical system components that were identified. 2.1 Biometric Enabled Mobile Payment Mobile telecommunications continue to be phenomenally successful with an estimated one billion mobile subscribers [1]. It is an easy and convenient way to communicate with others and being accessible 7 days a week, 24 hours a day, no
The Secure and Multiple Payment System Based on the Mobile Phone Platform
3
matter where you are. There are more mobile phones than internet connected PCs. The success of NTT DoCoMo’s i-mode service in Japan, which currently has 34 million data subscribers [2], illustrates the appetite of the mobile phone operators around the world to develop value-adding m-payment services. The mobile phone operators have the desire to play a major role in the mobile payment field however due to current technical, commercial and process concerns they are mainly restricted to micro-payment style services. With the increased risk from terrorism, mobile terminal manufacturers have become especially interested in biometrics. NTT DoCoMo, Inc of Japan released the MOVA F505i phone with fingerprint sensor in July 2003, and a number of successors are expected shortly. Yasuo Katsura, president and member of the board of Panasonic Mobile Communications Co, Ltd of Japan, for example, is confident: "Biometric recognition functions are essential in mobile phones. They will be commonplace in the near future."[3].With the lower price and smaller size, it is possible that biometric Enabled Mobile may finally begin to be prosperous in the near future. 2.2 Technology Background Having determined that the mobile industry is still looking for secure m-payment solutions and that new terminals will incorporate advanced functionality such as fingerprint readers, we need to identify other system components that could form part of our secure system such as smart cards and biometrics. Smart cards are essentially a small processor with a highly controlled interface to the outside world (they have just one serial line over which a well defined protocol runs). This, coupled with hardware tamper resistance, makes the smart card an ideal secure token for many security related applications, such as access control, banking and telecoms. To adapt a smart card for our purposes we need a programming and execution environment such as provided by a Java card. A Java card is simply a smart card containing a limited java platform. The Smart card applications running on Java cards are called applets which can be developed using widely available java development tools. Modern Java Cards include powerful security functionality such as DES, 3DES, RSA, message digest, signatures, etc. Fortunately, within every GSM mobile there is a type of smart card called a SIM (Subscriber Identity Modules). Many modern SIMs are now Java cards providing us with a suitable platform for elements of our payment solution. It should be noted that the SIM card is controlled by the network operators which can be restrictive, however it does avoid the free-for-all situation that exists with personal computers, where malicious code can be installed all too easily. Biometrics implies the verification of a person’s identity using a unique characteristic that is inherently attached to the respective person. Such characteristics can be physiological (e.g. fingerprints) or behavioral (e.g. dynamic signature or voice sample). In contrast to existing methods using secret keys, or
4
PIN codes, the biometric identification checks not only the possession of a security token, but also whether it is held by the legitimate user. Thus, biometrics is the first method to perform “real” personal identification. Generally a biometric system consists of a series of subsystems that includes subsystems for data collection, signal processing, matching, storage and a decision making [15]. The choice of biometric is critical and needs to consider not only security and technical issues but also user acceptance and long-term stability [14].
3 The Proposed M-Payment System
In this section, we propose the detail of our system along with the implementation details and two payment methods of system. 3.1 Initial Assumptions & Design Goals This project assumes that the customer already has his/her credit card information stored on the SIM Card or has pre-loaded money into e-Purse on the mobile phone via some means. The details of these processes are outside the scope of this paper. During the design process, we kept in mind the following main points: - Analyze the significance of using mobile equipment in the payment field - Give choices on payment method to realize both micro and macro payment - Provide a secure solution for the payment system - Minimum changes to the shopping habits of customers - Provide a convenient payment method to take the place of traditional payment. - Evaluate the practicality of a java card based approach 3.2 Targeted Advantages In our system, the payment process is realized off-line, hence no connection is needed between the merchant and the mobile phone operator during the payment process, which not only decreases costs but also greatly reduces the process time. For reason of efficiency, cost and ease-of-use the solution does not require a bank or financial entity to be involved in each transaction, which controversially suggests that a mobile phone operator might take the place of financial institution and enter the payment application area. Fingerprint recognition is employed in our system to verify the identity of the user, which is a practical method of protecting the sensitive personal information stored in the SIM card. Moreover, on-card-matching of fingerprint is developed in our system, which means that the sensitive biometric template data is never read out of the SIM card. Thus keeping the data secure against eavesdropping and the matching process protected against falsification.
The Secure and Multiple Payment System Based on the Mobile Phone Platform
5
3.3 The Entities Involved 3.3.1 Payment Applet in the SIM Card (PA) We have designed and implemented a Payment Applet module (PA) inside the SIM card, which is a separate applet using the java card technology inside the SIM card to realize the function of payment. This module is the key entity to realize the payment function. After the successful authentication of the user in the overall system, the mobile phone (MP) sends a message to this applet requesting either the credit card information or a debit order from the e-purse according to the APDU command [4]. In our system, in order to keep user’s personal sensitive information – such as credit card number – secure, we use a PKI-based system, encrypting sensitive information under the merchant’s public key (detail is given on 3.3.6) when it is read out from the SIM card. Since the encryption is processed by the payment applet inside the SIM card, no party can get the plaintext except the merchant with the corresponding private key, which means that even the mobile phone can not decrypt the information, hence providing end-to-end encryption between the SIM card and the merchant. Another thing worth mentioning about our system is the storage of the public key. The merchants’ public-key certificate is stored in the mobile phone due to the limited capacity of SIM card. The capacity of a proper X.509 certificate [5] is about 1k bytes, which is much greater than the size of the command APDU data buffer [4]. Consequently, a complete certificate has to been sent to the Payment Applet by a series of APDUs command. In our implementation, we use 4 APDUs command to send a certificate from the mobile phone to the PA and then the PA will concatenate the data from 4 APDU command to reconstruct the X.509 certificate. 3.3.2 Separate Bio-Applet in the SIM Card (BA) One of the key entities of our system is the so called Bio-Applet, loaded inside the SIM. Since the SIM card contains confidential information, such as credit card data, or data bound to the e-purse, the role of the Bio-Applet is to guarantee that this information can only be accessed if the legitimate phone holder is successfully authenticated. This is achieved by combining the use of the mobile phone and a biometric device, as described in section 3.3.4. The idea is that applets installed on the SIM card can only send information to the requestor if previously authorized by the Bio-Applet. In order to do this, the Bio-Applet must receive fresh biometric data from the mobile phone. We assume that the user has already stored his/her fingerprint template data inside the card when the applet was created by the mobile phone operators. A key feature of our system is that we use an on-card-matching process to realize fingerprint authentication. Once the mobile phone acquires the live
6
biometric information of the current user and processes it, it will send this processed fingerprint data to the Bio-applet in the SIM card via an APDU [4] command, afterwards the Bio-applet will be responsible to make the comparison between the live fingerprint data with the original template stored on it. Subsequently, the successful or unsuccessful authentication result will be returned to the mobile phone (PA) via APDU [4] command and the payment applet (PA) via a call to the shareable interface method [7]. The reason for our system to return the result to the payment applet is to prevent a malicious APDU command asking for the sensitive information from the payment applet. If the payment applet isn’t aware of any authentication result from the Bio-applet provided via the shareable interface object, which can be considered as a secure channel, any APDU request for the data will be regarded as invalid. 3.3.3 Mobile Phone (MP) In this section, we will explain the entity implemented in the mobile phone, excluding the fingerprint sensor and the SIM card. The role of this entity is to process incoming requests from third party applications, and communicate with the appropriate modules of the framework in order to retrieve, in a secure way, the information requested. The components in the mobile phone were implemented in Java – J2ME 2.1 [18]. Once again, the Java technology was chosen because of its portability; it is a powerful and mature programming language. Most of the new mobile phones released nowadays came with a Java Virtual Machine (JVM) [11, 12] in order to support Java applications. The existence of the JVM, provides the developers the possibility of developing an application independently of the hardware that will run the code – it’s the write once, run everywhere property provided by Java technology. As explained in more detail on section 3.3.5, the messages exchanged between the mobile phone and third party applications (merchant) are XML messages [23]. This means that incoming messages must be parsed in the mobile phone. This is in fact the first thing to do once a new message arrives, which means that a parser must be available. Unlike J2SE, J2ME does not come with an XML parser, however there are currently some implementations of light versions of XML parsers made specifically to be used within mobile phones. Our choice was for KXML2 [16], an open source parser originally developed by Enhydra but maintained now by KObjects [16]. KXML2 is a small XML pull parser, specially designed for constrained environments such as Applets, Personal Java or MIDP devices, and is based on the common XML pull API [17]. Figure 1 represents the architecture developed in the mobile phone.
J2ME Presentation Layer Sensor
Bio Data
Bio Classes JavaCard XML Parser
Incoming XML message Outgoing XML message 3rd Party App.
SIM Card
Business Layer classes
Data Layer
X.509 Cert
The Secure and Multiple Payment System Based on the Mobile Phone Platform Fig. 1. The MP architecture
7
The mobile phone’s module, acts as a coordinator; it is the entity that controls what needs to be done next. It was designed as 3-layer architecture – presentation layer, business layer and data layer. The first layer consists basically of a set of MIDlets [18] with which the user needs to interact (for example to confirm some operation that is about to be completed, or just to give some instructions to the user, like asking him/her to authenticate identity via biometric sensor device); the data layer is a set of classes that have access to the certificates stored on the handset, and on request, can pass the certificate information to the business layer, which will know what to do with that information; last, but not least, the business layer is where everything happens i.e. where decisions are made accordingly to the request made. This layer itself can be divided in three different components: XML parser component, communication component and business component. The XML parser component just parses an incoming message. It checks for its correctness (according to the XML schema [22] as defined in section 3.3.5), and passes the information parsed to the business component. Also, this component is responsible for constructing an XML message (outgoing XML message) based on data received from the business component. The communication component consists basically of a set of classes to communicate with both the fingerprint sensor device and the SIM card. To make use of the capabilities of the Java programming language, both the communication classes with the biometric device and the SIM card are defined using Java interfaces. This provides a way of implementing the same classes for different vendors with a minor impact on the overall framework. The business component is the “brain” of this module. Its role is to analyze data received from the XML parser component, and make decisions accordingly. For example the decisions can request the user to authenticate identity using the fingerprint device, in which case, some information must be presented on the screen of the mobile phone prompting the holder to use the sensor, as well as invoking the appropriate classes that are able to communicate with the biometric device. This component also provides a link between the data layer and the business layer, and decides what information is needed to be passed to the SIM. 3.3.4 The Fingerprint Sensor (FS)
User input
FS
Acquired raw data
Processing
Extracted features Matching
BA in SIM
Template
Mobile Phone
Retune result
Fig. 2. The Biometric Module
Figure 2 shows how biometrics is ideally fitted in this project. The fingerprint sensor is an important part of our payment system, by which the raw fingerprint is collected. In this process, the mobile phone acts as the data collection and the signaling processing subsystems. It starts by acquiring raw biometric data from
8
the fingerprint sensor at the beginning of the transaction with the third party. Then the raw fingerprint data is processed in the mobile phone. After that, the extracted features are sent to the SIM card via an APDU [4] command. The Bio-Applet has the responsibility of matching the acquired sample with the user’s stored template and makes a decision accordingly. The result of the matching is sent back to the mobile phone for further action. 3.3.5 The Third Party’s Application (TPA) The communication between third party applications and the mobile phone is done via XML [23] messages. The reason to use XML is due to the fact that it is currently the de facto standard for message interchange between applications which makes it easier for third party applications to integrate with the mobile phone. Also because XML is platform and technology independent, hence third party applications are not forced to use Java; in fact they can be developed using whichever available technologies as long as there is an XML parser available for it, which is nowadays available for almost every programming language. Since the exchange XML messages will most likely, contain confidential information, we need to make sure it is appropriately secured. In order to do that, we make use of the standards XML-encryption [20] and XML Digital Signatures [21], to protect the sensitive fields within the XML message. The level of protection required depends on the type of application and corresponding messages sent from the third party applications to the mobile phone. The XML messages are defined according to an XML Schema (XSD) [22]. There are two different XSDs to define each incoming and outgoing messages. Both of the schemas were designed to be application independent. The incoming XSD basically defines the parameters to be retrieved from the SIM card, the input parameters and an associated set of security parameters. The level of security can be one of the following: information signed with a third party’s private key, encrypted with third party’s public key, a combination of both or no security at all. Different level of confidentiality can be defined for input and output parameters. The level of authentication required is also defined in the incoming message and can be one of the following: biometric, PIN, a combination of both, or none. There is also the possibility to include a nonce in the XML message to guarantee the freshness of the message. All these security fields are signed by the third party. The outgoing XML message, also defined according to a XSD [22], contains the parameters requested in the incoming message. From the framework point of view, these parameters can be of any type. i.e., the framework just appends the information retrieved from the applet associated with the third party application to an element in this message. It is the responsibility of the applet to protect the information sent, either with the key provided by the Bio-Applet or with another self-generated key.
The Secure and Multiple Payment System Based on the Mobile Phone Platform
9
3.3.6 Key Centre of Mobile Phone Operator (KC) In order to run the whole project properly and efficiently, our system includes a Key Centre (KC), for which the mobile phone operator is responsible. The KC should consist of a set of policies, procedures and services to support applications that exploit both asymmetric and symmetric key cryptography. The operational issues include how keys should be managed, how to issue and organize the symmetric key for the subscriber and how a specific user’s public key is made available to others. KC could therefore be split into the following components: − A Security Policy (SP): It details the operation of the various components and essentially forms the framework for the infrastructure. It defines the procedures for key generation, issuance, storage and revocation. − A Registration Authority (RA): It is a trusted organization that is responsible for providing the authority to the third party applications (merchant). When a merchant wished to realize the payment function using the mobile phones of a particular mobile operator, he/she must first get the authority from the Registration Authority. The authorized merchant would need the connection equipment, consisting of a mobile phone, card reader and the merchant’s identity smart card, which serves 3 functions: 1: The merchant’s identification card. 2: The secure media to store the merchant private key (issued by CA), which is used to decrypt the message received from the customer during the payment. 3: The media to store the transaction log data. For the e-purse payment method, the merchant card is used to store the transfer record which is subsequently sent to the mobile phone for settlement. − A Certificate Authority (CA): It is a trusted organization that is responsible for managing key generation, issuance, storage and revocation. In our system concept, the certificate authority could also provide the issuance of symmetric keys (detail is given on section 3.5.2) for the mobile phone subscribers. − A Directory Service (DS): It is the Directory Service. This acts just like a telephone directory holding two lists. One of them is the list of the mobile phone subscribers and their corresponding symmetric key; the other is the list of the merchants and their corresponding public keys. This component also provides a valid and convenient channel for subscribers to download certificates of desirable merchants. Once the mobile phone user successfully downloaded a specific merchant’s certificate, he/she can conclude payment transactions using the mobile phone method. 3.4 Implementation Details In figure 3 we present a comprehensive architecture for our project. The following protocol takes place upon the reception of an XML message from third party application in the mobile phone. N is a nonce (so TPAN is a nonce sent by the merchant, and MPN is a nonce sent by the mobile):
10
Mobile Phone (J2ME) User Input Bio Sensor 3rd Party Apps: J2SE / .NET / ??
Presentation Layer
Bio Classes
SIM Card
=?
Bio
Bio-Applet
Payment Applet
APDU Packets
Java Card Classes Business Layer classes
XML(-Sec)
Merchant PC Application
APDU Packets
XML Parser
Symm key
Credit Card payment
e-Purse payment
X.509 Cert.
Data Layer
…
X.509 Cert.
Merchant card
Fig. 3. Architecture of the framework
TPA MP BA IF BIO RESULT==TURE MP PA MP PA: GET_INFO_REQUEST || TPA_PUB_K MP: {INFO} TPA_PUB_K TPA: XML MP: XML || {TPAN} TPA_PRIV_K BA: MP: MPN || BIO_DATA MPN – 1 || BIO_RESULT IF BIO_RESULT==FALSE BREAK
So, in this protocol run, (2) the merchant sends an XML message requesting payment information stored in the customer’s SIM card. Also, in that XML a nonce is used to guarantee the freshness of the message. (3) After receiving the XML message, the mobile phone parses it and checks what to do next. (4) If biometric authentication is required, then the mobile phone will instruct the user to submit his/her biometric data by using the fingerprint sensor. (5) The raw fingerprint data is then sent to the mobile phone by the sensor and is processed to get the extracted feature data (6) su bsequently, the processed feature data plus a new nonce is forwarded to the Bio-applet in the SIM card by the mobile phone to realize the matching. (7) The Bio-Applet then matches the biometric data with the user fingerprint template stored in the SIM and then, if they match, it returns the result to the mobile phone. If successful, the mobile can continue to process the transaction. So, in the next step, the mobile phone retrieves the merchant’s certificate and (8) then starts sending the payment request and merchant certificate via APDU [4]’s to the payment applet of the SIM card(9) which then retrieves the requested information and encrypts it under the merchant’s public key. (10)When the mobile phone receives encrypted data which it cannot decrypt (since it doesn't know the merchant's private key), it generates an outgoing XML
The Secure and Multiple Payment System Based on the Mobile Phone Platform
11
message containing the encrypted data and sends it to the merchant application. The merchant is the only party who knows the value of the private key and so is the only party that can decrypt the information. The figure.4 shows the process flow in a more detail.
User TPA 1. Initialize protocol MP 2.Request ||{Nonce} Priv_k 3. Request biometric data 4. Fingerprint collection 5. Raw biometric data 6. Extracted features: Biometric data ||{Nonce} 7. Biometric matching result ||{Nonce-1} 8. Payment Request || Merchant Priv_k 9. {Response} Merchant Pub_K 10. {Response} Merchant Pub_K FS SIM Card
Fig. 4. Detailed diagram of the protocol run
3.5 Choice of Payment Method Mobile payments can be divided into macro and micro payments. A micropayment refers to a payment of up to say £10 while macro-payments refer to larger values such as online shopping. The distinction between the two types of payment is important since the security required for each will be different. For example, authentication for every macro-payment transaction through a trusted financial entity is extremely important, whereas network authentication, such as SIM card authentication, may be sufficient for micro-payments that only use the operator’s infrastructure. In our system, we set £10 as the baseline to distinguish between micro and macro payments. That means that the third part application (merchant) will provide the request for either credit card payment or e-purse based on the amount spent by the customer. An e-purse is created by the mobile phone operator who is the entity responsible for micro payments. (The credit top-up process isn’t considered here) We assume that the customer’s mobile phone already has access to a merchant’s certificate, e.g. methods include; 1: When the customer downloads the payment application to his/her SIM card, he/she can also request which authorized shops’ certificates he/she wants to install on the mobile phone in order to enable the payment function. The mobile phone
12
operator would be responsible to provide these certificates to the customers. 2: User also can download the certificate by SMS in order to keep the list of authorized shops updated. 3.5.1 Credit Card Payment 1: A customer goes to an authorized shop whose certificate we assume is already available on the customer’s mobile phone. When the customer goes to the point of sale, the merchant connects the PC with the customer’s mobile phone using the connection equipment provided by the KC of mobile phone operator and requests for credit card information. The mobile phone will firstly ask the user to authenticate his/her identity by using the fingerprint sensor. After the successful authentication, the mobile phone will send an APDU command [4] to the SIM card asking for credit card information. Then, the SIM card will send a message encrypted under the merchant’s public key to the mobile phone, which is then forwarded to the merchant’s PC. The message includes the following information: {Credit card’s type, credit card holder’s name, the credit card’s number, the expire date of credit card} by merchant’s public key 2: After the reception of the relevant credit card information from the customer’s mobile phone, the merchant PC sends the encrypted data to the merchant’s card via APDU commands [4] and then the merchant card decrypts the customer information using merchant private key stored in the card. Subsequently, the credit card information can be read out and the payment process can be concluded 3.5.2 Electronic Purse 1: First of all, we assume that the e-purse has been created when the mobile phone operator uploads the payment application to the customer’s mobile phone. The user can realize the transfer from the mobile phone account to the e-purse via SMS, internet, telephone or in person. We also assume that the mobile phone operator has issued a symmetric key for every subscriber (detail is given on section 3.3.6), which should be stored on the SIM Card. 2: When the customer goes the point of sale, the merchant connects the PC to the customer’s mobile phone and requests to debit a certain amount from the e-Purse. 3: The mobile phone will then ask for the biometric authentication of the user. After the successful user authentication and after the user confirms the value to be debited, the mobile phone sends an APDU command [4] to the SIM card to debit the amount from the e-purse. If the debit is successful, the SIM card will then return the correct APDU command [4] to inform the mobile phone that the debit process took place successfully and also provide a message with the amount debited – encrypted under a symmetric key shared between the user and the network operator – plus the customer’s phone number i.e.; Message including:
The Secure and Multiple Payment System Based on the Mobile Phone Platform
13
{Amount} by symmetric key + customer’s telephone number 4: When the merchant receives the message from the customer’s mobile phone, he/she forwards it directly to the merchant card via an APDU command [4]. Subsequently, at any time after the transaction, the merchant can take his/her merchant card to the mobile phone operator and ask for the settlement of all the transaction records in the card. Eventually, the mobile phone operator decrypts the messages from the merchant card using the customer symmetric keys based on the customer’s telephone number and then processes the financial settlement
4 Practical Implementation
To assess the practicality of the proposed solution it was decided to carry out a partial practical implementation. The J2ME Wireless Toolkit 2.1 (WTK 2.1) [18] was used to compile the module for use in a mobile phone. WTK 2.1 comes with a mobile phone emulator which we used to test the integration of our application with both the fingerprint sensor and the third party application. In order to test our system’s functionality we used three different devices i.e. a mobile phone emulator, a fingerprint sensor, and a JavaCard reader / writer. The fingerprint sensor FingerTIPTM, and SDK was sourced by Infineon[25]. The communication with the device is done by making use of Vtapi and Fapi [24, 25] libraries provided by the evaluation package kit. These libraries implement the functions needed to acquire raw data, compare biometric data with a template stored previously, as well as functions to initialize the device, closing the connection to the device. So, in our system we use the aforementioned libraries to capture process and verify the validity of biometric data. We’ve also developed an application to act as a merchant, which sends XML messages to the mobile phone emulator and waits for a response. The third party application was developed in Java (J2SE 1.4.2) [19]. The tests performed included: − Sending a message from a third party to the mobile phone − According to the contents of the XML message received on the mobile phone, ask the user to authenticate fingerprint using the biometric sensor and send a request to the applet of SIM card in order to retrieve the information included in the incoming request. − Make sure the aforementioned information is sent in a secure way. In order to do this, the mobile phone must have access to a certificate bound to the third party and send some information to the SIM card (like the public key) − Guarantee that information stored on the SIM card is only accessed after the user is authenticated − Generate an XML message on the mobile phone and send it back to the merchant The PC development platform/environment was a Pentium Centrino 1.5 Ghz with 512 Mb of RAM; JBuilder9 was used as a development tool to develop all
14
the modules in Java; .NET 2003 was also used in order to make the libraries provided by infineon’s FingerTIP TM[25] accessible via JNI. On the other hand, we also generated a set of results for the APDU [4] communication between the mobile phone and the SIM card, then between the merchant PC payment application and merchant card. The card that we used was the STARSIM® java card from the G&D [6], which is specifically designed for the development of GSM java card application. Accordingly, we also used the G&D STARSIM Developer Suite [5] as our smart card application development tool, whose merit is that it provides convenient debugging and testing of Java Card applets. Moreover, it has the good performance of communicating with an external program via TCP/IP (e.g., mobile simulator). For this purpose, a TCP/IP server socket interface is integrated based on the VOP Socket Definition (Version 1.1, April 1998). To test the applets on the simulated GSM Java Card of our system, management tags and command APDUs can be sent via this additional communication path. The development environment was a 2.4GHz P4 windows machine with the UltraEdit editor for Java programming, JDK 1.2.2[7] and Java Card API 2.1.1[8, 9, 10].
5 Conclusion and Further Work
Nowadays, not only research groups but also industry bodies all agree that there is enormous potential for mobile payments. However, we still have a long way to go if we want to develop the mobile phone payment market to be a fully trusted, mature transaction environment. Our goal in this paper has been to practically apply good security and biometric practices which may help encourage the mobile payment solution for enhanced security, interoperability, simplicity, and low costs of deployment. According to the combination of mobile phone with the biometrics and PKI system, and also according to the integration of micro and macro payment methods, we proposed a proximity m-payment system. The implementation presented on this paper was successfully implemented, although it wasn’t tested in a real environment. We wish our work can help to provide both customers and
mobile phone operators new payment opportunity.
One outstanding question is how best to distribute merchant certificates according to the need of the user. We think that SMS is a potential solution however one difficulty is the limited payload of SMS (140 bytes) whereas the normal capacity of the X.509 certificate [5] is about 1K bytes. As a result, SMS message concatenation techniques could be used whereby larger message can be used, that are transported in several segments, and re-assembled by the recipient’s mobile phone. SMS can also be used for the user to manage the transfers between the mobile phone account and the e-purse. For this purpose, the SMS encryption should be considerate due to the transportation of sensitive data.
The Secure and Multiple Payment System Based on the Mobile Phone Platform
15
Moreover, there is another considerable excitement surrounding proximity payments, a means of wireless technologies and standards such as Bluetooth, infrared and radio frequency identification (RFID) that will enable consumers to send transaction data from a mobile device to a point of sale terminal without physical contact. Last but not least, since the m-payment system is intended to transmit and access to secure transaction data that is stored in a potentially insecure device (mobile phone), thus the development of embedded biometrics chip in mobile phone also is a valuable research direction.
References
The Universal Mobile Telecommunications Service (UMTS) Forum. 2003 Hiroki Yomogita. Technology Analysis: Biometrics Safeguards Mobile Gear, Bank Cards. 2004. Http://neasia.nikkeibp.com/nea/200401/comnet_283391.html [3] NTT DoCoMo. 2004. http://www.nttdocomo.co.jp/english/index.shtml [4] International Standards Organization. ISO/IEC 7816-4, Information technology Identification cards - Integrated Circuit(s) cards with contacts – Interindustry Commands for Interchange. International Organization for Standardization, 1995 [5] ITU-T Recommendation X.509. Information Technology - Open Systems Interconnection The Directory: Public-key and attribute certificate frameworks. June 1997 [6] Giesecke & Devrient. Getting Started With StarSIM Developer Suite. G&D June 2002 [7] Michael Montgomery and Ksheerabdhi Krishn. Secure Object Sharing in Java Card. USENIX, 1999 [8] Sun Microsystems. Java Card 2.1.1 Application Programming Interface, Revision 1.0. May 2000 [9] Sun Microsystems. The Java Card 2.1.1 Runtime Environment (JCRE) Specification, Revision 1.0. May 2000 [10] Sun Microsystems. The Java Card 2.1.1 Virtual Machine Specification, Revision 1.0. May 2000 [11] Dalheimer, Kalle. Java Virtual Machine. O’Reilly 1997 [12] Lindholm,Yellin. The Java Virtual machine Specification. Addison-wesley,1996 [13] Java Card Developer’s Guide Version 1.12. Sun Microsystems, Inc.2003 [14] Simon Liu, Mark Silverman. A Practical Guide to Biometric Security Technology.IEEE Computer Society, IT Pro - Security, Jan-Feb [15] Scarlet Schwiderski-Grosche. An overview of biometrics – Presentation for RHUL. 2003 [16] KObjects.org, kXML2 Project, http://kxml.enhydra.org/ [17] XML Pull.org.Common API for XML Pull Parsing. http://xmlpull.org [18] Sun Microsystems. Java2 Platform, Micro Edition (ME) Wireless Toolkit. http://java.sun.com/j2me/docs/j2me_wireless_toolkit.pdf [19] Sun Microsystems. Java2 SDK Standard Edition Documentation. http://java.sun.com/j2se/1.4.2/docs/index.html [20] W3C.XML Encryption WG.2001, http://www.w3.org/Encryption/2001/ [21] W3C.XML Signature WG.http://www.w3.org/Signature/ [22] W3C. XML Schema WG. 2003, http://www.w3.org/TR/xmlschema-1/ [23] W3C. Extensible Markup Language (XML). http://www.w3.org/XML/ [24] Veritouch. Software Development Kit for USB Smartcard reader with Integrated FingerTIPTM Sensor – Developer’s Guide 1.0, Release 01. 23.01, 2001 [25] Infineon, Software Development Kit (SDK) for FingerTIPTM – Programmer’s Guide 1.90 [1] [2]