Anti-Credit-Card-Fraud System--An Implementation Based on Patent Application (P307590GB)
Bangdao Chen
Keble College
University of Oxford
Supervised by Prof. Bill Roscoe
Oxford University Computing Laboratory
A dissertation submitted for the degree of Master of Science
in Computer Science
September 2007
Abstract
Approximately £428m was lost last year due to fraud on Credit Cards in the UK. In order to solve the problem, based on patent application P307590GB [Roscoe, 2006 a], we introduce a new device named Security Device to separate credit card from the merchant’s machine and use it to send Credit Card information (encrypted) to the merchant’s machine, as the merchant cannot read encrypted information, he has to send it to the bank and then the bank will tell the merchant whether the information is valid or not. With SD, we can successfully separate the credit card from the hand of malicious merchant or staff and greatly improve the security of credit card transaction.
The internal mechanism is mainly based on the HCBK (Hash Commitment Before Knowledge) protocol originally introduced in [Roscoe, 2006 b], the implementation mainly consists of two programs, one is SD client, the other is Merchant server.
Keywords: Credit-Card-Fraud, SD, HCBK, SHCBK, SD-M-HCBK, SD client, Merchant server
Acknowledgement
I would like to express my gratitude to my supervisor, Prof. Bill Roscoe, for guiding me through out the project. His kind suggestions and encouragement have helped me to overcome many difficulties that I have met when doing this project. Also I would like to thank Dr. Long Nguyen who has given me many advices when implementing the protocol. At the same time, I want to thank my friend Yuedong Song who has accompanied with me in the Lab during the past three months.
Contents
Introduction 3
1.1 News 3
1.2 Ideas 4
1.3 Main Contributions 4
1.4 Structure of the Thesis 7
Constructing System Model 8
2.1 Requirement Analysis 8
2.1.1 SD 8
2.1.2 Security 8
2.1.3 Transaction 9
2.1.4 Communication 9
2.2 Designing SD 10
2.3 Protecting the System 11
2.3.1 Finding the Right Protocol 11
2.3.2 Choosing Cryptographic Algorithms 15
2.4 The Blue-Print of the Credit Card Transaction 16
2.5 Designing Communication Mechanism of the System 19
2.5.1 Why TCP/IP 20
2.5.2 Why SSL v.3 22
Problems and solutions 23
3.1 System Analysis 23
3.1.1 Protocol Security 23
3.1.2 Communication Problems 24
3.2 Solutions 27
User Instructions 34
4.1 Usages 34
Scenario 1: 34
Scenario 2: 34
Scenario 3: 35
4.2 How to Use SD 35
Introduction to Implementation 39
5.1 Main Structure 39
Multi-process 39
Merchant Server 39
SD Client 40
SD (visualized) 40
5.2 The Balance between Cost and Security 41
Bibliography 44
Appendix A: Developers’ Handbook 46
Appendix B: RSA example 64
2
Chapter 1
Chapter 1
Introduction
1.1 News
Let us read a piece of news which was published in Feb 2007 [Mcewen, 2006]:
“MORE than 100 motorists have fallen victim to a card-cloning gang after visiting an Edinburgh petrol station.” “The gang managed to grab tens of thousands of pounds from the drivers' accounts after copying their card details at the BP garage in Barclay Place, Bruntsfield.”
How could this happen? A staff in that garage put a skimming device on the station’s credit card reading machine, so when the customer is making the payment, the information stored in the magnetic strip on the credit card is copied by the skimmer, and a small camera records the buttons pushed by the customer when they are making the input of PIN, then after the payment was made, the credit card was actually stolen even without taking the credit card away. We could call this technique Credit Card Cloning.
As reported by APACS (stands for the UK payment association) [APACS, 2006], approximately £428m was lost last year due to fraud on Credit Cards, and according to the following statistics:
CARD FRAUD LOSSES 2006 (Source from APACS)
· Counterfeit cards: £100m - up 3%,
· Stolen or lost cards: £68m - down 23%,
· Cards not present: £213m - up 16%,
· Intercepted in mail: £15m - down 62%,
· ID theft: £32m - up 5%,
· Total: £428m - down 3%.
Although the total lost has decreased, we can see that it is largely due to the drop in “Stolen or lost cards” and “Intercepted in mail “fields, no signs show that Credit Card Cloning is decreasing, because it differs from normal card stealing. If there is one malicious merchant or shop staff who wants to steal the information of your credit card, you can hardly realize it and then prevent this from happening.
1.2 Ideas
If we could separate credit card from the merchant’s machine, use another trusted machine to “physically contact” the credit card and read the information, and then send the information (encrypted) to the merchant’s machine, as the merchant cannot read encrypted information, he has to send it to the bank and then the bank will tell the merchant whether the information is valid or not. With this trusted machine, we can successfully separate the credit card from the hand of malicious merchant or staff and greatly improve the security of credit card transaction.
Therefore now we can imagine that the trusted machine should have a card reader, an input device, and a screen to display information, also with modules of connection in order to communicate with merchant’s machine to fulfil the transaction. We call the trusted machine Security Device (SD) in the following chapters.
1.3 Main Contributions
The user will commit to a b-digit[1] number which is formed by hashing the entire details of the session. If the number is correct, the user has a high degree of assurance that he is actually dealing with the merchant. Let’s discuss a concrete example to get a better understanding of this authentication mechanism.
The picture presented above shows how the authentication mechanism works. Firstly, SD starts to run protocol with Merchant server, and after a few messages, Merchant server displays a b-digit number where it can be seen by user (for example, on a screen). The user reads the number shown on the screen, and he inputs the number into SD, and SD then shows whether the number input by user is the same with the number generated by itself, if yes, Merchant is authenticated to the user and the transaction continues; if not, user aborts the transaction. This is just one scenario the system would work in, and more scenarios will be given in Chapter 4, and the protocol will be described later.
The action that the user reads numbers from a screen he can see directly can be rephrased as the user receives information through empirical channel. The empirical channel is just like two people talking to each other, on the telephone or face to face, this communication is public and can perhaps be delayed to a limited extent, but it can not be modified, replaced, or spoofed, each party in this communication believes that he/she is talking with the right person, and the information received through this channel is genuine. The empirical channel plays a key role in the whole protocol which will be explained in details in Chapter 2.
After the authentication process has been finished successfully, SD receives transaction information from Merchant server and shows that information on its screen, and then user inputs PIN into SD and waits for the transaction to be finished.
Let’s have a look at what we will get in the end first:
We could see from the picture shown above that there is a small device with buttons and a screen. This is what we call SD, which looks very simple and easy to use.
And the user might see a digest displayed on a point of sale terminal or on a https site with which he is carrying out an online transaction.
1.4 Structure of the Thesis
This thesis is intended to give a concrete description about how the ideas presented in the first chapter evolve into a practical Anti-Credit-Card-Fraud system. In Chapter 2 we will discuss how to build up the system model, taking into consideration the needs and the main structure we are going to build. And in Chapter 3 we mainly focus on the problems we will face when putting this system into practical use and bringing out the solutions to tackle those problems. In the end, there will be a brief introduction about how to use the system as a customer in Chapter 4 and how I have implemented a prototype in Chapter 5. More details about how to implement or how to develop by using this system will be explained in Developers’ Handbook in the appendix A.
The protocols and concepts described in this thesis are closely based on the Patent Application [Roscoe, 2006 a]
46
Chapter 2
Chapter 2
Constructing System Model
2.1 Requirement Analysis
Based on the ideas brought out in Chapter 1, we need to:
· Design SD;
· Design the security mechanism of the system.
· Design transaction steps;
· Design communication mechanism of the system;
2.1.1 SD
SD acts as a key part in our system, and with this device, we can protect our credit cards from intruders. So what should a SD be like?
· SD should be stateless, which means it holds no information at all before or after the transaction. In this way, even if the user has lost SD or someone has stolen it from the user, the user does not need to worry about the information of his Credit Card being revealed to others;
· SD should be easy to use, the user does not need to have any introduction before using this device; also the user should feel free to carry this device along with him, thus the SD should be very small and light;
· SD should be easy to manufacture, the less it would cost, the greater the likelihood of it being adopted by customers.
2.1.2 Security
Based on the former assumptions, we only need to focus on the security requirement of SD, while Merchant or other intermediary components will have the corresponding security to SD’s.
As we have presented, SD should be very simple, so the Cryptographic methods we are going to use should have a computation advantage, and at the same time, those methods should ensure that during the transaction, no one can break the barrier of protection we place on SD, and we do not need to consider what will happen before or after the transaction (Because SD is stateless).
Subject to overall security needs, we should keep computation power requirements to a minimum.
2.1.3 Transaction
The new transaction using SD should not be more complicated than the current transactions we would meet in the supermarkets or restaurants. The user should have the confidence that during the transaction, no one would have the chance of knowing any information about his Credit Card except for the bank.
2.1.4 Communication
The communication between SD and Merchant should be stable, efficient and fast. We need to make it capable of detecting message lost or message disorder, ensuring the desired message to be received and sent, and we have to be able to tackle any unexpected problems like:
· The Credit Card is loose or inserted improperly; the Credit Card is pulled out before the transaction is completed;
· The connection is lost during the transaction;
· The SD or Merchant is crashed during the transaction, for example, SD runs out of battery, etc.
Please note that we do not trust the connection between SD and Merchant, which means the connection may be corrupted.
2.2 Designing SD
Main parts of SD:
· Input: ten buttons ranging from ‘0’ to ‘9’, two buttons being used as ‘Enter’ and ‘Abort’.
· Display: single colour screen.
· Connection: USB, Wireless, Inferred etc.
· Memory: unnecessary to be very large, say 8M.
· Calculation module: able to carry out the cryptographic algorithms required by its role in the embedded protocol.
· Card reader.
· Frame and battery.
SD may looks like:
2.3 Protecting the System
2.3.1 Finding the Right Protocol
The bootstrapping protocols we use all belong to the family, the termed HCBK (Hash Commitment Before Knowledge) based the following protocol that was first introduced in [Roscoe, 2006 b]
HCBK Protocol
The main body of the protocol is as follows:
0. I : I
1. : {B, INFO_B}
2. I: lh(secret_I)
2b.: this step is to ensure I will not send a Message 3 while any other
agents in G is still waiting for Message 2.
3. I: secret_I
4a. displays: sh(secret_I, all message received), init(I, B)
4b. : Users compare
: via normal channel which implicitly means via insecure high bandwidth channel
: via empirical channel which implicitly means messages sent via this low bandwidth channel are the least to be hacked
I: the initiator who starts the session of protocol
A: a node that I want to set up the connection with