the cardholder to buy goods and services within a predefined monetary limit on the holder's pledge .... A dedicated network is required to interact with the server.
Secure and Cost Effective Transaction Model for Financial Services
A Thesis Submitted in Partial Fulfillment of the Requirements for the Degree of Bachelor - Master of Technology (Dual Degree)
by Nitin Munjal
to the DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING INDIAN INSTITUTE OF TECHNOLOGY KANPUR July 2009
Abstract At a time when e-commerce applications are fast emerging as an efficient and popular delivery channel for financial services, security risk is also enhanced which can transform the lives of many for the worse. With the advent of the e-commerce, it has become much easier for a ‘data bandit’ to sit in non descriptive location and quietly siphon away money from the service users. The financial service outlets (e.g. automated teller machine (ATM), Point of Sale (PoS) terminals) have been a soft target for these bandits since long. In the existing model, the users are forced to trust a service outlet to be authentic. A spoofed outlet can collect the account information and misuse it in some way later. Installing an outlet is also an expensive affair due to the need of dedicated network connectivity and hardware. In this work, we propose a model that addresses these security and cost related issues of the conventional Financial Service Model. The use of public key infrastructure (PKI) based authentication scheme enables offline mutual trust establishment and removes the primary requirement of persistent network connectivity for authentication. Introduction of smart cards provides a tamper-proof storage for the user’s sensitive information and ensures that PKI keys are not exposed to the external world. We designed and implemented a secure protocol for the model and also present various implementation scenarios for the same. Attributed to the lower equipment and running costs, this implementation is ideal for installing outlets in rural areas. In developing economies, where two-third of the population still lives in rural areas with limited or no network connectivity, this model can help the banks reach the masses and foster economic growth.
2
Acknowledgments I would take this opportunity to express my gratitude towards my advisor, friends and family. First, I would like to thank my advisor Prof. Rajat Moona for his continuous support and encouragement for the entire duration of my program. He helped me define my research goal and towards achieving it. His clarity of thought, dedication to work and impeccable knowledge inspired me to learn and work hard. It would not have been possible to complete this work without his inspiration and invaluable suggestions. I am grateful to my friends, fellow researchers and associates at the Smart Card Labs - CS108 and CS109 for their help and constant support. I am indebted to my family for their unconditional love and for the toughest times they have stood by me in. Their motivation and affection helped me achieve my goals. Nitin Munjal
i
Dedicated to my lovely little niece, Sayesha
ii
Contents List of Figures 1 Introduction 1.1 Motivation . . . . . . . 1.2 Problem Statement . . 1.3 Related Work . . . . . 1.4 Organization of Report
iv
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
1 2 3 4 6
2 Financial Services 2.1 Electronic Payment Systems . . . . . 2.1.1 Instruments of e-commerce . . 2.2 Attacks on Financial Service Outlets 2.2.1 Bogus outlet attack. . . . . . 2.2.2 Use of skimming devices. . . . 2.2.3 Shoulder surfing. . . . . . . . 2.2.4 Fake keypad overlay attack. . 2.3 Problem Classification . . . . . . . . 2.3.1 Security Issue. . . . . . . . . . 2.3.2 Network Issue. . . . . . . . . 2.3.3 Cost Issue. . . . . . . . . . . . 2.3.4 User Inconvenience . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
8 8 9 10 10 10 11 12 13 13 13 14 14
3 Proposed Financial Transaction Model 3.1 Model in Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Enhanced Security Features in Our Model . . . . . . . . . . . . . . .
16 17 20
4 Protocol for Proposed Financial Transaction Model 4.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Protocol Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Protocol Versioning . . . . . . . . . . . . . . . . . . . . . . . .
22 23 23 24
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
iii 4.2.2
. . . . . . . . . . . . . . . . .
24 24 28 29 29 31 31 31 35 35 36 37 38 38 38 38 38
. . . . . . . . . . . . . . .
42 44 45 45 47 47 47 47 48 48 48 49 49 50 50 50
6 Conclusion and Future Work 6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52 52 53
Bibliography
54
4.2.3 4.2.4
4.2.5 4.2.6 4.2.7 4.2.8
Handshake Stage . . . . . . . . . . . . . 4.2.2.1 Hello message . . . . . . . . . 4.2.2.2 Welcome message . . . . . . . . Certificate Exchange stage . . . . . . . . 4.2.3.1 Certificates message . . . . . Mutual Authentication stage . . . . . . . 4.2.4.1 Challenge message . . . . . . . 4.2.4.2 Response message . . . . . . . Account Information stage . . . . . . . . 4.2.5.1 AccountInformation message . Transaction stage . . . . . . . . . . . . . 4.2.6.1 Transaction message . . . . . Close Connection stage . . . . . . . . . . 4.2.7.1 CloseConnection message . . . Supplementary Messages . . . . . . . . . 4.2.8.1 Indication messages . . . . . . 4.2.8.2 Error messages . . . . . . . . .
5 Design and Implementation 5.1 Steps in the proposed model . . 5.2 Cryptography at the client side 5.3 Implementation . . . . . . . . . 5.3.1 Storing transaction logs 5.3.2 Testing . . . . . . . . . . 5.4 Related Technologies . . . . . . 5.4.1 NFC . . . . . . . . . . . 5.4.2 Bluetooth . . . . . . . . 5.5 Discussions . . . . . . . . . . . 5.5.1 Addressing the issues . . 5.5.1.1 Security Issue. 5.5.1.2 Network Issue. 5.5.1.3 Cost Issue. . . 5.5.1.4 Comfort Issue. 5.5.2 More Discussions . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
iv
List of Figures 2.1 2.2 2.3
A skimming device mounted on Automated Teller Machine [8] . . . . Camera used in conjunction with a skimming device. [40] . . . . . . . A fake keypad overlay [27] . . . . . . . . . . . . . . . . . . . . . . . .
11 12 12
3.1 3.2 3.3
Financial Service Model . . . . . . . . . . . . . . . . . . . . . . . . . Verification of certificate chain . . . . . . . . . . . . . . . . . . . . . . Presentation of Account Information . . . . . . . . . . . . . . . . . .
17 18 20
4.1 4.2
Transaction Service Protocol - Client Side . . . . . . . . . . . . . . . Transaction Service Protocol - Server Side . . . . . . . . . . . . . . .
25 26
5.1
Possible Implementation Scenarios . . . . . . . . . . . . . . . . . . . .
42
1
Chapter 1 Introduction Electronic Commerce has gradually seized the role of processing transactions from the physical walls of bank branches. The swiftness and convenience that it offers has resulted in it becoming an indispensable part of our day to day life. Financial organizations have shown great interest towards pushing the new technologies to the end user by encapsulating them in a variety of services. The organizations that we refer to are commercial banks, credit card companies, insurance companies, investment funds, stock brokerages etc. and by ‘services’, we refer to the financial services such as an automatic teller machine (ATM), credit cards, electronic fund transfer etc. These organizations compete amongst each other to introduce newer and better services since these services save working cost and/or lure more users by providing them more comfort. However, with most good things, there are always sore points. This also makes these services popular target amongst the fraudsters. These services should therefore try to cover up possible inroads and ensure that security is not compromised. Over 2 billion people [34] in the developing world have no access to financial services which constrains the economic growth.“A lack of access to finance in some parts
2 of the developing world stifles entrepreneurship, stunts development and leaves people trapped in a poor, cash-only society.” [34]. Microfinance is a special field in economics that concerns with the provision of financial services like credit, savings, insurance, fund transfers etc. to low-income clients [26]. Most of the rural population constitutes the poor and low-income clients. An easy access to the financial services would encourage savings amongst the poor whilst, at the same time, discourage them from approaching the moneylenders who charge unreasonable rates of interest. Therefore, it is often asserted that microfinance has the capacity to deal with poverty single handedly. For all these reasons every now and then, numerous theories are often produced in this respect.
1.1
Motivation
Financial services can play an important role in rural development as they increase money flow and boost economy. “Rural finance is about providing financial services - secure savings, credit, money transfer and insurance - in rural areas” [18]. Though there is a substantial demand for rural financial services, financial institutions such as microfinance institutions (MFI), commercial banks, insurance agencies, credit unions etc. are unwilling [18] to provide services in rural areas. There are two major reasons for this behavior. 1. High transaction costs. Lesser quantum of transactions in rural areas results in lower utilization of the service outlet. Banks have an incentive of saving upon the cost of human resource by installing a financial service outlet like an ATM. In scantly populated areas, the installation costs overpower the utilization of the service outlet. So, these areas are left out for economic reasons.
3 2. Infrastructure costs. A financial service outlet such as an ATM requires one time installation costs for hardware such as I/O devices, networking device and cooling machine. Besides this, it incurs the run time cost for the persistent network connectivity. A dedicated network is required for two reasons. One, querying a central server and authenticating the user. Two, updating the transaction information that took place with the user. It is estimated that an ATM machine in India requires an investment of 5-8 lakhs Indian Rupees. In the present transaction model for financial services, the user is constrained to trust the service outlet. The user is provided no means to lay down the authenticity of the service outlet. There could arise scenarios where an attacker installs a fake outlet and records the information stored in the user’s card along with the private information (such as PIN) entered by the user and use it for a replay attack later.
1.2
Problem Statement
There are two aspects of the problem that need to be addressed. One is the security concern. In persisting models, a person is forced to trust the service to be authentic. In this regard, some questions can be raised like “What if the outlet is fake? ” or “What if the outlet is meant to collect your card information and use against you later? ”. The current transaction model fails to give an answer to these concerns. High installation and working cost of a financial service outlet is another issue of concern. The outlets require a dedicated network connectivity to be able to communicate to a centralized server for authentication and updation of transaction log information. The requirement of network along with hardware cost increases the cost
4 of installing an outlet so much that commercial banks are reluctant to install them in rural areas. Hence the question, “Can network component be eliminated from the current transaction model for financial services so that costs are brought down? ”
1.3
Related Work
Low penetration of banking services in rural areas has been a deterrent to the development of rural economy. Many attempts have been made by various researchers and organizations to provide a solution that addresses this problem. Mobile banking has emerged as one of the feasible solution to this problem. A pilot program in this respect was launched in Andhra Pradesh, India in 2008 by “A Little World” (ALW [3]) in association with NXP semiconductors and a non-profit agency, Zero micro-finance. The initiative has registered 250,000 people in Andhra Pradesh for mobile banking services [9]. The users have been issued a contactless RFID smart card which biometrically stores the identity of the customer such as name, address, photograph, fingerprint templates and details of savings or loan accounts held by the issuing bank [33]. The users can use their card for doing transactions at Customer Service Points (CSPs [7]). The transactions take place in a secure environment using NFC enabled mobile phones. Currently, it is estimated that the government incurs Rs. 13 on every Rs. 100 it shells out for the poor. It is claimed [33] that this mobile banking model can bring down this cost to just Rs. 2. The problem of low penetration of ATM in rural areas has been extensively studied by many researchers and organizations. Amila et al. [24] propose a system called Mobile-ATM to address the problem of low financial and banking services in rural areas by incorporating the mobile technology. The system introduces a new entity
5 termed as an ‘M-ATM agent’ who is a person authorized by the bank to perform M-ATM transactions. In this system, the customer, the M-ATM agent and the bank communicate with each other through a sequence of secure SMS messages. After receiving the money withdrawal request from the customer and establishing his identity, the bank instructs the M-ATM agent to hand in the money to the customer. The M-ATM agent is trusted to pay the customer the money after establishing customer’s identity using a unique confirmation number. The bank deducts money from the customer’s account and sends him a transaction confirmation SMS in response. The concept relies on the fact that the spread of M-commerce is much larger than of internet connectivity. The introduction of M-ATM agents and cellular network service provider provides a ubiquitous solution with reasonably high cost per transaction. Han et al. [17] came up with a novel hybrid concept of Biometric Authentication scheme for ATM based banking applications. They proposed two levels of authentication, first using PKI based authentication and second using biometric trait like a fingerprint. This scheme prevents card forgery and phishing attacks but the biometric information is stored in the databases of the banks and requires online secure channel of communication between the ATM and the server for biometric verification. Moreover, the biometric devices are expensive and encrypting biometric images takes up a reasonably large amount of time (5 seconds [17]) making it impractical to be used in rural areas where cost is a big concern. Standard Chartered Bank recently (February 2009) launched ‘mBanking’ service for transferring money from one account to another, view bank statements, pay bills [37] etc. by means of sending SMSs over the network. The merchant in this scheme, need not be connected to the network. Jhunjhunwala [23] proposes to set up a low cost ATM in rural areas. The ATM
6 called Gramateller which eliminates the need for personal identification numbers and magnetic-stripe cards. Smart cards and fingerprints are used instead. The Gramateller plugs into the PC of a village Internet kiosk to communicate with the bank server. This model claims to bring down the installation cost of an ATM to approximately one-tenth of the current cost. The use of Internet kiosk, however, introduces unreliability in the service model. Moona et al. [14], [15] propose a solution which uses personal mobile devices held by the user to interact with the service outlets. This model does away with the need of the interaction console and communication infrastructure at service outlets. In this thesis, we mainly focus on explaining the work done by us, Munjal et al. [30] [29]. We propose a Financial Service Model which aims to address the various shortcomings of the current model. For this model, we also design and give implementation details of a secure protocol. The security of the working of the protocol does not rely on the security architecture of the underlying communication channel. Smart cards provide a tamper-proof storage media and protect data against unauthorized reading or copying. The use of public key infrastructure (PKI) removes the primary requuirement of a dedicated network connection for authentication and save operational cost overhead of the outlet.
1.4
Organization of Report
Various aspects of financial service model have been elaborated in this thesis. The thesis is divided into six chapters and a brief outline of each of the chapter is enumerated below. • Chapter 1. This chapter gives an introduction into financial services, their role
7 in economic development and the security issues concerning these services. The chapter also gives a brief overview of the efforts being put up for the same. • Chapter 2. This chapter gives an insight into the current financial services offered by the commercial banks. The chapter also talks about instruments involved in e-commerce applications and raises various concerns that emphasize the need for a better financial service transaction model. • Chapter 3. Proposes a new financial service model which is low cost and secure. • Chapter 4. This chapter deals with the design of a protocol for the transaction model proposed in Chapter 3. • Chapter 5. This chapter discusses three possible implementation scenarios of the protocol. The chapter also gives an overview of the design and implementation of the work. The chapter further briefs on how the new model addresses the various concerns pointed out in Chapter 2. • Chapter 6. This chapter summarizes the work and outlines future work.
8
Chapter 2 Financial Services Financial services refer to services offered by the finance industry. We limit our focus to services provided by the banking industry such as ATM outlets, credit card outlets at shops, gas stations, malls etc. These services are often known as electronic payment systems.
2.1
Electronic Payment Systems
Automated Teller Machines, popularly known as ATMs, are electronic terminals that offer most banking services almost any time. To withdraw money, make currency deposits, transfer funds from one account to another or to make balance enquiries, a customer is usually required to insert an ATM card and enter a personal identification number (PIN) at an ATM outlet. Some commercial banks may charge a fee (per transaction or per annual period) for the services they render. Point of sale (PoS) allows the customers to make purchases by presenting their charge card, credit card, debit card etc. The device, in this system, comprises of
9 a compact counter top terminal which is connected to a network. These days, PoS systems are being used extensively in supermarkets, malls, restaurants, gas stations, hotels, casinos, retail shops etc. The system follows the universal ISO 8583 standard [20] which defines the message format and the message flow sequence.
2.1.1
Instruments of e-commerce
Electronic purse or e-purse systems have been developed as an alternative for cash payments. The system is based on ‘pay-first’ concept [38] and uses a card with an integrated chip such as a smart card. The card contains a stored value which denotes the buying power in the card. The funds in the card can increase as well as decrease. To increase funds in the card, the service provider loads the card with some monetary value and a decrease in the stored value takes place upon payment of purchases. The process is fast and easy and is appropriate for deployment at railway stations (for payment of ticket charges), at shops, at vending machines (soft drink, fast food) or at public pay phones. The cardholder is himself responsible for safety of the card as there is no added safety mechanism (like PIN etc.) to prevent unauthorized use. A debit card follows the ‘pay-now’ [38] or direct debit payment concept and employs either signature or PIN based safety measure. The card is usually a magnetic stripe card and the magnetic stripe stores the cardholder’s account information. It allows the user to make a purchase directly charged to funds on his bank account when he purchases goods/services or withdraws money. Credit cards, on the other hand, offer a ’pay-later’ system [38]. The card entitles the cardholder to buy goods and services within a predefined monetary limit on the holder’s pledge to pay for them later.
10
2.2
Attacks on Financial Service Outlets
At a time when e-commerce applications are fast emerging as an efficient and popular delivery channel for financial services, the security risk associated with them is also enhanced. The current transaction model for financial services offers easy inroads for an attacker. In the upcoming sections we discuss some common attacks that are possible in the current scenario.
2.2.1
Bogus outlet attack.
This attack refers to the condition when an attacker installs a fake outlet which imitates a genuine outlet. The user is, currently, provided with no way to trust the outlet. So, in a way, he is compelled to use the outlet without establishing the identity of the outlet. The outlet reads the user information from the card presented by the user, takes the user PIN that is supplied by the user and stores it. This information stored is later used by the attacker to forge a card. The first ever recorded instance of using a fake outlet (ATM) occurred in 1993 [11], when a gang of criminals put a bogus ATM at a shopping mall in Connecticut, Manchester. The users didn’t know that the ATM was fake and won’t dispense any service. It was used to counterfeit ATM cards and swindle money from user accounts.
2.2.2
Use of skimming devices.
Skimmers are the devices that are used by swindlers to capture data from the magnetic stripe of the card issued by the bank. These devices are small, easy to carry and are often clamped together with the reader of a service outlet. The devices are inexpensive, commercially-available and can capture and retain the account
11 information of upto 200 ATM cards [11] before being reused. Some bold swindlers
Figure 2.1: A skimming device mounted on Automated Teller Machine [8]
have gone to the extent of placing a sign saying “Swipe Here First” before doing any transaction. Other bold moves include portraying the skimming device as a “card cleaner” to improve the life and performance of the card. These devices are very successful at places where the user cares more about convenience and ease of transactions rather than security such as petrol dispensing stations and restaurants and hands over his card to a stranger.
2.2.3
Shoulder surfing.
Shoulder surfing refers to the act of direct observation as a person enters his PIN or other private information at a financial service outlet. The modes of this observation are that an attacker could either be looking directly (in close proximity), using device such as a binocular or has placed some sophisticated equipment like miniature video cameras aimed at recording the PIN entry. In case of credit cards, this can be used as means of recording the secret credit card number and hence is very dangerous. This technique is usually used in conjunction
12
Figure 2.2: Camera used in conjunction with a skimming device. [40] with the use of skimming devices to obtain full information so that a new card can be faked and used.
2.2.4
Fake keypad overlay attack.
In this type of attack, an attacker accomplishes PIN stealing by placing a fake keypad overlay over the top of an existing keypad at a service outlet. The fake keypad overlay is very thin, often transparent and cannot be detected by a naked eye.
Figure 2.3: A fake keypad overlay [27]
13 The overlay pad stores each keypad button press along with the timestamp. This information can later be downloaded from the equipment. The button press is relayed to the original keypad and the transaction takes place normally without the user’s knowing that his PIN has been compromised.
2.3
Problem Classification
We now present and classify the issues related to the current financial transaction model. In the following chapters, we shall try to address these issues by proposing a model for the same.
2.3.1
Security Issue.
Security, by and large, remains the prime issue of concern in any kind of financial service transaction model. All the shortcomings discussed in Section 2.2 constitute the security issues related to the current financial service transaction model.
2.3.2
Network Issue.
1. Dedicated network is required. The service provider gives an authentication material, usually a magnetic stripe card or a smart card, to the customer. This authentication card carries information about the customer. In order to access a service, the customer presents his authentication card to the service outlet. The customer is asked to enter a password which is used to authenticate the customer. The service outlet extracts customer information from the card and sends this information (including the entered password) to a central server for authentication. Sometimes, the authentication may include biometric mech-
14 anisms which are usually matched at the service outlet. After authentication, the customer is allowed to access services. After the transaction is complete, the outlet sends the transaction information back to the central server. Thus, the present model makes the need of a dedicated network indispensable. 2. Network is unreliable. Messages on the network may sometimes get lost and usually take unpredictable amount to time to reach their destination. The non-functional/malfunctioning network results in a disrupted service and causes inconvenience to the users.
2.3.3
Cost Issue.
1. Cost of network connectivity. All the user information is stored in a centralized server. A dedicated network is required to interact with the server. Currently, institutions employ a solution which involves a V-SAT link or a Dial-up connection which are costly. 2. Need of display/input devices. A financial service outlet requires devices for input and output such as keyboard and display. This swells up the cost of the outlet. 3. Need of cooling hardware. For outlets like an ATM, greater number of hardware devices also mean requirement of greater cooling infrastructure.
2.3.4
User Inconvenience
Carrying multiple authentication tokens. Users often carry multiple authentication token such as a magnetic stripe card, smart card, RF card etc. for
15 multiple services like credit account, debit account etc. and for each of the financial institutions. This is a lot of overhead and causes inconvenience to service users.
16
Chapter 3 Proposed Financial Transaction Model In this chapter, we propose a transaction model for financial services, which we claim, is secure and cost effective. We rely on public key infrastructure for authentication and key generation. This chapter also explains the security features involved. Discussion on the cost effectiveness of this model follows in Chapter 5. All the transaction that take place between the financial service outlet and the user need to be guaranteed for the following. 1. Authentication. Ensure that the claimed user is the authorized user. 2. Integrity. Ensure data consistency; prevent unauthorized generation, alteration or deletion of the data being communicated in the transaction. 3. Confidentiality. Ensure data privacy; all the data carried in the transaction can only be known by the intended recipients of the transaction. 4. Non-replication. A transaction can not be replayed back.
17 5. Non-repudiation. An entity can not repudiate or refute the validity of the transaction. Based on these requirements, we propose a model whose steps are outlined in Figure 3.1. Financial Service Outlet
User
Certificate Exchange 1. Verify 2. Get Public Key
Mutual Authentication and Key Establishment
1. Verify 2. Get Public Key
Secure Channel
Account Information
Transactions
Figure 3.1: Financial Service Model
3.1
Model in Detail
Initially, the financial service outlet and the user each have their own digital certificates. An exchange of digital certificate chain (Figure 3.2) is necessary to establish a binding between the identity and the public key of the remote entity. For each entity, the entity’s identity, the public key, their binding, validity conditions and other
18 attributes are made unforgeable in digital certificates issued by the common root CA (CCA) [28]. Root CA Certificate (e.g. Reserve Bank of India)
Verify Certificate validity, verify this is signed by Root CA
Verify Certificate validity, verify this is signed by Bank 1 if Bank 1's certificate is verified
Bank 1
Trusted Authority
Untrusted Authority
Untrusted
Untrusted
ATM Authority
Saving Accounts Authority
Untrusted ATM at location X
Untrusted User U
Figure 3.2: Verification of certificate chain
Figure 3.2 gives an example of a certificate chain hierarchy and gives an abstraction on how a mutual trust is developed between the two participating entities, the ATM outlet and the user. This hierarchy could be extended to involve many other banks. This would enable a user to take advantage of services of an other banks too. After certificate exchange, each entity needs to verify the digital certificates thus received to trust the identity-public key binding. Once this binding has been established, the entity only needs to ensure that the remote entity has a private key that corresponds to the public key acquired from the certificate to prevent fake role play. If these steps are completed successfully, the entity is said to have authenticated the remote entity.
19 We classify the procedure outlined above in the following steps. 1. Certificate exchange. To start the process of establishing the identity of the participating party, both sides exchange the certificates along with the certificate chain starting from the common CA. 2. Mutual Authentication and Session Key establishment. Both parties issue a challenge in order to verify that the intended recipient is the one with whom the communication is taking place. If a person tries to establish a connection using some other user’s public key, then he won’t be able to respond correctly to the Challenge message issued by the challenger as it requires the corresponding private key. The Session Key for establishing a secure channel is also derived in the Mutual Authentication stage. Two keys are generated, one for encryption/decryption and other for MAC computation [28]. Encryption helps in maintaining the confidentiality of the message which means that if an eavesdropper gets hold of the message then he won’t be able to decipher the message. Attaching MAC with message is necessary to ensure integrity and authenticity of the data. New session keys are derived for each session. 3. Account Information Exchange and Transaction. After the establishment of a secure channel between the user and the outlet, the confidential account information can be safely transmitted by the user over this channel. All messages will be encrypted using the encryption key and a MAC will be computed using the MAC key and attached to it to maintain the confidentiality and integrity of the message. The account information that is sent by the user is first signed [25] by the user
20 and then counter signed by the bank. If the outlet verifies that the account information provided by the user is authentic, it lets the user to perform the transaction. The details of each transaction is stored in logs in the financial service outlet. This information can be updated to the central server periodically in a secure manner without the need of any dedicated network connection.
3.2
Enhanced Security Features in Our Model
The session keys for confidentiality and MAC are generated for establishing the secure channel to communicate. The session keys are for the symmetric key operation, since these operations are computationally much cheaper as compared to the PKI operations. In our model, the account information is signed first by the user and then
Figure 3.3: Presentation of Account Information
by the bank. The user signature is added to make sure that the account information provided is indeed of the user with whom the communication is taking place. In this way, a person cannot use someone else’s account information. This user signature
21 needs to be counter signed by the bank. This would prevent a user from forging the account information. This signature sequence can not be reversed (i.e. bank’s signature and then counter signed by the user) because in that case, a malicious user can use his signature over someone else’s account information that is signed by the bank. In this model, mutual authentication and session key establishment are done in the same stage. Separate stages for mutual authentication and session key establishment could pose a security threat if same algorithm is used. For example, if a malicious user wants to get the session key for some ongoing transaction then he can send the encrypted session key as a challenge in a separate transaction initiated by it. The other entity, on reception of this challenge, will decrypt it and send it back to the malicious user thus giving him the session key of the current transaction. Besides this, merging these stages saves computationally intensive PKI operations.
22
Chapter 4 Protocol for Proposed Financial Transaction Model The goal of our effort is to develop a secure transaction protocol [36] at the application layer. The protocol should be secure and should not rely on security architecture of lower layers. This would enable it to be used in conjunction with a variety of lower layer protocols. The protocol should work under the following worst case assumptions. 1. Eavesdropper can listen to the communication. 2. Eavesdropper can alter the messages. 3. Messages may get lost during the communication. 4. Messages may get reordered during the communication.
23
4.1
Terminology
The Client: In the context that follows, the client is the machine, such as mobile phone, smart card etc., using which one wants to do a transaction. A transaction could be any of the following: withdraw money, transfer money, payment or balance check. The Server: The role of the server is to accept and serve requests from the client. In this context, the server refers to the machine providing the ATM service or PoS terminals.
4.2
Protocol Details
We now present the details of the protocol for the transaction model proposed in Chapter 3. The communicated messages are all encoded according to Abstract Syntax Notation (ASN.1 [12]) standard. The protocol involves a sequence of stages, where none of the later stages shall take place without the successful completion of the previous stage. The stages in order of occurrences are the following. 1. Handshake stage. 2. Certificate Exchange stage. 3. Mutual Authentication stage. 4. Account Information stage. 5. Transaction stage.
24 The protocol to be followed by the client and the server is shown in Figures 4.1 and 4.2 respectively.
4.2.1
Protocol Versioning
Most protocols (TLS, SSL, SSH etc.) are dependent on cryptographic algorithms that they use. However our proposed protocol does away with this necessity by using unambiguous, globally unique algorithm object identifiers (Algorithm OIDs). These algorithm identifiers are based on ISO/IEC 9834 series of International Standards. A protocol defines the sequence and flow of messages that takes place between two communicating entities and the content of these messages. In context of this protocol, we define Protocol Version as a function of:
P rotocolV ersion = f (messagesequence, messagecontent)
4.2.2
Handshake Stage
The aim of this stage is to negotiate the Protocol version and the Algorithm suite. The Handshake is carried out using the following message exchanges between the client and the server. 1. Hello message 2. Welcome message 4.2.2.1
Hello message
When a client first connects to the server, it is required to send Hello message as its first message. Hello message is a request for the server to start the negotiation
25
Ready
wait for user action
send Hello
Received: ProtocolNotSupported / AlgorithmNotSupported
Received: Welcome Received: ExpiredCertificate / RevokedCertificate / InvalidCertificate
Y Is message okay?
send Certificates
send ProtocolNotSupported / AlgorithmNotSupported
N
Received: Certificates send ExpiredCertificate / RevokedCertificate / InvalidCertificate
N
Y
Certificate Verification successful?
send Challenge Received: Response
At any state, if the receiver receives any invalid command or any unexpected command, it sends InvalidCommand and UnexpectedCommand message respectively and goes back to the ready state.
Is message okay?
N
send ResponseVerificationFailed / InvalidResponse
Y
Upon reception of InvalidCommand or UnexpectedCommand message, the receiver goes back to the ready state.
send Response
Greyed area denotes that information is transmitted over a secure channel.
Received: Okay
On a secure channel, if the message is incorrect (wrong MAC or bad encryption), the session is aborted and the client goes back to ready state.
compute session key, send AccountInformation
Received: Okay send Transaction
Received: InvalidAccountInformation
Received: InvalidTransaction / ImpermissibleTransaction
Received: Okay
Y
Do more Transaction? N send CloseConnection
Figure 4.1: Transaction Service Protocol - Client Side
26
Ready Listening Received: Hello
send ProtocolNotSupported / AlgorithmNotSupported
N
Is Protocol / Algorithm supported? Y
Received: ProtocolNotSupported / AlgorithmNotSupported
send Welcome
Received: Certificates
Certificates verification successful?
N
send ExpiredCertificate / RevokedCertificate / InvalidCertificates
Y Received: ResponseVerificationFailed / InvalidResponse
Received: Challenge send Response
send Certificates
Received: Response
send ResponseVerificationFailed / InvalidResponse
N
Is message okay?
Y send Okay
Received: AccountInformation
At any state, if the receiver receives any invalid command or any unexpected command, it sends InvalidCommand and UnexpectedCommand message respectively and goes back to the ready state.
N
Is AccountInformation
Upon reception of InvalidCommand or UnexpectedCommand message, the receiver goes back to the ready state.
Y
Greyed area denotes that information is transmitted over a secure channel.
send Okay
On a secure channel, if the message is incorrect (wrong MAC or bad encryption), the session is aborted and the server goes back to ready state.
Received: Transaction send Okay
send InvalidAccountInformation
correct?
Received: Transaction
Is Transaction valid?
N
send InvalidTransaction / ImpermissibleTransaction
Y Received: CloseConnection
Figure 4.2: Transaction Service Protocol - Server Side
27 process anew. In response, the server should send Welcome message when convenient. The ASN.1 [4, 12] representation of Hello message is the following. Hello ::= SEQUENCE { command IA5String("HELO"), protocolVersionList ProtocolVersionList, algorithmSuite AlgorithmSuite } ProtocolVersionList ::= SET OF IA5String AlgorithmSuite ::= SEQUENCE { hashAlgorithms HashAlgorithms, −− used in session key derivation encMACAlgorithms EncMACAlgorithms −− used in the session for encryption, MAC operations } HashAlgorithms ::= SET OF AlgorithmIdentifier EncMACAlgorithms ::= SET OF EncMACAlgorithm EncMACAlgorithm ::= SEQUENCE { encAlgorithm AlgorithmIdentifier, MACAlgorithm AlgorithmIdentifier −− AlgorithmIdentifier as defined in section −− 4.1.1.2 of RFC 5280 [10] and reproduced here } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } ProtocolVersionList carries the list of versions of the protocol that the client supports. For example, if the supported protocol version is IA5String("1.0"), the corresponding DER encoding (in hexadecimal) of ProtocolVersionList is: 31 05 03
28 03 31 2E 30. AlgorithmSuite provides a list of algorithm identifiers of hash and encMAC (Encryption-MAC pair) algorithms that the client supports. The server should choose a pair of hash and encMAC algorithm that is supported by the server and is the most favored among the available choices.
4.2.2.2
Welcome message
The server should send this message in response to Hello message from the client, if it consents upon an acceptable pair of algorithm and protocol version. If it cannot find such a match, it should respond with an appropriate error message ProtocolNotSupported or AlgorithmNotSupported. Welcome message means that the server has agreed upon a pair of hash and encMAC algorithm. The pair of algorithm that the server has agreed upon is included in this message. The server also specifies in this message, the server’s preferred protocol that is usually the highest version provided by the client that is also supported by the server. The ASN.1 representation of Welcome message is the following. Welcome ::= SEQUENCE { command IA5String("WLCM"), selectedProtocolVersion IA5String, selectedAlgorithmSuite SelectedAlgorithmSuite } SelectedAlgorithmSuite ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, encMACAlgorithm EncMACAlgorithm }
29 SelectedProtocolVersion contains the protocol version that the server has agreed upon. This must be one of the protocols mentioned in ProtocolVersionList sent by the client in Hello message. SelectedAlgorithmSuite contains the reference of the hash and encMAC algorithm selected by the server. The server must select one of the hash and encMAC algorithms present in AlgorithmSuite (in Hello message) with the following conditions. 1. The server supports the selected hash and encMAC algorithms. 2. Each of the selected hash and encMAC algorithms is the most favored amongst the available choices in its domain. If the client finds that selectedProtocolVersion or selectedAlgorithmSuite sent by the server are not among those sent by the client during the Hello message then it sends a ProtocolNotSupported or AlgorithmNotSupported error message. Otherwise, the client should start the Certificate Exchange stage after receiving this message.
4.2.3
Certificate Exchange stage
Certificate exchange serves two purposes - one, exchange of public key; two, verification that the public key is signed by the common root CA.
4.2.3.1
Certificates message
The sender presents the list of certificates in the certificate chain to let receiver know the sender’s public key and to allow the receiver verify the sender’s public key using its certificate chain.
30 The ASN.1 representation of Certificates message is the following. Certificates ::= SEQUENCE { command IA5String("CERT"), certificateList SEQUENCE OF Certificate −−X.509 v3 Certificate defined in RFC 5280 } certificateList is a list of ASN.1 certificates in the certificate chain, appended in order of their hierarchy. The former certificates are closer to the root CA than the latter certificates. All certificates are DER encoded. In particular, - Each of the certificate type must be X.509v3 [10]. - Each of the certificate must have RSA public key. - The last certificate in the list must be the sender’s certificate. - Each certificate in the certificate chain is verified by the public key in the certificate immediately preceding it in the certificate chain. The response of the Certificates message must be one of the following. a. Certificates message - If the received certificates are verified then the receiver sends its own certificate. b. Mutual Authentication stage is started - If the receiver has verified that the received certificates are okay and the receiver’s certificates are also verified, then it starts the mutual authentication stage. c. Error message - Either of ExpiredCertificate, RevokedCertificate or InvalidCertificate as listed in Section 4.2.8.2.
31
4.2.4
Mutual Authentication stage
In order to ensure that the other side has private key as claimed, each side needs to authenticate the other side through a series of challenge-response pairs. Session keys for encryption and MAC operations [28] are also derived in this stage.
4.2.4.1
Challenge message
This message carries the challenge issued by the client in order to authenticate the other party, i.e the server. The server, in response must send the Response message to the client which would enable the client to authenticate the server. The ASN.1 representation of Challenge message is the following. Challenge ::= SEQUENCE { command IA5String("CHLG"), challenge BIT STRING } The challenge is a random number, say R1, generated by the sender of this message. For this version of the specification, the random number chosen is 8 bytes long.
4.2.4.2
Response message
This is in response to Challenge message received by the party. The ASN.1 representation of Response message is the following. Response ::= SEQUENCE { command IA5String("RESP"), response BIT STRING }
32 The server calculates response according to the following steps. 1. The server generates a random number R2 and a key material K2. 2. The server then concatenates the random number generated, the random number received and the key material. M1 = R2kR1kK2. 3. The server computes the cryptogram as C1 = RSAES-OAEP-ENCRYPT (ClientPublicKey, M1, EMPTY) [13]. 4. The server computes the hash of the message H1 = Hash(M1) using the Hash algorithm negotiated in the Handshake stage. 5. The server computes the signature as S1 = RSASSA-PSS-SIGN (ServerPrivateKey, H1). 6. The response is concatenation of the cryptogram and its signature, response = C1kS1. For this version of specification, R2 and K2 are chosen to be 8-byte and 16-byte long random numbers respectively. RSAES-OAEP-ENCRYPT and RSASSA-PSSSIGN operations are the standard RSA operations as defined in PKCS #1 v2.1 [35]. In reply to Response message sent by the server, the client sends another Response message after going through the following steps. 1. The client verifies Response message sent by the server. Let M be the message received, then, the client verifies the signature using RSASSA-PSS-VERIFY (ServerPublicKey, M, S1). If the verification fails, the client responds with the error message ResponseVerificationFailed.
33 2. The client then decrypts the cryptogram to get M1. M1 = RSAES-OAEPDECRYPT(ClientPrivateKey, C1, EMPTY). 3. The client extracts the random number R1 and checks if it has the same value as was sent in Challenge message. If it has a different value, it responds with the error message ResponseVerificationFailed. 4. The client generates its own key material K1. 5. The client then concatenates the random number received, R2, and the key material K1. M2 = R2kK1. 6. The client computes the cryptogram as C2 = RSAES-OAEP-ENCRYPT (ServerPublicKey, M2, EMPTY). 7. The client computes the signature as S2 = RSASSA-PSS-SIGN(ClientPublicKey, C2). 8. The response sent by the client is the concatenation of the cryptogram and its signature, response = C2kS2. For this version of specification, R1 and K1 are chosen to be 8-byte and 16byte long random numbers respectively. RSASSA-PSS-VERIFY, RSAES-OAEPDECRYPT, RSAES-OAEP-ENCRYPT and RSASSA-PSS-SIGN operations are the standard RSA operations. In response to Response message sent by the client, the server responds according to the following. 1. The server verifies the Response message sent by the client. Let M be the message received, M = C2kS2. Then, the client verifies the signature using
34 RSASSA-PSS-VERIFY(ClientPublicKey, M, S2). If the verification fails, the client responds with the error message ResponseVerificationFailed. 2. The server then decrypts the cryptogram to get M1. M1 = RSAES-OAEPDECRYPT(ServerPrivateKey, C2, EMPTY). 3. The server extracts the random number R2 and checks if it has the same value as sent in the Challenge message. If it has a different value, it responds with the error message InvalidResponse. Otherwise, it responds with the Okay message. After the successful completion of the Mutual Authentication stage, the session keys for encryption, KEN C , and MAC computation, KM AC , are computed as follows. 0 0 1. Compute KEN C = HASH((K1 ⊕ K2)k0x00 00 00 01) and KM AC = HASH((K1 0 0 0 ⊕ K2)k0x00 00 00 02). Let KEN C and KM AC be l bytes long.
2. Let lKenc bytes and lKmac bytes be the lengths of the keys required for encryption and MAC algorithms respectively which were negotiated in the Handshake stage. Now the following cases arise. 0 (a) If l0 ≤ lKenc , KEN C is padded with ones in the end to get session key
for encryption, KEN C , such that length (in bytes) of KEN C equals lKenc . 0 KEN C = KEN C k1...1 |{z}. 0 Else KEN C equals first lKenc bytes of KEN C 0 (b) If l0 ≤ lKmac , KM AC is padded with ones in the end to get session key
for encryption, KM AC , such that length (in bytes) of KM AC equals lKmac . 0 KM AC = KM AC k1...1 |{z}. 0 Else KM AC equals first lKmac bytes of KM AC
35 Here HASH operation uses the hash algorithm negotiated in the Handshake stage.
4.2.5
Account Information stage
This stage is initiated only after the Mutual Authentication stage. All the messages in this stage shall be carried using the encryption and MAC algorithm negotiated during the Handshake stage and the session keys derived in Mutual Authentication stage. For convenience, the messages are shown in plain only.
4.2.5.1
AccountInformation message
This message carries the bank account information of the client and is sent using the secure channel. The information contained is the Track 2 information according to ISO/IEC 7813 [21] standard. This information is further signed by the user and countersigned by the bank. The ASN.1 representation of the AccountInformation message is the following. AccountInformation ::= SEQUENCE { command IA5String("ACCI"), myAccountInformation BIT STRING, certificateList SEQUENCE OF Certificate } myAccountInformation is computed according to the following steps. - Let I be the Track 2 account information of the user, in accordance to the ISO/IEC 7813 [21] standard. Compute the user’s digital signature, SU , on I as SU = RSASSA-PSS-SIGN(UserPrivateKey, I). - Concatenate I and user’s digital signature, SU to get S 0 . S 0 = IkSU .
36 - Compute the bank’s digital signature on S 0 . Call it SB . SB = RSASSA-PSSSIGN(BankPrivateKey, S 0 ). - Concatenate S 0 and SB . myAccountInformation = S 0 kSB . Here, RSASSA-PSS-SIGN operation is the standard RSA operation as defined in PKCS #1 v2.1 [35]. certificateList contains a chain of DER encoded certificates such that each of the certificate in the chain can be verified using the certificate immediately preceding it in the chain. The first certificate in the certificate chain is the certificate of the entity next to root CA. The last certificate in the certificate chain is the certificate of user. UserPrivateKey and BankPrivateKey are the user’s private key (corresponding to the user’s public key in the certificateList) and the bank’s private key (corresponding to the bank’s public key in the certificateList) respectively. One of the following messages must be sent by the server using the secure channel in response to the AccountInformation. Okay - Account information is successfully verified, proceed to the Transaction stage. AccountInfoNotVerified - Account information could not be verified.
4.2.6
Transaction stage
Only after the client receives the Okay message in response to AccountInformation message sent, the transaction details are sent. All the messages in this stage are sent over the secure channel.
37 4.2.6.1
Transaction message
The ASN.1 representation of Transaction message is the following. Transaction ::= SEQUENCE { command IA5String("TRNS"), CHOICE { withdrawMoney [0] WithdrawMoney, transferMoney [1] TransferMoney ... } } WithDrawMoney ::= SEQUENCE { amount INTEGER } TransferMoney ::= SEQUENCE { amount INTEGER, remoteAccountDetails BankAccountDetails } BankAccountDetails ::= SEQUENCE { bankBranchCode BIT STRING, ifscCode BIT STRING, swiftCode BIT STRING, accountCode BIT STRING, ... } The amount is the amount of money that the user wants to withdraw from the outlet or transfer to a remote account.
bankBranchCode, ifscCode, swiftCode and accountCode refer to the bank branch code, the bank branch’s IFSC code, the bank branch’s SWIFT code and the user’s account code respectively.
38
4.2.7
Close Connection stage
The message in this stage is also sent over the secure channel.
4.2.7.1
CloseConnection message
This message is sent by the client when the user does not want to do any more transactions. CloseConnection ::= SEQUENCE { command IA5String("CLSC"), ... }
4.2.8
Supplementary Messages
4.2.8.1
Indication messages
Okay: This message is sent by the server to the client to denote the successful completion of the Mutual Authentication stage, Account Information stage and the Transaction stage. InvalidResponse ::= SEQUENCE { command IA5String("OKAY"), ... }
4.2.8.2
Error messages
AlgorithmNotSupported: If the server doesn’t find a mutually agreeable algorithm in the Handshake stage, it sends this message in response to the Hello message. If the client doesn’t find the algorithm acceptable in the Welcome message, it sends
39 this message in response to the Welcome message. AlgorithmNotSupported ::= SEQUENCE { command IA5String("ANSP"), ... } ExpiredCertificate: If a party receives Certificates message and finds out that a certificate in the certificate chain is an expired one, it sends this error message. ExpiredCertificate ::= SEQUENCE { command IA5String("ECRT"), ... } ImpermissibleTransaction: This message is sent in response to the Transaction message, if that transaction is not permitted by the server. ImpermissibleTransaction ::= SEQUENCE { command IA5String("ITNS"), ... } AccountInfoNotVerified: This message is sent by the server in response to AccountInformation message, if the user’s or bank’s signature on the account information could not be verified. InvalidAccountInformation::= SEQUENCE { command IA5String("AINV"), ... } InvalidCertificate: If a party receives Certificates message and finds out that
40 a certificate in the certificate fails in certificate verification, it sends this error message. InvalidCertificate ::= SEQUENCE { command IA5String("ICRT"), ... } InvalidCommand: This message is sent when the last message received does not represent a valid command. InvalidCommand ::= SEQUENCE { command IA5String("ICMD"), ... } InvalidResponse: This message is sent when the received Response message does not contain the expected random number. InvalidResponse ::= SEQUENCE { command IA5String("IRSP"), ... } ProtocolNotSupported: If the server doesn’t find a mutually agreeable protocol in the Handshake stage it sends this message in response to the Hello message. ProtocolNotSupported ::= SEQUENCE { command IA5String("PNSP"), ... } RevokedCertificate: If a party receives Certificates message and finds out that one or more of the certificates in the certificate chain have been revoked, it sends this
41 message. RevokedCertificate ::= SEQUENCE { command IA5String("RCRT"), ... } ResponseVerificationFailed: This message is sent in response to the Response message, if the random number received in the Response message does not match the random number sent. ResponseVerificationFailed ::= SEQUENCE { command IA5String("RPVF"), ... } UnexpectedCommand: This message is sent when some valid but unexpected command is received. UnexpectedCommand ::= SEQUENCE { command IA5String("UCMD"), ... }
42
Chapter 5 Design and Implementation There can be three scenarios possible as shown in Figure 5.1. We shall discuss these scenarios in reverse order, i.e. from the least preferred to the most preferred scenario. ATM
Mobile
Card
I
II
III
Figure 5.1: Possible Implementation Scenarios
In the Third case, the user has a personal electronic device (e.g. a mobile phone) which is capable of communicating with the financial service outlet via bluetooth [1]
43 or USB [2] or Infra Red technology. All the user’s personal information, the user’s digital certificate chain, account information is stored in the device. The session keys used in secure communication are derived between the device and the outlet. In this scenario the confidentiality of the session keys cannot be ensured since the session keys reside in the memory of the device. An attacker can possibly install a malware program (e.g. Spyware) that resides in the device’s memory and leaks the session key and therefore, this scenario is least preferred. In the Second case, the user is only provided a smart card. The user’s digital certificate chain, the private key corresponding to the user’s digital certificate and account information are stored securely in the smart card. The smart card uses PKI operations as defined in ISO7816-8 [19] to establish a secure communication channel with the outlet. This case is more secure compared to the third case as smart cards are known to store the information securely. However, the only downside of this scenario is that the cryptographic computation cost is incurred by the smart card. This would increase the per transaction time and thus is not very favorable. Also this scenario is still susceptible to fake keypad overlay attack and shoulder surfing (Chapter 2). First case takes the best of both worlds. Introduction of electronic device ensures faster transaction and smart card ensures data protection. This scheme prevents attacks like skimming device attack, shoulder surfing and fake keypad overlay attack. The user enters the confidential information (PIN) on his personal device which he can safely trust. As we saw that the account information and the transaction details between the personal device and the outlet are exchanged over a secure channel, possibility of mischief by omnipresent eavesdropper is eliminated.
44
5.1
Steps in the proposed model
Choosing the smart card as storage device for private information and certificates, mobile phone as the personal electronic device, and ATM as the service provider, the steps involved in the Protocol Model are the following. 1. Registration of the user with the bank. During the registration, the user is issued a smart card which carries a certificate chain, account details, PIN and the private key of the user. Only after the user enters the correct PIN can he be allowed by the smart card to use the private key. 2. The user authenticates himself to the smart card using his PIN. 3. The mobile phone reads the certificate chain from the smart card and an exchange of certificates between the mobile phone and the ATM takes place. 4. ATM and the mobile phone do mutual authentication to ensure that the other side possesses the private key as claimed. The session key is also established in this process. This stage requires PKI operations to be done by the smart card. 5. The mobile phone sends the bank account information of the user, signed by the user and counter signed by the bank to the ATM over a secure channel. 6. The user now does multiple transactions with the ATM over the secure channel by using his mobile phone. The outlet-phone communication can be established using either Bluetooth [1], USB [2] or Infra Red technologies and the phone-card communication using NFC technology [5] [6]. A contactless ISO 14443 [22] compatible smart card stores the certificate chain, user’s private key, the user’s account information and user’s PIN. Optionally
45 the account balance and transaction log can also be stored in the card. The card communicates [31] with the phone using NFC. The need of using a smart card arises from the fact that the data stored in the smart card can be protected against unauthorized access and manipulation [32]. The ATM keeps the log of the transaction details and periodically updates it to a centralized location.
5.2
Cryptography at the client side
The session keys are always to be derived between the end entities (between the outlet and the card in Scenario I and II and outlet and electronic device in Scenario III, Figure 5.1). The protocol is designed keeping client side cryptography in mind. By the virtue of the mutual authentication stage of the protocol, we can easily use the protocol in conjugation with a smart card. In such cases (Scenario I and II respectively, Figure 5.1), the personal device, outlet respectively can issue commands like GET CHALLENGE, MUTUAL AUTHENTICATION, PSO COMPUTE DIGITAL SIGNATURE commands (as defined in ISO7816-8 [19]) to the card.
5.3
Implementation
We implemented the protocol to work over the connection oriented TCP (Transmission Control Protocol) protocol. In our implementation, the outlet and the client both are personal computers which can run Java Runtime Environment. We chose Java as a choice of implementation language because it can be easily ported to a mobile device environment which is one of our possible implementation scenarios.
46 The following Java packages are used in our implementation. 1. J2SE. Java Platform, Standard Edition (Java SE 6). 2. Bouncy Castle Crypto APIs [39]. Bouncy Castle, Release 1.43 for Java SE 6. The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms. Our motivation for using Bouncy Castle API from the fact that this library can be used as JCE provider, implements over 400 cryptographic algorithms and is well supported by an open source community. Besides this, it provides an easy platform for encrypting and decrypting ASN.1 objects. The pseudo code structure of an ASN.1 object in our implementation is given below. import org.bouncycastle.asn1.*; public class ASN1Object extends ASN1Encodable { // class fields /* create object from parameters */ public ASN1Object(...) {} /* create object from ASN.1 stream */ public ASN1Object(ASN1Sequence seq) {} /* converts the class object to ASN.1 stream */ @Override public DERObject toASN1Object() {} }
By virtue of this structure, the same class can be used to encode and decode ASN.1 Objects.
47
5.3.1
Storing transaction logs
Each transaction is stored (in a fixed length format) with the outlet and optionally with the client device.
Field Track 2 Information † Date (YYYYMMDD) Space (in bytes) 30 4 Field Transaction Type Amount (in Rs) Space (in bytes) 1 2 Field Comments Space (in bytes) 30
Time (HHMMSS) 3 Account Information ‡ 65
† According to ISO 7813 [21] ‡ Bank Brach Code (9), IFSC Code (11), SWIFT Code (11), Account Number (34)
5.3.2
Testing
Testing is also an essential part of code development. We rigorously tested the implementation for errors and exceptions. Test cases were designed which include message dropping, message modification, message not following the protocol order, algorithms not implemented, etc. We tested the code for race conditions.
5.4 5.4.1
Related Technologies NFC
NFC stands for Near Field Communication. It is a short range, high frequency wireless communication technology which enables the exchange of data between two devices over a few centimeters distance. NFC relies on the principle of inductive coupling and is globally available in 13.56 MHz range with data transfer speed upto 424 kbps [5]. The technology extends ISO 14443 [22] proximity card standard which
48 ensures that it can interface with a smart card. This technology is primarily targeted to be used in mobile phones coupled with an embedded smart card so that it would enable an ease in public transportation and payment systems.
5.4.2
Bluetooth
Bluetooth (ratified as IEEE Standard 802.15.1) is an open wireless protocol that lets two devices communicate within a Personal Area Network (PAN) at distances upto 10 meters. Bluetooth works on a radio technology called frequency hopping spread spectrum which enables it to hop the communication over 79 frequencies. The bluetooth has an ability to work over a variety of protocols as defined by bluetooth SIG [1]. Some of the widely used are L2CAP (Logical Link Control and Adaptation Protocol) and RFCOMM (Radio Frequency Communication) which provides emulated RS-232 serial ports.
5.5
Discussions
The following section describes how our model addresses the critiques of the current financial service model.
5.5.1
Addressing the issues
In Section 2.3, we discussed and classified the various shortcomings of the current model in four major issues. In this section, we explain one by one how the proposed model addresses these issues.
49 5.5.1.1
Security Issue.
In the new model, a mutual trust is established between the user and the outlet. Both the user and the outlet authenticate each other using PKI. If the outlet is fake, the user will get to know about it and will not reveal his personal and confidential information to the fake outlet. In this way Bogus outlet attack (Section 2.2.1) cannot take place. Attacks like Shoulder surfing and Fake keypad overlay attack (Section 2.2.3, 2.2.4) are also precluded. This happens because now the user does not need to type his PIN at non-trusted locations. He can use the trusted keypad hardware of his personal electronic device hence preventing such attacks. Addition of smart card as means of storing data securely renders the use of skimming devices (Section 2.2.2) ineffective.
5.5.1.2
Network Issue.
A financial service outlet requires a persistent connection to the network to be able to authenticate the user using the user’s PIN and his account information. Since in the proposed model, the outlet authenticates the user using PKI, it does not require persistent network connectivity for authenticating the user. This saves a lot of operational overhead of the outlet. Most financial services which use the network, claim round the clock availability. However, networks are said to be inherently unreliable to an extent. Removing the need of persistent network connectivity makes the service more dependable.
50 5.5.1.3
Cost Issue.
Typically an outlet would require a display device (e.g. Monitor) and an input device (e.g. Keyboard). For a service outlet like an ATM, more hardware also implies additional cooling costs. This swells up the cost of the outlet. The proposed model would do away with the need of either of the above, since, the user can make use of his personal electronic device as an I/O device.
5.5.1.4
Comfort Issue.
One single smart card can store a number of applications, each for the service the user has access to. This eliminates the need to carry different card for each of the service. In places like gas (petrol) dispensing stations, the user can still sit in his car and use the smart card and a personal device (e.g. a phone with bluetooth) to do the transaction without physically having to get off the car. This way the model is more convenient and comforting to the users.
5.5.2
More Discussions
A few things that are left out and out of the scope of this thesis but are important for the successful working of the model are discussed below. How to prevent money overdrawing? A user can withdraw more money than his account balance and the outlet won’t know of this because it is not connected to any network. To prevent this, a counter denoting the current account balance is securely stored in the card which can only be changed by a trusted outlet. Need to carry multiple cards? One single smart card can store a number of appli-
51 cations, each for the service the user has access to. This eliminates the need to carry different card for each of the service. How soon to update transaction log? This depends on the policy of the outlet owner. It could vary from few hours to a couple of days. The account information at the central server is stale between two consecutive updates to the server. How to update? Updating the transaction log can be done manually (a person could do it using a memory stick) or automatically (using Dial-on-Demand Routing). Security of the outlet? Mischievous users can possible try to break/destroy the outlet after withdrawing money and before the outlet updates data to the central server. The outlet owner is responsible for providing security to the outlet.
52
Chapter 6 Conclusion and Future Work 6.1
Conclusion
In this work, we have proposed a new transaction model for financial services which addresses the various concerns related to the existing transaction model. As is evident from the discussion in the various chapters, there is a requirement to provide lower cost and more secure model for financial services. Lower cost financial services would enable the financial institutions to reach the rural population and contribute to rural development. Also, amidst the sharp rise in the cases of identity theft such as credit card identity theft and credit card frauds, we learnt the lesson not to trust the hardware of a public financial service outlet. The model utilizes public key infrastructure (PKI) to ensure that both these requirements are met. PKI allows offline authentication which eliminates the requirement of a dedicated network. Using PKI, mutual authentication is also possible, implying that users are no longer forced to trust a financial service outlet. We have also made an attempt to design a secure protocol for this model. The
53 protocol does not rely on the security architecture of the underlying communication channel (bluetooth etc.) used for its working. Cracking this protocol is equivalent to the problem of breaking the algorithms used by it (here RSA). Smart cards provide a tamper-proof storage media and protect data against unauthorized reading or copying [32]. This renders the use of skimming devices ineffective. The client-server protocol was implemented on a Java platform and tested.
6.2
Future Work
We discussed the most favored implementation scenario where an NFC enabled mobile phone communicates to an ISO 14443 compliant contactless smart card to do the transaction. SCOSTA now supports PKI [16] operations. The Java code implementation can be suitably modified and ported to the mobile environment to create MIDP (Java ME) application to run on the mobile device supporting JSR257 (for NFC). The application can then communicate with the SCOSTA-PKI smart card for PKI operations.
54
Bibliography [1] Bluetooth Special Interest Group. website: http://www.bluetooth.org. [2] Universal Serial Bus - Implementers Forum. website: http://www.usb.org. [3] A Little World. website: www.alittleworld.com. [4] ASN.1 Consortium. website: http://www.asn1.org/. [5] Near Field Communication forum. website: http://www.nfc-forum.org. [6] Nokia 6131 Phone. Nokia http://europe.nokia.com/A4142118.
Corporation.
website:
[7] Zero Mass Foundation. website: http://www.alittleworld.com/htmls/zmf.html. [8] ATM Scam. Bank ATMs converted to steal bank customer IDs. http://www.utexas.edu/police/alerts/atm scam/.
Online:
[9] Businesswireindia. A branchless banking form. Press Release, September 2008. http://www.businesswireindia.com/PressRelease.asp?b2mid=16867.
platOnline:
[10] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. RFC5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC Editor, United States, May 2008. [11] Diebold, Incorporated. ATM Fraud and Security - White Paper, September 2006. Online: http://www.diebold.com/atmsecurity/resources.htm. [12] Olivier Dubuisson and Philippe Fouquart. ASN.1: communication between heterogeneous systems. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2001. [13] Eiichiro Fujisaki, Tatsuaki Okamoto, David Pointcheval, and Jacques Stern. RSA-OAEP Is Secure under the RSA Assumption. J. Cryptol., 17(2):81–104, 2004.
55 [14] A. Gaurav, A. Sharma, V. Gelara, and R. Moona. Using Personal Electronic Device for Authentication-Based Service Access. pages 5930–5934. Communications, 2008. ICC ’08. IEEE International Conference on, May 2008. [15] Abhishek Gaurav, Ankit Sharma, Vikas Gelara, and Rajat Moona. Using mobile device for authentication and service-access. Indian Patent Office, April 2008. Patent application number 1018/Del/2008. [16] Aditi Gupta. Design and Implementation of Public Key Infrastructure on Smart Card Operating System. Master’s thesis, Department of Computer Science, IIT Kanpur, June 2008. [17] Fengling Han, Jiankun Hu, Xinghuo Yu, Yong Feng, and Jie Zhou. A Novel Hybrid Crypto-Biometric Authentication Scheme for ATM Based Banking Applications. In David Zhang and Anil K. Jain, editors, ICB, volume 3832 of Lecture Notes in Computer Science, pages 675–681. Springer, 2006. [18] Inforesources. Accessing Financial Services in Rural Areas, September 2008. Online: http://www.inforesources.ch/pdf/focus08 2 e.pdf. [19] ISO/IEC. ISO/IEC 7816-8, Information Technology-Identification cards - Integrated circuit(s) cards with contact - Part-8: Security related Interindustry commands, first edition, October 1999. Ref. no: ISO/IEC 7816-8:1999(E). [20] ISO/IEC. ISO/IEC 8583-1, Financial transaction card originated messages Interchange message specifications - Part 1: Messages, data elements and code values, first edition, 2003. Ref. no: ISO/IEC 8585-1:2003. [21] ISO/IEC. ISO/IEC 7813, Information technology - Identification cards - Financial transaction cards, sixth edition, July 2006. Ref. no: ISO/IEC 7813:2006(E). [22] ISO/IEC. ISO/IEC 14443-3, Identification cards - Contactless integrated circuit cards - Proximity cards - Part 3: Initialization and anticollision, 2008. Ref. no: ISO/IEC 14443-3:2006(R). [23] Ashok Jhunjhunwala. Banking towards Rural Empowerment: challenges and opportunities, September 2006. [24] Amila Karunanayake, Kasun De Zoysa, and Sead Muftic. Mobile ATM for developing countries. In MobiArch ’08: Proceedings of the 3rd international workshop on Mobility in the evolving internet architecture, pages 25–30, New York, NY, USA, 2008. ACM. [25] Jonathan Katz and Yehuda Lindell. Introduction to Modern Cryptography. CRC Press, 2007.
56 [26] Joanna. Ledgerwood and Sustainable Banking with the Poor (Project). Microfinance handbook : an institutional and financial perspective / Joanna Ledgerwood. World Bank, Washington, D.C. :, 1999. [27] London Evening Standard. Fraudsters use Tube machines to clone bank cards. Online: http://www.thisislondon.co.uk/standard/article-23421006details/Fraudsters+use+Tube+machines+to+clone+bank+cards/article.do. [28] Alfred J. Menezes, Scott A. Vanstone, and Paul C. Van Oorschot. Handbook of Applied Cryptography. CRC Press, Inc., Boca Raton, FL, USA, 1996. [29] Nitin Munjal and Rajat Moona. Secure and Cost Effective Transaction Model for Financial Services. OPNTDS - 2009, 2009. [30] Nitin Munjal, Ashish Paliwal, and Rajat Moona. Low Cost Secure Transaction Model for Financial Services. In International Conference on Security and Identity Management (SIM)-09, IIM Ahmedabad, India, May 2009. [31] National Informatics Centre, Government of India, Indian Institute of Technology Kanpur. SCOSTA-CL: Specifications for the Smart-Card Operating System with Contact-less Interface, Version 1.2, July 2007. [32] Wolfgang Rankl and Wolfganf Effing. Smart Card Handbook. Wiley, third edition, June 2002. [33] Rediff News. Mobile banking, boon for rural India. News Article, February 2008. Online: http://in.rediff.com/money/2008/feb/20mob.htm. [34] Research for Development. Improving access nancial services through new technologies. http://www.research4development.info/news.asp?ArticleID=50373.
to fiOnline:
[35] RSA Laboratories. PKCS #1 v2.1: RSA Cryptography Standard, February 2003. [36] Robin Sharp. Principles of Protocol Design. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1994. [37] Standard Chartered. Cardless Cash, Mobile Banking. [38] Margaret. Tan. E-payment : The Digital Exchange. Ridge Books, Singapore, 2004. [39] The Legion of the Bouncy Castle. http://www.bouncycastle.org/.
Bouncy Castle Crypto APIs.
Online:
[40] The Network World. Credit Card Skimming. Online: http://www.networkworld.com/community/node/33210?page=0%2C0.
