Usable Security - DiVA portaluu.diva-portal.org/smash/get/diva2:943682/FULLTEXT01.pdf · 2016-06-28 · Usable Security A seamless user authentication method using NFC and Bluetooth

IT 16045

Examensarbete 30 hp22 Juni 2016

Usable SecurityA seamless user authentication method using

NFC and Bluetooth

Benjamin Langlotz

Masterprogram i människa-datorinteraktionMaster Programme in Human-Computer Interaction

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

Usable Security - A seamless user authenticationmethod using NFC and Bluetooth

Benjamin Langlotz

Currently, the majority of user authentication procedures for computers, web services or software involve typing user names and passwords. Passwords which should have a reasonable complexity to be considered secure. The securest password, however, does not guard a user's data if she does not log out when leaving the computer.

The research question posed in this thesis is "How should a user authentication method be designed to automate login/logout and to mitigate negative effects of lacking security awareness?". Based on this question, the goal of this work is to develop a new solution for user authentication with NFC and Bluetooth, that takes care of logging in and out of computers and services without the user having to lose a thought about it. This is done by first looking at currently existing alternatives to password authentication. Secondly, the qualities and requirements of a new user authentication concept are devised and described. Thirdly, a testable prototype called NFCLogin, implementing the key aspects of logging in and logging out of Google chrome as well as saving and reopening of the user's opened tabs is implemented. Finally, an observational assessment test is conducted. The aim of the study is to get a hint about whether the system could be useful, if users are inclined to trust it and in which way it could be improved.

The main outcome of this thesis is the definition of a user authentication method coupled with suggestions for improvement gathered from a usability study, conducted with the method's prototype, NFCLogin. An important take away from the study is that participants seem to appreciate the prototype and are likely willing to use the proposed method, if it is sufficiently secure.

Tryckt av: Reprocentralen ITCIT 16045Examinator: Justin PearsonÄmnesgranskare: Lars OestreicherHandledare: Martin Jacobsson

Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1 Aim of this thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Scope & Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1 Authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.1 Automated screen locking with Bluetooth . . . . . . . . . . . . . . . . . . . . . 122.1.2 Contactless Smart cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.3 Biometric login methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Alternative technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.1 Google ”Authentication at scale“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 MazeMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Theory of Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1 Qualities of an ideal solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.1 Ideal log in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.2 Ideal log out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.3 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.5 Usability & Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.6 Qualities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.1 Means of identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.2 Near Field Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.3 Android Beam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.4 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.5 WebSocket protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.6 Proximity measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Falsification Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Prototype Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.1 Smartphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.1.2 NFC & Bluetooth Dongles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Prototype’s System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.1 Android Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.2 Java Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2.3 Chrome Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2.4 Used Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Problems with Software/Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3.1 NFC on Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3.2 RSSI measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3.3 Bluetooth or Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.1 Usability testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2.1 Pre-test questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.2 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.3 Post-test interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2.5 Reflections on Method & Problems with testing . . . . . . . . . . . 505.2.6 Changes that should be considered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2.7 Ethical considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6 Conclusion & Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.2.1 Use NFC to transfer credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.2.2 Google 2-step verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.2.3 Phone sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.2.4 Different distance measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.2.5 Features and improvements suggested from user

testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.2.6 More testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7

1. Introduction

If one looks at the user authentication procedures of computers, web servicesor software, the majority of them involve typing a user name and password.Passwords none of which should be the same as the other, and all of whichhave to be remembered by the user. To achieve a certain grade of security it isfurthermore important that those passwords are reasonably complex [1]. Themost secure password, however, does not guard sensitive data if the user isnot logged out when leaving her computer. This implies that to keep her dataprotected, a user has to log out whenever she leaves her computer and back inagain when she comes back. Because storing the password on the computer isnot an option as it defies the meaning of it, she always has to log in by typingit manually.

There are lines of work in which employees only partly work with com-puters or workstations and partly have to do physical work, such as nurses,waiters and librarians. This means that those users – if they want their dataor their company’s data to be secure – have to log out every time they leavetheir workstation and log back in again when they return. This combined withthe requirement of having a secure password makes this process quite time-consuming in one’s work day.

1.1 Aim of this thesisThe research question this thesis tries to answer is "How should a user authen-tication method be designed to automate login/logout and to mitigate negativeeffects of lacking security awareness?".

Based on this research question, the general aim of this work is to develop anew solution for user authentication and explore its aspects and requirements.The method should incorporate automatic login and logout so that it is possi-ble for the user to just walk up to her computer to use it and walk away fromit again when she is done. Without having to think about having to log in andout, the solution should take care of it so that her data is safe. This is expectedto help security aware users by smoothing their workflow and especially usersunaware of security by making sure they are logged out and taking away thehassle of logging in. The technologies that should be used are Bluetooth andNear Field Communication (NFC), which is a wireless communication tech-nique for shorter distances (explained more in section 3.2.2).

9

Given the general aim, the thesis can be structured in three sub goals. Firstof all, a new method of user authentication id defined with a Theory of Use(ToU, proposed by Laaksoharju [2]) containing specifications and use cases.The second goal is to design and develop a prototype that could be used asa proof of the previously specified concept. Last but not least, the prototypeand the assumptions made in the ToU will be tested in a usability study to getinsights about whether the system could be useful, if users are likely to trust itand how it could be improved.

1.2 Scope & DelimitationsThe scope of this thesis is limited to making a theoretical concept for a newuser authentication method, developing a prototype of one aspect of the con-cept and testing it in a small usability study. Technologies that should be in-cluded were NFC and Bluetooth. The prototype was not expected to resemblea full-fletched implementation of the concept, but rather required to be able tolog in and log out a user using one service as a proof of concept. That meansthat it was not required to have software for management tasks such as pair-ing devices, setting up services or settings. During the development phase ofthe thesis the scope shifted a bit due to technical restraints, e.g. did an initialproject plan not require the usage of Bluetooth.

Whereas the general concept proposed in this thesis can be applied to all op-erative systems, it was decided to limit technical research as well as prototypefunctionality to Microsoft Windows 7.

Although this thesis is undoubtedly quite technical it should still be countedtowards the area of Human-Computer-Interaction as the main topic is to testthe feasibility of a more user-friendly authentication method.

The most important work to continue after this thesis is to implement thesuggestions gathered from the usability study as well as doing a larger, moreextensive study on the product.

1.3 OutlineThe next parts of this thesis are organized into related work, Theory of Use,prototype implementation, evaluation, conclusion and future work. The chap-ter on related work will introduce concepts and software that is in differentways related to this thesis while stating the difference in the approach of theconcept proposed in this thesis. In the part titled Theory of Use, a descriptionof qualities, requirements and possible technical solutions for the proposedauthentication method are described. The implementation of a prototype forthis concept is covered in the following chapter. The usability study including

10

results and discussion are included in the chapter "Evaluation". The documentends with a conclusion and plans for future work.

11

2. Related Work

This chapter will introduce some concepts and technologies that are related tothe login and logout concept as well as the prototype proposed in this thesis.

2.1 Authentication methodsIn this first part, different methods of logging in and logging out are discussedand evaluated based on their advantages and drawbacks.

2.1.1 Automated screen locking with BluetoothBlueProximity [3], BTProximity [4], TokenLock [5] and KeyCard [6] are allprograms for different operating systems that automate screen locking. Com-puters that have Bluetooth support can pair up with a mobile phone. Thoseprograms then infer the distance between the computer and the mobile devicevia the signal strength. If the distance exceeds a certain value, the screen islocked with the usual screen saver. As soon as the mobile phone is registeredin a range lower than the threshold, the computer is unlocked.

While these systems take care of locking the user’s computer based on herdistance to the computer and unlocking it when she comes back, they don’tcover the initial log in. Their use case is based on the assumption that a com-puter is used by one user who logs in in the beginning of the session and thenstarts the software that will lock the screen when she leaves. This solutiondoes not work for a set of workstations that are supposed to be used by inter-changing users during the course of a day.

2.1.2 Contactless Smart cardsContactless smart cards can not only be used to get access to buildings or se-curity areas, but also for log in at computers, one example for home computersbeing EIDAuthenticate by MySmartLogon [7]. The used cards have the size ofcredit cards and are thus very portable. Besides authorization and identifica-tion they can also be used for payment. The radio frequency technology usedin these cards is similar but not entirely the same as Radio-frequency Iden-tification (RFID). Both this technology and RFID use electromagnetic fieldsfor data transfer. As the energy needed to read information on a smart card is

12

generated by said electromagnetic field from the card reader, they can neverrun out of battery [8]. Whereas contactless smart cards are readily available,this solution has several drawbacks. Firstly, the user would have to carry anadditional object with her that should not be lost or forgotten. Secondly, thelogout does not happen automatically, the user still has to do it herself, whichdecreases her data’s security as it could be forgotten. Thirdly, upon logout itis not possible to store metadata on the card.

2.1.3 Biometric login methodsHere a few biometric login methods that use different body parts for user au-thentication are introduced and discussed.

Login with fingerprint recognitionFingerprint readers are able to substitute password login on Windows com-puters. Some laptops already come with an inbuilt fingerprint reader, otherdevices can be equipped with an external reader [9]. While using one’s finger-print instead of typing a password probably speeds up the process of loggingin, given that the reader reads fast and without error, there are a few downsidesto this system. For once, it is not possible to use log in via fingerprint scanningwhile wearing gloves, which makes login impossible for certain usage situa-tions in which one has to wear hand protection. Furthermore, the log out doesnot happen automatically, which reduces security.

Login with facial recognitionSince Windows 10, the operating system has built in support for biometric au-thentication methods such as iris or facial recognition. The software requiresa camera to work [10]. However, not any webcam can be used for recognition,it has to be one that includes infrared technology, making it mostly a solutionfor Windows’ own devices or newer laptops [11].

A software that can be used for earlier Windows versions is KeyLemon,which basically has the same functionality [12]. The paid version of KeyLe-mon is actually the only of the authentication methods presented here, that canboth log in and log out a user.

While Windows’ solution does not support automatic logout, KeyLemondoes support it, but only in the paid model. Furthermore, neither situationallows the saving of metadata upon log out and neither can be used in usagesituations in which one has to wear something on one’s face (e.g. a shawl inwork places outside).

Login with hand recognitionBattelle SignWave Unlock, introduced in 2013 [13], was software based onthe Leap motion [14]. It could be added to the normal Windows or Mac login

13

screen as alternative to password login. To log in the user had to hold her handover the connected leap motion controller. The software then compared theuser’s hand to a previously saved model of the hand. Although this seemed tobe a neat idea, a review on the internet [15] reported of incidents where a usercould unlock her computer with somebody else’s hand. With traces of it onlyfound in Leaps community foru, the software was finally taken of the market[16].

While this software sounded incredibly easy to use the fact that it had severesecurity problems and that the company itself even stated that false positiveswere possible [17] probably lead to that it was taken of the market.

2.2 Alternative technologyHere, alternative technology that in some or other way is related to the pro-posed solution is presented.

2.2.1 Google ”Authentication at scale“In their paper “Authentication at scale” [18], Grosse and Upadhyay give alimited insight in Googles research on two-factor-authorization. Google’s ap-proach is, in contrast to let people log in from different devices, to grant rightsto devices, such as login or accessing a Google account. The difference isthat the user can view a list of connected devices or applications and revokethe rights if the device is lost or misused, which is called "device-Centric Au-thorization". To make this authorization secure but easy, Google chose a twostep verification process, with which it is possible to permanently authorize adevice. Hereby, every new device needs to be assured by a code, generated ona trusted device.

To increase the security, Google is looking into asymmetric or public-keycryptography used with smartcard-like USB tokens. A removable USB tokenwould be used to authenticate a new device. While these USB tokens havea clear mental model, much like a common door key, they are probably a bitcumbersome to use, partly because it is an additional device to carry around.This is why Google is thinking about integrating that system into jewellery(e.g. a finger ring) or smartphones, although they aim at making authentica-tion possible even when the trusted device does not have cellular connectivity.To achieve this, Google is experimenting with unsecured radio frequency com-munication and NFC.

2.2.2 MazeMapIndoor navigation is not per se directly related to automatic user authentica-tion, however if one thinks of the technology behind it, the connection be-

14

comes apparent. The solution proposed in this thesis decides whether to logout a user based on the user’s distance to a terminal. This distance has tobe measured and therefore the user’s position has to be known. To be ableto help a user find their destination, a navigational app also has to infer thecurrent location of the user. MazeMap [19] is such an application that usesWiFi trilateration, which measures the signal strength between the user’s mo-bile phone and 3 access points, to calculate the user’s position to an accuracyof 5-10 meters. While that accuracy is not incredibly high in the context ofa secure log out mechanism, it works to decide whether the user is inside acertain room or not, which could add useful information to a solution’s log outlogic [20].

15

3. Theory of Use

In his doctoral thesis "Designing for Autonomy" [2], Mikael Laaksoharju for-mulated a protocol that, if followed, results in a Theory of Use (ToU). A ToUcontains a specified problem that the designer attempts to solve as well as herthoughts on qualities a good solution should have. Furthermore it includes as-sumptions about possible users and use cases. This constitutes the designer’sTheory of Use for the artefact and by presenting it to users one can attempt tofalsify the different statements it consists of.

In this chapter, the author will attempt to formulate such a Theory of Usefor the wireless log in solution proposed in this thesis. Section 3.1 gives anoverview of the different qualities the concept should have. Following that,different technologies that could be used to implement the solution are pre-sented in the section "Model", 3.2.

The built prototype has, partly for technical reasons and partly because itwould exceed the scope of a master thesis, a few variations from this designwhich will be discussed in chapter 4.

3.1 Qualities of an ideal solutionThis section poses the author’s idea of different qualities an ideal wirelesssolution using a mobile authentication device to log in to a terminal shouldhave1.

In an ideal solution, the user would be able to log in at many differentcomputers or terminals with just one mobile device. Apart from their pri-vate computers, it could be library computers, shopping terminals (e.g. ICA,Willys2, IKEA), terminals at specific work places (e.g. hospital, warehouse,restaurant), computer rooms at the university or public computers that are sup-posed to be used by several users. Depending on the user and her status or userrole as well as the terminal and the context in which the terminal and the userreside right now, the system could be adjusted to automatically do differentthings.

If the user is an office worker and, at her place of work, goes to one of themany workstations there, she will be logged in into her personal account – herdesktop, folder structure and all her files will be loaded.

1In the rest of this text, "computer" and "terminal" are used interchangeably, as are "mobiledevice" and "authentication device".2ICA and Willy’s are big supermarket chains in Sweden.

16

If the user is working in a more specialized workplace in which employeesroutinely share the same terminal (e.g. a hospital or library), the user mightbe logged in to different programs or with different rights depending on whichrole the user has at the company. Taking a hospital as example, a caretakerwould, e.g., be logged in to another system than a nurse or a doctor.

When the user is going shopping (ICA/IKEA) and wants to check her per-sonal bonus account, she will be logged into that.

At the library, the system could start the last program she used at the librarycomputers or prepare for printing, depending on what she specified the defaultaction to be.

When using a terminal, the system could save metadata and reproduce themupon future log ins at the same terminal or ones of the same type. This could,taking the workplace example from above, be files that the user previouslyhad opened on a workstation. Storage of this metadata could be on the devicethe user carries around or on a server, which could enable the user to go todifferent workstations of the same type and get presented with the same screen.Advantages of device storage are that it works in areas without, or with limitedinternet connection. A disadvantage with that solution could be that, when theconnection between device and terminal is broken, it is no longer possible totransfer the latest set of metadata from the computer to the device.

3.1.1 Ideal log inAn ideal system would work in such a way that the user approaches the termi-nal and is immediately logged in without having to interact with the terminalor the authentication device. That means that either the system needs to knowwhen the user wants to log in or a sensor has to be positioned in such a waythat it is unmistakeably that the user wants to log in. This could, for example,be achieved with positioning sensors in spots that get close to areas in whichthe user is storing her mobile device. For example, for a scenario in whichthe user is sitting down, a sensor could be placed under the desk to recognizea device in the user’s pocket, one (or several) could be placed on the desk torecognize a device that is put on the table and one could be placed in the chairto recognize a device in the jacket/purse.

A compromise could be that the terminal displays a question, e.g. “Do youwant to log in?” when the user is coming close and then she can click orconfirm that question with a single press of a key or tapping a screen, withouthaving to enter a password or something similar. A prerequisite for this wouldbe that the question cannot come up when the user is not aware of it, i.e. itshould not easily be possible for somebody else to log in to a workstation justbecause the user is standing close. This is a security risk because it could befairly easy to distract the user while she is standing close to a terminal.

17

3.1.2 Ideal log outSimilar to the way the ideal system would log a user in to a terminal, the logoutshould happen automatically when the user moves away from the workstation.Hereby it is important that the user is not logged out when she actually wantsto continue using the terminal. This could be achieved by measuring and ana-lyzing the distance between the user and the terminal and logging the user outwhen she has moved a pre-defined distance away from the terminal.

Depending on what kind of workstation the user is signing into, the defaultbehaviour when leaving the terminal could be to lock the screen instead oflogging out the user. This might be handy in environments in which the usercan or needs to use different workstations every day but will return to thesame frequently during a day or a certain span of time. It could be possibleto "claim" a workstation in the morning and thus becoming its main user for aday.

3.1.3 SettingsTo set up the system there should be a management program in which the usercan add authentication devices that are allowed to log in to certain computersor services. It should be possible to add several devices and several services,e.g. the user should be able to use device A to login to service 1 and 2 anddevice B just to login to service 1. There also needs to be a possibility to deletea mobile device from a service as well as to block a device from all services incase the user lost her authentication device or is changing to a new one. Whenchanging to a new device, it should also be possible to take over settings froman old device so that the user does not have to connect a new authenticationdevice to all the services by hand. For each service, it should be possible tospecify the distance at which the user is to be logged out. For some services agreater distance might be required than for others to not accidentally be loggedout.

3.1.4 SecurityThe solution aims to get as little in the user’s way as possible but as it is asoftware to log in and log out, it has to have a security level that is as highas possible to be viable. The solution should be as secure as passwords thatare changed with reasonable frequency without actually requiring the user toremember or enter those passwords. This means that it should be fairly easy tochange the password in the service as well as in the app/management software.

To ensure security, it is not only important that the mobile device holds thepassword to the service, but also that it is a trusted device and allowed to login to a certain service. It should not be possible to use another device to imper-sonate a trusted one. At the same time, the terminal has to be authenticated as

18

well to prevent that a malicious terminal is posing as a trusted terminal (simi-lar to Wireless network certificates).To be secure, the password has to be transferred in a safe way using an en-crypted and secure channel.To prevent further harm in case an authentication device or computer is stolen,it should be possible to set devices as untrusted from both sides.

3.1.5 Usability & TrustWhile being a concept for a log in method and thus requiring a high level ofsecurity, the uttermost thought with this concept is to take the process of log-ging in from the users mind. Therefore, a perfect solution should not have tobe used during log in and log out and would disappear into the background.Not giving the user something to use, however, should not result in her losingcontrol of the situation. The user should feel that the system does what shewants and she therefore can trust the system. This is why it has to be madesure that the system correctly understands when the user intents to log in andwhen she is just passing by a terminal. Respectively, the solution should beable to infer when the user is leaving the terminal and wants to log out anddiscern it from e.g. a shift in body positioning. At the very least, the systemshould give the user unobtrusive feedback when she is walking away from theterminal and logged out automatically so that she does not have to watch theterminal for feedback.

The parts of the system that require a user interface, e.g. setup, settings andtrusting/untrusting devices, should be self-explainable and easy to use in casethe need arises.

3.1.6 QualitiesTo sum up this chapter, the solution should have the following qualities:

• Q1 - The solution works with different services.• Q2 - It takes care of automatic login.• Q3 - It takes care of automatic logout.• Q4 - It is secure.• Q5 - It saves and loads metadata.

3.2 ModelAs part of the Theory of Use, this section will take a look at different technolo-gies that could be used for the proposed solution. To put this into a context it

19

is important to look at the assumptions the author made about the users of theconcept:

Users of the proposed solution want to or have to secure their data. Theyare willing to carry a device with them at all times and are willing (or evenprefer) to log in with said device instead of passwords.

3.2.1 Means of identificationTo be able to automatically log in to different terminals without having to typea password, something else is required: an additional device either unobtrusiveand likely to be carried around or a device that the user already owns whichcan be used for this purpose. It should be equipped with technologies thatfacilitate wireless communication and identification at terminals. One devicethat most people have that could take over this role is a smartphone. Therest of this chapter is written under the assumption that the mobile device is asmartphone.

3.2.2 Near Field CommunicationNear Field Communication (NFC) is a wireless technology that works overshort distances. Strictly speaking, NFC is a set of technical standards andspecifications based on radio frequency fields with 13.45 MHz. This is thehigh-frequency (HF) wavelength of RFID which makes NFC compatible witha large amount of RFID devices and cards. As opposed to RFID tags whichcan have a large reach, NFC’s reach ranges between 3 and 5 centimeters.

NFC requires the initiator of a connection to emit a radio wave and thuscreating a field which the target enters. Upon entering the field, the target isactivated. Both stationary and mobile devices can function as initiator andtarget [21].

The small range of NFC as well as it’s one-to-one transmission charactermakes it more secure than, for example, Bluetooth or Zigbee [22]. As it onlyneeds little power and thus is very battery friendly it makes it an ideal candi-date for the proposed solution.

A non-profit founded by Philips, Sony and Nokia called NFC forum [23]develops and maintains NFC-related standards and specifications with the aimto ensure and enhance interoperability between devices and applications. Rel-evant for this thesis is the NFC Data Exchange Format (NDEF). This specifieshow data can be transferred from one NFC-enabled device to another. NDEFmessages consist of a series of records which hold the content and meta dataabout the content.

The two main standards included in NFC are ISO 18092 [24] and ISO21481 [25].

20

3.2.3 Android BeamWith Android Beam, a user can easily share pictures, URLs or other data viaNFC. To, for example, send a picture, the user just opens the file in question ontheir phone and then holds the device close to another mobile phone. As soonas the other machine is recognized, the screen warps into the Beam interface.All the user has to do is to tap the screen and the picture is transfered to theother phone. While the exchange is always initiated via NFC, the element thatis to be sent is transferred either via NFC or, in case the file exceeds a certainsize, via Bluetooth. Elements just consisting of text, e.g. URLs, are almostinstantly sent via NFC.

3.2.4 BluetoothBluetooth [26] is a cheap wireless technology that was invented to connectdevices over a short distance, as substitute for cables. Its nominal range is 10meters. It utilises piconets and has a master-slave system. Each piconet con-tains one master and up to seven slaves [27]. Being a slave is more resource-intensive than being a master as the slaves have to listen for incoming contactrequests all the time. Although both masters and slaves can initiate a connec-tion, it is usually the master who is the initiator.

Bluetooth conform devices have to follow the rules of the Bluetooth Spe-cial Interest Group (SIG), which also observes the advancement of Bluetoothstandards [28].

As Bluetooth has a larger range than NFC, it could be used for this userauthentication method to allow a greater distance between the terminal andthe user’s mobile device while still maintaining a connection.

3.2.5 WebSocket protocolThe most recent technique presented in this thesis is the WebSocket protocolwhich was developed as part of HTML5. It utilizes TCP connections and has ahandshake similar to HTTP, which enables web servers to use the same port asfor HTTP connections. As it provides full-duplex real-time communication itwas a perfect candidate for handling the communication between applications.It is possible to secure a WebSocket session by using it over TLS/SSL and fea-tures a messaging system called WebSocket Application Messaging Protocol(WAMP) [29].

3.2.6 Proximity measurementPart of the core of the proposed artefact is to determine when the user hasto be logged out of a terminal. For this to work, two things have to be in

21

place and work together. One prerequisite is the measurement of a value thatchanges depending on the distance between the authentication device and thecomputer.

In this paragraph it is assumed that the device for authentication that theuser carries with her is a smartphone. For the solution to work, the systemhas to infer the distance between the user and the terminal with an accuracy ofabout 1-3 meters (depending on the concrete use case).

There are different ways of measuring the distance between two devicesutilising wireless networks. The most common wireless network techniquesincluded in today’s mobile phones are WiFi, Bluetooth and NFC. NFC is notsuitable for distance measurement in this project as the reach of NFC is below10cm.3

As there are indoor navigation apps (cf. MazeMap in chapter 2) that utiliseWiFi, it would be possible to use WiFi to infer the distance between the twodevices. If the location of the phone and the location of the terminal is knownto the app, it would be possible for the user to specify on a map at about whichpoint she wants to be logged out. For example, the user could still be keptlogged in while being at the other end of the same room. There would bedrawbacks to including such a solution as well. As a system like MazeMaprequires a map of rooms and WiFi access points to work, there is a consid-erable amount of continuous management needed. Furthermore, whereas itwould theoretically be possible to pinpoint an exact log out location on themap, MazeMap only has an accuracy of about 5-10 meters, which could beenough for some use cases, but to inaccurate for others.

As can be seen in chapter 2, Bluetooth has been used for distance mea-surement before. Using Bluetooth, there are several ways to infer the distancebetween two devices. One way is to continuously send packets between theunits and track the packet loss. Through experimenting, a threshold could beset up that corresponds to a certain distance between the devices. Another waywould be to regularly check the Received Signal Strength Indication (RSSI) totry to infer a connection between signal strength and distance. This measure-ment could be improved if several Bluetooth antennas would be available asthis would give the possibility of triangulation.

3.3 Falsification CriteriaTo be able to test this ToU effectively with the prototype, some criteria thatimmediately falsify the theory were defined. Those are partly derived fromthe assumptions that have been stated earlier.

3Actually, as NFC is used to trigger the connection between the phone and the computer, it is ina way used for distance measurement. However, it can not be used to determine when the userhas to be logged out if the user should still be able to take away the phone from the NFC-readerto f.e. place a call.

22

The theory is considered falsified if...

• ...the prototype is hard to use.• ...carrying around and handling a device is against the normal behaviour

of most of the users.• ...neither the users nor the organizations that they belong to need to care

about login security.• ...all of the users leave the device when moving away from the terminal.• ...the users prefer passwords over the prototype.

23

4. Prototype Implementation

With the Theory of Use explained in the previous chapter, the author designedand implemented a prototype called NFCLogin. The purpose of this prototypewas to conduct successful user tests. This means that the author was satis-fied with a much more limited functionality than a commercial system wouldhave. Whereas an ideal product should be able to work together with severalservices, the service chosen for the proof of concept in this thesis is Googlevia the browser Chrome. Given those premises, the prototype was developedaccording to the following specifications and delimitations.

The prototype implemented in this thesis should fulfil the following specifi-cations. The corresponding qualities specified in section 3.1.6 are written inparentheses.

• Facilitate login to Google (Q1)• Log in by holding the phone to a sensor (Q2)• Keep the user logged in while the user is within a reasonable distance to

the computer• Log the user out once she moves a certain distance from the computer

(Q3)• Transfer credentials and information as securely as possible within the

restrictions of hardware, software and time (Q4)• Handle the user’s tabs (open on login, save on logout) (Q5)• It should be possible to use the prototype in a usability test with different

users

4.1 DelimitationsIn contrast to the design proposed in the previous chapter, the prototype devel-oped during the course of this thesis shows a few differences both due to limi-tations and reasonable simplifications. To have a secure product, it is vital thatthe credentials, which are stored on the mobile phone, are transferred as secureas possible. With the technology at hand, the most secure choice would havebeen NFC. In Android’s current implementation however, Beam (see section3.2.3) is the only way to send NFC messages to another entity. Due to Beam’sintended use case one can not send messages from the phone to another device

24

without user input. The whole problem is explained in section 4.3.1. This iswhy the prototype relies solely on the phone receiving information via NFCand all data that has to be sent from the phone to the computer is transferredvia Bluetooth.

Another drawback that changes the work flow of the system is that NFCis only enabled while the phone screen is unlocked. This means that the userhas to provide her fingerprint or enter a security pattern or a password on thephone prior to bringing it close to the computer’s NFC reader.

4.1.1 SmartphoneFor several reasons Android was chosen as operating system for the mobiledevice. First of all, the market share of smartphone operating systems since2012, shows that the two major players are iOS and Android with the latterone leading [30]. Secondly, if the author wanted to use NFC as a technology,iPhones were not an option as they are not equipped with an NFC chip usableby third party developers. The phone used for this thesis is a Google Nexus4, which has NFC and Bluetooth support and runs Android version 5.1.1 (API22).

4.1.2 NFC & Bluetooth DonglesThe communication between mobile phone and computer is triggered throughNFC (for an introduction to NFC see section 3.2.2), which is why the Com-puter had to be equipped with an NFC reader. There are a few possible deviceson the market which were considered. In the end a decision was made basedon their compatibility with different software libraries and operating systemsas well as their price.1 It was decided to buy dongles instead of the usuallyslightly bigger readers to make them easier to transport in case user testingwould be done with laptops that test persons have to carry around.

The two devices that were finally bought were the Identive SCL3711 NFCdongle [31] and the Sony RC-S360/S NFC dongle [32].

The secondary communication channel between mobile phone and com-puter, which greatly increases the systems range, is Bluetooth. As the de-velopment computer used was a stationary one without Bluetooth support, aBluetooth 4.0 dongle had to be bought. The decision criteria were the sameas for NFC. The device had to be small, cheap and compatible with existinglibraries and operating systems. Two Bluetooth dongles that also seemed tobe perfect for Linux2 were the IOGEAR Bluetooth 4.0 USB Micro Adapter

1The thought behind that was that it would be possible to buy a larger amount of devices foruser testing if they were cheaper. In the end, however, the study was designed in a differentway.2In the beginning of the project, hardware compatibility with Windows, Mac and Linux wasaspired.

25

(GBU521) 3 and the Plugable USB Bluetooth 4.0. However, both of themwere hardly available outside the US. The one that was bought in the end, abelkin Mini Bluetooth v4.0 Adapter [33], was easily available and turned towork out well.

4.2 Prototype’s System ArchitectureAs covered in section 4.1, the NFCLogin prototype implements a simplifiedversion of the concept introduced in the Theory of Use (see section 3). In thissection, the system architecture of the prototype built in this thesis will be ex-plained.

The prototype requires several different programs to cooperate as seen infigure 4.1. An Android App is running on the smartphone, which stores theuser’s login information. Prompted via an NFC connection, the computer tellsthe phone to open a Bluetooth connection. The user’s login information is thentransferred via Bluetooth to a Java program running on the computer. Java inturn is sending the credentials as well as a command to log in to Chrome via aChrome Extension and WebSockets.

As long as the Bluetooth connection is alive, the Java application derivesthe distance between the mobile phone and the computer based on RSSI mea-surement as explained in 4.2.2. When the distance crosses a certain thresholdor the connection dies, the Java application sends a command to the Chromeextension to log out the user. It also requests the user’s opened tabs from theChrome extension. Upon receiving of the tabs, the Java application saves themto a file.

The following subsections contain a closer look on the different parts of theNFCLogin prototype.

4.2.1 Android ApplicationDuring the time of programming the current Android version was 4.4. Thelast version the prototype was tested with was 5.1.1.

It is necessary to turn on both Bluetooth and NFC before the system canbe used with a terminal. To make this easier, the app checks during startupwhether NFC and Bluetooth are activated and prompts the user to do so if not.It is possible to present the user with a dialog (yes/no) if she wants to turnon Bluetooth or not, but NFC has to be activated in the phone’s settings. Foreasier handling, the correct settings page is opened and a notification promptsthe user to activate NFC in case it is disabled. The thought behind the promptsis that the app is started once before NFCLogin is supposed to be used (e.g. at

3The IOGEAR dongle recently seemed to have problems with bloatware and quality checking.

26

Figure 4.1. Overview of the different parts of the prototype. Prompted via NFC (1),the Android App initiates a Bluetooth connection to the Java Application. It sendsuser name and password via Bluetooth (2) to the Java Application. Then the JavaApplication sends the credentials (3) via WebSockets and tells the Chrome extensionto log the user in to Google (4). When the user should be logged out, a commandis sent from the Java application via WebSockets to Chrome and the user’s tabs aresaved. The black dotted line (as opposed to the grey dashed line) shows the path ofthe credentials. The arrows on the connections show the way information is sent.

the beginning of the testing session). When NFC is enabled and the phone isbrought in close proximity of the computers NFC reader, the phone will startup the NFCLogin app.

The Android Application is handling the Bluetooth and NFC communica-tion on the smartphone side. It saves the user’s Google credentials and is ableto send them via Bluetooth to a connected computer.The application is either already running or is started when the phone is heldto an NFC reader controlled by the Java Application (4.2.2). After initiatingthe Bluetooth connection via NFC, the communication between the devices iscontinued via Bluetooth. This is because it is not possible to send messagesto another device via NFC without user interaction, although it is possible toconstantly receive NFC messages with an Android handset. (As covered insection 4.1).

In figure 4.2, two screenshots of the Android app can be seen. The leftpicture shows the app’s view when started and waiting for a connection. Onthe right one can see the settings page in which the user’s Google usernameand password can be saved.

27

Figure 4.2. Left: Screenshot of the Android application showing the main screen withthe buttons "Terminate" and "Marker". The upper button will send a log out signal tothe computer and terminate the connection whereas the lower button will set a markerin the computers log. Right: Screenshot of the application’s settings page where theuser enters her credentials.

4.2.2 Java ApplicationThe prototype’s Java application functions as the spider in the net, connectingall the different parts of the software that are running on the computer.

The Java Application is the connection between the mobile phone and Chrome.It controls the NFC reader and the Bluetooth adapter connected to the com-puter to exchange messages with the smartphone. The communication withthe Chrome extension is handled bi-directional via WebSocket. For each userthe program manages a user account that saves the tabs that a user had open ina file. Upon re-login those tabs are loaded in the browser.Every second a message is sent to the mobile phone to receive the connec-tion’s RSSI to check if it is still in range or if the user has to be logged out.Whereas the ideal location to save tabs and other user information would beon a server, so that the information can be accessed from different terminals,this prototype saves it on the computer for the sake of simplicity and becauseit is sufficient for testing purposes.

Logic that determines when to log outIn section 3.2.6, different ways of measuring distance were introduced. Alogic that utilizes a Bluetooth connection and uses both RSSI and packet loss

28

to infer distance, is simple but should have good enough precision, and wastherefore implemented in the prototype. This part explains to some extent thelogic that determines when a user should be logged out.

It is not possible to measure the RSSI between the Android mobile phoneand the computer with a pre-determined frequency due to the way of the Blue-tooth implementation, which will be further explained in section 4.3.2. Nev-ertheless, the code produces a new RSSI roughly every 1-2 seconds. Becausethe RSSI can fluctuate very much within a short time period and is highly sus-ceptible to influences of other devices, it was not possible to look at the rawdata from the measurement. Instead, the Exponentially Weighted Moving Av-erage (EWMA) of the RSSI was interpreted. With help of the RSSI’s EWMAit is possible to factor in more than the last measurement of RSSI to try tocompensate for sudden changes in signal strength [34]. A factor α specifieshow much the older values should be factored into the new EWMA value. TheEWMA is calculated with the following formula:

EWMAt = αY t +(1−α)EWMAt-1 for t = 1,2, ...,n

Where:• EWMA0 is the mean of historical data• Y t is the observation at time t• n is the number of measurements to be monitored including EWMA0• 0 < α ≤ 1 is the parameter that specifies how much the older values

should be factored into the new EWMA value.

With the help of the EWMA, α , two offsets and a limit for the RSSI it ispossible to fine-tune the distance at which the user should be logged out. Witheach new measurement, the new RSSI value is compared to the RSSI limit

With the help of the EWMA and some parameters it is possible to fine-tunethe distance at which the user should be logged out. The following parametersand variables are used. Variables that are bolded can be set by the user.

• rssi - the current RSSI• ewma - the current EWMA, calculated with rssi• minValue - the lowest RSSI measured during the current session, up-

dated if the rssi is lower than the previous minValue, but never lowerthan minValueLimit.

• rssiOffset - the value by which the current RSSI is not allowed to un-dercut the minValue.

• ewmaOffset - the value by which the EWMA is not allowed to undercutthe minValue.

• minValueLimit - lowest possible minValue.

With each new measurement, the new RSSI value is compared to the min-Value. If it is lower than minValue, it is set as the new value for minValue. The

29

parameter minValue, though is capped and can never be lower than MinVal-ueLimit. This was introduced to prevent a sudden unreasonable fall in RSSIfrom being saved as minValue.

Subsequently to that, the EWMA is calculated using the formula above.Then, a two-step check is performed. First, it is checked if the RSSI is lowerthan the rssiOffset subtracted from the minValue. If that is the case, it ischecked, whether the EWMA is lower than the ewmaOffset subtracted fromthe minValue. If yes, the user is logged out. This whole process is shown infigure 4.3 in pseudocode.

Figure 4.3. [Code lines in parentheses] With each new measurement, the new RSSIvalue is compared to the minValue (9). If it is lower than minValue (11), it is comparedto minValueLimit (13). If the RSSI is lower or equal to the minValueLimit, minValue-Limit is set as new value for minValue (13). If the RSSI is greater than minValueLimit(15), it is set as new minValue (17). Subsequently to that, the EWMA is calculatedusing the formula above (20). Then, a two-step check is performed. First, it is checkedif the RSSI is lower than the rssiOffset subtracted from the minValue (23). If that isthe case, it is checked, whether the EWMA is lower than the ewmaOffset subtractedfrom the minValue (25). If yes, the user is logged out (27).

Additionally to that, the computer sends a ping message to the mobile phoneeach second, saving the timestamp of the ping in a list. Upon receiving a pongfrom the mobile phone, which also contains the original timestamp, that times-tamp is removed from the list. In a normal scenario with the phone nearby, thelist always contains at maximum one timestamp. Every second, the size of thelist is compared to a threshold and if it overshoots the limit, the user is loggedout as well.

30

With these calculations and a tuned threshold, α , RSSI limit and offsets,it is possible to hold the false-positive (logging out although the user is stillsitting next to the computer) to a minimum, while sufficiently preventing thefalse-negative (leaving the computer without logging out) from happening.

Right now, it is not possible to enter a desired distance in meters or choosefrom predefined values. One still has to adjust the values by trial-and-error asthey also depend on the surroundings and the used hardware. The user canpass those values as parameters when starting up the Java application.

The tuning of the threshold was in this prototype done empirically. First,arbitrary values were chosen for the parameters. Then, the author sat next tothe computer for a while to see if he would get logged out by accident. If thatdid not happen he walked away from the computer and kept track of whenhe was logged out. If the distance was too big, the parameters were changedand the process of testing was started anew. This was done until the authorwas satisfied with the logout behaviour of the system. Although this approachis not very straight-forward it is sufficient for this kind of prototype and wasconducted successfully at two different locations.

4.2.3 Chrome ExtensionWhen deciding to take Google as a use case for NFCLogin, the question waswhich browser to use. Different aspects weighed into the decision, upon whichwere market share and customizability with extensions. Research suggestedthat Chrome and Firefox were the most used browsers, whereas Chrome leadthe rankings. [35] When looking into the extension system Chrome seemedalso more accessible than Firefox, which is why Chrome was chosen for thisprototype. Keeping in mind that the use case was to log in into Google, thatalso seemed like a reasonable choice.

The Chrome Extension is the last part in the chain from mobile phone toGoogle. This extension implements a WebSocket client and connects to theJava Application’s WebSocket server. If it receives a login command withcredentials, it opens a Google login tab and injects credentials and a contentscript that then submits the data to Google. After that, the extension waits ashort time to make sure the log in process is completed and proceeds to loadtabs that the user had open when she was logging out the previous time. Thosetabs are automatically sent by the Java Application if they are existing. If theconnection to the phone is closed, the Chrome Extension sends all open tabsto the Java Application.

4.2.4 Used LibrariesIn this subsection the different libraries used in the development of the proto-type will be introduced sorted by device.

31

Libraries used on the computerThis part contains all the libraries that were used on the computer.

Libraries for NFCFor the NFCLogin Java application several libraries were used. In contrast toBluetooth, which is a technology that has been around for a while, NFC is stillquite new and after it’s first boom it seems that there are not too many librariesexisting that are still maintained and – most importantly – working.

The library that was used for NFC on the computer was NFCTools byAdrian Stabiszewski [36]. It is a library for Java which supports amongstother readers also the SCL3711.

Alternative libraries for different programming languages were also lookedat. For C it is possible to use libnfc [37]. For python, there is pynfc [38](which are python bindings for libnfc) and nfcpy [39]. Pynfc was at the timeof programming not up to date anymore and did therefore not work. Nfcpyworked just with older versions of python and other libraries.

Libraries for BluetoothThe bluetooth library used for this prototype is BlueCove [40]. It is outdatedbut unfortunately the only bluetooth library for Java on Windows that is stillworking. The jar file added to the projects build path is the latest snapshot ofversion 2.1.1, which is the most current existing version of BlueCove.

Other librariesIn addition to the most important libraries for NFC and Bluetooth discussedabove, two more were used. To connect to the Chrome extension, a libraryfor WebSocket made by Nathan Rajlich [41] was used. Because logging iseasier with a framework, the Simple Logging Facade for Java (SLF4j) [42]was included.

Libraries on the mobile phoneAndroid comes already with a broad support for NFC, but some useful codewas already written in a library by Thomas Rørvik Skjølberg called ”NDEFtools for Android“ [43]. Because Android already has out-of-the-box supportfor Bluetooth, there was no need to include a library for it.

4.3 Problems with Software/HardwareDuring the development of the prototype, some problems were encountered,some of which are discussed in this section

32

4.3.1 NFC on AndroidDue to the current NFC implementation on Android it is not possible to sendmessages via NFC without using the Beam interface (further explained in3.2.3). This means two things – firstly, the user has to approve every mes-sage that should be sent and, secondly, it is not possible to automatically pingbetween the computer and the phone using NFC.As described in the previous chapter, the work flow intended for this productwas imagined in such a way that the user does have to do as little as possiblewhile maintaining a strong feeling of security. The smoothest work flow forthe user would be to just have to hold the phone to the NFC reader. The readerwould then send a message to the phone, start the phone’s app which in turnwould send the credentials via NFC to the computer. Then the user would belogged in.Given the current NFC implementation on Android it is either possible to startan application via a NFC message from the computer or send an NFC messagefrom the phone to the computer. This is, as named before, because the onlyway to send message from an Android phone is to use Beam. For the Beaminterface to come up, the phone has to enter the NFC-range of another devicewhile the artefact that should be sent is opened on the phone’s screen. Thisis the case in the use cases for which Beam was designed.Therefore, the only way to use Beam would have been to introduce more stepsfor the user. One option would have been to let the user start the NFCLoginapp prior to bringing the phone close to the reader. Another one to let herhold the phone to the reader to trigger the opening of the app, then making herremove the phone from the range and bring it closer again to trigger the beaminterface.4 As the only thing the user should be required to do is to put thephone on the NFC reader (and maybe tap the screen to send the credentials viaBeam), it was decided against using NFC for credential transfer. Therefore,user name and password are sent to the computer via Bluetooth.

4.3.2 RSSI measurementDuring the implementation of the prototype, some problems with RSSI mea-surement were encountered, which were due to the limitations imposed by theoutdated BlueCove library that had to be used. According to the Java Blue-tooth API, there is a function called RemoteDeviceHelper.readRSSI, whichgives direct access to the current RSSI. However, for that to work, BlueCovehas to use the widcomm Bluetooth-stack instead of the standard winsock stack.Whereas there was a widcomm stack available for the 32-bit version of Blue-

4It was even experimented with turning the field generated by the NFC reader off and on tosimulate the phone leaving and re-entering the NFC range. This, however, did not work withthe used NFC library.

33

Cove, that version of BlueCove did not support the readRSSI method men-tioned before. The 64-bit version of BlueCove supported said method, butthere was no widcomm stack for that version available. The Bluetooth API forAndroid does not offer a method to access the RSSI right away either, thus, itwas not possible to use the straightforward approach to get the RSSI.The ”solution“ that was found, was to continuously do device discoveries andget the RSSI as a result from the function call. As the Bluetooth API forAndroid was more accessible than the one for PC, it was decided to run thedevice discovery on the mobile phone, despite the high demands this puts onthe battery. Obviously, this is not the way this would be done for a commercialproduct, but it works for testing purposes.

4.3.3 Bluetooth or Bluetooth Low EnergyAt the beginning of the programming phase one of the questions was wetherto utilise Bluetooth or Bluetooth Low Energy (BLE). BLE would be preferredas it is advantageous to use less energy, but BLE was not supported beforeAndroid 4.3 (API 18), which at that time was not yet available for the Samsungmobile phones. Therefore it was decided against BLE.

Despite those problems, it was possible to build a working prototype that metthe requirements specified earlier. This prototype then was tested in a seriesof usability tests covered in the next chapter.

34

5. Evaluation

This chapter will focus on the evaluation of the NFCLogin prototype and thethoughts behind it. The evaluation was done by conducting a short series ofusability studies. The first part of this chapter contains the setup of study andinterview and the second part an analysis and the discussion of the results.

5.1 Usability testingThe purpose of the study conducted within the scope of this thesis was toevaluate the prototype described in section 4. The author tried to investigatethe usability and utility of the NFCLogin system.

Research questionsThe broader research question given in this thesis is "How should a user au-thentication method be designed to automate login/logout and to mitigate neg-ative effects of lacking security awareness?". This research question is opera-tionalized in three questions:

1. How usable is the NFCLogin prototype?2. How trustworthy is the NFCLogin prototype?3. Could NFCLogin make logging out more socially acceptable?

5.1.1 MethodIf one looks at NFCLogin’s stage of development compared to a commercialproduct, it could best be described as being in the late prototyping and testingphase [44, p. 28]. Because most of the major functions (e.g. login, logout,saving/loading tabs) already existed, it was decided to do an assessment testto see how well NFCLogin can be used in a realistic environment [44, p. 34f].This chapter will try to cover the testing process with as much detail as possi-ble, to give background to the findings in the result section.

Participant characteristicsIt was decided to conduct the study with 6 participants as, for a first test, itwas deemed likely that the results would give a satisfying amount of sugges-tions towards further development of the product. Because NFCLogin utilises

35

Google on a computer, and this test more specifically evolved around Googlemail and Google drive, the author wanted to prevent lack of knowledge ofthose services having an impact on the study. That is why having a Googleaccount and basic proficiency in using mail and drive on a PC or Mac wasseen as a requirement for test participants. All participants used Gmail on thecomputer on a daily basis and Google drive on the computer on a weekly basis.Users were not required to use their own account during testing. Participantswere given a cinema voucher (worth 100SEK) as compensation.

Before conducting the tests with the participants, parts of the study weretested on a pilot.

Test overviewEach test session was planned to be 45 minutes long. In the beginning ofeach session, 15 minutes were used to both get background information on theparticipant as well as to explain the procedure and NFCLogin to them. Afterthe test, which was planned to take 10 minutes, a 20-minute post test interviewwas conducted. During the study the participants were testing logging in andout of Google using the NFCLogin system while performing basic documentediting and printing tasks. The test started and ended in an interview roomadjacent to the room in which the study took place.

Informed Consent AgreementPrior to anything else, the participants were given an Informed Consent Agree-ment (cf. appendix in section 7) citing amongst other things the purpose of thestudy, the required time, their withdrawal right and remuneration.

Introduction to the study sessionDuring a short introduction to the study session the moderator explained thepurpose of usability studies in general as well as the user’s part and importancein the study.

Pre-test questionnaire & interviewBefore the test, each participant had to fill out a background questionnairewhich asked for basic information such as age, gender, main occupation aswell as usage of Google services. This was partly to get user statistics andpartly to make sure that all participants had proficiency in using the Googleservices that would be part of the study.After the survey the participants were, in a short interview, asked about theirusual habits when leaving a computer amongst people for a few minutes aswell as possible security habits or settings with Google. The backgroundquestionnaire and the script for the background interview can be found in theappendix in section 7.

36

StudyThe pre-test interview was followed by the actual study, during which an elab-orated background story was used to help the participants imagine a certainuse case. This is explained in detail in section 5.1.1.

The participants were tasked to log in to Google with NFCLogin, print outand fetch a document for the printer (while logging out) and then to log inagain to read another e-mail. The tasks step-by-step were the following:

1. Login to Google using the phone.2. Open Gmail.3. Open an e-mail from a certain sender.4. Open the Google drive document linked in a separate e-mail.5. Do some changes to the document.6. Print out the document.7. Go to the printer in another room and fetch the printout, effecting a lo-

gout if the phone is carried along.8. Come back and put the printout into an envelope.9. Log in again to read a new e-mail.

Instead of having their tasks on small cards and turning them one-by-one orsomething similar, the way they got tasked was weaved into the backgroundstory developed for this study (See more in section 5.1.1).

The document was reset, the e-mails were marked as unread and the enve-lope was placed back on the table after every test user as to give every user thesame experience.

Post-study interview (20 minutes)After the study had been finished, the participants were interviewed by meansof a semi-structured interview to gather information about how NFCLoginworked for them as well as their thoughts about the system. Following that,they were thanked for participation, were informed about how NFCLoginworks and could ask any question that they felt like asking.

The script for the interview can be found in the appendix in section 7.

Test environmentThis part describes the location as well as the equipment used in the usabilitytest.

LocationThe tests were conducted at the Information Technology Center at UppsalaUniversity. The office room used as the test persons’ work place was locatedon the side of the building, a bit off from other offices to decrease the inter-ference of other wireless devices. To simulate an office environment, the testdesk was put into an office with one other person working at a separate desk

37

as can be seen in figure 5.1. The test persons’ desk was prepared to look likea normal work desk with some cables, envelopes, papers and a coffee mug.

Figure 5.1. Overview of the test room. The consultant’s desk is to the left, whereas thedesk of "Johanna Cederkvist" is closer to the door. Both people are facing the northwall.

EquipmentA desktop computer1 running Microsoft Windows 7 was used for testing. TheNFC dongle used was the SCL3711 and the Bluetooth dongle the Belkin mini.Because the system does not work on every phone, it was decided to use theauthor’s own Nexus 4 which holds the login credentials to a Google accountspecifically created for testing purposes. This hardware is all covered in sec-tion 4.1.1. A printer located in a separate room on the other side of the build-ing, as can be seen in figure 5.2 was used for the printing task. The computerhad been set up for use with the printer beforehand.

Immersion into the studyTo make the test situation closely represent a real world scenario, it was de-cided to take a use case and evolve a story around it, in which both the par-ticipant, the moderator as well as another person would take part. The testparticipants were told that they themselves as well as the moderator were em-ployees at the small (made up) company WirelessUsability. They were giventhe role of the administrator Johanna Cederkvist and had their own desk in anoffice shared with a consultant. Additionally it was explained that the com-pany uses a printer on the other side of the building for printing.

1The same as used for developing the system.

38

They were given the information that the company would introduce a newlogin method for their work force, which would let them log in and out ofGoogle chrome without having to type their password. A work phone wasprovided for them which had already stored Johanna’s Google credentials inthe NFCLogin app. The participants were informed that their computer hadbeen equipped with a device that logs them in to Google when they put theirphone onto it and would log them out when they leave the room. The loginprocess was explained to them in detail.

Next, Johanna and the moderator left the interview room and went intothe participants office. She was shown her work place and introduced to theconsultant after which the moderator demonstrated the login process and thenprompted her to follow him to the printer, thus enacting the logout process.While walking out of the room, Johanna had chance to see the logout happen-ing in causal connection to the position of the moderator who was holding thephone.

While walking to the printer, the moderator expanded on the company’sstory, that they were only starting out and therefore had to rent offices within alarger building and that their printer had not yet been plugged in which is whythey had to use one on the far side of the building.2

On the way back from the printer, Johanna was told that the moderatortries to get NFCLogin patented and that he had started a draft of the patentapplication in a document on Google drive which had been shared with her.Additionally, she was informed that a colleague, Phil Baggins, had offered hishelp and sent an e-mail with some suggestions to Johanna. It would be greatif she could take a look at her inbox as soon as she came back to the office.

Phil’s email contained two pieces of information that should be added tothe patent document as well as further instructions on what to do. He askedJohanna to print the document and upon return to the office put it into one ofthe brown envelopes that were lying on her desk. She was then to take theenvelope to lunch and give it to the moderator. The e-mail contained also areminder that this document was not to be seen by any untrusted person tofurther increase the perceived need of guarding the data.

When coming back from the printer, Johanna was prompted to check theire-mail once again for a calendar invitation that the moderator had sent her inthe meantime. Said calendar event invited her to the post-interview meetingin the adjacent room to which she went together with the author, taking thephone with her. Upon re-entering the interview room the moderator and theparticipant left their roles as employees of WirelessUsability.

2Trivia: this was actually partly true. Initially a printer in the office next down the hall shouldhave been used, but that printer got moved had had not been reconnected to the internet.

39

Figure 5.2. Map of the building containing the test room to the left and the printer onthe far right.

Role of the participantThe participants assumed the role of Johanna Cederkvist who was workingas an administrator at WirelessUsability. Using NFCLogin they logged in toJohanna’s email account containing amongst the e-mails needed for the studyalso a few other, personal-looking e-mails.

Role of the consultantTo realistically give the participant a feeling of being in a shared office, it waschosen to have another person sitting in the same room but at a separate desk.It was chosen that this person should be a consultant who would stay withthe company for only two weeks to infer a healthy feeling of mistrust towardstheir office-mate inside the participants. Each participant got introduced tothe consultant when shown to their work desk. The role of the consultant wasplayed by Mikael Laaksoharju and Ted White.

Role of the moderatorThe author took the role of the moderator and doubled as the participants col-league (but still in a position to ask the participants to do things) as well as anobserver, sitting on a couch in the same room.

Digital propsBefore the study, some digital "props" had been put into place, partly becausethe study required it and partly to help the participant’s immersion into thesituation. Besides the Google drive document with the patent (as well as acorresponding "Invitation to edit" in the mailbox) and Phil Baggins’ e-mailwith suggestions, there were three more e-mails in Johanna’s inbox, as can beseen in figure 5.3. All of them could be interpreted as being personal and wor-thy to hide from other’s eyes. One was made to look like it came from Kivra,a swedish service for receiving post from municipalities in digital instead ofpaper form. Another e-mail was sent from "Isabella Knutsson" and entitled"Pictures from Dubrovnic" with the preview-text hinting at a dropbox-link topictures from a beach holiday in Croatia. The most recent one (beside the e-mails related to the study) was a notification that the author had tagged them in

40

a picture on Facebook. While the first two e-mails were fake, the Facebook e-mail was genuine and linked to a fake profile for Johanna Cederkvist, so that,if the participants would have clicked on the link in the e-mail, they wouldhave been taken to an existing Facebook profile. The text of all the e-mailscan be found in the appendix in section 7.

Figure 5.3. Screenshot of Johanna Cederkvist’s inbox, showing the emails that everytest participant was presented with.

MeasuresTo try to answer the questions in section 5.1, this study facilitated interviewsand observation as the main source of data. With help of a pre-test interview,some information about the users’ login and logout habits was gathered beforethey could be biased too much by knowing too much about NFCLogin. Duringthe study, the participants’ actions were observed by the moderator who tooknotes sitting in the same room. Afterwards, the author tried to gain someinsights into the users’ actions as well as feelings towards and thoughts aboutNFCLogin with a semi-structured interview. Material for question 1 through 3could be found in both observation and interview, whereas question 4, "CouldNFCLogin make logging out more socially acceptable", was tried to interpretwith the interview alone.

5.2 ResultsAlthough the study just featured six participants, the author could get a greatamount of impressions and information from it. The following section willfirst state some of the observations that were made, then introduce some ofthe findings of the post-test interviews and at last put all in context to the fourquestions.

To increase the readability of the text, instead of participant codes, the au-thor decided to use the names Bruce, Tony, Steve, Natalia, Clint and Wanda.Whereas half of the six participant were women and half men the codenameswere randomized disregarding gender.

41

The studies were all conducted on Thursday, June 2nd 2016.

5.2.1 Pre-test questionnaireDuring the background questionnaire that the participants had to fill in priorto the test, age, gender, occupation and usage of specific Google services wasasked. The study was conducted with 6 participants, partly students and partlyemployees at Uppsala University. There were 3 female and 3 male test usersbetween the ages of 25 and 31.

In table 5.1 it can be seen that all participants use Google mail and Googledrive on the computer at least weekly, which indicates that they know theirway around the apps around which the test resolved. All of them had alsoused Google calendar before, which played a minor role in the test. The testperson that crossed "never" for Calendar on computer/mobile disclosed orallythat they had used Google calendar for work at some point and that the reasonthey do not use it now was that they mainly use it to sync their Apple calendars.

Table 5.1. Usage of Google servicesApplication Never Monthly Weekly DailyGmail computer 6Gmail mobile 1 5Drive computer 6Drive mobile 1 2 3Calendar computer 1 2 1 2Calendar mobile 3 1 2Other computer 1 3 1 1Other mobile 2 2 2

5.2.2 ObservationsThis part states observations that were made during the study, specificallythose made regarding login and logout.

LoginAll of the six participants managed to log in with NFCLogin. Four of them(Natalia, Wanda, Clint and Tony), however, forgot to unlock the screen beforeputting the phone on the NFC reader during the first login. Three of them re-membered it the second time they logged in. Tony waited for almost a minutewith only turning the phone a little bit on the NFC reader. In the end, he fig-ured out that he had to turn it on, but when logging in the second time, he triedit again without unlocking it. This time, though, he waited only for about twoseconds.

42

During the second login, it was observed that two participants (Bruce andClint) put the phone on the reader while they were sitting down, prior to con-tinuing with the envelope-task.

LogoutWhen they were supposed to fetch the document from the printer, three ofthe participants (Natalia, Steve and Tony) took the phone and walked directlyout of the door3. Two of the remaining three participants (Bruce and Clint)hesitated after picking up the phone and waited close to the door until theywere logged out. The last of the six participants, Wanda, left to the printerwithout taking the phone with her.

5.2.3 Post-test interviewsThe overall impression of NFCLogin seemed to be positive. While havingmany suggestions, questions and critique, the participants also had many goodwords for the product.

One of the things that got the most praise (Clint, Tony, Steve and Natalia)was the fact that previously opened tabs got reopened, which - according tothe participants - made it easier to continue working, and even worked as areminder of what they had worked on previously as not to forget that (Clint).Wanda could not experience the re-opening of the tabs as she did not log ina second time whereas Bruce logged out manually before logging out withNFCLogin which interfered with the mechanism.

The participants generally liked the idea of using it instead of passwords,partly because they thought that the login went smoother and faster and partlybecause they then do not have to remember the password. For most of theparticipants, the system using the phone to determine when to log out feltpractical, partly because the phone is something you always have with youand partly because it is not an additional item that you have to carry around tobe able to be logged in. According to Tony, it adds security without thinkingabout it.

Both Steve and Tony liked that one can use the phone while being logged in,otherwise this probably would have been a deal-breaker. Tony thought it wasreally nice that the saving and re-opening of the tabs worked for non-Googletabs as well.

The rest of this section introduces more findings from the interviews sortedby categories that combine several aspects that the author deemed related toeach other. An interpretation of the findings can be found in the discussion inthe following section.

3Tony came back to fetch an access card to reach the room with the printer. As this specific testwas done after 17:00, the card was needed.

43

LoginDuring the interview, Tony, who waited a long time before he unlocked thescreen said that he had not understood that he had to unlock the screen for thelogin to work.

Of the six participants, four were of the opinion that the time it took to login was acceptable, although they said it would be advantageous if it would gofaster. Bruce expected the login to take longer, whereas Steve thought it tooklonger than he would have thought.

LogoutTwo of the participants were satisfied with the time (actually distance) it tookto log them out. Bruce and Clint commented that the log out should go fasterand Wanda did not experience a log out as she left the phone on the desk.Steve disclosed during the interview that they, while going out on the corridor,looked at the app and established from the status that they still were not loggedout. Because they were of the opinion that they should have been logged outby now they decided to press the "Terminate" button which sent a logout signalto the computer.

As it turned out during the post-test interview, Bruce and Clint were underthe impression that the signal to log out would be sent the second they tookaway the phone from the NFC reader.

Wanda wondered if she might have left the phone on the desk because sheis not used to not having her phone in her pocket. Furthermore, she said thatshe usually neither logs out nor takes her phone with her if she just goes to thenext room.

UnpracticalSome things were named unpractical by some of the participants. Most men-tioned was the fact that you have to unlock the phone’s screen for the systemto work. While the participants understood that that was necessary to ensuresecurity, most of them also thought that it was a loss of convenience.

While being of the opinion that reopening the latest tabs was a good thing,Clint also thought that it could pose a disadvantage. He imagined the scenarioof meeting somebody while away from the computer and wanting to showthem something. Then upon re-login, the other person would be able to seethe last document the user was working with.

Wanda said that she always likes to double check if she is really logged outor if the screen is locked. She sometimes checks it two or three times.

Another point of critique from Wanda was that when the user is forced toput their phone on the table, logging in with a password could be equally fastas NFCLogin.

44

Use casesDuring the interview, the participants were asked to think of possible situationsin which they could imagine using NFCLogin. In general, the answer the au-thor got was "whenever I want to secure something". The participants quicklydiverted from Google as a service and suggested others that were more appli-cable to them. According to one, the system would be really useful in jobs thatrequired the user to walk between the computer and another artefact involvedin their work. For example, librarians who have to frequently go back and forthbetween their work computer and the book shelves. Tony mentioned that NF-CLogin could be used to secure the company mail instead of Google/Gmail,which would be especially useful in municipalities because the company mailis considered as a public document and one could get in trouble if somebodyelse would send emails in one’s name.

Wanda said that she could imagine using the system at work if she did nothave to put the phone on the table every time she wants to log in.

Natalia, as only participant, mentioned that it could be useful in more publicplaces like cafes where other people are present, but you still trust them enoughto not steal your computer.

RisksAll participants (prompted and unprompted) mentioned some risks that theyfeared for when using NFCLogin. Losing the phone and somebody readingout their user credentials was mentioned as a risk by all of them. Althoughsome of them mentioned in context to this that one should have a safe screenlock on one’s phone to prevent that, as well as that the same problem wouldoccur if you just store your passwords in your browser.

Four participants mentioned (or described the equivalent of) a man-in-the-middle-attack between phone and Google as a possible risk that should at leastbe minimized to make the system safe to use.

Clint said that it could be a source of stress if the system ceases to work forsome reason when one is working with sensitive data. He said that, in case thesystem sometimes acts up, that would be a reason for not using it.

TrustDuring the interview, the participants were questioned if - and under what cir-cumstances they would trust NFCLogin. All participants said that, with a fewassumptions, they would trust the system. The requirements they mentionedwere that the transfer of credentials from phone to Chrome is sufficiently se-cure and that it is possible to lose the phone without giving people access totheir Google account. Because two of the participants, Clint and Bruce, hada different understanding of how the logout worked, they stated that their per-ception of the system’s trustworthiness was influenced. They gave, however,credit to it and said that they probably would feel more trustworthy if the sys-tem’s workings had been clear to them.

45

Social implicationsThe participants were asked what (dis)advantages they could see with activelylocking the computer while sitting in a group with friends or colleagues. Na-talia and Bruce both mentioned, that the people around them could think thatthe participants do not trust them. That being said, they also mentioned thatcompared to the security gained by locking, the feeling of awkwardness is asmall price to pay.

When participants did not mention anything similar to that, they were prompteddirectly and asked how it feels to lock the computer without leaving. Stevethen said that one marks that one does not trust the people around and alsoadded, that locking the computer at work could mean that you are not doingwhat you are supposed to do.

After prompting more directly about the social implications, Wanda, Tonyand Clint joined the other three in agreeing on a social awkwardness that existswhen locking the computer.

When asked whether the app could make locking the computer more so-cially acceptable, Wanda, Tony and Clint (as well as Natalia and Bruce whosaid it from the beginning) all could see a point in that thought. Clint, how-ever, initially argued in the opposite direction. If NFCLogin would be used tolock the whole computer, he thought that it could be weird use it because itwould make it impossible for his friends or colleagues to use his computer ifthey wanted to do so.

Steve argued that the app would make no difference as it is still the user’schoice if she wants to use the app or not. According to him, the decision to usean automatic login/logout system is equal to the decision to lock a computermanually.

Feature suggestionsThe participants were quick to come up with suggestions or features that - intheir view - would improve the system.

Tony mentioned that the Terminate button on the phone could even be use-ful when sitting at your computer. In case somebody, whom you do not wantto see what you are doing walks by, you could quickly press that button (sup-posed that the phone is unlocked) to hide your tabs.

Wanda suggested to make alterations to the system in such a way that theNFC connection is only required in the beginning of the day. That wouldmean that - after leaving the room and logging out and coming back - thesystem would automatically build up a Bluetooth connection and measure thedistance, logging the user back in once she has entered a certain range.

One feature that the author also had planned for an ideal solution was to beable to specify the distance at which to log out in meters.

Wanda and Tony also mentioned that the system could be used when onecan use different workstations, which in turn also means that several peoplecould use one and the same computer. This, however, brought up the ques-

46

tion where the opened tabs should be saved. If they are saved locally on thecomputer, one can, for example, have a different set of tabs on the work com-puter and on the personal computer (as pointed out by Tony). If they are savedsomewhere online, the user could go from workstation to workstation and besure that her tabs always open regardless of the computer.

Because there is the risk of a phone or a computer being stolen, it was sug-gested to implement a feature that makes it possible to remove the possibilityto log in from both sides. I.e. if a computer is stolen, one should be able toremove that computer from the trusted devices and vice versa.

Something that two participants (Natalia and Clint) noticed was that whilelogging in some tabs are opened and closed. This is due to the system openingthe Google login page, entering the credentials and closing it again. Whereasone of them mentioned that they understood this was the reason behind it, boththought that it would seem smoother and less confusing if they just would belogged in without the flickering of tabs opening and closing.

Natalia suggested that, while reopening the previously opened tabs is veryuseful, it would be even better if the system also would remember which tabwas the active tab. Otherwise, she said, if one is prone to have many tabs openat the same time, it could be hard to find the correct tab.

She also noted that there was no, or not enough feedback when being loggedout while walking away from the computer.

5.2.4 DiscussionThis part will try to answer the four questions formulated in section 5.1 withhelp of the findings stated above.

How usable is the NFCLogin prototypeWhereas the system did not pose adamant problems to any user, there weremany things that could be changed to increase the product’s usability.

Besides forgetting to unlock the screen prior to log in, participants did nothave a problem with the login process. Tony’s long hesitation before unlockingthe phone can be explained by his statement during the interview, that he didnot know that it was a requirement to unlock the screen. When interpretingthe observations during the second login, the fact that Bruce and Clint put thephone on the reader while they were sitting down and before continuing towork, this could mean that they like to be logged in at all times when sittingat the desk. It could also suggest, though, that they learned from the first loginthat the process takes a few seconds, so logging in before continuing withanalog tasks makes their workflow more efficient.

Two of six participants were satisfied with the logout. One of the threeothers was Steve, who explained during the interview that he had to log outmanually using the app. While Steve really should have been logged out auto-matically given the distance between him and the computer, it was impressive

47

to see that he took matters in his own hands and used a function that had noteven been explained prior to the study. Bruce and Clint who were dissatisfiedwith the logout realized during the interview that they had a different under-standing of how the system works. They thought that they were supposed to belogged out as soon as the phone is taken away from the NFC-reader4 , whichexplained their hesitation and confusion when that did not happen. As theirhesitation was based on a different mental model of how NFCLogin works andthis is something that comparatively easily could be altered by using the prod-uct a little bit longer, the author decided not to count it as dissatisfaction withthe logout. However, he took it as a reminder that the actual way the systemworks has to be conveyed in a less ambiguous way to the end user. Natalia’s,Steve’s and Tony’s behaviour of leaving the room without hesitation seems toindicate that they trusted the system to log them out.

For the system to seem worth using instead of passwords, the login processhas to go with a speed that the user does not consider too long. The takeawayfrom the users’ statements on time would be that the login time is acceptable,although it would be better if would go faster. Of the three users that weredissatisfied with the logout time, two (Bruce and Clint) thought they would belogged out as soon as they removed the phone from the reader. Therefore itis not surprising that they were not satisfied with the logout time. To sum up,if NFCLogin aims to be a substitute for password-login, it should be at leastas fast as typing in a password. In the current implementation, it takes a fewseconds for the connection to be established. The findings suggest that a fasterlogin would be preferable.

While smoothing out the workflow for the users, it should still be paramountthat the system is secure. This balance between security and usability is veryvisible in the question whether the user should have to unlock the phone priorto using NFCLogin or not. While posing a noticeable interruption in the workflow, it at the same time is the only thing preventing a thief from using astolen phone to access the user’s account. The author still is of the opinionthat - supposed the login time can be minimized - NFCLogin would offer asmoother work flow than passwords because the user can unlock the phoneprior to arriving at the computer they want to unlock. Furthermore, most usersare probably able to unlock their phone faster than it takes to enter a passwordon a computer, especially when having a newer phone with fingerprint sensor.This coupled with the saving of the system’s status, in this case the re-openingof the tabs, would still be an advantage over passwords. Alternatively, if theproblem of NFC not working with locked screen can be solved, one could

4This situation could also have been avoided if the NFC-reader would not have been lying onthe desk, connected to the computer with an USB extension cord. If it instead had been pluggeddirectly into the computer, there would not have been the possibility of lying the phone on thereader. The disadvantage of that in its turn would have been that, for a first time user, it is hardto know how long the phone has to be close to the NFC reader.

48

think about using the phone’s other sensors to infer whether the current user isthe rightful one and only in that case log in although the screen is locked.

Clint mentioned that opening all tabs upon re-login could be a disadvantageif he wants to show somebody something on the computer, but does not wantthem to see all their tabs. The author, however, is inclined to argue that thiswould be the same when locking the screen with a password and unlocking itagain.

When asked about possible use cases for NFCLogin, most of the partici-pants thought that it could be used best at work, especially in situations whereone has to log in and out frequently. Only one participant mentioned that theywould consider using the system in a more public place, like a cafe.

How trustworthy is the NFCLogin prototype?When considering access control systems, it is not only important that theyare secure, but also that users perceive them as secure and trust them. Duringthe test, the participants seemed to get a positive feeling towards how NFCLo-gin reacted while it logged them in and out. They were concerned about thesystem’s security and came with thoughts on how it should be implemented.Steps that were suggested to be taken to make the participants trust NFCLoginare, firstly, to keep the credentials safe on the smartphone, secondly, to securethe system against man-in-the-middle-attacks and thirdly, to make the systemso stable that it is next to impossible that it fails to log out when the user isleaving the terminal.

While the current prototype does not have that exact level of security, thisis an indication towards that users would trust NFCLogin enough to considerusing it. With all that said, as Wanda showed with her habit of double checkingthe log out process, depending on personal preferences or personality traits, itmight not be something for every user.

Could NFCLogin make logging out more socially acceptable?One of the four questions was whether NFCLogin might make it more sociallyacceptable to log out when others are present. The reasoning behind this beingthat if the logout happens automatically it does not matter who is surroundingthe user, she is always logged out, thus taking away the edge of mistrust thatsome people might feel if their friends lock their computer in their vicinity.5

The users’ opinions on that matter were parted. 2 of 6 mentioned the awk-wardness of locking the computer after a rather open question. And the other4 could join in on that opinion after a more direct question.

When asked more directly whether NFCLogin could make logging outmore acceptable, all but Steve could see this to be true. Steve argued thatusing NFCLogin itself would be a sign of mistrust towards the surroundings.

5Even if it is just the user themselves that thinks that their surroundings might react in that way.

49

To sum it up, while participants were considering the notion of NFCLoginmaking logging out more socially acceptable, it did not feel significant enoughto suggest something for or against it. Whereas the author remains carefullyoptimistic that an automatic user authentication solution would make loggingout amongst friends less awkward, there is more research needed, to come toconvincing conclusions.

5.2.5 Reflections on Method & Problems with testingWhile it was not part of the actual usability test, the author also made severalobservations regarding the method of immersion on the study. This as wellwith some problems encountered while testing will be covered in the followingsection.

MethodThe author was surprised how much some of the participants seemed to diveinto the story and how important it seemed to them to guard the document fromunauthorized people (e.g. the consultant). Both Natalia and Bruce (severaltimes) noted during the interview how shifty and untrustworthy the consultanthad seemed to them. Clint, when taking the phone and leaving to the printer,waited on the doorstep looking back at the computer until it logged out. ("Istood there until it logged out, because it seemed so important with the patent-thingy") He even had closed the tab with the patent document beforehandbecause it seemed so important. Bruce disclosed during the interview that hehad thought about closing the document as well because he "did not trust theconsultant".

Something that was not quite fitting the story was noted by both Natalia andBruce. The printer was on the other side of the building in another "compa-nies" coffee room, which means that in the 60-90 seconds it took to get thereanybody over there could have had a sneak peek on the documents that wereprinted out. While this would be something to consider for future testing, itsuggests that those participants managed to immerse themselves into the storyto an impressive degree.

While the author thought that being moderator and also a "colleague" ofthe participants’ role in the study was interesting, it probably would have beenbetter to have another person playing the colleague, so that the moderator canfocus more on being a quiet observer. Similarly, as the author has imple-mented the prototype and designed and conducted the study himself, one cannot completely exclude a bias.

Although the participants were able to, as just described, immerse them-selves into the background story to an impressive degree, the author did notdeem this to be an ethical problem. Even though they described that they felta strong need to prevent others from seeing the confidential document, the

50

whole situation could never really be confused with reality and thus induceunbearable stress.

Problems encountered while testingWhile testing, the moderator noticed a few things that could have been donebetter or differently. It seemed that several test persons had missed that onehad to unlock the screen to be able to log in. While that probably also hints tothat users do not want to (or do not expect that they have to) unlock the screen,this maybe could have been prevented with clearer and longer explanation.

Another problem that was to attribute to the explanation of the system wasthat two test persons thought the system would log out as soon as the devicewas moved away from the NFC reader. With a more thorough explanation thiscould maybe have been avoided.

5.2.6 Changes that should be consideredWhen continuing to work on the NFCLogin system, the author would takewith him some of the aspects that were uncovered during the usability study.

First of all, it should be put effort into speeding up the login process thathappens in the backend when the user puts the phone on the NFC-reader. Thiswould make the system a lot smoother and much more practical.

A nice and easy addition to the saving and re-opening of the user’s tabswould be to also remember the tab that was active when the user logged out.

Another easy improvement that would possibly increase the user’s trust inthe system would be to implement better feedback when the user is logged out.In the current version, the user can only see that she is logged out when theNFCLogin app is open or, obviously, if she still can see the computer screen.An easy way to add some more feedback would be to add a notification andvibration when the user is logged out.

Whereas the user is appropriately logged in and her tabs are opened, therewere still comments on the opening and closing of tabs when logging in. Toget a less virus-like appearance it would probably good to have a look at howthat could be prevented.

One thing that could be looked into as an optional feature is to require NFCcontact to the mobile phone only once in the beginning of each day (or otherspecified intervals). During the rest of the day (or interval), the user wouldbe logged in just by the computer detecting her mobile phone in the vicinityand starting distance measurement, unlocking when she gets within a specifiedrange. This would need more careful research to still ensure a high amount ofsecurity even without a deliberate NFC connection.

51

5.2.7 Ethical considerationsThe idea behind NFCLogin is to make life easier and more secure for it’susers. By utilizing the mobile phone, a device that most users always havewith them, it aims to automate login and logout so that users do not have tothink about it anymore. However, there are some ethical implications that haveto be considered.

Whereas NFCLogin aims to eliminate the user’s need to remember pass-words and to log out, it increases the responsibility of taking care of the phone.While it is possible for the user to choose a more complicated and complexpassword, because NFCLogin takes care of it, it is likely that she would forgetthe password and thus would be dependent on her mobile phone. This can beproblematic when her phone runs out of battery, gets stolen or breaks.

Another thought is that, while NFCLogin aims to mitigate negative effectsof lacking security awareness, it itself might make users more unaware ofsecurity. The whole point of the system is to work smoothly without the userhaving to lose a thought about security, which might make it harder for usersto realize if their security has been compromised.

If one looks at the social aspect of locking one’s computer, which was cov-ered in the evaluation, another question arises. How would NFCLogin changethe interpersonal interaction within a group of people who are working withtheir computers? Would it take away the awkwardness of logging out or wouldit still be the same because the users opted to use a method to log out automat-ically? This question will have to be researched more in the future.

52

6. Conclusion & Future Work

This last chapter of the report summarizes the work done during the course ofthis thesis and gives some outlook on possible future work that could improvethe concept and product of NFCLogin.

6.1 ConclusionIn this thesis, a new concept of user authentication based on NFC and Blue-tooth was defined.

The aim of this thesis was to develop a new solution for user authenticationwith NFC and Bluetooth and to explore its aspects and requirements. By look-ing at current solutions and different wireless technologies a new concept wasproposed. A description of the qualities and requirements of this was given inform of a Theory of Use.

Given the specifications mandated by that theory, some key functionalitieswere isolated to be implemented in a testable prototype, called "NFCLogin".Those functionalities were in short: login, logout and saving as well as restor-ing of tabs. Google was chosen as service to log in and log out of. The proto-type that was built requires a Nexus 4 smartphone, a computer with Windows7 with connected Bluetooth and NFC devices as well as Google Chrome.

This prototype was then evaluated in an assessment that aimed at testingthe login and logout process as well as finding out whether participants wouldfind NFCLogin useful and whether users were inclined to trust the system.It was tried to give the observational study a realistic background with theparticipants assuming the role of an employee at a fictive company, sitting inthe same room as a consultant who should increase the users’ consciousnessabout the importance of guarding their data. While performing basic officetasks such as reading e-mail, editing documents and printing, the participantstested logging in and out using NFCLogin.

The study suggested that a concept like NFCLogin – if working reliable –could smoothen the users’ work flow in use cases where it is imperative tonever leave a workstation without having logged out. Even more so if thosesituations involve a need to frequently leave and come back to one’s work-place.

The participants seemed to be willing to trust the system to reliably andsecurely log them in and out of services. Some more technical users wereasking about more details about implementation but were satisfied with theproposed security that should be implemented in a commercial version.

53

6.2 Future WorkThe prototype developed in this thesis works as a proof of concept, however,already during the early implementation phase the author encountered ideasthat either would greatly improve the product or would be good complementsto make it an even broader and better solution. This last part of the thesiscontains some of these ideas.

6.2.1 Use NFC to transfer credentialsOne of the first problems that were encountered during the development wasthe inability to send several messages from the phone to the computer withoutthe user having to do anything, which is covered in more detail in section4.3.1. As a result to that, the user’s credentials are now sent via Bluetooth.Because NFC is more secure than Bluetooth, it would be preferable to sent thecredentials that way. With more low-level programming or future changes inthe NFC implementation on Android it might be possible to establish that.

6.2.2 Google 2-step verificationTo increase their users’ security, Google implemented 2-step verification, whichmeans that besides the user’s password some other information is needed tolog in. This other information could be a code sent to or generated in an appon the mobile phone or a physical security key. [45] One future change toNFCLogin could be to also include that functionality into the app. This wouldmake using 2-step verification easier which might lead to more people usingit. Although, admittedly, that would partly defeat the purpose of having a per-sonal secret (password) combined with a physical object (mobile phone), itstill would prevent people with malicious intent from logging in to a user’sGoogle account with only the password.

6.2.3 Phone sensorsAt the moment, NFCLogin only uses NFC and Bluetooth to determine when auser should be logged in or logged out. The distance measurement is based onBluetooth which works with radio waves. The RSSI of radio waves does notonly decrease with distance, but also with environmental factors (e.g. metal,humans, animals) [46]. Therefore it was observed that the RSSI sometimessuddenly got a lot worse. (cf. 4.2.2) With the phone’s other sensors, the systemcould gather clues as to what the user is doing right now. For example, thephones accelerometer and light sensor could be used to find out if the phone isin motion or residing on a table or in a pocket. This information could be usedto improve the log out logic by keeping the user logged in when the phone hasnot been moved although a sudden decrease in signal strength has occurred.

54

6.2.4 Different distance measurementAs covered in chapter 4.2.2, there are different ways to measure the distancebetween two devices. Distance measurement with Bluetooth proved to be sim-ple and sufficient for developed prototype. However, it was still considered tooshaky for a reliable product, which is why it should be tried to improve it. Ei-ther by using several antennas and triangulation or by looking into differenttechnologies.

6.2.5 Features and improvements suggested from user testingDuring the course of this thesis, usability tests were conducted which resultedin a list of possible improvements as well as features for NFCLogin. Thoseideas should be further developed and finally be put in new prototypes.

6.2.6 More testingWhereas one short assessment test evaluating the basic functionality of theconcept has been conducted, this test was too small and done with such asmall user base that it is not possible to gather more than suggestions from theresults. New studies testing different other parts of future prototypes, as wellas a more extensive study on logging in and logging out should be conducted.

55

Acknowledgements

During the time working on this thesis, I have had a lot of support and helpfrom different people.

First of all a big thank you to my supervisor Martin Jacobsson who besidesgreatly supervising this thesis helped me restart the process of working on itseveral times and always was incredibly supportive. Thank you as well to LarsOestreicher my reviewer who especially towards the end of my thesis gave memany pointers and support. I also want to give credit to Anders Jansson whotook the role of reviewer during the presentation and thesis coordinator JustinPearson whom I spammed with emails during the last days of this thesis.

To my unofficial supervisor for the HCI-part of this thesis Mikael Laakso-harju - thank you for all the support, meetings, talks, proofreading, inspiration,words of encouragement and being such an awkward office-mate.

My thanks goes also to Ted White for playing the role of the consultant inmy usability study.

I am thankful for the valuable feedback I received on my report by my twoopponents Tilda Pentikäinen and Stavros Mavrakis.

Marten Biehl and Bastiaan Boel, now I have also reached the goal. Thankyou for all the support, proofreading, stupid ideas, late night talks, beer tast-ings, horse masks and fat cat jokes. My gratitude goes as well to MaximilianHartl who proofread this thesis very thoroughly and prevented me from doingseveral embarrassing mistakes.

To the group of PhD students, postdocs, professors, teachers, lecturers, ad-ministrators and whomever I might have forgotten at Ångström laboratoryhouse 7 floor 2: thank you for including me so friendly in your midst. I feltdeeply accepted and happy that I got to hang out with you and I will not forgetthe pingisbord and the many lunch discussions about everything and nothing.

I also would like to thank my colleagues at MedfarmDoIT for all the con-tinuous support and awesome work environment.

I am very grateful to my parents, Astrid and Ero Langlotz who have beenimmensely supportive throughout my life and never ceased to let me knowthat it would be best for me to finish this thesis, although it - of course - is mydecision.

Linnea Fällström. Thank you for your support, proofreading, meals, listen-ing to my frustration and putting off decisions until after this thesis. Thankyou for believing in me and liking me for the person I am.

56

Acronyms

BLE Bluetooth Low EnergyEWMA Exponentially Weighted Moving AverageNDEF NFC Data Exchange FormatNFC Near Field CommunicationRFID Radio-frequency IdentificationRSSI Received Signal Strength IndicatorSIG Bluetooth Special Interest GroupToU Theory of UseWAMP WebSocket Application Messaging Protocol

57

References

[1] Bruce Schneier. Choosing Secure Passwords - Schneier on Security,last accessed June 8, 2016. https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html.

[2] Mikael Laaksoharju. “Designing for Autonomy”. In: (2014).[3] Lars Friedrichs. BlueProximity Sourceforge Page, last accessed June 9,

2016. http://sourceforge.net/projects/blueproximity/.[4] Dave Amenta. BTProximity homepage. Discontinued., last accessed June

9, 2016. http://www.daveamenta.com/products/btproximity/.[5] MapPin Software. TokenLock homepage, last accessed June 9, 2016.

http://www.map-pin.com/tokenlock.html.[6] Apple Appstore. KeyCard in Apple Appstore, last accessed June 9, 2016.

https://itunes.apple.com/us/app/keycard/id578513438?mt=

12.[7] MySmartLogon. EIDAuthenticate – Smart card authentication on stand

alone computers, last accessed June 7, 2016. https://www.mysmartlogon.com/eidauthenticate/.

[8] Marie-Pier Pelletier, Martin Trépanier, and Catherine Morency. “Smartcard data use in public transit: A literature review”. In: TransportationResearch Part C: Emerging Technologies 19.4 (2011), pp. 557–568.

[9] Microsoft Windows. What is Windows Hello? , last accessed June 9,2016. http://windows.microsoft.com/en-hk/windows7/can-i-use-a-fingerprint-reader-with-windows.

[10] Microsoft Windows. Can I use a fingerprint reader with Windows?, lastaccessed June 9, 2016. http://windows.microsoft.com/en-us/windows-10/getstarted-what-is-hello.

[11] Microsoft Windows. Making Windows 10 More Personal and More Se-cure with Windows Hello, last accessed June 9, 2016. https://blogs.windows.com/windowsexperience/2015/03/17/making-windows-

10-more-personal-and-more-secure-with-windows-hello/.[12] KeyLemon. KeyLemon Desktop Application, last accessed June 9, 2016.

https://www.keylemon.com/.

58

https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html

https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html

http://sourceforge.net/projects/blueproximity/

http://www.daveamenta.com/products/btproximity/

http://www.map-pin.com/tokenlock.html

https://itunes.apple.com/us/app/keycard/id578513438?mt=12

https://itunes.apple.com/us/app/keycard/id578513438?mt=12

https://www.mysmartlogon.com/eidauthenticate/

https://www.mysmartlogon.com/eidauthenticate/

http://windows.microsoft.com/en-hk/windows7/can-i-use-a-fingerprint-reader-with-windows

http://windows.microsoft.com/en-hk/windows7/can-i-use-a-fingerprint-reader-with-windows

http://windows.microsoft.com/en-us/windows-10/getstarted-what-is-hello

http://windows.microsoft.com/en-us/windows-10/getstarted-what-is-hello

https://blogs.windows.com/windowsexperience/2015/03/17/making-windows-10-more-personal-and-more-secure-with-windows-hello/



https://www.keylemon.com/

[13] Marketwired. Battelle SignWave? Unlock App for Leap Motion Lets YouWave Goodbye to Passwords, last accessed June 6, 2016. http : / /www.marketwired.com/press- release/battelle- signwave-

unlock-app-for-leap-motion-lets-you-wave-goodbye-to-

passwords-1814268.htm.[14] Leap Motion. Leap Motion | Mac & PC Motion Controller for Games,

Design, Virtual Reality & More, last accessed June 6, 2016. https://www.leapmotion.com/.

[15] Malwarebytes Lab Jean Taggart. Lock – Unlock, Biometrics Failure |Malwarebytes Labs, last accessed June 6, 2016. https://blog.malwarebytes.org / security - world / 2013 / 08 / lock - unlock - biometrics -

failure/.[16] LEAP community. Where is Sign Wave Unlock?, last accessed June 6,

2016. https://community.leapmotion.com/t/where-is-sign-wave-unlock/509.

[17] Battelle. Update about Signwave Unlock on Battelle’s Facebook page,last accessed June 6, 2016. https://www.facebook.com/Battelle/videos/578940642176559/.

[18] E. Grosse and M. Upadhyay. “Authentication at Scale”. In: Security Pri-vacy, IEEE 11.1 (2013), pp. 15–22. ISSN: 1540-7993. DOI: 10.1109/MSP.2012.162.

[19] MazeMap. MazeMap Indoor Maps and Navigation, last accessed June8, 2016. http://www.mazemap.com/.

[20] Gergely Biczok et al. “Navigating MazeMap: indoor human mobility,spatio-logical ties and future potential”. In: Pervasive Computing andCommunications Workshops (PERCOM Workshops), 2014 IEEE Inter-national Conference on. IEEE. 2014, pp. 266–271.

[21] Sheli McHugh and Kristen Yarmey. “Near field communication: Re-cent developments and library implications”. In: Synthesis Lectures onEmerging Trends in Librarianship 1.1 (2014), pp. 1–93.

[22] Vedat Coskun, Busra Ozdenizci, and Kerem Ok. “A survey on near fieldcommunication (NFC) technology”. In: Wireless personal communica-tions 71.3 (2013), pp. 2259–2294.

[23] NFC Forum. NFC Forum, last accessed April 29, 2016. http://nfc-forum.org/.

[24] Information technology – Telecommunications and information exchangebetween systems – Near Field Communication – Interface and Protocol(NFCIP-1). Norm. 2013.

[25] Information technology – Telecommunications and information exchangebetween systems – Near Field Communication Interface and Protocol -2(NFCIP-2). Norm. 2012.

59

http://www.marketwired.com/press-release/battelle-signwave-unlock-app-for-leap-motion-lets-you-wave-goodbye-to-passwords-1814268.htm




https://www.leapmotion.com/

https://www.leapmotion.com/

https://blog.malwarebytes.org/security-world/2013/08/lock-unlock-biometrics-failure/



https://community.leapmotion.com/t/where-is-sign-wave-unlock/509

https://community.leapmotion.com/t/where-is-sign-wave-unlock/509

https://www.facebook.com/Battelle/videos/578940642176559/

https://www.facebook.com/Battelle/videos/578940642176559/

http://dx.doi.org/10.1109/MSP.2012.162

http://dx.doi.org/10.1109/MSP.2012.162

http://www.mazemap.com/

http://nfc-forum.org/

http://nfc-forum.org/

[26] “IEEE Standard for Information technology– Local and metropolitanarea networks– Specific requirements– Part 15.1a: Wireless MediumAccess Control (MAC) and Physical Layer (PHY) specifications forWireless Personal Area Networks (WPAN)”. In: IEEE Std. 802.15.1-2005 (2010).

[27] Erina Ferro and Francesco Potorti. “Bluetooth and Wi-Fi wireless pro-tocols: a survey and a comparison”. In: Wireless Communications, IEEE12.1 (2005), pp. 12–26.

[28] Bluetooth SIG. bluetooth.com, last accessed May 25, 2016. http://bluetooth.com/.

[29] Vasileios Karagiannis et al. “A survey on application layer protocols forthe internet of things”. In: Transaction on IoT and Cloud Computing 3.1(2015), pp. 11–17.

[30] IDC Research Inc. Smartphone OS market share, last accessed April 08,2016. http://www.idc.com/prodserv/smartphone-os-market-share.jsp.

[31] Identive USA. identive.com, last accessed May 06, 2016. http://www.identiveusa.com/contactless-mobile-reader-scl3711.htm.

[32] Sony. Sony RC-S360/S, last accessed May 26, 2016. http://www.sony.net/Products/felica/business/products/RC-S360.html.

[33] Belkin USA. Belkin USA Site – Mini Bluetooth R� V4.0 USB Adapter,last accessed June 8, 2016. http://www.belkin.com/us/support-product?pid=01t80000003Hgu9AAC.

[34] NIST/SEMATECH. e-Handbook of Statistical Methods, last accessedMay 25, 2016. http://www.itl.nist.gov/div898/handbook/pmc/section3/pmc324.htm.

[35] w3schools.com. Browser Statistics, last accessed June 6, 2016. http://www.w3schools.com/browsers/browsers_stats.asp.

[36] Adrian Stabiszewski. Google code page of nfctools, last accessed March24, 2016. https://code.google.com/archive/p/nfctools/.

[37] libnfc.org. libnfc wiki, last accessed March 24, 2016. http://libnfc.org.

[38] ikelos. pynfc on github, last accessed March 24, 2016. https://github.com/ikelos/pynfc.

[39] Stephen Tiedemann. nfcpy’s homepage, last accessed March 24, 2016.https://nfcpy.readthedocs.org/en/latest/.

[40] BlueCove Team. BlueCove’s homepage, last accessed March 24, 2016.http://bluecove.org/.

[41] Nathan Rajlich. Websocket library for Java, last accessed May 25, 2016.http://java-websocket.org/.

60

http://bluetooth.com/

http://bluetooth.com/

http://www.idc.com/prodserv/smartphone-os-market-share.jsp

http://www.idc.com/prodserv/smartphone-os-market-share.jsp

http://www.identiveusa.com/contactless-mobile-reader-scl3711.htm

http://www.identiveusa.com/contactless-mobile-reader-scl3711.htm

http://www.sony.net/Products/felica/business/products/RC-S360.html

http://www.sony.net/Products/felica/business/products/RC-S360.html

http://www.belkin.com/us/support-product?pid=01t80000003Hgu9AAC

http://www.belkin.com/us/support-product?pid=01t80000003Hgu9AAC

http://www.itl.nist.gov/div898/handbook/pmc/section3/pmc324.htm

http://www.itl.nist.gov/div898/handbook/pmc/section3/pmc324.htm

http://www.w3schools.com/browsers/browsers_stats.asp

http://www.w3schools.com/browsers/browsers_stats.asp

https://code.google.com/archive/p/nfctools/

http://libnfc.org

http://libnfc.org

https://github.com/ikelos/pynfc

https://github.com/ikelos/pynfc

https://nfcpy.readthedocs.org/en/latest/

http://bluecove.org/

http://java-websocket.org/

[42] Quality Open Software. Simple Logging Facade for Java (SLF4J), lastaccessed May 25, 2016. http://www.slf4j.org/.

[43] Thomas Rørvik Skjølberg. NDEF Tools for Android - git, last accessedApril 28, 2014. https://code.google.com/p/ndef-tools-for-android/.

[44] Jeffrey Rubin and Dana Chisnell. Handbook of usability testing: howto plan, design and conduct effective tests, 2nd edition. John Wiley &Sons, 2008.

[45] Google. Google 2-step verification, last accessed May 25, 2016. https://www.google.com/landing/2step/.

[46] Jordi Solsona Belenguer et al. “Immaterial materials: designing with ra-dio”. In: Proceedings of the Sixth International Conference on Tangible,Embedded and Embodied Interaction. ACM. 2012, pp. 205–212.

61

http://www.slf4j.org/

https://code.google.com/p/ndef-tools-for-android/

https://code.google.com/p/ndef-tools-for-android/

https://www.google.com/landing/2step/

https://www.google.com/landing/2step/

7. Appendix

Figure 7.1. Mail from Phil Baggins.

Figure 7.2. Mail from Google Drive - Invitation to edit.

62

Figure 7.3. Mail from Facebook.

Figure 7.4. Mail from Isabella Knutsson.

63

Figure 7.5. Mail from Kivra.

64

Informed Consent Agreement Please read this consent agreement carefully before you decide to participate in the study.

Purpose of the research study: The purpose of this study is to investigate the usability and utility of the NFCLogin prototype.

What you will do in the study: You will log in and log out using NFCLogin and do office tasks like editing and printing a document. After the study there will be a short interview.

Time required: The time required for study and interview is approximately 45 minutes.

Risk: There are no anticipated risks in this study.

Benefits: There are no direct benefits to you for participating in this research study. The study may help us to understand how the NFCLogin prototype is perceived and could be improved.

Confidentiality: All data collected and stored will be completely anonymous. Your information will be assigned a code number but no list linking code number to your name will be created.

Voluntary participation: Your participation in the study is completely voluntary.

Right to withdraw: You have the right to withdraw from the study at any time without any penalty.

How to withdraw: If you want to withdraw from the study just tell the researcher and leave the room. There is no penalty for withdrawing. You will still receive full remuneration.

Remuneration: You will receive one cinema voucher (worth 100SEK) for participating in the study.

If you have questions about the study, contact:

Mikael Laaksoharju Department of Information Technology Uppsala University Box 337 751 05 Uppsala Tel: 018-471 3599 email: [email protected]

Agreement: I agree to participate in the research study described above.

Signature:_______________________________________________ Date:_________________

Pre-test survey 1. How old are you?

_____________

2. What gender? _____________

3. What is your main occupation? o student o employee o other: _______________________

Pre-test interview 1. In a situation with other people working/studying in the same room - what

are your usual habits when leaving your computer for a few minutes?

2. Do you have noteworthy security habits or settings concerning Google?

Post-test interview Thank you for testing NFCLogin - now I have a few follow-up questions!

1. How did you experience logging in? Can you describe what happened?

a. What happened? i. On mobile

ii. On computer?

b. What did you expect to happen when logging in? c. Was there anything you reacted on?

d. (How did it feel?) e. Did you notice anything while logging in?

i. The second time? ii. Did you notice your tabs opening?

1. What disadvantages or advantages do you see with that? f. Advantages or disadvantages with logging in? g. What about the time it took to log in?

2. How did the log out happen?

a. Did you notice it? b. (Did the system log you out?) c. Did you get logged out when you expected to be logged out? d. What did you expect when logging out? e. When did you get logged out?

i. How did that feel?

3. Do you see advantages or risks with logging in and out automatically? a. If you compare it to different log in/log out methods? b. How trustworthy would you say that it is?

4. How do you think the app logged you in technically?

a. (you were logged in through password, which was sent via blt) b. In this case it was Johannas account, how would it feel with your own? c. How would it feel with your own password? d. Do you see advantages/Risks with storage?

5. If NFCLogin would be on your phone, would you use it? a. Can you imagine a situation in which this kind of system would be useful?

i. Home ii. With others?

b. Instead of not logging out/in at all?

6. Imagine you’re working at your computer in a room with other people and lock your computer and leave for a short errand.

a. Do you see any advantages/disadvantages with that? b. How does it feel to lock the computer before leaving?

7. Imagine you’re working at your computer in a room with other people, leave for a short errand and the computer logs you out.

a. Do you see any advantages/disadvantages with that? b. How does it feel that the computer is logging out automatically?

8. Do you see any social advantages/risks with either of the situations? a. Does the app make logging out more socially acceptable?

Finally: Anything else I’ve missed, anything you would like to say? Is there any feature you would like NFCLogin to have? Anything that could improve it or anything that was missing for basic functionality?

Documents

Usable Security - DiVA portaluu.diva-portal.org/smash/get/diva2:943682/FULLTEXT01.pdf · 2016-06-28 · Usable Security A seamless user authentication method using NFC and Bluetooth