Airo National Research Journal October, 2016 Volume V, ISSN:

Size: px

Start display at page:

Download "Airo National Research Journal October, 2016 Volume V, ISSN:"

Daniela Russell
5 years ago
Views:

1 1

2 A STUDY ON SECURITY OF WIRELESS FINANCIAL ARCHITECTURE Abstract MAHINDER JIT SINGH KHANNA RESEARCH SCHOLAR OF SRI SATYA SAI UNIVERSITY MADHYA PRADESH (INDIA) Mobile commerce (m-commerce) offers a practical and complementary solution to credit card transactions. This paper proposes a Secure Wireless Financial Transaction (SWiFT) system and describes a proto-type implementation. A review of similar m-commerce solutions is included with comparison to the proposed SWiFT system. Keywords M-commerce, secure wireless financial transaction system INTRODUCTION Credit card fraud is an increasing problem; card fraud in the UK totalled over 500 million in 2004, a 20% increase on 2003 [1]. The two major types of credit card fraud are: Card-present fraud: forgery of authenticating signature where the card is present at the point of sale (POS). The introduction of Chip-and-PIN credit card technology offers increased security, though only to card-present transactions. Card-not-present fraud: online purchasing or phone-based ordering where a merchant cannot view the card at the time of transaction. This fraud is more common than card-present fraud [1]. Chip-and-PIN credit card technology does not protect against card-not-present transaction fraud. A stolen card contains all of the required information to conduct fraudulent transactions. Customers report lost or stolen cards to the appropriate financial institution and are required to wait several days before re-issue of a replacement card. 2

3 M-commerce offers a solution, which protects against both of the above types of fraud and which offers the consumer increased control over personal transactions and accounts. Interest in m-commerce is increasing; the Mobey Forum [2] expects the global m-commerce market to be in excess of $40 billion by 2009 [3]. Forum members include leading financial institutions and major developers of mobile communications technology. M-commerce solution architecture, security and functionality remain critical to their adoption by consumers. Massive global mobile phone ownership (estimated 1.52 billion users in December 2004 [7]) makes such technology an obvious choice as a user device. Current technology and a growing wireless network infrastructure, including J2ME-enabled mobile phones, enables practical implementation of secure m- commerce transaction systems. With improvements in processing power, screen size and transmission bandwidth, adequate data encryption for security and content delivery to consumers is becoming a reality. M-commerce offers an improved consumer-orientated approach to transactions, improved transaction security and extended services, compared to credit card transactions. The proposed SWiFT system includes the following three key components: a consumer e-card, a bank server (or banking agent server), and a merchant terminal. Unlike credit card transactions, no direct communication occurs between the SWiFT system e-card and merchant terminal. The e- card and merchant terminal communicate only via the trusted bank server. This approach reduces the security risk as each device must only establish one secure channel each and the bank has centralised control of all network connections. RELATED RESEARCH Research in secure wireless transaction systems has delivered various approaches to the architecture, security protocols and consumer applications. Various fora, mobile phone manufacturers, financial institutions and educational institutes have driven this research. The SWiFT system provides a fresh approach to m-commerce and to the concept of a wireless wallet. Before outlining the proposed solution, this paper will first comment on some of the most pertinent previous research developments in this area. 3

4 Itani proposes an end-to-end security protocol for an mcommerce solution developed on a J2ME enabled mobile phone [5]. It utilises the HTTP protocol implemented on top of the WAP stack to communicate with a server using HTTP requests. As WAP 1.0 support for encryption and security is not on its own satisfactory for an m-commerce application, it is necessary to further encrypt the data. Itani proposes to use the AES encryption algorithm and describes a cipher key management procedure. The protocol described is particularly suitable for mobile phone based transaction authentication. It overcomes the main limitations of J2ME enabled mobile phone development, namely processing power for encryption and lack of support for TCP/IP. AES is a symmetric encryption algorithm, which requires sensitive data to be stored on the device and a cipher key management protocol to be implemented. RSA has an advantage over AES in that it does not need sensitive data to be stored locally as it is the case with an asymmetric public-private key algorithm. Labrou describes a wireless wallet application and architecture [6] similar to the way in which SWiFT system operates. The system was implemented on two devices; a purpose-built Wi-Fi enabled device and a J2ME enabled mobile phone. The Wi-Fi device connected directly to a merchant provided access point and all communication with the banking agent are done via the merchant s resources. The consumer and merchant devices also exchange data. The concept that the SWiFT system is based is that the merchant and consumer should be able to operate independently. The dependence used in Labrou s solution could be used to compromise security by an untrustworthy merchant or a criminal posing as a merchant. The solution implemented on the developed device could not be easily ported to a phone due to architectural structure and reliance on Wi-Fi. The phone solution requires the user to register separately with each retailer and download a J2ME wireless wallet application specific to each retailer. The proposed architecture in contrast offers an integrated approach that combines all merchants under one solution. The Mobey Forum was founded in May 2000 by the leading financial institutions and mobile phone terminal manufacturers [2]. It aims to 4

5 encourage the use of mobile technology in financial services. The Forum has established a Preferred Payment Architecture (PPA). A prototype based on the PPA has been demonstrated [2]. SWIFT SYSTEM TRANSACTION PROTOCOL The SWiFT system (Fig. 1) processes a financial transaction in the following sequence. The description also explains the log in and authentication procedure for each customer e-card. 1. E-card begins the log in procedure by requesting a server connection. 2. Server authenticates the e-card by issuing three handshaked challenges to the e-card to validate the customer PIN number, e-card device serial number and two known secret values. 3. The e-card must respond correctly to each challenge to enable authentication by the server. 4. Using location information the e-card indicates its current geographic location to the bank and requests a list of available local merchants. 5. Server responds with a list of local retailers and optional retailer marketing information. 6. The customer initiates a payment transaction by selecting a specific retailer and informing the bank. 5

6 The SWiFT transaction is customer-driven and customer focused. A customer can maintain anonymity by providing a username. All sensitive data is encrypted using the RSA algorithm on both merchantto-bank and e-card-to-bank communication channels. Exponent and modulus values are 1024 bits wide. A two-stage encryption method is used: 1. encryption using the sender s private key 2. encryption using the receiver s public key. This ensures that only the intended receiver can recover the original data and it authenticates the sender. PIN number padding and hashing (using MD5) is performed and the resulting hash is encrypted (using the RSA algorithm) before network transmissions. This guarantees optimum security. DESCRIPTION OF SWIFT SYSTEM ELEMENTS The server provides clients transaction support and guards system security. The concept of a single bank server supporting all e-cards and merchant terminals is only applicable to a small-scale implementation. 6

7 For a scalable solution, many dedicated e- card servers would be required with dedicated merchant servers communicating over an internal secure network. The RSA encryption and MD5 hash algorithms are implemented to provide secure data transmission between server, e-card and merchant. As a result of server authentication of each device into the system, unauthorized parties are prevented from interfering. The server maintains a database containing all PIN numbers, device serial numbers and additional customer and merchant account information to enable control of network security. A customer web interface to the server is provided to enable customer control of PIN numbers and selected device parameters. The web interface takes the form of a secure (https) web site with authorized access to the main database. A consumer is required to enter username and PIN number to view account details, e.g., recent transaction history and balance. The server is typically implemented using the J2EE specification, which provides support for servlets and session tracking. As most J2ME enabled phones do not have support for TCP/IP but instead communicate using HTTP requests, J2EE makes an excellent choice for handling such requests. The HTTP servlets can be used to full advantage in responding to e-card requests. Communication is performed using the widely used Java database connectivity (JDBC) API. Sockets provide the merchant terminal communication over TCP/IP, allowing a duplex stream of data between a merchant and the bank. Socket programming is used rather than a high level HTTP protocol, as it is more convenient for servermerchant communication. Consumer E-Card The e-card could in theory be deployed on any device (ideally wireless, such as mobile phone or PDA) that supports HTTP and implements encryption algorithms. This paper describes the deployment using J2ME enabled mobile phones. The e-card application is developed using the mobile information device profile (MIDP), which is a set of Java API s provided by J2ME enabled phones. Combined with the Connected Limited Device Configuration (CLDC), a mobile phone provides a complete Java runtime environment. The e-card application is developed as a MIDlet (mobile information device 7

8 application) and downloaded onto the phone. The MIDlet then uses the provided runtime environment to execute and can communicate over the WAP stack, Bluetooth or infrared if supported by the phone. The e-card application s purpose is to represent the consumer within the SWiFT network. The e-card provides a simple, informative GUI on the mobile phone screen to support user requests and provide the user with current status and instructions. Device memory limitation and processing power constraints must be considered to meet the required encryption performance. The RSA algorithm implementation must be highly optimised, and the amount of data encrypted minimised, to allow the phone to encrypt at the 1024-bit level. Unique secret values known only to the bank and the individual phone are generated and encrypted using the consumers PIN at compile time. These are then hard coded within the customer unique MIDlet which is downloaded to the mobile phone. A customer s PIN number is the final security mechanism. The application requests the customer s PIN number to authenticate the transaction during the bank login procedure. During this phase, the PIN is used to decipher the known secret values. A hashed version of the padded value is sent to the bank. It is also required to allow authentication of the purchase. The phone could be connected to the bank over a data call, GPRS, HSCSD or 3G connections. The bandwidth requirement of the e-card application is low. Ideally the e-card would be constantly connected, e.g., using GPRS. With GPRS, customers pay for service during data upload or download. Consequently a consumer using the SWiFT system would be charged only when purchasing something or updating the geographic location. The relatively low data volume that needs to be transferred makes this service affordable and competitive. Merchant Terminal To ease integration of the proposed SWiFT system, the merchant terminal would be very similar to existing terminals already in use in retail stores. SWiFT system functionality could be integrated with existing terminals. There are some minor changes. These are however largely software updates as follows: Merchant kiosks implement the RSA and MD5 algorithms. A unique secret code is encrypted using the retailer s password on the device. 8

9 There is no requirement that the kiosk should be developed in Java, as network communications are software independent. The terminal is required to have a constant connection to the bank, as a bank must be able to issue updates to the merchant kiosk when a customer wishes to initiate a transaction. This could be achieved using a DSL or possibly a GPRS connection. If DSL and GPRS infrastructure were not available, a terminal could dial in to the server as performed presently. However, this would prove inefficient, slow and time consuming. A private wired connection would also give added security to the system. SWIFT PROTOTYPE IMPLEMENTATION The proposed SWiFT system has been prototyped (Fig. 2). A description of each implemented component is included below: 9

Bank Server The bank server was developed as a standalone Java application connected to a MySQL database using the JDBC connector. The fundamental components of the server are illustrated in Fig. 3.

10 Bank Server The bank server was developed as a standalone Java application connected to a MySQL database using the JDBC connector. The fundamental components of the server are illustrated in Fig. 3. The server application deals with requests from clients received from the Internet. Customer and retail records are retrieved by the server application as needed. Consumer E-Card The e-card architecture is illustrated in Figure 4. The ecard uses a Sharp Zaurus SL PDA. The device s Linux kernel supports a reduced version of the standard Java runtime environment, similar to J2ME. The SWiFT prototype e-card (Sharp PDA) supports TCP/UDP sockets, which are quicker and easier to implement than HTTP requests, supported by MIDP. 10

Merchant Terminal This device has been developed to resemble the current merchant terminal device using an Analog Devices ADuC7020 ARM7TDMI Development Board.

11 Merchant Terminal This device has been developed to resemble the current merchant terminal device using an Analog Devices ADuC7020 ARM7TDMI Development Board. The board interfaces with an LCD display and a 16 key keypad. CONCLUSION AND FUTURE WORK This paper presents a new approach to secure financial transactions as an m- commerce solution. We have presented an alternative approach to existing solutions that overcomes the reliance of trust between merchant and customer. It provides a centralised authentication server that does not require any direct interaction between both parties. Consequently this architecture does not rely on local trust with a merchant, but builds solely on GPRS mobile phone services. The system offers improved security over other solutions and can be easily integrated into a mobile phone platform reducing the total cost of ownership. The proposed solution provides complete support for both card-present and card-non-present types of transactions, protecting against all types of credit card fraud. The described prototype demonstrates the capabilities of the SWiFT system. Currently further optimisations of the RSA encryption algorithm are proposed for implementation on a mobile phone platform. In addition, hardware support to 11

12 meet m-commerce transaction performance requirements also needs investigation. REFERENCES [1] United Kingdom Crime Reduction Website, [2] The Mobey Forum, [3] The European Financial Management & Marketing Association, [4] Mobile Electronic Transactions Ltd, [5] W. Itani and A. I. Kayssi, J2ME Endto-End Security for MCommerce, Wireless Communications and Networking 2003, WCNC 2003, IEEE, March 2003 [6] Y. Labrou, J. Agre, L. Ji, J. Molina and W. Chen, Wireless Wallet, 1st Mobile and Ubiquitous Systems: Networking and Services, Mobiquitous 2004, August 04 [7] Cellular Online, [8] Irish Bankers Federation, 12

Best Practices Guide to Electronic Banking

Best Practices Guide to Electronic Banking City Bank & Trust Company offers a variety of services to our customers. As these services have evolved over time, a much higher percentage of customers have