See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/224085982

Secure and cost effective transaction model for financial services

Conference Paper · November 2009

DOI: 10.1109/ICUMT.2009.5345473 · Source: IEEE Xplore

CITATIONS READS
12 288

2 authors, including:

R. Moona
Indian Institute of Technology Bhilai
41 PUBLICATIONS   177 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Book for teaching Assembly Language programming View project

All content following this page was uploaded by R. Moona on 11 June 2014.

The user has requested enhancement of the downloaded file.

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 pop-

ular 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. auto-

mated 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 is-

sues of the conventional Financial Service Model. The use of public key infrastructure

(PKI) based authentication scheme enables offline mutual trust establishment and re-

moves 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 iv

1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Organization of Report . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Financial Services 8
2.1 Electronic Payment Systems . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Instruments of e-commerce . . . . . . . . . . . . . . . . . . . . 9
2.2 Attacks on Financial Service Outlets . . . . . . . . . . . . . . . . . . 10
2.2.1 Bogus outlet attack. . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Use of skimming devices. . . . . . . . . . . . . . . . . . . . . . 10
2.2.3 Shoulder surfing. . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.4 Fake keypad overlay attack. . . . . . . . . . . . . . . . . . . . 12
2.3 Problem Classification . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1 Security Issue. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 Network Issue. . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3 Cost Issue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.4 User Inconvenience . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Proposed Financial Transaction Model 16

3.1 Model in Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Enhanced Security Features in Our Model . . . . . . . . . . . . . . . 20

4 Protocol for Proposed Financial Transaction Model 22

4.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Protocol Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1 Protocol Versioning . . . . . . . . . . . . . . . . . . . . . . . . 24
 iii

4.2.2 Handshake Stage . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.2.1 Hello message . . . . . . . . . . . . . . . . . . . . . 24
4.2.2.2 Welcome message . . . . . . . . . . . . . . . . . . . . 28
4.2.3 Certificate Exchange stage . . . . . . . . . . . . . . . . . . . . 29
4.2.3.1 Certificates message . . . . . . . . . . . . . . . . . 29
4.2.4 Mutual Authentication stage . . . . . . . . . . . . . . . . . . . 31
4.2.4.1 Challenge message . . . . . . . . . . . . . . . . . . . 31
4.2.4.2 Response message . . . . . . . . . . . . . . . . . . . 31
4.2.5 Account Information stage . . . . . . . . . . . . . . . . . . . . 35
4.2.5.1 AccountInformation message . . . . . . . . . . . . . 35
4.2.6 Transaction stage . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.6.1 Transaction message . . . . . . . . . . . . . . . . . 37
4.2.7 Close Connection stage . . . . . . . . . . . . . . . . . . . . . . 38
4.2.7.1 CloseConnection message . . . . . . . . . . . . . . . 38
4.2.8 Supplementary Messages . . . . . . . . . . . . . . . . . . . . . 38
4.2.8.1 Indication messages . . . . . . . . . . . . . . . . . . 38
4.2.8.2 Error messages . . . . . . . . . . . . . . . . . . . . . 38

5 Design and Implementation 42

5.1 Steps in the proposed model . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Cryptography at the client side . . . . . . . . . . . . . . . . . . . . . 45
5.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3.1 Storing transaction logs . . . . . . . . . . . . . . . . . . . . . 47
5.3.2 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4 Related Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4.1 NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5 Discussions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5.1 Addressing the issues . . . . . . . . . . . . . . . . . . . . . . . 48
5.5.1.1 Security Issue. . . . . . . . . . . . . . . . . . . . . . 49
5.5.1.2 Network Issue. . . . . . . . . . . . . . . . . . . . . . 49
5.5.1.3 Cost Issue. . . . . . . . . . . . . . . . . . . . . . . . 50
5.5.1.4 Comfort Issue. . . . . . . . . . . . . . . . . . . . . . 50
5.5.2 More Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 50

6 Conclusion and Future Work 52

6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Bibliography 54
 iv

List of Figures

2.1 A skimming device mounted on Automated Teller Machine [8] . . . . 11

2.2 Camera used in conjunction with a skimming device. [40] . . . . . . . 12
2.3 A fake keypad overlay [27] . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Financial Service Model . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Verification of certificate chain . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Presentation of Account Information . . . . . . . . . . . . . . . . . . 20

4.1 Transaction Service Protocol - Client Side . . . . . . . . . . . . . . . 25

4.2 Transaction Service Protocol - Server Side . . . . . . . . . . . . . . . 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 orga-

nizations 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 or-

ganizations 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 com-

fort. 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 ser-

vices 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 consti-

tutes 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 trans-

action 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 com-

municate 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 stud-

ied 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 re-

ceiving 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 in-

ternet 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 authen-

tication, first using PKI based authentication and second using biometric trait like

a fingerprint. This scheme prevents card forgery and phishing attacks but the bio-

metric 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 Gra-

mateller 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 approxi-

mately 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 imple-

mentation 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 unau-

thorized 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 em-

ploys 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 de-

vices 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 conve-

nience 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 authentica-

tion 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 cen-

tralized 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 au-

thentication 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 authenti-

cation 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
User Outlet

Certificate Exchange

1. Verify 1. Verify
2. Get Public 2. Get Public
Key Mutual Authentication and Key

Key Establishment
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 cer-

tificates. 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 en-

tity, 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 Trusted Authority
India)

Verify Certificate validity,

verify this is signed by Root CA Bank 1 Untrusted Authority

Verify Certificate validity,

verify this is signed by Bank 1
if Bank 1's certificate is verified Untrusted Untrusted
Saving Accounts
ATM Authority
Authority

Untrusted Untrusted

ATM at location X 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 estab-

lished, 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 certifi-

cate 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 con-

nection 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 establish-

ment 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 ser-

vice 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 applica-

tion 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

Received:
send ProtocolNotSupported /
Hello AlgorithmNotSupported

Received:
Welcome
Received:
ExpiredCertificate / Y N send
RevokedCertificate / send Is message
ProtocolNotSupported /
InvalidCertificate Certificates okay? AlgorithmNotSupported
Received:
Certificates

send ExpiredCertificate / Y
N Certificate
RevokedCertificate / send
InvalidCertificate Verification Challenge
successful?
Received:
Response
At any state, if the receiver receives
any invalid command or any unexpected
N send
command, it sends InvalidCommand and Is message
ResponseVerificationFailed /
UnexpectedCommand message respectively okay? InvalidResponse
and goes back to the ready state.

Upon reception of InvalidCommand or Y

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 Received:

compute session key, InvalidAccountInformation
incorrect (wrong MAC or bad encryption),
send
the session is aborted and the client
AccountInformation
goes back to ready state.

Received: Okay Received:

InvalidTransaction /
send ImpermissibleTransaction
Transaction

Received: Okay

Y
Do more
Transaction?

send
CloseConnection

Figure 4.1: Transaction Service Protocol - Client Side

 26

Ready
Listening

Received:
Hello

send N Is Protocol /
ProtocolNotSupported / Algorithm
AlgorithmNotSupported supported?

Y
Received:
ProtocolNotSupported / Received:
AlgorithmNotSupported Certificates Certificates N send ExpiredCertificate /
send
Welcome verification RevokedCertificate /
successful? InvalidCertificates

Y
Received:
ResponseVerificationFailed / Received:
InvalidResponse Challenge send
send Response
Certificates

Received:
Response

send N Is message
ResponseVerificationFailed /
InvalidResponse okay?

send
Okay

Received:
At any state, if the receiver receives AccountInformation
any invalid command or any unexpected
command, it sends InvalidCommand and
UnexpectedCommand message respectively
and goes back to the ready state. Is N
AccountInformation send
InvalidAccountInformation
Upon reception of InvalidCommand or correct?
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 Received:
Transaction
goes back to ready state.

Is N
Transaction send InvalidTransaction /
Received: ImpermissibleTransaction
Transaction valid?

send Y
Okay
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 enc-

MAC 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 usu-

ally 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 algo-

rithm selected by the server. The server must select one of the hash and encMAC

algorithms present in AlgorithmSuite (in Hello message) with the following condi-

tions.

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, veri-

fication 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 cer-

tificate 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 num-

ber received and the key material. M1 = R2kR1kK2.

3. The server computes the cryptogram as C1 = RSAES-OAEP-ENCRYPT (Client-

PublicKey, 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 (ServerPri-

vateKey, 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-PSS-

SIGN 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-OAEP-

DECRYPT(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 (Server-

PublicKey, 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 16-

byte long random numbers respectively. RSASSA-PSS-VERIFY, RSAES-OAEP-

DECRYPT, 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-OAEP-

DECRYPT(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 encryp-

tion and MAC algorithms respectively which were negotiated in the Handshake

stage. Now the following cases arise.

(a) If l0 ≤ lKenc , KEN

0
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

(b) If l0 ≤ lKmac , KM
0
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 mes-

sages 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-PSS-

SIGN(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 rep-

resent 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 com-

mand 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 ex-

change 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 technol-

ogy [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 com-

municates [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 respec-

tively, 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 (Trans-

mission 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 algo-

rithms. 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) Time (HHMMSS)

Space (in bytes) 30 4 3
Field Transaction Type Amount (in Rs) Account Information ‡
Space (in bytes) 1 2 65
Field Comments
Space (in bytes) 30
† 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 Related Technologies

5.4.1 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 emu-

lated RS-232 serial ports.

5.5 Discussions

The following section describes how our model addresses the critiques of the cur-

rent 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 skim-

ming 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 infras-

tructure (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 Corporation. website:

http://europe.nokia.com/A4142118.

[7] Zero Mass Foundation. website: http://www.alittleworld.com/htmls/zmf.html.

[8] ATM Scam. Bank ATMs converted to steal bank customer IDs. Online:
http://www.utexas.edu/police/alerts/atm scam/.

[9] Businesswireindia. A branchless banking plat-

form. Press Release, September 2008. Online:
http://www.businesswireindia.com/PressRelease.asp?b2mid=16867.

[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 het-
erogeneous 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. Communica-
tions, 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 Ap-
plications. 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 - In-

tegrated 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 - Finan-

cial 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 devel-
oping 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). Microfi-
nance 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-23421006-
details/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 Transac-
tion 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 Technol-
ogy 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 to fi-
nancial services through new technologies. Online:
http://www.research4development.info/news.asp?ArticleID=50373.
[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. Bouncy Castle Crypto APIs. Online:
http://www.bouncycastle.org/.
[40] The Network World. Credit Card Skimming. Online:
http://www.networkworld.com/community/node/33210?page=0%2C0.

View publication stats