Electronic Transaction Through Mobile Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Payments through mobile phone are gaining popularity as it is very convenient means of payments. But there is also a danger of hacking and the payments could be directed towards wrong recipient or the amount could be changed. Payment through mobile is called Mobile banking, it is a term used for performing balance checks, account transactions, payments etc. via a mobile device such as a mobile phone. This is performed via SMS or by using Mobil internet (GPRS), or can also use special programs called clients, downloaded to the mobile device. [1]

Purpose of Document:

The purpose of this research is to

To develop a system, that is secure.

To design an interface with our own server, instead of the main mobile company server.

To develop a system that would be usable for payment of any utility services, like gas, electricity and also used for direct fund transfer.

Encryption will be used in transmitting the data.

Background Knowledge:

Mobile commerce was born in 1997 when the first two mobile phone enabled Coca Cola vending machines were installed in the Helsinki area in Finland. They used SMS text messages to send the payment to the vending machines. In 1997 also the first mobile phone based banking service was launched by Merita bank of Finland also using SMS [6]

Mobile Banking refers to provision of banking- and financial services with the help of mobile telecommunication devices. The scope of offered services may include facilities to conduct bank and stock market transactions, to administer accounts and to access customized information. [2]

Motivation :

Now days mobile are very popular among people and it's becoming inexpensive day by day. Life today is so busy; no one has enough time for standing in a queue to pay bills, fund transactions etc. Therefore I feel there is a need to have such a system through which one can do these transactions online.

Research Statement :

"Secure Electronic Fund Transfer through Mobile Phones "

1.5 Research Area & its Importance:

Research area of my thesis is electronic transaction through mobile.

M commerce is major application domain for mobile devices, enabling user to perform commercial transactions where ever they go. However these applications required a high level of security. Now a day's man wants more and more convenient way to perform tasks. In case of bill payments it is very difficult for busy peoples to stand in long queues. In order to solve such types of problems mobile payments in very good approach. This provide ease to peoples.

1.6 Objective:

The purpose of my thesis will be to provide ease to those peoples who want to perform most of their important transaction though mobiles. The purpose of making this transaction most secure because people mostly don't believe on mobile. For this I will use some sort of algorithms to provide security to the system.

1.7 Scope of the Document:

Any project is investment, either financial, time and effort or knowledge investment. It is to be returned and though it is to be planned well. People are expanding their existing needs. Controlling of home remotely is becoming more and more common. Companies are facing intense competition and are striving hard to cut down the costs. Mobile is becoming more and more inexpensive and this increases its use all over the world. One great advantage of using mobile is that it does not require any cable installation and we are connected to world from anywhere. The purpose of this application is to provide the business people with a system using which users can get more control over their home from any where in the world.

1.8 Outline:

The outline of my thesis is:

• Chapter 1 Introduction as well as background knowledge is discussed. Purpose of document and research statement is clearly defined.

• Chapter 2 History and complete background information is provided.

• Chapter 3 Literature review of the article is given

• Chapter 4 Proposed model with description.

• Chapter 5 Analysis and design.

• Chapter 6 Test cases are given

• Chapter 7 Conclusion and future work is provided

• At the end references resources are given.

2.1 Electronic money:

Electronic money is defined as the exchange or the transaction of money by using electronic device, typically this involves computer networks and digital stored value system. [3]

2.2 Electronic payment system:

Electronic payment system is a part of e-commerce. Electronic payment system is a system that is used to exchange or transfer the actual money. This system use different protocols and different types of cryptographic techniques or different algorithms in order to male the transaction more secure and to authenticate the sender and receiver.

Figure 1: Electronic payment system

2.3 Mobile payment:

Mobile payment is new payment method that provides convenience to user by using mobile for the payment of wide range of services instead of paying with cash, checks or through credit cards. The services contain payment of utility bills, fees, funds etc. This is rapidly adopting payment system. [4]

Mostly mobile payment architecture involves three parties, a mobile device (customer/user), a merchant and financial service provider (e.g., a bank or credit card service provider). To make the transaction secure the third trusted party involve to authenticate or to authorize user. In most use cases, the third trusted party is part of the financial service provider [5]

2.4 Direct Mobile Billing:

The consumer uses the mobile billing option during checkout at an e-commerce site. After two-factor authentication involving a PIN and One-Time-Password, the consumer's mobile account is charged for the purchase. It is a true alternative payment method that does not require the use of credit/debit cards or pre-registration at an online payment solution such as PayPal, This type of mobile payment method provides the following benefits:

Security-Two-factor authentication and a risk management engine prevent fraud.

Convenience-No pre-registration and no new mobile software is required.

Easy -It's just another option during the checkout process.

Fast -Most transactions are completed in less than 10 seconds [4].

2.5 Mobile Services:

There are four different areas of mobile services in banking:

• Mobile banking - where basic banking services such as balance enquiry, transfers, or last five transactions are made available from the mobile;

• Mobile payments - allowing the transmission of funds to other accounts perhaps to pay a bill or sending a remittance to friends or family in another country;

• Contactless payments using the mobile - using the contactless capability available on some phones through Near Field Communications (NFC) to make a 'card' payment;

• Mobile authentication - using the mobile phone to authenticate a transaction carried out in another channel.

2.6 Electronic payment through mobile:

Mobile phones are used for the electronic payments, also called mobile banking. Mobile banking provides services of banking and financial services by using mobile devices. Services further include facilities to conduct bank and stock market transactions, to administer accounts and to access customized information. [4]

2.7 Secure Electronic Fund transaction:

Secure electronic fund transaction depend upon the following objectives

To ensure that communications are private

It verify that the transmit data have not been changed during transmission

To ensure that the client and server are who each claims to be.

To ensure that the data to be transferred was, is generated by the authorise users

In order to fulfil above objective, every electronic payment system use some algorithms or some encryption decryption techniques [3].

3.1 Technique # 1: QR-TAN: Secure Mobile Transaction Authentication

Authors: Guenther Starnberger, Lorenz Froihofer and Karl M. Goeschka

3.1.1 Main Idea

The security of electronic transactions depends on the security of the user's terminal. An insecure terminal may allow an attacker to create or manipulate transactions. Several techniques have been developed that help to protect transactions performed over insecure terminals. TAN codes,

Security tokens and smart cards prevent an attacker who obtained the user's password from signing transaction under the user's identity. However, usually these techniques do not allow a user to claim that the content of a transaction has not been manipulated.

3.1.2 Features:

This paper contributes with the QR-TAN authentication technique.

QR-TANs are a transaction authentication technique based on two-dimensional barcodes.

QR-TANs allow the user to directly validate the content of a transaction within a trusted device.

Validation is secure even if an attacker manages to gain full control over a user's computer.

QR-TANs in combination with smart cards can also be utilized for offline transactions that do not require any server.

3.1.3 Graphical Model:

Figure 2: QR-TAN authentication

3.1.4 Algorithm/ Pseudocode:

Above figure shows the messages that are transmitted during the authentication process. In order to sign a message, the following steps are executed:

The user U, who intends to perform a transaction, generates the transaction data T on the local untrusted computer LUC. It is assumed that an attacker is able to read and modify any data stored or relayed by the LUC.

The LUC requests a nonce N from the remote trusted computer RTC, e.g., a bank's server. The nonce is required to prevent replay attacks and to prove the freshness of transactions. The RTC is the trusted device in charge of the transaction. In the case of offline transactions a smart card could also perform the tasks of the RTC.

The LUC concatenates T and N, encrypts them with the public key of the user's mobile phone M and displays the result as a QR barcode.

U uses the mobile phone M to extract T and N and to read T. M acts as a trusted device.

If the user wants to approve T, she enters her secret password on M to decrypt the device password D. The device password is a shared secret between the device and the server. It can be initially distributed to the user via letter post as a QR code.

M calculates HMACD (T +N +approve+cnt) [10], converts the result to an alphanumeric format and displays the first X characters. The approve value

Serves as an indicator that the user wants to accept the transaction. If the user prefers to explicitly reject a transaction, she can calculate the hash value of

HMACD(T + N + reject + cnt). The cnt field is usually set to zero. However, if the resulting shortened hash values for approve and reject match, cnt is increased until the two hash values differ.

U reads the first X characters and inputs them on LUC.

LUC transmits T and the hash to the RTC.

RTC does the calculation for the two possible hashes in step 6 itself and checks if the received hash matches one of the two hashes. Furthermore, the RTC computes the confirmation hash HMACD(T +N+check) and transmits it back to the LUC.

M computes the confirmation hash using the same formula as the RTC. If the hashes displayed by M and LUC match, the user knows that the transaction has been confirmed by the RTC.

3.1.5 Advantages:

QR-TANs use a visual communication channel and do not require any direct communication link between the mobile trusted device and the untrusted terminal.

They do not require the installation or configuration of additional software on the untrusted terminal.

3.2 Technique # 2: A secure mobile payment system

Authors: LI Xi, HU Han-ping

3.2.1 Main Idea:

Now a day the use for mobile device in m-commerce for payment is gaining popularity. Since mobile payment (m-payment) is a critical part of most wireless information services and mobile commerce applications, how to build secured m-payment systems becomes a research hotspot. This paper presents an effective Mobile Payment System (MPS) in wireless insecure environments using mobile devices. The proposed framework provides a secure and convenient payment mechanism. Moreover, the mobile payment protocol and the security solution of the MPS are described.

3.2.2 Features:

Features are given as follow

The application is installed into the SIM card of mobile phone and implemented with the SMS technology.

The interoperability between SIM card and terminals is achieved through Global Platform standards

The merchant server works with an application by communicating with the payer and the payment gateway.

The purpose of designing the protocol is to provide a convenient, secure and brief protocol for supporting m-payment transactions

3.2.3 Graphical Model:

Figure 3: The architecture of mobile payment system

3.2.4 Algorithm/ Pseudocode:

The m-payment protocol can be divided into two parts: session key generation protocol and payment transaction protocol.

The mobile phone sends the message with the encrypted payment data to the merchant.

Before operating on the payment functions, the mobile phone and the issuing bank have already generated the session key Ks and the integrity key Ki, both of which are generated offline by a Random Sequence Number (RSN) shared by them. The procedure is at the background and invisible to the payer.

Figure 4: Message format of mobile payment

3.3 Technique # 3: A Lightweight Architecture for Secure Two-Party Mobile Payment

Authors: Y. Zhu and J. E. Rice

3.3.1 Main Idea:

Wireless networks and mobile devices have been used widely in more areas than ever. As an important wireless network application in financial field mobile payment was predicted to possess a bright future in becoming a successful mobile service. However, due to security problems,

it has not become a major medium for payment

In this paper a lightweight secured architecture for two party involved mobile payments (SA2pMP) is proposed.

This architecture makes use of a lightweight cryptography scheme, a multi-factor authentication mechanism along with a transaction log strategy to ensure all security requirements are fulfilled.

3.3.2 Features:

In a banking transaction there are two parties involved: the user and the bank.

The user taking part in our banking transaction is also the mobile device's holder and owner.

Mobile device connects with a network gateway through mobile networks provided by a mobile network operator.

Wired networks connect the banking system and the network gateway.

3.3.3 Graphical Model:

Figure 5: Network module for SA2pMP

3.3.4 Algorithm/ Pseudocode:

Encrypt and Decrypt denote the encryption and decryption operations. V erify denotes the process of authentication verification, while DV erify denotes verifying the digital signature. AuthConfirm denotes an authentication confirmation, while BizConfirm denotes a business confirmation. BizT ransaction denotes a business transaction process. Bizlist denotes the authorized business transaction list. TD denotes transaction data. DS denotes a digital signature. RKS and PKS denotes the private key and the public key for generating the digital signature, while KE denotes the encryption key. The h is a hash function, and crypto msg is an encrypted message. TLog is an activity recording transaction log on the network Gateway.

1. Client sends an authentication request to Bank.

Client− > Bank : (ACID, PWD, IDC)

2. Bank verifies the authentication request.

Bank: Verify(ACID,PWD, IDC)

3. Bank responds a confirmation to Client.

Bank− > Client: (AuthConfirm,Bizlist)

4. Client generates a transaction message.

Client: msg < −TD

5. Client computes a digital signature.

Client : DS = DSign(IDC, h(msg),RKS)

6. Client encrypts the signed message.

Client: crypto msg = Encrypt(DS + msg,KE)

7. Client sends an encrypted message to Bank.

Client− > Bank: crypto msg

8. Bank decrypts encrypted message.

Bank: DS + msg = Decrypt(crypto msg,KE)

9. Bank verifies the digital signature

Bank: Yes/No = DV erify(DS, h(msg),PKS)

10. If the step responds true, the business transaction is started.

Bank: BizTransaction

11. Bank responds a transaction confirmation to Client, and records a transaction log.

Bank− > Client: BizConfirm

Gateway: TLog

3.4 Problem Statement:

To make the transaction more secure so that no one can see the payment information. and to develop a system that will authenticate the user by PIN code/password.

3.5 Proposed Solution:

To develop a system that encrypts the information when user send this message and it will reach to mobile operator in encrypted form. When bank receive this message, it decrypt the message and authenticate the user by identifying its PIN code/password

4. Purposed Model

4.1 Main Idea:

My main idea is to develop a secure system that transfer funds and utility bills from the user account to the required account. For this it is must that both have an account in the bank. For the very first time the user has to get registered from the bank for mobile payments. For transaction of money the user will send message to the bank, the bank will authenticate the user by its PIN code that has selected by user when he was registered. The bank will check in the database of third party (bill companies) and deduct the amount of bill from the user account, and then send a confirmation message to the user. If there is no sufficient amount in the account then it will also send message to user.

4.2: Features/Characteristics:

An interface with our own server, instead of the main mobile company server.

To make transaction more secure, by authenticate user by user the PIN code or password.

4.3. Graphical Model:

Figure 6:

4.4 Algorithm/ Pseudocode:

First the user gets registered from the particular bank and gets its PIN code/ password.

User enters payment detail in the mobile like PIN code, account number. Account number of recipient bank, Bill serial number.

User's information is encrypted and sends to the bank through SMS gateway.

Bank decrypts the information.

Bank authenticates the user by its PIN code/ password.

Bank Execute the checks.

Merchant sends a success message to user if all checks are true

Merchant sends a failure message to user if any check is not true

5.1 Sequence diagram

The following figure describes Sequence diagram of proposed system

Figure 8

5.2 Flow diagram

The following figure describes the flow diagram of proposed system.

Figure 9