Authenticating Device – Implementations and
Applications
Christian Johansen , Audun Jøsang , Denis Migdal Research report 454, August 2016
ISBN 978-82-7368-419-6
ISSN 0806-3036
Abstract
Identity and authentication solutions often lack usability and scal- ability, or do not provide high enough authentication assurance. The concept of Lucidman (Local User-Centric Identity Management) is an approach to providing scalable, secure and user friendly identity and authentication functionalities. In this context we demonstrate the use of 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 server side or in the cloud. This demo aims to show how OffPAD strengthens authentication assurance, improves usability, minimizes trust require- ments, and has the advantage that trusted online interaction can be achieved 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 six demonstrators, three useful in e-banking and three in the hospital do- main where nurses, doctors, or patients are authenticated and access is 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, France
E-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
1 Motivation and Background 4
2 OffPAD device description 5
2.1 Hardware specification . . . 6
2.1.1 Usability . . . 6
2.1.2 Sensors and Security . . . 7
2.1.3 Secure display . . . 8
2.1.4 General considerations . . . 8
2.2 Software features . . . 8
3 OffPAD demonstrators 9 3.1 E-banking . . . 9
3.2 Hospital environments . . . 10
4 Data Authentication based on OCR 11 4.1 Data Authentication . . . 11
4.1.1 Background and motivation . . . 11
4.1.2 High-level description for Data Authentication Sup- ported by the OffPAD . . . 12
4.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 . 19 4.2.3 API descriptions . . . 22
4.2.4 A Concrete Application . . . 24
5 User Authentication based on HTTP XDAA 27 5.1 User Authentication using Biometrics through OffPAD . . . . 27
5.1.1 Background and motivation . . . 27
5.1.2 High-level description for User Authentication through OffPAD . . . 28
5.2 Detailed Description of the Ceremony for User Authentication using OffPAD . . . 29
5.2.1 Structure of the Security Ceremony for User Authen- tication . . . 30
5.2.2 Secure Run of the Ceremony for User Authentication . 30 5.2.3 API descriptions . . . 32
5.2.4 A Concrete Application . . . 33
6 Server Authentication by the User based on Petname 34
6.1 Server Authentication by the User . . . 34
6.1.1 Background and motivation . . . 34
6.1.2 High-level description for Server Authentication . . . . 36
6.2 Detailed Description of the Server Authentication Ceremony by the User . . . 37
6.2.1 Structure of the Security Ceremony for Server Authen- tication . . . 37
6.2.2 Secure Run of the Ceremony for Server Authentication 38 6.2.3 API descriptions . . . 40
6.2.4 A Concrete Application . . . 41
7 Contextual automatic login based on indoor location 42 7.1 Background . . . 42
7.1.1 Motivation . . . 42
7.1.2 Standard automatic login-logoff . . . 42
7.2 eHospital . . . 43
7.2.1 eHospital infrastructure . . . 43
7.2.2 Sonitor sense . . . 44
7.2.3 User . . . 44
7.2.4 Hospital Network . . . 45
7.2.5 SmartTracker . . . 45
7.3 eHospital Automatic Terminal Logon Access System (ATLAS) 45 7.3.1 Pairing . . . 45
7.3.2 Soft authentication . . . 46
7.3.3 Hard authentication . . . 46
7.3.4 Multi-login . . . 46
7.3.5 Disconnection . . . 47
7.4 API descriptions . . . 47
7.4.1 OffPAD - SmartTracker API . . . 47 8 Alternative Applications and Implementations 49
9 Security services 50
10 Discussion and Conclusion 50
Acknowledgements:
We thank all OffPAD project members who have either put effort into parts of this technical report or have contributed with great ideas or discussions; par- ticularly to: L. Dallot, L. Miralabe, and G. Cornet (TazTag, manufacturer of secure 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 indoor locating solutions).
1 Motivation and Background
We present the OffPAD concept, i.e., the hardware, a phone-jacket with secure elements, and software components. The concept of OffPAD has been put forward in [17], part of the project called OffPAD.1 Several use cases have been identified to show case the OffPAD in the domains of e-banking and hospitals.
One purpose of the OffPAD is to provide higher security without reducing the 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 on each side in the client-server model, as illustrated in Fig.1. A requirement for trusted interaction in this scenario is to have mutual authentication be- tween pairs of interacting entities whenever relevant, leading to 4 possible types of mutual entity authentication as shown in Fig.1 and described in Tables 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 because users recognise the server identity and decides whether it is the intended one.
User identity management is frequently discussed in the identity manage- ment literature, whereas SP identity management is mostly discussed in the network security literature. Lucidman applies to both types because users must manage their own identities as well as those of SPs, in order to be authenticated by server systems on a semantic level, and to authenticate the server systems on a cognitive level. Lucidman is aimed at providing adequate
1www.offpad.eu
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 service provider (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 identities and server identities, with the goal of enabling trusted interaction between online entities.
2 OffPAD device description
The OffPAD is a trusted device, i.e. assumed to function as intended and to be adequately protected against relevant attacks. The first OffPAD pro- totype is a phone cover connected to its host with a standard micro-USB interface. This makes the OffPAD a portable object, but not a second elec- tronic object in the user’s pocket. Unlocking the OffPAD is currently done through 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 and applications.
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 to verify the connection between the device and the client platform, the trust must 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 Model
Controller ARM Cortex-M4
32b MCU+FPU, 105 DMIPS, 256KB Flash / 64KB RAM
STM32F401
Secure display e-Ink 2.5 inches
NFC transceiver NFC Forum Certified NPC1002A2EV Secure element Java Card / Global
Platform compliant
ST33FIMFF,ST Micro
USB interface USB OTG 2.0 (High
speed) Fingerprint sensor Pixel matrix 192x192
pixels @502 dpi
FPC1020 Touch Fin- gerprint Sensor
3 states switch On / Off / Mainte- nance
Mechanical switch Flash memory For private and secure
storage
4 to 16GB
LED Multicolor Multicolor
studies show that they want to limit the number of those device and ideally bring 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 easily portable 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 the channel cannot be controlled (e.g. GPS) or the physical environment can be easily distorted (e.g. magnetometer). For instance, a non secure channel can be spoofed [14]. Physical environment can also be artificially manipu- lated by electrical or magnetic fields altering magnetometer and even some accelerometers.
We assume that the sensors integrated in the OffPAD are secure. As we consider that it is not critical to embed such sensors into a secure platform, we keep 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 a malware 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 design cost or in end-user usability without any benefit on the experimental power of the current prototype.
2.1.3 Secure display
As stated in section 4, standard displays cannot be trusted by the user as a malware might modify what should be printed. By adding secure display on the 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-Paper screen for advanced information which can print 40 characters per line and 4 lines.
2.1.4 General considerations
To maximize the security and the universality of the OffPAD, we based the security on hardware secure components that can be attached to any devices (phone or PC) that provides communication interfaces. For this reason we choose to use USB communication as is compliant with all Android phone and micro-USIB is a standard interface on theses devices.
We choose to implement the OffPAD as a phone cover as it does not constitute 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 Android Interface Definition Language (AIDL) which allows API definition in Java- like style. Thus after bounding the OffPAD service, an application can access the OffPAD features simply by calling methods on an object. Theses calls are transformed by Android to be transmitted to the recipient service. In our cases, theses transformed calls are transmitted by USB to the OffPAD device.
The OffPAD service defines its own permissions that must be requested by 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 future work.
The OffPAD firmware supports the following features:
User Authentication by performing a biometric authentication of the holder
Manage 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 based
on OCR (Optical Character Recognition) displayed on the OffPAD ink-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 of the OffPAD using Sonitor system, as detailed in section 7.
Multi-login: Automatic access to a resource conditioned on multiple users authenticated at once, using TellU SmartTracker system, as detailed in section 7.
Strong auth.: Strong authentication required for accessing sensitive infor- mation or tasks, using biometric fingerprint authentication of the user by the OffPAD, as detailed in section 7.
3.1 E-banking
Internet operations such as banking operations needs at least 3 types of authentications :
• 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 that he has the right to query for such operation. Ensuring the user’s identity remains on verifying that she knows a secret, such as credentials. Thus this secret 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 expose credentials on possibly infected client that may leak users’ credentials when performing operations.
The ordering person has to ensure that he sends his information to the operating, 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’s identity and make operations in her name, such as transferring money from the 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 the operating 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 of 100£ 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 the standard display is corrupted.
3.2 Hospital environments
Hospitals are a hectic working environment where a multitude of users with diverse roles interact with hospital IT shared systems for various duties like patient records, routine information, or logging of medical tasks. However, patient information security and privacy must still be ensured throughout the daily work. This implies that the hospital staff must log on to terminals and be authorized every time they interact with IT systems. This has been found 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 where the user will be automatically logged (Auto-login) into a terminal when she approaches 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
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 is different from entity authentication because knowing the identity of a remote entity in a session (entity authentication) is different from knowing whether the data received through a session with a specific remote entity genuinely originates from that entity. This difference might sound subtle at first glance but it is in fact fundamental for security, as explained below.
Malware infection of client platforms opens up for attacks against data authentication that entity authentication can not prevent. More specifically, entity authentication is insufficient for ensuring trusted interaction in case the client platform is compromised. A typical example is the situation of online banking transactions with mutual entity authentication. Even when there is strong 2-factor user authentication, and we assume that users correctly inter- pret server certificates for server authentication, there is the possibility that malware on the client platform can modify data communicated between client and server platforms, and thereby compromise transactions. Current attacks against online banking are typically mounted in this way. Such attacks lead to breach of data integrity, but not a breach of entity authentication.
The preparation for this type of attacks typically includes tricking the user into installing a Trojan, i.e. a program that really or seemingly does something useful, but that in addition contains hidden malicious functionality that allows the attacker to take control of the client platform. During an online banking transaction the attacker uses the Trojan program to change transaction details without the user’s knowledge. SpyEye, Zeus, IceIX, TDL, Hiloti, Carberp, and many others [6, 25] are concrete examples of malware that enable such attacks.
The separation between the human/legal entity and the system entity on each side of a client-server session makes it necessary to specify which entity in particular is the assumed origin of data. In case e.g. the human user is assumed to be the origin, and the client system modifies data input by the user before it is sent to the server system, then this would be a breach of data origin authentication. However, in case the client system is assumed to be the origin, the same scenario would not be a breach of data authentication. The general rule is that the object of entity authentication must also be the origin of data authentication. For typical online transactions where the human user
is directly involved and authenticated, the user must also be seen as the origin of data for data authentication purposes. Unfortunately current solutions for user data origin authentication are either non-existent or inadequate because they assume the client system to be the origin of data [2].
Users rely on visual cues to know whether a browser session is secured with TLS. After verifying that TLS is enabled, averagely security aware users will comfortably input their banking account and transaction details into the browser window. However, many users ignore that malware like those mentioned above has functionality commonly known as a "web inject" that can change the behaviour of the browser and modify input and output data arbitrarily.
The fact that entity authentication and data authentication are two sep- arate security functions implies that it is necessary to have specific security mechanisms to ensure data integrity in online transactions. The OffPAD enables data origin authentication with high assurance and usability, as ex- plained below.
4.1.2 High-level description for Data Authentication Supported by the OffPAD
Users generally rely on what they see on a computer display to read the output of transactions, to verify that they type correctly, and to ensure that the data being sent through online transactions is according to their inten- tions. In general, all this depends on the integrity of the computing platform to which the VDU (Visual Display Unit) is connected. Assuming that the computing platform is infected with malware it is a priori impossible to trust what is being displayed to be 100% correct [1, 16, 19, 29, 31].
The prospect that the computer display can lie to us is both frightening and real. This problem is amplified by the fact that we often read data from platforms that are not under our control, and that hackers have incentives for trying to manipulate the systems and the way data is displayed. For example, typical attacks against online banking consist of using a malicious Trojan on a client computer to send falsified transaction data to the bank server while displaying what the user expects to see.
In order to provide data authentication, some online banks offer SMS authorization of transactions, which consists of mirroring the received trans- action data (destination account and amount to be transferred) together with an authorization code by SMS to the user. After verifying the correctness of the transaction data, the user returns the authorization code via the browser to confirm that the integrity of the transmitted transaction data. In case of an 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 a relatively 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 when transaction data in an SMS message have been changed, which means that 30% 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. to ensure that what is displayed on the VDU corresponds to what is being trans- mitted to other parties in online transactions. The method assumes that the user has an OffPAD with integrated camera, OCR (Optical Character Recog- nition) and communication functions. The user first captures a screenshot from the VDU with the OffPAD camera, then uses the OffPAD to recover the displayed data from the image through OCR, and finally to compute a MAC (Message Authentication Code) which is sent along with the original transaction data. The MAC enables the recipient server to authenticate the received 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 be discovered 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 the OffPAD is offline, it is assumed that the OffPAD will not be exposed to threats from the Internet.
One drawback of the above ceremony is the use of OCR technology on the OffPAD device side. OCR recognition is computational intensive, and may not be scalable to any graphical user interface that the browser provides. We
Nr. Message / action description
1. User types the transaction data in a browser window on the client computer
2. User activates the OffPAD to take a snapshot of the browser window
3: Snapshot is taken of the text displayed in the browser window on the VDU
4. The OCR function recovers the transaction data from the snapshot
5. MAC generation with the transaction data and the user- password as input
6. OffPAD send the MAC to the client computer
7. Client computer sends transaction data together with MAC to server
8. 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 that the browser and transaction is being done, even if this can be infected by malware. And we would like the task of the OffPAD device to use as little computation power as possible.
We want to achieve this by adapting the idea of proof-carrying-code from software 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 the verification of the proof and execution of the compiled software. Generation of the proof is a more computational intensive part, whereas checking of the validity 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 proof to 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 verification of this proof by the OffPAD device is simple and it uses the credentials of the user, the same credentials that were used to authenticate to the server.
These credentials are the secure bit that only the user (OffPAD device) and the 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 this ceremony. Any other possible runs should be considered insecure. In the end we discuss the API associated to this ceremony and present some sequence diagrams. These would be similar, but more concrete, to the description of the 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: the User (U) and theBank(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, be that 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, these are:
SB which represents the Server of the Bank. This is why this configuration is under the control of the Bank identity (rep- resented as the under-script). In Figure 3 this is represented as 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 which may be infected with malware. But the terminal can be other things as well, e.g., the Internet Browser that is used to com- municate with the bank, or the SmartPhone, or an App on the SmartPhone.
Note that the Terminal is not under the control of any of the two identities. Therefore it is left open to potentially become under the control of an Attacker.
At this level of description it is good to leave room for such variations. 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 Trusted Hardware OHU. The software agent is assumed to be under the control of the User.
PU which represents the Persona of the user (i.e., the human part of the ceremony). We do not focus on the concept of Personas here, but consider it as is usually done to represent the Human User involved in the protocol. For more details about Personas please see our paper [15] and the references therein.
OHU which represents the OffPAD Trusted Hardware which is assumed 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, and NFC communication capabilities.
• One complex configuration, (depicted as a small black square) which we will call theOffPADUbeing formed of putting together the OffPAD Hardware and the OffPAD Agent to share informa- tion between each other. The dashed lines symbolize the complex configuration and how information can flow from the components to the back square and back. This complex configuration is thus under the control of the User. How the sharing of information is done is not so important as long as it respects the assumption that it is secure, i.e., it cannot be intercepted by an attacker. For this the TazTag will implement this sharing using NFC commu- nication.
The precise implementation of the sharing of information between the Hardware and the Agent is important, and will be detailed further.
Channels which represent the various ways of transmitting information or interacting 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 labelled with the type of channel. The type of channel encapsulates the secu- rity assumptions we have about this interaction medium, and we will make these precise. We are working on developing a formalism for this, which can be used in conjunction with the formalism we have presented in [27] for the rest of the AMP ceremony to achieve formal verification.
U
B
SB
PU
OAU
OHU
cyb cyb
key vis cmd Term
OffPadU
visInk bio
OSchan IMG
blue
Figure 4: ANPstructure for the Data authentication ceremony.
The ceremony comprises of the following channels:
• There are two cyber-channels (cyb) between the Server of the Bank and the Terminal. Cyber channels carry the assumptions that are un-safe, falling under the standard Dolev-Yao model of attacker which can listen to messages, change messages, and insert new messages.
• There is avisualchannel (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 that nothing can change the messages sent on this channel, and thus the Persona receives whatever is sent by the Terminal. But this does not exclude that an infected Terminal sends spurious infor- mation on this channel.
• There is also akeyboardchannel (key) which can be used by the Persona 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 other aspects like thedrivers which handle the information processing for these channels on the Terminal side. We consider these drivers to be part of the Terminal. Therefore, if the Terminal is under the control of the Attacker these drivers may be as well, and thus handle information in unexpected ways. For example, we may type one character at the keyboard, but the driver changes it into another; 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 we type we just see star symbols.
• There is also avisual InkDisplaychannel (visInk) from the Off- PAD hardware to the Persona. Assumptions are made of this channel similar to the other visual channel. The InkDisplay is though more rudimentary and thus can display more simplistic information, and maybe without all the visual aids of a fully- fledge visual laptop display. For example colours are not available here, so any visual aids that are usually used to help users, like color red for danger/unsecure, or color green for secure. This also may make the communication of the information to the user more error prone, in the sense that the user may not distinguish well the information displayed. Such situations can be taken advantage by an 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 that the drivers that handle the information displayed cannot be ma- nipulated.
• Abiometricschannel (bio) transfers Fingerprint biometrics from the Persona to the OffPAD hardware.
• We have added also a commandschannel (cmd), which commu- nicates very simplistic command messages, OK, StartTransaction, StartOCR, etc. Such a channel can be devised in any number of ways, like through buttons, or through a led-blink and finger press protocol. In any case the simplicity of the messages makes it dif- ficult to attack such a channel. Even more in our situation where this channel is between the Persona and the OffPAD configura- tion, which is assumed to be secure and under the control of the User.
• There are two channels between the Terminal and the OffPAD Agent to handle any kind of information transfer. From the point of view of the information these channels are like cyber-channel, being able to transfer any kind of data. But these channels are implemented with short-range communication technologies like NFC, BlueTooth, or Operating System communication channels. NFC and BlueTooth would be used when the Agent and Terminal are part of two different devices (i.e., the Terminal is a Laptop), whereas OS-channel would be used when the Agent is an App on the SmartPhone. This last situation is what we concentrate on in our first prototype.
• There is also aIMG channel for transferring an image equivalent of 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 is that the image transferred is identical to the one displayed on the visual display (i.e., send on the visual channel to the Persona).
One example, in the case of Terminal being a Laptop, could be to use a camera incorporated in the OffPAD hardware (which is trusted) and to take a picture of the Terminal screen. Another ex- ample, in the case the Terminal is a SmartPhone, can be to take a screen-shot and guarantee that the OS-transmission path for this operation to the OffPAD Agent is secured. This means that all involved software components from the Operating System of the SmartPhone (like drivers or screen-capture software) are ensured to not be susceptible to Attacks which have the power to alter the information. Note that attacks that only have the power to snoop this 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 the components of our ceremony we can detail the secure run that we expect of this security ceremony. Any other runs, if possible, are considered insecure.
We picture this run in Figure 5 with graphical notation introduced in [26] and which we investigate in [27]. This notation should be familiar from Strand Spaces. But otherwise, the notation is rather intuitive and also similar to sequence diagrams. Nevertheless, we explain each step of the run, because for our ceremony there are various assumptions and discussions which do not appear in the figure.
In a run we draw horizontal arrows when there is communication between the parts of the ceremony. These parts are the ones defined in the structure Figure 4 and for the run we just display these parts at the top. One can imagine a vertical line (as in sequence diagrams) to pertain to that specific actor in the ceremony. We label the horizontal arrows with the channel name on which the communication is done (shows in the same grey color as the arrow itself). On top of the arrows we display the information that is being sent, or the action that is being taken or that produces the respective information.
We display internal computations or actions by a vertical arrow and label it with the respective activity that is being performed (possibly with the outcome of that activity).
Sharing of information inside the complex configuration is represented by the same dotted line. In our case the sharing between the Software Agent and 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) through the 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 the Transaction information, which we denote by the general termt. What exact structure this information has is not relevant here, and can later be defined to be many things, like bank account and amount to be transferred.
• The Terminal displays this information back to the User through the visual display channel. This is natural because usually the user fills in a form, which is already displayed. But we cannot assume that the Terminal displays the same information, therefore we denote this byt1.
• 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. This part 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 it does not appear in the implementation part that we see later.
• Presumably, the Persona then starts the OCR operation by sending such a command to the OffPAD.
• In turn, the OffPAD Software Agent is the one asking the Terminal for the image related to the transaction form.
• The acquiring of the Image is an operation that can be done in various ways, and we let it open here. But in any case we can assume that the image is being transferred from the Terminal (where it was displayed to the User) to the Software Agent. This step 3 needs more careful analyses and development.
• The image is shared with the Hardware.
• In the OffPAD Hardware is where the OCR operation takes place (in a trusted environment). This takes as input the acquired image, and
SB
PU OHU OAU
Cognitive analyse
t ?= t 2
3
5
6 7
8
Cognitive analyse t ?= t ?= t1 2
4 1
Term
nu[x]
OSchan cyb
share
x x
x x
key vis
AskIMG StartOCR
share
cmd OSchan
share
IMG
s s
t := OCR(s)2
s := ImgAcquire() t := SendTransInfo()
t := ShowTransInfo()1
visInk
bio
share
m m m
OSchan cyb
check
1
m + t1
2
f := ok+Finger() Show(t )2 1
0
m := MAC(t , f,x)
m ?= MAC(t , f,x)
OffPadU
Figure 5: ANPrun for the Data authentication ceremony.
outputs some transaction information. For our purposes we can only denote this t2 differently from before.
• The Transaction information is then Displayed on the InkDisplay to the Persona.
• The Persona can check to see if these transaction information are matching.
• Then the Persona can issues the signing key by providing the Hardware with the Fingerprint. This key can also just be the OffPAD Hardware key. The Fingerprint can mean the Authentication of the User by the OffPAD Hardware (function discussed by TazTag documents). The Fingerprint can also trigger a command, like “OK, make the MAC and finalize the transaction”.
• Using the key f the OffPAD Hardware produces a MAC (Message Authentication Code) of the transaction information t2 it extracted from the image; call this m. Note that this could have been done without interaction with the User, but just immediately after the OCR operation, and by using the OffPAD key, since the user has already been authenticated previously to the transaction start. But this is an assumption that we need to be careful about.
• The MAC m is being shared with the Software Agent, which in turn sends it to the Terminal. In the case of the SmartPhone scenario, the Agent communicates through the Operating System message bus. But what exact communication mechanism is abstracted away here, and we only assume to not be so unsecure as a cyber-channel, but maybe under the Operating System.
• The Terminal sends both this message and the transaction information that it wants (here we assume it sends the same transaction that it was 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 transaction information sent by the Terminal.
4.2.3 API descriptions
By now we can identify several functionalities that need to be provided by the components of the ceremony in order to achieve the run that we just described. 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 of the OffPAD Hardware. This provides trusted visual communica- tion with the User.
input: annotated in a specific purpose XML format, which we will call TransXML. The annotations are needed so that we can tell the display how each piece of information to be rendered, like the Banck account larger, or the sum larger. The XML content is converted 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 prototype does 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 some visual queues so to allow the OCR to recognize easier the relevant information 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 the extraction 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 the transaction information) using the key of the OffPAD hardware which 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 Software Agent
purpose: to allow for transmission of any kind of data between the two OffPAD components, in both ways. Sharing is currently im- plemented through micro-USB standard. But one can use here other communication means s.a. NFC or BlueTooth; though only NFC 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 operating system. For the terminal we consider the Browser through which the User interacts 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 than normal apps. This needs more discussion because it is important to under- stand the security aspects and what kind of resources are available to the Agent, 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. NFC communication could also be possible between the back-cover and the Smart- Phone. Note that in the above scenario alone we already share various kinds of information: nounce, image, XML text output by OCR, or a generated MAC; and the sharing is both ways.
There are two aspects of this diagram that need more detailing: these are marked with the red labels A and B. This is where the development mostly takes 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 designs as 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 in the red squares (only one of these should be part of a final diagram).
OffPAD Hardware
OffPAD Software (Android service)
Software client (Browser)
User Bank’s Server
A Share(s)
Share(t2) B
Android SmartPhone Secure 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 of the OffPAD Hardware, using the image acquired in the OffPAD Agent. If we assume the image acquisition is trusted (or evaluate the threat level to a low one), then this method is as secure as this threat. But OCR usually requires intensive computation resources, which most probably are not available in the secure jacket of the OffPAD.
Therefore we investigate the lower square alternative. Here the OCR is done on the Agent, which as a smartphone has the required computation power, and then a term t2 is transmitted securely through the microUSB connection. One can imagine an attack where the Agent is infected, and thus the output from the OCR is not the same as the one transmitted to the Hardware. But we assume that infecting the Agent is less probable than infecting a common app (how probable remains to be determined). Neverthe- less, even in the setting of this attack, the fact that the t2is being displayed on the secure Hardware allows the user to verify that the t2 corresponds to the image displayed by the Agent, by simply flipping the phone from one side to the other so to look at both screens and compare their displays. But how easy 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 task is 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 is used for tweaking the performance of the OCR algorithm (i.e., is associated with the visual pattern in the OCR algorithm).
This form is displayed to the user by the Browser. An infected Browser can of course display a manipulated form (this is the purpose of f1 in the diagram), even with the graphics pertaining to the BankID unchanged.
The User provides information into the form, which we denote byt. This is the transaction information intended by the User. This information can be different than the other (similar in format) information that is being transmitted around, i.e., the other t1, t2terms. To emphasis this aspect the diagram 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 the Browser 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 to the Browser more info than required by the Bank. The attacker would send only what was required by the Bank. This would be an instance of a social engineering attack. Such an attack could be captured through the above use of OCR technology because the MAC sent to the Bank would contain the extra information.
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 input b of the User. This hash is used in the MAC generating algorithm, which is applied to the transaction information displayed on the secure InkDisplay as t2.
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
5.1.1 Background and motivation
Users of online services typically accumulate so many online identities and related passwords that it quickly becomes a usability challenge to manage them securely. In addition, since it is reasonable to assume that typical client platforms are infected by malware, storing and using credentials such as pass- words on these platforms is a security risk. Passwords can be intercepted by Trojans either through keystroke logging, RAM-scraping, or by screenshots when shown on the screen in clear text. Even automatic log-in and iden- tity management applications such as LastPass2 are not safe, as they release the clear text password to the web browser (or other application) during authentication, leaving it visible in memory for the Trojan to steal.
The OffPAD may be used to manage and authenticate a user to a system in a secure way. This would improve usability by providing a tool for iden- tity management, and would also improve security in several respects. In a traditional scenario where the user types his password, or the password is decrypted by a password manager (e.g. LastPass), the password is exposed in the computer’s memory and is vulnerable to attacks such as key logging or memory inspection. A solution for password authentication using an Off- PAD is proposed by Klevjer et al. in [22], consisting of an extension to the original HTTP Digest Access Authentication scheme specified as a part of the HTTP standard in [11]. User credentials are stored in a hashed format on both the server and the OffPAD. When the user via the client requests a protected resource, the server responds with an authentication challenge, which on the client side is hashed with the user credentials and returned to the 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 the resource. This can be done securely through an insecure channel, such as over HTTP, not requiring an extra connection to the server, just a browser plug-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-known HTTP Digest Access Authentication protocol. A brief overview of the exist- ing HTTP Digest Access Authentication standard is provided next. We then describe our method of combining the OffPAD with extended HTTP Digest Access Authentication. The advantage of our method is that it totally pre- vents exposure of passwords on potentially vulnerable client platforms, and thereby represents secure local user-centric identity management solution. A proof-of-concept implementation of the method has been developed for the OffPAD prototype [21].
HTTP Digest Access Authentication (short: DAA) originates from the challenge-response authentication framework described in the original HTTP 1.0 specification [5]. It is a web standard for access control to a service or domain called realm by user authentication over HTTP. DAA was first defined 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 implementable for protection of local resources, or in any situation where application level access control is required3.
5.1.2 High-level description for User Authentication through Off- PAD
Internet 7
Server Infected
Client
User
2
User 5 OffPAD
8 6 1
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 description
1. Server sends HTTP digest access authentication challenge to client
2. Challenge from server is forwarded to OffPAD 3: OffPAD presents user authentication request to user 4. User approves authentication request
5. OffPAD computes response to challenge from server 6. Response is sent from OffPAD to client
7. Client forwards response to server
8. 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 calculations done in the authentication phase are outsourced to the OffPAD.
Our XDAA is beneficial both for security and usability. By managing the user credentials on an external device, we get a local user-centric iden- tity management system, so users are no longer required to remember their passwords. Moving the challenge-response calculations and handling of the values critical to authentication over to a mostly offline device, we reduce the risk of exposing these values. Moving the identity management over to such a device alleviates the cognitive and physical strain on the user during authen- tication, as well as removing the time penalty brought by user interaction in most situations4.
In its simplest form (using the OffPAD and no further protection mecha- nisms), XDAA can be used with any HTTP server supporting original HTTP DAA without change to the server system. The immediate benefit is that the user’s credentials themselves are never present. They are never shown on the screen, never exposed in any vulnerable state in the computer’s memory and 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
B
SB
PU
OAU
OHU
cyb cyb cmd Term
OffPadU
visInk bio
OSchan blue
Figure 8: ANP structure for the ceremony for User authentication using the credentials stored on the OffPAD.
ceremony. Any other possible runs should be considered insecure. In the end we discuss the API associated to this ceremony and present some sequence diagrams. These would be similar, but more concrete, to the description of the secure run.
5.2.1 Structure of the Security Ceremony for User Authentication The structure of the ceremony for User authentication using the credentials stored on the OffPAD, is pictured in Figure 8.
The structure is similar to the one described before in Section 4.2.1 with a few channels missing. In particular, we do not need to look at the Image acquisition 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 fact that 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 the ones mentioned above).
5.2.2 Secure Run of the Ceremony for User Authentication Using the same notation conventions as before, we detail the secure run that we expect of this security ceremony. Any other runs, if possible, are considered insecure. We picture this run in Figure 9. We explain those steps of the run which are not entirely clear from the figure.
• The Terminal starts the ceremony by requesting a restricted resource from the service provider on behalf of the User.
SB
PU OHU OAU
0
1 3
5
6 7
check 8
m ?= MAC(h,x)
4
2
Term
nu[x]
share cyb
Req(UserID) http_DAA(x);BankID
c := Credentials(BankID) visInk
BankID Approve
share
m m m
OSchan cyb
m := MAC(c,x)
m
h :=
HashedCreden(UserID) cmd/bio
x;BankID OSchan x;BankID
OffPadU
Figure 9: ANP run for the User authentication using credentials stored on OffPAD.
• The Bank server generates a unique timestamp and sends this as a HTTP 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 we couple with the petname system so to show the identity of the Service provider in a more intuitive and user-friendly way. Even DNSSEC-like certificates could be used previously in the run.
• The approval can be either through the command channel (like press and OK button) or through biometrics (providing the fingerprint; thus showing that the actual User is handling the OffPAD). Either of these would trigger the OffPAD functionality of retrieving User credentials particular 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 forwards it through the Operating System channel to the Terminal to further forward to the Service Provider.
• At the Service Provider, the hashed credentials for the current User are retrieved and used to also generate a MAC which is checked against the message received from the Terminal.
5.2.3 API descriptions
There are two main functionalities that we need on the OffPAD hardware.
1. MACgen() on the OffPAD Hardware component.
This feature is provided by the OffPAD as "Sign", see section 2.2.
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.
OffPAD Hardware
OffPAD Software (Android service)
Software client (Browser)
User Bank’s Server
Android SmartPhone Secure Cover
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 dependent on the initial algorithm/protocol for storing these credentials, and are not limited to just Username/password.
5.2.4 A Concrete Application
Let us now consider a concrete implementation of the above ceremony. See the sequence diagram of Figure 10. This has the same setup as in the other ceremonies, and follows rather closely the secure run we described in the previous section.
6 Server Authentication by the User based on Petname
6.1 Server Authentication by the User
6.1.1 Background and motivation
Secure access to online services is typically implemented with mutual au- thentication, i.e. with user authentication on the application layer and server authentication on the transport layer. Since mutual authentication goes be- tween the user and the server, we require server authentication by the user as[S→ U]which most often is not satisfied in current implementations, and user authentication by the server as [U → S] which currently is satisfied in most implementations.
Despite strong cryptographic server authentication, the typical implemen- tation of TLS in browsers only enforces syntactic server authentication, so that 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 phishing attacks often succeed even when TLS is being used for server authentica- tion [18].
Because phishing works fine without server certificates, most phishing sites do not have server certificates. Phishing victims often do not know the difference between a HTTP connection (without certificate) and a HTTPS connection (with certificate and TLS), so server certificates are probably seen by attackers as an unnecessary expense. However, there are phishing sites with certificates, and paradoxically, phishing site certificates are automati- cally validated by browsers.
Current browser implementations of TLS with certificates do not support semantic or cognitive server authentication, so using TLS with certificate does not offer any meaningful authentication. In order to provide cognitive server authentication, apetname system [9,10,30] must be used, as described below.
Reliable authentication of online entities require globally unique names that are understood by people. Domain names were designed to represent online identities of organisations, but domain names alone can be difficult to interpret.
Company names, trademarks and logos are typically used for recognising organisations in the real world, but would not be suitable for global online identification and authentication. This mismatch between names used in the online world and in the real world creates confusion about which unique domain 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 amount of time, e.g. 10 minutes after the bus has passed. A name is unique if it is collision-free within the domain [30].
The triangle of Fig.11 where each of the three desirable properties of names 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 Petnames Memorable
No names land
Figure 11: Zooko’s triangle
Wilcox-O’Hearn claimed with supporting evidence that no name space can be designed where names generally have all three desirable properties simultaneously. A visual analogy of this idea is created by placing the three properties at the three corners of a triangle. In a triangle, the three corners are never connected by a single line, only pairs of corners are connected. The edges joining the corners then illustrate the possible properties that a name space can have. Wilcox-O’Hearn suggested to design name spaces of global and unique names (pointers), and name spaces of memorable and unique names (petnames).
The Petname Model consists of mapping a common name space of point- ers to individual name spaces of petnames, which thereby combines all three desirable properties. A petname system is a system that implements the Petname Model. The OffPAD is ideal for hosting a petname system, so a simple petname system was implemented on the OffPAD.
5Called decentralized in [32]
6Called secure in [32]
7Called human-meaningful in [32].