TRANSFERRING ATM INTERFACE AND INTERACTION TO

Submitted by Emre Zaim Submitted at Institut Integriert Studieren Supervisor a.Univ.-Prof. Dr. Klaus Miesenberger Co-Supervisor Dipl.-Ing. Peter Heumader Month Year March 2017

TRANSFERRING ATM INTERFACE AND INTERACTION TO MOBILE DEVICES FOR ENHANCING ACCESSIBILITY AND USABILITY

Master Thesis to obtain the academic degree of

Diplom-Ingenieur in the Master’s Program

Computer Science

ACKNOWLEDGEMENTS

I would like to thank Prof. Miesenberger for his assistance and guidance during the development of this thesis as well as for coming up with such an interesting subject for me to write my thesis about. I would also like to thank the staff members of Institut Integriert Studieren, especially Daniel Pöll and Bernhard Stöger, Gerhard Nußbaum and Franziska Mitter of Kompetenznetzwerk Informationstechnologie zur Förderung der Integration von Menschen mit Behinderungen, who took the time to participate in usability studies and test the prototype with me. Their valuable feedback and the insight gained in these real-world tests made the final form of the prototype possible. To my mother: Thank you for always supporting me in life, even when my decisions did not make sense to you. To my father: I wish you were here to see that I finally graduated from university. To Marlene: Thank you for being in my life.

ABSTRACT

Self-service terminals are becoming more and more the only point of access to many services in today’s “self-service society”. They can be found in many areas of everyday life like train stations, universities, bus stops, libraries, movie theaters, airports and banks, with the ATM being the first and still the most commonly used self-service terminal. Unfortunately, ATMs are not very accessible for people with disabilities like blind people, people with cognitive disabilities, the elderly, deaf people and people with motor disabilities. Lack of accessibility is especially problematic with ATMs, because the services of an ATM cannot be accessed through alternative ways like a mobile application. The reason for that is that the user has to be physically present at the ATM and interact with it directly as transaction of money in cash is involved. That makes accessible interaction with ATMs an absolute necessity for users with disabilities. Improving ATM accessibility is difficult for a couple of reasons: There are no universal standards and guidelines for ATM accessibility that manufacturers and developers could rely on. Accessibility needs of individual user groups are well known, e.g. blind people need screen readers and / or braille displays, but ATM hardware is not easily extensible to accommodate these needs. In other words, one cannot simply add hardware and software accessibility tools to an ATM in an effort to make it more accessible. In addition, a feature or a tool that a user with a specific disability needs can be a barrier for another user with a different disability or a user without any disabilities. Trying to implement a lot of accessibility features in one machine would inevitably lead to an over-cluttered UI and bad usability for all users. This thesis presents an alternative approach for making ATMs more accessible: Decoupling the interaction from the ATM and shifting it as much as possible to the personal accessible environment of the user’s choice. Parts of the interaction that cannot be decoupled and have to take place at the ATM are executed with a mobile device and a very simple two-step workflow. The solution idea introduces the concept of a digital token that is generated in the personal accessible environment of the user and contains the same information that would result from the traditional interaction with the ATM. This digital token is stored securely on the mobile device of the user and is used later to execute the pre-prepared interaction at the ATM. The resulting experience is less stressful and faster for users with disabilities and requires no changes to the ATM hardware itself. The concrete solution idea and the prototype presented in this thesis are tailored specifically for ATMs, but the general concept – called TokenAccess – could be adapted to any type of self-service terminal.

ZUSAMMENFASSUNG

Selbstbedienungsautomaten werden immer mehr und mehr zum einzigen Zugangspunkt für viele Dienstleistungen in der heutigen „Selbstbedienungs-Gesellschaft“. Man findet sie in vielen Bereichen des Alltags wie Bahnhöfen, Universitäten, Bushaltestellen, Bibliotheken, Kinos Flughäfen und Banken, wobei der Bankomat der erste und immer noch der am häufigsten gebrauchte Selbstbedienungsautomat ist. Leider sind Bankomaten nicht sehr barrierefrei für Menschen mit Behinderungen wie zum Beispiel blinde Menschen, Menschen mit kognitiven Behinderungen, ältere Menschen, gehörlose Menschen oder Menschen mit motorischen Behinderungen. Fehlende Barrierefreiheit ist gerade bei Bankomaten ein großes Problem, weil die Dienstleistungen eines Bankomaten nicht über alternative Wege wie z.b. durch eine mobile Applikation in Anspruch genommen werden können. Der Grund dafür ist, dass der Benutzer physisch am Bankomaten anwesend sein und mit ihm direkt interagieren muss, weil Bargeld in der Transaktion involviert ist. Bankomaten barrierefrei zu gestalten ist aus einigen Gründen sehr schwierig: Es gibt keine universellen Standards und Richtlinien, auf die sich Hersteller und Entwickler stützen können. Die Bedürfnisse einzelner Benutzergruppen für eine barrierefreie Interaktion sind zwar bekannt – blinde Benutzer brauchen z.B. Sprachausgabe und eine Braillezeile – aber die Bankomat-Hardware kann nicht einfach erweitert werden. Anders gesagt: Man kann einem Bankomaten nicht einfach Hardware- und Software-Tools für Barrierefreiheit hinzufügen, um den Bankomaten barrierefreier zu machen. Des Weiteren kann ein Tool, das ein Benutzer mit einer bestimmten Behinderungen braucht, für einen anderen Benutzer mit einer anderen Behinderung eine Barriere darstellen. Der Versuch, sehr viele Tool für Barrierefreiheit in einem einzigen Automaten zu implementieren, würde unvermeidlich zu einer überladenen Benutzeroberfläche und schlechter Bedienbarkeit für alle Benutzer führen. Diese Arbeit präsentiert einen alternativen Ansatz, um Bankomaten barrierefreier zugänglich zu machen: Die Interaktion mit dem Bankomaten wird so gut wie möglich vom Bankomaten entkoppelt und in die persönliche, bereits barrierefreie Arbeitsumgebung des Benutzers verlagert. Teile der Interaktion, die nicht entkoppelt werden können und am Bankomaten stattfinden müssen, werden mit einem mobilen Gerät und einem sehr einfachen Ablauf, bestehend aus nur zwei Schritten, gelöst. Die Lösungsidee führt das Konzept eines digitalen „Tokens“ ein, welcher in der persönlichen barrierefreien Arbeitsumgebung des Benutzers erstellt wird und die gleichen Informationen beinhaltet, die aus der traditionellen Interaktion mit dem Bankomaten resultieren würden. Dieser Token wird auf dem mobilen Gerät des Benutzers gesichert gespeichert und später für die Ausführung der vorbereiteten Interaktion am Bankomaten verwendet. Das resultierende Erlebnis ist weniger stressbehaftet für den Benutzer mit Behinderungen und erfordert keine Hardware-Änderungen bei Bankomaten. Die konkrete Lösungsidee und der Prototyp sind speziell für Bankomaten entwickelt, aber das allgemeine Konzept, genannt „TokenAccess“, könnte auf jede Art von Selbstbedienungsautomaten adaptiert werden.

TASK DEFINITION

At the Institut Integriert Studieren (IIS), accessible interaction concepts for SSTs (Self-Service Terminals), parcel machines and ATMs (Automated Teller Machines) are being researched. The use of these machines is difficult for many people: � Blind people have to memorize the key combinations for withdrawing money, because they

receive no feedback for the input. This is on the one hand very unsecure and on the other hand very error-prone.

� People with low vision cannot read the contents of the screen without appropriate magnification.

� The elderly often avoid these machines because they are afraid of making mistakes or because the user interface is overwhelming for them.

� People with restricted mobility cannot use wrongly positioned terminals.

It would make sense for these people to be able to execute the interaction with the machine with the help of a mobile device. In this master’s thesis, a prototype should be developed that enables interaction with an SST over RFID / NFC. Because users with different types of disabilities would be using the prototype, a special focus should be put on the accessibility of the implementation. Additionally, it should be possible to prepare the planned interactions with the SST over a web interface at home. As soon as the user reaches the SST, the interaction should be executed as automatically as possible. For the development of the prototype, a normal PC or a tablet can be used as the “Test-SST”. Goals / Expected results: � Analysis and selection of existing technologies for the implementation

� Development of a concept for operating the SST over a smart phone

� A prototype implementing this concept

� Usability study

Table of Contents

1. Introduction ........................................................................................................................... 1

2. Problem Analysis .................................................................................................................. 3

2.1. The difficulties in ATM accessibility ............................................................................... 3

2.2. Target group .................................................................................................................. 4

2.2.1. Blind and visually impaired people ...................................................................... 5

2.2.2. Elderly people ..................................................................................................... 5

2.2.3. Deaf people and people with hearing loss .......................................................... 5

2.2.4. People with cognitive and learning disabilities .................................................... 5

2.2.5. People with motor disabilities.............................................................................. 5

2.2.6. People without any disabilities ............................................................................ 6

3. State of the Art and Requirements Analysis for Defining Research Questions ...................... 7

3.1. Current trends in ATM accessibility ............................................................................... 7

3.1.1. APSIS4all – Direct interaction ............................................................................. 7

3.1.2. APSIS4all – Indirect interaction .......................................................................... 9

3.1.3. INREDIS – Indirect interaction .......................................................................... 10

3.1.4. Summary .......................................................................................................... 11

3.2. Requirements .............................................................................................................. 12

3.3. Research questions related to decoupling the ATM interface and interaction .............. 15

4. Interaction with ATMs: Analysis and Design ....................................................................... 16

5. Interaction Design TokenAccess ......................................................................................... 20

5.1. User centered design .................................................................................................. 21

5.2. Executing the prepared interaction at the ATM ............................................................ 25

5.3. Further examples of the TokenAccess interaction model ............................................. 29

5.3.1. Depositing money at an ATM with TokenAccess .............................................. 29

5.3.2. Buying tram tickets at a ticketing machine with TokenAccess ........................... 31

6. TokenAccess Architecture and Security .............................................................................. 34

6.1. Architectural overview ................................................................................................. 34

6.1.1. The TokenAccess web interface ....................................................................... 34

6.1.2. The mobile device of the user ........................................................................... 35

6.1.3. The TokenAccess server .................................................................................. 35

6.1.4. A cloud messaging service ............................................................................... 36

6.1.5. The ATM .......................................................................................................... 36

6.1.6. The payment host ............................................................................................. 36

6.2. Security considerations ............................................................................................... 36

6.2.1. HTTP over SSL/TLS ......................................................................................... 37

6.2.2. HTTPS with client authentication ...................................................................... 37

6.2.3. Google Cloud Messaging ................................................................................. 38

6.2.4. Secure communication over NFC ..................................................................... 41

6.2.5. Authenticity and integrity of the token ............................................................... 46

6.2.6. Secure storage of the token on the mobile device ............................................ 48

6.2.7. Attack scenarios ............................................................................................... 49

7. Prototype Implementation................................................................................................... 53

7.1. TokenAccess server – Play web application ............................................................... 53

7.1.1. Architecture ...................................................................................................... 53

7.1.2. Connecting the mobile device to the TokenAccess server................................ 58

7.1.3. Creating tokens and sending them to the mobile device .................................. 62

7.1.4. WCAG 2.0 compatibility ................................................................................... 65

7.2. TokenAccess client – Android application ................................................................... 65

7.2.1. Architecture ...................................................................................................... 67

7.2.2. Decoding the audio enrollment message ......................................................... 73

7.2.3. Secure storage of tokens ................................................................................. 75

7.3. ATM simulation – Android application ......................................................................... 77

7.3.1. Architecture ...................................................................................................... 79

7.3.2. Mobile device to ATM communication .............................................................. 83

7.4. Installation and setup of the prototype environment .................................................... 89

7.4.1. Hardware and software requirements............................................................... 89

7.4.2. Installation ........................................................................................................ 90

7.4.3. Getting the source code ................................................................................... 91

8. Usability Study ................................................................................................................... 93

9. Conclusions and Future Work .......................................................................................... 101

10. Bibliography ..................................................................................................................... 103

11. List of figures .................................................................................................................... 109

March 17, 2017 Emre Zaim 1/114

1. Introduction

ATMs have a long history – the first one was installed in London in 1967 [1] – but the level of accessibility for them is still not very good [2]. Nowadays, some ATMs offer a headphone jack and a screen reader as well as braille on the keys. In practice though, interacting with the terminal using a headphone and the screen reader is hard to learn in the first place and very time consuming afterwards, so that many blind people resort to giving away their PIN code and bank card to a person of their trust and have this person withdraw money for them [3] [4]. As you can imagine, this can be problematic for many reasons. Conditions for bank cards of most banks cite that the owner of the card is not supposed to give the card and the PIN to a third party: “The bank card must not be passed to a third party”, “The PIN shall be kept secret. The PIN must not be disclosed to anybody, not even to employees of the bank, other Account Holders or other Cardholders” [5]. Ignoring this means that the bank would most likely refuse liability in case the card got lost or stolen and money would be withdrawn from the customers bank account. The fact that many blind people still choose to give away their bank card and PIN code instead of using the ATM themselves is a testimony to the lackluster accessibility of these devices. Even when a blind user decides to go ahead and use the ATM on his own, the interaction is very time consuming and unpleasant. Little things like finding the slot for the headphone jack can be difficult. The added stress of possibly having others waiting in line behind you and maybe even hearing them complain certainly does not help, too. A basic interaction like withdrawing money that might take someone without disabilities about two minutes can take more than five times as much time for a blind user [6]. Blind people are not the only user group affected by the poor accessibility of ATMs. People with low vision, people with restricted mobility, people with cognitive disabilities, deaf people and the elderly are all affected by the poor accessibility of ATMs. The concept presented in this thesis – called TokenAccess – offers an alternative solution for improving the accessibility of ATMs for users with disabilities and also for enhancing the usability of ATMs for all user groups, both with and without disabilities. The main idea of TokenAccess is to shift the interaction from the ATM interface to a more familiar interface that the user is already accustomed to and one that already caters to the users accessibility needs. The interaction is prepared using a web interface and then securely stored on the mobile device of the user as a digital token, hence the name TokenAccess. This stored interaction in the form of a digital token is then executed at the ATM at a later time. As most of the interaction is moved away from the ATM, TokenAccess can cater to users with different disabilities without running into the problem of overcomplicating the ATM interface itself. The ATM hardware can mostly be left as is, the only hardware requirements for a TokenAccess compatible ATM are an NFC reader and internet connectivity. NFC is already being added to many ATMs as part of contactless payment solutions [7] [8] and internet connectivity is a given at this day and age. For banks, this means not having to invest in new ATM hardware, which would make TokenAccess easy to adapt in a real-world scenario.


Video of Tommy Edison, a blind radio presenter and film critic with his own YouTube channel about everyday experiences of the blind, showing the hurdles of withdrawing money from an ATM using headphones and the ATM’s screen reader [6].


2. Problem Analysis

2.1. The difficulties in ATM accessibility

Accessibility means removing barriers that prevent people with disabilities from participating in substantial life activities, including the use of services, products and information [9]. Some examples are the bell that chimes to notify blind people that an elevator is about to arrive or the curb cut ramps on street corners for wheel chair users. Human-computer interaction (HCI) accessibility is a special subdomain of accessibility that is concerned with enabling people with disabilities access to computer systems. ATMs are a special type of computer system, an electronic telecommunications device that enables customers to perform financial transactions. As such, the problem of ATM accessibility is not just about the physical accessibility of the ATM but at the same time about the HCI accessibility of the ATM interface. There are legislations about ATM accessibility, for example the 2010 ADA (Americans with Disabilities Act) Standards [10]. The 2010 ADA Standards cover the physical accessibility of the ATM like ground clearance and also accessibility considerations about the input mechanism and speech output (see sections 707.2, 707.5 and 707.6 in [10]). The accessibility of the interaction with the ATM interface is not fully covered. What we mean by that is that the ADA Standards do not contain concrete interaction models and guidelines for making the ATM interface accessible for users with disabilities. Similar to the 2010 ADA Standards, there is a current proposal of the European Union called the European Accessibility Act [11] which covers some aspects of ATM accessibility (Annex I, Section II). The relative section “User interface and functionality design” describes what the UI (UI) of an ATM should be capable of, such as “provide for communication and orientation via more than one sensory channel” or “provide for flexible magnification and contrast”, but similar to the ADA guidelines, the European Accessibility Act also doesn’t provide detailed guidelines for how to achieve these. In contrast, HCI accessibility on personal devices like the PC or mobile devices (smartphones and tablets) is better researched with existing design guidelines, for example the Web Content Accessibility Guidelines (WCAG 2.0) [12], which is also recognized as the ISO Standard “ISO/IEC 40500:2012 Information technology – W3C Web Content Accessibility Guidelines (WCAG) 2.0“ [13]. These guidelines not only describe what the UI should be capable of – be perceivable, operable, understandable and robust [14] – but also how to achieve these [15]. The WCAG guidelines were initially devised for the web, but they can be applied to other platforms as well [16]. Besides WCAG, there are also vendor specific guidelines for making applications accessible on the most widely used PC and mobile platforms. For example accessibility guidelines for Windows [17], Mac OS [18], Android [19] and iOS [20] application development. This lack of guidelines for developers is one of the major obstacles in the way of better usability and accessibility for ATMs. The “inflexibility” of ATMs in terms of modularity and upgradeability is another obstacle. Even if legislations and standards were to include detailed design guidelines, it would take several years until ATM manufacturers would adapt the guidelines and banks would start deploying these new


ATMs. In the USA for example, more than half of the ATMs were still not compatible with the 2010 ADA Standards as of 2012 [21]. In 2012 and 2013, several ADA related law suits were filed against financial institutions [22] [23] which finally accelerated the adaptation rate. Another problem is that different disability types require very distinct accessibility tools. People with disabilities usually have their personalized work environments with hardware and software tools that are suited to their exact accessibility needs. A blind user might attach a refreshable braille display [24] to his PC and install a screen reader software [25], whereas a user with severe motor disability would probably use a mouth operated mouse [26]. This type of personalization is not possible with ATMs because they are not personal devices. Users cannot be expected to carry their accessibility setup with them all the time to connect to the ATM and user-installed unauthorized software on the ATM will not be permitted for security reasons. It would also not be possible that the ATM houses the hardware and software required to accommodate the needs of all users, e.g. a keypad, a refreshable braille display, a mouth operated mouse, tremor reduction capabilities etc. Leaving aside the space limitations and the associated costs, this would inevitably lead to a machine with an over cluttered UI and bad usability for all users. In human-computer interaction, what is “good for someone” is not always “good for someone else” [9]. In other words, accessibility tools that help a specific group of users might end up hindering another group of users with different disabilities and especially users without disabilities. Elderly people for example often have low vision and also deterioration in cognitive capacity like memory, attention span and reaction time [27]. A UI with large fonts and high contrast would be more accessible for elderly people given their low vision. Also texts composed in simple language, pictures next to the text, didactic illustrations and slow animations might make a better UI for elderly people [28]. However, such an interface might be perceived as unpleasant and slow by users without disabilities. Blind users would need speech output, e.g. a screen reader and deaf users would need visual notifications such as closed captions and visual alerts as alternatives to sound alerts. A user without disabilities would not want to deal with all the voice descriptions and closed captions and flashing screens [9].

2.2. Target group

The focus of the alternative ATM interaction model presented in this thesis is to make the ATM more accessible to people with various types of disabilities. At the same time, we believe that the adaptation of an alternative ATM interface by the banks is only possible through “universal design” given the costs and logistics involved with deploying and upgrading ATMs. Universal design broadens the term “accessibility” to encompass more than design for people with disabilities [9]. Universal design means “the design of products and environments to be usable by all people, to the greatest extent possible, without adaptation or specialized design” [29]. Automatic doors are a good example of universal design. With automatic doors, people with disabilities who were previously unable to open doors are now able to, and for people without disabilities, the task of opening the door has become easier [9]. Similarly, our proposed improvement to the ATM interface aims to make the ATM more accessible to people with disabilities and easier and quicker to use for people without disabilities. In the next sections, we will explain shortly what problems people from each target group experience when using an ATM.


2.2.1. Blind and visually impaired people

Blind and visually impaired people usually rely on the speech function of the ATM. In a usability study conducted by the Swedish Post and Telecom Agency, visually impaired users stated that they usually avoid the speech function of the ATM in public places as this causes a certain degree of insecurity and vulnerability [30]. Blind users usually have to memorize the full sequence of key strokes for ATM operations like withdrawing money [31], which might become problematic if the blind user is elderly or simply does not have the memory capacity. A design survey conducted by the Georgie Tech Research Institute has shown that blind people have the most difficulty with operations like making cash withdrawals, making deposits, checking account balances or printing a statement [32].

2.2.2. Elderly people

According to [33], the most common problems elderly people have when using an ATM are “understanding how to perform operations” and “the inability to see the screen well”. The explanation is that elderly people have low vision and also deterioration in cognitive capacity like memory, attention span and reaction time [27], as mentioned before. The elderly are an especially important target group, as most people will fall into this category later in their lifetime and also because the number of elderly people is growing. According to Administration on Aging [34], the number of elderly people – people aged 65 or older was 46.2 million in 2014 – in the USA and made up 17.4% of the overall population and this number is expected to grow to 21.7% by 2040. By 2060, there will be about 98 million elderly people according to the same report, more than twice the number compared to 2014.

2.2.3. Deaf people and people with hearing loss

For people who are deaf or hearing loss, using ATMs can be problematic if the machine relies on sound to indicate errors or key-presses. Also, a study in Canada has found that the average reading age for people who are deaf is equivalent to year five [31]. This means that deaf people might have difficulties with reading and understanding the labels presented on the ATM UI if these are not written in an easy-to-understand language.

2.2.4. People with cognitive and learning disabilities

People with cognitive disabilities can have difficulties with ATMs when the steps in the transaction are not consistent, logical and focused on the result. They need consistency of steps in transactions, without distractions and a limited number of potentially distracting choices. With so many different ATM models, there is little consistency between them. Screen readers, simplified language and a more pictorial UI might make the ATM UI more accessible for people with cognitive disabilities [31].

2.2.5. People with motor disabilities

Most of the problems that people with motor disabilities have when using an ATM are related to the physical accessibility of the ATM. For example when wheel chair users operate an ATM, their eye levels are lower, their posture control is less stable and the space for machine


operation is narrower and lower compared to users who operate the ATM from a standing position [35]. People with motor disabilities like cerebral palsy, Parkinson’s disease or essential tremor also have problems using the ATM interface. For example people with cerebral palsy are generally speaking able to use computers, but have difficulties with the mouse and the keyboard as their arm movements are often too jerky [36]. Similarly, these users would have difficulties inserting their bank card into the ATM card slot and operating the keypad.

2.2.6. People without any disabilities

While people without any disabilities do not have major problems with the ATM interface, we believe that there is room for improvement when it comes to ease of use and usability. Entering the PIN, selecting the desired operation, confirming this operation etc. can in sum take a long time. Shortening the total interaction time with the machine can be especially of interest for other self-service terminal types like ticketing machines, where the user might be in a hurry. The interface of a foreign ATM might differ greatly from the local ATM the user is used to and might not offer the native tongue of the user as an option, making the interaction difficult and unsure even if there are no barriers related to disability. In these and similar situations, users without any disabilities would also benefit from an alternative ATM interaction model that is simpler and quicker.


3. State of the Art and Requirements Analysis for Defining Research Questions

3.1. Current trends in ATM accessibility

There are currently two main trends addressing accessibility barriers of ATMs. The first line focuses on modelling the user’s needs and preferences and coding them in a standardized way to adapt the self-service terminal interfaces automatically (“direct interaction”). The second trend focuses on reducing the required interaction through the self-service terminal by enabling users to carry out their requests though their preferred device (“indirect interaction”) [37]. Both approaches have their advantages and disadvantages: We will look into some examples from both approaches and explain how they relate to our solution idea later on.

3.1.1. APSIS4all – Direct interaction

APSIS4all is a project aimed at personalizing Public Digital Terminals for all. It also overcomes the existing accessibility barriers faced by people unfamiliar with ICT, people with disabilities and older people when interacting with public digital terminals, such as ATMs and ticket vending machines [38]. APSIS4all offers two different solutions for making ATMs more accessible, the first solution is based on the “direct interaction” approach. The fundamental idea of the “direct interaction” approach in APSIS4all is to personalize the ATM on site according to the user’s needs [39]. First, the user has to create a “user profile” by filling out a questionnaire about their disability and their accessibility needs. This user profile is then encoded according to the standard specification in EN 1332-4 [40]. Finally, a new bank card can be ordered with the encoded user profile stored on it to be used for future interactions with the ATM.

Figure 1: The user starts by selecting one of the predefined disability types.


Figure 2: The user answers additional questions about his accessibility needs and preferences.

Figure 3: Once the user profile is finalized, a new bank card has to be ordered that can later be used at compatible

ATMs to adapt the ATMs interface according to the user profile. Once at the ATM, the user activates his profile by touching the NFC reader of the ATM with his bank card. The ATM interface changes according to the user profile stored on the card, for example larger UI elements and higher contrast for a visually impaired user, a sign language avatar for a deaf user or a simplified interface for elderly people.

Figure 4: The ATMs interface is adapted to the user’s needs according to the user profile stored on the bank card [41].


This direct interaction approach of APSIS4all is deployed on over 800 ATMs of the Spanish bank “La Caixa” in Barcelona and Madrid [39], so its “real world applicability” is proven to some extent. That being said, we see two main problems with this solution: � A new bank card has to be ordered in order to be able to use the system. This means

additional complexity, waiting time and cost for the user.

� The ATM UI has to be rewritten to support many user profiles. Some components of the existing UI can be reused, but features like sign language avatars would have to be done from scratch. We think that making the UI of ATMs from different manufacturers compatible with APSIS4all would take a very large effort.

3.1.2. APSIS4all – Indirect interaction

APSIS4all also includes a solution idea for the “indirect interaction” approach. In this solution idea, the self-service terminal operation is shifted to the Internet, so users can operate on their laptop or smartphone which is already configured according to their needs and preferences and has the corresponding assistive technologies installed when necessary [41]. The user executes the desired operation on his personal device (laptop or mobile device) and then receives a 2D-code with instructions. This code is scanned at the self-service terminal and the transaction is completed. In the case of a ticketing machine for example, after scanning the 2D-code, the user would receive the ticket that he has already bought online.

Figure 5: Buying the ticket with the mobile web application of APSIS4all [41].


Figure 6: The user buys the ticket online using the web app shown in Figure 5, receives the QR code and scans the

QR code at the ticket vending machine to receive his ticket [41]. In our opinion, the “indirect interaction” approach is the superior one as it does not impose as many requirements to the ATM as the “direct interaction” approach. Nevertheless, we still see some problems with the concrete solution idea proposed by APSIS4all: � The only example that demonstrates the workflow is a ticket vending machine. This type of

self-service terminal has next to none security requirements, in comparison to the ATM and the workflow does not necessarily need to be as fail-safe. It is not clear how the same workflow could be applied to ATM operations, for example withdrawing money: How would the user authenticate himself? How is an accidental scan handled? Etc.

� Scanning a QR code might be not so easy for blind users, users with motor impairments, or in general for users who have never scanned a QR code before. This is also apparent from the user experience data presented in one of the APSIS4all papers and the conclusion they come to: “Scanning bar codes requires some training. All participants used the mobile web app without problems. However, for most of the users it was the first time scanning barcodes and for some of them it was very difficult to find the right angle or place under the scanner “ [41, p. 10].

3.1.3. INREDIS – Indirect interaction

INREDIS is another solution idea that could be classified as an indirect interaction approach. The idea behind INREDIS is to turn the personal devices like laptops or mobile devices into personalized and universal remote controls [42]. This is achieved by generating a custom interface for the user’s device with the information at hand, e.g. “what are the accessibility needs of the user?”, “what kind of assistive technologies does the user’s personal device support?”, “what is the target device that is to be remote controlled?”, etc. When a blind user wants to interact with an ATM using INREDIS [42, pp. 3-4] : � He logs in into the INREDIS system on his mobile device.

� The INREDIS platform on the mobile device retrieves the profile of the user describing the users accessibility needs.

� The INREDIS platform also knows that the mobile device offers text-to-speech capabilities, so the “Interface Generator” will adapt the UI accordingly.


� From this point on, the user will use the UI created specifically for him to interact with the ATM.

� For example, after choosing how much money to withdraw and after the operation is accepted by the bank, the user is shown a confirmation screen on the mobile device. After the user presses the confirmation button on the mobile device, the ATM gives out the money. This way, the user can control exactly when he wants to receive the money, in case he needs more time finding the cash slot.

Figure 7: With INREDIS, a mobile device is used to control the ATM remotely [42].

As with the other approaches, we think there are some drawbacks of INREDIS as well: � The ATM would need to be modified heavily to be compatible with INREDIS. The connection

between the mobile device and the ATM is over Bluetooth for example. To our knowledge, currently there are no ATMs with Bluetooth capability. It would definitely be possible to equip ATMs with Bluetooth, but this means additional cost and deployment effort.

� Making the ATM remote controllable opens up a large attack surface. Security implications of remotely controlling the ATM, especially over Bluetooth, are not analyzed in detail in the INREDIS paper, only that a “session token” is sent to the mobile device from the (backend) banking system with a short expiration time.

3.1.4. Summary

� The indirect interaction approach shows more potential than the direct interaction approach, because it leverages the existing accessibility features of the user’s personal device more. As explained in the previous section “2.1. The difficulties of making ATMs accessible”, the ATM itself cannot be universally accessible by all users with different disabilities, but the personal device of the user can be made to be very accessible for that specific user.

� Any solution that imposes too many requirements to the ATM hardware will most likely not be adapted by ATM manufacturers and banks because of the associated costs and logistics of modifying or replacing ATMs. Ideally, the solution idea should make use of hardware features that are already embedded in most ATMs.


� For ATM solutions, security is a big aspect and the solution idea should be developed with security in mind from the beginning and the technologies required by the solution idea should be chosen accordingly.

3.2. Requirements

Having analyzed the current state of the art in ATM accessibility, we believe that the following requirements need to be fulfilled for the proposed concept to be accessible, easy to use, and easily adaptable by banks: � As much of the interaction as possible should be decoupled from the ATM.

� The remaining interaction with the ATM should

� …be executed using only the personal mobile device of the user.

� …be very easy to understand and remember.

� …not require fine motor skills to execute.

� …take very little time to complete.

� Internet connectivity and an NFC reader are the only hardware requirements for the ATM.

� The usability of the ATM for users without any disabilities should not be affected.

� Security level should be comparable to contactless payment options.

� As much of the interaction as possible should be decoupled from the ATM

Ideally, all interaction would be decoupled from the ATM and shifted to an alternative platform with better accessibility support, but this is not possible as the user has to be physically present at the ATM for the transaction of money. That is why we require that “as much of the interaction as possible” should be decoupled from the ATM. The idea is that we do not have to figure out how to solve the problem of accessibility for the parts of the interaction that can be decoupled from the ATM when this alternative platform is chosen smartly to be one with good accessibility support.

� The remaining interaction with the ATM should � …be executed using only the personal mobile device of the user. For the remaining parts

of the interaction that has to take place at the ATM, we still want to avoid direct interaction with the ATM as this would bring us back to the problem of making the ATM itself accessible. Instead a mobile device is chosen as the medium to be used for completing the interaction, because a large portion of the population already has one [43].

� …be very easy to understand and remember. The interaction with the ATM using the mobile device should be kept to a minimum and be very simple as the target group for TokenAccess consists among others of elderly people and users with cognitive disabilities. A simple interaction model that is easy to understand and remember should reduce the stress level at the ATM for these user groups.

� …not require fine motor skills to execute. TokenAccess should be usable by people with even severe motor disabilities. Elderly and blind people would also benefit from a solution that does not rely on fine motor skills.


� …take very little time to complete. As mentioned before, one of the biggest problems caused by bad accessibility of ATMs is that the current ATM interaction takes users with disabilities much longer than users without disabilities and this puts users with disabilities under a lot of stress. TokenAccess should enable users with disabilities to execute an operation at the ATM in the same timeframe as users without any disabilities. This should encourage users with disabilities to use ATMs instead of avoiding them.

� Internet connectivity and NFC reader as the only hardware requirements to ATMs Any solution proposal that requires hardware changes to the ATM would fail because of the massive costs and logistics involved with upgrading the ATMs. A system that works with the current hardware tools that ATMs offer would be a lot easier to adopt. The only hardware requirements of TokenAccess for ATMs are internet connectivity and NFC. Internet connection is given for almost all ATMs today as most ATMs are part of an “Interbank network” [44] and NFC capable ATMs are being introduced as NFC based payment options are gaining momentum [45], [46], [47], [48]. We also specify that internet connection is not required for the mobile device when interacting with the ATM. The reason is that the ATM might be placed anywhere, e.g. in a subway, in a closed building, in remote areas, etc. where the mobile device might not have internet connection.

� The usability of the ATM for users without any disability should not be effected As users without disabilities still make up the major portion of all users, new solutions for improving ATM accessibility should not affect the existing usability of the ATM for users without disabilities. This is also absolutely needed for the potential adaptation of the new solution, as banks would reject any accessibility improvements that come at the cost of decreased usability for users without disabilities. Furthermore, as explained in the section “2.2. Target group”, a well-designed and universal interface should be easy to use and accessible by all user types, both with and without any disabilities.

� Security level should be comparable to contactless payment options The number of contactless purchases made and the total revenue [49] indicates that users feel comfortable with the security tradeoffs of contactless payment options. That is why the security level and tradeoffs of contactless card payment are selected as a rough reference point for TokenAccess security considerations.


Figure 8: NFC capable ATM in Austria [50].

Figure 9: Another NFC capable ATM in Austria [51]


3.3. Research questions related to decoupling the ATM interface and interaction

The main idea behind our proposed solution concept TokenAccess is to decouple the ATM interface and realize it on an alternative platform with better accessibility and usability. The user would execute the interaction on this alternative platform instead of using the ATM interface, store the results of the interaction on his mobile device and transfer the prepared interaction to the ATM over Near Field Communication (NFC). There are open research questions to be answered before this solution idea can be realized: � Can we really decouple the ATM interface and interaction from the ATM and to what extent?

� Can we implement the steps, actions and user interfaces required to replicate the ATM interface and interaction on the alternative platform based on the WCAG 2.0 standard and the related methods, techniques and tools?

� Can the interaction at the ATM be reduced to a minimum based on the pre-executed interaction on the alternative platform and using NFC?

� Does the proposed solution meet users’ accessibility and usability requirements better than the current ATM interaction?

� Can we argue that all safety, security and privacy aspects are respected at the same level as with the ATM interaction?


4. Interaction with ATMs: Analysis and Design

We narrow down the interaction with the ATM to the two operations “withdraw money” and “deposit money” for simplicity and also because they are the most used operations at an ATM. Below is a simplified workflow of withdrawing money from an ATM and the role of each step in the interaction: � Insert your bank card into the ATM (Identification)

The bank card is used to transfer the account number or the card number to the ATM. This is mainly for identification purposes. The bank card – actually just the magnetic strip on the back of the card – holds the unique card number, expiration date of the card and sometimes the PIN offset (not the actual PIN itself), but this is becoming less and less common as almost all ATMs have internet access nowadays and the PIN offset can be stored on a special server and retrieved when you insert your bank card into the ATM [28]. At the same time, supplying the bank card can be seen as the first part of a two-factor authentication scheme [29]: The bank card is what the user “owns” and the PIN is what he “knows”.

� Enter your PIN code (Authentication) Entering the PIN code is the “real authentication” part of the interaction. Its purpose is to prevent the unauthorized withdrawal of money from the users account even if the bank card lands in the wrong hands.

� Select the operation (e.g. “withdraw money”) and the amount to withdraw (Input) The user interacts with the UI of the ATM to give the information needed by the machine to complete the transaction, e.g. selecting which operation to execute and entering additional information like the amount to withdraw.

� Confirm that you really want to withdraw the selected amount of money (Confirmation) Although not strictly necessary, almost all ATMs have confirmation as the second to last step of the interaction when a transaction of money is involved. In this step, the user is usually shown a summary of the transaction that is going to take place and is asked if he wants to continue with finalizing the transaction or if he wants to cancel and start over.

� Receive the money (Transaction) Taking out the bills from the ATM.

Other ATM operations, e.g. depositing money, can also be modelled using these five steps with slight modifications. Identification and authentication would stay the same as you still have to enter your bank card into the machine and type in your PIN. The input step would again be performed by choosing the operation using the ATM UI. Additionally, you would have to place the bills and coins you want to deposit in the designated area on the ATM. The confirmation step stays the same and the transaction would be the machine accepting the bills and printing out a receipt. We omit edge cases like the ATM not recognizing and rejecting the bills.


Figure 10: Basic interaction model for the ATM.

The main idea of TokenAccess is to design an alternative interaction model for the ATM where as many of the steps above as possible are decoupled from the ATM and are shifted to another platform with better accessibility support. We believe that by decoupling the interaction from the ATM and leveraging the existing accessibility support of other platforms like the PC and the web, a user centered interaction model can be developed that is more accessible for users with disabilities. Next we will analyze each step of the ATM interaction model above and try to find an answer to the question of whether or not this step can be decoupled from the ATM and shifted to an alternative platform: � Can the “Identification” step be decoupled from the ATM and shifted to an alternative

platform? Yes it can. The account number that the bank card stores could be stored on the mobile device as well and instead of inserting the bank card into the ATM and the ATM reading the account number from the magnetic strip of the bank card, the account number could be transferred to the ATM over NFC.

� Can the “Authentication” step be decoupled from the ATM and shifted to an alternative platform? Yes it can. First of all, the entering of the PIN could be done remotely on the mobile device as well, like some of the solutions presented in chapter 3. But this approach brings a lot of problems with it. We would have to figure out how to make entering numbers on a touch screen accessible for users with different disabilities, how the mobile device would communicate with the ATM, etc. A better approach to the problem is not to think of authentication being only possible by entering a PIN or password. Proof of possession of the mobile device that is associated with the users account could also apply as authentication. The details of this type of authentication are more complicated and explained in chapter 5 section 2 “Security considerations”. To give you a short preview: A private key is stored on the mobile device securely that is used for challenge-response based authentication over NFC.

� Can the “Input” step be decoupled from the ATM and shifted to an alternative platform? Yes it can. The “Input” step is merely interacting with the ATM UI to “communicate” the details of the operation you want to execute, e.g. “I want to withdraw 30 Euros”. There is nothing special about communicating this kind of information. It is very compact and simple and it could be done on almost any device with any type of UI. Imagine selecting the operation you want to execute and entering the amount of money using a mobile device running a native mobile application or using a PC and a web browser running a web


application. It is easy to see that it does not matter how you enter the information, using the ATMs buttons and keypad or using your smartphone or PC. This still leaves us with the question of how to transfer the result of the input to the ATM, which is explained further in the chapter 5 “Interaction design TokenAccess”.

� Can the “Confirmation” step be decoupled from the ATM and shifted to an alternative platform? Yes and no. Confirmation is not much more than pressing one button on the ATM, so it could be theoretically done on an alternative platform as well. In practice though, the confirmation step is tightly coupled to the transaction of money. This means that you have to confirm the operation you want to execute right before it is executed and that you have to do it at the ATM, because the transaction of money occurs right afterwards. So on the one hand, yes, the confirmation step can be shifted to an alternative platform. On the other hand, no, it cannot be decoupled from the ATM. You have to be physically present at the ATM at the time of the confirmation to receive your money right afterwards.

� Can the “Transaction” step be decoupled from the ATM and shifted to an alternative platform? No, obviously it cannot. As we explained in the previous step “Confirmation”, you have to be physically present at the ATM for the transaction of the money.

Figure 11: Most of the interaction with an ATM could be virtualized on an alternative platform like a PC or a mobile

device.

Figure 12: Some parts of the ATM interaction cannot be decoupled and the user is forced to be physically present at

the ATM at the time of the interaction as transaction of money is involved.


Figure 13: The identification, authentication and input steps can be shifted to an alternative platform entirely, but their

results have to be transferred to the ATM at the time of the interaction. The confirmation step can be shifted to another platform, but the user has to be physically present at the ATM at the time of the confirmation. The transaction step

happens entirely at the ATM. To summarize our analysis of the ATM interaction model: � The identification, authentication and input steps can definitely be decoupled from the ATM

and shifted to another platform. The remaining question is how to remodel the interaction for these steps on an alternative platform so that the interaction is more accessible and easier to use than the standard ATM interaction.

� The confirmation step can be done on another platform as well. But it has to be ensured that the user is directly at the ATM when the confirmation step is executed, as the confirmation step is immediately followed by the transaction of money. This implies that the user has to either interact with the alternative platform in very near proximity of the ATM, or there has to be some sort of direct physical contact with the ATM to ensure the spatial and temporal closeness to the ATM and to the transaction of money.

Alternative platform ATM


5. Interaction Design TokenAccess

In this chapter, we explain how the TokenAccess interaction model works in detail, how parts of the remodeled ATM interaction are realized on alternative platforms and how the final interaction at the ATM is executed. TokenAccess decouples the interaction as much as possible from the ATM interface and shifts it to an alternative platform with better accessibility support, namely the web. Parts of the interaction that cannot be decoupled from the ATM are to be solved with the help of a mobile device and a very simple workflow. The complete workflow consists of two distinct parts: � The first part of the interaction takes place in the personal accessible environment of the

user, see Fig. 13. In this part, the user prepares the interaction with the ATM in his personal accessible environment using the TokenAccess web application. The result is then encoded as a digital “token” and sent to the user’s mobile device. This is the decoupling of the “Input” step from the ATM.

� The second part of the interaction takes place at the ATM, see Fig. 14. In this part, the user executes the prepared interaction with what we call the “two-tap workflow”. Firstly, the user touches the NFC reader of the ATM with his mobile device for “Identification” and at the same time “Authentication”. With a second touch of the NFC reader, the user executes the “Confirmation” step and the token stored on the mobile device is transferred to the ATM. The ATM then executes the prepared interaction stored in the token, completing the interaction.

Figure 14: Step 1: Preparing the interaction in the personal accessible environment.

Figure 15: Step 2: Executing the prepared interaction at the ATM using the two-tap workflow of TokenAccess.

Input

(Prepare ATM interaction)

Personal accessible environment TokenAccess server

Create token

Mobile device

Accessible interaction

No

interaction

required

First tap: Identification &

Authentication

Second tap: Confirmation

(Transfer token)

Transaction of money

Mobile device ATM

Process

token

(Execute

the

prepared

interaction)


Classical ATM interaction TokenAccess

Identification The bank account number is stored on the magnetic strip on the bank card and transferred to the ATM when the card is inserted into the ATM.

The bank account number is stored on the mobile device and is transferred to the ATM with the first tap via NFC.

Authentication The user enters his PIN using the keypad of the ATM.

Digital certificates and challenge-response based authentication.

Input The input is done using the ATM interface, e.g. the menus shown on the screen, the hardware buttons to the left and right of the screen, the keypad etc.

The same input is realized using web forms in the TokenAccess web application that is accessible by the user in his personal accessible environment.

Confirmation Using the ATM interface, similar to the input step.

By touching the NFC reader of the ATM a second time, the user confirms executing the prepared interaction (the token) on the mobile device.

Transaction The ATM executes the operation (e.g. dispense money).

The ATM executes the operation (e.g. dispense cash).

Table 1: Comparison of the standard ATM and the TokenAccess interaction models. The name TokenAccess was chosen because the interaction in the user’s personal accessible environment is encoded in a digital token that is stored on the user’s mobile device. We can assume that users carry their mobile device, e.g. smartphone with them all the time, thus also the token. The token grants users access to the services of any compatible ATM, without being limited by the interface of the ATM, hence the name “TokenAccess”.

5.1. User centered design

The approach we have taken with developing the interaction model of TokenAccess was to put the user and his existing working environment into the center and figure out things from there, instead of starting with the ATM in the center and trying to figure out how to modify the ATM interface in order to make it more accessible and usable. Users of all types, including users with disabilities, already have their preferred working environments tailored to their needs and preferences, for example the operating system of choice, applications, accessibility tools and peripherals. Users also usually have a preferred setting where they are comfortable with getting work done. This can be in one’s private room at home, it can be in the office at work, or it can also be on a bench sitting in a park, if the user feels comfortable and privacy is given. The core idea of the TokenAccess interaction model is to let the user execute as much of the interaction as possible in such a working environment, which we call the “personal accessible environment”, instead of performing the interaction at the ATM.


Some concrete examples for a personal accessible environment would be a PC with additional accessibility tools like a refreshable braille display and/or a screen reader software [24] [25], or a mobile device platform with good accessibility support [52] [53]. The PC provides an especially good basis for a personal accessible environment as it can be extended and adapted to the user’s needs. A blind user might use a PC with a refreshable braille display and a screen reader software while a user with severe motor disability might use a mouth operated mouse [26]. Whereas a user with low-vision can make use of the built-in accessibility features of the operating system (OS) for zooming and contrast. The user should already be familiar with these tools, ideally he should already be doing his other day-to-day work on this computer system. The user’s familiarity with the tools in his personal accessible environment assures that there is no learning curve compared to having to learn the accessibility tools of ATMs.

Figure 16: A blind user in his personal accessible environment [54].

As we said before, the personal accessible environment is not just about the accessibility hardware and software, but also about the setting in which these tools are available to the user. This setting should fulfill these two important criteria: � In his personal accessible environment, the user should be in a familiar and both physically

as well as psychologically comfortable surroundings. At home, in one’s private surroundings or at work in the office are considered suitable settings. The ATM and its direct surroundings are not considered a suitable setting. A blind user might have difficulties locating the headphone jack on the ATM. There might be people waiting in line. All these things might cause stress for the user which would not be a concern at home or at the office with plenty of time available to complete the desired operation.

� The personal accessible environment should be in a setting that offers good privacy. For users with disabilities, the lack of privacy at an ATM is a big problem because it takes them a lot longer to complete an ATM operation compared to users without disabilities. When an operation takes longer to complete, users with disabilities are not only put under time pressure, but at the same time it gets easier for attackers to peek at the PIN the user enters or at the account information shown on the ATM screen. When preparing the interaction in his personal accessible environment, the user will also be entering sensitive information like


the username and the password and the amount of money to withdraw. This is why privacy is also a very important criteria for the personal accessible environment. Again, at home or in the office are good settings for privacy, but the setting can also be a coffee shop if the user can have enough privacy there.

Figure 17: A quadriplegic user in his personal accessible environment [55].

Figure 18: A mobile device can function as the personal accessible environment as well if the accessibility tools of the

platform satisfy the user’s needs [56].


Figure 19: Mobile devices can also be extended to fulfill the user’s accessibility needs, although the possibilities are

more limited compared to PCs. What you see here is a mobile device on the lap of the user and a Bluetooth refreshable display connected to it [56].

The accessibility tools alone are not enough to make the interaction accessible and easy to use, the specific software used to accomplish a task must also be designed and developed with accessibility guidelines of the platform in mind. Nowadays, accessibility guidelines exist for all major PC and mobile operating systems and APIs, see [17], [18], [19], [20], [57], [58]. This is one of the main advantages of developing accessible solutions for the PC or mobile platforms compared to ATMs. When an application is developed in compliance with the accessibility guidelines of the platform, it should be usable with any type of specific accessibility setup of the user. There is still a problem though. Native applications have to be developed separately for each platform, e.g. one application for Windows, one application for Android, one application for iOS, etc. For each application, the developer has to implement the accessibility guidelines of the specific platform. This would be an enormous development task. We circumvent this problem by making use of the web as the development platform. The web has some of the most detailed and robust accessibility guidelines in the form of WCAG [12]. In several countries for example, government agency websites are required to be WCAG compatible and WCAG is mentioned in disability discrimination legislations [59]. By developing the interface for preparing the ATM interaction as a web application with special regard to WCAG 2.0 compatibility, we aim to ensure that the application will be accessible on any platform and with any kind of accessibility setup the user might have. There is not much difference between entering the information required for an operation like withdrawing money using the ATM interface and using a web form: The user chooses which operation he wants to execute, enters the amount of money to withdraw and confirms the operation at the end. The difference is that with the web application, we can count on the interaction being accessible as long as we make sure to follow the WCAG guidelines. On the software side, what we have essentially done is taking the complex problem of “making the ATM UI accessible” and transformed it into the simpler problem of “making web pages accessible”. On the hardware side, it is the same: We have transformed the problem of “making ATM hardware accessible” into “making PCs and mobile devices accessible” which we do not have to solve because it is already solved by manufacturers of various accessibility tools and mobile devices. We also profit from the fact that users are already familiar with the accessibility tools they use every day to browse web pages. Every user who has navigated through a web page


once and filled in a web form could prepare ATM interactions with the TokenAccess web application. The result of preparing the ATM interaction with the TokenAccess web application is a digital token, which is generated on the TokenAccess server and transferred to the mobile device of the user over the internet. This token contains the data the user has entered using the web application and some additional data like a digital signature. We leave details like the exact format of the token as well as how the token gets transferred to the mobile device over the internet vague on purpose, as these are implementation details and could be done in different ways.

Figure 20: Abstract representation of a token that is stored on the mobile device.

5.2. Executing the prepared interaction at the ATM

Once the prepared interaction is transferred to the mobile device of the user, it is ready to be executed at any TokenAccess compatible ATM. We define a “TokenAccess compatible ATM” as one that has an NFC reader and always-on internet connection and whose software is updated in order to be able to process TokenAccess tokens. As we have mentioned before, the requirements for the interaction with the ATM are: � It should be possible to execute the interaction with the ATM using only the mobile device of

the user and without having to interact with the ATM UI itself.

� The steps of the interaction should be very easy to understand and remember.

� No step of the interaction should require fine motor skill to execute.

� The whole interaction from start to finish should take very little time to complete.

Working with these requirements, we developed a very simple workflow for executing the prepared interaction at the ATM, which we call the “two-tap workflow”. The two-tap workflow consists of touching the NFC reader component of the ATM with the mobile device twice, hence the name “two-tap”. The interaction with the ATM via the mobile device is made solely of physically touching the ATM’s NFC reader with the mobile device. The two-tap workflow is loosely based on the existing “touch to pay” workflows of mobile contactless payment systems like Apple Pay [60] or Android Pay [61]. Both of these systems have their dedicated apps, but both can be used without starting the app and interacting with it, at least for simple operations: “With Android Pay, you can keep doing what you’re doing on your phone. Just make sure it’s unlocked and hold it to the terminal — you don’t even need to open the app.” [61]. Not having to interact with the UI of a mobile application and reducing the interaction to the physical act of bringing the mobile device in close proximity of the terminal is a huge advantage.

Token UUID: 7f70e0b3-9942-4f8e-8201-10163bbd33f7 Token type: ATM Operation type: “withdraw money” Amount: 10 Valid for: 1 Signature: E/EuK34KGHKoHOF4lwFKVr8oKAfdg7YtARj/uigGj8IBj7HpxaY//Iz35...


The purpose of the first touch with the ATM is

� …to activate TokenAccess on the mobile device and on the ATM.

� …to give the user a chance to cancel the interaction if he does not want to continue. If the user does not touch the NFC reader of the ATM for a second time in a pre-defined amount of time, the transaction is cancelled. The first touch with the ATM has no consequences, as the token is transferred with the second touch only.

� …to give the user feedback that a TokenAccess compatible ATM has been recognized. It might be hard for the target group of TokenAccess users to tell whether or not an ATM is TokenAccess compatible. When the user touches a TokenAccess compatible ATM with his mobile device, the user receives vibration and audio feedback from his mobile device and also visual feedback from the ATM screen.

� …to let the user know about the details of the prepared interaction that would be executed to if he touches the ATM a second time with his mobile device.

� …for identification and authentication. The mobile device sends the user’s TokenAccess account number to the ATM for identification. Also, both the mobile device and the ATM authenticate each other using a challenge-response based mutual authentication scheme.

The purpose of the second touch with the ATM is

� …for confirmation. The user confirms executing the stored interaction on the token.

� …to transfer the token to the ATM.

Let us take the example of the most common ATM operation, namely withdrawing money, and explain how the two-tap workflow works for the specific operation “withdraw 10 Euros”.


Figure 21: Mobile device touches the ATM for the first time.

The activity diagram above shows what happens during the first touch between the mobile device and the ATM. All communication is over NFC only. The authentication step of the ATM interaction occur here, but this time decoupled from the ATM interface. Notice how the user does not have to enter a PIN for authentication. The authentication relies on the possession factor of the mobile device that is known to the TokenAccess system. You may have noticed that the ATM also authenticates itself to the mobile device. This is an additional security measure of TokenAccess for preventing the mobile device from sending the token to a fake ATM as users with disabilities might have difficulties recognizing fake ATMs. Compare this single step in the TokenAccess interaction with the multiple steps involved in identification and authentication in the traditional ATM interaction: In the traditional ATM interaction, you have to find the slot for the card reader, which is a lot smaller than the NFC reader on the ATM and thus takes more time and requires fine motor skill. After inserting your card, you have to enter your PIN using the keypad of the ATM. You might make mistakes while entering the PIN, etc. By decoupling these steps from the ATM interface and replacing them with one single step that does not require any interaction with the ATM interface, the new interaction model becomes more accessible and easier to use because of its sheer simplicity.


When no errors occur and TokenAccess mode is activated on the ATM successfully, the user receives haptic and audio feedback. In our example, the mobile device would vibrate and the audio feedback would be that the speech synthesis software on the mobile device reads out the text: “TokenAccess recognized. Touch the ATM again to withdraw 10 Euros”. The information “TokenAccess recognized” tells the user that everything went ok and that the ATM he has touched is a legitimate, TokenAccess compatible ATM. The information “Touch the ATM again to withdraw 10 Euros” informs him about the details of the token stored on the device. Once the user has received this information, he can choose to touch the ATM a second time to complete the interaction, or he can simply do nothing and leave and the transaction will be automatically cancelled.

Figure 22: Mobile device touches the ATM for the second time.

When the user touches the NFC reader of the ATM with his mobile device for the second time (see Fig. 22), the token stored on the device is sent to the ATM over NFC. The user again gets audio and haptic feedback. The ATM verifies the token and if the token is valid, the ATM executes the prepared interaction stored in the token. In our case, the prepared interaction in the token was “withdraw 10 Euros”, so the ATM gives out 10 euros. Now we want to go back to the requirements we have defined for decoupling the interaction from the ATM interface and explain how the two-tap workflow fulfills these requirements: � The interaction with the ATM should be executed using only the personal mobile

device of the user With the two-tap workflow, the user never interacts with the ATM interface. Also, no additional devices or accessibility tools other than the mobile device are required for the interaction.


� The steps of the interaction should be very easy to understand and remember The two-tap workflow is very easy to explain and understand: Touch the ATM once to hear what will happen. If you want to continue, touch the ATM again. If not, simply walk away. The workflow does not require the user to remember several complex steps. Also, because the steps are identical, the user does not have to remember the order of the steps.

� No step of the interaction should require fine motor skills to execute The exact positioning and orientation of the mobile device relative to the NFC reader of the ATM does not matter for establishing an NFC connection. This makes it possible to execute the two-step workflow without fine motor skills.

� The whole interaction should take very little time to complete As the workflow consists of merely two touches of the mobile device with the NFC reader of the ATM, it is very fast to execute. It also helps that there are no menus to read, no buttons to find, etc.

5.3. Further examples of the TokenAccess interaction model

We have explained the complete workflow of the TokenAccess interaction model with the example of the “withdraw money” operation of the ATM in the previous sections. In this section, we want to give two more examples so that you can understand better how the TokenAccess interaction model could be applied to different workflows. The first example will be another ATM operation: “deposit money”. The second example will be an operation at a ticketing machine. With this example, we want to show that the TokenAccess interaction model is not limited to ATMs only and the same methods of decoupling the interaction and the two-tap workflow can be applied to other self-service terminals as well.

5.3.1. Depositing money at an ATM with TokenAccess

The interaction is again prepared at home in the personal accessible environment of the user using the TokenAccess web application. There is virtually no difference to preparing the “withdraw money” operation, except that the user does not need to enter the amount of money. The prepared interaction is encoded in the token and sent to the user’s mobile device.


Figure 23: The “deposit money” operation – the mobile device touches the ATM for the first time.

As you can see, the two-tap workflow stays the same from the user’s perspective. When the user touches the NFC reader on the ATM for the first time, the mobile device sends the account number and the operation type to the ATM. The ATM needs to know the operation type before the token is transferred to the ATM with the second touch, in case the ATM needs to do additional things before the second step (confirmation). In the example of the “deposit money” operation, the ATM needs to open the money deposit slot. Finally, just like with the “withdraw money” operation, the user gets haptic and audio feedback that informs him about the next step: “To deposit money, insert the banknotes into the designated slot on the machine and then touch the ATM again.”


Figure 24: The “deposit money” operation - mobile device touches the ATM for the second time.

In the second step, the user has to put the banknotes he wants to deposit into the designated slot of the ATM – as he has been informed with the first touch – and touch the NFC reader of the ATM a second time with his mobile device to complete the transaction. Unlike with the “withdraw money” operation, the token that is being sent to the ATM does not include much information this time, but it is still needed for verification purposes. If the token can be verified, the ATM closes the deposit slot and counts the banknotes and deposits the correct amount on the user’s bank account. Finally the ATM prints out a receipt.

5.3.2. Buying tram tickets at a ticketing machine with TokenAccess

The second example we want to have a look at is a ticketing machine for tram tickets. This example should show how the TokenAccess interaction model could be applied to another self-service terminal than the ATM. The example is based on the ticketing machines for the local tram in the city of Linz, Austria. The main functionality of the ticketing machine is to buy tram and bus tickets directly at the tram or bus stops. There are three main ticket types, a ticket for a short distance called “Mini”, a ticket for a longer distance called “Midi” and a 24-hour ticket called “Maxi”. To illustrate how the


TokenAccess interaction model would be applied to this machine, we will limit the functionality of the machine to one operation: “buy tram ticket”. The ticketing machines are equipped with touch screens for input. The interaction is normally started by touching the screen, the user then selects the ticket and the amount of tickets he wants to buy. He is then informed about the total amount of the tickets and asked to pay for them. The user can pay by using the POS terminal integrated into the machine or he can pay by inserting bills and coins into the machine. Once the payment is done, the machine prints out the ticket for the user. Here is how the TokenAccess interaction model would be applied to this machine: � The input step of selecting the ticket type and entering the amount of tickets you want to buy

is prepared at home using the TokenAccess web application. This works analogue to how the ATM operations like “withdraw money” and “deposit money” are prepared.

� The user activates TokenAccess on the ticketing machine with the first touch of the NFC reader with his mobile device and gets informed via his mobile device of how many tickets he is about to buy and how much it would cost.

� The user can confirm buying the tickets by touching the machine a second time. He is informed to pay for the ticket.

� After the user pays for the ticket, the ticket is printed out.

Note the differences to the ATM interaction: � The identification and authentication steps are missing. The ticketing machine can be used

by anyone without the need to identify and authenticate himself.

� The confirmation step is not the final step of the interaction. This time, the user still has to pay for the ticket to finalize the interaction. This step is not part of the TokenAccess interaction and stays unchanged.


Figure 25: Buying a tram ticket with TokenAccess: First touch.

Figure 26: Buying a tram ticket with TokenAccess: Second touch.

The missing security measures like identification and authentication, as well as the verification of the token and authentication of the ticketing machine itself could of course be implemented for the ticketing machine as well. The point here is to demonstrate that the TokenAccess interaction model could be applied to any self-service terminal when the interaction with this terminal can be modeled using a subset of the steps we have defined for the ATM interaction.


6. TokenAccess Architecture and Security

In this chapter we will give you an overview of the TokenAccess architecture so that you can understand better how TokenAccess can be implemented in a real world scenario and we will also explain the security considerations of the system.

6.1. Architectural overview

TokenAccess has five main components: � The TokenAccess web interface in the personal accessible environment of the user.

� The mobile device of the user.

� The TokenAccess server.

� A cloud messaging service.

� The TokenAccess compatible ATM.

Figure 27: The components of the TokenAccess architecture and the communication channels between them.

6.1.1. The TokenAccess web interface

The personal accessible environment of the user is a personal computer system adapted to the accessibility needs of the user. A PC with a refreshable braille display and screen reader would be an example. The user accesses the TokenAccess web application from his personal accessible environment and prepares there the interaction that is to be later executed at the ATM. The TokenAccess web interface is designed and implemented in accordance with the WCAG 2.0 guidelines. This should ensure the accessibility of the web interface regardless of the accessibility setup of the user.


6.1.2. The mobile device of the user

The mobile device of the user can be any NFC capable device running a modern mobile OS that offers API access to the NFC hardware. Currently, this is only possible with the Android operating system [62]. Android is also the only mobile operating system so far that supports emulating passive NFC cards in software, called “Host-based Card Emulation” (HCE). HCE enables developers to emulate smart cards in software based on the NFC-Forum ISO-DEP specification and also to process Application Protocol Data Units (APDUs) as defined in the ISO/IEC 7816-4 specification [63]. Although the Android operating system is currently the only candidate for a real-world implementation of TokenAccess, the architectural and security details explained in this chapter are kept as general as possible. The TokenAccess client application installed on the user’s mobile device makes use of HCE to communicate with the ATM over NFC using mostly proprietary APDU commands defined according to ISO 7816-4. The token is also transferred to the ATM this way. The TokenAccess client application is also responsible for receiving commands from the TokenAccess server and processing them, for example when a new token is available or a token on the device should be deleted. These commands are sent over a cloud messaging service to enable the TokenAccess client application to run in the background without the user needing to manually synchronize the app. The TokenAccess client application is also responsible for storing the tokens securely on the device. This is achieved by encrypting token data. The challenge with storing encrypted data on mobile devices is not the encryption itself, but storing the keys that encrypt the data.

6.1.3. The TokenAccess server

The TokenAccess server is the application server component that fulfills many responsibilities like:

� Managing the mobile devices connected to the TokenAccess system.

� Serving the web interface

� Creating and deploying new tokens over Google Cloud messaging

� Encrypting and signing the tokens before the transfer

� Provide an interface for the ATM to: Verify a token’s identity online, delete or modify a token, etc.

Please note that in a real world scenario, the server’s many roles would be split over many logical and hardware server components. The cryptographic keys for example would never be stored on the same server as the web application itself. Also, the application server serving the web application and the “actual TokenAccess server” would also most likely be two physically separate server. To simplify things and abstract from these implementation details that are outside the boundaries of this thesis, we assume that the abstract “TokenAccess server” component fulfills all of these roles on one server.


6.1.4. A cloud messaging service

Although not strictly necessary, TokenAccess heavily relies on the use of a cloud messaging service for the communication between the TokenAccess server and the TokenAccess client application running on the mobile device. The main advantage of using a cloud messaging service is that tokens created with the TokenAccess web application are pushed to the device over the cloud messaging service. This way, the user does not need to synchronize his mobile device, and he can be sure that the tokens he creates are transferred automatically and very fast to his mobile device.

6.1.5. The ATM

The ATM in TokenAccess has to have internet connection and an NFC reader. The ATM software would also need an update to be able to process tokens and to communicate with the TokenAccess server. We call such an ATM a “TokenAccess compatible” ATM.

6.1.6. The payment host

The payment host is strictly speaking not part of the TokenAccess system and mentioned here only to give a complete overview of the whole system. The ATM communicates with the payment host for operations like verifying that the user has sufficient funds in his account etc. As TokenAccess only shifts the interaction from the ATM to the web and the mobile device, every other function of the ATM and the ATM infrastructure is left untouched, including the payment host. In other words, regardless of whether the user executes an ATM operation with TokenAccess or he uses the ATM the traditional way, the same communication with the payment host occurs when verifying the transaction details.

6.2. Security considerations

As TokenAccess is primarily designed for ATM interactions that involve financial transactions, security is of high importance. There are three major considerations to make the whole system secure: � Securing the communication channels

� Insuring token authenticity

� Secure storage of the token on the mobile device

We have also identified the following attack scenarios: � Eavesdropping

� Spoofing

� Man-in-the-middle

� Replay attacks

� Relay attacks

� Generating counterfeit tokens


In the next sections, we will first go into detail about the security considerations of TokenAccess and how they might be realized. And then we will show how the attack scenarios can be remedied with these security considerations in place. Fig. 27 shows an overview of how the communication channels in TokenAccess are secured. The communication channels 1 and 2 are typical HTTP connections secured with SSL/TLS and with additional client authentication when needed. Channels 3 and 4 are more interesting, especially securing channel 4, as the communication there is over NFC only. The communication channel between the ATM and the payment host is left out as it is not TokenAccess specific.

Figure 28: Securing the communication channels.

6.2.1. HTTP over SSL/TLS

HTTP over SSL/TLS or shortly HTTPS is a protocol for secure communication over a computer network which is usually the Internet [64]. You most likely already know how HTTPS is used from everyday activities on the internet. When you access your bank’s online banking website or any other website that has to secure the connection between the webserver and the client, HTTPS and digital certificates are used to secure the connection. Because sensitive information like usernames and passwords are transferred between the user’s browser and the TokenAccess server, the connection needs to be secured using HTTPS. HTTPS is widely known and well documented and the inner workings of the HTTPS protocol are beyond the scope of this thesis, so we will not go into any further details. If you want to read more about the inner workings of HTTPS in detail, [65] would be a good source.

6.2.2. HTTPS with client authentication

“HTTPS with client authentication” (also known as “Mutual SSL authentication” or “Certificate based mutual authentication”) is a well-known authentication scheme for providing communication security over the internet using server and client certificates. HTTPS with client


authentication is based on the mutual authentication of both the server and the client using digital certificates and trust anchors. In other words, not only is the server identity verified and the transfer channel between the server and the client secured like it is the case with HTTPS, but the server also verifies the client identity and restricts connections to authorized clients only [66].

Figure 29: HTTPS with client authentication [66].

As we have explained in the section “7.1.3. The TokenAccess server”, the TokenAccess server provides an interface for TokenAccess compatible ATMs for operations like deleting or modifying a token. The ATM uses this interface to for example delete a token when a token is used up after a “withdraw money” operation. Obviously, we would not want a third party to have access to these services, as it would compromise the security of the system heavily. These services of the TokenAccess server are accessed by HTTP requests, meaning that anyone who knows the URL and the required parameters could make the request and access the services without client authentication. An attacker could for example delete all the tokens on a user’s device by accessing the appropriate URL of the TokenAccess server. By securing the communication with HTTPS with client authentication, we make sure that attacks like this cannot happen.

6.2.3. Google Cloud Messaging

TokenAccess uses Google Cloud Messaging (GCM) [67] for sending commands to the client application running on the mobile device, including the “new token” command that carries the actual token in its payload. GCM was chosen as the push notification service because it can be used on both of the major mobile platforms, namely Android and iOS. For other mobile


platforms, another push notification service like Windows Push Notification Services (WNS) [68] might have to be used. Without a push mechanism like GCM, the user would have to manually synchronize the TokenAccess client application on his mobile device each time he creates a token using the web interface, which would be very cumbersome and user-unfriendly. That being said, all push notification services operate similarly and the security considerations we present here, especially the end-to-end encryption would be valid for any push notification service. But there are some general security concerns about using GCM: � An attacker could make a request to GCM impersonating the TokenAccess server and

send unauthorized commands to the client. So the question is: How does GCM guarantee that the messages it sends to the TokenAccess client application really come from the TokenAccess server and not from someone else? The answer is that each server application that wants to communicate with the GCM servers has to have a GCM API key that is associated with a certain project number.

Figure 30: The API key authenticates the server application to GCM.

Also, each client application that wants to receive GCM messages has to enroll itself in GCM providing this same project number. The client application then receives a “GCM registration id” that it shares with the server application. The server application has to send the registration id with every GCM message request to the GCM servers. The request for a GCM registration id includes the project number, so each device is associated with this project and the API key of the server application also. Because the API key plays such an important role in the communication, it has to be treated just like a private key and stored accordingly.

� An attacker could eavesdrop the communication between the TokenAccess server and the GCM servers.

The interface a server application uses to communicate with GCM is HTTP over SSL/TLS, meaning each request is sent encrypted to GCM. This prevents eavesdropping attacks.


Figure 31: Registering the mobile device in GCM.

Figure 32: Sending a GCM push notification from the TokenAccess server to the mobile device.

� As GCM messages are not end-to-end encrypted between the TokenAccess server and the

mobile device, Google has access to the message content, including token information.

To overcome this problem, we introduce end-to-end encryption between the TokenAccess server and the TokenAccess client application running on the mobile device. The TokenAccess server encrypts the message content in the GCM payload before sending the


GCM push notification. The encrypted message is then decrypted in the TokenAccess client application on arrival. That way, sensitive information like token details cannot be read by any third party, including Google who has access to the GCM push notification payloads. To break down how the end-to-end encryption in TokenAccess works:

� When a new device is being enrolled in TokenAccess, the TokenAccess server generates a new AES key for this device solely to be used for end-to-end encryption.

� The key is sent to the device during the enrollment over a secure channel. This can be HTTPS, but other ways are also possible like encoding the enrollment data in a QR code that the user scans. The secure channel we propose is over audio as the workflow is easier for blind users, you can read more about this in the next chapter “Prototype implementation”.

� The key is stored securely on the mobile device using the Android Keystore or the iOS Keychain. On other platforms, similar means of storing cryptographic keys would be used.

� Each time the TokenAccess client application receives a GCM message, the payload is decrypted using this key.

End-to-end encryption prevents any type of eavesdropping attack between the TokenAccess server and the TokenAccess client application.

6.2.4. Secure communication over NFC

With TokenAccess, the communication between the mobile device and the ATM happens solely over NFC. The most sensitive part of the communication between the ATM and the mobile device is the transfer of the token. The token contains all the information required to execute an action on the ATM, meaning the transfer of the token to the ATM needs to be secure. NFC does not offer a secure channel by default, this has to be done on application level. Note that the TokenAccess communication protocol should be considered to be public, e.g. any attacker would have the knowledge of the commands defined in the protocol, in which sequence they have to be sent from the ATM to the mobile device, the response format, etc. With that in mind, we define three requirements for the communication over NFC to be considered secure for our needs:

� Mutual authentication: We want to make sure that the mobile device only communicates

with a legitimate TokenAccess compatible ATM and that the mobile device detects if it receives commands by an unknown – possibly malicious – terminal and vice versa. This is achieved via digital certificates and challenge-response authentication.

� Encryption: Sensitive information exchanged between the mobile device and the ATM should only be readable by the mobile device and the ATM taking part in the transaction. Any third party eavesdropping or intercepting the communication should not be able to learn anything useful. This is achieved by encrypting the critical parts of the communication, most importantly the token that is sent from the mobile device to the ATM.

� Authenticity and integrity: The ATM should be able to verify if the token it receives is indeed an authentic TokenAccess token and that it has not been modified. This is achieved


with digital signatures and explained in the separate section “7.2.5. Authenticity and integrity of the token”.

6.2.4.1. Mutual authentication

The mutual authentication scheme proposed for TokenAccess is based on challenge-response based authentication [69]. In challenge-response authentication, Alice sends Bob a challenge that only Bob knows the answer to. Bob sends the answer back to Alice, who can verify the correctness of the answer, thus verifying the identity of Bob. One possible implementation of challenge-response authentication is using public-key cryptography and digital signatures. To give you an abstract overview of how mutual challenge-response authentication works in TokenAccess: � The ATM sends its public certificate to the mobile device.

� The mobile device verifies the public certificate of the ATM.

� The mobile device responds with a randomly generated string as the challenge

� The ATM signs the challenge with its private key.

� The ATM sends the mobile device the signature of the challenge.

� The mobile device verifies the signature of the challenge using the ATMs public key obtained from the verified ATM certificate. If the verification is successful, this proves the ATM’s identity.

� The same process is repeated in the other direction for authenticating the mobile device to the ATM.

Mutual authentication takes place as the first step in the transaction when the mobile device touches the ATM for the first time. The token is transferred during the second touch of the ATM with the mobile device, so mutual authentication has to take place before that, on the first tap. Strictly speaking, we could forego mutual authentication when we have encryption for the communication channel and ensure the authenticity and integrity of the information being transmitted. The main reason we want mutual authentication is from a usability perspective. We want to give the user feedback as soon as possible when the ATM he is using is a “not trusted ATM”. When the mutual authentication fails on the first tap, the user is notified that this ATM is not trusted and that he should not touch the ATM again. This gives the user a clear signal that he might be at a malicious terminal set up for spoofing attacks. Also, the fact that the mobile device has to authenticate itself to the ATM as well adds an additional layer of security when it comes to verifying the token. Each token is associated with a mobile device registered in the TokenAccess system. TokenAccess compatible ATMs can ask the TokenAccess server to verify a token. The mobile device that just authenticated itself to the ATM and the mobile device associated with the token sent to the terminal has to be the same one, otherwise the transaction is cancelled.


Figure 33: Challenge-response based mutual authentication between the ATM and the mobile device.


6.2.4.2. Encryption

We want to implement encryption for the communication over NFC between the mobile device and the ATM, so that no third party can read the data exchanged between the mobile device and the ATM. Assuming Alice and Bob are the communicating parties and Eve is the attacker, the properties of a secure channel can be formulated in a simplified way as [70]: � Eve does not learn anything about the messages exchanged between Alice and Bob except

their size and timing.

� When Eve attacks the channel by manipulating the data that is being communicated, Bob can find out that the data he has received has been manipulated. In our case, this would mean encrypting and hashing each command that the ATM sends to the mobile device and each response that the mobile device sends back. While this can certainly be done, it is a little overcomplicated for our use case, as the actual “sensitive data” exchanged between the ATM and the mobile device is the token itself. Furthermore, the ATM not only wants to ensure that the token data it receives has not been tampered with during the transit, it also wants to make sure that this token is an authentic TokenAccess token created by the TokenAccess server. This is realized by making the TokenAccess server sign the token with its private key before the token is sent to the mobile device, you will read about the details of this later in this chapter. As the token is signed during all of its lifecycle from being created on the TokenAccess server to being stored on the mobile device to being sent to the ATM over NFC, its integrity is always guaranteed. If the token data were to be tampered with, no matter where and when, the signature of the original token would not match the new (tampered) token data. The attacker also could not create a legitimate signature for the new token data as he does not possess the TokenAccess server’s private key.

To summarize:

� We only need to encrypt the token data itself as the commands themselves exchanged between the ATM and the mobile device do not contain sensitive data.

� The integrity of the token is implicitly given as the token is signed by the TokenAccess server during creation.

The first step is to exchange a new key with every transaction. We continue where the mutual authentication has ended, marked as “Continue with handshake…” on Figure 30. The following steps are happening when the mobile device touches the ATM for the first time. � The ATM generates a new transaction number. Transaction numbers are valid for a fixed

amount of time, we recommend 60 seconds. Our usability tests showed that 60 seconds is well within the timeframe to complete the whole two-tap workflow. When a transaction number expires, so does the transaction key associated with this transaction number.

� The ATM creates a new transaction key for this transaction. The specific algorithm and key size are implementation details, we recommend AES-256 [71].

� The ATM encrypts the transaction key with the public key of the mobile device. Remember that public certificates were exchanged during mutual authentication and both the mobile device and the ATM have each other’s public keys.


� The ATM sends the encrypted transaction key to the mobile device alongside the transaction number.

� The mobile device decrypts the transaction key it has received.

� At this point, the key exchange has completed. Both the ATM and the mobile device have a key they can use for encrypting all further communication. In our case, this key is used only to encrypt the token when sending it to the ATM.

Figure 34: Key exchange between the ATM and the mobile device.


Figure 35: Encryption of the token

6.2.5. Authenticity and integrity of the token

The token is signed when it is created on the TokenAccess server to ensure that its authenticity and integrity can be verified later by the ATM. � When the user creates a new token using the TokenAccess web interface, the TokenAccess

server calculates a digital signature from the raw token data and appends the signature to the token. The signature is consequently a part of the token now for the whole lifecycle of the token.

� When the ATM receives the token from the mobile device, it verifies the token signature.

� If the signature can be verified, it means that this token indeed originates from the TokenAccess server and is not a fake one, and also that the token content was not modified after its creation.


Figure 36: The token is signed when it is created on the TokenAccess server.

Fig. 37 shows how the token is encrypted on the TokenAccess server when it is created. On Fig. 36, you can see how the ATM verifies the token signature as the last step before executing the operation stored in the token. If the token signature can be verified, the ATM executes the operation, otherwise the transaction is aborted. In addition to the digital signature, we propose a second check to verify the authenticity of the token. After the ATM has received the token and verified its signature, the ATM contacts the TokenAccess server and asks it to verify the token as well. There is a reason for the online verification and also a reason for why the online verification is not the sole method of validating the token: � To prevent unauthorized re-use of the same (legitimate) token. An attack scenario could be

cloning the legitimate token on the mobile device and executing the operation in the token (e.g. withdrawing money) multiple times with the same token. To prevent this, when a token is used up at an ATM, the ATM contacts the TokenAccess server and informs it. The TokenAccess server then deletes the token and triggers a GCM push notification asking the mobile device also to remove the token. One way to prevent the token from being deleted from the mobile device would be to turn off the internet connection on the device and then use the token at an ATM. When the user tries to use the same token a second time, the ATM would have no way of knowing that the token is already used once. An online verification of the token prevents this type of misuse as the TokenAccess server always has the up-to-date state of all tokens.

� As mentioned before, TokenAccess is mainly designed for ATMs but it would be implemented for other types of self-service terminals as well, for example for ticketing machines. Most other types of self-service terminals do not have the same security requirements as ATMs. With the ticketing machine for example, there is no identification or authentication required for using any functionality of the machine. Anyone can walk up to the machine and can buy tickets. The user has to pay for the ticket regardless of whether he uses TokenAccess or the interface of the ticketing machine. TokenAccess only decouples


the interaction from the self-service terminal interface, the payment step is still done the traditional way at the self-service terminal. This means that the misuse of a token as described above is not an issue with this type of terminal and the online check would pose unnecessary requirements to the self-service terminal like internet connectivity.

Figure 37: Online verification of the token.

6.2.6. Secure storage of the token on the mobile device

Once the token is created on the TokenAccess server and deployed to the mobile device, it is stored on the mobile device until it is used at an ATM. We want to store the token in a secure manner on the mobile device, so that the token cannot be compromised even if the local storage of the device is compromised. The main idea of how to store the token securely on the mobile device is simple: � The token is encrypted as soon as it arrives on the mobile device via a GCM push

notification.

� An attacker cannot decrypt the token and access the information stored in it, as long as he does not have the key, even if the device is compromised.

� Thus the problem of securely storing the token now becomes the problem of securely storing the key that was used to encrypt the token.

� The key should in no way be treated like ordinary application data and stored unsecured.


� The solution is to use the APIs of the platform for storing cryptographic keys. All major mobile platforms offer an API for storing cryptographic keys securely, for example the Keychain API on iOS [72], the Keystore API on Android [73] and the Data Protection API on Windows Phone 8 [74].

� Alternatively, a third party key store could be used, for example one of the Bouncy Castle library’s key stores [75].

The chosen key store is then used to store the key used to encrypt the token for storage on the device, and the key used to decrypt the GCM payloads that are encrypted on the TokenAccess server and also the private device key that is used for mutual authentication. All cryptographic keys used by the TokenAccess client application should be stored in a key store without exception.

6.2.7. Attack scenarios

In this section, we will have more detailed a look at possible attack scenarios and how these are remedied with our security measures described in the previous section. We will concentrate on the NFC channel between the mobile device and the ATM as this channel is most critical because the transaction at the ATM occurs solely over this channel.

6.2.7.1. Eavesdropping

Eavesdropping is the act of surreptitiously listening to a private conversation, typically between hosts of a network [76]. In the case of TokenAccess, eavesdropping would be a third party listening to the NFC connection between the mobile device and the ATM while the user is interacting with the ATM via TokenAccess. It is widely agreed upon that eavesdropping attacks are possible for an NFC connection [77] [78] [79]. This is not surprising as the NFC communication is wireless using radio waves and any wireless communication can be eavesdropped. The question is now: At what maximum distance between the NFC reader and the eavesdropping equipment can the communication be eavesdropped? In [79] the authors estimate that for a device sending data in active mode the maximum distance at which eavesdropping would still be possible is about 10 meters. For a device sending data in passive mode, e.g. a passive NFC tag, the maximum distance is estimated at about one meter. In other words, the eavesdropping equipment would have to be within a one meter perimeter of the NFC reader. In [78], the authors show how the communication between a reader and passive NFC tags can be eavesdropped successfully up to a distance of 30 centimeters, not by estimation but by really eavesdropping the communication using a passive antenna connected to an oscilloscope. The fact that the maximum distance at which eavesdropping is still possible is that small makes real-world attacks rather implausible. Somebody standing in 30 centimeters distance next to the ATM with an antenna in hand would definitely attract attention. Nevertheless, reading the token information when eavesdropping the NFC connection between the mobile device and the TokenAccess compatible ATM is not possible for an attacker as the token is sent encrypted. The transaction key is also sent encrypted during the key exchange, so the attacker cannot read that, too.


6.2.7.2. Spoofing

A spoofing attack is masquerading as another and therefore gaining an illegitimate advantage [80]. In our case, an attacker might set up a “fake” ATM to lure users to use TokenAccess with this ATM and collect their tokens for later usage. Another possible attack might be to emulate a TokenAccess compatible ATM with a mobile device acting in active reader mode and try to steal tokens from users mobile devices from a close distance, for example in a bus or on the street. Because the main target group of TokenAccess are blind users, this type of attacks might have a higher chance of success. Spoofing attacks are remedied in TokenAccess by using mutual authentication. As the spoofing device cannot possess a valid private key of a legitimate TokenAccess compatible ATM, it can never authenticate itself to the mobile device and the mobile device will not send any tokens to the spoofing device. Should the private key of a TokenAccess compatible ATM be stolen, the spoofing device can of course masquerade itself as a legitimate TokenAccess compatible ATM, but this is a general problem with any system relying on public-key cryptography.

6.2.7.3. Man-in-the-middle

In the classical Man-in-the-middle attack, two parties who want to talk to each other, called Alice and Bob, are tricked into a three party conversation by an attacker Eve [79]. In our case, Alice and Bob would be the mobile device and the ATM, and Eve might be a device that is placed on top of the NFC reader of the ATM that intercepts the communication between the mobile device and the ATM and forwards the intercepted data in both directions. From the perspective of the mobile device or the ATM, the communication would look normal as the data transmitted is not corrupted or modified. The man-in-the-middle attack might be used to intercept a token that has many uses, and to use this token at a later time. The viability of man-in-the-middle attacks to an NFC connection is more controversial than eavesdropping or spoofing attacks. The authors in [79] argue that a man-in-the-middle attack is practically infeasible in a real-word scenario if one of the devices is in active mode and the other in passive mode. Regardless of the discussion whether or not a man-in-the-middle attack is possible in general over NFC, with TokenAccess it would not be possible to get the token transmitted between the mobile device and the ATM with such an attack. Please note that mutual authentication does not remedy man-in-the-middle attacks. The man-in-the-middle can authenticate himself to both parties by simply forwarding the response to the challenge to each party. What remedies a man-in-the-middle attack in TokenAccess is the key-exchange for each transaction and the subsequent encryption of the token with this key. While the man-in-the-middle can intercept the communication, what he will see is the encrypted token, which is encrypted with the current transaction key that is valid for this transaction only, which is about 60 seconds. If the man-in-the-middle tries to use this token at a later time, the ATM will not be able to decrypt the token and execute the operation stored in it.

6.2.7.4. Replay attacks

A replay attack is when a valid data transmission is repeated maliciously after the original transmission occurs [80]. In our case, an attacker might record each command and response in the NFC communication using an eavesdropping or man-in-the-middle attack. At a later time, the attacker might try to use parts of this recorded transaction to represent himself as a legitimate TokenAccess compatible ATM to the mobile device and trick the device to send the token to him. Or the attacker might try to represent himself as a mobile device in the TokenAccess system and try to trick the ATM to accept counterfeits tokens he sends. Both attack scenarios


would fail at the mutual authentication step because both the ATM and the mobile device generate a new random challenge with every transaction. The attacker would have recorded the correct responses to challenges from a previous transaction but these would not be valid for a new transaction later on.

6.2.7.5. Relay attacks

Relay attacks are a special form of man-in-the-middle attack. In a classic man-in-the-middle attack, an attacker intercepts and manipulates communications between two parties. In a classic relay attack, communication with both parties is initiated by the attacker who then merely relays messages between the two parties without manipulating them or even necessarily reading them [81]. Here is how a relay attack might be executed in TokenAccess: � We have two attackers, Attacker-M and Attacker-A. Attacker-M is present at the user’s

mobile device and Attacker-A is present at the ATM.

� Attacker-A has a mobile device that can simulate a legitimate mobile device connected to TokenAccess. As the communication protocol with the ATM cannot be considered a secret, it would not be hard to implement a modified TokenAccess client that can do that.

� Attacker-M has also a mobile device that simulates a legitimate TokenAccess compatible ATM. Again, this is not hard to do if the communication protocol is known, which we must assume as it can be easily reverse engineered.

� Attacker-A touches the ATM with his mobile device and starts a transaction. The ATM starts the handshake processes which includes the mutual authentication and key exchange. For now, just assume we are talking about one single command for simplification. The ATM sends the mobile device of Attacker-A the command, Attacker-A relays this command untouched to the mobile device of Attacker-M, Attacker-M relays the command to the users mobile device by touching it.

� Here lies the problem with the real world feasibility of relay attacks in TokenAccess: Attacker-M and Attacker-A have to time their attack very precisely as each transaction times out after 60 seconds. Attacker-M touching the user’s mobile device with his mobile device without the user noticing is unrealistic. Also, on most mobile platforms, the NFC component on the mobile device is not activated unless the device screen is turned on. This means that Attacker-M has to find an opportunity when the user has turned on his screen – which would most likely implicate that he is currently using his device – and then touch the user’s device within a 60 second timeframe without the user noticing it. As you can imagine, this is very unlikely.

� Once Attacker-M has relayed the command to the user’s mobile device, he receives the response from the user’s mobile device, which he then relays to Attacker-A and Attacker-A relays the response to the ATM. Similar to the man-in-the-middle attack, both the ATM and the mobile device are unaware that a third party (in this case two third parties) are in between.

� All commands are relayed back and forth between the ATM and the mobile device, including the token. The ATM then executes the operation in the token. Assuming the operation is a “withdraw money” operation, Attacker-A, who is directly at the ATM receives the money.


Currently, there are no security measures in TokenAccess that would prevent such an attack. As explained before, we think this type of attack is not really feasible in a real-world scenario given the workflow and edge conditions.

6.2.7.6. Generating counterfeit tokens

As explained before, each token is signed by the TokenAccess server upon creation. Assuming that the private key used for signing is stored securely and never gets into the wrong hands, it is not possible for an attacker to generate counterfeit tokens. As with the communication protocols, the detailed format of the token should not be considered a secret. An attacker might create tokens that are in the exact same format as tokens created by the TokenAccess server, but as he cannot sign these tokens, they are useless. Also, the additional online check ensures that not only a token’s signature is valid, but also that the token is really known to the TokenAccess server. Even if the private key for signing tokens was to be compromised and attackers were to be able to sign tokens, the online verification would still fail as an attacker cannot insert the token he has created into the TokenAccess server’s database.

6.2.7.7. Summary

The table below shows a quick summary of the security measures in TokenAccess we have explained so far and which attack scenarios they remedy.

Eaves-

dropping Spoofing Man-

in-the-middle

Replay attack

Relay attack

Counterfeit tokens

Token extraction

Encryption of the token over NFC

X X X

New key for each

transaction X

Mutual authentication X

Token signature X

Online token verification X

Secure key storage X

Table 1: Security measures in TokenAccess and the attack scenarios they remedy.


7. Prototype Implementation

To demonstrate the workflows of TokenAccess and to evaluate the feasibility of the concept, we have developed a prototype. The TokenAccess prototype consists of the TokenAccess server, the TokenAccess ATM simulation and the TokenAccess client application running on the mobile device. Some security measures explained in Chapter 5 are also implemented as a proof of concept.

7.1. TokenAccess server – Play web application

The prototype of the TokenAccess server was implemented using the Play web framework [82]. Play was the framework of choice because it allows development in Java and makes binding of Java libraries possible, which was needed for the cryptography and audio encoding / decoding. The main responsibilities of the TokenAccess server are: � Managing the mobile devices connected to the TokenAccess system.

� Creating and deploying new tokens over Google Cloud messaging.

� Encrypting and signing the tokens before the transfer.

� Provide an interface for the ATM to: Verify a tokens identify online, delete or modify a token.

In the next sections, we will explain how these responsibilities are implemented in the prototype.

7.1.1. Architecture

Play applications follow the MVC pattern. Models are simple JavaBeans that can be persisted in different database configurations using Hibernate [83]. Views are scripts in the Twirl language [84] that are processed to HTML files on runtime. Controllers are written in plain Java and contain the application logic. Another important component of a Play web application is the “routes” file. In Play, every URL is mapped to a controller method, and this mappings are defined in the routes file. The routes file can be seen as the “interface” between the web application and the clients. The client can be a web browser or an Android application, basically any application that wants to talk to the web application via HTTP. Below is the routes file for the TokenAccess server prototype: # TokenAccess Web Interface GET / controllers.TokenAccess.showMainPage() GET /login controllers.TokenAccess.showLoginForm() POST /authenticate controllers.TokenAccess.authenticate() GET /logout controllers.TokenAccess.logout() GET /connect_device controllers.TokenAccess.showConnectDevicePage() GET /new_token controllers.TokenAccess.showNewTokenForm() POST /new_token controllers.TokenAccess.processNewTokenForm() GET /new_withdraw_money_token controllers.TokenAccess.showWithdrawMoneyForm() POST /new_withdraw_money_token controllers.TokenAccess.processOperationDetailsForm() GET /new_deposit_money_token controllers.TokenAccess.showDepositMoneyForm() POST /new_deposit_money_token controllers.TokenAccess.processOperationDetailsForm() GET /new_tram_ticket_token controllers.TokenAccess.showTramTicketForm() POST /new_tram_ticket_token controllers.TokenAccess.processOperationDetailsForm() POST /new_token_confirmation controllers.TokenAccess.deployToken() GET /new_token_created controllers.TokenAccess.showTokenCreatedPage(operation: String) GET /delete_token controllers.TokenAccess.deleteToken(tokenid: Long)


# Admin Interface GET /admin/show_users controllers.AdminInterface.showUsers() GET /admin/new_user controllers.AdminInterface.showNewUserForm() POST /admin/new_user controllers.AdminInterface.processNewUserForm() GET /admin/delete_user controllers.AdminInterface.deleteUser(userid: Long) POST /admin/generate_keys controllers.AdminInterface.generateKeys() GET /admin/public_key controllers.AdminInterface.showPublicKey() # Client Interface POST /client/configuration controllers.ClientInterface.configureDevice(deviceid: Long,

gcmRegId:String) # ATM Interface POST /atm/delete_token controllers.ATMInterface.deleteToken(UUID: String) POST /atm/update_token controllers.ATMInterface.updateToken(UUID: String,

nrOfUsesLeft: Integer) GET /atm/verify_token controllers.ATMInterface.verifyToken(UUID: String,

signature: String) GET /atm/ta_public_key controllers.ATMInterface.getTokenAccessPublicKey() The server offers an interface for the web application that runs in the user’s web browser (TokenAccess Web Interface), an interface for the client application running on the mobile device (Client Interface), and an interface for the ATM (ATM Interface). The TokenAccess web interface offers methods for connecting mobile devices to the TokenAccess server and for creating new tokens. The client interface is only used for the initial enrollment, which is when the mobile device contacts the TokenAccess server for the first time. After that, all communication is done over Google Cloud Messaging. The ATM interface offers methods for the ATM to delete a token, which is used when a token is used up at an ATM, for updating tokens, which is used to update the number of uses left for a token that is just used at this ATM, and for online verification of tokens. There is also a method for getting the public key that the ATM can use to verify the signature of tokens signed with the TokenAccess server’s private key. Please note that public keys would be distributed with digital certificates in a real world scenario. The ATM getting the public key over an HTTP call is just a shortcut in our prototype. There is also an Admin Interface which is used for creating new user accounts on the server. Again, this is also a shortcut for the prototype, in a real world implementation, users would be creating new accounts themselves and couple their TokenAccess account with their online banking account and verify it with something like a TAN verification scheme. We are omitting these details as the prototype’s main goal is to demonstrate how the ATM interaction could be decoupled from the ATM and prepared with a web interface. The TokenAccess server application classes are distributed over seven packages: � models

� views

� controllers

� crypto

� utils

� acousticmodem

� authenticators


7.1.1.1. Package models

The models package contains classes for managing the data in the application. There are five classes in this package: � Device.java

� Token.java

� User.java

� Login.java

� GcmCommand.java

� Device.java: Represents a mobile device connected to the TokenAccess server. It stores

the GCM registration id of the device and the list of tokens on this device as well as a reference to the user this device belongs to.

� Token.java: Represents a digital token in TokenAccess. The important token fields are the UUID which identifies a token uniquely within TokenAccess, the operation stored on this token, e.g. “withdraw money”, how many number of uses the token has still left and the value of the token, e.g. “50 euros”. The token signature is also a separate field and stored as a Base64 encoded string.

� User.java: Represents a user registered on the TokenAccess server. The user class has the typical fields like username and password and a reference to the device of this user. For the prototype, the relationship between the user and the device is one-to-one. In a real world implementation, it might make sense that a user is allowed to have multiple devices. This would for example be useful for support persons managing devices or multiple elderly users or users with cognitive disabilities.

� GcmCommand.java: Is used for constructing GCM commands that are sent to the client.

� Login.java: Is used to represent the form object in the login form.


Figure 38: Class diagram for the models package.

7.1.1.2. Package views

The views package contains the scripted HTML files called Twirl scripts that are rendered on runtime. There is no logic implemented in the view files, only presentation. In the next sections, you will see screenshots of the web interface and get an idea of how these files look rendered in the web browser.

7.1.1.3. Package controllers

The controllers package is where the main application logic is located. If you look at the routes file, you will see that each URL in the application is mapped to exactly one method in a controller. There are four main controllers in this package: � TokenAccess.java: This is the interface to the web application that runs in the user’s browser.

There are methods for rendering each web page, for example showConnectDevicePage() or showNewTokenForm() etc. There are also methods with more logic in them, for example deployToken(), which processes the new token form, saves the token in the database and transfers the token to the users mobile device via a GCM notification.

� ATMInterface.java: This controller offers the methods for the ATM to TokenAccess server communication. Important methods are deleteToken(String UUID), updateToken(String UUID, int nrOfUsesLeft) and verifyToken(String UUID, String signature).

� ClientInterface.java: This controller contains only one method, configureDevice(Long deviceid, String gcmRegID) which the TokenAccess client on the mobile device uses for the initial enrollment. The method associates a device id for the device that was created on the TokenAccess server beforehand with the GCM registration id that the mobile device has requested from GCM. Once the server has this association, it can send GCM push notifications to devices.


� AdminInterface.java: This controller contains methods for the administrator pages of the web application, for example for adding new users to the TokenAccess server or deleting them. As explained before, this is only for prototyping purposes. In a real world implementation of TokenAccess, users would create their user accounts themselves and associate their accounts with their online banking accounts.

Figure 39: Class diagram for the controllers package.

7.1.1.4. Package crypto

The crypto package contains helper classes for cryptographic operations used by the TokenAccess server. Currently, only signing the token is implemented in the prototype. There are two classes in the crypto package that help with signing the token: � KeyHelper.java: This class contains a helper method called generateKeyPair() for

generating the key-pair that is used for signing and verifying the tokens created by the TokenAccess server. This method needs to be called once after the TokenAccess server is set up. The other two methods in this class are getTokenAccessPublicKey() and getTokenAccessPrivateKey(), which are used to retrieve the public or private key of the key-pair generated. We want to iterate here one more time that this way of handling private and public keys is for prototyping purposes only and absolutely a bad practice from a security point of view. Private keys should be password protected and stored securely, ideally on a separate key management server and public keys should be distributed using digital certificates.

� SignatureHelper.java: This class has two methods ,sign(Token token) and verify(Token token). As the names suggest, the first method is used to sign a token and the second method is used to verify the signature of a token.

7.1.1.5. Package utils

The utils package contains miscellaneous helper classes that do not fit logically into any other package: � FFMPEGMacOSXLocator.java: This class is needed to initialize the ffmpeg library correctly if the

TokenAccess server is running on a Mac OS X machine.

� JsonHelper.java: This class is used for converting a token object into different JSON representations and has two methods. getTokenNode(Token token) converts a token object


into a JSON node object. getTokenJsonWithoutSignature(Token token) strips the signature field from a token object and returns the JSON representation as string. This is helpful when verifying the token signature for example.

� ClientCommunication.java: This class is used to construct the GCM commands that are sent to the mobile device. Currently, three commands are supported: New token, delete token, and unregister device. Each command is represented with its own method: newToken(Token token, boolean informUser), deleteToken(Token token, boolean informUser) and unregisterDevice(Device device, boolean informUser). The informUser parameter tells whether or not the user should get a feedback when the mobile device receives this command. The type of feedback is dependent on the user’s profile, a blind user would get audio and vibration feedback, a deaf user would be shown a sign language avatar etc. Currently, only the audio and vibration feedback for blind users is implemented in the prototype.

7.1.1.6. Package acousticmodem

This package contains MIT licensed code [85] from the Digital Voices project [86] by Jonas Michel. Acoustic modem functionality is used by the TokenAccess server to encode the enrollment message for the mobile device that wants to connect to the TokenAccess server. The enrollment message contains the device id and the TokenAccess server URL that the client application on the mobile device needs to contact the server and register it for the first time, see section 6.1.1.3, ClientInterface.java.

7.1.1.7. Package authenticators

This package contains classes that implement authenticator functionality used by the Play framework to regulate access to each page of the web application. Each authenticator defines a getUsername(Context ctx) method that retrieves the username of the currently logged in user from the browsers session cookie and the onUnauthorized(Context ctx) method that describes what should happen if the authentication fails. Each controller method can then be annotated accordingly to restrict access to parts of the application to certain users only. For example, all methods in the AdminInterface.java controller that are annotated with @Security.Authenticated(AdminAuthenticator.class) are accessible only when an admin user is logged in.

7.1.2. Connecting the mobile device to the TokenAccess server

Each mobile device connected to the TokenAccess server is represented in the Device.java class. The TokenAccess server communicates with the mobile devices using GCM and push notifications. Here is the problem: � To be able to send push notifications to a specific device, the TokenAccess server needs to

know the GCM registration id of that device.

� The GCM registration id is requested by the mobile device from the GCM servers.

� The device now has to tell the TokenAccess server about its GCM registration id, but:

� It needs to know the URL of the resource it can communicate with the TokenAccess server over, e.g. https://www.tokenaccess.com/configure_device. Especially the server

https://www.tokenaccess.com/configure_device


URL could be different for each TokenAccess installment, a bank might have a different URL than the local railway company etc.

� The device needs to tell the server with which device on the server this GCM registration id should be associated with. In other words, the server needs to map the device id in its database with the GCM registration id sent by the device. This means that the server first has to tell the mobile device its TokenAccess device id and then the device requests a GCM registration id and responds back to the server with the TokenAccess device id and the GCM registration id.

� The question is: How does this all happen for the first time when the server and the mobile device know nothing of each other?

The problem exists in every Mobile Device Management (MDM) [87] application where the server needs to communicate with a mobile client. The mobile device needs to be coupled with the server for the first time in a process often called “enrollment”. The user receives the enrollment information, which usually contains an enrollment secret (sometimes called token, not to be confused with tokens created in TokenAccess), the server URL and sometimes additional information like the users email address. The enrollment information is either sent to the user via email or it can also be directly shown in the web application. The user then has to start the client application on the mobile device and enter the enrollment information. Alternatively, the enrollment information is often offered encoded in a QR code, which the user has to scan with the client application. Both approaches are not ideal for the target group of TokenAccess, because: � It is difficult to enter long strings on a mobile device. This is especially true for blind and

visually impaired people, as they can only achieve about one-and-a-half to two words per minute with touch based text entry [88].

� We think that users with cognitive disabilities and the elderly would also have difficulties with entering long strings.

� Scanning a QR code can be problematic because the user needs to be able to hold a camera reasonably steady at a certain distance to scan a QR code [89]. This is not easily doable by users with motor disabilities like tremors or the elderly.


Figure 40: Enrollment email in an MDM application (Sophos Mobile Control) [90] [91]. The user can connect his

mobile device by either scanning the QR code or entering the enrollment information manually. For these reasons, TokenAccess uses a different method of configuring the mobile device for the first time, which we call the “audio-based device configuration”. Below is the workflow of the audio-based device configuration: � The enrollment information is encoded in an audio message that can be played in the web

browser.

� The client application on the mobile device is able to listen and decode this audio message and receive the enrollment information this way.

We believe that the audio-based device configuration is far more suited for the target group of TokenAccess. You can read more in the chapter “9. Usability testing” how users with different types of disabilities fared at connecting a mobile device to the TokenAccess server using the audio-based enrollment method.

Figure 41: Audio-based device configuration: The mobile device receives the configuration information with audio that

is played over the PC speakers.


Figure 42: The device configuration page in the TokenAccess web application. When the user clicks the "Connect device" button, the audio message containing the configuration information like the server URL and the device id is

played in the web browser. The mobile device listens to this audio stream and receives the configuration information this way.

Figure 43: Sequence diagram for audio-based device configuration.

The code for encoding a string in an audio message and decoding it back on the mobile device originates from the Digital Voices project [86]. The technical details of traditional audio modulation for embedding information in audio is beyond the scope of this thesis. The encoding and decoding functions from the Digital Voices project are used in TokenAccess as is, without modification. It is sufficient to know that the configuration message is encoded on the server side in an audio file, which is played in the web browser via the HTML 5 audio tag. The mobile device listens to this audio message via the microphone, decodes the audio stream and extracts the configuration message. Using the server URL and the device id from the configuration message, the mobile device enrolls itself in the TokenAccess server.


7.1.3. Creating tokens and sending them to the mobile device

After a device is connected to the TokenAccess server, the user can create tokens with the TokenAccess web interface. These tokens are sent to the user’s mobile device immediately using the GCM push notification mechanism.

Figure 44: The "dashboard" right after the user's mobile device is connected to TokenAccess.

Figure 45: Currently, three different operations are implemented in the prototype: Withdrawing and depositing money

for the ATM and buying tram tickets for a ticketing machine.

Figure 46: Operation details for a "withdraw money" token. The user can choose the amount to withdraw and how

many times this token can be used. In this case, the token expires after one single use.


Figure 47: A confirmation screen is shown with the details of the token. Once the user clicks the “Create token” button,

the token is created and sent to his device.

Figure 48: The “dashboard” after creating the token for withdrawing money.

Figure 49: The user can have multiple tokens on his device, but he can only have one token for each self-service

terminal type on the device. This is required so that the user does not need to choose the token on the device manually at the self-service terminal. Here, you can see that the user has stored both an ATM token for withdrawing

money and a ticketing machine token on his device.


Figure 50: Sequence diagram for creating a new token on the TokenAccess serve


7.1.4. WCAG 2.0 compatibility

The web interface of the TokenAccess prototype was designed to be accessible by any user group, including those with disabilities. The WCGA 2.0 guidelines [92] were taken as reference to ensure good accessibility. Here are some examples from the WCAG 2.0 guidelines that we have applied to the TokenAccess web interface to ensure good accessibility of the web interface: � Text alternative for non-text context (Guideline 1.1.1): On the TokenAccess web interface,

the only non-text content is the TokenAccess logo which has an alternative text.

� Contrast (Guideline 1.4.3 and 1.4.6): The main content on the TokenAccess web interface is black on white, offering maximum contrast.

� Keyboard Accessible (Guideline 2.1): All functionality can be accessed using a keyboard only. Tab indexes are defined for forms.

� Labels (Guideline 3.3.2): Labels are provided for forms.

Each page of the web interface was reviewed for WCAG 2.0 Level AAA compatibility using the web accessibility checker tool AChecker [93]. None of the pages of the web interface include any known or likely problems according to AChecker.

7.2. TokenAccess client – Android application

The second part of the prototype is the client application running on the mobile device. The client application (called the TokenAccess client from now on) has the following responsibilities: � Processing GCM messages that are received from the TokenAccess server.

� Storing tokens securely on the device.

� Emulating a smart card when in touch with the NFC reader of a TokenAccess compatible ATM.

The TokenAccess client application has no graphical UI like other Android applications, only the TokenAccess logo is shown on the main screen. The user interacts with the app by tapping and double tapping anywhere on the screen. The feedback is via sound output only. There is also an action overflow menu with debugging operations. This menu is not meant for the user and is only for debugging purposes. The user does not need to interact with the app strictly speaking. The app runs in the background and reacts to GCM commands from the TokenAccess server and NFC communication when in contact with a TokenAccess compatible ATM. The UI of the mobile device only comes into play only if the user wants to know which tokens he has stored on his device. Otherwise, after the first touch of the ATM with his mobile device, the user hears the details of the token that is supported by this ATM (or self-service terminal). This way, the user can still use TokenAccess without ever starting the client app if he does not want to. This is possible because of only one token of each self-service terminal type is permitted on the device at one given time.


Figure 51: The TokenAccess client application. There is no classical GUI, instead the user interacts with the client

application via touches and gestures and gets audio feedback. The gestures supported by the TokenAccess client application are: � When the device is not connected to the TokenAccess server yet:

� Tapping the screen once tells the user that his device is not connected to TokenAccess yet.

� Tapping the screen twice starts the enrollment process, the client application starts listening to the audio enrollment message that is expected from the user’s web browser.

� When the device is already connected to the TokenAccess server:

� Tapping the screen once tells the user how many tokens he has left on the device.

� The user can swipe right or left to hear the details of the next or previous token on the device.

Because the interaction at the ATM can be done without needing to interact with the client application on the mobile device, we think that a more complex UI is not needed. You can read in chapter “9. User study” how users from different groups felt about using the UI. The Android OS was chosen as the platform for the prototype, because Android is currently the only mobile platform that has good API access to the NFC reader. Android has introduced a method for emulating smart cards with Android 4.4, called “Host-based Card Emulation” (HCE) [63] which we make use of in the TokenAccess client application. HCE allows developers to process Application Processing Data Units (APDUs) from an NFC reader in their own application that are forwarded from the NFC hardware on the device to the application. Before Android introduced HCE, the only way of emulating a smart card using the mobile device was via a secure element implemented in the hardware. The secure element performed all communication with the NFC reader and no Android application was involved in the transaction. With the newly introduced HCE, the commands from the NFC reader are forwarded to the appropriate Android application running on the device instead of the hardware secure element, see Fig. 53. Our prototype makes use of HCE to emulate a smart card each time the mobile device touches the ATM: On the first touch of the ATM with the mobile device, it is as if the user has touched the ATM with a smart card that has the information stored on it that is required for identification and


authentication, e.g. the account number. On the second touch of the ATM with the mobile device, it is as if the user has touched the ATM with a second smart card that has the digital token stored on it.

Figure 52: On the left: Card emulation via a secure element. On the right: Host-based Card Emulation [63].

7.2.1. Architecture

The TokenAccess client application consists of seven packages: � client

� crypto

� gcm

� nfc

� servercomm

� token

� acousticmodem

7.2.1.1. Package client

The client package houses the classes for general client functionality like showing the UI and saving the client data. There are four classes in this package: � MainActivity.java: This is the main activity in the TokenAccess client and handles the

main UI responsibilities.

� ClientData.java: This class is used for persistent storage of miscellaneous client related information like the current device state, the current transaction state, if a transaction is going on and the TokenAccess server URL.

� ManualEnrollmentActivity.java: This class offers a fallback method for enrollment in case the audio enrollment does not work. The user can enter the TokenAccess server URL and the device id manually and connect the device to the TokenAccess server this way. This method is mainly for debugging. Under normal circumstances, enrollment occurs via audio-based enrollment and manual enrollment is not needed.


� Speaker.java: Because the main feedback in the client application occurs in form of spoken text that is constructed together from different string resources depending on the token type and device state etc., this helper class was needed to offer a unified interface to the text-to-speech engine. Other classes in the client application do not access the Android text-to-speech class directly, instead they call one of the appropriate methods of this Speaker class, e.g. speakConfirmationMessage() after the user touches the ATM for the first time. The Speaker class then constructs the text to be spoken and uses the Android text-to-speech engine to speak aloud the text.

Figure 53: Class diagram for the client package.



This package contains helper classes for cryptographic operations. The two classes in this package are: � SecretKeyWrapper.java: The Android operating system has a component called ”Android

Keystore Provider” [73] that we use in our prototype to securely store an encryption key on the device. Sensitive information like tokens are then encrypted with this key. While the Android Keystore Provider is available since API level 18 (Android 4.3), it supports symmetric-key algorithms like AES [73] since API level 23 (Android 6.0 onwards). To overcome this limitation, one workaround is to “wrap” an AES key using an RSA private-public key pair. The idea is that a new RSA private-public key pair is generated and securely stored using the Android Keystore Provider, and this key pair is used to encrypt and decrypt an AES key that itself is not stored using the Android Keystore Provider, but anywhere on the device.

� TokenEncryption.java: As the name suggests, this class is used to encrypt and decrypt tokens that are stored on the device. It has two methods: encryptToken(Token token) and decryptToken(String encryptedTokenAsBase64). The encrypted token is stored Base64 encoded on the application data folder of the TokenAccess client application.

Figure 54: Class diagram for the package crypto.

7.2.1.3. Package gcm

The gcm package contains classes related to Google Cloud Messaging functionality. The communication between the TokenAccess server and the client application occurs solely over GCM after the initial enrollment. The TokenAccess server sends the client commands wrapped in GCM push notifications and the client processes these commands. The classes in this package are: � GcmBroadCastReceiver.java: Processes the broadcast event that is received when a new

GCM push notification arrives on the device. The GCM push notification is passed to the class as an Android intent. This class then forwards the intent action to the appropriate IntentService for further processing. The reason for this workflow being like this is that the broadcast receiver processes the push notification very fast and offloads the real work to a background service.


� GcmMessageHandler.java: This class receives the intent that represents the GCM push notification from the GcmBroadCastReceiver and extracts the command from the TokenAccess server from it. Once the command is extracted, the appropriate client action is executed using the ClientActions class.

� GcmCommand.java: Object representation of commands sent from the TokenAccess server for easier handling of the commands. Supported commands are new_token, delete_token, and unregister.

� ClientActions.java: This class implements the client actions mapped to the commands sent from the TokenAccess server, namely for storing a new token on the device, for deleting a token on the device and for disconnecting the device from Google Cloud Messaging and the TokenAccess server.

� GcmUnregisterTask.java: Asynchronous task used for disconnecting the device from Google Cloud Messaging. This operation can take some time and is executed in a background task so the main application thread is not blocked.

Figure 55: Class diagram for the package gcm.

7.2.1.4. Package nfc

The nfc package contains the classes related to the NFC communication between the mobile device and the ATM. The main class is the ApduProcessor class which extends android.nfc.cardemulation.HostApduService. This class is the entry point for the APDU (Application Processing Data Unit) commands received from the ATM. The Android OS redirects APDU commands coming from a card reader intended for a certain application to this classes main method processCommandApdu(byte[] command, Bundle extras). The Android OS knows which application an APDU command is intended for via the AID (application id) according to the IS0-7816 specification. Some AIDs are reserved for industry standard applications, vendor specific AIDs always start with an F. The TokenAccess AID is “F333333333”. The AID has to be defined in an XML file called aid_list.xml in the application folder “res” (resources).


Figure 56: The AID (application id) has to be defined in an own file called ais_list.xml in the folder “res”. It is through this AID that the Android OS knows which application to forward the commands from the NFC reader to.

The nfc package consists of four classes: � NfcConstants.java: This class contains the constants required in the NFC communication,

namely the instructions sent from the ATM to the mobile device and the response sent back from the mobile device to the ATM. Both the mobile device and the ATM need to use the same constants for a successful communication.

� ApduProcessor.java: The main entry point for APDU commands received from the ATM. The mobile device side of the communication protocol is implemented in this class.

� CommandParser.java: A helper class for parsing the APDU commands received from the ATM.

� ByteArrayOperations.java: The APDU commands received from the ATM are byte arrays. This class offers helper methods for handling byte arrays. The two most important methods are equals(byte[] array1, byte[] array2) and byteArrayToHexString(byte[] bytes). The first method is used when comparing part of an APDU like the instruction with an NFC constant and the second method is used for printing out the APDU commands in a more human readable form for debugging purposes.

Figure 56: Class diagram for the package nfc.

7.2.1.5. Package servercomm

The servercomm package contains classes used by the client application to communicate with the TokenAccess server. As a reminder: The TokenAccess server communicates with the client application via GCM push notifications only. The mobile device needs to communicate with the TokenAccess server only for the initial enrollment and for the un-enrollment in case the user wants to disconnect his device from the TokenAccess system. As such, this package contains four classes related to enrollment and un-enrollment:


� EnrollmentTask.java: Asynchronous task used to connect to the TokenAccess server and transfer the GCM registration id for the enrollment.

� UnerollmentTask.java: Asynchronous task to deregister the device from GCM.

� EnrollmentListener.java: Listener interface for being notified when the enrollment is successful or fails.

� UnenrollmentListener.java: Listener interface for being notified when the enrollment is successful or fails.

Figure 57: Class diagram for the package servercomm.

7.2.1.6. Package token

This package contains the classes responsible for storing tokens on the device. The tokens are stored encrypted and as Base64 encoded strings in a preferences file of the client application. There are two classes in this package: � Token.java: The object representation of a token.

� TokenStorage.java: Helper class for saving and retrieving tokens.

Figure 58: Class diagram for the package token. The TokenStorage class depends on the TokenEncrpytion class

for encrypting the tokens before storing them. The ClientActions class depends on the TokenStorage class for adding and removing tokens from the device when it receives the corresponding command from the TokenAccess

server.


7.2.1.7. Package acousticmodem

This package contains code from the Digital Voices project [85] that is used for decoding the audio enrollment message received from the TokenAccess server during the enrollment. We are using the SessionService class to start a listening service in the background to decode the enrollment message.

7.2.2. Decoding the audio enrollment message

This section explains the second part of the enrollment process, namely the mobile device decoding the audio enrollment message and enrolling itself on the TokenAccess server. The audio enrollment message contains the following information: � The full URL of the enrollment resource on the TokenAccess server.

� The device id the TokenAccess server has generated1.

1 In a real world implementation, not the device id, but a more complex „enrollment secret“ associated with this device would be used to prevent malicious devices guessing the device id and enrolling themselves as a legitimate device.


Figure 59: Sequence diagram of the client application decoding the enrollment message from the web browser.


During the enrollment, the following happens: � A SessionService from the acoustic modem library is created that starts listening for the

audio enrollment message in the background.

� Another asynchronous task is started that checks every second if the enrollment message has been decoded successfully.

� Once the enrollment message has been decoded successfully, the enrollment URL and the device id are extracted from the message.

� An asynchronous enrollment task is started in the background. The enrollment task does the following:

� It contacts the Google Cloud Messaging service and registers the TokenAccess client application instance running on the mobile device. Once the registration is complete, a GCM registration id is received.

� It contacts the TokenAccess server using the enrollment URL, providing the device id from the enrollment message and the GCM registration id.

� When the enrollment request is successful, the enrollment is considered completed.

� Once the enrollment is completed, the listeners are notified. In our case, it is the MainActivity of the client application that gives the user an audio feedback that the enrollment was successful.

Figure 60: The enrollment task in detail.

7.2.3. Secure storage of tokens

Tokens are stored on the device encrypted to ensure that they are useless if extracted from the device. The main class responsible for storing and retrieving is the TokenStorage class. This class uses the TokenEncryption class to encrypt and decrypt tokens for storage and retrieval. The TokenEncryption class generates a new AES key if there is none present and wraps it using the SecretKeyWrapper for secure storage.


Figure 61: Encrypting and saving a new token.

Figure 62: Retrieving (and decrypting) a token.


7.3. ATM simulation – Android application

Getting hold of a real ATM for development purposes was not possible, because of this the ATM part of the prototype is simulated as an Android application running on a tablet. The idea is to use the NFC hardware on the tablet in reader mode to simulate the NFC reader of the ATM and to use the screen of the tablet to simulate the rest of the ATM workflow, e.g. the user receiving the money. The NFC hardware is usually at the back of the tablet, meaning the user has to touch the back side of the tablet with his mobile device for the interaction. Currently, the prototype can simulate an ATM and a ticketing machine.

Figure 63: ATM simulation running on an Android tablet.


Figure 64: A ticketing machine is also simulated to showcase how the TokenAccess workflow could be applied to other self-service terminal types.


7.3.1. Architecture

The ATM simulation consists of 17 classes distributed over four packages: � atm

� nfc

� crypto

� token

7.3.1.1. Package atm

This package contains the classes used for simulating the UI and the interaction of the ATM and the ticketing machine. The classes in this package are: MainActivity.java: This class is the entry point of the application and the launcher activity. After this activity is launched, it launches either the ATMActivity or the TicketingMachineActivity depending on which self-service terminal is to be simulated. This can be set up in the settings. SstActivity: Abstract base class for simulating different types of self-service terminals. This class initialized the NFC reader component and handles the server communication, classes extending this abstract class implement the UI simulation of the self-service terminal. SSTActionsListener.java: Listener interface for events from the NFC reader that occur during the communication between the mobile device and the ATM. AtmActivity.java: Simulates the ATM UI and transactions like the user receiving money or receiving a receipt. TicketingMachineActivity.java: Simulates the UI of a ticketing machine and the transaction of buying tram tickets. DataStorage.java: Helper class for storing information like the self-service terminal type being simulated, the TokenAccess server URL, or the state of the ongoing transaction. SettingsActivity.java: This class is used to set up the self-service terminal type to simulate and to enter the TokenAccess server URL to connect the simulation to. ServerCommunication.java: Helper class for handling the connection between the ATM and the TokenAccess server. This class offers methods for deleting and modifying a token on the server and also for online verification of the token.


Figure 65: Class diagram for the package atm.

7.3.1.2. Package nfc

This package contains the classes used in the NFC communication between the mobile device and the ATM. NfcConstants.java: This is the same class as in the TokenAccess client application and contains the constants for instructions sent to the mobile device and for response codes received from the mobile device. ByteArrayOperations.java: This is also the same class as in the TokenAccess client application and used for handling APDU commands that are sent to the mobile device as arrays of bytes. NfcCommandBuilder: Helper class for building APDU commands to be sent to the mobile device. APDU commands are byte arrays specified in ISO 7816-4. Constructing APDU commands by hand is difficult and error prone, hence this helper class that abstracts command construction. NfcResponseParser: Helper class for parsing the response from the mobile device. Similar to APDU commands sent to the mobile device, the response from the mobile device is also a byte array that is difficult and error prone to parse each time. This class abstracts response parsing and offers methods for getting the status words and the payload in the response. NfcReader: This is the main class that handles the NFC communication on the ATM simulation side. The application has to declare that it uses the NFC component in the manifest and it needs to declare in an XML file called nfc_tech_filter.xml in the res/xml folder which NFC protocol the NFC reader supports. Android HCE only supports IsoDep, so the ATM simulation application needs to declare that in the nfc_tech_filter.xml file.


Figure 66: The ATM simulation Android application needs to declare in the manifest that it requires the NFC

permission and that it uses the NFC hardware feature.

Figure 67: The ATM simulation Android application also needs to have a file called nfc_tech_fitler.xml in the

res/xml folder that declares IsoDep in the supported tech list. The NFCReader class implements the NfcAdapter.ReaderCallback interface. Classes that implement this interface get notified via the onTagDiscovered(Tag tag) when a new tag is discovered, e.g. when a smart card or a mobile device emulating a smart card touches the NFC reader. In the onTagDiscovered(Tag tag) method, the ATM side of the communication protocol is implemented. You can read about the details of the TokenAccess NFC communication protocol in the next section.


Figure 68: Class diagram for the package nfc.


The crypto package contains helper classes for cryptographic operations. The only cryptographic operation implemented in our ATM simulation prototype is checking the signature of the token that is received from the mobile device and that is signed by the TokenAccess server. There are two classes that help with verifying the token signature: � KeyHelper.java: Tokens created on the TokenAccess server are signed with the

TokenAccess server’s private key. To verify such a token, the ATM needs to have the TokenAccess server’s public key. In a real world implementation, public keys would be distributed using digital certificates. To simplify certificate handling in the prototype, the TokenAccess server offers an interface for the ATM to download the public key. This is done in the settings activity by using the KeyHelper classes writeTokenAccessPublicKeyToFile() method. Once the public key is saved on the device, it can be retrieved using KeyHelper classes writeTokenAccessPublicKeyToFile() method.

� SignatureHelper.java: This is a helper class for verifying signatures. Its is only public method is verifyTokenSignature(Token token) which is used to verify a token’s signature.


Figure 69: Class diagram for the package crypto.

7.3.1.4. Package token

This package contains one class only: The same Token class as in the TokenAccess mobile application that is used for the object representation of a token.

7.3.2. Mobile device to ATM communication

As mentioned before, the communication between the ATM and the mobile device occurs solely over NFC. The mobile device emulates a smart card that the ATM reads from. The communication protocol between a smart card and an NFC reader is well defined in ISO-7816-4 [94]. To summarize: � The communication is half-duplex, meaning the NFC reader sends a command to the smart

card and reads the response from the smart card. The smart card cannot send commands to the NFC reader.

� The commands from the NFC reader to the smart card are called “command APDUs” and the response from the smartcard to the NFC reader is called “response APDU”. APDU stands for “Application Data Processing Unit”. APDUs are byte arrays.

� The command APDUs and response APDUs have a specific format, see Table 3 for details.

� The maximum amount of data payload that can be sent with a command APDU is 65535 bytes.

� Similarly, the response APDU payload has a maximum size of 65536 bytes. More information about the command and response APDU format is provided in [94, pp. 7-12].

Table 2: Detailed format of command and response APDUs [81, p. 7].


The TokenAccess specific APDU commands have the following properties: � The class byte CLA is set to 0x80 for all commands indicating a proprietary class. The only

exception is the command with the SELECT instruction, which is an inter-industry command used in TokenAccess as well. For this command, the CLA is set to 0x00. Although it is not explicitly specified in the Android HCE documentation [63], during our prototype implementation we have identified that the first command sent to the mobile device has to be a SELECT command2 so that the Android OS knows which application this and all subsequent commands should be sent to.

� The second byte is the instruction byte. The instruction is the core of the command and “tells the client what to do”.

� The next two bytes are the command parameters P1 and P2. The first command parameter byte is used in some TokenAccess specific commands (HANDSHAKE and GET TOKEN) to send the self-service terminal type to the mobile client. The mobile device knows based on the self-service terminal type which token to send to the ATM without the need for additional user interaction.

� The next zero to three bytes (Lc) encode the length of the data payload that is sent with the command. In the TokenAccess protocol, Lc is always set to zero except for the SELECT command, as the commands from the ATM to the mobile device do not contain any data. The only information sent from the ATM to the mobile device is the SST type, which is sent with the command parameters as explained in the previous point.

� The next Lc amount of bytes would be the data payload. In our case, there is no data payload.

� The next zero to three bytes (Le) encode the length of the response expected from the mobile device. This is useful for checking if the response received from the smart card has indeed all the data expected or if something got lost during the transmission. In the TokenAccess communication protocol, Le is absent on purpose. The response from the mobile device can include the token and the token size is left undefined to allow for more token types in the future without having to change the NFC communication protocol.

The response sent back from the mobile device has the following properties: � The last two bytes encode the status words. Both status words combined make up the status

message. In our TokenAccess protocol, we define the two status messages as “OK” and “ERROR”.

� The rest of the response is the data payload. The payload contains the token after the second touch of the ATM’s NFC reader with the mobile device.

2 SELECT is actually the instruction (encoded in the second byte) and not the whole command, but as the instruction pretty much defines the command, we simply call a command where the instruction byte is set to SELECT a “SELECT command” for simplicities sake.


The TokenAccess protocol defines five commands in total: � SELECT:

CLA 0x00 INS 0xA4 P1 0x04 P2 0x00 Lc 0x05 Data field 0xF333333333 Le field 0x0000

Table 3: Details of the SELECT command.

The SELECT command is sent to the mobile device so that the Android OS knows which application to forward this NFC communication to. The SELECT command has to be sent as the first command both on the first touch of the ATM with the mobile device as well as on the second touch. The data field contains the application identifier for TokenAccess, which is 0xF333333333. Proprietary AIDs start with F, the rest is arbitrary and the AID can be up to sixteen bytes in length. More details about the exact encoding of AIDs can be found in [94, p. 66]. � HANDSHAKE:

CLA 0x80 INS 0xE1 P1 0x01 or 0x02 P2 0x00 Lc 0x00 Data field - Le field 0x0000

Table 4: Details of the HANDSHAKE command.

The HANDHSHAKE command is sent as the second command when the mobile device touches the ATM or the ticketing machine for the first time. Its purpose is to send the mobile device the self-service terminal type, so that the mobile device picks the appropriate token stored on the device and so that it can give the user feedback about the token. Note that the CLA field is 0x80, indicating a proprietary command, but the instruction byte is chosen arbitrary. The first parameter is the self-service terminal type (1 for ATM and 2 for ticketing machine). There is no data payload in the command. � HANDSHAKE CONFIRMATION:

CLA 0x80 INS 0xE3 P1 0x00 P2 0x00 Lc 0x00 Data field - Le field 0x0000

Table 5: Details of the HANDSHAKE CONFIRMATION command.


This command is sent from the ATM to the mobile device when the handshake has been completed successfully. Remember that the NFC communication is half-duplex: The ATM receives a response from the mobile device whether or not the command has been processed successfully, but the mobile device has no way of knowing if the ATM has received the response. Because of the TokenAccess two-tap workflow, both the ATM and the mobile device have to know the current state of the transaction, meaning the mobile device needs to know whether or not the ATM has completed the handshake and has moved to the next step. This is where the HANDSHAKE CONFIRMATION command comes into play. After the HANDSHAKE command has been sent to the mobile device and the response has been received successfully by the ATM, the ATM sends the HANDSHAKE CONFIRMATION command to the mobile device so that the mobile device can adjust its state accordingly. � GET TOKEN:

CLA 0x80 INS 0xE2 P1 0x01 or 0x02 P2 0x00 Lc 0x00 Data field - Le field 0x0000

Table 6: Details of the GET TOKEN command.

The GET TOKEN command is sent after the mobile device touches the ATM for the second time. As the name suggests, the ATM is asking the mobile device to send the appropriate token stored on the device to the ATM. The token contains no data payload and the first parameter is the type of the self-service terminal (ATM or ticketing machine) just like with the HANDSHAKE command. The response from the mobile device contains the token (Base64 encoded JSON). � TOKEN CONFIRMATION:

CLA 0x80 INS 0xE4 P1 0x00 P2 0x00 Lc 0x00 Data field - Le field 0x0000 Table 7: Details of the TOKEN CONFIRMATION command.

When the ATM receives the token, the TOKEN CONFIRMATION command is sent to the mobile device to inform it that the transaction has completed. The reasoning behind this command is the same as with the HANDSHAKE COMMAND: The mobile device has to be notified by the ATM that the response to the GET TOKEN command (the token) has been received successfully.


Figure 70: Example of an ATM to mobile device communication. In this example, the token on the user’s device is a

token for the operation “withdraw money” and has a value of “30 Euros”. Error handling is omitted for the sake of simplicity.


1: The communication starts when the mobile device touches the ATM for the first time. The ATM recognizes the tag simulated on the mobile device and sends a SELECT command. 1.1: The mobile device receives the SELECT command. As long as the device is still in contact with the NFC reader, this command and all consecutive commands of the ATM are routed to the TokenAccess client application identified by the AID (F333333333). There is no data to be transmitted from the mobile device back to the ATM, so a simple OK (0x0900) response is sent. 2: The ATM sends a HANDSHAKE command to the mobile device. With the SST type from the HANDSHAKE command, the mobile device can choose the correct token on the device. Notice how the first parameter in the HANDSHAKE command is 0 (0x80E10000000000), indicating that the command is coming from an ATM. 2.1: The mobile device retrieves the ATM token stored on this device and looks up the operation stored on the token. A self-service terminal can support several token types used for different operations, for example an ATM supports “withdraw money” and “deposit money” tokens. In some cases, the ATM needs to know which operation is stored on the token, before even receiving the token. This is the case with a “deposit money” token for example. The workflow is that the ATM opens the slot on the terminal for putting the bills in as soon as TokenAccess is activated on the terminal. To be able to do that, the ATM needs to receive the information about the operation type in response to the HANDSHAKE command. In our example, the response indicates that the operation in the upcoming token is “withdraw money”: 0x010900, 1 indicates “withdraw money”, 2 indicates “deposit money”. 3: The ATM sets its transaction state to “handshake complete”. 4: The ATM sends the confirmation message to the mobile device. 4.1: The mobile device also sets its transaction state to “handshake complete”. 4.3: The mobile device sends a simple OK response (0x0900). All the steps in the communication step happen during the first touch of the ATM with the mobile device. Once the handshake is finished, the user receives feedback from his mobile device in form of vibration and an audio message. The audio message tells him that “TokenAccess has been activated”. The user is expected to touch the ATM a second time for confirmation, which will cause the token to be transferred to the ATM and executed there. 5: Here, the second touch of the ATM with the mobile device starts. The SELECT command has to be sent again, because the mobile device has been removed from the ATM and now touches it for a second time. This is the same SELECT command as during the first touch. 5.1: The mobile device again responds with a simple OK. 6: The ATM sends the GET TOKEN command. The GET TOKEN command also includes the self-service terminal type: 0x80E20100000000. 6.1: The mobile device sends back an OK response that contains the token. The token is sent formatted as JSON, and encoded in UTF-8 and converted to a byte array. Such an OK response containing the token would look like: 0x7B225...673D3D227D0900. 7: The ATM verifies the digital signature stored on the token.


8: The ATM contacts the TokenAccess server and asks it to verify the token. 9: The ATM changes the transaction state to “token received”. The ATM does not reset the transaction state to “idle” although the transaction is complete because of simulation reasons. We want the ATM simulation to show the last state (e.g. the bills being given out) as long as needed. The simulation can then be reset manually by double tapping the screen. 10: If the verification steps are successful, the ATM sends the TOKEN CONFIRMATION command to the mobile device. 10.1: The mobile device sets its transaction state to “idle”. 10.2: The mobile device sends a simple OK response.

Figure 71: The JSON representation of the token that is sent as a byte array to the ATM.

7.4. Installation and setup of the prototype environment

7.4.1. Hardware and software requirements

For a fully functioning prototype environment where you can test TokenAccess yourself, you will need: � Two NFC capable Android devices with Android 4.4 or higher, one for the “mobile device of

the user” and one for the ATM simulation. Although not strictly necessary, we suggest a tablet type of device in landscape mode for running the ATM simulation.

� A PC to run the TokenAccess server on. The server application is platform independent and should work on Windows, Mac OS and Linux as long as a current version of Java Runtime Environment is installed.

� Java Runtime Environment 1.8 or higher for the TokenAccess server.

� MySQL 5.7 or higher, also for the TokenAccess server.

� An HTML5 compatible web browser for using the web interface. The audio enrollment described in section 6.1.2 depends on the audio tag that was introduced with HTML5. The audio message itself is encoded as mp3, so any HTML5 capable browsers should work.


7.4.2. Installation

TokenAccess has a Bintray project repository that hosts the binary packages for all there components: https://bintray.com/emrezaim/TokenAccess You can download APKs for the TokenAccess client application and the TokenAccess ATM simulation as well as a self-contained distribution package for the TokenAccess server there. At the time of this writing, the project repository contains the initial release 1.0, which is the final form of the prototype iteratively improved with the usability testing you will read more about in the next chapter. To set up the TokenAccess server:

� Before starting with the server setup, you will have to set up the MySQL database.

� Create a new user for your MySQL installation with the username “admin” and the password “Admin123”. If you want to use other values for the username and password, you will have to adapt the parameters db.default.username and db.default.password in the TokenAccess server configuration file you can find at conf/application.conf.

� Create a new database schema called “token_access”. Again, if you want to use another name, you will have to adapt the parameter db.default.url.

� Start the MySQL server if it is not running already.

� Download the latest TokenAccess server package from https://dl.bintray.com/emrezaim/TokenAccess/.

� Unzip the package.

� Navigate to the folder “bin” on the console.

� Execute the “tokenaccess-server.bat” script to start the server.

� Open a browser window and go to “127.0.0.1:9000”, you should be greeted by the login screen if everything went all right.

To setup the TokenAccess ATM Android application:

� Download the TokenAccess ATM simulation APK from https://dl.bintray.com/emrezaim/TokenAccess/.

� Copy the APK to the local storage of the mobile device that will run the simulation.

� You must allow installing applications from unknown resources on your device. The required setting is under “Settings Æ Security Æ Unknown Resources” on most Android devices.

� Browse to the location where you have saved the APK with a file manager and tap the APK file to install it.

� Start the application once the installation is finished.

� You will be shown the setup screen.

� Here enter the TokenAccess server’s IP address including the port number “9000”, for example “220.98.63.45:9000”. You can use a website like http://checkip.amazonaws.com/ to

https://bintray.com/emrezaim/TokenAccess

https://dl.bintray.com/emrezaim/TokenAccess/


http://checkip.amazonaws.com/


get your server’s IP address that is visible to the outside in case your server is part of a local network.

� Tap “Save”.

� When everything goes right, the ATM simulation application will connect to the TokenAccess server and configure itself. You will be shown a confirmation message when the process is completed.

� You can later access the setup screen by long tapping anywhere on the screen. You can change the simulation type and save, this will change the simulation from ATM to ticketing machine etc.

� You can always reset the simulation by double tapping anywhere on the screen. This comes handy when the simulation gets stuck for whatever reason.

To setup the TokenAccess client application:

� Download the latest TokenAccess client APK from https://dl.bintray.com/emrezaim/TokenAccess/.

� Install the application on the mobile device that will act as the user’s personal mobile device. The installation steps are the same as above.

� Once the installation is finished, start the application.

� Tapping the screen once, you should hear that your device is not connected to the TokenAccess server yet.

� You can access the debugging menu by tapping the three dots on the upper right corner of the screen. Here you can find some useful functions like resetting the transaction state or disconnecting the device from the TokenAccess server.

Once you have successfully installed and set up all three components of the prototype, you are ready to try out TokenAccess yourself. You can create a new user, login on the TokenAccess web interface and follow the instructions given there for connecting your mobile device to the TokenAccess server and creating tokens.

7.4.3. Getting the source code

The source code for all three components of the prototype are available if you want to modify or extend the prototype. The code lives in three separate SVN repositories: � https://svn.riouxsvn.com/tokenaccess_srv for the TokenAccess server

� https://svn.riouxsvn.com/tokenaccess_atm for the TokenAccess ATM simulation

� https://svn.riouxsvn.com/tokenaccess_cli for the TokenAccess client application

All three repositories can be accessed read-only by the user account: � Username: TokenAccess_SVN

� Password: Admin123


https://svn.riouxsvn.com/tokenaccess_srv

https://svn.riouxsvn.com/tokenaccess_atm

https://svn.riouxsvn.com/tokenaccess_cli



8. Usability Study

To test the viability of the TokenAccess concept and the usability of the prototype, a series of usability studies were conducted. The methodology deployed during the user studies was based on the insight gained by Nielsen and Landauer in their seminal paper “A Mathematical Model of the Finding of Usability Problems” [95]. Nielsen summarizes this as: “Elaborate usability tests are a waste of resources. The best results come from testing no more than 5 users and running as many small tests as you can afford”. Nielsen also states the importance of iterative testing and argues that: “You want to run multiple tests because the real goal of usability engineering is to improve the design and not just to document its weaknesses” [96]. We have followed Nielsen’s advice and conducted several iterations of usability tests with a small number of users and improved the TokenAccess prototype between each iteration based on the feedback we have received. Our test group consisted of 5 users: � A user without any disabilities

� Two blind users

� A user with mild cognitive disability

� A user with motor disabilities

Some data was collected from each user before the usability testing to ensure that they are ideal candidates. In particular: � All users were using personal computers and a web browser in their daily activities as part of

their work as well as in their private life. All users were able to navigate web pages with ease and were already doing it in their personal accessible environment as part of their daily computer usage.

� All users had a smartphone that they used in everyday life. The blind users had iPhones and the other users had Android phones. To provide the same test environment to all users and also because the TokenAccess prototype can only run on Android devices currently, all of the users were provided with the same Android smartphone that had the TokenAccess client application pre-installed.

� All users have been using ATMs before in their daily life.

� All users except the user with mild cognitive disability were familiar with NFC based payment systems.

The usability test was divided into concrete tasks with the goal of identifying usability problems in both the web interface and also the client application of the TokenAccess prototype. These tasks were:

� Navigating the client application before it is connected to TokenAccess.

� Connecting the client application to TokenAccess via audio-based enrollment.

� Create a “withdraw money” token for single usage on the TokenAccess web interface.

� Use this token to withdraw money on the TokenAccess ATM simulation.


� Create a “withdraw money” token for multiple usages.

� Use this token multiple times on the TokenAccess simulation.

� Create multiple tokens (both ATM and ticketing machine) for the same device.

� Navigate the client application when there are multiple tokens on the mobile device.

� Use these tokens on different simulations (ATM and ticketing machine) to withdraw money and buy a tram ticket.

In total, we have had eight test runs: two with each blind user, one with the user with mild cognitive disability, one with the user with motor disabilities (web interface only) and two with the user with no disabilities. As explained before, the goal was to improve the prototype iteratively with the results of the usability tests. So instead of presenting the raw results of each test run, we will next present the problems identified during the usability tests and how the prototype was improved accordingly. � Audio-enrollment workflow

As a reminder of how the audio-enrollment works:

� The user starts the TokenAccess client application on his mobile device.

� The user puts the client application into enrollment mode via a special gesture.

� The user clicks a button on the “Connect your device to TokenAccess” page on the web interface.

� An audio track (the enrollment message) is played in the web browser.

� The mobile device listens and decodes this audio message.

During the first test run with the user without disabilities, the user was not able to complete the enrollment process on her own without any help from us. It became clear that:

� The instructions shown on the web interface were not clear and detailed enough so that the user could complete the enrollment by simply following the instructions.

� Starting the enrollment on the mobile device was error prone and not intuitive.

� It took the mobile device too long to process the enrollment message played out by the web browser.

To improve the first point, new instructions were formulated. Each instruction is one atomic action that has to be completed before proceeding to the next instruction. The instructions are written in simple and non-technical language. You can read the instructions on Fig. 43 on page 61. The second point had to do with the fact that every interaction with the TokenAccess client was done with a simple tap. This was by design to keep things simple, but has proven to be a major mistake. The solution was to assign a separate gesture (a double-tap) to the action of starting the enrollment. This, in combination with clear instructions, removed many of the errors and made it possible that the user could complete the enrollment on his own. Due to technical details of the implementation, it took the mobile device about 40 to 60 seconds to decode the audio enrollment message from the web browser. We figured that this


would pose no problem as the enrollment has to be done only once, but this has proven to be a mistake. During the listening and decoding of the audio message, the mobile device cannot give the user any feedback in form of vibration or audio as this would interfere with the decoding itself. This lack of feedback and the long duration of the decoding made the user believe that something went wrong and the enrollment process was unsuccessful. But we were able to reduce the time required for decoding the enrollment message to about 10 seconds. This way, the user gets a faster feedback whether or not the enrollment has worked. In case it did not work, the user can try again. Because the decoding is much faster now, having to start the enrollment a second time – because of ambient noise for example – is not perceived as bothersome as before.

� Screen readers and binding actions to keyboard keys In one of the earlier versions of the prototype, the user had to start playing the enrollment message by pressing the “enter” key on the keyboard, there was no traditional button on the enrollment web page to do it. After the mobile device starts listening for the enrollment message, the user has to start playing the enrollment message within a short amount of time – about five seconds – otherwise the enrollment usually fails. The idea was that pressing a key on the keyboard would be easier and faster to execute for users with disabilities than clicking a button on the enrollment web page with the mouse. We have observed during the first usability tests that this was a mistake. The blind users were using screen readers on their personal computers that bind keyboard keys to special actions. In other words, pressing the enter key would execute the pre-defined actions of the screen reader instead of starting the enrollment message. According to the blind users, it is possible to disable the key binding of the screen reader at any time. The feedback we have received was that either:

� The enrollment instructions should clearly state that the key binding of the screen reader should be temporarily disabled before pressing the enter key to start the enrollment message.

� Or the enrollment should be started by clicking a button on the enrollment web page. Locating the button and clicking it would not be a problem according to the blind users.

In our opinion, the first option had many drawbacks. The enrollment instructions could not be kept in a general form for all users and instead would have to include a special instruction for blind users. We have anticipated that disabling the key binding in the screen reader and pressing the enter key might take too long as well. Because of these reasons, we chose to go with the second option. The second iteration of usability tests with blind users has proven that they had no difficulties locating and clicking the button to start the enrollment message. We did not measure the exact time it took the user to click the button as it was very fast and an absolute non-issue.

� Automatic page redirect when the device is connected successfully

Both the user with mild cognitive disability and the user without any disabilities raised the question of why the “Connect your device to TokenAccess” page is not reloaded automatically with the information that the audio enrollment has finished successfully after the client application is successfully enrolled. The user without disabilities suggested that she would like to be redirected to the start page once the enrollment was successful. We have


decided not to implement this feature, because of the accessibility concerns with automatic page redirects [97].

In the current implementation, the user is notified by the client application that the enrollment has finished (audio feedback) and that he has to click the “Go to the start page” button on the “Connect your device to TokenAccess” page to go back to the start page where he then can create tokens.

� Home link The blind users both requested that the web interface should have a link to the start page on every page. They were used to webpages having such a home link and the lack of it made navigation difficult for them. This link was implemented on the TokenAccess logo that is on the header of each page. Furthermore, the alternative text for the TokenAccess logo was extended to say that clicking the logo will take the user to the start page.

� Feedback when creating a new token One complaint from blind users was that they received no immediate feedback after they had created a new token on the web interface. This animated us to add audio and vibration feedback to the TokenAccess client on the mobile device. Each time a new token is created on the web interface and pushed to the mobile device, the device vibrates and a summary of the token (value, how many times it can be used etc.) is read out aloud to the user. On the second round of the testing, the feedback from blind users was very positive. The user with mild cognitive disability also perceived the immediate audio feedback as very positive. The user without disabilities had no strong preference for or against the immediate feedback. The user with motor disabilities clearly disliked it. In his opinion, the feedback should be an option to turn on if needed, but it should be turned off by default. His argumentation was that this kind of audio feedback was well-suited for blind users but not for any other user type. This was the last round of user testing we had done and his feedback was not implemented further into the prototype. We think his criticism is valid and the client application could be improved further. You can read more about this in the next chapter “Conclusions and Future work”.

� Having multiple tokens of the same type on the same device One key point of the TokenAccess workflow is that the user can have only one token for each self-service terminal type on his mobile device at any given time, e.g. one “withdraw money” or “deposit money” token (ATM) and one “buy tram ticket” token (ticketing machine) and so on, but not one “withdraw money” and “deposit money” token at the same time. It is this restriction that allows the self-service terminal to pick the correct token on the device without the need of user interaction with the mobile device.

During testing, the users were not told of this restriction in order to observe whether or not they would perceive it as a big restriction. When executing the fourth task in the test plan (Using the prepared token on the ATM simulation), all five users were pleasantly surprised that the whole interaction did not require any interaction with the mobile device itself. That being said, all but the user with mild cognitive disability said that they would still like to have the option to have multiple tokens of the same type on the device. The users suggested some possible scenarios where this might be useful:


� For withdrawing money, being able to withdraw different amounts for different occasions would be useful.

� One possible usage of a “withdraw money” token would be to always have a token on the device for emergencies. But if one wants to deposit money, he has to delete his emergency “withdraw money” token.

� Although the ticketing machine simulation is for tram tickets only, the same concept would apply to train tickets just as well. It is usual that multiple tickets have to be purchased for longer distances. In this case, one might not want to buy all tickets at once. Not being able to store more than one token on the device makes this impossible.

In general, it became clear that users really wanted the option to store an arbitrary number of tokens for the same self-service terminal type on the device. We have not implemented this in the prototype as this would involve a major redo of the client UI. Also the two-tap workflow would have to be adapted so that the user can pick the token during the interaction with the terminal. You can read more about our proposed solution in the next chapter “10. Conclusions and Future Work”.

� Better feedback during the token execution at the ATM One of the blind users wanted to have a clear indication when the transaction at the self-service terminal was completed successfully. The audio feedback text that was spoken out was not clear in his opinion. He suggested that the text should contain the words “Transaction completed” or “Transaction completed successfully” to clearly indicate that the transaction was successful. This was then implemented into the prototype.

� Moving the mobile device around on the surface of the tablet Another common mistake was that the users kept the mobile device on the ATM (the tablet device in our simulation) after the first touch. It had to be explained to the users that they had to remove the device away from the ATM after the first touch. Keeping the mobile device on the ATM is not a problem in itself, but it was a problem in our simulation environment because of the position of the NFC reader in the tablet device. The NFC reader is right in the middle of the tablet and the tablet’s surface is rather large, so moving the mobile device while it is still on the tablet caused the connection to the NFC reader to fail. In other words, moving the mobile device too much while it is still touching the tablet is equal to completely removing the mobile device from the tablet. Similarly, moving the mobile device again into the range of the NFC reader while it is still on the tablet is registered as touching the ATM a second time. This would not be such a problem with real world NFC readers as the surface of the reader is rather small compared to a tablet and thus it is physically not possible to move around the mobile device on the reader without leaving the surface area of the reader. In our simulation, users were keeping the mobile device on the tablet after the first touch and moving the mobile device around on the tablet unintentionally while they were paying attention to the audio message being spoken out. This was tricking the simulation to think that the mobile device was removed and touched the ATM again, which caused confusion with users. At the end, this is a limitation caused by using a tablet as the NFC reader and there is not much we could do about this. We have implemented some heuristics into both the client application as well as into the ATM simulation to compensate a little for this problem. The blind users noticed a big improvement on their second run of tests, but it has to be said that they were already aware of the problem from their first test run and were being careful not to keep the mobile device on the tablet and move it around after the first touch.


The user without disabilities never ran into the problem as it was clear for her that she had to remove the mobile device from the tablet as soon as she got the vibration feedback. The user with mild cognitive disability ran into the problem very often, even with the version of the prototype that had the heuristic improvements built-in. The user with the motor disabilities only tested the web interface part of the prototype, so the problem was not relevant in his case. While we were not able to run any tests with a real NFC reader device, we strongly anticipate that this problem would not exist with such a device and consider the workflow not affected. As you can see from the summary of the test results, users were able to complete the interaction at the ATM once they were explained what the problem was and what they should pay attention to.

� Final results Below is an overview of the results from the last round of the usability study:

Blind

user 1 Blind

user 2

User with mild

cognitive disability

User without any

disabilities

User with motor

disabilities

Navigating the client application before it is connected to TokenAccess

9 9 9 9 -1 Connecting the client application to TokenAccess via audio-based enrollment

9�92 9 9 9 1 Create a “withdraw money” token for single usage on the TokenAccess web interface

9�9� 9� 9� 9 Use this token to withdraw money on the TokenAccess ATM simulation

9 9 9 9 -1 Create a “withdraw money” token for multiple usages 9 9 9 9 9 Use this token multiple times on the TokenAccess simulation 9 9 93 9 -1 Create multiple tokens (both ATM and ticketing machine) for the same device

9 9 9 9 9 Navigate the client application when there are multiple tokens on the mobile device

9�9� 9� 9� -1�Use these tokens on different simulations (ATM and ticketing machine) to withdraw money and buy a tram ticket

9 9 X4 9 -1


1. In his daily life, the user with motor disabilities was using a smartphone with a mouth stick and the smartphone being placed on a desk. Thus during our tests, he was not able to complete some of the tasks that involved handling the smartphone, e.g. the interaction at the ATM because of his motor disabilities. Furthermore, the mouth stick stylus he was using was not compatible with our test device, so we did the interaction with the mobile device for him and had him evaluate the interaction with the web interface as well as the workflows as a whole.

2. The audio enrollment failed multiple times before finally working when we suggested that the user put his mobile device directly in front of the speakers and turn on the volume louder. On the next try, the audio enrollment worked. We believe that the problem was ambient noise in the room or the speakers not producing a clear enough sound at low volume levels.

3. This was the first test run with the user with mild cognitive disability and we have not instructed her in detail that she should not move the mobile device while it is on the tablet, etc. This was done deliberately to see if she would run into the same problems as the users before her, and she did. Interestingly, she did not run into this problem on the first time she had to withdraw money at the ATM simulation, but later on during the “withdraw money multiple times” task. Once she was explained what the problem was and was instructed not to move the mobile device while it is touching the tablet, she was able to complete the interaction. As explained before, we consider this to be a problem of the prototyping environment that cannot be solved.

4. The ATM simulation had a bug that caused the simulation to be stuck at ATM mode internally and it acted like an ATM although the UI was showing a ticketing machine. The problem was later on solved by re-installing the simulation app, but this could not be done during the test run. This means that while the user was able to complete the first part of the task (“withdraw money”) she could not complete the second part (“buy a tram ticket”) and we considered the task to have failed.



9. Conclusions and Future Work

In this work, we have presented the TokenAccess concept for improving the ATM accessibility and usability and developed a prototype to test the feasibility of the concept. We have analyzed the current state of the art in ATM accessibility and the requirements for a better solution. Research questions were derived from the state of the art and requirements. These research questions were answered over the course of the work: � Can we really decouple the ATM interface and interaction from the ATM and to what

extent? In chapter 4, “Interaction with ATMs: Analysis and Design”, we have analyzed the ATM interface and interaction and explained what parts can be decoupled.

� Can we implement the steps, actions and user interfaces required to replicate the ATM interface and interaction on the alternative platform based on the WCAG 2.0 standard and the related methods, techniques and tools? In chapter 5, “Interaction Design TokenAccess”, we explain how the decoupling of the ATM interface and the TokenAccess interaction model works. We explain how preparing the ATM interaction on a web interface based on WCAG 2.0 circumvents the problem of making the ATM interface accessible. We show how the TokenAccess interaction model can be applied to different operations like withdrawing and depositing money with an ATM and also buying tram tickets with a ticketing machine.

� Can the interaction at the ATM be reduced to a minimum based on the pre-executed interaction on the alternative platform and using NFC? In chapter 5, section 2, “Executing the prepared interaction at the ATM”, we introduce the TokenAccess workflow at the ATM, which we call the two-tap workflow. We explain how easy the two-tap workflow is to understand, remember and execute. Later on, in the results of the usability study, we show that the majority of users were able to execute the two-tap workflow successfully and with ease.

� Does the proposed solution meet users’ accessibility and usability requirements better than the current ATM interaction? In chapter 8, “Usability study”, we presented the results of the usability study. Users with different disabilities (two blinds users, a user with mild cognitive disability, a user with motor disabilities) and a user without any disabilities took part in the usability study. ATM operations like withdrawing and depositing money and buying tickets from a ticketing machine using TokenAccess were evaluated during the usability study. All participants were able to complete these actions successfully and with relative ease. In our opinion, this shows the feasibility of TokenAccess as an alternative interaction model for ATMs as well as other types of self-service terminals.

� Can we argue that all safety, security and privacy aspects are respected at the same level as with the ATM interaction? In chapter 6, “TokenAccess Architecture and Security”, we have analyzed the security implications of applying the TokenAccess concept to critical ATM operations such as withdrawing money. We have shown how TokenAccess would be secure against most common attack scenarios.


We think there are two major points that could be addressed in future works: � Extending the TokenAccess interaction concept and prototype to allow multiple

tokens of the same type on one mobile device. The ability to have more than one of the same token type on the mobile device was a request by several users during the usability testing. Users gave examples for real life scenarios where this might come in handy, for example having several ticketing machine tokens for a long train journey where the user might not want to buy all tickets at once, or several “withdraw money” tokens for different amounts, so that the user could withdraw money more than once without having to create a new token using the web interface. Allowing more than one token of the same type on the mobile device is not a matter of technical limitations. The challenge is rather rethinking the two-tap workflow that is the core of the interaction with the ATM. The two-tap workflow is only possible because the mobile device knows which self-service terminal type it is in contact with and there can be only one token for this self-service terminal type on the mobile device. Allowing more than one token of the same type on the mobile device would mean that the user must choose the token he wants to execute. The easiest way to achieve this, is, to make the user choose the token before touching the self-service terminal with his mobile device, and then execute the two-tap workflow as usual. To test the feasibility of this new workflow, the prototype would have to be modified and several new rounds of usability tests should be conducted. This is left out for future work.

� Improving the user interface of the TokenAccess client application running on the mobile device. To make the interaction with the mobile device easy to use and accessible to all users, the UI of the TokenAccess client application was devised as an interface relying solely on gestures as input and speech as output. This type of interface has proven to be too specialized for blind users’ needs. In hindsight, we think that a GUI designed with the native widgets of the mobile platform might be a better solution to serve all user types. Such an interface would be familiar for users without disabilities as it would resemble other applications on the device and still be accessible for users with disabilities if the mobile platform offers good accessibility support and guidelines for native applications. This could not be verified as the blind users in our test group were both iPhone users and our prototype was running on Android. What could be done in a future work is to implement a second version of the client application with a native GUI instead of the current interface, run usability tests with both versions and try to find out if the native GUI is indeed perceived as the better option by all users.


10. Bibliography

[1] B. Batiz-Lazo and R. J. K. Reid, "Evidence from the Patent Record on the Development of

Cash Dispensing Technology," p. 4, 2008. [2] "Monitoring eAccessibility in Europe: 2011 Annual Report," Technosite for the European

Comission, 2011. [3] "Barrierefreie Geldausgabe," [Online]. Available:

http://www.blindenverband.at/home/672?help=1. [Accessed 24 02 2016]. [4] "Safer banking tips for disabled people," [Online]. Available:

http://www.bbc.com/news/blogs-ouch-31108792. [Accessed 24 02 2016]. [5] Bank Austria, "Bank Austria Maestro Guidelines," [Online]. Available:

http://www.bankaustria.at/files/Maestro_Guidelines.pdf. [Accessed 22 03 2016]. [6] "How Blind People Use The ATM," [Online]. Available:

https://www.youtube.com/watch?v=Jzah0A6IC5o. [Accessed 03 04 2016]. [7] "OTI to outfit financial self-service terminals with NFC," [Online]. Available:

http://www.atmmarketplace.com/news/oti-to-outfit-financial-self-service-terminals-with-nfc/. [Accessed 06 04 2016].

[8] "Diebold takes NFC to the self-checkout," [Online]. Available: http://www.nfcworld.com/2016/01/14/341260/diebold-takes-nfc-to-the-self-checkout/. [Accessed 06 04 2016].

[9] E. Bergman and E. Johnson, "Towards Accessible Human-Computer Interaction," in Advances in Human-Computer Interaction, 1995.

[10] "2010 ADA Standards - Chapter 7: Communication Elements and Features," [Online]. Available: http://www.ct.gov/brs/lib/brs/pdfs/adastandards2010.pdf. [Accessed 27 06 2016].

[11] "Proposal for a directive of the European Parliament and of the Council on the approximation of the laws, regulations and administrative provisions of the Member States as regards the accessibility requirements for products and services," [Online]. Available: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2015:0615:FIN. [Accessed 27 06 2016].

[12] "Web Content Accessiibility Guidelines (WCAG) 2.0," [Online]. Available: https://www.w3.org/TR/WCAG20/. [Accessed 02 07 2016].

[13] "ISO/IEC 40500:2012: Information technology -- W3C Web Content Accessibility Guidelines (WCAG) 2.0," [Online]. Available: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=58625. [Accessed 25 02 2017].

[14] "WCAG 2.0 - Understanding the Four Principles of Accessobility," [Online]. Available: https://www.w3.org/TR/UNDERSTANDING-WCAG20/intro.html#introduction-fourprincs-head. [Accessed 29 01 2017].

[15] "How to meet WCAG 2.0," [Online]. Available: https://www.w3.org/WAI/WCAG20/quickref/. [Accessed 29 01 2017].

[16] "Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile," [Online]. Available: https://www.w3.org/TR/mobile-accessibility-mapping/. [Accessed 29 01


2017]. [17] "Developing accessible applications - Windows app development," [Online]. Available:

https://developer.microsoft.com/en-us/windows/accessible-apps. [Accessed 02 07 2016]. [18] "Accessibility on OS X - Apple developer," [Online]. Available:

https://developer.apple.com/accessibility/osx/. [Accessed 02 07 2016]. [19] "Implementing Accessibility | Android Developers," [Online]. Available:

https://developer.android.com/training/accessibility/index.html. [Accessed 02 07 2016]. [20] "Accessibility on iOS - Apple Developer," [Online]. Available:

https://developer.apple.com/accessibility/ios/. [Accessed 02 07 2016]. [21] "ATMs Fall Short on Disability Rule," [Online]. Available:

http://www.wsj.com/articles/SB10001424052970204276304577265710282201338. [Accessed 27 06 2016].

[22] "More ADA lawsuits land on court dockets," [Online]. Available: http://www.atmmarketplace.com/news/more-ada-lawsuits-land-on-court-dockets/. [Accessed 27 06 2016].

[23] "7 new ADA lawsuits lodged against Tenn. FIs," [Online]. Available: http://www.atmmarketplace.com/news/7-new-ada-lawsuits-lodged-against-tenn-fis/. [Accessed 27 06 2016].

[24] "Refreshable Braille Display," [Online]. Available: http://www.afb.org/info/living-with-vision-loss/for-job-seekers/careerconnect-virtual-worksites/retail-worksite-for-blind-users/refreshable-braille-display-3652/12345. [Accessed 27 06 2016].

[25] "JAWS screen reader," [Online]. Available: http://www.freedomscientific.com/Products/Blindness/JAWS. [Accessed 27 06 2016].

[26] "QuadJoy - Hands Free Muth Mouse," [Online]. Available: https://quadjoy.com/. [Accessed 06 04 2016].

[27] A. H. M. Hiroko, "Usability Research for the Elderly People," Oki Technical Review, vol. 71, no. 199, pp. 54-57, 2004.

[28] A. Tarakonov-Plax, "Design Concept for ATM Machine, Accessible for the Elderly Users in Israel," 2005.

[29] N. S. University, The Principles of Universal Design, 2006. [30] S. P. a. T. Agency, "How accessible are automated teller machines for people with

disabilities and elderly?," 2014. [31] "Barriers to Using Automated Teller Machines," [Online]. Available:

https://www.humanrights.gov.au/barriers-using-automatic-teller-machines#_Toc474344391. [Accessed 29 01 2017].

[32] G. T. U. D. Survey, "An analysis of a survey of 402 participants with disabilities focusing on universal design features found in common consumer products".

[33] A. Tarakanov-Plax, "Design concept for ATM Machine, Accessible for the Elderly Users in Israel".

[34] A. o. Aging. [Online]. Available: https://aoa.acl.gov/Aging_Statistics/Index.aspx. [Accessed 29 01 2017].

[35] T. O. A. A. T. Asawa, "Promoting Universal Design of Automated Teller Machines (ATMs)," Fujitsu, 2004.


[36] "WebAIM: Types of Motor Disabilities," [Online]. Available: http://webaim.org/articles/motor/motordisabilities. [Accessed 04 02 2017].

[37] M. U. J. A. Cristobal R. T., "Present and future of eAccessibility in public digital terminals," European Journal of ePractice, vol. 10, 2010.

[38] "APSIS4all," [Online]. Available: http://apsis4all.eu/. [Accessed 08 08 2016]. [39] B. C. Ignacio Madrid R., "APSIS4all: Personalisation as a Strategy to Ensure Accessibility

and Echance User Experience of Public Digital Terminals". [40] EN 1332-4 identification card systems - Man-machine interface / Part 4: Coding of user

requirements for people with special needs. [41] S. K. O.-M. M. Ignacio Madrid R., "Improving the Accessibility of Public Digital Terminals

thourgh Personalisation: Comparison of Direct and Indirect Interaction Modes". [42] S.-V. C. G. R. T.-M. M. B. D. Pous M., "Enchancing accessibility: mobnile to ATM case

study," in 2nd IEEE International Workshop on Consumer eHealth Platforms, Services and Applications, 2012.

[43] "Mobile Technology Fact Sheet," [Online]. Available: http://www.pewinternet.org/fact-sheets/mobile-technology-fact-sheet/9/. [Accessed 24 04 2016].

[44] "Interbank network," [Online]. Available: https://en.wikipedia.org/wiki/Interbank_network. [Accessed 27 06 2016].

[45] "Erste Bank launches range of NFC payment options in Austria," [Online]. Available: http://www.nfcworld.com/2016/06/07/345335/erste-bank-launches-range-nfc-payment-options-austria/. [Accessed 27 06 2016].

[46] "Bank of America enables Apple Pay and Samsung Pay at ATMs," [Online]. Available: http://www.nfcworld.com/2016/06/20/345674/bank-america-enables-apple-pay-samsung-pay-atms/. [Accessed 27 06 2016].

[47] "Bank of America adds Android Pay withdrawals at ATMs," [Online]. Available: http://www.nfcworld.com/2016/05/19/344886/bank-america-adds-android-pay-withdrawals-atms/. [Accessed 27 06 2016].

[48] "Spanish Bank Installs "First" Contactless ATMs," [Online]. Available: http://www.nfctimes.com/news/spanish-bank-installs-first-contactless-atms. [Accessed 03 07 2016].

[49] "1 billion Visa contactless purchases made in last year," [Online]. Available: https://www.visaeurope.com/newsroom/news/1-billion-visa-contactless-purchases-made-in-last-year. [Accessed 24 04 2016].

[50] "Contactless Payment Revolution at Erste Bank uns Sparkassen," [Online]. Available: https://www.erstegroup.com/de/news-media/presseaussendungen/2016/06/02/contactless-payment-revolution. [Accessed 11 02 2017].

[51] "Banken planen Einführung von NFC-Bankomaten," [Online]. Available: https://www.ress.at/banken-planen-einfuehrung-von-nfcbankomaten-news25072014102309.html. [Accessed 11 02 2017].

[52] "iOS Accesibility," [Online]. Available: http://www.apple.com/accessibility/ios/. [Accessed 07 04 2016].

[53] "Android accesibility features," [Online]. Available: https://support.google.com/accessibility/android/answer/6006564?hl=en. [Accessed 07 04 2016].


[54] "Adapted PC-Worstations for Visually-Disabled Students at the University of Marburg," [Online]. Available: https://www.uni-marburg.de/studium-en/specialneeds/visuallydisabled/pc-workstation. [Accessed 01 07 2016].

[55] "Sip & Puff Joystick Controlled by Mouth - Jouse2," [Online]. Available: https://www.youtube.com/watch?v=fFi5_ctNFl0. [Accessed 01 07 2016].

[56] "Assitive Technology Blog: How Do Blind Users Use Smartphones?," [Online]. Available: http://www.assistivetechnologyblog.com/2014/02/how-do-blind-users-use-smartphones.html. [Accessed 02 07 2016].

[57] "How Accessibility Works in GNOME," [Online]. Available: https://developer.gnome.org/accessibility-devel-guide/stable/gad-how-it-works.html.en. [Accessed 02 07 2016].

[58] "Accessibility | Qt 5.7," [Online]. Available: http://doc.qt.io/qt-5/accessible.html. [Accessed 02 07 2016].

[59] "Government accessibility standards and WCAG 2," [Online]. Available: http://www.powermapper.com/blog/government-accessibility-standards/. [Accessed 02 07 2016].

[60] "Apple Pay," [Online]. Available: http://www.apple.com/apple-pay/. [Accessed 05 07 2016]. [61] "Android Pay," [Online]. Available: https://www.android.com/pay/. [Accessed 05 07 2016]. [62] "Near Field Communication | Android Developers," [Online]. Available:

https://developer.android.com/guide/topics/connectivity/nfc/index.html. [Accessed 05 07 2016].

[63] "Host-based Card Emulation | Android Developers," [Online]. Available: https://developer.android.com/guide/topics/connectivity/nfc/hce.html. [Accessed 05 07 2016].

[64] "Wikipedia: HTTPS," [Online]. Available: https://en.wikipedia.org/wiki/HTTPS. [Accessed 04 08 2016].

[65] D. G. a. B. Totty, "Secure HTTP," in HTTP - The definitive Guide, O'Reilly, pp. 307-336. [66] "HTTPS Client Authentication," [Online]. Available: https://docs.oracle.com/cd/E19226-

01/820-7627/bncbs/index.html. [Accessed 25 05 2016]. [67] "Google Cloud Messaging," [Online]. Available: https://developers.google.com/cloud-

messaging/. [Accessed 25 05 2016]. [68] "Push notifications for Windows Phone 8," [Online]. Available:

https://msdn.microsoft.com/en-us/library/windows/apps/ff402558(v=vs.105).aspx. [Accessed 05 06 2016].

[69] "Challange-response authentication," [Online]. Available: https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication. [Accessed 04 06 2016].

[70] F. K. Schneier, "Security Properties," in Cryptography Engineering, Wiley Publishing, 2010, pp. 101-102.

[71] "Advanced Encryption Standard - Wikipedia, the free encylopedia," [Online]. Available: https://en.wikipedia.org/wiki/Advanced_Encryption_Standard. [Accessed 06 08 2016].

[72] "Keychain Services Concepts," [Online]. Available: https://developer.apple.com/library/mac/documentation/Security/Conceptual/keychainServConcepts/02concepts/concepts.html#//apple_ref/doc/uid/TP30000897-CH204-TP9.


[Accessed 06 08 2016]. [73] "Android Keystore," [Online]. Available:

https://developer.android.com/training/articles/keystore.html. [Accessed 04 06 2016]. [74] "How to encrypt data for Windows Phone 8," [Online]. Available:

https://msdn.microsoft.com/en-us/library/windows/apps/hh487164%28v=vs.105%29.aspx?f=255&MSPPError=-2147217396. [Accessed 06 08 2016].

[75] "Bouncy Castle specifications - Section 6.4 Keystore," [Online]. Available: http://www.bouncycastle.org/specifications.html. [Accessed 06 08 2016].

[76] "Computer security - Wikipedia the free encyclopedia," [Online]. Available: https://en.wikipedia.org/wiki/Computer_security#Eavesdropping. [Accessed 07 08 2016].

[77] "Security Concerns with NFC Technology," [Online]. Available: http://nearfieldcommunication.org/nfc-security.html. [Accessed 07 08 2016].

[78] M. S. F. Kortvedt H. S., "Eavesdroppping Near Field Communication," The Norwegian Information Security Conference, pp. 57-68, 2009.

[79] B. K. Haselsteiner E., "Security in Near Field Communication (NFC) - Strengths and Weaknesses".

[80] O. K. O. B. Coskun V., Near Field Communication (NFC): From Theory to Practice, Wiley, 2012.

[81] "Relay attack - Wikipedia the free encyclopedia," [Online]. Available: https://en.wikipedia.org/wiki/Relay_attack. [Accessed 07 08 2016].

[82] "Play Framework - Build Modern & Scalable Web Apps with Java and Scala," [Online]. Available: https://www.playframework.com/. [Accessed 12 08 2016].

[83] "Hibernate. Everything data. - Hibernate," [Online]. Available: http://hibernate.org/. [Accessed 12 08 2016].

[84] "Twirl is the Play 2 templating language," [Online]. Available: http://www.scalatra.org/2.4/guides/views/twirl.html. [Accessed 12 08 2016].

[85] "Digital Voices GitHub repository," [Online]. Available: https://github.com/jonasrmichel/digital-voices. [Accessed 14 08 2016].

[86] "Digital Voices Wiki," [Online]. Available: https://github.com/jonasrmichel/mobile-acoustic-modems-in-action/wiki/Wiki. [Accessed 14 08 2016].

[87] "Mobile device management - Wikipedia the free encyclopedia," [Online]. Available: https://en.wikipedia.org/wiki/Mobile_device_management. [Accessed 15 08 2016].

[88] G. T. N. H. J. J. G. D. Oliveira J., "Blind People and Mobile Touch-based Text-Entry: Acknowledging the Need for Different Flavors".

[89] "Should I use QR code? Probably not! Here's why not to use QR codes," [Online]. Available: http://dotmonster.co/blog/ditch-they-qr-codes-dude. [Accessed 15 08 2016].

[90] "Install Sophos Mobile Control on iOS," [Online]. Available: http://tech.rochester.edu/tutorials/install-sophos-mobile-control-ios/.

[91] "Sophos Mobile Control," [Online]. Available: https://www.sophos.com/en-us/products/mobile-control.aspx. [Accessed 15 08 2016].

[92] "WCAG 2.0 Quick Reference," [Online]. Available: https://www.w3.org/WAI/WCAG20/quickref/. [Accessed 19 08 2016].


[93] "IDI Web Accessibility Checker," [Online]. Available: http://achecker.ca/checker/index.php. [Accessed 19 08 2016].

[94] "ISO 7816-4," [Online]. Available: http://www.embedx.com/pdfs/ISO_STD_7816/info_isoiec7816-4%7Bed2.0%7Den.pdf.

[95] L. T. K. Nielsen J., "A Mathematical Model of the Finding of Usability Problems," Proceedings of the INTERACT'93 and CHI'93 conference on Human factors in computing systems, 1993.

[96] J. Nielsen, "Why You Only Need to Test with 5 Users," [Online]. Available: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/.

[97] "Accessibility and Usability at Penn State | Redirects and Other Timed Responses," [Online]. Available: http://accessibility.psu.edu/redirects/. [Accessed 13 02 2017].

[98] A. W. W. T. M. L. I. C. Chetwyn C.H. Chan, "Modified automatic teller machine prototype for older adults: A case study of participative approach to inclusive design," Applied Ergonomics, vol. 40, pp. 151-160, 2009.


11. List of figures

Figure 1: The user starts by selecting one of the predefined disability types. .............................. 7 Figure 2: The user answers additional questions about his accessibility needs and preferences. 8 Figure 3: Once the user profile is finalized, a new bank card has to be ordered that can later be used at compatible ATMs to adapt the ATMs interface according to the user profile. .................. 8 Figure 4: The ATMs interface is adapted to the user’s needs according to the user profile stored on the bank card [41]. ................................................................................................................. 8 Figure 5: Buying the ticket with the mobile web application of APSIS4all [41]. ............................ 9 Figure 6: The user buys the ticket online using the web app shown in Figure 5, receives the QR code and scans the QR code at the ticket vending machine to receive his ticket [41]. ...............10 Figure 7: With INREDIS, a mobile device is used to control the ATM remotely [42]. ..................11 Figure 8: NFC capable ATM in Austria [50]. ...............................................................................14 Figure 9: Another NFC capable ATM in Austria [51] ..................................................................14 Figure 10: Basic interaction model for the ATM. .........................................................................17 Figure 11: Most of the interaction with an ATM could be virtualized on an alternative platform like a PC or a mobile device. ............................................................................................................18 Figure 12: Some parts of the ATM interaction cannot be decoupled and the user is forced to be physically present at the ATM at the time of the interaction as transaction of money is involved. ..................................................................................................................................................18 Figure 13: The identification, authentication and input steps can be shifted to an alternative platform entirely, but their results have to be transferred to the ATM at the time of the interaction. The confirmation step can be shifted to another platform, but the user has to be physically present at the ATM at the time of the confirmation. The transaction step happens entirely at the ATM. ..........................................................................................................................................19 Figure 14: Step 1: Preparing the interaction in the personal accessible environment. ................20 Figure 15: Step 2: Executing the prepared interaction at the ATM using the two-tap workflow of TokenAccess. ............................................................................................................................20 Figure 16: A blind user in his personal accessible environment [54]. .........................................22 Figure 17: A quadriplegic user in his personal accessible environment [55]. ..............................23 Figure 18: A mobile device can function as the personal accessible environment as well if the accessibility tools of the platform satisfy the user’s needs [56]. ..................................................23 Figure 19: Mobile devices can also be extended to fulfill the user’s accessibility needs, although the possibilities are more limited compared to PCs. What you see here is a mobile device on the lap of the user and a Bluetooth refreshable display connected to it [56]. ....................................24 Figure 20: Abstract representation of a token that is stored on the mobile device. .....................25 Figure 21: Mobile device touches the ATM for the first time. ......................................................27 Figure 22: Mobile device touches the ATM for the second time. ................................................28 Figure 23: The “deposit money” operation – the mobile device touches the ATM for the first time. ..................................................................................................................................................30 Figure 24: The “deposit money” operation - mobile device touches the ATM for the second time. ..................................................................................................................................................31 Figure 25: Buying a tram ticket with TokenAccess: First touch. ..................................................33 Figure 26: Buying a tram ticket with TokenAccess: Second touch..............................................33 Figure 27: The components of the TokenAccess architecture and the communication channels between them. ...........................................................................................................................34 Figure 28: Securing the communication channels. .....................................................................37 Figure 29: HTTPS with client authentication [66]. .......................................................................38


Figure 30: The API key authenticates the server application to GCM. ....................................... 39 Figure 31: Registering the mobile device in GCM. ..................................................................... 40 Figure 32: Sending a GCM push notification from the TokenAccess server to the mobile device. .................................................................................................................................................. 40 Figure 33: Challenge-response based mutual authentication between the ATM and the mobile device. ....................................................................................................................................... 43 Figure 34: Key exchange between the ATM and the mobile device. .......................................... 45 Figure 35: Encryption of the token ............................................................................................. 46 Figure 36: The token is signed when it is created on the TokenAccess server. ......................... 47 Figure 37: Online verification of the token.................................................................................. 48 Figure 38: Class diagram for the models package..................................................................... 56 Figure 39: Class diagram for the controllers package. .......................................................... 57 Figure 40: Enrollment email in an MDM application (Sophos Mobile Control) [90] [91]. The user can connect his mobile device by either scanning the QR code or entering the enrollment information manually. ................................................................................................................ 60 Figure 41: Audio-based device configuration: The mobile device receives the configuration information with audio that is played over the PC speakers. ...................................................... 60 Figure 42: The device configuration page in the TokenAccess web application. When the user clicks the "Connect device" button, the audio message containing the configuration information like the server URL and the device id is played in the web browser. The mobile device listens to this audio stream and receives the configuration information this way. ...................................... 61 Figure 43: Sequence diagram for audio-based device configuration.......................................... 61 Figure 44: The "dashboard" right after the user's mobile device is connected to TokenAccess. 62 Figure 45: Currently, three different operations are implemented in the prototype: Withdrawing and depositing money for the ATM and buying tram tickets for a ticketing machine. ................. 62 Figure 46: Operation details for a "withdraw money" token. The user can choose the amount to withdraw and how many times this token can be used. In this case, the token expires after one single use. ................................................................................................................................. 62 Figure 47: A confirmation screen is shown with the details of the token. Once the user clicks the “Create token” button, the token is created and sent to his device. ............................................ 63 Figure 48: The “dashboard” after creating the token for withdrawing money. ............................. 63 Figure 49: The user can have multiple tokens on his device, but he can only have one token for each self-service terminal type on the device. This is required so that the user does not need to choose the token on the device manually at the self-service terminal. Here, you can see that the user has stored both an ATM token for withdrawing money and a ticketing machine token on his device. ....................................................................................................................................... 63 Figure 50: Sequence diagram for creating a new token on the TokenAccess serve .................. 64 Figure 51: The TokenAccess client application. There is no classical GUI, instead the user interacts with the client application via touches and gestures and gets audio feedback. ............ 66 Figure 52: On the left: Card emulation via a secure element. On the right: Host-based Card Emulation [63]. .......................................................................................................................... 67 Figure 53: Class diagram for the client package..................................................................... 68 Figure 54: Class diagram for the package crypto. ................................................................... 69 Figure 55: Class diagram for the package gcm. ........................................................................ 70 Figure 56: The AID (application id) has to be defined in an own file called ais_list.xml in the folder “res”. It is through this AID that the Android OS knows which application to forward the commands from the NFC reader to. .......................................................................................... 71 Figure 57: Class diagram for the package servercomm. ........................................................... 72


Figure 58: Class diagram for the package token. The TokenStorage class depends on the TokenEncrpytion class for encrypting the tokens before storing them. The ClientActions class depends on the TokenStorage class for adding and removing tokens from the device when it receives the corresponding command from the TokenAccess server. ...........................72 Figure 59: Sequence diagram of the client application decoding the enrollment message from the web browser. .......................................................................................................................74 Figure 60: The enrollment task in detail. ....................................................................................75 Figure 61: Encrypting and saving a new token. ..........................................................................76 Figure 62: Retrieving (and decrypting) a token...........................................................................76 Figure 63: ATM simulation running on an Android tablet. ...........................................................77 Figure 64: A ticketing machine is also simulated to showcase how the TokenAccess workflow could be applied to other self-service terminal types. .................................................................78 Figure 65: Class diagram for the package atm. .........................................................................80 Figure 66: The ATM simulation Android application needs to declare in the manifest that it requires the NFC permission and that it uses the NFC hardware feature. ..................................81 Figure 67: The ATM simulation Android application also needs to have a file called nfc_tech_fitler.xml in the res/xml folder that declares IsoDep in the supported tech list. ..81 Figure 68: Class diagram for the package nfc. .........................................................................82 Figure 69: Class diagram for the package crypto. ...................................................................83 Figure 70: Example of an ATM to mobile device communication. In this example, the token on the user’s device is a token for the operation “withdraw money” and has a value of “30 Euros”. Error handling is omitted for the sake of simplicity. ....................................................................87 Figure 71: The JSON representation of the token that is sent as a byte array to the ATM. ........89



Additional credits

� Icons used in the figures Figure 9 & Figure 12: credit cards by hunotika from thenounproject.com Pin Code icon by Oliviu Stoian from thenounproject.com Keypad icon by Creative Stall from thenounproject.com confirm or deny icon by Icon Island from thenounproject.com Money” icon by joe pictos from thenounproject.com

Figure 10: Computer by Martin Vanco from thenounproject.com Smartphone by Aaron K. Kim from thenounproject.com Figure 13 & Figure 14: Person by Javier Cabezas from thenounproject.com Computer by Martin Vanco from thenounproject.com Browser by Fritz from thenounproject.com servers by Creative Stall from thenounproject.com Smartphone by Aaron K. Kim from thenounproject.com Figure 14: Person by Javier Cabezas from thenounproject.com Smartphone by Aaron K. Kim from thenounproject.com ATM by Korawan. M from thenounproject.com

� Icons and graphics used in the TokenAccess prototype

The TokenAccess icon and the graphics in the ATM simulation application: Marlene Larndorfer

� Acoustic modem code

The TokenAccess web application and the TokenAccess Android client make use of code from the Digital Voices project3 which is MIT licensed. The code is used to for audio based device configuration via acoustic modems, as explained in “Chapter 8: Prototype implementation”.

3 https://code.google.com/archive/p/mobile-acoustic-modems-in-action/ https://github.com/jonasrmichel/digital-voices

https://code.google.com/archive/p/mobile-acoustic-modems-in-action/

https://github.com/jonasrmichel/digital-voices


Personal Information

Day of birth 06.10.1984

Citizenship Turkey

Email [email protected]

Education

2012 – 2017 Computer Science Master‘s Program, JKU Linz

Expected graduation spring 2017

2004 – 2012 Computer Science Bachelor‘s Program, JKU Linz

2003 – 2004 Diploma Program Mechatronics, JKU Linz

1995 – 2003 High School St. Georgs-Kolleg, Istanbul

Languages

Turkish Native speaker

German Very high level of written and spoken German

English Very high level of written and spoken English

Work Experience

2014 – 2015 Student worker Quality Assurance, Sophos Linz

2015 – now Quality Assurance Engineer, Sophos Linz

Miscellaneous

August 2013 First place at Project Possibility SS12 2013 European Coding

Competition (Development of a braille keyboard for Android)

Curriculum Vitae

Emre Zaim

Statutory declaration

I hereby declare that the thesis submitted is my own unaided work, that I have not used other than the sources indicated, and that all direct and indirect sources are acknowledged as references. This printed thesis is identical with the electronic version submitted. Linz, Date Signature

Documents

TRANSFERRING ATM INTERFACE AND INTERACTION TO