SEPIA: Secure-PIN-Authentication-as-a-Service for ATM using Mobile and Wearable Devices

SEPIA: Secure-PIN-Authentication-as-a-Service for ATM using Mobile and Wearable Devices Rasib Khan, Ragib Hasan, and Jinfang Xu SECRETLab, Department of Computer and Information Sciences University of Alabama at Birmingham, Birmingham, AL 35294, USA Email: {rasib, ragib, xujf}@cis.uab.edu Abstract Credit card fraud is a common problem in today s world. Financial institutions have registered major loses till today due to users being exposed of their credit card information. Shoulder-surfing or observation attacks, including card skimming and video recording with hidden cameras while users perform PIN-based authentication at ATM terminals is one of the common threats for common users. Researchers have struggled to come up with secure solutions for secure PIN authentication. However, modern day ubiquitous wearable devices, such as the Google Glass have presented us with newer opportunities in this research area. In this paper, we propose Secure-PIN-Authentication-as-a- Service (SEPIA), a secure obfuscated PIN authentication protocol for ATM and other point-of-service terminals using cloudconnected personal mobile and wearable devices. Our approach protects the user from shoulder-surfers and partial observation attacks, and is also resistant to relay, replay, and intermediate transaction attacks. A SEPIA user utilizes a Google Glass or a mobile device for scanning a QR code on the terminal screen to prove co-location to the cloud-based server and obtain a secure PIN template for point-of-service authentication. SEPIA ensures minimal task overhead on the user s device with maximal computation offloaded to the cloud. We have implemented a proof-of-concept prototype to perform experimental analysis and a usability study for the SEPIA architecture. Keywords-ATM, Authentication, Credit/Debit Card, Google Glass, Obfuscated PIN, PIN Template, Point-of-Service, Security I. INTRODUCTION Authentication of users at automatic teller machines (ATMs) is mostly dependent on PIN-based verification. Several usability factors have been studied so far in enhance the security for authentication of users at ATMs. Socio-physical factors, such as, queue length, distractions, length of time for the interaction, urgency, physical hindrance, memorization of PINs, co-located user display, speed of interaction, and the environment are all determinants of the secureness for the procedure [1, 2]. The major concerns from all of these factors are correlated to shoulder-surfing attacks, replay attacks, card cloning, and unintentional PIN sharing [2]. Multiple researches have also been conducted to detect fraudulent card transactions [3, 4]. Security of credit and debit card authentication may be considered as an evolving field to fight against the skillful fraudsters getting hold of modern and more effective means every day [5]. Researches have analyzed the current scenario of credit card fraud [6]. Systems supporting card-less transactions are getting popular, where users can use additional personal devices, such as mobiles phones, to perform the financial transaction [7, 8]. However, even today, incidents of exposure of credit card information are still a common event [9]. The total loss from consumer cyber-attacks in 2013 was estimated at approximately 38 million USD in the US, including 13 and 37 million in Europe and China respectively [9]. Shoulder-surfing attacks, also known as observation attacks, are most common for ATM authentication. In this case, the attacker simply observes the entry procedure of the PIN by the authorized user to get hold of the secret information. Credit and debit card frauds due to identity thefts are increasing every year [10, 11]. Unfortunately, users of such banking systems are still not legally protected by the banks and card companies [12]. Additionally, there are sophisticated scamming techniques using fake terminals, credit card cloning, and remote relay or wormhole attacks which make the process of user protection harder [13 16]. Researchers have studied the reasons for ATM malpractices and the ways users are exposed to attackers [2]. Credit or debit cards may have magnetic strips on them to store the PIN information. Cards with magnetic strips are easy to clone with readily available and cheap card readers [17, 18]. Even though chip-based (EMV) cards are recently gaining popularity, cards still come with the magnetic strips, and it will be a while till all point-of-service devices and banks are upgraded to support only EMV cards. Unfortunately, such EMV cards are still vulnerable to cloning of the bank s certificate and relay attacks [15, 16]. Research on shoulder-surfing resistant PIN entry has not been new [19, 20]. Newer technologies, such as ubiquitous wearable devices and mobile phones have also been utilized in developing secure PIN authentication technologies [21]. However, such devices are also considered as an opportunity for more complex attacks by malicious users [22]. In this paper, we propose the Secure-PIN-Authenticationas-a-Service (SEPIA) framework to enable obfuscated PIN authentication for ATM and other point-of-service terminals using cloud-connected personal mobile and wearable devices. SEPIA allows a user to scan a QR code from the screen of a point-of-service terminal and connects to the cloudbased bank s SEPIA server to obtain secure one-time-use PIN templates. Here, a PIN template is a sequence of digits with marked positions for the user to enter the actual PIN code. The QR code scanning is done using wearable devices,

such as the Google Glass 1 wear. The SEPIA service can also be used with a smart phone. The protocol is immune to shoulder-surfing attackers, and ensures resistance against relay and replay attacks by proving co-location with the ATM terminal to the cloud-based bank s server. Our design requires minimal overhead computation on the personal devices with most operations offloaded to the cloud and does not impose any hardware-oriented requirements on the terminals. Contributions: The contributions of this paper are summarized as follows: 1) We have proposed Secure-PIN-Authentication-as-a- Service (SEPIA), a secure obfuscated PIN-based authentication protocol for point-of-service terminals using cloud-connected personal devices. The proposed protocol works with a wearable or mobile device to allow an obfuscated PIN template entry and is resistant to shoulder-surfing, relay, and replay attacks. 2) We have implemented a proof-of-concept prototype for the SEPIA service, using a cloud-based bank server, a desktop-based Java ATM imitating application on Raspberry Pis, and user applications for both Google Glass and Android phones. 3) The implemented SEPIA prototype applications were used to perform experimental analysis, as well as a usability study to investigate the human factors involved in the SEPIA protocol. The rest of the paper is organized as follows. Section II describes the threat and the system model. The SEPIA protocol is presented in Section III. We present a security analysis of the design in Section IV. Section V presents the implementation and experiments for the proof-of-concept SEPIA components. A usability study is presented in Section VI. The related works and conclusion are presented in Sections VII and VIII respectively. II. THE SEPIA MODEL The SEPIA architecture is a protocol for secure ATM pointof-service user authentication using obfuscated PIN codes. In this section, we present the threat and system model to illustrate the functionality of the proposed SEPIA architecture. A. Threat Model The SEPIA threat model includes the definition of the assets and the attackers capabilities in the process of ATM authentication using PIN codes. 1) Assets: The asset for ATM point-of-service authentication is primarily the user s PIN code. The PIN is a secret information known only to the user of the card and is used by the user to authenticate at the ATM along with the credit and/or debit card. 1 Google Glass https://www.google.com/glass/start/ 2) Attacker s Capability: In the scenario where a user has presented a credit or debit card at an ATM and is about to present the PIN code for authentication, the following are considered to be the potential attacks by a malicious entity: 1) The attacker can be standing in queue behind the authenticating person and looking at the PIN entry and execute a shoulder-surfing or observation attack [19]. The attacker may also install a small camera on the top surface of the ATM terminal to record PIN entries of users at the point-of-service. 2) A bystander may be successful in a partial observation attack, where he is only able to see the partial PIN entry for the user. Given that most PIN codes are 4-digits long, the probability of a PIN-guessing attack still persists. 3) The attacker works at a local restaurant and owns a cheap and readily available card cloning device. A user may visit the restaurant, and when paying with the credit or debit card, the attacker clones the customer s card [14, 17, 18]. 4) The attacker has installed a card skimming device on the ATM machine to get hold of the user s card information. Such devices fit at the card slot on ATM machines and record the card information as the user slides in their card [23]. 5) The attacker can execute a relay attack on the user s card. The attacker operates a modified ATM terminal, and uses relayed card information from an actual credit card user to make payments at another remote terminal [16]. 6) The attacker has installed a legitimate-looking ATM terminal. Users are therefore tricked into thinking the terminal as a valid ATM and puts in their credit/debit card and loses the card information. 7) The user uses an advanced credit/debit card PIN protection service based on memorability and graphical image recall [13]. An attacker keenly follows the entry procedure of the user, or uses a mobile phone camera to record and gain knowledge about the user s graphical password entry and is successful in executing a shouldersurfing attack. 8) An attacker can execute an intermediate interaction attack. In this case, the attacker finds his way to steal the information as the user has been distracted for some reason and exposes the credentials to the attacker. 9) The user utilizes a mobile or wearable device, such as Google Glass to perform secure PIN authentication at the ATM terminal [21]. Unfortunately, the user loses the mobile phone or the Google Glass. The information stored on the device is also therefore lost and lets an attacker gain the knowledge of the user s credentials. B. System Model Next, we define the SEPIA system model, which will allow credit/debit card users to perform secure obfuscated PIN authentication at ATM point-of-service terminals. SEPIA is

8. Transaction Request Verification SEPIA Server 3. Generate [PIN_Template, Tran_ID] 5. Generate QR [Loc_ID, Req_ID, Tran_ID] User 1. Touch screen to initiate 6. Scan QR Code 10. [PIN on PIN_Template] Touch to begin 11. Verify PIN ATM Fig. 1: The Secure-PIN-Authentication-as-a-Service (SEPIA) for Obfuscated PIN Authentication for ATM using Personal Mobile and Wearable Devices (e.g. Google Glass) dependent on three entities: the user, the ATM terminal, and the bank server. SEPIA Server: The SEPIA server is a cloud-based server owned by the bank and stores the user s SEPIA service profiles. The server incorporates a callable API server to communicate with the user application and the ATM terminal. In our case, we have considered RESTful APIs [24] over HTTPS and client-side certificate verification for all communication. Point-of-Service Terminal: The ATM point-of-service terminal has a unique location identifier, Loc ID, which is approved and assigned by the bank. The ATM incorporates network connectivity and can communicate with the bank over secure connection. User: The user owns a credit/debit card along with a valid PIN code for authentication at the point-of-service terminal. The user owns a personal wearable device, such as the Google Glass, for using the SEPIA service for secure obfuscated PIN authentication. The user may also choose to use a mobile device for using the SEPIA service. However, the larger and relatively impersonal display on the mobile device, compared to the Google Glass, creates some vulnerability for observation attacks. The SEPIA application is installed on the Google Glass or the mobile device. Initially, the user generates a username and password pair to be used for SEPIA on the Google Glass SEPIA app. The mobile application requires the user to log in using the SEPIA username and password. The web-based SEPIA service on the cloud allows the user to store and save the SEPIA username/password information, which is later used during the SEPIA protocol. The user can create a new password at any time, and update it on the bank website and the SEPIA application on the device(s) accordingly. III. THE SEPIA PROTOCOL The SEPIA protocol involves mutual interaction between all three pairs of entities: the user and the ATM, the ATM and the bank, and the user and the bank, as shown in Figure 1. The sequence of interactions and messages in the SEPIA protocol is described as follows. Step 1 [Initiation]: The user, along with the personal mobile or wearable device, approaches the ATM to perform a secure transaction. The ATM screen displays a Touch to begin information screen by default. The user touches the screen (or presses the button) to initiate the protocol. Step 2 [ATM Transaction Request]: At this point, the ATM sends an ATM TRAN REQ message to the bank s secure server. The structure of the message is defined as: ATM TRAN REQ [Req ID, Loc ID] (1) Here, the Req ID is a request identifier which is generated by the ATM for this current transaction request. The Loc ID is the unique and verified identifier for the particular ATM point-of-service assigned by the bank. Step 3 [PIN Template Generation]: Upon receiving the ATM TRAN REQ message from the ATM, the bank generates a transaction identifier, Tran ID, for this particular ATM transaction request. The bank then generates an obfuscated numeric template, PIN Template, for the transaction to be made at the ATM point-of-service. The PIN template is an N-digit numeric pattern, where N 2P, and P is the length of the PIN code required by the bank for the users. The PIN template is generated using a random N-digit generator, with a total of P number of digits marked as * at random places. For example, 8-digit PIN templates for a 4-digit PIN may look like [4 8 * * 2 9 * *], [* * 4 0 2 * * 6], etc. Finally, the bank creates a record, REC, for the received ATM TRAN REQ message, and stores it on the local database. REC [Req ID, Loc ID, T ran ID, V alidity, P IN T emplate, T S, IsUsed] Here, TS is the timestamp at which the ATM TRAN REQ message was received by the bank from the ATM. The bank can specify a time limit for PIN template. The bank stores the Validity for the maximum period of time (e.g. 30 seconds) within which the PIN template has to be used. A Validity value too low will require the user to perform the ATM authentication very fast, while a higher value will make the (2)

system vulnerable to relay and replay attacks. Additionally, the IsUsed flag is set to FALSE and is saved to keep track if the particular transaction request has been successfully completed or not. Step 4 [ATM Transaction Response]: Next, the bank server responds to the transaction request made by the ATM using an ATM TRAN RES message. The structure of the message is defined as: ATM TRAN RES [T ran ID, V alidity, P IN T emplate] Here, the Tran ID is the identifier generated by the bank for this particular transaction request. The PIN Template is the numeric N-digit template generated by the bank. The bank also sends the Validity token, a timer for the maximum allowed time limit for the particular PIN template and transaction request for the current user. Step 5 [QR Code Generation]: Once the ATM receives the ATM TRAN RES message, it extracts the Tran ID, and generates a quick response (QR) code [25]. The QR code is generated from the following context: (3) QR Code [Loc ID, Req ID, T ran ID] (4) Here, the Loc ID, Req ID, and Tran ID are the location, request, and transaction identifiers respectively. The QR code is then displayed on the ATM screen. Step 6 [QR Code Scan]: At this point, the user is able to see the QR code displayed on the ATM screen. The user then uses his personal mobile or wearable device running the SEPIA application to scan the QR code. The advantage of using a personal wearable device, such as the Google Glass, is that the display of messages in the next phases are only visible to the interacting user. Upon a successful QR code scan, the Loc ID, Req ID, and Tran ID are transferred to the user s device from the ATM screen. Step 7 [User Transaction Request]: Once the user scans the QR code on the ATM screen, a USR TRAN REQ message is created and sent to the bank server over secure communication channel. The structure of the USR TRAN REQ message is as follows: USR TRAN REQ [Username, P assword, Loc ID, Req ID, T ran ID] In this message, the Loc ID, Req ID, and Tran ID had been obtained from the QR scan, and the username and password are the user s personal SEPIA service settings which have been previously saved on the bank s website. Step 8 [Transaction Request Verification]: The bank s cloud-based server receives the USR TRAN REQ message from the user s personal mobile or wearable device. The bank then executes the transaction request verification algorithm in the cloud, and responds to the user s personal device. The transaction verification algorithm as mentioned in Table I. (5) t r a n s a c t i o n r e q u e s t v e r i f y (USR TRAN REQ){ ( uname, pwd, locid, reqid, t r a n I D ) < p a r s e (USR TRAN REQ ) ; s u c c e s s < a u t h e n t i c a t e u s e r ( uname, pwd ) ; i f ( s u c c e s s ) t h e n : REC < g e t r e c ( locid, reqid, t r a n I D ) ; i f (REC!= n u l l ) t h e n : currtime < g e t s y s t e m t i m e ( ) ; i f ( ( currtime REC. TS ) < REC. V a l i d i t y ) t h e n : i f (REC. IsUsed == FALSE) t h e n : u p d a t e (REC. IsUsed, TRUE ) ; r e t u r n ( s u c c e s s, REC ) ; e l s e : r e t u r n ( f a i l u r e, Repeated t r a n s a c t i o n ) ; e l s e : r e t u r n ( f a i l u r e, E x p i r e d t r a n s a c t i o n ) ; e l s e : r e t u r n ( f a i l u r e, I n v a l i d t r a n s a c t i o n r e q u e s t ) ; e l s e : r e t u r n ( f a i l u r e, I n v a l i d u s e r ) ; } TABLE I: SEPIA Transaction Request Verification Algorithm Initially, the USR TRAN REQ is parsed to obtain the username, password, Loc ID, Req ID, and Tran ID. The username/password is used to validate a user for the SEPIA service offered by the bank. If authentication is unsuccessful, the process returns with a failure message and the reason Invalid user. If successful, the Loc ID, Req ID, and Tran ID is used to locate the transaction record, REC, from the banks database. If a REC is not found, the process returns with a failure status and the reason Invalid transaction request. Given that a REC is found in the database, the current system time is then compared to the saved timestamp, TS, within the REC. The time difference must be less than the allowed validity period for the ATM transaction by the user. If the time difference is above the allowed limit, the process returns a failure status and the reason Expired transaction. If the transaction request is still valid, the process then checks if the IsUsed is set to FALSE or not. If it set as TRUE, this means that this is a replay attack, and the process returns a failed status with the failure reason Repeated transaction. Given that the IsUsed flag is FALSE, the process updates the IsUsed flag in REC as TRUE and returns a success status along with the retrieved REC. Step 9 [User Transaction Response]: Given that the transaction request verification algorithm returns a success, the bank server then constructs a USR TRAN RES and sends it back to the user. The structure of the message is shown as below: USR TRAN RES [Status, [P IN T emplate, Rem V alidity] [Reason] ] Here, the status corresponds to the success of the USR TRAN REQ sent earlier. The PIN Template is obtained from the corresponding REC found in the request verification phase. Finally, the Rem Validity is the remaining time for the (6)

validity of the ATM transaction for the current user. This is calculated as follows: Rem Validity = REC.Validity - (Current System Time - TS). Alternatively, if the status is a failure in the request verification phase, the message includes a Reason for the failure. Step 10 [Obfuscated PIN Input]: Given that the user received a success status in the USR TRAN RES message, the PIN Template is then displayed on the users personal mobile or wearable device. In case on a mobile (smart) phone, the PIN Template is displayed and is visible on the phone screen and it depends on the user to prevent other people peeking at the phone screen. If using a Google Glass, the user does not need to worry about shoulder surfers, as the PIN Template will only be visible to the user. The user then enters the P-digit PIN code obfuscated within the N-digit PIN Template on the ATM s input screen. For example, the user is displayed the following 8-digit PIN Template: [4 8 * * 2 9 * *]. Assuming that the 4-digit PIN for the user is [1 2 3 4], the user enters the following obfuscated PIN [4 8 1 2 2 9 3 4]. Step 11 [PIN Verification]: The ATM receives the user s obfuscated PIN input on the screen. The PIN Template which the ATM received earlier in the ATM TRAN RES message is then used to extract the P-digit PIN code obfuscated within the N-digit PIN Template. The extracted PIN is then used by the ATM to authenticate the user and completes the SEPIA protocol. IV. DESIGN ANALYSIS This section presents the security and architectural design analysis for the proposed SEPIA architecture with respect to the threats mentioned in the SEPIA model in Section II. The SEPIA protocol requires a personal wearable device, such as Google Glass, for performing the obfuscated PIN authentication. The system also supports any other (smart) mobile device to be used with the service. However, as it has already been mentioned, the larger screen on the mobile device requires the user to be more careful than when using the user-only display on the Google Glass. Given that the display of the PIN Template is protected, SEPIA ensures shouldersurfing resistant PIN authentication. Any bystander observing or recording the PIN entry procedure will not be able to decipher the actual PIN code that pertains to the authentication of the card user. Let us assume that a non-authorized user scans the QR code while the user is performing the authentication process. There are two possible event scenarios: the user has already scanned the QR and sent the USR TRAN REQ before the attacker has scanned it, or the attacker scans it first before the user. In the first case, the REC for that particular transaction and the PIN Template will already be flagged as used. The attacker will therefore receive a Repeated transaction error code. In the second case, the user will receive the Repeated transaction error, in which case, the whole procedure can be restarted securely. In case an attacker attempts to perform the terminal authentication with the PIN code of a cloned card, the attacker will still require a username/password information. Without the SEPIA service username/password information, which is registered on the bank s website, the attacker will receive the Invalid user error status. Video recording bugs on an ATM terminal or bystanders recording the PIN entry procedure with mobile cameras will still protect the user from being exploited due to the one-timeuse PIN Template. Additionally, the N-digit PIN Template offers 10 (N P ) more numeric combinations for the PIN entry procedure. This makes the task of PIN-guessing with partial observation attacks much more difficult. The user proves colocation with the ATM terminal to the SEPIA server using the corresponding Req ID, Loc ID, and the Tran ID. Therefore, delegating information to a remote terminal and execution of a relay attack becomes impossible. A tainted ATM terminal will not be holding a valid Loc ID which have been assigned by the bank. As a result, the Tran ID for the requested transaction will not be validated by the bank and will be responded with a Invalid transaction request error from the SEPIA server. Similarly, the one-time-use PIN Template and the SEPIA server generated Tran ID also protects the user from replay attacks. Additionally, the timed validity period for each transaction and the corresponding PIN Template prevents users from intermediate interaction attacks. Given that the SEPIA service only allows the PIN Template to be used for Rem Validity time (e.g. 20 seconds), the transaction request gets expired and the user has to start the process from the beginning. Therefore, only an active interaction of the user at the point-of-service will allow the authentication process to be successful. Finally, given that the user loses his personal mobile or wearable device, the credentials are still safe with the user. Unlike other works [21], the devices do not store any information, such as certificates, to decrypt the one-time PIN. Instead, the username/password information is used to retrieve the PIN Template securely from the SEPIA service API, and then the PIN code is mapped by the user on the PIN Template for obfuscated authentication. The SEPIA protocol therefore protects the users even after their personal devices are lost. Unlike other previously proposed schemes [26], the SEPIA service running on the cloud performs the majority of the operation by allowing the user s device to offload the transaction request verification process. The user s personal mobile or wearable device merely acts as a requestor and receiver of the PIN Template from the cloud server. Moreover, SEPIA does not require any hardware upgrades to currently operating ATM or point-of-service terminals. The ATM software can be easily upgraded to incorporate the SEPIA cloud-enabled service for users with Internet-enabled devices. V. IMPLEMENTATION We have implemented a prototype for the proposed SEPIA protocol. The prototype consisted of a cloud-based SEPIA bank server, a Java based desktop application to imitate the ATM terminal, and SEPIA user applications for Android and Google Glass. In this section, we present the details and the experimental results from for prototype implementation. All

Initialize SEPIA SEPIA Options (a) Java Desktop ATM Application Layout (b) SEPIA ATM Application Running on Model-B Raspberry Pis Fig. 2: SEPIA ATM Prototype Implementation identifiers within the protocol were generated using the Java universally unique identifier (UUID) package for 32-character long alpha-numeric strings. Network communication between the bank server in the cloud, the ATM, and the user is done via RESTful APIs over HTTPS using server side certificate. A. Bank Server Web Application The SEPIA service was implemented as a web-based application on a cloud instance using Apache Tomcat [27]. The server was deployed in an Amazon EC2 t2.small instance running Ubuntu Server 14.04. The back-end was implemented using MySQL database, which was running on the same cloud instance. The response and control logic was developed using JavaServer Pages. The application generates 8-digit PIN Templates based on the Java random generator. The first step creates an 8-digit random number, and then replaces 4 random places to create the PIN Template. B. ATM Point-of-Service Terminal Application A real-life ATM terminal context is difficult to simulate within the lab environment. To analyze the complexity of the proposed protocol, we developed an imitated scenario for the ATM point-of-service using a graphical desktop application. The application was developed using Java and an intuitive interface similar to an ATM banking application. The graphical interface for the ATM application is shown in Figure 2a. The ATM application communicates with the bank server over HTTPS using client-side verification. The application was executed on Model B Raspberry Pis 2 with 512 MB RAM and cable network connectivity to communicate with the bank server, as shown in Figure 2b. The application had a start screen with a Start label to indicate users to begin interacting with the ATM for a transaction. Once clicked, the application displayed a QR code of dimention 200px*200px, along with a numeric keypad for the user to enter the PIN template. 2 Raspberry Pi http://www.raspberrypi.org/product/model-b/ OK Glass Tap to start Start SEPIA Create New Password Scan Code PIN Template 3 4 * * 9 * * 0 Creates New Google Glass Password Start Camera View New Password abcdefgh Scan QR code Display PIN Template Fig. 3: SEPIA Google Glass Application User Flow C. SEPIA User Application We developed the SEPIA user application for both Android mobile devices and the Google Glass. The Google Glass is a ubiquitous wearable device with the display only viewable to the person wearing the glass. The device therefore inherently filters off the imminent threats for observation attacks. The user control flow for the Google Glass interface is shown in Figure 3. The Google Glass application operates by displaying option cards to the user. Once the application is launched, there are two options: Create New Password, and Scan Code. We implemented a new password creation option for the Google Glass in terms of usability. It is not a trivial task to have manual inputs for the Google Glass device. Therefore, a user is expected to create a new password for the SEPIA Google Glass application. The new password is then displayed on the screen for the user, which he can enter and save on the SEPIA service profile on the bank s website. The other option for scanning the code starts the camera view. Once the user has successfully scanned the QR code, the protocol is automatically triggered and the PIN Template is displayed on the screen. The Android mobile application follows a similar user flow. However, the mobile application does not have the new password creation option. Rather, it has a username/password based login panel to log in to the SEPIA application. After the user logs in, the QR code can be scanned and the PIN Template will be displayed after the protocol is executed. D. Performance Experiment The SEPIA protocol introduces two additional message exchange compared to the single verification request in regular PIN validation protocols. The two message interactions are ATM TRAN REQ and ATM TRAN RES messages between the point-of-service and the bank server, and USR TRAN REQ and USR TRAN RES messages between the user and the bank server. We measured the time required for the two pairs of message interactions with the bank server for a total of 10,000 requests and responses. 1) ATM Request: The plot for sending and receiving 10,000 ATM TRAN REQ and ATM TRAN RES messages is displayed on Figure 4a. The plot also shows the line for the lambda-connectedness of the time measurement. The mean time required for sending and receiving the total 10,000

Mean: 331822 Mean: 4177360 (a) ATM TRAN REQ & ATM TRAN RES (b) USR TRAN REQ & USR TRAN RES Fig. 4: Time Measurements between SEPIA Requests and Responses messages was 3.318 milliseconds, with a standard deviation of 2.340 milliseconds. The 25% and 75% quartiles were at 2.587 milliseconds and 2.837 milliseconds respectively. Even though in a small scale controlled environment, the results show negligible time requirements in terms of the request and response processing. 2) User Request: The user request times are measured between the USR TRAN REQ and USR TRAN RES messages. Figure 4b illustrates the scatter plot for the measured times between the 10,000 request response pairs. The mean required time was at 4.177 milliseconds, with a standard deviation of 2.370 milliseconds. The 25% and 75% quartlies were at 3.047 milliseconds and 4.362 milliseconds respectively. The times between the user request and response shows that it is more than that of the ATM s. The minimal increase in this case is due to the verification algorithm which runs on the bank server to verify the USR TRAN REQ request and ensure the security of the SEPIA protocol. The required time is still not a major overload in terms of the system overhead. VI. USABILITY STUDY The implemented SEPIA prototype was used to perform a usability study. In this case, we focused on the human factor that is oriented with the operation of the SEPIA service. The study consisted of 8 participant users and their timing measurements while interacting with the SEPIA service. We measured the times which were required for users to scan QR codes using both the Android mobile application and the Google Glass, as well as the times required to enter the PIN code using the PIN Template. A. Demographics and Procedure The usability study was conducted with 8 SEPIA participant users. There were 4 male users within the age range of 27 and 34, and 4 female users within the age range of 22 and 28. Most participants had never used a Google Glass before. The participants were therefore provided a short tutorial on the use of Google Glass. The users were then described the data collection procedure as follows: 1) The participants were provided with a pre-defined PIN code, and were given approximately 10 minutes to register the information in their short-term memory. 2) To observe the comfort of users scanning QR code with mobile devices, the QR code displayed on the SEPIA ATM was scanned for 10 times by each participant. 3) Next, each participant used the Google Glass SEPIA application to scan the QR code for 10 times from the SEPIA ATM application. 4) The ATM application interface was then used for each of the participants to enter their PIN code 10 times. 5) Next, the participants were asked to use the SEPIA protocol to obtain a PIN template and enter the same PIN, but this time, using the PIN template. The procedure was repeated 10 times for each participating user. B. QR Code Scanning We asked the participants to scan the SEPIA QR code using both the Google Glass and the Android application. In both the cases, the users performed the QR scan for at least 10 times. The Android phone, being more convenient and a known device, was easier to use for the users. This was an anticipated outcome, as the Google Glass is not yet a very common gadget to own by the participants. The QR scan times

PIN Entry Time Required (milliseconds) Response and PIN Template Entry Time Required (milliseconds) Times Required (milliseconds) QR Scan Time Required (milliseconds) Times Required (milliseconds) Phone Google Glass User (a) User-wise Distribution of QR Scan Times (b) Aggregate Data Distribution for QR Scan Times Fig. 5: QR Code (200px*200px) Scan Times using Mobile Phone and Google Glass Users (a) Only PIN Fig. 6: Time Required by Participants Users (b) PIN on PIN Template for both Google Glass and the Android phone for each of the 8 users is shown in Figure 5a. The smaller box plots for the phone measurements compared to Google Glass shows that the users displayed a more consistent behavior while scanning the QR codes with their phones. However, we observed that the usability and convenience of using the Google Glass to carry out the operation improved even within the 10 times the users performed the QR scan. The highest points for each of the users were among the first few attempts, which drastically improved for all users with repeated trials. We also show the aggregated data distribution for the QR scan times in Figure 5b. The figure also displays the box plot for the mean and the quartiles for the data including the outliers. The mean time required for scanning the QR code using the phone and Google Glass were 4.75 seconds and 13.67 seconds respectively. The quartiles (25%, 50%, 75%) for the phone were at 3.80 seconds, 4.44 seconds, and 5.05 seconds respectively. The quartiles (25%, 50%, 75%) for the Google Glass were at 7.13 seconds, 10.37 seconds, and 17.34 seconds respectively. We saw that an overall approximate difference of

Success/Failure (Percentage) Success/Failure (Percentage) 8 to 10 seconds between the QR scan times for the phone and the Google Glass. Additionally, these measurements were for participants who were probably using Google Glass for the first time. This is not a major usability concern for the users, given that we observed the gradual improvement in their use of Google Glass with subsequent trials. Another important factor was the size of the QR code which was being displayed. To introduce the maximum constraint on the users, we generated 200px*200px sized QR images. The performance of scanning using the Google Glass is expected to increase with larger sizes of QR-code images. C. PIN and Obfuscated PIN Entry The participants were asked to perform two procedures. Initially, they were asked to enter only the 4-digit PIN code. The distribution of the time taken and the quartile ranges for the 8 participants for the simple PIN entry is shown in Figure 6a, and the corresponding success/failure ratio is shown in Figure 7a. The mean time taken by all the participants for only the successful attempts was 1747.7 milliseconds. Next, the participants entered the PIN using the PIN Template. We measured two time segments; the response time, and the entry time. The response time was the time required the users to look at the current PIN Template and start the process of entering the numbers. The entry time is the time required for the numbers to be entered as the user mentally superimposes the PIN on the PIN Template. The measured times for all participants is shown in Figure 6b, and the corresponding success/failure ratio is shown in Figure 7b. The mean response and entry time for all successful attempts was 3011.9 milliseconds and 8959.8 milliseconds respectively. The time difference between the two cases allowed us to compare the additional overhead that is being imposed on the users. The total mean time difference, including the response and entry time, between simple PIN entry and SEPIA was 10.224 seconds. This can be considered to be a minimal overtime that the users have spent for SEPIA compared to the simple PIN entry. We also observed that the users performed better after a few attempts. Initial attempts took longer times compared to the next ones. This can be seen from the small interquartile range for the PIN Template entry compared to its maximum value. Additionally, the number of failed attempts were also minimal, with a total of only 5% failed attempts, compared to 2.5% for the simple PIN entry. VII. RELATED WORK Luca et al. in [2] and Bhatia et al. [6] have presented an analysis of credit card fraud schemes and loopholes exploited by attackers. Asokan et al. [28] have analyzed the attacks on compromised ATM terminals and presented approximate solutions for the identified security issues. Relay-attacks, particularly on credit cards, have been studied by Drimer et al. [16]. Coventry et al. [1] proposed a biometric-based authentication scheme for ATMs. Raj et al. [3] and Sethi et al. [4] have presented surveys on numerous advanced credit card fraud detection mechanisms. The protocol design for Success/Failure Success/Failure 100 90 60 40 20 0 100 90 60 40 20 0 Success/Failure for Users 1 2 3 4 5 6 7 8 Users (a) Only PIN Success/Failure for Users 1 2 3 4 5 6 7 8 Users (b) PIN on PIN Template Fig. 7: Success/Failure Ratio for Each Participant the SEPIA service addresses these these possible credit card attacks. Modern solutions for secure financial transactions involve card-less interactions, where users generally rely on a secondary device to perform the operation [7, 8]. However, such solutions have also triggered an increase in stolen credentials which occur with lost devices. There are numerous gamebased authentication techniques, such as the cognitive trapdoor game [29], used to secure PIN entry and authentication for ATMs. Unfortunately, these cognition-centric designs for security will always have limited usability for general users. Sasamoto et al. [13] presented Undercover, a shoulder-surfing resistant PIN authentication. Luca et al. presented Vibraass [26], which uses the phone s vibration channel as a tactile input for preventing shoulder-surfing. These solutions rely on additional hardware requirements at the ATM terminals and may not be a ready-to-deploy solution for secure PIN authentication. SEPIA can work with currently supported hardware on ATM and point-of-service terminals. Lee et al. have presented a similar PIN-mapping technique in [19], and proposed quantitative techniques to evaluate the security for PIN-based authentication approaches. With the introduction

of modern devices as the Google Glass, usability of such secure systems can be leveraged greatly. A similar work to ours, Ubic, uses Google Glass to perform decryption of an onscreen QR-based password using the client s certificate [21]. However, SEPIA does not rely on stored client certificates, and can be considered resistant to attacks even if the user loses the personal device. Moreover, the SEPIA service allows the users devices to offload any security critical operations to the cloud and is highly scalable without imposing any resourcehungry operations on the personal mobile or wearable devices. VIII. CONCLUSION ATM authentication using PIN-based entry is highly susceptible to shoulder-surfing or observation attacks. Credit/Debit cards are also not resilient to relay and other skimming and cloning attacks. In this paper, we propose the Secure-PIN- Authentication-as-a-Service (SEPIA), a cloud-based obfuscated PIN-based authentication service for ATMs or point-ofservice terminals using personal mobile or wearable devices. We have focused the security design for SEPIA based on visual privacy of users for a one-time-use PIN template and address the security vulnerabilities in PIN-based authentication. The protocol does not require any additional hardware support for currently operating ATM terminals and employs offloaded computation from the mobile device for verifying the transaction requests. A proof-of-concept prototype implementation was used to perform experimental analysis and a usability study. Results show that users are easily adapted to the process of template-based authentication. Our future work involves applying the SEPIA service to newer application fields, such as, PIN-enabled doors and visual authentication mechanisms. ACKNOWLEDGMENT This research was supported by a Google Faculty Research Award, the Department of Homeland Security Grant FA8750-12-2-0254, and by the National Science Foundation CAREER Award CNS-1351038. REFERENCES [1] L. Coventry, A. De Angeli, and G. Johnson, Usability and biometric verification at the atm interface, in Proceedings of the SIGCHI conference on Human factors in computing systems. ACM, 2003, pp. 153 160. [2] A. De Luca, M. Langheinrich, and H. Hussmann, Towards understanding atm security: a field study of real world atm use, in Proceedings of the 6th Symposium on Usable Privacy and Security. ACM, 2010. [3] S. Raj and A. Portia, Analysis on credit card fraud detection methods, in Computer, Communication and Electrical Technology (ICCCET), 2011 International Conference on, March 2011, pp. 152 156. [4] N. Sethi and A. Gera, A revived survey of various credit card fraud detection techniques, International Journal of Computer Science and Mobile Computing, vol. 3, no. 4, pp. 780 791, April 2014. [5] M. Dlamini, J. H. Eloff, and M. M. Eloff, Information security: The moving target, Elsevier Computers & Security, vol. 28, no. 3, pp. 189 198, May 2009. [6] T. P. Bhatla, V. Prabhu, and A. Dua, Understanding credit card frauds, Cards business review, vol. 1, no. 6, 2003. [7] G. Stanley, Card-less financial transaction, Apr. 21 2014, US Patent App. 14/257,588. [8] S. N. White, Secure mobile-based financial transactions, Feb 2013, US Patent 8,374,916. [9] E. Weise, Home depot s credit cards may have been hacked, Online at http://www.usatoday.com/story/tech/2014/09/02/home-depotcredit-cards-hack-russia-ukraine/14972179/, Sep 2014, usatoday. [10] R. Khan, M. Mizan, R. Hasan, and A. Sprague, Hot zone identification: Analyzing effects of data sampling on spam clustering, Journal of Digital Forensics, Security and Law (JDFSL), vol. Vol. 9, no. 1, pp. 67 82, 2014. [11] Bureau of Justice Statistics, Identity Theft Supplement (ITS) to the National Crime Victimization Survey, Online at http://www.bjs.gov/ content/pub/pdf/vit12.pdf. [12] R. Anderson, Why cryptosystems fail, in Proceedings of the 1st ACM Conference on Computer and Communications Security. ACM, 1993, pp. 215 227. [13] H. Sasamoto, N. Christin, and E. Hayashi, Undercover: Authentication usable in front of prying eyes, in Proceeding of The 26th Annual SIGCHI Conference on Human factors in Computing Systems. New York, NY, USA: ACM, 2008, pp. 183 192. [14] M. Roland and J. Langer, Cloning credit cards: A combined pre-play and downgrade attack on emv contactless. in Proceedings of The 7th USENIX Workshop on Offensive Technologies, 2013. [15] R. Anderson and S. J. Murdoch, Emv: Why payment systems fail, Communications of the ACM, vol. 57, no. 6, pp. 24 28, Jun 2014. [Online]. Available: http://doi.acm.org/10.1145/2602321 [16] S. Drimer and S. J. Murdoch, Keep your enemies close: Distance bounding against smartcard relay attacks. in Proceedings of The 16th USENIX Security Symposium, 2007, pp. 87 102. [17] S. Schaible, How thieves clone your credit cards, Online at http: //www.wfla.com/story/26074193/credit-cards-cloned, Jul 2014, wfla News Report. [18] J. Kegley, Financial crimes: Credit card cloning is a growing form of identity theft, Online at http://www.kentucky.com/2012/06/24/ 2236535/financial-crimes-credit-card-cloning.html, Jun 2012. [19] M.-K. Lee and H. Nam, Secure and usable pin-entry method with shoulder-surfing resistance, in HCI International 2013-Posters Extended Abstracts. Springer, 2013, pp. 745 748. [20] M.-K. Lee, Security notions and advanced method for human shouldersurfing resistant pin-entry, IEEE Transactions on Information Forensics and Security, vol. 9, no. 4, pp. 695 708, April 2014. [21] J. Hsu, How google glass can improve atm banking security, Online at http://spectrum.ieee.org/tech-talk/consumer-electronics/gadgets/howgoogle-glass-can-improve-atm-banking-security, Mar 2014, ieee Spectrum. [22] S. Safavi and Z. Shukur, Improving google glass security and privacy by changing the physical and software structure, Life Science Journal, vol. 11, no. 5, pp. 109 117, 2014. [23] B. Krebs, Would you have spotted the fraud? Online at http: //krebsonsecurity.com/2010/01/would-you-have-spotted-the-fraud/, Jan 2010, krebs on Security, In-depth security news and investigation. [24] L. Richardson and S. Ruby, RESTful web services. O Reilly Media, Inc., 2008. [25] Y. Liu, J. Yang, and M. Liu, Recognition of qr code with mobile phones, in Control and Decision Conference, 2008. CCDC 2008. Chinese, July 2008, pp. 203 206. [26] A. De Luca, E. von Zezschwitz, and H. Huβmann, Vibrapass: Secure authentication based on shared lies, in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, ser. CHI 09. New York, NY, USA: ACM, 2009, pp. 913 916. [27] A. Vukotic and J. Goodwill, Apache Tomcat 7, 1st ed. Berkely, CA, USA: Apress, 2011. [28] N. Asokan, H. Debar, M. Steiner, and M. Waidner, Authenticating public terminals, Computer Networks, vol. 31, no. 8, pp. 861 870, 1999. [29] V. Roth, K. Richter, and R. Freidinger, A pin-entry method resilient against shoulder surfing, in Proceedings of the 11th ACM Conference on Computer and Communications Security. New York: ACM, 2004, pp. 236 245.