ISSN 2278 – 3091 International Journal of Advanced Trends in Computer Science and Engineering (IJATCSE), Vol. 4 , No.4 Pages : 49 - 50 (2015) Special Issue of ICEEC 2015 - Held on August 24, 2015 in The Dunes, Cochin, India http://warse.org/IJATCSE/static/pdf/Issue/iceec2015sp10.pdf (ICEEC 2015)
A Hybridized Framework For Safer Storage Of User's Billing Information On Merchant's Site Shadkam Islam1, Hima Bindu Maringanti2 Booking.com, Amsterdam, shadkam.islam@gmail.com 2 North Orissa University, Odisha, India, profhbnou2012@gmail.com PROPOSED APPROACH
Abstract : The present paper is a short and a theoretical proposal of implementing a secured user billing information detail , that is least (not at all) prone to leakage. This objective is being achieved by the use of a private key, which encrypts the Credit card / Debit card that is dynamic in nature, as it is changed for every merchant per transaction. The proposal presented in short paper is a self-validated and a practically implementable solution to online transaction security, with no burden on the user of the internet.
A novel approach for keeping the user billing information safe from unauthorized persons has been proposed in this section. The merchant storing the Credit Card details does not need to know the details. He / She only needs to be able to charge the user making transactions using the Credit Card details. This is possible if the Credit Card issuing company (bank) provides the option to the user to set a private key (password) [1] on a per merchant basis, analogous to the traditional One Time Pad substitution Cipher [3]. This process tends to create a unique key based upon the user id (UID) and the merchant id (MID), probably also time-stamped and which is discarded after use or once the session expires, whichever is earlier [2]. Whenever the user is entering his/her Credit Card details on a merchant’s website, the user also enters this private key along with this info. The merchant site automatically sends the credit card details (CC-details), user id ( UID) and the merchant id (MID) to the credit card company (CCC) or the Bank. The details which the merchant stores would be encrypted based on this private key and the private key would only be stored with Credit Card company / bank; not with the merchant. Whenever the merchant has to receive / take some money from the user, they would send the Encrypted Credit Card details to the Credit Card company and the user’s id. It can be user’s back login id, or his / her email id / any primary key using which, the bank can identify the user and the merchant’s id. In turn, the Credit Card company, based on the user-id and merchant-id, would get the private key from its records, decrypt the Credit Card details, and accept / reject the transaction. The above functioning of the proposed system is depicted in the figure 1 below:
Key words : Public key, Private Key, Encrypt and Decrypt, Merchant-id, User-id . INTRODUCTION Many a times, companies / merchants have to store user billing information (Credit Card / debit card related data). Though they store it in an encrypted form, in any unfortunate incident of data leakage to unauthorized persons, the following repercussions are observed: at best, user confidence is gone, with most of them deciding to block that card, at worst, the information to decrypt the billing information may also have got compromised, and before all the users could be informed about blocking the cards, the hackers may do some transactions. Also, users who would like to avail some services, hesitate in doing so, if the company / merchant stores billing information (which is generally the case for subscriptions). This is because once the Credit Card details are out, there is no way to take them back / erase it, unless one gets the cards blocked. The downside is, once a card is blocked, it is blocked everywhere, and new card details (as and when they become available) will have to be re-entered by the user for all the services they had used the earlier card for. The control is there with the merchant ; so the user always has this risk at the back of their head that even if they discontinue the service / they still would have to check their bills to see that they haven’t been charged.
Credit Card Company / Bank UID,MID,PRkey(UID,MID) Request for Mode of Payment [UID, MID] Request for Product
OTP Request for CC-det & OTP(PR-key)
49