Pico: No More Passwords!

Hsing Ping Fu

Thesis submitted for the degree ofMaster of Science in

Electrical Engineering, optionEmbedded Systems and Multimedia

Thesis supervisor:Prof. dr. ir. Bart Preneel

Assessors:Prof. dr. ir. Patrick Wambacq

Dr. ir. Stefaan Seys

Mentors:Dr. ir. Jens Hermans

Dr. ir. Roel Peeters

Academic year 2012 – 2013

c© Copyright KU Leuven

Without written permission of the thesis supervisor and the author it is forbiddento reproduce or adapt in any form or by any means any part of this publication.Requests for obtaining the right to reproduce or utilize parts of this publication shouldbe addressed to Departement Elektrotechniek, Kasteelpark Arenberg 10 postbus2440, B-3001 Heverlee, +32-16-321130 or by email info@esat.kuleuven.be.

A written permission of the thesis supervisor is also required to use the methods,products, schematics and programs described in this work for industrial or commercialuse, and for submitting this publication in scientific contests.

Preface

In the beginning of making this thesis I barely believed that I could actually finishthis thesis. I had no experience in programming in Java, not mentioned in Android.I would like to take this opportunity to present my sincere gratitude to those whohave helped me in this year.

To begin with, I would like to thank my supervisors, Roel and Jens, for theirpatience on me and devotion in this thesis. I would not be able to finish thisthesis without their guidance and encourages. Thank you for providing me a testsmart phone and a demonstration server, these things contributes greatly in theimplementation of the prototype. And special thanks to Roel for correcting mythesis, and sharing great experiences on academic writing. I am very glad, mostof the time, that I chose Pico as a companion during the adventure of studying inKULeuven.

I appreciate Professor Preneel’s help when I am deciding my thesis topic, and hiskindness in explaining and arranging this thesis for me. I am lucky to be able tosettle down my thesis topic at the beginning of the semester. I would like to thankthe jury for reading my work, and participated in the thesis proposal presentation.Also, I wish to thank Sara for reviewing my thesis carefully and encouraged me whenI felt stressful on the writings.

Writing this preface also means the one year study in Leuven is going to end. Iam very grateful to my home institute NCTU and KULeuven for making this journeyhappen. And Silicon Motion for their financial sponsor on my scholarship, whichallows me to explore around Europe and eat better in the busy days.

I want to thank every one of my friends here in Leuven, Roos, Bass, Joanna, Liu,Carl, Orman, Kuang Yu, Jacky, Tzu Ting, Eleonoor and Eleanor, Fang Wei, Nicolo,Tian Li, people in Don Bosco Peda, and many many more. It is a great pleasure forhaving you as accompanies, and sharing the ups and downs together with me. Also,my friends in Taiwan who made me laugh in the late nights, the EE99s, 317a people,girls from high school, and many more, I want to thank you all for supporting mefrom afar, and listen to my stories.

I would like to thank Jason for being there for me as always. Last but not least,my dear family, mom, dad, and Edward, for encouraging me to apply for exchangein KULeuven, and comforting me all the time. I really wish that you can experiencethis wonderful journey, too.

Hsing Ping Fu

i

Contents

Preface iAbstract ivList of Figures and Tables v1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Literature Review 52.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Pico Funtionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Design of Pico 173.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 The Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 The Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Implementation 274.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3 Program Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Evaluation 435.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2 Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Conclusions and Future Work 516.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

ii

Contents

Bibliography 55

iii

Abstract

Managing passwords for online application accounts is a heavy responsibility for users.Using easily remembered passwords or repeatedly using the same password makesthe account susceptible to brute force guessing. Furthermore, the password-protectedaccounts are vulnerable to attacks like phishing, keylogging, eavesdropping, andman-in-the-middle attacks, no matter how strong the passwords are. Hence theurgent need for an alternative to password system.

Stajano proposed a candidate known as Pico [37]. This is an authenticationhardware token utilizing mutual authentication with the application server to obtainaccess to users’ accounts. The credentials for the authentication are created andmanaged by Pico and are guaranteed to be secure and unique for each application.The Pico device is portable and easy to use, allowing users to login everywhere.Compared to other existing password alternatives, Pico has the advantage of pro-viding protection against the attacks mentioned above and effortless access controldevice.

Although Stajano presents desirable functionalities in for the Pico, its practi-cality remains to be demonstrated. Toward this goal, this thesis proposes a set ofspecifications for the Pico device, and a prototype device to demonstrate the Picofunctionalities. The specification defines authentication protocols, the underlyingcryptographic algorithms, and the credentials. The protocols mutually authenti-cate Pico and the server, over an encrypted channel protected by mutual secretfrom key exchange algorithms. The servers are verified by credentials registered inPico database, to prevent internet phishing. Moreover, out-of-band communicationschemes and message structures for all the communication between Pico and serversare specified as well.

The technical specifications are implemented on a smartphone based Pico proto-type. The algorithms are programmed in Java and executed on Android platform,using several Android libraries. This prototype is capable of performing crypto-graphic calculations, wireless communication, and providing a proper user interface.A demonstration server is also implemented to test the entire Pico system. As aresult, users can log on to this server by pointing the Pico prototype to the QR codedisplayed on the web page, and the account can be accessed within few seconds.

iv

List of Figures and Tables

List of Figures

2.1 State diagram of Pico [37] . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Example QR code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Visual hash of "Foo" and "Boo" . . . . . . . . . . . . . . . . . . . . . . . 102.4 Basic STS protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 ISO protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 SIGMA protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.7 AES-GCM encryption flow [27] . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Pico login procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Higher security level Pico enrol protocol . . . . . . . . . . . . . . . . . 213.3 Lower security level Pico enrol protocol . . . . . . . . . . . . . . . . . . 223.4 Communication targets of Pico . . . . . . . . . . . . . . . . . . . . . . 23

4.1 Software architecture of Pico system . . . . . . . . . . . . . . . . . . . 274.2 Java Cryptography Architecture(JCA) [30] . . . . . . . . . . . . . . . . 294.3 QR code structure for enrol and login functions . . . . . . . . . . . . . . 344.4 Basic message structure in Pico protocols . . . . . . . . . . . . . . . . . 354.5 Life cycle of AsyncTask . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.6 State diagram of Pico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.7 Screen shots of user interface . . . . . . . . . . . . . . . . . . . . . . . . 394.8 Flow diagram of executing Pico functions . . . . . . . . . . . . . . . . . 40

5.1 Time line of main events in one Pico operation . . . . . . . . . . . . . . 465.2 Timing comparison of different functions in Pico . . . . . . . . . . . . . 47

List of Tables

2.1 Desired properties for the Pico . . . . . . . . . . . . . . . . . . . . . . . 6

4.1 Security levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Contents of an entry in Pico’s database . . . . . . . . . . . . . . . . . . 334.3 Summary of specifications . . . . . . . . . . . . . . . . . . . . . . . . . . 41

v

List of Figures and Tables

5.1 Execution time of different elliptic curves in milliseconds . . . . . . . . . 465.2 Execution time of Pico in milliseconds . . . . . . . . . . . . . . . . . . 485.3 Evaluation of achievements . . . . . . . . . . . . . . . . . . . . . . . . . 50

vi

Chapter 1

Introduction

1.1 Motivation

The password system has safeguarded our confidential information in online applica-tions for years. Each attempt to access an application account must pass certainauthentication procedures that verify user ID and password. As more and moredaily life services become available online, users have to manage more accounts andpasswords. Users are moreover restricted by strict password rules when setting upan account, such as including upper- and lower-case letters with at least one numberand a special character. This is because passwords that are easy to remember arealso insecure against dictionary attack or brute force guessing [24]. Thirdly, a studyconducted by Bonneau and Preibusch [6] states that repeatedly using the samepasswords renders highly-protected sites by cracking other badly managed passwordservers. Some application servers even request users to change those complicatedpasswords periodically, making them even harder to remember.

Another problem appears when users arrive at the login page. To avoid otherseavesdropping the passwords over the shoulder, the keyed in characters are shownas *******. Because of this, typing mistakes are difficult to notice until warned byerror messages from the web page. This could be troublesome especially for thosesites that limit the number of password re-entering. Once the limitation is reached,users have to go through a trivial procedure to reclaim the access to their accounts.

Even if users obey all the password regulations, Florencio et al. [16] point outthat the security is still threatened by attacks such as keylogging and phishing. Theformer steals password by recording key board strokes via a virus or trojan horse inthe victim’s computer. The latter is conducted by malicious attackers masqueradingas a trustworthy entity, deluding the users into disclosing their credentials. Otherthreats such as man-in-the-middle or replay attacks can also compromise securityif the communication channels and authentication protocols are inappropriatelymanaged.

A good access control mechanism should not sacrifice either security or conve-nience. Adams et al. [1] states that it is the regulations that lower the securitymotivation among users, by making them unwilling to consistently conduct the

1

1. Introduction

complicated security practices.Because of the problems existing in the password system, other access control

mechanisms have been studied. These alternatives include desktop and browserplug-in password wallets [23], [33], single-sign-on(SSO) systems [14], [29], biometricauthentication [2], [10].

Password wallets generate strong passwords and manage them for the users.However, study by Chiasson et al. [9] shows that password wallets are not acceptedby users in general; and it is still susceptible to certain malicious attacks. Onthe other hand, SSO systems, proposed by Pashalidis and Mitchell [32], are moreintuitive and effortless since users only have to sign in on one or two applicationsand they can access other relying applications. Users must be careful to use onlythe well-secured SSO servers, or else active attacks are still a threat [39]. Contraryto the password wallets, SSO systems can be accessed where ever internet accessare available, without installing extra software. Lastly, biometric characteristicscan be used as authentication tokens as proposed by Hao et al. [18]. This type ofauthentication tokens is convenient, but is insecure and expensive.

Although the alternatives mentioned above perform better than password systemin certain aspects, research done by Herley and Van Oorschot [19] state that theconcept of the password has already been deeply implanted in users mind. Thus,unless the new proposal outperforms passwords significantly, users might have lowmotivation to accommodate to the new system.

In 2011, Stajano [37] proposes Pico, a token based authentication device as analternative for managing access control to every kind of applications. Using Piconot only relieves the memorization effort for users, but the device is also resistantto attacks like keylogging, phishing, replay attack, and man-in-the-middle attack.It could be scaled to manage various types of credentials, not only limited to webapplications. Moreover, the continuous authentication feature of Pico automaticallylocks itself when users are out of range from their computers. When Pico is stolenor lost, it also locks itself so that no one can access the credentials inside. The paperalso mentions that Pico could be modified to manage not only web applications,but also daily life objects, such as doors or electronic safe.

The above functionalities indicate that Pico is more secure and convenient thantraditional password systems. However, one difficulty arises when attempting toexamine the usability issue of Pico, as pointed out by Herley et al. [19]. Stajanoonly proposes the functionalities, but missing the design details of the actual Picodevice.

1.2 Goal

Currently, the lack of technical specifications for Pico makes it a doubtful alternativeto password based authentication systems. To overcome these obstacles, we proposein this thesis a set of concrete specifications for Pico and an implementation of Picoprototype. The specifications include cryptographic algorithms and communicationprotocols that satisfy the security requirements imposed by Stajano [37]. Based on

2

1.3. Overview

these specifications, a prototype device is realized on Android based smart phone.This implementation satisfies the security requirements and accomplishes mainfunctionalities of a Pico and is able to communicate with a test server. Using thereal device, we can evaluate the practicality and usability of Pico to assess whetherit is indeed as user friendly as it promised to be.

1.3 OverviewIntroduction and motivation are given in this chapter, Chapter 2 looks deeper intoStajano’s work, and provide the necessary background for the next part of the text.Chapter 3 explains the proposed protocols for authentication between Pico andapplications. Technical specifications and implementation details are provided inChapter 4, with performance analysis and results given in Chapter 5. Finally, thethesis is concluded in Chapter 6.

3

Chapter 2

Literature Review

The conventional password system and some of its alternatives mentioned in theprevious chapter are either insecure or considered unacceptable by users. Thisincreases the interest in the Pico system, proposed by Stajano [37] in 2011. Inthis chapter, the main idea of Pico system and implementation related backgroundinformation is provided.

2.1 Introduction

The principal feature of Pico is that it can authenticate itself to application servers,and the vice versa, so that users can access their accounts safely and easily. Thisprocedure is executed without typing or memorizing any passwords. There areadditional supporting functionalities to protect the Pico device itself, and to extendthe use of this system to non-web applications.

In Section 2.2, the functionalities of Pico and the desirable features described inthe original paper are introduced. The proposed design is based on these concepts.The algorithms and components that are capable of implementing the functionalitiesare described in Section 2.3.

2.2 Pico Funtionalities

Table 2.1, summarized from Stajano [37] lists all the desired properties of Pico. Picois implemented on a small portable device that users can carry along easily, so their ac-counts can be accessed FROM-ANYWHERE. Basic requirements include no memorizationof passwords, and being flexible to different applications (MEMORYLESS, SCALABLE,WORKS-FOR-ALL). Pico also has a friendly user interface that guarantees to beMEMORYLESS, NO-SEARCH, and NO-TYPING. The underlying security mechanisms satis-fies SECURE, NO-WEAK, NO-REUSE, NO-PHISING, NO-EAVESDROPPING, NO-KEYLOGGING,NO-SURFING, and NO-LINKAGEproperties.

5

2. Literature Review

Table 2.1: Desired properties for the PicoM

inim

umMEMORYLESS End-users should not have to memorise any secretsSCALABLE Scalable to thousands of applicationsSECURE Security level comparable to passwordsLOSS-RESISTANT End-users can regain access to applications after losing the PicoTHEFT-RESISTANT Thieves of a Pico cannot impersonate the end-user

Des

ired

WORKS-FOR-ALL For all credentials, not just internet application passwordsFROM-ANYWHERE End-users can authenticate from any clientNO-SEARCH End-users do not have to select the correct credentialsNO-TYPING End-users do not have to typeCONTINUOUS Authentication is continuousNO-WEAK End-users cannot choose weak passwordsNO-REUSE End-users cannot reuse credentials with different applicationsNO-PHISING Phising (application impersonation) is impossibleNO-EAVESDROPPING Network eavesdropping is impossibleNO-KEYLOGGING Keylogging is impossibleNO-SURFING Shoulder surfing is impossibleNO-LINKAGE Different credentials from the same end-user cannot be linked

Ext

ra

NO-COST As cheap to deploy as passwordsNO-APP-CHANGES Deployable without changing existing applicationsNO-CLI-CHANGES Deployable without changing existing clientsNO-TTP No reliance on a Trusted Third Party that knows your credentials

2.2.1 Core functionalities

Contrary to most password systems, Pico identifies itself and the user to applicationservers directly. Both Pico and server stores pre-established credentials in theirdatabase to authenticate each other. The whole challenge-response proceduresare executed in an encrypted channel. After finishing the process, continuousauthentication is performed until users leave the client browser.

There are two essential buttons in Pico representing the main and pairingfunction. The former executes the login process, and the latter is used to establisha new entry for a new application. To start an operation, users press one of thebuttons, and point Pico toward the 2D visual code displaying on the applicationweb page. This image contains a hash of the server’s self-signed certificate and ahuman-readable name. The process of obtaining server’s identification through asecondary communication channel, which is capturing images by camera, is calledout-of-band (OOB) communication.

The purpose of main is to gain the access right for a registered application. Atthe beginning of this procedure, Pico sends a temporary public key to the server toestablish an encrypted channel. It first verifies the server by checking the possessionof the private key corresponding to server’s public key, which is stored in Picodatabase. It then replies to the server with a (userid, credential) pair for the server

6

2.2. Pico Funtionalities

to verify user. Once both sides recognize each other, server grants the access rightto the content of the user’s account, and set up a session for subsequent continuousauthentication.

Pressing the pairing button is equivalent to creating a new account. Considertwo different scenarios, one in which the application has a prior relationship withuser, such as online banking accounts, and one without, like online social networks.After retrieving information on the login page as in the first step of main, Picoconsults the user to know whether to continue or not if the target application alreadyexists in its database. If the answer is positive, Pico starts authentication with theserver. In the case of a prior relationship, Picoauthenticates the server based onthe information passed to user before pairing. This information contains two visualcodes; one is a hash of server’s public key and a nonce specifically for this Pico. Inthe second case, a malicious application could masquerade as the real applicationbecause there is no information to verify the server.

The pairing process begins with Pico acquiring a complete public key throughradio. For the first case, Pico checks whether this key and the obtained visual codeare identical, and stop if they are inconsistent. If they are identical Pico continueswith setting up an encrypted channel, and verifies the possession of the correspondingprivate key of server. The server also expects Pico’s public key, and registers it inits database. If the server needs to associate the user with his or her Pico Picohas to present the encoded nonce to server. Once the account is established both inPico and the server’s database, Pico will only communicate with the server it hasbeen paired with.

These two core functionalities satisfy several desirable properties mentioned inTable 2.1. Pico handles the authentication processes with the credentials in itsdatabase, providing MEMORYLESS, NO-SEARCH, and NO-TYPING. Given a proper genera-tion mechanism, credentials generated by Pico have SECURE, NO-WEAK, NO-REUSE, andNO-LINKAGE features. Also, with secure protocols for main and pairing function, itwill have SCALABLE, NO-PHISING, NO-EAVESDROPPING, NO-KEYLOGGING, NO-SURFING,and NO-TTP features.

2.2.2 Other functionalities

The two functions described above alone cannot guarantee all the properties thepaper promised, other supporting facilities are required to complete the Picosystem. Stajano also discusses possible solutions that solve the WORKS-FOR-ALL,THEFT-RESISTANT, LOSS-RESISTANT, and CONTINUOUS issues.

Interaction with non-web applications

Stajano points out that Pico device should be able to communicate with devices orapplications other than websites. In other words, Pico not only manages internet-related passwords, but it can also replace the keys of the house, car, or access safedeposits. Pico uses pattern recognition technique to identify a lock, and directly

7

2. Literature Review

perform same authentication process using main and pairing with the micro-controllerwithin the lock. It can be used to organize access control in our daily life.

Locking and unlocking Pico

The safety of the credentials relies on securing the Pico using a Master Key, andlocking the device when necessary. As depicted in Figure 2.1, it transit betweenthe UNLOCKED and LOCKED states after leaving IMPRINTABLE state. Since manuallychosen PINs as the Master Key could violate NO-WEAK, NO-REUSE, and MEMORYLESS,Pico distributes its Master Key among different shares, known as the Picosiblings.Picosiblings are small objects that surround users in their daily life, such as glasses,belt, or wallet, having a short range radio being able to talk with the Pico . Alongwith other two special shares, the Master Key can be reconstructed using k-out-of-nsecret sharing schemes [36]. One of the two special shares must be biomedicalmeasurement of the owner, and the other should be kept by a remote server.

When sufficient Picosiblings are in the neighbor and the two special shares areactivated, Pico can safely unlock itself; otherwise, it will remain locked. Pico has atable recording each paired Picosibling, and sets a decay counter for each of them.This counter starts counting down when Picosibling first pings PicoOnce the countershows time out, the Master Key is reconstructed again by finding current in-rangeshares. Since main and pairing operate in UNLOCKED state, a stolen or lost Pico isnot capable of providing any credential since it would be locked, which provides theLOSS-RESISTANT, and THEFT-RESISTANT properties.

Figure 2.1: State diagram of Pico [37]

Backup

Another feature mentioned by Stajano is an automatic backup routine. To preventloss or accidentally destruction, regular backups must be taken. Since users shouldnot be hindered by the backup routine, Pico performs the backup when connected tothe charging dock. The dock can write the backups in a memory card and provides

8

2.3. Building Blocks

user interface to manage the backups if necessary. These backup files can be restoredin an imprintable Pico and then be accessed when it is unlocked, as depicted in 2.1.

Continuous authentication

Pico offers an auto-logout feature to replace manually disconnecting from theapplication. This is accomplished by continuously authenticating each other throughthe protected channel established in the initial mutual authentication process. Thecontinuous authentication process notifies the server the presence of Pico so thatserver can block access to the account while Pico is out of range. The authenticationcredentials in this process should be freshly generated at every pass, otherwise replayattack might use the stale messages to impersonate the user. A range detectordecides when Pico stops pinging the server by sensing the range between Picoand the client computer. For example by using near field communication devicesor RFID tag implemented in computers, the computer can manage the continuousauthentication session by periodically detect whether Pico is within a certain range.If the Pico is out of range, the logged in application cannot be accessed until Picoshows up and logs in again.

2.3 Building Blocks

This section provides an introduction to the communication and cryptographicmodules required to support the aim of this thesis, setting up concrete cryptographicspecifications and implementing a prototype of the PicoThe introduction begins without-of-band communication, followed by cryptographic modules. In the cryptographicaspects, we first mentioned briefly the basic components in authentication protocols,and then compares different type of existing protocols that might suit the requirementsin Pico .

2.3.1 Out-of-Band communication

In addition to the main communication channel in a Pico system, an out-of-band(OOB) channel must implemented to extract information from the user’sbrowsers, and to serve the verification purpose of pairing in Section. 2.2. There aretwo contemplate solutions suitable for serving these purposes, QR code and visualhash.

QR code

A QR code is a type of matrix barcode containing encoded symbols and finderpatterns to locate the code. QR codes can process four different types of data,numeric, alphanumeric, binary and kanji [20]. A typical QR code is shown inFigure 2.2, the coded modules are arranged in a square with finder patterns locatedat three corners. The amount of input data determines the QR code version definedin the QR code standard [20], with the highest version containing up to 4296

9

2. Literature Review

alphanumeric characters. Moreover, QR codes also feature different levels of errorcorrection capability, so that they can tolerate a certain amount of disturbance inthe matrix. The actual printing size of a QR code depends on the resolution of theprinter and the scanner, and the complexity of the code matrix itself. For instance,the data capacity of a QR code with 3 cm edges displayed on a web page is around365 alphanumeric characters with medium level of error correction ability. This is adecent data size for the out-of-band channel between Pico and the target login pageon browser.

Figure 2.2: Example QR code

Visual hash

As mentioned by McCune et al. [28], visualization data can also be used as an OOBcommunication channel. This OOB channel is able to deliver authentication valuesin a way that is easily understood by humans. Visual hashes translate data bits intoimages, so that they are easily recognized by human, e.g. the algorithms provided instudy of Perrig and Song [34].

(a) "Foo" (b) "Boo"

Figure 2.3: Visual hash of "Foo" and "Boo"

There are only a few implemented visual hash functions, such as "vash"[38],"identicon"[31], and similar concept "robohash"[11], although this last one is not anideal hash function. An example of vash is as in Figure2.3, the visual hash for "Foo"and "Boo", which is very different although the encoded texts differ in only one letter.

2.3.2 Mutual Authentication Protocols

In this section, we discuss various kinds of mutual authentication protocols andcompare the efficiency and security against several attacks. The basic requirements

10

2.3. Building Blocks

of a key exchange protocol are to have authentication, secrecy, and consistency.Authentication means that each party in the key exchange session has to be able toverify the identity of the peer. To ensure secrecy, no third party should be able togather information about the exchanged key. Finally, the protocol needs to guaranteethat each party in the key exchange session has a consistent view on each other.I.e., if Alice wants to exchange key with Bob, then Bob should also know that he isestablishing key with Alice.

Mutual authentication protocols are established based on public key cryptography.The two most popular public key cryptographic algorithms are RSA and ellipticcurve cryptography(ECC). The former has been widely adopted since 1997, but isgradually replaced by latter. Compared to RSA, ECC provides better performanceand shorter key length, which is beneficial for both speed and storage space. Hence,in this thesis, we choose ECC as the public key algorithm.

Both algorithms can also be used to implement digital signature and Diffie-Hellman key exchange scheme. Digital signature schemes sign a message with signer’sprivate key, so that others can verify the signature using signer’s public key. Diffie-Hellman algorithm is used to generate a mutual secret between two parties through apublic channel without needing a third party. In the remainder of this text, a public,private key pair is represented as (X, x), where X = xP , with P a point on givenECC curve. The digital signature on message m signed by signer A’s private key iswritten as SIGA(msg).

2.3.3 Adversarial model

Consider an active attacker, also known as a "man-in-the-middle", who has fullcontrol over the communication channel between the two parties. This attacker canmodify, delay the message, interleaving his own messages between the messages ofthe two parties, or impersonate others. Note that, it is undesirable to reveal the trueidentity of the two parties to the adversary. The security of the following protocolsare evaluated base on this adversarial model.

2.3.4 Basic Station-to-Station protocol

Station-to-Station (STS) key exchange protocol [13] is a three pass protocol thatimplements Diffie-Hellman key exchange and mutual authentication. The messagesequence chart of the STS protocol is shown in Figure 2.4. In this protocol, eachparty generates their key pairs (public key, private key) as (X, x), and (Y, y). Theinitializer A starts by sending X to responder B. After receiving X, B can generatethe mutual key Ks, and use it as the secret key for symmetric key encryption {}Ks

for later messages. The signature SIGB() ensures that X is indeed coming from B,which can be verified with B’s public key. This public key is usually derived froma certification authority certified public key, or obtained through a secure channelprior to the key exchange session. Since the signature is protected by symmetrickey encryption, malicious attackers cannot modify or replace the signature by theirown. Note that the exchanged key parameter X and Y should be unique among

11

2. Literature Review

different sessions in order to prevent replay attacks. Furthermore, if one party istaken over by the attacker, computationally independent session keys can protectforward secrecy. In this case, the past secret communication would not be disclosedby the corrupted party.

Figure 2.4: Basic STS protocol

However, the STS protocol is susceptible to a misbinding attack. Considera malicious attacker Oscar who registers A’s public key as his own. During thecommunication, since the identity field is not encrypted, Oscar can replace it with hisown identity, so that B thinks he is communicating with Oscar, violating consistencyproperty. Secondly, using symmetric key encryption modes such as CBC, whichXOR the secret cipher with message at the end, is not a proper method to prove thepossession of mutual key. If the attacker XORs the cipher text with the plain text,then the secret key information is revealed.

2.3.5 ISO protocol

The ISO protocol [21] is similar to the STS protocol, which makes use of digitalsignature and Diffie-Hellman key exchange to complete mutual authentication andkey establishment. The vulnerability to identity misbinding attacks in STS is solvedin ISO by including the identity in the signed part of the message, as in Figure 2.5.Thus, this protocol provides authentication with consistency, and ensures the secrecyof the exchanged key.

One advantage of ISO is that it postpones the calculation of the mutual secretXY to the end of the session. It is also a compact algorithm in the sense thateach element is essential for its security. However, ISO lacks identity protectionbecause it sends the identity in plain text, which is disclosed to any third party.This is not desirable when considering privacy issues. Another privacy related issueis that in this protocol, each party leave a signed trace in the other’s hand, sinceA’s identity is signed by B’s secret key. The signed trace makes the communicationbetween two parties undeniable. However, deniability is often preferred in personalor business communication when off-the-record conversation is necessary[12]. In this

12

2.3. Building Blocks

Figure 2.5: ISO protocol

case, deniability conflicts with protection of consistency, so this protocol can only beapplied to non-repudiation specific applications.

2.3.6 SIGMA protocol

The SIGMA protocol [26] is adopted in current Internet Key Exchange(IKE) pro-tocol. It has the advantage of STS allowing parties to authenticate to each otherwithout knowing their peer’s identity in advance. In ISO, the identity is includedin the signature in order to authenticate the DH elements and bind the identity tothe exchanged key. The SIGMA protocol realizes the same concepts using signa-ture on DH components and message authentication codes(MAC), representing byMACkm{message}, where km is the MAC key. This three-pass protocol is shownin Figure 2.6.

Figure 2.6: SIGMA protocol

The main difference between SIGMA and other protocols is the use of a MAC.In the second step, after signing the DH components, a MAC on sender’s identityensures that the two parties have consistent view on each other. The key used in theMAC is derived from the exchanged key, which must be computationally independentfrom the final session key. The signature in SIGMA includes only the sender and

13

2. Literature Review

the peer’s DH components, not the peer’s identity. Furthermore, the second elementin the signature can be either peer’s DH component or a nonce, but both of whichshould be generated freshly and independently for each session in order to maintainthe forward secrecy property.

Note that SIGMA allows the initiator A to authenticate responder B first. In thesecond step, if B failed to verify itself to A, A can refuse to continue the subsequentprocedures. This property is desirable when the initiator requires more protection.However, the basic SIGMA protocol does not have identity protection either, thisdisadvantage is modified in SIGMA-I, which is discussed in the following chapter.

2.3.7 Authenticated encryption

An authenticated encryption(AE) scheme is a symmetric key mechanism that providesboth confidentiality and authenticity on the encrypted message. The benefits ofauthenticated encryption are that it generates authentication tag and the ciphertext with the same key. Some of them encrypt only certain parts of a message andprotect the authenticity of the entire message. Schemes supporting this propertyare referred to authenticated encryption with associated data(AEAD) schemes. TheAEAD schemes can be categorized into two types, one-pass and two-pass schemes.Two-pass schemes compute the authentication tag after encryption, while one-passschemes computes both in parallel. The former has longer computation time, and thelatter has better timing performance. In this section, four popular AEAD schemesare reviewed, the first two algorithms are two-pass schemes, and the latter ones areone-pass.

CCM

AES-CCM[40] is a block cipher-based AEAD scheme which encrypts the messageusing counter mode(CTR) encryption and authenticates the message by cipher blockchaining message authentication code(CBC-MAC). The CCM mode is a two-passand off-line algorithm requiring prior knowledge of the message length. It takes fourinputs: block cipher key K, nonce N , message m, and additional authenticated dataa. First, the MAC of message and additional authentication data is generated usingN and K. The result is concatenated with m and encrypted in CTR mode using thesame K and N .

EAX

EAX [4] is a two-pass AEAD scheme based on block cipher, allowing on-the-flycalculation. The inputs to EAS algorithm are the same as CCM, but it generatesthe cipher and authentication tag in different order. First the authentication tagof N and a is generated by employing OMAC algorithm, which is a variant ofbasic MAC algorithm. Next, it encrypts m by CTR mode encryption and producesauthentication tag for this cipher text. The OMAC and CTR encryption use thesame block cipher key k. Finally, the three tags are XORed together to output

14

2.4. Conclusion

the authentication tag. Compared to AES-CCM, EAX has the advantage of onlinecalculation, but it is inefficient due to its two-pass nature.

OCB

OCB[35] is a patented one-pass AEAD algorithm based on block cipher operation. Itprovides confidentiality of m and authentication for a, N , and m. The block cipherand MAC used in OCB use the same key k. CTR mode is applied to encrypt m, anda checksum of the previous plain text message blocks is updated by combining withthe check sum of current message block. The output authentication tag is derivedby encrypting the final checksum and MAC of a. The fact that authentication tag isgenerated in parallel with encryption, and the flexibility on input length makes theOCB an efficient AEAD scheme. However, it’s main drawback is that it is patented.

AES-GCM

The AES Galois/Counter Mode(AES-GCM) is an AES mode of operation providingAEAD feature. AES-GCM assures the confidentiality of data using CTR mode,and authenticity of the confidential data and/or the additional authentication datausing a hash function defined over Galois field operations. This hash function iscalled GHASH, which claimed in the standard of AES-GCM[27] to have strongerauthentication assurance compared to traditional checksum. AES-GCM takes thesame input as previous schemes, and can be separated into two parallel paths, CTRand GHASH. The GASH value of additional data a is calculated first, as mult inFigure 2.7. After generating the cipher text of one message block in CTR, the ciphertext and the previous GHASH value are feed into GHASH module together, as inFigure 2.7. When the CTR encryption is finished, the authentication tag will alsobe ready. Thus, AES-GCM is a one-pass and online AEAD scheme calculating theauthentication tag simultaneously with the encryption process.

Considering the security of the order of encryption and authentication operationsin AEAD schemes, Krawczyk[25] states that only encrypt-then-authenticate is secure.Neither encrypt-and-authenticate nor authenticate-then-encrypt are secure againstactive attackers; unless the underlying encryption method of authenticate-then-encrypt is either CBC mode or a stream cipher, which is not the case in the AEADschemes discussed. Among the four presented AEAD schemes, only EAX andAES-GCM have the encrypt-then-authenticate order. Thus, considering the parallelprocessing ability of the AES-GCM algorithm, it is the preferred solution.

2.4 Conclusion

This brief introduction to Stajano’s work [37] gives an overview of the Pico func-tionalities and properties. Pico offers several advantages over password systemsby sharing the user’s burden and managing the credentials. Pico also offers moresecure access control mechanism using mutual authentication.

15

2. Literature Review

Figure 2.7: AES-GCM encryption flow [27]

We also reviews several basic building blocks needed for the implementation.These building blocks include out-of-bound(OOB) communication methods, mutualauthentication protocols, and AEAD schemes. The QR code and visual hash areused to implementing OOB communication. We also consider SIGMA suitablefor realizing Pico and server authentication. For message protection, we selectAES-GCM, because it is the most secure and efficient AEAD scheme.

16

Chapter 3

Design of Pico

After reviewing the main functionalities of Pico in the previous chapter, our proposeddesign will be introduced in this chapter. This chapter provides detail explanationson how each previously mentioned building blocks is adopted in our design.

3.1 Introduction

Although Stajano [37] proposes a Pico with several benefits (listed in Table 2.1),practicality remains to be shown. Towards this goal, we design solid securityprotocols and clear specifications to show that the security requirements of Picoare feasible. We envision the Pico’s main use for managing web credentials, a setof particular protocols serving this purpose are presented. The proposed solutioncovers secure mutual authentication protocol for both main and pairing operations,and the continuous authentication process. We aim to apply these protocols onweb-application first, since these are the most well-known password applications.

Section 3.2 discusses the design criteria and consideration of Pico protocols.Based on these protocols, a model of Pico device can be established. This will bepresented in the Section 3.3.

3.2 Functionality

To minimize the effort to access user accounts, Pico should not demand any cre-dentials from user during authentication. Based on this virtue, our implementationmanages to minimize the burden on users down to only one click. In this thesis,the two core functionalities are called login and enrol, corresponding with main andpairing defined in the original paper. Once the user has created an account usingenrol, he or she can later login using Pico’s login function. For each function wedesign a secure solution to exchange secret and authenticate both parties. Sincethe underlying cryptography protocol in these two functions are fairly similar, theparagraphs below will explain the details of login first and then enrol.

17

3. Design of Pico

Figure 3.1: Pico login procedure

3.2.1 Login

The goal of the login function is allowing users to access their web accounts safely.To accomplish this, we adopt a modification of the SIGMA protocol mentionedin Chapter 2. Once the login procedure is done, users are able to enter theiraccounts, and a secure channel between Pico and server is established. The protocolis described in Figure 3.1. QR{} indicates QR code with encoded information inthe braces. AE{} indicates the plain text input that is encrypted in AEAD, AD{}stands for the authentication only parts. H() represents the hash function.

When users arrive at the login page, they first capture the QR code displaying onthe web page ( first line in Figure 3.1). This QR code is an out-of-band channel usedto transmit essential information about the current server. Encoding informationin QR codes can avoid over-the-shoulder observation of the information, becauseQR codes are only recognizable by machines, not by humans. Once the QR codehas been decoded by QR code decoder embedded in Pico, Pico gets the a header,serverID, and hashed sessionID from the server. The header here specifies that thisQR code encodes information for login. The sessionID belongs to the web page thatdisplays the QR code. Only the hashed version of sessionID is available here, becausethe real sessionID should be kept known only to the server and user’s browser toavoid attacks like session hijacking. Utilizing QR codes eliminates manually enteringinformation like server ID.

Based on the decoded information, Pico finds the corresponding server credentialsstored in its database according to the serverID. If the user indeed has an accountfor this server, Pico retrieves server’s public key and url address for later mutualauthentication. When users open an incorrect web site, they will notice when Pico

18

3.2. Functionality

informs users with user-defined server name before starting the actual login. On theother hand, if the serverID cannot be found, a new account might need to be set up.

After confirming the target server, Pico starts a mutual authentication process.This process ensures that the user is safely log on to the correct server. It beginswith generating a Diffie-Hellman(DH) pair, which R1 is the public key, and sendsit to server along with a header. The DH value should be generated freshly andindependently for each authentication process to avoid replay attack and guarantees"forward secrecy". This message is transmitted wirelessly through either 3G or Wi-Fi,which are two most popular wireless communication methods supported by variousdevices.

When the server receives R1, it generates its own pair of DH values and thencomputes the mutual secret K. Since the session requires two keys in total, onefor encrypting protocol messages and one for the continuous authentication session,the login key kx1 is independently derived from K, so does the other key, kx2, tomaintain forward secrecy. In order to authenticate server itself to Pico the servergenerates a signature using its digital signature key pair to sign on both Pico’sDH value and its own. Finally, the signature will be encrypted using authenticatedencryption with additional data (AEAD) scheme mentioned in Section 2.3.7.

Using AEAD scheme instead of encryption not only secure the data, but alsoprovide message authentication to the cipher text and other associated data that arenot encrypted. For instance the second message transmitted by the server, it containsthree essential elements: the signature, a header of Pico protocol, and server’s DHvalue. The signature should be encrypted and authenticated, and the two othersshould only be authenticated. Thus, the resulting streaming contains plain text forheader and server’s DH, an encrypted message, and an authentication tag for theentire message. We allow Pico authenticate the server first; thus, the server cannotdistinguish which Pico it is communicating with at this stage.

In the third phase, Pico first generates the mutual secret K and uses it to decryptthe AEAD message. Decrypting this message includes first checking the correctnessof authentication tag, and then decrypting the encrypted parts using session keykx1. If the authentication tag does not match with the tag generated by Pico, themessage must have been modified during transmission. The data can be modified bynetwork packet loss or malicious attacker, which Pico should terminate the session ineither case. The message authentication also proofs the consistency in key exchangeprotocol that Pico is indeed talking to the server it expects. After decrypting thecipher text, Pico verifies the signature on DH values by server’s public key stored inits database. Signature verification only succeed if the server is indeed the one thatPico registered with. The above verification steps protect Pico from threats suchas man-in-the-middle attack, or Internet phishing. The latter attack as well as otherweb attacks like, cross site scripting are especially dangerous in password-based loginsystems, but can be avoided in Pico.

Now that the server has verified itself to Pico, it is Pico’ s turn to identifyitself to the server. The message transmitted to server in third pass( see Figure 3.1)contains a header, Pico’s DH value, the Pico ID, a signature, and the sessionIDobtained from the QR code. The plain text includes Pico’s identity, the signature

19

3. Design of Pico

containing both DH values using Pico’s private key, and the sessionID. The PicoID serves as the account name in normal login, and the encryption provides identityprotection. Identity protection is a desirable feature in accessing sensitive informationsuch as online banking accounts. After verifying the authentication tag, the serversearches its database for the Pico ID, and the corresponding public key. If Pico IDdoes not exist or signature verification fails, the server will not permit any access tothe account. If both succeed, the server notifies the session indicated by sessionIDto provide further service.

In summary, the login protocol has following properties:

1. It competes mutual authentication for both Pico and server for getting accessto an account. The authentication process has the properties of confidentialityand integrity. More particularly, users( Pico) have the priority in checkingwhether the application is the desired.

2. It provides a key exchange protocol that guarantees safe mutual secret estab-lishment, and forward secrecy.

3. It manages the logged on session by continuous challenge-response requestsbetween the server and Pico, to prove the presence of users.

4. It reduces user’s efforts by using QR code and credentials in the Pico database.

3.2.2 Enrol

The login function depends successful enrolment. The enrol protocol must registerthe correct server in Pico’s database and Pico in server’s database. This requiresexchanging both parties’ public key and other related information, and should beprotected from malicious attacks. Two types of enrolment are considered, applicationsthat should be highly secured, which might be closely related to the user’s real life;and applications that the user does not want to entirely reveal his or her identity to.Online-banking accounts are an instance of the former case, and the latter could beFacebook or online gaming accounts. In this section, we presents the two types ofenrolment.

Higher security level applications

Applications that are established based on user’s real identity have stricter regulationsupon enrolment. Take KU Leuven’s online learning platform "Toledo" as an example,the account is issued by the KU Leuven authority after the student has registered.To activate a Toledo accounts, students have to type some pre-set passwords inthe login page and change the password to their own afterward. Servers in thistype of applications usually have prior communication with users before they enrolonline. More importantly, servers allow only the qualified users to enrol, not arbitraryrequests. Since this type of applications closely related to users’ credentials used indaily life, the enrol process should be executed more carefully.

20

3.2. Functionality

Pico has a specific enrol procedure for higher security level applications likeschool system and online banking system shown in Figure 3.2. The first step is anoffline message distributes by the server, it is a QR code printed on paper or anemail, which is assumed secure and only available to user. This message includesthe serverID, server public key serverPk, serverUrl, and nonce. The first threeelements are server information that should be registered in Pico’s database oncethe mutual authentication succeeds. The nonce in this message is important forserver to verify whether this user is the qualified one or not, and to correlate Pico tothe corresponding user. Pico then starts mutual authentication and key exchangeprocedures as in login.

As indicated in phase 3 in Figure 3.2, once the server is identified, Pico sendsback its ID and public key along with the nonce distributed by the server. The serverthen checks whether this is the qualified user by the nonce, and registers Pico’s data.Using the similar protocol as in login, the messages exchanged by both parties areprotected from malicious modifications, eavesdropping, and impersonation. Thus,Pico and server are guaranteed to register safely with the correct correspondent.

Figure 3.2: Higher security level Pico enrol protocol

Lower security level applications

Users have no obligation to reveal all their personal information to services likeFacebook, Twitter, or discussion board communities. Hence, Pico cannot registerthrough exactly the same method described as in previous section. For enrolmentin these applications, Pico should check the server’s identity, but the server shouldnot set any constraints on clients. We classify this type of enrolment as low securitylevel applications, and use a modified version of the enrol protocol, as depicted inFigure 3.3.

The rationale behind the lower security level application enrolment is establishinga secure method to demonstrate the server’s identity. This is being done by utilizinga visual hash algorithm. Visual hash algorithms translate text data into images, asmentioned in Section 2.3.1, and ensure that the resulting images are different if the

21

3. Design of Pico

input texts are different. In our implementation, the visual hash image generatesfrom encoding server’s ID, public key, and url. These information are essential insetting up an account for this server, since the future login operations depend entirelyon this information.

We assuming the correct visual hash image is well-known or displayed on a trustedpublic website, known as the visual hash database. Once Pico decodes informationin QR code, it generates a visual hash image according to the data in QR code.Users have to decide whether this image is identical with the correct image of thetarget server displayed in the visual hash database. Using the hash image as atype of message authentication, Pico is protected from registering with phishingwebsites. Additionally, the nonce including in the QR code can be used by servers asa freshness test, to check whether this enrolment request is stale or not.

The advantage of using Pico to handle registration with this type of webapplications is that the user can choose how much information he or she wouldlike to disclose to the public, and has a certain level of deniability. Because Pico’scredentials are randomly generated, it has no direct relation with the owner. Thisfeature is beneficial for protecting users’ privacy, not accidentally leaving identitytraces when they use online applications.

Figure 3.3: Lower security level Pico enrol protocol

3.2.3 Continuous authentication

To ensure the logged on session is remained secure, Pico and the server executecontinuous authentication after a successful login or enrol. It can also act as alife-ness test that check the presence of the peer. This test uses another key kx2which should be computationally independent with kx1, as shown in the last phasein Figure 3.1. The continuous authentication session starts with an encrypted noncegenerated by the server. Pico calculates the hash of this nonce concatenated with abyte value and sends it back. The server then verifies the correctness of this answer,

22

3.3. The Device

and then delivers a new nonce to Pico and so on. Only the entities having the samesecret key kx2 can successfully perform the correct calculation on the nonce. Hence,a malicious attacker cannot impersonate either Pico or the server. This procedureallows continuous login until user wants to leave the session, or the session times out.

3.3 The DeviceA question raised after defining all the Pico operations is, what elements should theactual Pico device consist of, in order to execute these operations? Consider thescenario shown in Figure 3.4. When the user wants to login to a website shown onthe PC’s browser, Pico can directly retrieves the necessary information about thecurrent session from the browser. In this case, Pico can tell the server which sessionthe user desires to log in to by communicating with the server through Internetprotocols like HTTP. The other parts of the protocols require wireless communicationwith server as well, and the ability to calculate cryptographic algorithms.

Figure 3.4: Communication targets of Pico

To accomplish login and enrol, an actual Pico device will be a smartphone-likedevice having the following hardware properties:

1. Cryptographic module: The login process includes several cryptographic com-putations, so the device should support algorithms for public key and secret

23

3. Design of Pico

key cryptosystem.

2. Wireless Internet connection: Pico has to talk to application servers directlythrough Internet.

3. Camera: To provide an out-of-band channel to retrieve information frombrowsers.

4. Secured database: To store the registered credentials needed to access theaccounts.

5. User interface: Pico needs a screen and some buttons ( or touchscreen) toreceive user commands and display important message to users. Moreover, theuser interface should be easy to manipulate, so that every user is able to use it,not only the sophisticated ones.

6. Small in size: Since an important properties of Pico is FROM-ANYWHERE, thedevice should be small enough to be carried around with users.

The list above are the minimum requirements for a Pico device to conduct itscore functions. Other services mentioned by Stajano [37], such as range detectionbased auto-logout and non-web applications login, needs more sophisticated hardware;thus, they are not covered in the scope of this thesis.

3.4 The ServerTo complete the Pico system, the target application servers must also supportcommunication with Pico by providing the following functionalities:

1. Displaying QR codes on login pages to transmit related information.2. Dedicated routines to handle Pico communication, including executing cryp-

tographic functions.3. A database storing different registered Pico public keys, IDs, and for higher

security level applications, probably user information.4. A database containing information about every ongoing session with Pico.5. Time-out mechanism to manage the continuous authentication of logged on

sessions.Most of the servers nowadays are able to meet the computational requirements

of the Pico system, only small modifications need to be performed to the originallogin mechanism. In this thesis, we will also show the result of Pico communicationwith a demonstration server we built.

3.5 ConclusionThe implementation of the two core functionalities of Pico in Stajano’s study [37],main and pairing, are proposed in this thesis, referred to as login and enrol. Theproposed Pico protocols for these functions execute mutual authentication and key

24

3.5. Conclusion

exchange with the target application server. The protocols are based on a modifiedversion of SIGMA-I protocol, using digital signatures, DH key exchange and AEADschemes. Authentication procedures in the proposed protocols prevent man-in-the-middle attacks and phishing attack. Message encryption protects the identity andcredentials from eavesdropping. The proposed protocols also offer forward secrecyfeatures, by generating fresh DH key pairs for each new session, and derived thecontinuous authentication key independently from the key used in authenticationsession.

On the usability point of view, Pico searches the corresponding credentials in itsdatabase by using the ID indicated in the QR code. The visual hash confirmationallows users to check the consistency of Pico’s action with their intentions. As aresult, the users are able to safely access their accounts with only a few interactionswith Pico.

25

Chapter 4

Implementation

The user experience and practicality of Pico system need to be tested with anactual device. Thus, we present a prototype of Pico and a server that can suc-cessfully demonstrates Pico functions. The hardware specifications and Java codeimplementations will be discussed in this chapter.

4.1 Introduction

The hardware requirements of Pico have been mentioned in Section 3.3. A smart-phone is an excellent candidate for implementing a functional prototype. Becausesmartphones contain a micro controller, wireless modules, storage spaces, and mostof them have high quality cameras. Moreover, some mobile platforms like Androidare open source operating systems, which allow programmers make use of variousAPI to develop their own applications. Hence, we choose to construct Pico on anAndroid based touchscreen smartphone.

Note that, the real Pico device should not be integrated in smartphones. Thereason is that there are many applications installed on a smartphone, the memorysharing might leak information about the credentials. Furthermore, security threatson the smartphone can endanger Pico also.

Figure 4.1: Software architecture of Pico system

Figure 4.1 presents the overall architecture of main functional components in

27

4. Implementation

Pico implementation in Android platform. The top layer MainActivity is theuser interface(UI), displaying options on the screen, taking user input, and delivermessage to users. This layer will then call different types of Pico’s operations, likelogin, enrol, and continuous authentication task. These functions send distinctiveprotocol messages to server as described in Chapter 3. The cryptography algo-rithms, communication module, and other auxiliary functions are supported by threelibraries, as Crypto, Comm, and Utility depicted in the figure. Moreover, there isalso a database managing the access of registered credentials. The camera events arean independent activity, focusing only capturing image and decoding QR code.

In Section 4.2, specifications for each functional components will be defined.The components conduct cryptographic computations and communication withservers. The descriptions contains brief code demonstration, reasons for choosingthe algorithms, and related classes that implements them. Section 4.3 explainsthe system point of view of Pico implementation. Connecting all the componentsmentioned in first section, this section describes the relationship of each class andthe state transition between classes.

4.2 SpecificationsAndroid is a Linux based operating system released by Google. On top of Linuxkernel runs APIs, libraries, and middleware, which support the application frameworkabove. The application software runs on the application framework and is Javacompatible. An Android application usually make uses of different APIs provided byAndroid, documented in the Android API library [17], to perform desired interactionwith the smartphone. These official APIs and other user-developed sophisticatedlibraries can be adopted in implementing Pico system. We choose Android 4.0 asminimum target platform and JDK 1.6 for compatibility with the selected librariesused later on.

4.2.1 Cryptographic Module

The Android platform supports most of the APIs provided by Jav. The JavaCryptography Architecture(JCA) manages security related APIs using engine classesas interface to access any kinds of cryptographic functions, while the algorithmsare implemented by different providers. As shown in Figure4.2 clipped from [30],JCA includes most of the cryptographic algorithms we need to generate signatures,establish key agreement, encryption and authentication. These algorithms areimplemented by various content providers, so that programmers have freedom toselect which implementation of the algorithm they prefer to use. Here we utilizealgorithms supported by the spongycastle provider to compensate limited supportson elliptic curve and authenticated encryption schemes from the default provider. Inthe realization of Pico, we encapsulate all the cryptographic related functions inthe Crypto class.

Pico protocols descried in Section 3.2 require both public key and secret keycryptography algorithms. The former supports digital signature and DH key exchange,

28

4.2. Specifications

Figure 4.2: Java Cryptography Architecture(JCA) [30]

and the latter takes care of encryption, message authentication, and hash functions.One of the major security measure lies on the length of the credentials, as suggestedin the reports presented by ECRYPII[15] and NIST[3]. Table 4.1 summarizes partsof the different security levels defined in yearly report of ECRYPII[15]. For the year2012, the smallest general purpose security level is level 4, which has 80 bit security.It has protection for less than 4 years, while level 5 can reach 10 years protection,and level 6 for 20 years medium protection. Thus, the security level of Pico shouldbe at least 80 bits or higher, which depends on the performance of cryptographicfunctions.

Security level Security(bits) Symmetric key Hash ECC RSA4 80 80 160 160 12485 96 96 192 192 17766 112 112 224 224 2432

Table 4.1: Security levels

Public Key System

Public key cryptosystem can be implemented by algorithms like RSA or Elliptic curvecryptography(ECC). Compared to RSA, ECC has the upper hand in the efficiencyof algorithm due to shorter key length. In mobile device like Pico smaller storagespace for the credentials is always preferable. The computation time for RSA isexponentially increased when key length increase, whereas ECC has linear increase

29

4. Implementation

in computation time. Due to the power limitation and the device response time,shorter computation time is better. Thus, based on the efficiency in storage spaceand performance, we select ECC for realizing public key algorithms. In practice, 224bit Elliptic curve cryptography over prime field is selected. The implementation ofECC is based on curves recommended in SEC [8] over prime field or binary fieldwith key length larger than 160. Consider performance and Java library’s capability,224 bit curve over prime field standardized as secp224r1 is used in the end.

When using EC algorithms, one must first generates the EC keys. In JCA,cryptography keys are generated by an engine class KeyPairGenerator, which takesa random source and specification of key. The generated key is of class KeyPair,which the public key and private key can be retrieved respectively. keyGenDSA()and keyGenECDH() are the two function responsible for generatin EC keys for DSAand ECDH respectively in class Crypto, as digested below:

1 KeyPairGenerator keyGen = KeyPairGenerator . getInstance ("EC", "SC" );2 ECGenParameterSpec ecSpec = new ECGenParameterSpec ( EC_CURVE_NAME );3 keyGen . initialize (ecSpec , srandom );4 KeyPair pair = keyGen . generateKeyPair ();5 PublicKey pub = pair. getPublic ();6 PrivateKey priv = pair. getPrivate ();

The keys can be stored as a byte array type that is easier to manage andtransmit through out the program or store in the database. There are specificencoding methods for translating keys between their original classes( PublicKey orPrivateKey). The default encoding for class Public Key is X509EncodedKeySpec,and PKCS8EncodedKeySpec for Private Key. To get encoded key is simple, but de-coding keys from byte array need to make use of KeyFactory class. The KeyFactoryclass translates raw byte arrays to keys given certain specifications. And to convert apublic or private key to byte, simply use getEncoded() of that class as demonstratedbelow:

1 // get byte [] of keys2 byte [] pubByte = pub. getEncoded ();3 byte [] privByte = priv. getEncoded ();45 // decode back to PublicKey and PrivateKey class6 X509EncodedKeySpec publicKeySpec = new X509EncodedKeySpec ( pubByte );7 PKCS8EncodedKeySpec privateKeySpec = new PKCS8EncodedKeySpec ( privByte );8 KeyFactory kf = KeyFactory . getInstance ("EC", "SC");9

10 PublicKey pubBack = kf. generatePublic ( publicKeySpec );11 PrivateKEy privBack = kf. generatePrivate ( privateKeySpec );

The constructed EC keys could be applied in both ECDSA and ECDH, which arealso provided by spongycastle library. Th signature generation and verification aredemonstrated in the following code. ECDSA belongs to class Signature containinginitialization and update phases. Initialization phase initialize the signature algorithmwith EC key, and update is called to fill in the data to be signed. The signatureis generated when finished updating all data. Verifying signatures proceeds withsimilar fashion as through line 8 to 10 of the code below, using peer’s public key.

1 // generating signature

30

4.2. Specifications

2 Signature dsaSign = Signature . getInstance (" SHA256withECDSA ", "SC" );3 dsaSign . initSign (priv);4 dsaSign . update (data);5 byte [] signature = dsaSign .sign ();67 // verifying signature8 Signature dsaVerify = Signature . getInstance (" SHA256withECDSA ", "SC" );9 dsaVerify . initVerify (pub);

10 dsaVerify . update (data);11 boolean ans = sig. verify ( signature );

Lastly, Diffie-Hellman key exchange can be done by calling KeyAgreement class.We first initialize the instance of KeyAgreement class with a party’s private key asin line 2, then provide the peer’s public key as in line 3 of the code below. ThedoPhase() functions could be called several times as long as the second argument,indicating whether it is the last data or not, is set to false. Finally, the generatedsecret is of type byte array, and is applicable to instantiate other credentials.

1 KeyAgreement keyAgreement = KeyAgreement . getInstance ("ECDH", "SC");2 keyAgreement .init( myPriv );3 keyAgreement . doPhase (peerPub , true);4 byte [] secret = keyAgreement . generateSecret ();

Symmetric Key System

In the symmetric key system, hash function are widely used. Among the existinghash fucntions, SHA-256 is preferable to SHA-1 or MD5, which are both proven notsecure. SHA-256 has 128 bit security, and generates 256 bit output with arbitraryinput message length.

1 MessageDigest SHA = MessageDigest . getInstance (" SHA256 ");2 SHA. reset ();3 byte [] result = SHA. digest ( message );

For the encryption, AES provides a satisfactory level of security and performance.This cipher should always combined with the a mode of operation, like AES-CTRand AES-CCB, instead of using it alone. These modes take additional randomnessas initial vector for processing different block of the input message. Since all of themessage in Pico protocol need not only encryption but also authentication, AEADschemes discussed in Section 2.3.7 can be exploited here. Among all the AEADschemes, AES-GCM is the best choice because it first encrypts the data and thencomputes the authentication tag, and also its flexibility in message length. The secretkey is computed by concatenating exchanged secret from ECDH with a pre-definedvalue, and the initial vector used in AES-GCM is then derived in a similar fashionfrom this secret key. As shown in the following code, the cipher takes secret key,IV, and associate data on initialization( line 9 to 12). The encryption is done inline 13,14, where the doFinal() function calculates necessary padding and generatesauthentication tag along with encrypted cipher text. The program below shows apart of AES-GCM encryption and decryption process in actual implementation.

31

4. Implementation

1 byte [] rawKeyB = SHA. digest ( secret );2 KeyParameter rawKey = new KeyParameter ( rawKeyB );3 // trim the key to 128 bit4 rawKey = Arrays . copyOf (rawKey , 16);5 SecretKey keyAES128 = new SecretKeySpec (rawKey , "AES");6 KeyParameter encKey = new KeyParameter ( keyAES128 );7 // HASH_IV is a pre - defined byte for creating IV8 IV = sha4AESKey . digest ( Utility . concatAll (key. getEncoded () , HASH_IV ) );9 AEADParameters params = new AEADParameters (encKey , MAC_SIZE , IV ,

associateData );10 // start AES - GCM cipher11 GCMBlockCipher gcm = new GCMBlockCipher (new AESEngine ());12 gcm.init(true , params );13 offOut = gcm. processBytes (plaintext , 0, plaintext .length , out , 0);14 gcm. doFinal (out , offOut );

Despite the GCM key in the protocol, another GCM key is independently gen-erated from GCM key for later continuous authentication, denoted as kx2 as inChapter 3. This key is produced by hashing the mutual secret with an extra bytevalue, which is similar to the above key generation procedure.

Random Number Generation

The freshly generated DH values are based on the security of random numbergenerator in Pico. SecureRandom class generates non-deterministic outputs that arecryptographically strong for application on other cryptography modules. This classuse pseudo-random number generators(PRNG) with true-random seeds to producerandom output. Programmers can specify the type of PRNG used, for example inPico system, SHA1PRNG is selected. The instance obtained by a getInstance() callis not seeded until either secureRandom.nextByte() or secureRandom.setSeed()have been called. Since seeding is often time consuming, it does not have to beexecute everytime when SecureRandom object is used. The reseed process can bedone periodically over a certain time period.

4.2.2 Database

Pico stores its credentials and sever information in a SQLite database supportedby Android. SQLite allows searching through the database using queries as in otherdatabase. An entry in the Pico database has elements listed in Table 4.2. Note thatthe field "ID" is not an extra information provided by server, it is constructed byfirst hashing(SHA256) server’s public key, and then encoding the hash byte streamusing Base64 encoding. Using byte array in query might crash the database becausebytes may be misinterpreted as prohibited special characters. Thus, a byte array isconverted to Base64 encoded string before storing into database. Additionally, thebyte string send by Pico or servers is encoded using Base64 as well.

Table 4.2 displays members in PicoContact, which defines an entry in thedatabase. The gateway to the SQLite database is DatabaseHandler class, processingthe query coming from PicoContactDataSource. This class provide certain functions

32

4.2. Specifications

such as retrieve and insertion of an entry for any functions who want to use thedatabase.

Field name Description Data typeIndex Index number of the entry INTEGERID Searching index of this server TEXTNickName User defined names for server TEXTPublic Key Server’s public key in byte format BLOBMy Pirv Pico’s private key for this server BLOBMy Pub Pico’s public key registered on server’s database BLOBLevel Security level for enrol INTEGERURL URL for login TEXTSubnum Used if having multiple account in the same server INTEGER

Table 4.2: Contents of an entry in Pico’s database

4.2.3 Communication with the Server

Most of the elements essential to implement Pico’s protocol, including cryptographicunits and database, has been covered in previous sections. This section will discusshow to wrap up the protocol messages and how to transmit them between Pico andserver. In Pico system, communication between server and Pico can be separatedinto two methods : through Internet and out-of-bound channel. The former usesHTTP or HTTPs through either 3G or Wi-Fi, and the latter is achieved by QR codeon web page.

QR code

QR code is a 2D bar code that efficiently encodes letters, numbers, and some specialcharacters in a small square. The size of QR code is determined mainly by theamount of data encoded and the camera resolution. Pico thus requires a camera onits device to complete this out-of-band communication. The Pico system definestwo types of QR code message structure, for enrol and login function respectively asin Figure 4.3. The structures shown in the figure is the raw byte array, which will beencoded using Base64 encoding to translate into text string. Pico has its own set of1-byte headers indicating the type of the message, which always appear at the firstbyte of every Pico messages. As for enrol, the length of public key depends on ECcurve used, in this case, we need 80 bytes to represent an encoded public key. Thenonce is 32 bytes, and the length of server’s enrol url varies with different servers. Inlogin, its shorter because it only needs server ID to indicate the target server, whichis 32 byte value.

We make use of ZbarScanner activity provided by ZbarScannerActivity [41]extending original source [7] to start up camera, focus, take picture of QR code, andthen decode it into string. After that the QR message is ready to be used in login orenrol function.

33

4. Implementation

Figure 4.3: QR code structure for enrol and login functions

Visual hash

Visual hash takes an important rule in enrol procedure, it makes alphanumericsequences easy to distinguish by visualize them. When implementing this mechanism,we found that the existing libraries are limited. Vash [38] library states that theiralgorithm could be adopted in cryptographic systems, such as verifying two long hexstrings. Although no clear information about the size of input and output space isdefined, this hash function should be suitable for distinguish different hash strings.Unfortunately, to adopt this library, it has to be ported into Android platform first,which we are not able to achieve due to timing constraints.

Robohash [11] is another visual hash algorithm that generates different robotswith different input string. To obtain the image, simply pad the textual input stringafter is url "http://robohash.org/YOUR-TEXT.png", and the resulting website willdisplay the hash result. Despite the limited output space of size 223, this libraryis a sufficient visual hash generator for demonstration purpose. Hence, the Picoprototype utilize the response from the url as the visual hash for user confirmation.

Communication modules

When communicating directly with the server, Pico use queries defined in classHttpWorks to send HTTP or HTTPS queries over Internet. Pico acting as client inHTTP protocol, could use HTTP Post or Get requests to obtain information fromserver. Server responds to the incoming requests. Since Post method is designedfor transmitting larger amount of information, we will make use of this method toexchange Pico messages. On the Pico side, the HTTP request could be sent as follow:

1 HttpPost method = new HttpPost (url);2 ArrayList < NameValuePair > postParameters = new ArrayList < NameValuePair >();3 postParameters .add(new BasicNameValuePair ("msg",toServerMessage ));4 method . setEntity (new UrlEncodedFormEntity ( postParameters ));5 HttpResponse response = httpclient . execute ( method );

The last line in the above code sends HTTP request to server through Wifi or 3Gservice provided by the phone, and catch the server’s response. The toServerMessageis a message in Pico protocol. These protocols are executed by HttpWorks class,which sets all the parameters for sending an request to the server, waits for response,and extracts the response messages.

34

4.2. Specifications

Figure 4.4: Basic message structure in Pico protocols

Protocol Messages

The basic structure of a message is displayed in Figure 4.4. First two fields are notencrypted, since they are only associated data, not credentials. The cipher text ofAEAD stream may consists of Server/Pico ID, signature, Hashed session ID,Pico’s public key as described in Figure 3.1 and Figure 3.2. The header is onebyte, and the DH value is 80 bytes for the current curve. However, the AEADstream might vary in length making fix length byte extraction difficult. We adoptJSON encoding method to pass this structured message. JSON [22] is a text-basedrepresentation of simple name-value pair-like data structure and arrays. It is alanguage-independent data format, thus is suitable for transmitting data betweendifferent entities. The class PicoMessage is a container of structure described inFigure 4.4; plus, the headers used to identify the type of protocol message is alsodefined within that class as static values. Each header is associated with one specificphase in protocol, such as QR code, the first pass sent by Pico , or the replyfrom the server. Using these headers prevents executing incorrect operations on thewrong message. With the help of helper class GSON, PicoMessage could be directlytranslated to JSON format like follows:

{" aeadString ":"lzE66A0Cdsl9EieN1 zwSbtrIH 21Blw2Uw =="," dhValue ":"ME4 wEAYHKoZIzj 0 CAQYFK 4EE8d9V5gqf6bD5 VDdwrkPlU /yiA ="," header ":"Qg =="}

One of the advantages of using JSON format is that parsing data of arbitrarylengths is not a problem, because each element is obtained by the associated name,instead of truncation. Another benefit is that it can be translated into string likethe example, which is easy to transmit via HTTP. Furthermore, JSON encoder cantranslate object members directly into JSON string associated with member’s name.As a result, the byte values of the credentials and cipher text are first encodedin Base64, and then translate to JSON string to send to the peer. The peer canreconstruct an object according to the JSON string, and easily retrieve data of eachfield. In realization, GSON helper class is utilized to easily convert members of a classand their values into JSON format.

A big macro wrapping up Pico message generation and parsing are in classPicoMessageHandler. The member function genPICOMessageJSON generates JSONstring message for each step, including signature generation, AEAD encryption,and final JSON string construction, depending on what the message should include.

35

4. Implementation

readPICOMessageJSON on the other hand, parse the message and do necessarydecryption or signature verification.

Background execution

When designing an Android application, one should never put every computationeffort on the main thread. This will cause unpleasant user experience like stalls or afrozen screen. Android platform provides several methods to implement backgroundexecution tasks. Two of the most popular methods are AsyncTask and HandlerThread. These two classes serve the same purpose of invoking a background threadparallel to main thread, but they are different in their life cycle and the way theyinteracting with the main thread. AsyncTask is especially designed for Androidplatform, to ease the management of background tasks and their synchronizationwith UI. Compared to Handler Threads, AsyncTask is allowed to perform UI up-dates with proper use of methods of its life cycle; but Handler Thread is moreflexible when massive interactions with main thread is on demand. Figure 4.5depicted the interaction between AsyncTask and the main thread, which containsmodules as UI and Handler. The dashed-line circles are of class AsyncTask, whileonly doInBackground is actually executing in background thread, other methodslike OnPreExecute, OnPostExecute, OnProgressUpdate, and OnCancelled are allresides in main thread. These methods permit the members and methods in thisclass to modify the UI screen, as depicted in the figure. We deploy the AsyncTaskto implement our main functions and continuous authentication for cleaner codeand easy management. However, Handler is still necessary in this scenario, tohandle a message passing from AsyncTask to main thread when the task is done.To accomplish this task, a Message object containing a Bundle of several pieces ofinformation is created at the end of doInBackground. This object is sent to Handlerin the main thread, and then Handler can extract the information within. TheAsyncTask is normally terminated in two manner, from OnPostExecution in normalcases or from OnCancelled when cancelled in main thread.

4.3 Program FlowThis section analyses the actual program flow of Pico device, linking all the submodules discussed in previous chapter together. We will discuss when how doesmain activity thread interacts with user and what event triggers other child threads.Figure 4.6 describes the state transition between important functions existing inthe Pico device. The dashed line circle indicates a function in another independentactivity, and the gray circles mean children threads invoked by the main thread,also known as main activity. Note that the choice of an Android phone is only forprototyping purpose. An actual Pico device should perform same functions, but inorder to realizing all the other properties mentioned in Table 2.1, should be a standalone device.

When the Pico application starts up, it enters 0.Init state in Figure 4.6. Thisstate initialize database and instances required by later procedures. Besides ordinary

36

4.3. Program Flow

Figure 4.5: Life cycle of AsyncTask

Figure 4.6: State diagram of Pico

initialization of activities, such as displaying UI, this state is responsible for more.There are four static objects, an instance of Crypto class, the database, a queuefor recording running continuous authentication session, and a queue storing pre-calculated key pairs for ECDH. The main reason of initiating Crypto is to reseedthe secure random number generator within. It must be reseeded before start usingor else it will always start from the same initial state. Obtaining the access todatabase creates an instance of PicoContactDataSource, processing queries fromother functions and returning results searched in the databased. A queue is required

37

4. Implementation

for recording the instantiated continuous authentication. Thus, users can keep trackof the current accessible account, and decides whether cancel them or not. Finally,we computes a few DH key pairs and store them in the database, so that the keypair generation time in subsequent operations can be eliminated. Cryptographicfunctions like key generation and signature generation are time consuming. Thus,preparing a few pairs of key for login saves significant amount of time in waiting.

Pico device enters the 1.Idle state and waits for user input. The main userinterface is displayed at this state, as shown in Figure 4.7a. This interface containsonly one button, the button with a logo of Pico on it. To start a login or enroloperation, users only have to press ths button, and the machine will enter the firststage of these operations. The main activity is switched to ZbarScanner activity,which is in charge of the camera until it capture a proper QR code like in Figure 4.7b.This activity also decodes the QR code, and hand back the screen to original thread.

The decoded string is handled in 3.OnActivityResult, a routine designed tointeract with all the other activities originates from main activity. In this state, Picoprepares the necessary operations before starting a login or enrol process as describedin Figure 4.8. Pico first parses the QR string to ensure it contains valid information,and decides which function will be executed later according to the header associatedwith QR message. Next, Pico searches the database for credentials correspond tothe server ID field in the QR message. The SQLite search routine is performed in anindependent thread to avoid unpleasant stall in UI. The search result is enclosed ina Message object and passed to the handler function in main thread. The handlerfunction handles all messages delivered from children threads of main thread, bycalling this handler in children threads.

If the user scans a QR code from a login page, a dialog like Figure 4.7c pops outand reminds users to check whether the following action is consistent with his orher intention. If not, then the process is cancelled, back to idle state. Otherwise,the handler pulls out a pair of DH keys stored in the queue and passed it toLoginAsyncTask along with server information extracted from database. At thispoint, the device displays a progress dialog as shown in Figure 4.7d, keeping theuser waiting for result. The class AsyncTask is especially designed for Androidenables easy manipulation of background thread and UI thread. Since wirelesscommunication can be time consuming, it is forbidden in the main thread in Androidplatform. Thus, we designed a LoginAsyncTask class to execute all the calculationand communication in phase 1 to 4 of Pico login described in Figure 3.1. This classprovides a message handling procedure of each phase, by integrating algorithms inCrypto, Utility, and PicoMessageHandler. The message is encapsulated in JSONformat with three name-value pairs, and the byte values of each field is encodedin Base64 format. After generating the message for server, the HttpWorks objecttransmits this message to server, and wait for the server response. This task will onlycontinue if every element in the server’s response is verified correctly; otherwise, itwill end immediately and return to main screen. In addition to authentication, thistask also calculates the mutual secret and generates two independent keys, one forencryption in the protocol, and another for the following continuous authentication.If the mutual authentication process completes successfully, this thread ends with

38

4.3. Program Flow

(a) Main screen (b) Capturing QR code

(c) User confirmation (d) Progressing

Figure 4.7: Screen shots of user interface

sending a message containing the continuous authentication key kx2 to main thread.The enrol procedure works in a slight different manner. First, the search result of

database might be empty, meaning the scanned application has not been registeredbefore. On the other hand, if there are existing accounts of this application already,user can decide to create another new account, or cancel this procedure. Thehandler passes the search result to VHashAsyncTask, producing visual hash imagefor user to check the correctness. In this stage, due to lack of visual hash libraryfor Android, the image for visual hash is generated by downloading image fromRobohash using authentication string. Generating visual hash is another AsyncTask,

39

4. Implementation

Figure 4.8: Flow diagram of executing Pico functions

because it might be time consuming. Once ensuring that QR information is correctby user confirmation on the images, EnrolAsyncTask executes the enrol protocolsubsequently.

Whenever a background thread like AsyncTask are invoked, the UI screen turnsto progress dialog as shown in Figure 4.7d. This dialog disappears after backgroundcomputations are finished, and a short message will pop out on the main screen tonotify what has been done. While login or enrol ends and UI screen is put backon display, a PingpongAsyncTask is generated by the handler. Using kx2 derivedfrom the mutual secret, this thread continuously throws message to the applicationserver and request for a new nonce, until it is cancelled by either the user or theserver. One interesting fact is found the effect on the program done by AsyncTask ofcontinuous authentication. The default thread management of AsyncTask in Androidversion 3.0 or above is serial execution of only one background thread. Because theremight be another request while a continuous authentication session is still active, theAsyncTask should be executed by thread pool executor. In this case, the executorcan schedule the threads that are active for proper use of hardware resources. Theongoing life-ness test is stored also in a queue so that users can check which sessionsare still activate, until it times-out.

One important component still missing here is the application server. The serveris activated by client requests, and processed the message according to the headerwithin. At the server side, each new client will be associated with the DH value itsends in the first pass of the protocol. By keeping track of the received DH value ofeach client, the server can easily recognize which client it is talking to.

40

4.4. Conclusion

4.4 ConclusionTo recap, the Pico prototype presents in this chapter is a practical implementa-tion with substantial cryptography and communication specifications designed. Asummary of specifications are listed in Table 4.3. The device provides a simpleUI to interact with users, without asking the user to memorize anything . It iscapable of accomplishing the protocol designed in Chapter 3, utilizing internallystored credentials and computation modules.

Software environmentTarget platform AndroidMinimum version 4.0Target version 4.2Database SQLite

Communication specificationsString encoding scheme Base64HTTP message format JSONQR code decoder ZBarScanner [7]Visual hash generator Robohash [11]

Cryptography algorithmsLibrary spongycastleDigital signature scheme ECDSAKey exchange algorithm ECDHEcliptic curve secp224r1Public key storage X.509Private key storage PKC#8AEAD scheme AES-GCMBlock cipher AES-128Hash function SHA-256Secure random generator SHA-1PRNG

Table 4.3: Summary of specifications

41

Chapter 5

Evaluation

To examine the practicality of the proposed design, this chapter presents the perfor-mance measurements of the prototype. These results confirm that the implementationdiscussed in the previous chapter is a good solution of Pico from security and usabilitypoint of view.

5.1 Introduction

Satisfying all the security requirements is not enough to convince users that Picocan indeed be a replacement for password systems. The computation time of theimplemented system should not become a burden that affects user experience. Sincethe objective of this thesis is to implement a prototype of Pico device, usabilitymust be taking into account.

This chapter begins with a discussion on optimization techniques, followed by theresults of the cryptographic modules and the system performance. The result of theproposed design is then evaluated based on the properties mentioned in Stajano [37]’swork.

5.2 Optimizations

During the development phase, we employed several optimization techniques toimprove the performance of the code. The aim of these scheme is to make the userexperience of the overall system better, by speeding up or threading the procedures.The main optimizations are listed below:

1. Background processingEveryone hates when their computer or smartphone freezes. To avoid this typeof situation, all of the heavy processes are executed in background threads.These processes include cryptographic functions, database queries, and wirelesscommunication. Moving calculations to background threads other than themain thread might slower down the process subtly, but the progress dialog makesthe overall user experience better. For example, when the Pico is performing

43

5. Evaluation

login or enrol operation, the screen will show a dialog with spinning wheelsindicating the progress instead of stall at the main screen. Since initializinga thread and switching between threads also take efforts, we integrate thecryptographic functions and communication modules into the same thread.Considering the case of a large database, the database searching operation isalso performed by a thread.

2. PrecomputationAlthough a progress dialog is better than having a frozen screen to the userexperience, the background process time should still be as short as possible.The most time-consuming operations are asymmetric key algorithms. Functionsrelated to ECDH and ECDSA occupy most of the execution time. As describedin Chapter 3, a login function consists of one EC key generation, one signatureverification, one mutual secret calculation, and one signature generation, forthe public key algorithms; the enrol function needs an additional EC keygeneration for credentials to register with the server. We reduce the burden ofgenerating EC keys when executing Pico functions by pre-calculating a setof EC keys. These keys are stored in a queue, waiting to be pulled out whenrequired. The system replenish the queue by generating EC keys while nooperation is running, such as when finishing a login task. This precomputationreduces waiting time for users, hence providing better performance.

3. Instance reuseAcquiring some of the objects requires a lot of time, such as instances ofSecureRandom, GSON, HttpClient, and Dialog. Although the preparationtime might be shorter compared to cryptographic functions, they will becalled several times during the whole process. Thus, decreasing the numberparameter setting procedures can effectively reduce the total execution time.SecureRandom objects must be reseeded properly during the initialization phaseor else the randomness cannot be guaranteed. Thus, we only have one instanceof SecureRandom object throughout the program to reduce the initializationtime. The GSON and HttpClient will be called frequently in Pico functions.Since the object of these classes can safely reset, there are only one copy ofeach respectively in an AsyncTask. The Dialog in UI thread can also beimplemented in this fashion. An AlertDialog.Builder object is instantiateat the start up phase of this program, later dialogs can be simply called bymodifying specific parameter using this instance.

4. Clean user interface On the main screen, there is only one button to press.This simple button starts the camera activity and Pico will distinguish thecaptured QR code is either login or enrol. Users can immediately understandwhat to do when they turn on Pico, without being confused by other availablebuttons. Other functions such as testing functions used in development phaseare hidden the option menu.

44

5.3. Performance

5.3 Performance

This section provides evidences to support the claim on the usability of the Picosystem. All the timing measurements are collected from actual execution on aSamsung Galaxy III mini touch screen smartphone. The results indicates that Picois capable of performing authentication with application server in an acceptableperiod of time.

5.3.1 Cryptographic Modules

Spongycastle library provides several choices of curves, which are suggested in SEC[8]document or X9.62 standard, to realize public key algorithms. In order to findthe curve most suitable for implementing EC-related algorithms, we selected a fewcandidate curves that have a key length between 160 bits and 239 bits. The test isconduct by calculating the same functions for 100 different key pairs respectively foreach curve. As shown in Table 5.1, the primary cryptographic functions we test arekey generation( keyGenEC), ECDSA signature generation( genSig) and verification(verSig), and mutual secret generation of ECDH( genKx). Among all the operations,verifying the signature is likely to be the most time consuming job, followed bymutual secret generation. The results displayed in milliseconds are the averageexecution time over 100 samples. Although 100 trails might not cover enough testspace, the trend is clear enough to distinguish the difference in computational speed.

As shown in the table, an interesting fact is that the curve having the bestperformance is secp224r1, even the curves with shorter key lengths might have longercomputation time. This might because of the nature of the curves itself, or theway spongycastle implements them. Another environmental factor that might haveinfluence on the result is temperature. The temperature of mobile phones can easilyincrease when loading with heavy computations, and will slow done the hardwareinside. To avoid this influence, we test each performance separately, instead ofexecuting everything in a row. Considering the results in Table 5.1, we compute thepublic key cryptographic functions based on the secp224r1 curve.

The computation time of symmetric key algorithms, on the other hand, isgenerally much shorter then that of public key systems. Except the initialization ofSecureRandom object, operations like encryption, decryption, or hash function canbe finished in few milliseconds.

45

5. Evaluation

Table 5.1: Execution time of different elliptic curves inmilliseconds

Curve KeyGenEC genSig verSig genKxsect163r2 296 293 466 319c2pnb163v3 288 294 464 308c2pnb176w1 303 331 477 327c2tnb191v3 404 401 574 399c2pnb208w1 475 454 681 463secp224r1 239 219 304 227sect233r1 622 585 914 658prime239v3 235 242 313 239c2tnb239v3 653 623 959 682

The performance is measured in milliseconds.

5.3.2 The Pico System

A brief review of what the Pico device does in one operation, for example login, isin Figure 5.1. The User row indicates the timing point when the user has to interactwith the device. The second row, Pico, is divided in to two rows, representing theUI screen and other computations respectively. The gray blocks in this row meanthat the process is being executed in a child thread. The last row shows the statusof the Server, which is activated whenever receiving requests from Pico illustratedby the up and down facing arrows between the two rows.

Figure 5.1: Time line of main events in one Pico operation

Since user interaction time can not be decided by the device, we exclude theuser response time in our measurement results. Doing a detailed profiling is difficultbecause of the hardware constraints, so only the significant functions will be measured.The results are shown in Figure 5.2, indicating the operation time as a percentageof the total execution time for a login task. Note that the gray bars in the figureare tasks that performed only during system start up, i.e. the first time we activatePicoThe black bars are the functions that will be executed every time a user request

46

5.3. Performance

Figure 5.2: Timing comparison of different functions in Pico

is received. Summing up black and gray bars respectively, it can be found that theinitializations occupies big portion of the computation time.

If instance initializations execute in every Pico function, they will slow downthe device seriously. Hence, as proposed in the optimizations, most of the ini-tializations are done only once, and other calls to the instance will reuse readilyexist ones. Generating key pairs indicates filling the queue of DH key pairs,which trades the long initialization time to speed up later procedures. Unsurpris-ingly, obtaining a SecureRandom instance( SecureRandom init) and reseeding (reseedSecureRandom) are indeed time consuming, thus initiating an object of thatclass whenever it is used should be avoided. Initializations like PicoMessageHandlerand GSON instances take small period of time, but they will be execute repeatedlyduring Pico functions if the objects are not reused. Hence supporting the optimiza-tion schemes we adopt. Note that every function requires more times when it is firstcalled, so the first operation executed after Pico has been initialized is always slower.In total, the initialization time starting from user pressing the Pico application iconto the main screen of Pico appeared takes around 800 milliseconds.

The second long period of time is Http total, which is the sum of two time slotscounting from Picoś request until receiving server response. The performance of thisfunction is difficult to judge since it depends largely on the quality of wireless signal.If the signal is weak, it might take up to 5 second to complete the task; whereas undergood conditions of wireless signal, it can be finished within 500 milliseconds. Ourtest uses wifi provided in ESAT building, which is considered of good quality. Publickey algorithms play a substantial part in total computation time as well, so a properchoice of elliptic curve can in fact improve the performance. On the other hand,symmetric key algorithms are computationally fast, they are called several times butdoes not affect performance heavily. Finally, the Other field is the miscellaneous

47

5. Evaluation

tasks throughout a complete process. These tasks include transition time betweenactivities, initialization of an AsyncTask, Handler and OnActivityResults as inFigure 5.2. Exact average timing on each tasks is recorded in Table 5.2.

Table 5.2: Execution time of Pico in milliseconds

Procedure Execution time(ms)In

itia

lizat

ion Generating key pairs 736

Crypto init 327reseed SecureRandom 262PicoMessageHandler init 34Gson init 33Init dialog 6

Ord

inar

yR

outi

nes verSig 387

HTTP average time 359genKx 310genSig 232Button pressed to camera 68Return from camera 25gcmEnc 3gcmDec 3SHA256 2

The total execution time that users have to wait is between 2 and 5 seconds, undergood network connection. Excluding the time waiting for user inputs, execution timestarts from the second input of the user in Figure 5.1, to the end of a task. As for theuser input, the average QR code fetching time among several testers are 5 10 seconds;and the confirmation time is around 2 5 seconds. Thus, the time of user input isslightly longer than the computation time of Pico, which is also comparable withthe time spending on entering passwords in conventional password authenticationsystems.

5.3.3 The application server

An application server is implemented to process requests from PicoThe serverkeeps track of the current progress of login in a session database, containing Picośtemporary DH value and other related credentials. This DH value including in everyPico message is used to identify which session the Pico corresponds to. Since theserver performs Java-based executables, the bouncycastle cryptographic library isembedded instead of spongycastle. The algorithms provided by both libraries arebasically similar, because spongycastle is a repackage of bouncycastle for the Androidplatform. Unlike mobile devices’ hardware constrained by power and area, the serveris capable of achieving much higher performance for the same functionalities. Hence,the response time of the server side depends mostly on the wireless communicationenvironment.

48

5.4. Evaluation

5.4 Evaluation

In additions to timing measurements, this section evaluates our design by examiningthe level of accomplishment of properties proposed in Stajano’s original work [37].The evaluation assumes that the design is realized on an actual hardware token, notthe smartphone that we currently use.

Table 5.4 lists all the properties in his paper in its first column, as introduced inSection 2.2. The second column briefly summarizes how each property is achieved inour design. The third column indicates that we only miss a few properties, most ofthem are satisfied. In Minimum properties, we do not achieve LOSS-RESISTANT andTHEFT-RESISTANT because the intention of the thesis is to build a prototype device,focusing on the security specifications and feasibility. Once the prototype is provedpractical and secure, the next step could be building a specific hardware for Pico.Also, some of our functionalities somehow restrained by the smartphone it self, suchas distance detection with Picosiblings, so that these two properties have not beenmet. MEMORYLESS is not accomplished entirely because we still need a PIN for lockand unlock the Pico at this stage, but the account credentials are all recorded inPico.

On the other hand, most of the Desired properties can be seen from this prototype.Not only all the security features are supported by the proposed protocols, credential-handling related properties like NO-SEARCH and NO-TYPING are accomplished as well.However, the designed protocols and procedures work only for web-related accountaccess, they cannot be used for other applications for now. As for Extra features,the proposed Pico system does not require extra modification on users’ computersor browsers, and no third party is involved in the Pico system, so NO-CLI-CHANGESand NO-TTP are guaranteed. Using this system does demand extra modification onapplication server and a specific Pico device, thus cannot guarantee NO-COST andNO-APP-CHANGES.

We also conduct a simple preliminary usability study on several testers. Afterusers are aware of the purpose of Pico, they are left with the device, without anyfurther instruction on how will this function proceed. The main screen is quitesatisfied for users with only one button to press. Pointing to the QR code might beunfamiliar with some people but others knows immediately what should be done.Most of the users have positive response on the intuitive usage of Picoand the fastexecution time. However, some users feel insecure to login about this new type ofaccess control mechanism, because no secret is provided by the user. The feedbacksfrom users assure that Pico has a good potential in usability aspects, and thus isworth conducting further tests or improvements.

5.5 Conclusion

The Pico prototype is evaluated from different angles in this chapter. First weexplained the optimizations that improve overall computation time and user expe-rience. Next, cryptographic performance of different elliptic curves are presented,

49

5. Evaluation

Table 5.3: Evaluation of achievementsM

inim

umMEMORYLESS PIN required for locking mechanism #SCALABLE Can store thousands of credentials SECURE Security of underlying protocols LOSS-RESISTANT Not implemented #THEFT-RESISTANT Not implemented #

Des

ired

WORKS-FOR-ALL For web applications currently GFROM-ANYWHERE Everywhere with the Pico device NO-SEARCH Searches credentials using QR code information NO-TYPING Captures server info from QR code CONTINUOUS Time-out mechanism from server NO-WEAK Self-generated random credentials NO-REUSE Self-generated random credentials NO-PHISING Uses the server public keys in the Pico database NO-EAVESDROPPING Encrypted Pico - server communication NO-KEYLOGGING No key board is used NO-SURFING Never show credentials on screen, hidden session ID NO-LINKAGE Randomly generated credentials

Ext

ra

NO-COST Requires a Pico device #NO-APP-CHANGES Application servers must adopt Pico protocols #NO-CLI-CHANGES No adjustment on web browsers NO-TTP Only Pico knows all the credentials

: Complete support for this property.G: Limited support for this property.#: Not supported.

supporting our choice of specification defined in Section 4.2. A profiling result ofexecution time of all the functions in a compete login procedure is presented as well.We locate the most time consuming parts and explain the difficulties and solution forconquering these obstacles. At the end, our implementation is evaluated based onPico’s original proposal. Concluding from Table 5.4, this design satisfied most of thepromised properties, especially all the security requirements are met. Therefore, it isproven that our proposed Pico design is a practical realization of Pico; which alsoindicates that the Pico system is suitable as an alternative of conventional passwordsystem.

50

Chapter 6

Conclusions and Future Work

This chapter summarizes the motivation, contributions, and results of this work. Atthe end several potential future study directions are suggested as well.

6.1 Conclusions

The widely used conventional password system has been criticized for its difficulty inmanaging all the passwords, and security vulnerabilities. As discussed in Chapter 1,several attempts have been made but failed in usability and security aspects. Apotential solution proposed by Stajano [37] is able to provide a user friendly system,called Pico, that uses secure authentication process to gain access of users’ accountsfrom application servers. However, in a comprehensive research on alternatives ofpassword system conducted by Bonneau et al.[5], it is skeptical about Pico onusability and deployability aspects.

To clarify the doubts on Pico, this thesis establishes the necessary specificationsand details for realizing a Pico, based on the idea described in Stajano [37]. Usingan implemented prototype, we can have a initial observation on whether the systemis practical and suitable for being an authentication device. To begin with, we firstreview basic cryptographic building blocks and out-of-band communication methodsin Section 2.3.

We proposed a set of protocols for mutual authentication between Pico andapplication servers. There are two main functions in our design, explained inChapter 3, these are login and enrol, which the former is used to login to existingaccount, and the latter registers a new account for each other in their database.The underlying protocols of these functions are a modified version of SIGMA-I [26], using AEAD and ECC for symmetric and asymmetric key cryptographyrespectively. As for the security concerns, these protocols are secure against attackssuch as impersonation, replay attacks, eavesdropping, and have identity protectionand forward secrecy characteristics. Users are not responsible for memorizing orgenerating the credentials for the main functions. Pico produces secure credentialsfor each server, and exploits information encoded in the QR code on the clientbrowser to search for credentials stored in the Pico database.

51

6. Conclusions and Future Work

Our proposed Pico prototype is implemented on a Android smartphone, usingspongycastle library for cryptographic algorithms. A login or enrol operation startsby the users pressing the only button on the display, and then captures the QRcode image on the client browser. This out-of-band channel transmits the serverinformation to Pico, enabling it to search corresponding credentials in its SQLitedatabase. The messages interchanged with Pico are all encoded in Base64 encoding.Next, the user has a chance to confirm that the subsequent action is consistent withhis or her intention. Once the action is confirmed, Pico initiate a child thread toperform the login or enrol protocols. Finally, if mutual authentication succeeds,another child thread is invoked to handle the later continuous authentication withserver.

The evaluation results of this prototype is presented in Chapter 5. Severaloptimizations are applied to improve user experience and execution time, such asprecomputation, instance reuse, and background processing. A basic profiling resultis given in the chapter, along with performance comparison of different EC curves.As a result, an entire login operation excluding the user interactions completes withina few seconds. Although the prototype in this thesis is built on a smartphone,because of the convenience in development of a demonstration device, it is ableto deliver a first insight into the feasibility and usability of Pico system. Whenexamining the properties promised by the original Pico proposal, we can see thatour implementation accomplishes most of the significant properties, especially thesecurity aspects. Hence, the proposed design proves the fact that Pico is a suitablecandidate to replace the passwords in the future.

6.2 Future work

Based on the specification and prototype device developed in this thesis, several linesof study can be pursued. These insights into possible research directions could bringfuture interests related to this topic.

1. Building the Pico hardware:This prototype is implemented on a smartphone for demonstration purpose, asexplained in Section 4.1, but not in actual use. The reasons is that a smartphoneis vulnerable to attacks like trojan horse or viruses; and has the potential threatof leaking information to other installed applications. An official Pico deviceshould be in a stand-alone hardware containing functionalities similar to thisprototype. Our implementation has proven that with the hardware components,described in Section 3.3, Pico can achieve most of the desirable properties.However, the locking/unlocking, backup, and Picosiblings can only be realizedby a specifically designed hardware. Also, the locking mechanism in thisprototype is by a PIN, which might also be replaced by facial recognition orother techniques. Hence, it is worth researching on building a Pico as hardwaretoken, based on the specification defined in this thesis.

52

6.2. Future work

2. Conducting usability testing:One challenge for Pico will be the usability issue that numerous replacementsof password system failed in. Usability testing involves real users to assesswhether the product can accomplish its intended purpose, and the level ofsatisfaction of users. Collecting feedbacks from different types of users helpssignificantly in improving user experience of the design. We did not conduct theusability test for Pico prototype due to the limitation in time. Nevertheless,such a test conducted with this prototype is beneficial to future hardwareimplementation.

3. Extending applicable situations:An advantage of Pico over other password replacements is the potential offlexibility. By utilizing a 2-D visual code or image recognition techniques, Picois able to authenticate with various applications. For instance devices such ascomputers and electronic safe, having a screen to display the visual code, arehighly possible targets. If Pico can manage other credentials, the motivationof users will definitely elevate.

53

Bibliography

[1] A. Adams and M. A. Sasse. Users Are Not the Enemy. Commun. ACM,42(12):40–46, Dec. 1999.

[2] P. S. Aleksic and A. K. Katsaggelos. Audio-Visual Biometrics. Proceedings ofthe IEEE, 94(11):2025–2044, 2006.

[3] E. Barker, W. Burr, A. Jones, et al. Recommendataion For Key Management .Technical report, National Institute of Standards and Technology, 2009.

[4] M. Bellare, P. Rogaway, and D. Wagner. The EAX Mode of Operation (A Two-Pass Authenticated-Encryption Scheme Optimized for Simplicity and Efficiency),2004.

[5] J. Bonneau, C. Herley, P. C. van Oorschot, and F. Stajano. The Quest to ReplacePasswords: A Framework for Comparative Evaluation of Web AuthenticationSchemes. In Security and Privacy (SP), 2012 IEEE Symposium on, pages553–567. IEEE, 2012.

[6] J. Bonneau and S. Preibusch. The Password Thicket: technical and marketfailures in human authentication on the web. In 9TH WORKSHOP ON THEECONOMICS OF INFO SECURITY (WEIS 2010), 2010.

[7] J. Brown. The ZBar Android SDK. http://zbar.sourceforge.net/.

[8] Certicom Corp. SEC 2: Recommended Elliptic Curve Domain Parameters.Technical report, 2005.

[9] S. Chiasson, P. C. van Oorschot, and R. Biddle. A Usability Study and Critiqueof Two Password Managers. In 15th USENIX Security Symposium, pages 1–16,2006.

[10] J. Daugman. How Iris Recognition Works. Circuits and Systems for VideoTechnology, IEEE Transactions on, 14(1):21–30, 2004.

[11] C. Davis. Robohash. http://robohash.org/.

[12] M. Di Raimondo, R. Gennaro, and H. Krawczyk. Deniable authentication andkey exchange. In Proceedings of the 13th ACM conference on Computer andcommunications security, CCS ’06, pages 400–409, 2006.

55

Bibliography

[13] W. Diffie, P. C. Van Oorschot, and M. J. Wiener. Authentication and au-thenticated key exchanges. Designs, Codes and Cryptography, 2(2):107–125,1992.

[14] Facebook Connect, 2008. https://developers.facebook.com/blog/post/2008/05-/09/announcing-facebook-connect/.

[15] Federal Information Processing Standards Publication. ECRYPT II YearlyReport on Algorithms and Keysizes (2010-2011). Technical Report ICT-2007-216676, ECRYPT II, 2011.

[16] D. Florêncio, C. Herley, and B. Coskun. Do Strong Web Passwords AccomplishAnything. Proc. Usenix Hot Topics in Security, 2007.

[17] Google Inc. Android APIs Package Index. http://developer.android.com/-reference/packages.html.

[18] F. Hao, R. Anderson, and J. Daugman. Combining Crypto With BiometricsEffectively. Computers, IEEE Transactions on, 55(9):1081–1088, 2006.

[19] C. Herley and P. Van Oorschot. A Research Agenda Acknowledging the Persis-tence of Passwords. Security & Privacy, IEEE, 10(1):28–36, 2012.

[20] ISO/IEC. Information technology - Automatic identification and data capturetechniques - Bar code symbology - QR Code. Technical Report ISO/IEC 18004,The International Electrotechnical Commission, 2000.

[21] ISO/IEC 9798-3. Entity Authentication Mechanisms. 1993.

[22] JSON.org. Introducing JSON. http://www.json.org/.

[23] KeePass, 2010. http://keepass.info/.

[24] D. V. Klein. "Foiling the Cracker": A Survey of, and Improvements to, PasswordSecurity. In UNIX Security Workshop II, The Usenix Association, 1990.

[25] H. Krawczyk. The Order of Encryption and Authentication for ProtectingCommunications (or: How Secure is SSL?). pages 310–331. Springer-Verlag,2001.

[26] H. Krawczyk. SIGMA: The "SIGn-and-MAc" Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols. In D. Boneh, editor, Advances inCryptology - CRYPTO 2003, volume 2729 of Lecture Notes in Computer Science,pages 400–425. 2003.

[27] M. Dworkin. NIST-Recommendation for block cipher modes of operation:Galois/counter mode (GCM) and GMAC. Technical report, National Instituteof Standards and Technology, 2007.

56

Bibliography

[28] J. McCune, A. Perrig, and M. Reiter. Seeing-is-believing: using camera phonesfor human-verifiable authentication. In Security and Privacy, 2005 IEEE Sym-posium on, pages 110 – 124, may 2005.

[29] OpenID. http://openid.net/.

[30] ORACLE. Java Cryptography Architecture (JCA) Reference Guide for JavaPlatform SE 6.

[31] D. Park. Identicon. http://blog.docuverse.com/tag/identicon/.

[32] A. Pashalidis and C. J. Mitchell. A Taxonomy of Single Sign-On Systems. InInformation Security and Privacy, pages 249–264. Springer, 2003.

[33] PasswordSafe, Feb. 2010. http://passwordsafe.sourceforge.net/.

[34] A. Perrig and D. Song. Hash Visualization: a New Technique to improve Real-World Security. In In International Workshop on Cryptographic Techniques andE-Commerce, pages 131–138, 1999.

[35] P. Rogaway, M. Bellare, J. Black, and T. Krovetz. OCB: A Block-Cipher Modeof Operation for Efficient Authenticated Encryption. pages 196–205, 2001.

[36] A. Shamir. How to Share a Secret. In Communications of the ACM, volume 22,pages 612–613, 1979.

[37] F. Stajano. Pico: No More Passwords! In Proc. Security Protocols Workshop2011, volume 7114, pages 49–81, 2011.

[38] Vash. https://github.com/thevash/vash.

[39] R. Wang, S. Chen, and X. Wang. Signing Me onto Your Accounts ThroughFacebook and Google: a Traffic-Guided Security Study of Commercially De-ployed Single-Sign-on Web Services. In Security and Privacy (SP), 2012 IEEESymposium on, pages 365–379. IEEE, 2012.

[40] D. Whiting, R. Housley, and N. Ferguson. Counter with CBC-MAC (CCM).Technical Report RFC 3610, 2003.

[41] ZBarScanner. https://github.com/DushyanthMaguluru/ZBarScanner.

57

KU Leuven Faculty of Engineering 2012 – 2013

Master thesis filing card

Student: Hsing Ping Fu

Title: Pico: No More Passwords!

UDC : 621.3

Abstract:Passwords are tightly connected to people’s lives today. However, memorizing eachcomplicated password is painful for users. As an alternative to password-basedauthentication system, Stajano [37] proposed the idea of Pico, an authenticationdevice that manages and utilize for accessing application accounts. This thesisdefines and realizes the details on core operations of Pico to fulfill the missingimplementation issues in Stajano’s paper. The specifications cover cryptographicprotocols, communication methods, user interface design. We realize a prototype on asmartphone for evaluating the initial performance and usability. This implementationis capable of executing login for the user with a demonstration server within a fewseconds, and satisfies most of the desirable properties of Pico.

Thesis submitted for the degree of Master of Science in Electrical Engineering,option Embedded Systems and MultimediaThesis supervisor : Prof. dr. ir. Bart PreneelAssessors: Prof. dr. ir. Patrick Wambacq

Dr. ir. Stefaan SeysMentors: Dr. ir. Jens Hermans

Dr. ir. Roel Peeters