eurocon 2005

EUROCON 2005 - “Computer as a Tool”, Belgrade, 24 th November 2005 (1) Paul Killoran

EUROCON 2005EUROCON 2005

Paul Killoran, Fearghal Morgan & Michael Schukat

National University of Ireland, Galway

[email protected]

SWiFTSWiFT:: A New Secure Wireless Financial Transaction :::: A New Secure Wireless Financial Transaction ::

:: Architecture :::: Architecture ::


IntroductionIntroduction

Aim: to develop a more secure alternative to the credit card

Credit card fraud totalled £500 million in 2004

Credit card security– Signature– Chip and PIN

Types of fraud

Architecture of current system

Bank

Retailer

Authorisation & Confirmation

CustomerCredit Card &

Reciept


Proposed SolutionProposed Solution

Model the credit card on a wireless mobile authentication device– J2ME (Java 2 micro edition) mobile phone

Increase the security of the system by removing the trust required of the customer– Open a connection to

the bank (GPRS)

Focus on the security of the customer– Provide anonymity

Bank

Retailer

Authorisation & Confirmation

Customer

Payment Request & Verification


SWiFT ArchitectureSWiFT Architecture

Transaction Server– Bank or Banking Agent

Bank

Retailer Customer

Retailer Support

Customer Support

HTTP Interface

Security &Encryption

Customer Authorisation Device

– MIDP enabled mobile phone– E-Card

Retailer Kiosk– Modelled on existing terminals

Network & Security– GPRS & Bluetooth– RSA, MD5 & Customer PIN

Bank

Retailer Customer

J2MEMIDlet

GUI

HTTP(WAP)


Bank

Retailer Customer

BasicRetailerTerminal


Bank

Retailer Customer

GPRS Bluetooth

Network

RSA MD5

Security

PIN


SecuritySecurity

E-Card – Merchant communication– Never occurs– Eliminates need for a third secure channel.

Customer authorises bank directly– Must only trust their bank

Centralised control of security (Bank)– All parties communicate through the bank– Bank controls security in the network by supporting

requests of authorised nodes only


ProtocolProtocol

Transaction server established with many retailer nodes connected

E-Card logs onto the network

3 handshaked challenges

Use geographic information to inform bank of its location

E-Card receives list of local retailers

Bank

Retailer

Bank

Retailer Customer

Request Connection

Bank

Retailer Customer

3 Handshake ChallengesMD5, RSA, PIN, Secret Known Values

Bank

Retailer Customer

Current Location

Bank

Retailer Customer

Local Retailers


ProtocolProtocol

Customer approaches a retailer pay point with goods and produces their mobile phone (E-Card)

Customer uses their E-Card to request the Transaction Server to initiate a payment to the retailer

Cashier is informed of this request on their merchant terminal

Bank

Retailer Customer

Bank

Retailer Customer

Initiate TransactionTo Retailer Bob

Bank

Retailer

Inform Bob Of Transaction From Alice

Customer


ProtocolProtocol

Cashier requests payment using the Merchant Terminal

Customer is asked to confirm payment of this amount on their E-Card by entering their PIN

The PIN number is first padded, then hashed using MD5 and finally encrypted using RSA. The result is send to the Transaction Server for authorisation

Bank

Retailer

Request SaleAmount From Alice

Customer

Bank

Retailer Customer

Confirm Sale Amount To Pay To Bob

Bank

Retailer Customer

Verify & Authorise


ProtocolProtocol

If the PIN authorisation is successful, a confirmation is then sent to the Merchant TerminalThe cashier confirms the sale and the agreed amount is transferred between accountsThe E-Card and Merchant Terminals receive a copy each of an e-receiptThe e-receipt is printed by the Merchant Terminal and issued to the customer

Bank

Retailer

Confirm Transaction

Customer

Bank

Retailer

Confirm Sale

Customer

Bank

Retailer

E-Receipt

Customer

E-Receipt

Bank

Retailer CustomerPrinted Reciept


Points to NotePoints to Note

Geographic location

Customer username

Customer initiated

Marketing opportunity

Card-present & card-not-present transactions support

Security– RSA, MD5 & PIN number


ImplementationImplementation

Transaction Server– HTTP requests & responses– Session tracking– Web user interface (account management)

E-Card Application– J2ME & Mobile Information Device Profile (MIDP)– HTTP over WAP– Downloaded MIDlet– Secret shared values


ImplementationImplementation

Retailer Kiosk– Easy integration with existing retail terminals– Requires MD5 & RSA encryption module– Requires online connection (GPRS)


PrototypePrototype

E-Card– Java PDA– Wi-Fi & sockets– Large touch screen

Transaction Server– Java application– Sockets

Retailer kiosk– ARM development kit– Keypad & small LCD– Modelled on current retail

payment devices


Future WorkFuture Work

Expand the application to include card-not-present transactions

Refine the RSA implementation for faster operation

Transfer the E-Card application from the PDA to a mobile phone

Extensive testing of the security of the network


ConclusionConclusion

New approach to secure personal financial solutions

Considerable improvements over credit card security

Easy integration

Support for card-present & non-present transactions

Reliance of trust between customer and 3rd parties removed

Working prototype developed


SWiFTSWiFT:: A New Secure Wireless Financial Transaction Architecture ::

Paul Killoran

Progress is impossible without change, and those who cannot change their minds cannot change anything.

- Albert Einstein (1879-1955)

eurocon 2005

Documents