MOBILE CHIP ELECTRONIC COMMERCE: ENABLING CREDIT CARD PAYMENT FOR MOBILE DEVICES

MOBILE CHIP ELECTRONIC COMMERCE: ENABLING CREDIT CARD PAYMENT FOR MOBILE DEVICES Marko Schuba and Konrad Wrona Ericsson Research, Germany ABSTRACT This paper describes the Mobile Chip Electronic Commerce system architecture, an adaptation of the Chip Electronic Commerce specification for credit card payments to mobile phones. The new architecture splits the functionality required at the payment client into two separate units. The main parts of the protocol, i.e. all tasks which are computational intensive but not sensitive with respect to security, are performed on a server in the fixed part of the communication network. The mobile phone or to be more specific a smart card, inserted into the phone or a phone accessory, serves as security device, which signs the transaction data and thus not only confirms the correctness of the payment transaction data but also ensures that the credit card has actually been present in the transaction. INTRODUCTION The deployment of new technologies like WAP (Wireless Protocol) [1] and i-mode will lead to a large number of users accessing the Internet with their mobile phones. A key issue when looking at the Internet as a marketplace for these users is to enable secure payment from mobile phones to Internet merchants. Since such merchants can be located anywhere in the world, a widely accepted payment mechanism, e.g. based on credit cards, is required. Although credit cards have been in use for PCbased Internet payments for a long time, the security mechanisms, especially with respect to authentication, are either very weak or too complicated to be handled by typical users. In order to overcome these problems, a new specification called Chip Electronic Commerce has been released in the end of 1999. The goal of this specification is to combine the benefits of smart cards (as authentication token) with the SET 1 (Secure Electronic Transactions) standard for credit card payment in the Internet. However, Chip Electronic Commerce has been developed for powerful computers connected to Internet via fixed lines. Implementing the same client functionality directly in mobile devices is not feasible today, because of the power and bandwidth constraints of mobiles. In order to overcome the limitations of mobile devices with respect to bandwidth, processing and 1 SET is a trademark owned by SET Secure Electronic Transaction LCC battery power, an adaptation of the Chip Electronic Commerce standard is necessary. The so-called Mobile Chip Electronic Commerce approach chosen in the present paper splits the client part of the original specification into a mobile device and a server part. While the server, which is located in the fixed part of the network, performs time and resource consuming protocol tasks, only the critical functions from a security perspective are executed in the mobile terminal. Thus, the processing load as well as the bandwidth requirements for the mobile are reduced, while preserving end-to-end security between the mobile terminal and the transaction processing system in the fixed network. STANDARDS FOR CREDIT CARD PAYMENT Internet Credit Card s Today, there are two main protocols, which are used to secure online purchases with credit cards: the Secure Sockets Layer (SSL) protocol, and the Secure Electronic Transaction (SET) protocol. A drawback of the both SSL and SET protocols is that they require the use of cryptographic algorithms that place a significant load on the computer systems involved in the commercial transactions. SSL has a lower impact on the e-commerce service, but provides fewer features to eliminate security risks. Secure Electronic Transaction Protocol After the separate development of Secure Transaction Technology (STT) by VISA and Secure

Electronic Protocol (SEPP) by Master- Card, the companies joined forces and announced in 1996 the joint development of one standard protocol, SET, to secure payment card transactions over open networks. SET has been published as open specification for the industry [2]. The current version of SET was designed for common desktop PCs as the typical user terminal, and with the Internet as the transport network. SET provides an electronic commerce infrastructure that delivers: Confidentiality of information Integrity of data Interoperability Certificate based authentication SET uses both primary encryption methods: secret-key (symmetric) cryptography and public-key (asymmetric) cryptography. A secret-key cryptography algorithm used by SET is the Data Encryption Standard (DES), and the public-key cryptography algorithm is RSA with 1024-bit keys. In Figure 1 the processing flows for purchase request and payment authorization are shown. 1. After browsing and selecting an item from the merchant, the cardholder sends a purchase initialization request to the merchant, requesting a copy of the certificates belonging to the merchant and payment gateway (INITI- ATE_REQUEST). 2. After receiving the purchase initialization request, the merchant sends a purchase initialization response (digitally signed with the merchant s private signature key) along with the merchant s and payment gateway s certificates to the cardholder (INITIATE_RESPONSE). 3. The cardholder software verifies the certificates and the merchant s signature included in the purchase initialization response. The cardholder software creates an order information for the merchant and completes payment instructions for the payment gateway and generates a dual signature for both messages. In the end, the order information and the encrypted payment instructions are sent back to the merchant along with the cardholder s certificate (PURCHASE_REQUEST). 4. The merchant software verifies the cardholder s certificate and the dual signature. The merchant software creates an authorization request for the payment gateway and digitally signs it. The merchant software sends the authorization request and the encrypted payment instructions along with the cardholder s and merchant s certificates to the payment gateway (AUTHORISATION_REQUEST). 5. The payment gateway verifies the certificates, the authorization request and the payment instructions. Then it sends an authorization request through the financial network to the cardholder s financial institution (i.e. issuer), where the payment instructions are to be cleared. The payment gateway generates an encrypted authorization response and generates then a capture token. The authorization response and the capture token are then transmitted to the merchant along with the gateway s certificate (AUTHORISA- TION_RESPONSE). 6. The merchant software verifies the gateway s certificate and decrypts the authorization response. The capture token is stored for later capture processing. The merchant software creates a purchase response, digitally signs it and sends it back to the cardholder (PUR- CHASE_RESPONSE). If the transaction was authorized, the merchant fulfils the order, e.g. by delivering the purchased goods. 7. In order to obtain the money from the purchase (after fulfilling the cardholder s order), the merchant starts a payment capture process with the payment gateway using the stored capture token. Cardholder Issuer INITIATE_REQUEST INITIATE_RESPONSE PURCHASE_REQUEST PURCHASE_RESPONSE the Internet SETTLEMENT financial networks AUTHORISATION_ REQUEST Merchant gateway Acquirer AUTHORISATION_ RESPONSE Figure 1: Processing flows for purchase request and authorization in SET

EMV 96 and EMV 2000 a Smart Credit Card Europay, MasterCard and Visa (EMV) jointly developed specifications that define a set of requirements to ensure interoperability between chip cards and terminals on a global basis, regardless of manufacturer, financial institution, or location of card usage. EMV offers both asymmetric (public-key) and symmetric (shared-key) security mechanisms. Asymmetric security mechanisms authenticate the card as a valid card to the terminal. Symmetric security mechanisms generate and verify transaction cryptograms (essentially Authentication Codes, MACs) based on a key shared between card and issuer. Chip Electronic Commerce Chip Electronic Commerce is a part of the EMV 2000 specification [3]. It defines the use of an integrated chip card (smart card) application to conduct a credit or debit transaction in an electronic commerce environment using SET 1.0 compliant software. Chip Electronic Commerce leverages the EMV functions with the Secure Electronic Transaction specification to provide a protocol for secure smart card based transactions over the Internet. Chip Electronic Commerce takes advantage of two enhancements to the SET protocol: SET Common Chip Extension: Extends the SET protocol to support the transport of smart card related data. Online PIN extension: Extends the SET protocol to support the online transport of a cardholder s PIN. In addition, Chip Electronic Commerce extends the SET specification by supporting two key features native to EMV smart card applications: Online card authentication, through the use of a cryptogram. Cardholder verification, through the use of an optional cardholder PIN. Chip Electronic Commerce does not require any modification to EMV compliant smart cards. RESTRICTIONS OF MOBILE SYSTEMS Electronic commerce in a wireless environment faces a number of constraints. Firstly, the bearer service in wireless networks is rather limited when compared to fixed networks, i.e. less bandwidth, longer latencies and more errors. Secondly, cheap mobile devices produced for the mass market have several restrictions, e.g. concerning the input and output of data (small keyboard and display), processing power, and memory. Thus, services suitable for desktop computers in fixed networks cannot be deployed in wireless systems without modification. To illustrate this problem in connection with electronic commerce let us take a closer look at one of the main applications for mobile electronic commerce: shopping. As in real shops shopping with a mobile device consists of several phases. After the selection of goods to be purchased (phase 1), the merchant transmits a contract containing a list of the goods and the amount of money to be paid to the mobile device (phase 2). If the customer agrees on the contract the money is transferred (phase 3) and the goods are delivered (phase 4). Depending on the type of good this delivery can be either physically or electronically. The main problems for the wireless environment arise from phase 1 and 3, i.e. selection and payment. In a fixed network customers usually select goods by browsing on an Internet merchant s web page. Providing a similar service on a mobile device is rather difficult, because merchant web pages usually contain a lot of information and pictures, resulting in a high data rate and the need for a large display. But even if these problems are solved, the problems with respect to the payment phase still remain. The required cryptographic algorithms, which are usually based on public key infrastructures, need a lot of computational power (i.e. battery power) as well as memory. Due to the resource limitations of the mobile device specific solutions for mobile electronic commerce have to be found. Typically, such solutions consist of a thin client, which is supported by a server in the fixed part of the network. Several methods for adapting the original SET protocol to wireless systems have been proposed in [4]. The following Mobile Chip Electronic Commerce approach, i.e. the mobile adaptation of the Chip Electronic Commerce specification, is based on a similar architecture. MOBILE CHIP ELECTRONIC COMMERCE The concept of Mobile Chip Electronic Commerce has to take the following considerations into account: 1) Mobile Chip Electronic Commerce must fit into restrictions of mobile systems.

2) Mobile Chip Electronic Commerce software must conform to both SET and EMV specifications. 3) Mobile Chip Electronic Commerce should offer the same security level as standard Chip Electronic Commerce. 4) Mobile Chip Electronic Commerce should work transparently for the merchants as well as for other SET entities as specified in the specifications. In order to adapt the Chip Electronic Commerce specification to the mobile environment, the cardholder part of the architecture is divided into a Mobile Chip Electronic Commerce Client and a Mobile Chip Electronic Commerce Server. While the server performs the main part of the protocol, i.e. it compiles and exchanges messages with the merchant, checks certificates etc., the client s task is limited to important security related tasks like authentication of the user or authorization of the payment transaction (achieved by an EMV cryptogram calculated on the smart card). Note that the splitting of functionality between client and server not only substantially limits the processing load put on the mobile device, but also reduces the traffic on the wireless link. The Mobile Chip Electronic Commerce Transaction Flow A number of messages have to be transmitted between the different parties during a payment transaction. Figure 2 shows the overall message flow in the Mobile Chip Electronic Commerce architecture. A more detailed description of the message exchange between server, client and EMV smart card is given in Figure 3. Mobile Chip Electronic Commerce Client ICC EMV Mobile Chip Electr. Comm. Server PInitReq PInitRes PReq Unsigned PRes SET Merchant AuthReq AuthRes SET CapReq Gateway CapRes Figure 2: Mobile Chip Electronic Commerce overall message flow EMV Smart Card Card Initiation Read Cardholder Verification Terminal Action Analysis Issuer Script Processing and Completion Mobile Chip Electronic Commerce Client Mobile Chip Electr. Commerce Server Figure 3: Mobile Chip Electronic Commerce message flow between server, client, and EMV smart card Phases of a Mobile Chip Electronic Commerce From the Mobile Chip Electronic Commerce Server s perspective, a payment can be divided into three phases: 1. Initialization 2. Purchase / 3. Completion 1. Initialization Phase During this phase the Mobile Chip Electronic Commerce Server obtains the information that it needs to start the typical SET purchase request/response dialog with the Merchant Server. It consists of: : The Merchant Server invokes the Mobile Chip Electronic Commerce Client and informs it about accepted payment brands. Card : The cardholder presents to the Mobile Chip Electronic Commerce Client the payment card to be used for the purchase. : The Mobile Chip Electronic Commerce Client selects an application from the card, with input from the cardholder if necessary.

Initiation: The Mobile Chip Electronic Commerce Client initiates the card application to determine whether it and the card agree about how the transaction should be processed. Read : The Mobile Chip Electronic Commerce Client reads the application data. : The Mobile Chip Electronic Commerce Client invokes the Mobile Chip Electronic Commerce Server by sending the order information, the merchant s address and other data objects obtained during the initialization phase. The sources of these data objects and elements are either the or the EMV card application. Once converted, these data objects serve as inputs to the SET Purchase Initialization (PInitReq) message as shown in Table 1. SET PInitReq Data Input Language BrandID Bank Ident. Number (BIN) CardExpiry Corresponding Card Data Object Language Preference Selected ID Personal Account Number (PAN) Expiration Date Source Read Data Read Data Amount Order Description Transaction Currency Code Merchant Address Table 1: Input for the SET PinitReq message Mobile Chip Electronic Commerce Clients may provide an option to use a cardholder selected language rather than the EMV card s language. Alternatively, language settings may be stored in the user profile at the Mobile Chip Electronic Commerce Server. Some data objects used in the Chip Electronic Commerce messages (e.g. Amount Other, or Transaction Type) are constant values and do not need to be send to the Mobile Chip Electronic Commerce Server. 2. Purchase / Phase In this phase the Mobile Chip Electronic Commerce Server requests the actual purchase from the merchant and gets a positive or negative response back. The phase is the longest one and is quite similar to a normal SET transaction, except that it uses a cryptogram instead of a SET dual signature for authorization. It consists of: Purchase Initialization : The Mobile Chip Electronic Commerce Server initializes the purchase by informing the Merchant Server how the cardholder intends to pay. Purchase Initialization : The Merchant Server returns the information necessary to complete the purchase. : The Mobile Chip Electronic Commerce Server request a purchase authorization and cryptogram generation from the Mobile Chip Electronic Commerce Client. Cardholder Verification: The Mobile Chip Electronic Commerce Client retrieves information from the cardholder that may verify her identity and either presents it to the card or transmits it to the issuer for verification Terminal Action Analysis: The Mobile Chip Electronic Commerce Client requests an authorization of the transaction. The card determines whether to decline the transaction off line or to request an online authorization or referral. : The Mobile Chip Electronic Commerce Client approves the payment transaction and sends back the required Common Chip extension data input (in particular the cryptogram). Purchase : The Mobile Chip Electronic Commerce Server requests a purchase and provides the Merchant Server with the data that itself, the Gateway, and the issuer need to respond to the request. Authorization & : The Merchant Server sends to the Gateway the information needed to verify the authenticity of the cardholder and to create a System s authorization request message. The Gateway sends back a message indicating whether the transaction has been authorized or declined by the issuer. Purchase : The Merchant Server informs the Mobile Chip Electronic Commerce Server about the status of the transaction sometime after it has received the Mobile Chip Electronic Commerce Server s Purchase. Note: SET allows a merchant to return a PRes message to the Mobile Chip Electronic Commerce Server before authorization processing.

3. Completion Phase This is the last transaction phase. Its only task is to inform the Mobile Chip Electronic Commerce Client about the final status of the payment transaction. The completion phase consists of: : The Mobile Chip Electronic Commerce Server sends payment result and possible Issuer Authentication and Issuer Script Data to the Mobile Chip Electronic Commerce Client. Issuer Script Processing and Completion: The Mobile Chip Electronic Commerce Client ends the involvement of the cardholder and EMV Card. CONCLUSIONS A number of standards for online credit card payment exist today. The implementation of those standards in mobile devices requires consideration not only of security-related issues but also of the limitations of the mobile device with respect to power and bandwidth. In this paper the Mobile Chip Electronic Commerce architecture - an adaptation of the Chip Electronic Commerce specification for credit card payment to mobile devices has been proposed. The architecture consists of a server, which performs most of the cardholder s protocol during a transaction, and a client with EMV smart card, which is used to authorize the payment. This division of functionality significantly reduces the traffic on the wireless link as well as the processing requirements in the phone, while the security of the solution is still end-to-end. One of the most important issues in case of the full-scale electronic commerce solutions is operation and maintenance costs and complexity. The standard SET protocol requires a user to install additional software, generate private-public RSA key pair and request a public key certificate from her financial institution. These steps require active participation of the user and at least basic level of understanding of underlying technology. Multiple problems can arise during the installation and certification process, causing the user to abandon the personalization process. From an issuer/service provider perspective, intensive user assistance has to be provided, raising overall costs of the solution and diminishing the user's satisfaction. owned infrastructure. Only mobile terminal and payment gateway have to support additional Mobile Chip Electronic Commerce functionality. Intuitive usage of a familiar credit card for payment transaction can increase users trust and improve the mobile e-commerce experience. Maintaining a payment authorization module (i.e. smart credit card), which is separated from the mobile terminal eliminates the need for a trust relation between mobile network operator and card issuer. This enables an easier adoption and a global interoperability of the solution. REFERENCES 1. April 2000. Wireless Protocol Architecture Specification. Version 30. April 2000. Available online at: http://www.wapforum.org. 2. May 1997. SET Secure Electronic Transaction Specification, Book One: Business Description. Version 1.0, SETCo. Available online at: http://www.setco.org/. HYPERLINK3. April 2000. EMV2000 Integrated Circuit Card Specification for Systems, Book 3: Specification. Draft Version 4.0, EMVCo. Available online at: http://www.emvco.com/. 4. Wrona, K., Zavagli, G. 1999. Adaptation of the Secure Electronic Transaction Protocol to Mobile Networks and WAP. Proceedings of European Wireless '99, Pp. 193-198. Berlin: VDE Verlag. ACKNOWLEDGEMENTS The authors would like to thank their colleague Guido Zavagli for his contributions to this work. Mobile Chip Electronic Commerce leverages on the existing penetration of EMV-compliant credit cards, reducing the complexity and cost of the cardholders credentials management. Ideally, every mobile user possessing an EMV-compliant credit/debit card and Mobile Chip Electronic Commerce-enabled terminal can benefit from the robust payment security provided by the SET protocol. No changes are required to the bank and merchant