OffPAD: Ofﬂine Personal Authenticating Device ...

OffPAD: Offline PersonalAuthenticating Device –Implementations andApplicationsChristian Johansen , Audun Jøsang , Denis Migdal

Research report 454, August 2016

ISBN 978-82-7368-419-6

ISSN 0806-3036

1

Abstract

Identity and authentication solutions often lack usability and scal-ability, or do not provide high enough authentication assurance. Theconcept of Lucidman (Local User-Centric Identity Management) is anapproach to providing scalable, secure and user friendly identity andauthentication functionalities. In this context we demonstrate the useof an OffPAD (Offline Personal Authentication Device) as a trusted de-vice to support different forms of authentication. The Lucidman/Off-PAD approach consists of locating the identity management and au-thentication functionalities on the user side instead of on the serverside or in the cloud. This demo aims to show how OffPAD strengthensauthentication assurance, improves usability, minimizes trust require-ments, and has the advantage that trusted online interaction can beachieved even in the presence of malware infection of client platforms.The trusted device OffPAD has been designed as a phone cover, there-fore not requiring the user to carry an extra gadget. We focus on sixdemonstrators, three useful in e-banking and three in the hospital do-main where nurses, doctors, or patients are authenticated and accessis granted in various situations base on the OffPAD.

0Address for Denis Migdal:Ecole Nationale Supérieure d’Ingénieurs de Caen, 6 Boulevard Maréchal Juin, 14000 Caen,FranceE-mail: [email protected]

Address for Christian Johansen (né Cristian Prisacariu):Department of Informatics, University of Oslo, P.O. Box 1080 Blindern, 0316 Oslo, Norway.E-mail: [email protected]

Address for Audun Jøsang:Department of Informatics, University of Oslo, P.O. Box 1080 Blindern, 0316 Oslo, Norway.E-mail: [email protected]

CONTENTS 2

Contents

1 Motivation and Background 4

2 OffPAD device description 52.1 Hardware specification . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Sensors and Security . . . . . . . . . . . . . . . . . . . 72.1.3 Secure display . . . . . . . . . . . . . . . . . . . . . . . 82.1.4 General considerations . . . . . . . . . . . . . . . . . . 8

2.2 Software features . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 OffPAD demonstrators 93.1 E-banking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Hospital environments . . . . . . . . . . . . . . . . . . . . . . 10

4 Data Authentication based on OCR 114.1 Data Authentication . . . . . . . . . . . . . . . . . . . . . . . 11

4.1.1 Background and motivation . . . . . . . . . . . . . . . 114.1.2 High-level description for Data Authentication Sup-

ported by the OffPAD . . . . . . . . . . . . . . . . . . 124.2 Detailed Description of the Data Authentication Ceremony . . 15

4.2.1 Structure of the Security Ceremony for Data Authen-tication . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.2 Secure Run of the Ceremony for Data Authentication . 194.2.3 API descriptions . . . . . . . . . . . . . . . . . . . . . 224.2.4 A Concrete Application . . . . . . . . . . . . . . . . . 24

5 User Authentication based on HTTP XDAA 275.1 User Authentication using Biometrics through OffPAD . . . . 27

5.1.1 Background and motivation . . . . . . . . . . . . . . . 275.1.2 High-level description for User Authentication through

OffPAD . . . . . . . . . . . . . . . . . . . . . . . . . . 285.2 Detailed Description of the Ceremony for User Authentication

using OffPAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2.1 Structure of the Security Ceremony for User Authen-

tication . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2.2 Secure Run of the Ceremony for User Authentication . 305.2.3 API descriptions . . . . . . . . . . . . . . . . . . . . . 325.2.4 A Concrete Application . . . . . . . . . . . . . . . . . 33

CONTENTS 3

6 Server Authentication by the User based on Petname 346.1 Server Authentication by the User . . . . . . . . . . . . . . . . 34

6.1.1 Background and motivation . . . . . . . . . . . . . . . 346.1.2 High-level description for Server Authentication . . . . 36

6.2 Detailed Description of the Server Authentication Ceremonyby the User . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2.1 Structure of the Security Ceremony for Server Authen-

tication . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2.2 Secure Run of the Ceremony for Server Authentication 386.2.3 API descriptions . . . . . . . . . . . . . . . . . . . . . 406.2.4 A Concrete Application . . . . . . . . . . . . . . . . . 41

7 Contextual automatic login based on indoor location 427.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 427.1.2 Standard automatic login-logoff . . . . . . . . . . . . . 42

7.2 eHospital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437.2.1 eHospital infrastructure . . . . . . . . . . . . . . . . . 437.2.2 Sonitor sense . . . . . . . . . . . . . . . . . . . . . . . 447.2.3 User . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447.2.4 Hospital Network . . . . . . . . . . . . . . . . . . . . . 457.2.5 SmartTracker . . . . . . . . . . . . . . . . . . . . . . . 45

7.3 eHospital Automatic Terminal Logon Access System (ATLAS) 457.3.1 Pairing . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.3.2 Soft authentication . . . . . . . . . . . . . . . . . . . . 467.3.3 Hard authentication . . . . . . . . . . . . . . . . . . . 467.3.4 Multi-login . . . . . . . . . . . . . . . . . . . . . . . . 467.3.5 Disconnection . . . . . . . . . . . . . . . . . . . . . . . 47

7.4 API descriptions . . . . . . . . . . . . . . . . . . . . . . . . . 477.4.1 OffPAD - SmartTracker API . . . . . . . . . . . . . . . 47

8 Alternative Applications and Implementations 49

9 Security services 50

10 Discussion and Conclusion 50

1 MOTIVATION AND BACKGROUND 4

Acknowledgements:

We thank all OffPAD project members who have either put effort into parts ofthis technical report or have contributed with great ideas or discussions; par-ticularly to: L.Dallot, L.Miralabe, and G.Cornet (TazTag, manufacturer ofsecure mobile hardware) K.E.Husa and S.Morka (TellU, providing IoT plat-form and services), M.P.Haugen (U.Oslo), C.Rosenberger and E.Cherrier(ENSI Caen GREYC lab), A.Taherkordi (Sonitor, manufacturer of indoorlocating solutions).

1 Motivation and Background

We present the OffPAD concept, i.e., the hardware, a phone-jacket withsecure elements, and software components. The concept of OffPAD has beenput forward in [17], part of the project called OffPAD.1 Several use caseshave been identified to show case the OffPAD in the domains of e-bankingand hospitals.

One purpose of the OffPAD is to provide higher security without reducingthe usability, i.e., have minimal interference with the normal tasks of the user,yet automate some of the authentication related tasks.

Related works are discussed in the journal paper [17].The distinction between a system entity (client or server) and a legal/cog-

nitive entity (person or organisation) brings into play multiple entities oneach side in the client-server model, as illustrated in Fig.1. A requirementfor trusted interaction in this scenario is to have mutual authentication be-tween pairs of interacting entities whenever relevant, leading to 4 possibletypes of mutual entity authentication as shown in Fig.1 and described inTables 1 & 2.

Cognitive entity authentication requires the relying party to have cogni-tive reasoning power, such as in humans, animals or advanced AI systems.This authentication modality effectively prevents phishing attacks becauseusers recognise the server identity and decides whether it is the intendedone.

User identity management is frequently discussed in the identity manage-ment literature, whereas SP identity management is mostly discussed in thenetwork security literature. Lucidman applies to both types because usersmust manage their own identities as well as those of SPs, in order to beauthenticated by server systems on a semantic level, and to authenticate theserver systems on a cognitive level. Lucidman is aimed at providing adequate

1www.offpad.eu

2 OFFPAD DEVICE DESCRIPTION 5

Service Provider (P)

Server System (S)

User Side

Human User (U)

Untrusted Infected Client (C)

Server Side Authentication

Classes

Trusted

Interactions

P®U

P®C

S®U

S®C

U®P

U®S

C®P

C®S

Trusted

Element

OffPAD

Figure 1: Trusted interactions in the presence of malware-infected clients

Class Authentication of user-side entities[U → P] User (U) authentication by the service provider

(P)[U → S] User (U) authentication by the server system

(S)(called user authentication)

[C → P] Client (C) authentication by the serviceprovider (P)

[C → S] Client (C) authentication by the server system(S)

Table 1: Authentication classes for user-side entities as illustrated in Fig.1

security assurance and usability for the management of both user identitiesand server identities, with the goal of enabling trusted interaction betweenonline entities.

2 OffPAD device description

The OffPAD is a trusted device, i.e. assumed to function as intended andto be adequately protected against relevant attacks. The first OffPAD pro-totype is a phone cover connected to its host with a standard micro-USBinterface. This makes the OffPAD a portable object, but not a second elec-tronic object in the user’s pocket. Unlocking the OffPAD is currently donethrough fingerprint biometrics.

OffPAD is considered offline, meaning that communications follow con-trolled formats, during short and restricted time periods, not involving wire-less broadband capabilities, i.e., we use only micro-USB or NFC communi-


Class Authentication of SP-side entities[P → U] Service provider (P) authentication by the hu-

man user (U)[P → C] Service provider (P) authentication by the user

client (C)[S → U] Server (S) authentication by the human user

(U)(called cognitive server authentication)

[S → C] Server (S) authentication by the user client (C)

Table 2: Authentication classes for SP-side entities as illustrated in Fig.1

cations.Being offline eliminates exposure to Internet threats. Thus we assume

that attackers are unable to exploit bugs in OffPAD’s operating system andapplications.

The first connection to the OffPAD requires Trust-On-First-Use (TOFU),also known as leap-of-faith. On first use, there is no cryptographic way toverify the connection between the device and the client platform, the trustmust simply be based on the physically observed set-up.

2.1 Hardware specification

A schematic view of OffPAD design is illustrated in Fig.2.

Figure 2: OffPAD v.1 design elements

OffPAD integrates the following hardware components:

2.1.1 Usability

We aim to integrate the OffPAD into the user ecosystem for better accep-tance. People have already a lot of devices and peripherals in their pockets,


Component Description ModelController ARM Cortex-M4

32b MCU+FPU, 105DMIPS, 256KB Flash/ 64KB RAM

STM32F401

Secure display e-Ink 2.5 inchesNFC transceiver NFC Forum Certified NPC1002A2EVSecure element Java Card / Global

Platform compliantST33FIMFF,ST Micro

USB interface USB OTG 2.0 (Highspeed)

Fingerprint sensor Pixel matrix 192x192pixels @502 dpi

FPC1020 Touch Fin-gerprint Sensor

3 states switch On / Off / Mainte-nance

Mechanical switch

Flash memory For private and securestorage

4 to 16GB

LED Multicolor Multicolor

studies show that they want to limit the number of those device and ideallybring only their phone which is the most personal and preferred communi-cating object .

As the OffPAD is meant to be a device the user wear, it must be easilyportable this its size and weight must be reasonable.

2.1.2 Sensors and Security

Most of sensors are fundamentally insecure. Indeed, either one side of thechannel cannot be controlled (e.g. GPS) or the physical environment canbe easily distorted (e.g. magnetometer). For instance, a non secure channelcan be spoofed [14]. Physical environment can also be artificially manipu-lated by electrical or magnetic fields altering magnetometer and even someaccelerometers.

We assume that the sensors integrated in the OffPAD are secure. As weconsider that it is not critical to embed such sensors into a secure platform, wekeep the OffPAD core as simple as possible for economical and size reasons.OffPAD makes use of the host phone for other sensors, like camera, thus amalware on the phone can communicate false information to the OffPAD.OffPAD also asks the host phone for the more heavy computations, e.g.,for OCR. However, all these inputs from the phone are considered in our


scenarios as untrusted.The prototype is non full-secured as it is not tamper resistant and embeds

a processor non-secured against physical threats such as side channel attacks.Indeed implementing those protections would have a strong impact in designcost or in end-user usability without any benefit on the experimental powerof the current prototype.

2.1.3 Secure display

As stated in section 4, standard displays cannot be trusted by the user as amalware might modify what should be printed. By adding secure display onthe OffPAD, we give the user displays that she can trust in. We use a multi-color LED for simple information transmission and a mono-chrome e-Paperscreen for advanced information which can print 40 characters per line and4 lines.

2.1.4 General considerations

To maximize the security and the universality of the OffPAD, we based thesecurity on hardware secure components that can be attached to any devices(phone or PC) that provides communication interfaces. For this reason wechoose to use USB communication as is compliant with all Android phoneand micro-USIB is a standard interface on theses devices.

We choose to implement the OffPAD as a phone cover as it does notconstitute an extra-object in the user pocket and is transportable.

2.2 Software features

The OffPAD is accessed on the phone through an Android Service, the Off-PAD service. The OffPAD services provides an API described with AndroidInterface Definition Language (AIDL) which allows API definition in Java-like style. Thus after bounding the OffPAD service, an application can accessthe OffPAD features simply by calling methods on an object. Theses callsare transformed by Android to be transmitted to the recipient service. Inour cases, theses transformed calls are transmitted by USB to the OffPADdevice.

The OffPAD service defines its own permissions that must be requestedby any application wishing to use the OffPAD’s functionalities).

Other features can be built on-top of the OffPAD service’s provided fea-tures, theses features could be then integrated in the OffPAD-side in futurework.

3 OFFPAD DEMONSTRATORS 9

The OffPAD firmware supports the following features:User Authentication by performing a biometric authentication of the

holderManage certificates in OffPAD’s certificate store to check signature,

s.a. for authenticating service provider’s identity.Sign and check signature using the OffPAD’s holder private key un-

locked after successful holder’s authentication.Show sensitive information using the e-Ink display or the multi-color

LED.Biometric user enrollment on the OffPAD according to the specified

biometric modality.

3 OffPAD demonstrators

In this technical report, we present the following applications of OffPAD :

Data-US: Authentication of user Data by the Service provider, to be basedon OCR (Optical Character Recognition) displayed on the OffPADink-screen, as detailed in section 4.

SU: Server authentication by the User, to be based on petname systems [9]managed by the OffPAD, as detailed in section 6.

US: User authenticated by the service provider, based on an extended challenge-response protocol XDAA [23] between the client terminal and OffPAD,as detailed in section 5.

Auto-login: Contextual automatic login/logoff based on indoor location ofthe OffPAD using Sonitor system, as detailed in section 7.

Multi-login: Automatic access to a resource conditioned on multiple usersauthenticated at once, using TellU SmartTracker system, as detailed insection 7.

Strong auth.: Strong authentication required for accessing sensitive infor-mation or tasks, using biometric fingerprint authentication of the userby the OffPAD, as detailed in section 7.

3.1 E-banking

Internet operations such as banking operations needs at least 3 types ofauthentications :

3 OFFPAD DEMONSTRATORS 10

• authentication of the ordering person (the user) ;

• authentication of the operating ;

• authentication of operation’s content.

The operating system has to ensure the user’s identity to confirm thathe has the right to query for such operation. Ensuring the user’s identityremains on verifying that she knows a secret, such as credentials. Thus thissecret has to be keep confidential and must not be exposed to outsiders.We propose the usage of XDAA [23], detailed in section 5, to not exposecredentials on possibly infected client that may leak users’ credentials whenperforming operations.

The ordering person has to ensure that he sends his information to theoperating, and not to another, system, as theses informations are often sen-sitives (e.g. credentials) and could be used by an outsider to usurp the user’sidentity and make operations in her name, such as transferring money fromthe user’s account to the thief’s. We propose the usage of petname [9], de-tailed in section 6, for the user to perfom cognitive authentication of theoperating based on its domain-name, thus avoiding her to transmit her cre-dentials on a phishing website.

The ordering person also has to ensure the operation’s content, as modi-fication on the operation may be prejudicial, such as sending 200£ instead of100£ during a banking transfert. We introduce the usage of data authenti-cation, as detailed in section 4, to ensure the operation’s content even if thestandard display is corrupted.

3.2 Hospital environments

Hospitals are a hectic working environment where a multitude of users withdiverse roles interact with hospital IT shared systems for various duties likepatient records, routine information, or logging of medical tasks. However,patient information security and privacy must still be ensured throughoutthe daily work. This implies that the hospital staff must log on to terminalsand be authorized every time they interact with IT systems. This has beenfound very time consuming and distracts attention from primary tasks.

The OffPAD proposes to focus on context-aware authentication mecha-nisms to relieve the user from the burden of a frequent login/logoff process.We introduce in section 7 a location-based authentication mechanism wherethe user will be automatically logged (Auto-login) into a terminal when sheapproaches the terminal, and logged off from it when she leaves the terminal.We also provide Multi-login and strong authentication.

4 DATA AUTHENTICATION BASED ON OCR 11

4 Data Authentication based on OCR

4.1 Data Authentication

4.1.1 Background and motivation

According to the X.800 standard the concept of data origin authentication is"the corroboration that the source of data received is as claimed" [7]. This isdifferent from entity authentication because knowing the identity of a remoteentity in a session (entity authentication) is different from knowing whetherthe data received through a session with a specific remote entity genuinelyoriginates from that entity. This difference might sound subtle at first glancebut it is in fact fundamental for security, as explained below.

Malware infection of client platforms opens up for attacks against dataauthentication that entity authentication can not prevent. More specifically,entity authentication is insufficient for ensuring trusted interaction in case theclient platform is compromised. A typical example is the situation of onlinebanking transactions with mutual entity authentication. Even when there isstrong 2-factor user authentication, and we assume that users correctly inter-pret server certificates for server authentication, there is the possibility thatmalware on the client platform can modify data communicated between clientand server platforms, and thereby compromise transactions. Current attacksagainst online banking are typically mounted in this way. Such attacks leadto breach of data integrity, but not a breach of entity authentication.

The preparation for this type of attacks typically includes tricking theuser into installing a Trojan, i.e. a program that really or seemingly doessomething useful, but that in addition contains hidden malicious functionalitythat allows the attacker to take control of the client platform. During anonline banking transaction the attacker uses the Trojan program to changetransaction details without the user’s knowledge. SpyEye, Zeus, IceIX, TDL,Hiloti, Carberp, and many others [6, 25] are concrete examples of malwarethat enable such attacks.

The separation between the human/legal entity and the system entity oneach side of a client-server session makes it necessary to specify which entityin particular is the assumed origin of data. In case e.g. the human user isassumed to be the origin, and the client system modifies data input by theuser before it is sent to the server system, then this would be a breach of dataorigin authentication. However, in case the client system is assumed to be theorigin, the same scenario would not be a breach of data authentication. Thegeneral rule is that the object of entity authentication must also be the originof data authentication. For typical online transactions where the human user


is directly involved and authenticated, the user must also be seen as the originof data for data authentication purposes. Unfortunately current solutions foruser data origin authentication are either non-existent or inadequate becausethey assume the client system to be the origin of data [2].

Users rely on visual cues to know whether a browser session is securedwith TLS. After verifying that TLS is enabled, averagely security aware userswill comfortably input their banking account and transaction details intothe browser window. However, many users ignore that malware like thosementioned above has functionality commonly known as a "web inject" thatcan change the behaviour of the browser and modify input and output dataarbitrarily.

The fact that entity authentication and data authentication are two sep-arate security functions implies that it is necessary to have specific securitymechanisms to ensure data integrity in online transactions. The OffPADenables data origin authentication with high assurance and usability, as ex-plained below.

4.1.2 High-level description for Data Authentication Supportedby the OffPAD

Users generally rely on what they see on a computer display to read theoutput of transactions, to verify that they type correctly, and to ensure thatthe data being sent through online transactions is according to their inten-tions. In general, all this depends on the integrity of the computing platformto which the VDU (Visual Display Unit) is connected. Assuming that thecomputing platform is infected with malware it is a priori impossible to trustwhat is being displayed to be 100% correct [1, 16, 19, 29, 31].

The prospect that the computer display can lie to us is both frighteningand real. This problem is amplified by the fact that we often read data fromplatforms that are not under our control, and that hackers have incentivesfor trying to manipulate the systems and the way data is displayed. Forexample, typical attacks against online banking consist of using a maliciousTrojan on a client computer to send falsified transaction data to the bankserver while displaying what the user expects to see.

In order to provide data authentication, some online banks offer SMSauthorization of transactions, which consists of mirroring the received trans-action data (destination account and amount to be transferred) together withan authorization code by SMS to the user. After verifying the correctness ofthe transaction data, the user returns the authorization code via the browserto confirm that the integrity of the transmitted transaction data. In case ofan attack, it is assumed that the user will notice when transaction data have


been changed, so the attack can be stopped by canceling the transaction.This method can in theory provide strong data authentication, but it puts arelatively high cognitive load on the user for verifying the transaction data.In a study, it has been shown that about 30% of users fail to notice whentransaction data in an SMS message have been changed, which means that30% of attacks would succeed even in the presence of SMS authorisation [2].The problem with SMS-authorisation is poor security usability, which fortu-nately can be solved with Lucidman as is explained below.

Fig.3 illustrates a simple ceremony for data origin authentication, i.e. toensure that what is displayed on the VDU corresponds to what is being trans-mitted to other parties in online transactions. The method assumes that theuser has an OffPAD with integrated camera, OCR (Optical Character Recog-nition) and communication functions. The user first captures a screenshotfrom the VDU with the OffPAD camera, then uses the OffPAD to recoverthe displayed data from the image through OCR, and finally to compute aMAC (Message Authentication Code) which is sent along with the originaltransaction data. The MAC enables the recipient server to authenticate thereceived original data.

Internet

3

5

7

4

Server Infected

Client OffPAD

User

5 4

AD

1

2 6

User

8

Figure 3: Ceremony for data authentication with the OffPAD

The actions/messages of the ceremony are described in Table 3.Even though it is assumed that the client platform is infected, it is easy to

see that attackers will not be able to falsify the transaction data undetected.Falsified transaction data would produce a MAC mismatch, which would bediscovered by the server in (8).

In order to successfully falsify data, the attacker would have to compro-mise both the client platform and the OffPAD simultaneously. Since theOffPAD is offline, it is assumed that the OffPAD will not be exposed tothreats from the Internet.

One drawback of the above ceremony is the use of OCR technology on theOffPAD device side. OCR recognition is computational intensive, and maynot be scalable to any graphical user interface that the browser provides. We


Nr. Message / action description1. User types the transaction data in a browser window on the

client computer2. User activates the OffPAD to take a snapshot of the browser

window3: Snapshot is taken of the text displayed in the browser window

on the VDU4. The OCR function recovers the transaction data from the

snapshot5. MAC generation with the transaction data and the user-

password as input6. OffPAD send the MAC to the client computer7. Client computer sends transaction data together with MAC

to server8. Server verifies that the MAC corresponds to the received

transaction data.

Table 3: Sequence of messages and actions for data authentication ceremony

would like to put the computational burden on the PC client machine thatthe browser and transaction is being done, even if this can be infected bymalware. And we would like the task of the OffPAD device to use as littlecomputation power as possible.

We want to achieve this by adapting the idea of proof-carrying-code fromsoftware code to data. Proof-carrying-code intuitively works in two stages,one is the compilation stage where the proof is generated, and the other is theverification of the proof and execution of the compiled software. Generationof the proof is a more computational intensive part, whereas checking of thevalidity of the proof is the easy task.

For data authentication we ask the client to generate the proof of authen-ticity of the data (as e.g., with MACs). The client then displays the proofto the user in the form of a bar-code. This can be easily scanned by the Off-PAD device (with the same camera as the OCR is using). The verificationof this proof by the OffPAD device is simple and it uses the credentials ofthe user, the same credentials that were used to authenticate to the server.These credentials are the secure bit that only the user (OffPAD device) andthe server know, but which the (possibly infected) client does not know.


4.2 Detailed Description of the Data Authentication Cer-emony

We will present first the structure of the ceremony and discuss its com-ponents. We then continue to describe the secure run that we see of thisceremony. Any other possible runs should be considered insecure. In the endwe discuss the API associated to this ceremony and present some sequencediagrams. These would be similar, but more concrete, to the description ofthe secure run.

4.2.1 Structure of the Security Ceremony for Data Authentica-tion

The structure of the Data ceremony is pictured in Figure 4. It comprises of:

Identities of the actors involved in the ceremony. Here we have two: theUser (U) and the Bank (B). For visual aid, we encircle all the config-uration under the control of the same agent.

Configurations which are the various parts involved in the ceremony, bethat devices or human persons. Here we have:

• Five basic configurations, which are depicted as the black circles,and labelled according to their purpose. From right to left, theseare:

SB which represents the Server of the Bank. This is why thisconfiguration is under the control of the Bank identity (rep-resented as the under-script). In Figure 3 this is representedas the server box.

Term which represents the Terminal to which the user is sup-posed to interact in order to perform the transaction oper-ation. In Figure 3 this is represented as the laptop whichmay be infected with malware. But the terminal can be otherthings as well, e.g., the Internet Browser that is used to com-municate with the bank, or the SmartPhone, or an App onthe SmartPhone.Note that the Terminal is not under the control of any of thetwo identities. Therefore it is left open to potentially becomeunder the control of an Attacker.At this level of description it is good to leave room for suchvariations. But at the later point when we describe the se-quence diagram we may become even more concrete.


OAU which represents the OffPAD Software Agent that is sup-posed to be deployed on the Terminal (or otherwise) to facili-tate the interaction of the Terminal with the OffPAD TrustedHardware OHU. The software agent is assumed to be underthe control of the User.

PU which represents the Persona of the user (i.e., the humanpart of the ceremony). We do not focus on the concept ofPersonas here, but consider it as is usually done to representthe Human User involved in the protocol. For more detailsabout Personas please see our paper [15] and the referencestherein.

OHU which represents the OffPAD Trusted Hardware which isassumed to offer the following trusted hardware components:computation power, biometric imput in the form of Finger-print Reader, visual output in the form of InkDisplay, andNFC communication capabilities.

• One complex configuration, (depicted as a small black square)which we will call the OffPADU being formed of putting togetherthe OffPAD Hardware and the OffPAD Agent to share informa-tion between each other. The dashed lines symbolize the complexconfiguration and how information can flow from the componentsto the back square and back. This complex configuration is thusunder the control of the User. How the sharing of informationis done is not so important as long as it respects the assumptionthat it is secure, i.e., it cannot be intercepted by an attacker. Forthis the TazTag will implement this sharing using NFC commu-nication.

The precise implementation of the sharing of information betweenthe Hardware and the Agent is important, and will be detailedfurther.

Channels which represent the various ways of transmitting information orinteracting in some sort between the parts of the ceremony (i.e., be-tween the configurations). The channels are depicted as grey arrows,pointing in the direction of the flow of informations, and are labelledwith the type of channel. The type of channel encapsulates the secu-rity assumptions we have about this interaction medium, and we willmake these precise. We are working on developing a formalism for this,which can be used in conjunction with the formalism we have presentedin [27] for the rest of the AMP ceremony to achieve formal verification.


U

BSB

PU

UOAUOH

cyb

cyb

key

vis

Termcmd

UOffPad

visInk

bio

OSchan

IMG

blue

Figure 4: ANP structure for the Data authentication ceremony.

The ceremony comprises of the following channels:

• There are two cyber-channels (cyb) between the Server of theBank and the Terminal. Cyber channels carry the assumptionsthat are un-safe, falling under the standard Dolev-Yao model ofattacker which can listen to messages, change messages, and insertnew messages.

• There is a visual channel (vis) between the Terminal and the Per-sona. This can be achieved through any standard display screen,as that of a laptop or of a SmartPhone. The assumption is thatnothing can change the messages sent on this channel, and thusthe Persona receives whatever is sent by the Terminal. But thisdoes not exclude that an infected Terminal sends spurious infor-mation on this channel.

• There is also a keyboard channel (key) which can be used by thePersona to input information to the Terminal. Similar assump-tions as with the visual channel hold here as well.

Note that in both the above channels we do not consider any otheraspects like the drivers which handle the information processingfor these channels on the Terminal side. We consider these driversto be part of the Terminal. Therefore, if the Terminal is underthe control of the Attacker these drivers may be as well, and thushandle information in unexpected ways. For example, we maytype one character at the keyboard, but the driver changes it intoanother; this may not be observable either because the visual dis-play driver is manipulated as well, or just because of the situation,


like with a password form field where instead of seeing what wetype we just see star symbols.

• There is also a visual InkDisplay channel (visInk) from the Off-PAD hardware to the Persona. Assumptions are made of thischannel similar to the other visual channel. The InkDisplay isthough more rudimentary and thus can display more simplisticinformation, and maybe without all the visual aids of a fully-fledge visual laptop display. For example colours are not availablehere, so any visual aids that are usually used to help users, likecolor red for danger/unsecure, or color green for secure. This alsomay make the communication of the information to the user moreerror prone, in the sense that the user may not distinguish well theinformation displayed. Such situations can be taken advantage byan Attacker in a Social-engineering attack.

On the other hand, the fact that this channel is between the Off-PAD hardware means we can add more assumptions and say thatthe drivers that handle the information displayed cannot be ma-nipulated.

• A biometrics channel (bio) transfers Fingerprint biometrics fromthe Persona to the OffPAD hardware.

• We have added also a commands channel (cmd), which commu-nicates very simplistic command messages, OK, StartTransaction,StartOCR, etc. Such a channel can be devised in any number ofways, like through buttons, or through a led-blink and finger pressprotocol. In any case the simplicity of the messages makes it dif-ficult to attack such a channel. Even more in our situation wherethis channel is between the Persona and the OffPAD configura-tion, which is assumed to be secure and under the control of theUser.

• There are two channels between the Terminal and the OffPADAgent to handle any kind of information transfer. From the pointof view of the information these channels are like cyber-channel,being able to transfer any kind of data. But these channels areimplemented with short-range communication technologies likeNFC, BlueTooth, or Operating System communicationchannels. NFC and BlueTooth would be used when the Agentand Terminal are part of two different devices (i.e., the Terminalis a Laptop), whereas OS-channel would be used when the Agentis an App on the SmartPhone. This last situation is what weconcentrate on in our first prototype.


• There is also a IMG channel for transferring an image equivalentof the visual display (or part of it) of the Terminal to the OffPAD.How this channel is achieved can vary, and we are still investigat-ing which method is best for our purposes. The assumption isthat the image transferred is identical to the one displayed on thevisual display (i.e., send on the visual channel to the Persona).One example, in the case of Terminal being a Laptop, could beto use a camera incorporated in the OffPAD hardware (which istrusted) and to take a picture of the Terminal screen. Another ex-ample, in the case the Terminal is a SmartPhone, can be to take ascreen-shot and guarantee that the OS-transmission path for thisoperation to the OffPAD Agent is secured. This means that allinvolved software components from the Operating System of theSmartPhone (like drivers or screen-capture software) are ensuredto not be susceptible to Attacks which have the power to alter theinformation. Note that attacks that only have the power to snoopthis channel do not break our security assumption.

4.2.2 Secure Run of the Ceremony for Data Authentication

After we know the structure of the possible communications between thecomponents of our ceremony we can detail the secure run that we expect ofthis security ceremony. Any other runs, if possible, are considered insecure.We picture this run in Figure 5 with graphical notation introduced in [26] andwhich we investigate in [27]. This notation should be familiar from StrandSpaces. But otherwise, the notation is rather intuitive and also similar tosequence diagrams. Nevertheless, we explain each step of the run, becausefor our ceremony there are various assumptions and discussions which do notappear in the figure.

In a run we draw horizontal arrows when there is communication betweenthe parts of the ceremony. These parts are the ones defined in the structureFigure 4 and for the run we just display these parts at the top. One canimagine a vertical line (as in sequence diagrams) to pertain to that specificactor in the ceremony. We label the horizontal arrows with the channelname on which the communication is done (shows in the same grey color asthe arrow itself). On top of the arrows we display the information that isbeing sent, or the action that is being taken or that produces the respectiveinformation.

We display internal computations or actions by a vertical arrow and labelit with the respective activity that is being performed (possibly with theoutcome of that activity).


Sharing of information inside the complex configuration is represented bythe same dotted line. In our case the sharing between the Software Agentand the Hardware is doe through an NFC channel

We detail more each step in the above run.

• The ceremony starts with the service provider sending a fresh value(i.e., the down-arrow labelled by nu[x], where x is the value) throughthe Terminal to the OffPAD configuration which shares it with its com-ponents. This is to be used as unique identifier of this particular Trans-action.

• The Persona inputs through the keyboard channel to the Terminal theTransaction information, which we denote by the general term t. Whatexact structure this information has is not relevant here, and can laterbe defined to be many things, like bank account and amount to betransferred.

• The Terminal displays this information back to the User through thevisual display channel. This is natural because usually the user fillsin a form, which is already displayed. But we cannot assume that theTerminal displays the same information, therefore we denote this by t1.

• We then ask the Persona to verify that the information that she in-tended (and typed) is the same as the information that she sees. Thispart is actually done involuntary (or not done at all by a careless Per-sona). But it is good to have this step part of the ceremony, though itdoes not appear in the implementation part that we see later.

• Presumably, the Persona then starts the OCR operation by sendingsuch a command to the OffPAD.

• In turn, the OffPAD Software Agent is the one asking the Terminal forthe image related to the transaction form.

• The acquiring of the Image is an operation that can be done in variousways, and we let it open here. But in any case we can assume that theimage is being transferred from the Terminal (where it was displayedto the User) to the Software Agent. This step 3 needs more carefulanalyses and development.

• The image is shared with the Hardware.

• In the OffPAD Hardware is where the OCR operation takes place (ina trusted environment). This takes as input the acquired image, and


SBPU UOAUOH

Cognitiveanalyset ?= t 2

3

5

6 7

8

Cognitiveanalyse

2t ?= t ?= t1

4

1

Term

nu[x]

OSchan cybshare

xxx x

key

vis

AskIMGStartOCRsharecmd OSchan

share

IMG

s s

2t := OCR(s)

s := ImgAcquire()

t := SendTransInfo()

1t := ShowTransInfo()

visInk

bio

sharem m m

OSchan cybcheck

1

m + t1

2

f := ok+Finger()

2Show(t )

1

0

m := MAC(t , f,x)

m ?= MAC(t , f,x)

UOffPad

Figure 5: ANP run for the Data authentication ceremony.


outputs some transaction information. For our purposes we can onlydenote this t2 differently from before.

• The Transaction information is then Displayed on the InkDisplay tothe Persona.

• The Persona can check to see if these transaction information arematching.

• Then the Persona can issues the signing key by providing the Hardwarewith the Fingerprint. This key can also just be the OffPAD Hardwarekey. The Fingerprint can mean the Authentication of the User by theOffPAD Hardware (function discussed by TazTag documents). TheFingerprint can also trigger a command, like “OK, make the MAC andfinalize the transaction”.

• Using the key f the OffPAD Hardware produces a MAC (MessageAuthentication Code) of the transaction information t2 it extractedfrom the image; call this m. Note that this could have been donewithout interaction with the User, but just immediately after the OCRoperation, and by using the OffPAD key, since the user has alreadybeen authenticated previously to the transaction start. But this is anassumption that we need to be careful about.

• The MAC m is being shared with the Software Agent, which in turnsends it to the Terminal. In the case of the SmartPhone scenario, theAgent communicates through the Operating System message bus. Butwhat exact communication mechanism is abstracted away here, and weonly assume to not be so unsecure as a cyber-channel, but maybe underthe Operating System.

• The Terminal sends both this message and the transaction informationthat it wants (here we assume it sends the same transaction that itwas showing to the User) to the Server of the Bank through the cyber-channel.

• At the Bank’s Server the MAC is being verified against the transactioninformation sent by the Terminal.

4.2.3 API descriptions

By now we can identify several functionalities that need to be provided bythe components of the ceremony in order to achieve the run that we justdescribed. We describe these here in the form of API specifications.


1. DisplayTransInfo() on the OffPAD Hardware component.

This feature is provided by the OffPAD as "Show sensitive informa-tion", see section 2.2.

purpose: to display the Transaction information on the InkDisplay ofthe OffPAD Hardware. This provides trusted visual communica-tion with the User.

input: annotated in a specific purpose XML format, which we willcall TransXML. The annotations are needed so that we can tellthe display how each piece of information to be rendered, like theBanck account larger, or the sum larger. The XML content isconverted into ASCII text to use the OffPAD secure screen.

output: the Status: success or error (what kind of error: parsing, i.e.,wrong input, etc.)

2. OCRTransInfo() ideally on the OffPAD Hardware component.

This feature is not provided by the OffPAD as the current prototypedoes not embed a camera and does not have enough computing power.Thus this feature have to be provided by the host.

purpose: to extract from an image the information related to a trans-action for a specific Service. The image needs to satisfy somevisual queues so to allow the OCR to recognize easier the relevantinformation and the respective annotation it should carry.

input: an image (like png, jpeg, etc.) that is provided by the Terminal;

together with a Service Provider ID. We use the ID to tune theextraction process (i.e., apply different parameters or method)depending on the design imposed by the service provider.

output: text in the TransXML format.

3. MACgen() on the OffPAD Hardware component

This feature is provided by the OffPAD as "Sign", see section 2.2.

purpose: to generate a MAC for a message (for us containing thetransaction information) using the key of the OffPAD hardwarewhich is released by the User through authentication with biomet-rics. Uses a hash function like SHA-256.

input: the transaction information and a key.

output: a hash of the message.


4. SecureShare() on the OffPAD Hardware and on the OffPAD SoftwareAgent

purpose: to allow for transmission of any kind of data between thetwo OffPAD components, in both ways. Sharing is currently im-plemented through micro-USB standard. But one can use hereother communication means s.a. NFC or BlueTooth; though onlyNFC is short-range and secure enough to be considered as an of-fline communication mechanism.

input: any kind of data.

output: same as input.

4.2.4 A Concrete Application

Consider that the Terminal is a SmartPhone with the Android operatingsystem. For the terminal we consider the Browser through which the Userinteracts by filling in the form sent by the Bank for performing a Transaction.

Then consider the OffPAD Agent to be an “Android bound Service”.Therefore the Agent runs as an Android app, with different privileges thannormal apps. This needs more discussion because it is important to under-stand the security aspects and what kind of resources are available to theAgent, and in what degree can this access to resources be trusted. For exam-ple, can the Agent have access to the camera of the SmartPhone (Terminal);or can the Agent take a screen-shot?

The OffPAD Hardware is attached to the SmartPhone as a back-cover.This means that the Share() function can be implemented using the mi-croUSB protocol, through which the cover is connected to the phone. NFCcommunication could also be possible between the back-cover and the Smart-Phone. Note that in the above scenario alone we already share various kindsof information: nounce, image, XML text output by OCR, or a generatedMAC; and the sharing is both ways.

There are two aspects of this diagram that need more detailing: these aremarked with the red labels A and B. This is where the development mostlytakes place.

(A) is where we acquire an image of what the Browser displays to the User.

(B) is the OCR technology implementation, also considering various designsas preferred by the Bank (i.e., is parametrized by the Bank’s identifier).

There are two alternatives for doing the OCR, and these are marked inthe red squares (only one of these should be part of a final diagram).


OffPADHardware

OffPAD Software(Android service)

Software client(Browser)User Bank’s Server

A

Share(s)

Share(t2)

B

Android SmartPhoneSecure Cover

StartTransaction(UserID)

DisplayForm(f)

t = SendTransInfo()t1 = Fake(t)

DisplayTransInfo(t2)

b = Authenticate()h = BioHash(b)

s = ImgAcquire()

OSTransmit(Nonce)Share(Nonce)

m = MACgen(t2, h , Nonce)

Share(m)OSTransmit(m)

Send(m , t1)

Accept/Reject

m ?= MACgen(t1, h , Nonce)

t2 = OCRTransInfo(s, BankID)

t2 = OCRTransInfo(s, BankID)

f = Form(UserID,BankID); Nonce

Figure 6: Sequence diagram for the Data authentication ceremony.


The upper square does the OCR extraction in the trusted environment ofthe OffPAD Hardware, using the image acquired in the OffPAD Agent. If weassume the image acquisition is trusted (or evaluate the threat level to a lowone), then this method is as secure as this threat. But OCR usually requiresintensive computation resources, which most probably are not available inthe secure jacket of the OffPAD.

Therefore we investigate the lower square alternative. Here the OCR isdone on the Agent, which as a smartphone has the required computationpower, and then a term t2 is transmitted securely through the microUSBconnection. One can imagine an attack where the Agent is infected, andthus the output from the OCR is not the same as the one transmitted tothe Hardware. But we assume that infecting the Agent is less probable thaninfecting a common app (how probable remains to be determined). Neverthe-less, even in the setting of this attack, the fact that the t2 is being displayedon the secure Hardware allows the user to verify that the t2 corresponds tothe image displayed by the Agent, by simply flipping the phone from one sideto the other so to look at both screens and compare their displays. But howeasy it is for the Human user to identify if there are differences is not clear.In previous research of ours [2] we analysed and seen that this cognitive taskis often performed wrong, and attacks can be quite often missed.

To avoid reply attacks the Bank’s Server uses “Nonces” (timestamps)which it expects to receive back, part of the MAC.

The form sent to the Browser is parametrized by a Bank ID, which isused for tweaking the performance of the OCR algorithm (i.e., is associatedwith the visual pattern in the OCR algorithm).

This form is displayed to the user by the Browser. An infected Browsercan of course display a manipulated form (this is the purpose of f1 in thediagram), even with the graphics pertaining to the BankID unchanged.

The User provides information into the form, which we denote by t. Thisis the transaction information intended by the User. This information canbe different than the other (similar in format) information that is beingtransmitted around, i.e., the other t1, t2 terms. To emphasis this aspect thediagram has a dotted arrow that shows that t1 is a fake transaction info.But this should not be present on the diagram, and we only assume that theBrowser can send any term, not necessarily the one received from the User.

Since the form can be faked then the User can be tricked into providing tothe Browser more info than required by the Bank. The attacker would sendonly what was required by the Bank. This would be an instance of a socialengineering attack. Such an attack could be captured through the above useof OCR technology because the MAC sent to the Bank would contain theextra information.

5 USER AUTHENTICATION BASED ON HTTP XDAA 27

On the OffPAD hardware we perform to main operations. We apply a bio-hashing algorithm so to obtain a one-time biometric from the biometric inputb of the User. This hash is used in the MAC generating algorithm, which isapplied to the transaction information displayed on the secure InkDisplay ast2.

The Bank can verify this MAC against the term sent by the Browser.

5 User Authentication based on HTTP XDAA

5.1 User Authentication using Biometrics through Off-PAD


Users of online services typically accumulate so many online identities andrelated passwords that it quickly becomes a usability challenge to managethem securely. In addition, since it is reasonable to assume that typical clientplatforms are infected by malware, storing and using credentials such as pass-words on these platforms is a security risk. Passwords can be intercepted byTrojans either through keystroke logging, RAM-scraping, or by screenshotswhen shown on the screen in clear text. Even automatic log-in and iden-tity management applications such as LastPass2 are not safe, as they releasethe clear text password to the web browser (or other application) duringauthentication, leaving it visible in memory for the Trojan to steal.

The OffPAD may be used to manage and authenticate a user to a systemin a secure way. This would improve usability by providing a tool for iden-tity management, and would also improve security in several respects. In atraditional scenario where the user types his password, or the password isdecrypted by a password manager (e.g. LastPass), the password is exposedin the computer’s memory and is vulnerable to attacks such as key loggingor memory inspection. A solution for password authentication using an Off-PAD is proposed by Klevjer et al. in [22], consisting of an extension to theoriginal HTTP Digest Access Authentication scheme specified as a part ofthe HTTP standard in [11]. User credentials are stored in a hashed formaton both the server and the OffPAD. When the user via the client requestsa protected resource, the server responds with an authentication challenge,which on the client side is hashed with the user credentials and returned tothe server. The server does the same challenge-response calculations locally,and compares the result and the response. If the two values match and the

2HTTP://lastpass.com


user corresponds to an authorized entity, the user is granted access to theresource. This can be done securely through an insecure channel, such asover HTTP, not requiring an extra connection to the server, just a browserplug-in or extension.

In this section, we describe a method for local user-side identity manage-ment based on the OffPAD, combined with an extension of the well-knownHTTP Digest Access Authentication protocol. A brief overview of the exist-ing HTTP Digest Access Authentication standard is provided next. We thendescribe our method of combining the OffPAD with extended HTTP DigestAccess Authentication. The advantage of our method is that it totally pre-vents exposure of passwords on potentially vulnerable client platforms, andthereby represents secure local user-centric identity management solution. Aproof-of-concept implementation of the method has been developed for theOffPAD prototype [21].

HTTP Digest Access Authentication (short: DAA) originates from thechallenge-response authentication framework described in the original HTTP1.0 specification [5]. It is a web standard for access control to a serviceor domain called realm by user authentication over HTTP. DAA was firstdefined in 1997 in RFC 2069 [12] and refurbished in RFC 2617 [11] in 1999.Its intended use is on the World Wide Web, but it is perfectly implementablefor protection of local resources, or in any situation where application levelaccess control is required3.

5.1.2 High-level description for User Authentication through Off-PAD

Internet

7

Server Infected

Client

User

2

User OffPAD

5

8

1 6

3

4

Figure 7: Ceremony for user authentication with the OffPAD

The actions/messages of the ceremony of Fig.7 are described in Table 4.Extended Digest Access Authentication (short: XDAA) represents an

extension of traditional HTTP DAA in two respects. The actual IETF stan-dard RFC 2617 is extended to allow more than just username and password

3The challenge-response theory behind the scheme is applicable also outside HTTP.


Nr. Message / action description1. Server sends HTTP digest access authentication challenge to

client2. Challenge from server is forwarded to OffPAD3: OffPAD presents user authentication request to user4. User approves authentication request5. OffPAD computes response to challenge from server6. Response is sent from OffPAD to client7. Client forwards response to server8. Server verifies response which completes user authentication

Table 4: Sequence of messages and actions for user authentication ceremony

as valid credential sets. The authentication process itself is also extended,physically, in that it is moved to another location. All client-side calculationsdone in the authentication phase are outsourced to the OffPAD.

Our XDAA is beneficial both for security and usability. By managingthe user credentials on an external device, we get a local user-centric iden-tity management system, so users are no longer required to remember theirpasswords. Moving the challenge-response calculations and handling of thevalues critical to authentication over to a mostly offline device, we reduce therisk of exposing these values. Moving the identity management over to such adevice alleviates the cognitive and physical strain on the user during authen-tication, as well as removing the time penalty brought by user interaction inmost situations4.

In its simplest form (using the OffPAD and no further protection mecha-nisms), XDAA can be used with any HTTP server supporting original HTTPDAA without change to the server system. The immediate benefit is thatthe user’s credentials themselves are never present. They are never shown onthe screen, never exposed in any vulnerable state in the computer’s memoryand never transferred in clear text.

5.2 Detailed Description of the Ceremony for User Au-thentication using OffPAD

We will present first the structure of the ceremony and discuss its com-ponents. We then continue to describe the secure run that we see of this

4Situations where no identity or multiple identities are available for the user to authen-ticate with, the password is wrong, or another error appears, user interaction is necessary.


U

BSB

PU

UOAUOH

cyb

cyb

Termcmd

UOffPad

visInk

bio

OSchanblue

Figure 8: ANP structure for the ceremony for User authentication usingthe credentials stored on the OffPAD.

ceremony. Any other possible runs should be considered insecure. In the endwe discuss the API associated to this ceremony and present some sequencediagrams. These would be similar, but more concrete, to the description ofthe secure run.

5.2.1 Structure of the Security Ceremony for User Authentication

The structure of the ceremony for User authentication using the credentialsstored on the OffPAD, is pictured in Figure 8.

The structure is similar to the one described before in Section 4.2.1 witha few channels missing. In particular, we do not need to look at the Imageacquisition channel from the Terminal to the OffPAD, and there is no inter-action between the User’s persona and the Terminal, thus hinting at the factthat the user credentials flow only through the secure OffPAD.

Otherwise, in short, we have the same Identities of the actors User (U)and Bank (B); the same Configurations; and the same Channels (except theones mentioned above).

5.2.2 Secure Run of the Ceremony for User Authentication

Using the same notation conventions as before, we detail the secure runthat we expect of this security ceremony. Any other runs, if possible, areconsidered insecure. We picture this run in Figure 9. We explain those stepsof the run which are not entirely clear from the figure.

• The Terminal starts the ceremony by requesting a restricted resourcefrom the service provider on behalf of the User.


SBPU UOAUOH0

1

3

5

6 7

8checkm ?= MAC(h,x)

4

2

Term

nu[x]

sharecyb

Req(UserID)

http_DAA(x);BankID

c := Credentials(BankID)

visInkBankID

Approve

sharem m m

OSchan cyb

m := MAC(c,x)

m

h := HashedCreden(UserID)

cmd/bio

x;BankIDOSchanx;BankID

UOffPad

Figure 9: ANP run for the User authentication using credentials stored onOffPAD.


• The Bank server generates a unique timestamp and sends this as aHTTP digest response, which asks for authentication from the user.

The use of the timestampt is intended to counter reply attacks.

• The timestamp as well as the identity of the service requesting authen-tication are forwarded to the OffPAD hardware.

• The Bank’s ID is shown to the User and approval is waited for. Here wecouple with the petname system so to show the identity of the Serviceprovider in a more intuitive and user-friendly way. Even DNSSEC-likecertificates could be used previously in the run.

• The approval can be either through the command channel (like pressand OK button) or through biometrics (providing the fingerprint; thusshowing that the actual User is handling the OffPAD). Either of thesewould trigger the OffPAD functionality of retrieving User credentialsparticular to the requesting provider.

• A MAC is generated from the timestamp, using the credentials.

• This message is shared with the OffPAD Agent, which in turn forwardsit through the Operating System channel to the Terminal to furtherforward to the Service Provider.

• At the Service Provider, the hashed credentials for the current User areretrieved and used to also generate a MAC which is checked againstthe message received from the Terminal.


There are two main functionalities that we need on the OffPAD hardware.

1. MACgen() on the OffPAD Hardware component.


purpose: generates the MAC of the timestamp using the hashed cre-dentials as key. This is the same function that we used in Sec-tion 4.2.3.

input: a message (i.e., timestamp here) and a key (i.e., the creden-tials).

output: a hash of the message.


OffPADHardware




OSTransmit(d)Share(d)

Request(UserID)

b = Authenticate()

Share(m)OSTransmit(m)

Display(BankID)

Send(m)

Accept/Reject

c = Credentials(BankID)

m = MACgen(c, Nonce)

h := HashedCreden(UserID)

m ?= MACgen(h, Nonce)

d = HTTP_DAA(Nonce,BankID)

Figure 10: Sequence diagram for the User authentication ceremony.

2. Credentials() ideally on the OffPAD Hardware component

This feature is not provided yet by the OffPAD.

purpose: returns the credentials stored in the OffPAD wrt. an Iden-tity of the Service Provider.

input: ID of service provider.

output: hashed value of credentials for this ID. These are dependenton the initial algorithm/protocol for storing these credentials, andare not limited to just Username/password.


Let us now consider a concrete implementation of the above ceremony. Seethe sequence diagram of Figure 10. This has the same setup as in the otherceremonies, and follows rather closely the secure run we described in theprevious section.

6 SERVER AUTHENTICATION BY THE USER BASED ON PETNAME34

6 Server Authentication by the User based on

Petname

6.1 Server Authentication by the User


Secure access to online services is typically implemented with mutual au-thentication, i.e. with user authentication on the application layer and serverauthentication on the transport layer. Since mutual authentication goes be-tween the user and the server, we require server authentication by the useras [S → U] which most often is not satisfied in current implementations, anduser authentication by the server as [U → S] which currently is satisfied inmost implementations.

Despite strong cryptographic server authentication, the typical implemen-tation of TLS in browsers only enforces syntactic server authentication, sothat any server identity is accepted as long as the certificate is correctly val-idated. This is a serious vulnerability which is also the reason why phishingattacks often succeed even when TLS is being used for server authentica-tion [18].

Because phishing works fine without server certificates, most phishingsites do not have server certificates. Phishing victims often do not know thedifference between a HTTP connection (without certificate) and a HTTPSconnection (with certificate and TLS), so server certificates are probably seenby attackers as an unnecessary expense. However, there are phishing siteswith certificates, and paradoxically, phishing site certificates are automati-cally validated by browsers.

Current browser implementations of TLS with certificates do not supportsemantic or cognitive server authentication, so using TLS with certificatedoes not offer any meaningful authentication. In order to provide cognitiveserver authentication, a petname system [9,10,30] must be used, as describedbelow.

Reliable authentication of online entities require globally unique namesthat are understood by people. Domain names were designed to representonline identities of organisations, but domain names alone can be difficult tointerpret.

Company names, trademarks and logos are typically used for recognisingorganisations in the real world, but would not be suitable for global onlineidentification and authentication. This mismatch between names used inthe online world and in the real world creates confusion about which uniquedomain name to expect when accessing online services. Without knowing


which name to expect, authentication becomes meaningless.Three fundamental desirable properties of names described by Bryce

"Zooko" Wilcox-O’Hearn [32] are to be global5, unique6 and memorable7.To be memorable a name has to pass the so-called "moving bus test" [24]which consists of testing whether a averagely alert person is able to cor-rectly remember the name written on a moving bus for a definite amountof time, e.g. 10 minutes after the bus has passed. A name is unique if it iscollision-free within the domain [30].

The triangle of Fig.11 where each of the three desirable properties ofnames are placed in one of the corners is commonly known as Zooko’s triangle,and represents the basic foundation for the Petname Model [9, 32].

Global

Unique Memorable Petnames

No names

land

Figure 11: Zooko’s triangle

Wilcox-O’Hearn claimed with supporting evidence that no name spacecan be designed where names generally have all three desirable propertiessimultaneously. A visual analogy of this idea is created by placing the threeproperties at the three corners of a triangle. In a triangle, the three cornersare never connected by a single line, only pairs of corners are connected. Theedges joining the corners then illustrate the possible properties that a namespace can have. Wilcox-O’Hearn suggested to design name spaces of globaland unique names (pointers), and name spaces of memorable and uniquenames (petnames).

The Petname Model consists of mapping a common name space of point-ers to individual name spaces of petnames, which thereby combines all threedesirable properties. A petname system is a system that implements thePetname Model. The OffPAD is ideal for hosting a petname system, so asimple petname system was implemented on the OffPAD.

5Called decentralized in [32]6Called secure in [32]7Called human-meaningful in [32].


Nr. Message / action description1. User initiates secure TLS connection through client platform2. Client platform contacts server3: Server returns server certificate containing public key4. Server certificate is forwarded to OffPAD5. Server certificate is validated (syntactic server authentication)6. Server certificate is mapped to petname7. Petname is presented to user8. User performs cognitive server authentication9. User approves server authentication

10. TLS connection established between client and server

Table 5: Sequence of messages and actions for server authentication ceremony

6.1.2 High-level description for Server Authentication

The petname system on the OffPAD receives server certificates during theTLS handshake. In order to support cognitive server authentication, theserver domain name (pointer) – received in a certificate – is mapped to a user-defined petname representing the service provider, as illustrated in Fig.12.The server certificate is also validated in the traditional way, which providessyntactic server authentication. Strengthened authentication assurance canbe obtained by having server certificates signed under DNSSEC, which wouldgive a very high Server Authentication Assurance Level according to theserver authentication framework proposed by Jøsang et al. [18].

Internet

6

2

Server

Infected

Client

4

User

3

Petname

7

OffPAD

1

5

9

8

10

Figure 12: Ceremony for server authentication with the OffPAD

The actions/messages of the ceremony of Fig.12 are described in Table 5.The petname system combined with e.g. TLS enables manual trust eval-

uation by the user [8,9]. More specifically, a petname system in combinationwith TLS provides cognitive server authentication, which is precisely thesecurity service needed to prevent phishing attacks.


If the user navigates to a web site where the petname system finds nomatch between its pointer (domain name) and a petname, the petname sys-tem should alert the user, or ask the user to add a new petname for the newservice. Petname systems support cognitive authentication and protect usersfrom falling victim to phishing attacks [9].

In a petname system, users create personal petnames to represent globallyunique pointers for services that they use. When a specific service is accessed,the user recognises it by its petname, not by its pointer. A petname systemmakes it easy to manage the list of mappings between petnames and pointers,and automatically translates between pointers and petnames.

In the current implementation, Petname and XDAA were merged : thepetname is verified and shown to the user only when a XDAA authentica-tion is requested. As a single webpage might open several TLS connections,showing all petnames to the user would lead to flood her. Thus by showingthe petname only when needed, we improve the overall ergonomic.

6.2 Detailed Description of the Server AuthenticationCeremony by the User

We will present first the structure of the ceremony and discuss its com-ponents. We then continue to describe the secure run that we see of thisceremony. Any other possible runs should be considered insecure. In the endwe discuss the API associated to this ceremony and present some sequencediagrams. These would be similar, but more concrete, to the description ofthe secure run.

6.2.1 Structure of the Security Ceremony for Server Authentica-tion

The structure of the ceremony of Server authentication using the cognitiveevaluation abilities of the User, is pictured in Figure 13.

The structure is similar to the one described before in Section 4.2.1 witha few channels missing. In particular, we do not need to look at the Im-age acquisition channel from the Terminal to the OffPAD, and we are notrequiring any biometric input from the User’s persona.

Otherwise, in short, we have the same Identities of the actors User (U)and Bank (B); the same Configurations; and the same Channels (except thetwo mentioned above).


U

BSB

PU

UOAUOH

cyb

cyb

key

vis

Termcmd

UOffPad

visInk

OSchan

Figure 13: ANP structure for the ceremony of Server authentication by theUser.

6.2.2 Secure Run of the Ceremony for Server Authentication

Using the same notation conventions as before, we detail the secure runthat we expect of this security ceremony. Any other runs, if possible, areconsidered insecure. We picture this run in Figure 14. We explain thosesteps of the run which are not entirely clear from the figure.

• The User starts the ceremony by interacting with the Terminal (i.e., aweb browser) and starting a secure connection with the service provider.We assume this ceremony wants to use a protocol involving securityCertificates (e.g., Kerberos/TLS). The input that the Persona can pro-vide is the URL of the desired service.

• The Terminal (which may be infected) starts the TLS connection withthe Bank. A typical attack is to change the provided URL into amalicious one. This ceremony wants to avoid this.

• The Bank (or whoever the url poited to) responds by sending back itsCertificate.

We want to use DNSSEC style of certificates, which include a chain oftrust based on root signing keys being trusted for the few root DNS au-thorities, thus authenticating and protecting the integrity of responsesto DNS queries. The use of DNSSEC certificates wants to ensure thatthe URL points to the correct IP address. In this way we avoid infamousDNS cache-poisoning [3,28], out-of-path [20], and other attacks [13] (seea nice presentation of these and their formalizations in [4]).


SBPU UOAUOH

34

Validate(c)5

7

8

6

1 2

9

Term

keyTLS_req

cyb

cyb

c := DNSSEC(cert)

sharec

OSchanc c

p := Pet(c)

visInkShow(p)

cyb

analyse(p)Cognitive

TLS_finish

10

keyTLS_OK

StartTLS(url)

UOffPad

Figure 14: ANP run for the Server authentication by the User.


The use of DNSSEC allows us to work with the URL to point to theService provider, which is more user friendly than the IP. But still,URLs can be misleading, and an attacker can carefully fake a URLwithout the user noticing, thus resulting in phishing attacks.

• The certificate returned by the Service is forwarded to the OffPADtrusted hardware.

• This certificate can very well be authentic and with a correctly acquiredIP address, hence could pass standard syntactic validation. Yet thecertificate is for the wrong URL. We want the User to be able to verifyconsciously the validity of the certificate.

• On the OffPAD hardware each certificate can be mapped to a petname.Only those known to the User have an existing petname associated.For any new certificates the User will be prompted to make a newassociation. This would allow the User (in step 8) to be consciousabout the URL that the browser points to. For otherwise, if the usertyped in a URL that she visited previously, but OffPAD prompts for anew petname association, the she know an attack is under way.

• For correct petnames (like a simple word or picture/logo) the User pro-ceeds with establishing the trusted connection, through the untrustedTerminal.


There are two main functionalities that we need on the OffPAD hardware.

1. Validate() ideally on the OffPAD Hardware component.


purpose: to validate syntactically a DNSSEC certificate. This in-volves the same implementations as are currently being imple-mented in DNS resolvers that support DNSSEC. This implies adatabase of trusted root certificates (similar to what web browsershave for handling HTTPS) and the ability to verify signatures.

input: a DNSSEC certificate with its associated chain of trust (em-bedded in the DNS response).

output: the Status: success or error.


OffPADHardware



Type(URL)

URL2 = Fake(URL)

HTTPSrequest(URL2)

DisplayPetName(p)


Share(c)OSTransmit(c)

Validate(c)

TLS_OK()EstablishTLS()

c = DNSSEC(URL2)

p = PetName(c)

Figure 15: Sequence diagram for the Server authentication ceremony.

2. PetName() ideally on the OffPAD Hardware component.


purpose: to associate a petname to a url (DNSSEC certificate). Thisimplies the existence of a database of petnames associations.

input: a DNSSEC certificate (or just the URL from this certificatewhen the syntactic validation went through).

output: a petname. This can be either a text/keyword (like “MyFavoriteBank-3”) or a logo/image. Since the petname would be displayed on thelimited (but trusted) InkDisplay of the OffPAD hardware, proba-bly images/logos are harder to handle nicely.


Let us now consider a concrete implementation of the above ceremony. Seethe sequence diagram of Figure 15.

As before, consider that the Terminal is a SmartPhone with the Androidoperating system. For the terminal we consider the Browser through whichthe User interacts by filling in the URL field. Consider also the OffPAD Agentto be an “Android bound Service”. This communicates with the OffPAD

7 CONTEXTUAL AUTOMATIC LOGIN BASED ON INDOOR LOCATION42

Hardware, attached to the SmartPhone as a back-cover, using the microUSBprotocol, through which the cover is connected to the phone.

Since the URL can be faked by an infected Browser (i.e., this alternativeis symbolized through the red square in the diagram) then the User can betricked into interacting with a face service. We avoid this by using the Off-PAD hardware to display to the User, in a very intuitive way, using petnames(which are assumed to be easy to understand and associate in ones mind withthe intended service).

Besides the Validation of DNSSEC certificates and the PetName gener-ation, which are to be done on the OffPAD hardware, the Browser has tocooperate as well, in the sense that it needs to forward the Certificate to theOffPAD agent and wait for a confirmation from the user (e.g., through anOK button) before establishing the TLS channel and displaying the UI ofthe requested Service.

7 Contextual automatic login based on indoor

location

7.1 Background

7.1.1 Motivation

Hospitals are considered as a hectic working environment. However, patientinformation security and privacy must still be ensured throughout the dailywork. This implies that the hospital staff must log on to terminals and beauthorised every time they interact with IT systems. This is time consumingand distracts attention from primary tasks. There may also be hygienic issuesrelated to logon procedures since staff will have to interact with keyboardsused by many users.

The objective is to implement a set of use cases that makes use of OffPADtechnology to automatically log on and log off users to computer systems asthe user approaches a terminal, simplifying the authentication procedure forthe hospital staff.

7.1.2 Standard automatic login-logoff

The existing solutions are cumbersome to use due to strict security require-ments. Users stay logged in for a very limited period and they might need toprovide the authentication information (e.g., username and password) sev-eral times when interacting with hospital IT systems. The expiry of a session


is short because many users use the same terminal and sensitive informationmust not be exposed to unauthorized personnel.

7.2 eHospital

The OffPAD project proposes to focus on a context-aware authenticationmechanism which will relieve the user from the burden of a frequent login/l-ogoff process. We implement a location-based authentication mechanismwhere the user is automatically logged in to a terminal when she approachesthe terminal, and logged off from it when she leaves the terminal. Thanksto the high spatial and timing precision provided by the Sonitor’s Sense sys-tem, OffPAD’s security framework can make use of Sonitor Sense to realizea location-based automatic authentication process.

7.2.1 eHospital infrastructure

SmartTracker

Sonitor location

engine

Hospital serverTerminal

LF exciter

User

Sonitor

TAG

O�PAD

User-side

Terminal

Sonitor-side

Hospital Network

(1)

(2)

(3)(4)

(5)

(6)

(7)

(a)

(b)

SmartTracker

Figure 16: eHospital infrastructure

As shown in Figure 16, the eHospital infrastructure is subdivised into 4subparts :

• Sonitor sensor for detection of user location ;


• User with her OffPAD and sonitor tag ;

• Hospital network, the client network ;

• SmartTracker, the center of the infrastructure, linking the three sub-parts together.

7.2.2 Sonitor sense

Sonitor Sense is the most robust and accurate solution for indoor positioningon the market. Sonitor Sense allows for room level and true-bay-level posi-tioning using ultrasound. The tag has a latency of a few milliseconds and abattery life of one year or more. Sonitor Sense is based on attaching tags topatients, hospital staff and objects. Hospital staff and multiuser terminalsare trackable objects in the context of the Sonitor Sense system. Whenevera hospital staff member (e.g., a nurse or a physician) wearing a Sonitor tagapproaches a terminal (which is equipped with a Sonitor tag/device), thehospital system will automatically log the user in on that particular termi-nal. Similarly, when the user walks away from the terminal, Sonitor Sensecan detect this and notify the hospital system to automatically log the useroff from that terminal.

Figure 17: High level description of automatic Login-Logoff use case scenario

In our infrastructure, a LF Exciter detects the user position by detect-ing her sonitor tag (3), then notify the Sonitor server (4) which notify theSmartTracker server (5).

7.2.3 User

In our infrastructure, the user wears an OffPAD and a sonitor tag.Every tag has a unique tagID, which is assigned when configuring the

tag for the first time. Allocating a specific tag to a specific user poses twosecurity challenges that need to be addressed :

1. the tag must only be used by the user assigned for that tag.


2. the process for assigning a user to a tag must be secure.

The first challenge is addressed by attaching the tag (Sonitor’s P-tag)to a wristband. Hospital staff must wear the wristband with a P-tag whenthey start a working day, and the P-tag will be deactivated once the tag isdetached from the wristband. In this way, the tag cannot be used by anotheruser. To address 2., we use the OffPAD device for assigning a tag to the user(1). The OffPAD device will be used to authenticate and authorize a user toassign a tag to a userID (a) and transmit this information to SmartTracker(2). The user authenticates to her userID using biometric authentication onthe OffPAD. We ensure that a tagID is assigned to the user’s userID. TheP-tag should be equipped with a communication capability that makes itpossible for the OffPAD device to read the P-tagID and assign it to the user.We are considering two communication capabilities; NFC and Bluetooth lowenergy. These communication technologies are used for proximity and short-range communication.

In future versions, the Tag could be included in the OffPAD.

7.2.4 Hospital Network

The hospital network is composed of a set of terminals associated with a LFexciter to detect the user’s entrance and departure. Users accesses to theterminals are managed by the hospital server (7) notified of each locationchanges by the SmartTracker server (6).

7.2.5 SmartTracker

The SmartTracker server provides REST API to the hospital network, thusable to track user state changes. SmartTracker communication with theOffPAD through Google Cloud Messaging (GCM).

7.3 eHospital Automatic Terminal Logon Access Sys-

tem (ATLAS)

7.3.1 Pairing

The nurse has a userID on the SmartTracker server. The OffPAD devicestores the user credentials for her userID. At the start of a working day, thenurse puts on a wristband with a P-tag, puts her OffPAD device close to theP-tag (1) and swipe the finger on the biometric sensor. The OffPAD devicereads the P-tagID and authenticates the user from the biometric information(a). The OffPAd device sends the user credentials and the P-tagID to the


SmartTracker server (2). The SmartTracker server authenticates the userand assigns the P-tagID to the UserID.

7.3.2 Soft authentication

When the Sonitor LF exciter, attached to the terminal, detects a P-tag (3),it contacts the SmartTracker system (4,5) to check if the P-tag is assigned toa userID. If so, the user is automatically logged in to the terminal. When thenurse leaves the terminal, the nurse is automatically logged off that terminal.

7.3.3 Hard authentication

When the user (e.g., a nurse) approaches a terminal, there might be needsto introduce strong authentication if the user needs to access more sensitivedata.

An additional authentication request is triggered and issued by Smart-Tracker. The SmartTracker server requests the user to re-authenticate (b).The user will authenticate to the OffPAD device using the fingerprint sensor(a). The device will authenticate the user and send the user credentials tothe SmartTracker server (b). SmartTracker will check if the authenticateduser has access to the more sensitive data. If yes, SmartTracker will giveaccess to the sensitive data (6,7) in the user session running on the terminal.Once the user exits the sensitive data, the user session on the terminal willreturn to the normal security mode .

7.3.4 Multi-login

To access patient informations, his approval might be required resulting ofasking him to authenticate after the nurse has been authenticated. We pro-pose multi-login to offer nurses access to informations depending on soft-authenticated patients on the terminal.

As the LF exciter operates in a restraint area, we assume that the patient,by his present, consent to the access of theses informations, and is able tomonitor the accessed informations. For more confidential informations or forediting theses information, strong authentication is asked to the patient.

As for soft and strong authentication, the patient is disconnected as soonas he leave the terminal. Subsequently, nurses do not have access anymoreto his informations.


7.3.5 Disconnection

At the end of a working day, the nurse disconnect her from her OffPADdevice, puts off her wristband with a P-tag. The OffPAD device sends adisconnection query to the SmartTracker server. The SmartTracker serverthen unassigns the P-tagID to the UserID.

7.4 API descriptions

We need one main functionality on the OffPAD hardware.

1. MACgen() on the OffPAD Hardware component


purpose: to generate a MAC for a message (for us to answers Smart-Tracker challenges) using the key of the OffPAD hardware whichis released by the User through authentication with biometrics.Uses a hash function like SHA-256.

input: the challenge and a key.

output: the challenge’s answer.

7.4.1 OffPAD - SmartTracker API

The OffPAD and the SmartTracker server communicate through GoogleCloud Messaging (GCM) providing a secure connection and optimizing thephone’s battery usage.

As shown in Figure 18 The OffPAD can send the following messages :

• VERIFY_REGISTRATION to query for the current status of the OffPADon the SmartTracker system.

• registering to register, on SmartTracker, the OffPAD’s public keyand the GCM identifier to use for the OffPAD-SmartTracker.

• offpad_pairing to pair the OffPAD with a Sonitor Tag user the TagID.

• offpad_diconnect to unpair the OffPAD with the previously pairedSonitor Tag.

• offpad_auth to respond to a strong authentication query (offpad_authentication.perfor

The OffPAD can receive the following messages :

• registration.status, the answer to a VERIFY_REGISTRATION request.The OffPAD can be registered ("registerred"), waiting to be reg-istered ("status is init") or having a key or GCM errors ("GCMmismatch", "Signature validation failed. Invalid key-pair").


Figure 18: eHospital OffPAD - SmartTracker API

• offpad_pairing.(success|failed), the answer to a offpad_pairingrequest.

• registration.(success|failed), the answer to a registering re-quest.

• offpad_authentication.perform, asks the OffPAD for strong au-thentication.

• offpad_disconnect.(success|failed), the answer to a offpad_disconnectrequest.

• offpad_authentication.(success|failed), the answer to a offpad_authrequest. offpad_authentication.success is also used to inform thatthe user is now authenticated to an area (soft and strong authentica-tion).

• offpad_authentication.left, sent to inform that the user left anarea and is disconnected from that area.

Each signature with the OffPAD’s private key should be confirmed by the

8 ALTERNATIVE APPLICATIONS AND IMPLEMENTATIONS 49

user to prevent an attacker to make the OffPAD sign arbitrary data withoutthe user knowledge. Though, the OffPAD may require 3 signatures whenpairing the device. Indeed the OffPAD checks its status, register itself if not,pair itself and might be asked for strong authentication is the user is in aspecific location.

Asking for 4 user confirmations is not ergonomic to the user. Only thestrong authentication requires explicit user authentication and needs to signa random challenge sent by SmartTracker. The pairing only needs to signthe tag ID and the status verification to sign an arbitrary chain, thus thesessignatures can be computed once and be stored. Thus we ask for one userconfirmation when pairing to unlock access to stored data such as the precal-culed signatures and the public key, and then ask for user authentication foran eventual strong authentication which require explicit user confirmation.

8 Alternative Applications and Implementations

There are various other applications that could be imagined using OffPAD.We mention here only a few.

The method for signing bank transaction can be used to sign medicalprescriptions.

The method for patient record can be used in other situations, like whena nurse is allowed to make changes to a resource only under the supervisionof a doctor (maybe a specialist).

Auto-login can be used for easy moving of patients between rooms, wherethe entertaining system, like preferred TV channels, are immediately trans-ferred to the new terminal based on the location.

Petnames can be associated to all sorts of domain names, and user cando cognitive authentication of these web-sites as well. Like for any sensitiveservices, like tax office, preferred shops, etc.

Alternative implementations could also be possible. In the case of signingbank transactions, we have worked with OCR so to prove a concept. However,one can think of alternatives like involving QR codes. Instead of takinga picture and extracting the info from the picture, we can ask the phoneapplication to display also a QR code containing the essential informationwhich are displayed to the user. Of course, this QR code can be attackedthe same as the displayed picture can. But the same countermeasure comesto help where the use verifies on the secure screen the information beforesigning it.

9 SECURITY SERVICES 50

9 Security services

10 Discussion and Conclusion

With this technical paper, we also set up a demonstration and make a posterwhere the OffPAD demo is described. The demo uses two laptops which needto sit at least 2 meters apart, along with indoor location equipment fromthe project partners TellU and Sonitor. Besides, the also uses a smart phoneapplication, together with the OffPAD hardware phone-jacket attached to thephone.8 The demo also uses the SmartTracker technology from the projectpartner TellU, which runs in the home servers of TellU, therefore, Internetconnection is needed.

References

[1] M. Alzomai, B. Alfayyadh, and A. Jøsang. Display security for on-line transactions. In The 5th International Conference for InternetTechnology and Secured Transactions (ICITST-2010), London, Novem-ber 2010.

[2] M. AlZomai, B. AlFayyadh, A. Jøsang, and A. McCullag. An Exper-imental Investigation of the Usability of Transaction Authorization inOnline Bank Security Systems. In The Proceedings of the AustralasianInformatin Security Conference (AISC2008), Wollongong, Australia,January 2008.

[3] D. Atkins and R. Austein. Threat analysis of the domain name system(dns). RFC 3833 (Informational), 2004.

[4] J. Bau and J. C. Mitchell. A Security Evaluation of DNSSEC withNSEC3. In Network and Distributed Systems Security (NDSS), 2010.

[5] T. Berners-Lee, R. Fielding, and H. Frystyk.RFC 1945 – Hypertext Transfer Protocol – HTTP/1.0. IETF, May1996.

[6] S. Bodmer. SpyEye being kicked to the curb by its customers? ResearchNote, Damballa Inc. http://www.damballa.com, 2012.

8The secure jacket is a hardware prototype version 1, which does not have the properdimensions. Unfortunately, the version 2 of the jacket will appear only towards the end ofthe year.

REFERENCES 51

[7] I. (CCITT). Recommendation X.800, Security Architecture for Open Systems InterconnectionInternational Telecommunications Union (formerly known as the In-ternational Telegraph and Telephone Consultantive Committee), 1991.(X.800 is a re-edition of IS7498-2).

[8] T. Close. Trust management for humans. Waterken YURL, Waterken-Inc. http://www.waterken.com/dev/YURL/Name/, 12 July 2004.

[9] M. S. Ferdous and A. Jøsang. Entity Authentication & Trust Validationin PKI using Petname Systems. In Theory and Practice of CryptographySolutions for Secure Information Systems (CRYPSIS), pages 302–334.IGI Global, 2013.

[10] M. S. Ferdous, A. Jøsang, K. Singh, and R. Borgaonkar. Security Usabil-ity of Petname Systems. In Proceedings of the 14th Nordic Workshopon Secure IT systems (NordSec 2009), Oslo, October 2009.

[11] J. Franks et al. RFC 2617 – HTTP Authentication: Basic and Digest Access Authentication.IETF, June 1999. URL: http://www.ietf.org/rfc/rfc2617.txt.

[12] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink,and L. Stewart. An Extension to HTTP : Digest Access Authentication.RFC 2069, RFC Editor, January 1997.

[13] A. Herzberg and H. Shulman. Security of Patched DNS. In S. Foresti,M. Yung, and F. Martinelli, editors, Computer Security – ESORICS2012, volume 7459 of Lecture Notes in Computer Science, pages 271–288. Springer Berlin Heidelberg, 2012.

[14] T. E. Humphreys, B. M. Ledvina, M. L. Psiaki, B. W. O’Hanlon,and P. M. Kintner Jr. Assessing the spoofing threat: Developmentof a portable gps civilian spoofer. In Proceedings of the ION GNSSinternational technical meeting of the satellite division, volume 55,page 56, 2008.

[15] C. Johansen and A. Jøsang. Probabilistic Modeling of Humans in Secu-rity Ceremonies. In A. Aldini, F. Martinelli, and N. Suri, editors, 3rdInternational Workshop on Quantitative Aspects in Security Assurance(QASA14), volume 8872 of Lecture Notes in Computer Science, Wro-clow, Poland, September 2014. Springer.

[16] A. Jøsang, D. Povey, and A. Ho. What You See is Not Always WhatYou Sign. In Proceedings of the Australian UNIX and Open SystemsUsers Group Conference (AUUG2002), Melbourne, September 2002.

REFERENCES 52

[17] A. Jøsang, C. Rosenberger, L. Miralabé, H. Klevjer, K. A. Varmedal,J. Daveau, K. E. Husa, and P. Taugbøl. Local user-centric identitymanagement. Journal of Trust Management, 2(1):1–28, 2015.

[18] A. Jøsang, K. A. Varmedal, C. Rosenberger, and R. Kumar. ServiceProvider Authentication Assurance. In Proceedings of the 10th AnnualConference on Privacy, Security and Trust (PST 2012), Paris, July 2012.

[19] K. Kain, S. Smith, and R. Asokanm. Digital Signatures and ElectronicDocuments: A Cautionary Tale. In Proceedings of IFIP Conference onCommunications and Multimedia Security: Advanced Communicationsand Multimedia Security., 2002.

[20] D. Kaminsky. It’s the End of the Cache as We Know It. BlackHat USA,2008.

[21] H. Klevjer. Requirements and Analysis of Extended HTTP Digest Ac-cess Authentication. Master’s thesis, University of Oslo, Norway, 2013.

[22] H. Klevjer, A. Jøsang, and K. A. Varmedal. Extended HTTP Di-gest Access Authentication. In Proceedings of the 3rd IFIP WG 11.6Working Conference on Policies & Research in Identity Management(IFIP IDMAN 2013). Springer, London, 8-9 April 2013.

[23] H. Klevjer, K. A. Varmedal, and A. Jøsang. Extended HTTP digestaccess authentication. In 3rd IFIP WG 11.6 Working Conference onPolicies & Research in Identity Management (IFIP IDMAN), volume396 of IFIP AICT, pages 83–96. Springer, 2013.

[24] M. S. Miller. Lambda for Humans: The Pet-Name Markup Language. Resources library for E,http://www.erights.org/elib/capability/pnml.html, 2000.

[25] H. Nayyar. Clash of the Titans: ZeuS v SpyEye. SANS Institute InfoSecReading Room, 2010.

[26] D. Pavlovic and C. Meadows. Actor-network procedures: Mod-eling multi-factor authentication, device pairing, social interactions.arXiv.org, 2011.

[27] C. Prisacariu. Actor Network Procedures as Psi-calculi for SecurityCeremonies. In S. Mauw, B. Kordy, and W. Pieters, editors, GraMSec2014 – First International Workshop on Graphical Models for Security,2014.

REFERENCES 53

[28] S. Son and V. Shmatikov. The Hitchhiker’s Guide to DNS Cache Poi-soning. In S. Jajodia and J. Zhou, editors, Security and Privacy inCommunication Networks, volume 50 of Lecture Notes of the Institutefor Computer Sciences, Social Informatics and TelecommunicationsEngineering, pages 466–483. Springer Berlin Heidelberg, 2010.

[29] A. Spalka, A. B. Cremers, and H. Langweg. The fairy tale of ‘What YouSee Is What You Sign - Trojan Horse Attacks on Software for DigitalSignatures. In IFIP Working Conference on Security and Control of ITin Society-II (SCITS-II), Bratislava, Slovakia, June 2001.

[30] M. Stiegler. Petname Systems. Technical Report HPL-2005-148, HPLaboratories Palo Alto, 15 August 2005.

[31] A. Weber. See What You Sign: Secure Implementations of Digital Sig-natures. In Proceedings of the International Conference on Intelligenceand Services in Networks (ISN 1998), pages 509–520, 1998.

[32] B. Z. Wilcox-O’Hearn. Names: Decentralized, secure, human-meaningful: Choose two. http://www.zooko.com/distnames.html, 2005.

OffPAD: Ofﬂine Personal Authenticating Device ...

Documents

Transcript of OffPAD: Ofﬂine Personal Authenticating Device ...