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-aService (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. I NTRODUCTION
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 Glass1 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-aService (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. T HE SEPIA M ODEL
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]
1. Touch screen to initiate
Touch to begin
6. Scan QR Code
User
10. [PIN on PIN_Template]
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. T HE SEPIA P ROTOCOL
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, IsU sed]
(2)
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
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]
(3)
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:
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 ⇒ [U sername, P assword,
Loc ID, Req ID, T ran ID]
(5)
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.
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 , l o c I D , 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 ( success ) then :
REC <− g e t r e c ( l o c I D , reqID , t r a n I D ) ;
i f (REC ! = n u l l ) t h e n :
c u r r T i m e <− g e t s y s t e m t i m e ( ) ;
i f ( ( c u r r T i m e − REC . TS ) < REC . V a l i d i t y )
then :
i f (REC . I s U s e d == FALSE ) t h e n :
u p d a t e (REC . I s U s e d , TRUE ) ;
r e t u r n ( s u c c e s s , REC ) ;
else :
return ( failure ,
” Repeated t r a n s a c t i o n ” ) ;
else :
return ( failure ,
” Expired t r a n s a c t i o n ” ) ;
else :
return ( failure ,
” Invalid transaction request ”);
else :
return ( failure , ” Invalid user ”);
}
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] ]
(6)
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
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. D ESIGN A NALYSIS
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. I MPLEMENTATION
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
Creates
OK Glass
SEPIA Options
Initialize SEPIA
Tap to start
Start SEPIA
New
Create
Google
New
Glass
Password Password
Scan Code
New Password
abcdefgh
Start
Camera
View
Scan QR
code
PIN
Display
Template
PIN
3 4 * * 9 * * 0 Template
Fig. 3: SEPIA Google Glass Application User Flow
C. SEPIA User Application
(a) Java Desktop ATM Ap- (b) SEPIA ATM Application Running
plication Layout
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 Pis2 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/
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
(a) ATM TRAN REQ & ATM TRAN RES
Mean: 4177360
(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. U SABILITY S TUDY
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
Times Required (milliseconds)
Times Required (milliseconds)
QR Scan Time Required (milliseconds)
Phone
User
(a) User-wise Distribution of QR Scan Times
Google Glass
(b) Aggregate Data Distribution for QR Scan Times
PIN Entry Time Required (milliseconds)
Response and PIN Template Entry Time Required (milliseconds)
Fig. 5: QR Code (200px*200px) Scan Times using Mobile Phone and Google Glass
Users
(a) Only PIN
Users
(b) PIN on PIN Template
Fig. 6: Time Required by Participants
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 for Users
100
Success/Failure
90
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.
60
40
20
C. PIN and Obfuscated PIN Entry
VII. R ELATED W ORK
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
0
1
2
3
4
5
Users
6
7
8
7
8
(a) Only PIN
Success/Failure for Users
100
Success/Failure
90
Success/Failure (Percentage)
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.
60
40
20
0
1
2
3
4
5
Users
6
(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. C ONCLUSION
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-PINAuthentication-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 FA875012-2-0254, and by the National Science Foundation CAREER
Award CNS-1351038.
R EFERENCES
[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.