Institutionen För Datavetenskap Department of Computer and Information Science

Institutionen för datavetenskap Department of Computer and Information Science

Final thesis Securing Credentials on Untrusted Clients

by Johannes Hassmund

LIU-IDA/LITH-EX-A--10/003--SE

2010-01-21

Linköpings universitet Linköpings universitet SE-581 83 Linköping, Sweden 581 83 Linköping

Linköping University Department of Computer and Information Science

Final Thesis Securing Credentials on Untrusted Clients

by Johannes Hassmund

LIU-IDA/LITH-EX-A--10/003--SE

2010-01-21

Supervisor: Nahid Shahmehri Examiner: Nahid Shahmehri

Abstract

IT systems rely on correct authentication of their users in order to provide confidentiality and integr‐ ity of data. When accessing systems remotely, for instance over the Internet, no assumptions can be made regarding the level of security on the computer used. Such computers may be exposed to malware, keyloggers and other threats and must therefore generally be considered as untrusted.

To increase security when users connect remotely from untrusted clients various authentication mechanisms can be used. Usability must however be considered when deploying new mechanisms. Protection must also be balanced to the load put on users.

This thesis gives a presentation of common authentication mechanisms available and enumerates the main attack vectors threatening correct authentication and credentials. Furthermore a ranking method is proposed in order to evaluate authentication mechanisms in relation to each other.

Using the outcome of the ranking of existing methods an authentication system called Smokey (Synchronizable Mobile Key) is proposed and implemented. Smokey uses Java capable cell phones as hardware tokens generating short time valid one time passwords. Whereas traditional tokens may cease to work under certain circumstances Smokey provides users the ability to synchronize with the authentication server aiming for high usability.

Acknowledgements

I would like to thank my supervisor and examiner Professor Nahid Shahmehri at the Department of Computer and Information Science (IDA) at Linköping University for feedback and support during the work of this thesis and for an interesting and much appreciated time at IDA. I would also like to thank my opponent Christian Vestlund for creative discussions and cherished coffee breaks. Finally I would like to thank my beloved wife Helena for hours of proofreading and constantly bringing light into my life.

Linköping, January, 2010

Johannes Hassmund

iii

Content

Chapter 1 Introduction ...... 1 1.1. Background ...... 1 1.2. Definition of Problem ...... 1 1.3. Method ...... 2 1.4. Delimitations ...... 2 1.5. Target Audience ...... 2 1.6. Outline...... 3 Chapter 2 Background ...... 5 2.1. Cryptography Basics ...... 5 2.1.1. Secure Hash Functions ...... 5 2.1.2. Message Authentication Codes ...... 6 2.1.3. Symmetric vs. Asymmetric Cryptography ...... 6 2.1.4. Digital Signatures ...... 7 2.1.5. Certification Authorities ...... 7 2.2. SSL/TLS ...... 8 2.2.1. SSL/TLS Handshake Protocol ...... 8 2.2.2. SSL/TLS Record Protocol ...... 10 2.3. Threats and attack vectors ...... 11 2.4. Malicious Software (Viruses, Worms, Trojan Horses and Rootkits) ...... 11 2.5. Untrusted Clients vs. Trusted computers ...... 12 2.5.1. Untrusted Client ...... 12 2.5.2. Trusted Computing ...... 12 2.5.3. What is Secure Authentication? ...... 12 2.6. Java ME ...... 13 2.6.1. Java ME API Access Control ...... 13 2.6.2. Java ME Security and Trust Services API ...... 14

Chapter 3 Attack Vectors ...... 15 3.1. Classification of Attack Vectors ...... 15 3.1.1. Active vs. Passive Attacks ...... 16 3.1.2. Definition of Attack Vector Classes ...... 16 3.2. Basic Level Attack Vectors ...... 16 3.2.1. Guessing and Dictionary attacks ...... 17 3.2.2. Brute Force Attacks ...... 17 3.2.3. Shoulder Surfing ...... 17 3.2.4. Password Reuse ...... 17 3.2.5. Hardware Keylogger ...... 18 3.2.6. Software Keylogger ...... 18 3.2.7. Social Engineering ...... 19 3.3. Medium Level Attack Vectors ...... 19 3.3.1. Theft of Credentials by Intrusion ...... 19 3.3.2. Eavesdropping of Network Traffic ...... 19 3.4. Advanced Level Attack Vectors ...... 20 3.4.1. Man in the Middle ...... 21 3.4.2. Man in the Browser ...... 22 3.4.3. Session Hijacking ...... 22 3.5. Other Attack Vectors ...... 23 Chapter 4 Authentication Methods ...... 25 4.1. Threat Assessment and Ranking of Methods ...... 25 4.2. Knowledge Based Authentication ...... 26 4.2.1. Passwords ...... 26 4.2.2. On Screen Mouse Entered Passwords ...... 26 4.2.3. Threat Assessment ...... 27 4.3. Token Based Authentication; One Time Passwords ...... 28 4.3.1. One Time Pads ...... 28 4.3.2. Short Time Valid One Time Passwords ...... 29 4.3.3. Challenge‐Response Based One Time Passwords ...... 31 4.3.4. Threat Assessment ...... 32 4.4. Token Based Authentication; Public Key Infrastructure ...... 36 4.4.1. Soft SSL/TLS Certificates ...... 36

vi 4.4.2. Smart Card Encapsulated SSL/TLS ...... 37 4.4.3. Threat Assessment ...... 38 4.5. Authentication Methods Suggested by the Research Community ...... 40 4.5.1. Secure Web Authentication with Mobile Phones ...... 40 4.5.2. Camera‐Based Authentication ...... 40 4.5.3. Threat Assessment ...... 41 4.6. Threat Assessment Summary and Comments ...... 42 Chapter 5 Suggested Authentication Method ...... 45 5.1. Choice of Authentication Method ...... 45 5.2. Prototype ...... 46 5.3. Usability Analysis of Prototype ...... 47 5.3.1. Usability Analysis Method ...... 48 5.3.2. Generic Usability Issues ...... 48 5.3.3. System Usability Scale ...... 48 5.3.4. Benefit of a Preinstalled Shortcut ...... 49 5.3.5. Comparison of Prototype versus Standalone Token ...... 50 5.3.6. Comparison of Digit versus Alphanumerical Passwords ...... 50 5.3.7. Conclusions ...... 51 5.4. OTP Generating Algorithm ...... 51 5.5. Security Considerations ...... 52 5.5.1. Counter and Time Window ...... 52 5.5.2. Throttling Parameter ...... 52 5.5.3. Recommended Parameters ...... 53 5.6. Key Exchange ...... 53 5.7. New Attack Vectors ...... 54 5.7.1. Physical Access to Cell Phone ...... 55 5.7.2. Theft by Infection of Malware ...... 55 5.7.3. Attacking the Phone Interfaces from Short Distance ...... 55 5.7.4. Theft from a Compromised Computer...... 55 5.7.5. Summary ...... 56 Chapter 6 Design and Implementation of Smokey ...... 57 6.1. Functional Requirement Specification ...... 57 6.2. Protocol Design ...... 62 6.2.1. Initialization Protocol ...... 63

vii 6.2.2. Synchronization Protocol ...... 66 6.3. Backend Database Design ...... 68 6.4. Server Implementation ...... 71 6.5. Client Application Implementation ...... 72 Chapter 7 Reference Deployment ...... 75 7.1. The Cisco ASA VPN Appliance ...... 75 7.2. Radius Authentication Protocol ...... 75 7.3. Freeradius Configuration ...... 76 7.4. Cisco ASA 5505 Configuration ...... 77 7.5. Sample Run ...... 77 Chapter 8 Summary and Conclusions ...... 79 8.1. Attack Vectors, Authentication Methods and Threat Assessment ...... 79 8.2. Suggested Authentication Method ...... 79 8.3. Implementation and Deployment ...... 79 8.4. Future Work ...... 80

Bibliography: ...... i

Appendix I: Usability Evaluation Instruction ...... ix Appendix II: Usability Evaluation Questionnaires ...... xix

Appendix III: Configuration of the Cisco ASA 5505 ...... xxv

viii Nomenclature

ASA Cisco Adaptive Security Appliance CA Certification Authority CDC Connected Device Configuration CLDC Connected Limited Device Configuration DoS Denial of Service HMAC Secure Hash based Message Authentication Code HOTP HMAC‐Based One Time Password Algorithm HTTP Hypertext Transfer Protocol IETF Internet Engineering Task Force MAC Message Authentication Code MIDP Mobile Information Device Profile MVC Model View Controller NAS Network Access Server NIST National Institute of Standards and Technology OTP One Time Password OTPW One Time Password Login Package PKI Public Key Infrastructure SATSA Security and Trust Services API SE Security Element SITIC Swedish IT Incident Center SSL/TLS Secure Sockets Layer/Transport Layer Security SUS System Usability Scale TC Trusted Computing TCG Trusted Computing Group TPM Trusted Platform Module VPN Virtual Private Network

Figures

All figures are drawn by the author unless otherwise stated in figure captions.

Figure 1: Certificate chain of a SSL/TLS certificate ...... 8 Figure 2: The SSL/TLS handshake process ...... 9 Figure 3: SSL/TLS Record Protocol ...... 10 Figure 4: A hardware keylogger to be mounted inside a keyboard casing ...... 18 Figure 5: Opportunity for eavesdropping when bouncing via an external server ...... 20 Figure 6: Man in the middle attack scheme ...... 21 Figure 7: Attacker executing a session hijacking attack ...... 22 Figure 8: One time pad from the Swedish bank Skandiabanken ...... 28 Figure 9: One time pad generated with OTPW ...... 29 Figure 10: Generation of a short time valid one time password ...... 30 Figure 11: Generation of short time valid password ...... 32 Figure 12: First part of a man in the middle attack ...... 35 Figure 13: Second part of a man in the middle attack ...... 35 Figure 14: SSL/TLS handshake process utilizing client authentication ...... 36 Figure 15: SSL/TLS authentication using a hardware token ...... 37 Figure 16: The Internet protocol stack extended with SSL/TLS ...... 39 Figure 17: Workflow of “Secure web authentication with mobile phones” ...... 40 Figure 18: Flow of secured data (bi‐directional) using camera‐based authentication ...... 41 Figure 19: Prototype main screen ...... 47 Figure 20: Prototype showing a one time password ...... 47 Figure 21: Prototype login form ...... 47 Figure 22: Participants’ report of easiness to generate OTP:s using the prototype ...... 48 Figure 23: Frequency distribution of SUS scores for 129 conditions from 50 Studies ...... 49 Figure 24: Participants’ report of easiness to open applications menu ...... 50 Figure 25: Share of users preferring Smokey vs. standalone token ...... 50 Figure 26: Users’ password format preferences ...... 51 Figure 27: Alphabet used to convert output to base‐32 ...... 51 Figure 28: Initialization protocol ...... 63 Figure 29: Synchronization protocol ...... 66 Figure 30: ER‐diagram of backend database ...... 68 Figure 31: Alternative database design allowing several tokens for each user ...... 69 Figure 32: ER‐diagram of Figure 30 mapped to relations ...... 69

xi Figure 33: Inefficient solution when few ID:s are free ...... 70 Figure 34: Efficient loop‐free solution ...... 70 Figure 35: Hierarchic organization of server components ...... 71 Figure 36: UML diagram of the classes: Smokey, Model and Storage ...... 72 Figure 37: UML‐diagram of view classes ...... 73 Figure 38: Authentication using Radius ...... 76 Figure 39: Web based VPN login ...... 77 Figure 40: Any Connect VPN client login ...... 77

xii Tables

Table 1: Assessment of applicability of social engineering attacks towards OTP:s ...... 34 Table 2: Assessment of applicability of eavesdropping attacks towards OTP:s ...... 34 Table 3: Assessment of applicability of social engineering attacks towards PKI ...... 39 Table 4: Comparison chart ...... 43 Table 5: Overview of candidate authentication methods ...... 46 Table 6: Recommended clock window, counter window and throttling parameters ...... 53 Table 7: Requirement specification ...... 57 Table 8: Detailed key exchange protocol ...... 65 Table 9: Detailed synchronization protocol ...... 67 Table 10: Organization of server code ...... 71

xiii

Chapter 1 Introduction

This chapter provides a short background and purpose of this master thesis as well as a description of the methods used, the delimitations and a short outline of the upcoming chapters.

1.1. Background Authentication is the process of “confidently associate an identity with a person” [1]. In order to authenticate different sets of credentials are used. Gollmann [2] defines credentials as “security evidence”. For example, in a password based authentication the credentials are made up from the combination of user ID and password.

Numerous services on the Internet require users to authenticate themselves before access is granted. This holds for a wide spectrum of services ‐ from the discussion of hobbies on forums to the management of personal or business economy. Authentication is a key element in keeping sensitive data confidential and protected from unauthorized modification.

Designers of networked applications need to consider several threats towards authentication mechanisms, but must not forget to consider usability. The strength needed for an authentication mechanism varies with the personal and financial value of different kinds of information and must be in proportion with the load that is put on the users of the authentication mechanism.

1.2. Definition of Problem At Linköping University administrators and technicians use Virtual private network (VPN) clients to securely access IT systems within the university’s protective domains. Authentication mechanisms for using the VPN are based on a traditional password shared with several systems. All users of VPN services are instructed to keep their home computers fully patched with security updates and have updated antivirus software installed. However it cannot be guaranteed that the users follow these rules and some concerns have been raised regarding the sensitivity of VPN access. The users’ client computers are therefore, in general, regarded as untrusted1.

Studying authentication in this context entails the following problem statements:

Problem statement 1: Which authentication method would be suitable for use by employees at Linköping University (or any similar organization) accessing the organization’s network via VPN considering security and usability?

1 For definition of untrusted clients see Section 2.5.

Problem statement 2: How can we implement this authentication method and deploy it on a commercial VPN appliance, still maintaining an acceptable level of usability?

The first problem statement can be decomposed into further questions:  Which authentication methods are offered and how well do they protect against known attacks?  Which attacks exist towards authentication today?  How can we rank methods according to offered security? 1.3. Method In order to answer the first problem statement defined above we will study common authentication methods and propose a generic method to rank these methods according to the offered level of security. To support the ranking we will enumerate known attack vectors and propose a set of unbiased principles for classification of attack vectors. The classification will reflect the level of competence and effort needed for an attacker to successfully accomplish the use of each attack vector. The enumeration of authentication methods and attack vectors will emanate from a litera‐ ture study.

Utilizing a threat assessment of each presented authentication method we will carry out the ranking according to the proposed method. With this ranking as a base we will suggest an authentication method aiming to answer the second problem statement.

Furthermore, in order to provide answers to the second problem statement we will propose a proto‐ type of an application implementing of the suggested authentication method. Using this prototype we will conduct a usability analysis and finally present a full implementation of the system as well as a reference deployment utilizing a VPN appliance from Cisco Systems.

1.4. Delimitations In order to achieve a deeper focus on authentication mechanisms actually suitable for authentica‐ tion on the Internet from untrusted clients we have chosen to exclude biometric mechanisms. Due to the risk of replay attacks biometric methods are better suited for local deployment. A base secret is required to mitigate this threat, which more or less would turn the biometric device into a hard‐ ware token. [1] Such appliances are available but since biometrics, in the author’s opinion, cannot stand on their own in a remote and untrusted environment we opt not to investigate biometrics further in this thesis.

1.5. Target Audience The intended readers of this thesis are persons with a background in computer science who are fa‐ miliar with essential computer security. Chapter 2 provides background necessary for readers who lack knowledge of these concepts.

2 1.6. Outline The thesis is outlined as follows:

Chapter 1 presents the background, motivation, problem statements, methodology and delimita‐ tions of this thesis.

Chapter 2 provides background knowledge introducing computer security concepts and a basic presentation of Java ME.

Chapter 3 enumerates and classifies prominent attack vectors towards authentication.

Chapter 4 proposes a method for ranking of authentication methods. The chapter also contains a presentation of various authentication methods as well as a threat assessment of each authentication method presented. Finally the full ranking of the discussed authentication methods is presented.

Chapter 5 suggests a suitable authentication method, based on the ranking performed in Chapter 4. Furthermore, a usability analysis of a prototype implementing this method is proposed. The chapter will also discuss new attack vectors entailed by the suggested implementa‐ tion.

Chapter 6 discusses details on design and implementation of the application proposed in Chapter 5.

Chapter 7 presents a reference deployment utilizing an authentication server backend and a VPN appliance from Cisco Systems.

Chapter 8 summarizes the thesis and discusses possible further work.

Chapter 2 Background

This chapter gives a brief introduction to some computer security concepts necessary to compre‐ hend the rest of this thesis. A short presentation of the key concepts of Java Micro Edition (Java ME) is also provided. Experienced readers may skip to Section 2.5.

2.1. Cryptography Basics In order to understand the core concepts of Secure Sockets Layer/Transport Layer Security (SSL/TLS), presented in Section 2.2, some basic insight in cryptography is necessary. This section will focus on what cryptography can accomplish but will not go into details on algorithms or how cryptography is successfully carried out.

2.1.1. Secure Hash Functions A hash function takes an arbitrary integer (or string represented as an integer) as input and returns an integer of a defined interval [3]. As an example; defining a positive integer m we could define the hash function p as: p k a k modm k 2 Zà,pkà2 0,m @ 1 àBC A secure hash function is a hash function with the following additional properties [4]:

Assuming h is a secure hash‐function it is easy to compute y  h x `a but given y it is computationally infeasible to find an x . such that . y h x `a It should also be infeasible to modify x without modifying y. Furthermore it should be infeasible to find two different values for x, which generates the same output y of the hash function. The output of a secure hash function is often called the digest [5] or message digest [2] of the input.

An example of a secure hash function is the Secure Hash Algorithm‐1 (SHA1) [6], which generates a 160 160‐bit output; that is hSHA1 k 2 0,2 @ 1 . Secure hash functions have applications in several BC authentication algorithms that`a will be discussed in this thesis.

5 2.1.2. Message Authentication Codes In order to verify the integrity of messages a Message Authentication Code (MAC) can be used. A MAC takes a shared secret key, K, and a message, m, as argument and outputs a value in a given 160 interval, for instance 0,2 @1 . Ideally the output of a MAC should be a random mapping from all BC possible inputs to an output in the given interval. [7]

Let us illustrate this with an example. Assume two participants, Alice and Bob. Alice is about to send a secret text to Bob over the Internet. Since Alice wants Bob to be able to verify the integrity of the text Alice sends both the text t and mac(K,t). K is secret to Alice and Bob (and must thus not be exposed to anyone else). Using K and the MAC‐function Bob may calculate mac(K,t) and compare its output with the expected MAC sent by Alice. If there is a mismatch the message has been tampered with.

Secure hash functions may be the base for the construction of MACs. RFC 2104 [8] defines the secure hash based message authentication code (HMAC) function hmac as:

hmac K,m  hKL opad || hKL ipad || m bcbcdebc where K is a secret key (possibly padded with zeros to fulfill properties of the hash function used) h is a secure hash function (e.g. MD5, SHA‐1) opad and ipad are constants as defined in RFC2104 L denotes bitwise XOR || denotes concatenation.

In this thesis MACs and HMACs will be used when describing a variety of protocols.

2.1.3. Symmetric vs. Asymmetric Cryptography There are two main classes of encryption algorithms; symmetric and asymmetric. In symmetric algo‐ rithms the same key is used for encryption and decryption (or the decryption key is easily calculated from the encryption key) [4]. Suppose we once more have two participants, Alice and Bob, who wish to communicate securely. Using symmetric encryption Alice and Bob must agree on the key; for instance Alice might generate the key and send it to Bob. If the key is compromised (e.g. copied) by a third participant, Eve, she will be able to decrypt all messages sent between Alice and Bob.

Using asymmetric encryption algorithms, also known as public key encryption algorithms, different keys are used for encryption and decryption. Even though the keys are related it should be computa‐ tionally infeasible to extract the private key from the public key [2]. If Alice wants to send an encrypted message to Bob using public key encryption, she only needs to encrypt the message using Bob’s public key. Bob’s public key is not secret; it can for instance be posted on his web site.

A challenge when using public key cryptography is to know which key to trust. Consider again that Eve wants to listen in on Alice’s and Bob’s communication. If Eve can trick Alice to believe that Eve’s public key belongs to Bob, Eve will be able to decrypt messages encrypted with this key. Determining the authenticity of public keys is an important issue when using public key cryptography; this will be discussed further in Section 2.1.5.

6 2.1.4. Digital Signatures Digital signatures can be implemented in a scheme similar, but not identical, to public key encryp‐ tion. We will not go into details on any of the many algorithms that can be used to realize digital signatures but will cover the main concepts.

Assume again participant Alice. Alice wants to post a message and prove its authenticity. In order to accomplish this Alice needs a private signature key and participants authenticating the signature need Alice’s public verification key.

When Alice wants to sign her message m, she uses her signature key sig to create the pair: m, sig m bc`a Anyone authenticating the signature needs Alice’s verification key verify to carry out the process: verify m, sig m  t, t 2 good , bad bc`a RS In order to support higher efficiency and compress the signatures, Alice can create a digest of the message by first hashing it through a secure hash function h. Alice will now post the pair:

m, sig h m de bcà If the requirements of the secure hash functions are met it is infeasible to find a message such that hm. hm. Note that for a signature algorithm to be successful it must also be infeasible to constructà sig(m)à without access to the private signature key.

Still the problem of knowing which keys to trust remain; how can we be sure that Alice’s verification key is indeed correct? This is the topic of the next section.

2.1.5. Certification Authorities In order to solve the problem of which keys to trust, one can let a third party vouch for the authen‐ ticity of a public key using certificates. Gollmann [2] defines a certificate as “a digitally signed docu‐ ment that binds a subject to some other information”. Using the examples above a certificate may bind Alice (the subject) to her public encryption or verification key. The issuer of a certificate (the entity who signs the certificate) is called a Certification Authority (CA). If we trust the CA and have access to the CA’s public verification key we can extract Alice’s public keys from the certificate and verify their authenticity.

In order to verify the certificate we must trust the CA’s verification key. If we do not trust this key directly a fourth party, which we trust, may vouch for the verification key using a certificate. This process can be repeated and creates a chain of certificates. Ultimately, we must have access to a verification key that we simply trust. Such a key is called a root verification key.

A certificate providing a root verification key signed with the corresponding signature key is called self signed and constitutes a root certificate. A set of root certificates are included in most web browsers. These certificates are in practice vouched for by the producer of the operating system or web browser used.

7 Figure 1 below illustrates the concept of certificates by presenting the certification chain used to verify that the certificate of https://www.liu.se indeed belongs to Linköping University. Note that the last certificate (Add Trust External CA Root) is self signed.

Certificate

cn: www.liu.se Certificate O: Linköpings universitet Key ID: c0 d0 ao.... Certificate cn: TERENA SSL CA Key ID: 0c bd 93... cn: Certificate Signed by TERENA SSL CA UTN-USERFirst-Hardware using key: 0c bd 93... cn: Signed by Key ID: a1 72 5f... AddTrust External CA Root UTN-USERFirst-Hardware using key: a1 72 5f... Signed by Key ID: ad bd 98... AddTrust External CA Root using key: ad bd 98... Signed by AddTrust External CA Root using key: ad bd 98...

Root certificate

Figure 1: Certificate chain of a SSL/TLS certificate 2.2. SSL/TLS Secure Sockets Layer (SSL) was introduced by Netscape in the mid 1990’s to facilitate confidentiality and integrity of network traffic, particularly of WWW‐traffic [9]. The final version of SSL, version 3.0, provided the basis of the Transport Layer Security protocol (TLS) maintained by the Internet Engineering Task Force (IETF) since 1999 [10]. The current version of TLS, version 1.2, is still very similar to SSLv3, but supports extensions and several more algorithms than previous versions.

When a SSL/TLS connection is set up communication between peers is handled by the SSL/TLS Record Protocol. The Record Protocol is responsible for compression, application of a MAC and encryption of payload data.

TLS can be used for public key authentication of the peers involved in the communication. The most common case is authentication of the server by the client using certificates. Authentication of the certificate and setup of parameters needed by the Record Protocol is done during the handshake phase using the SSL/TLS Handshake Protocol, described and illustrated in Section 2.2.1 below.

2.2.1. SSL/TLS Handshake Protocol The SSL/TLS Handshake Protocol is used to (optionally) authenticate the server and the client and set up a master secret used for later generation of keys to encrypt and authenticate payload handled by the Record Protocol. An overview of the SSL/TLS Handshake Protocol is illustrated in Figure 2 below and described in detail in the rest of this section.

8 Client Server CLIENT HELLO: -SSL/TLS Version -Random 1 -Session ID -Cipher list -Compression list SERVER HELLO: -SSL/TLS Version -Random 2 -Session ID -Cipher -Compression SERVER CERTIFICATE SERVER KEY EXCHANGE CLIENT KEY SERVER HELLO DONE EXCHANGE -pre CHANGE CIPHER SPEC E(CLIENT FINISHED)

CHANGE CIPHER SPEC E(SERVER FINISHED)

Figure 2: The SSL/TLS handshake process

Step 1. Client to server: CLIENT HELLO The TLS connection is initiated by the client, by sending a CLIENT HELLO message to the server. The CLIENT HELLO message contains the following parameters: 1. Version of SSL/TLS the client wishes to use. 2. RANDOM1, a random nonce (random value used once), chosen by the client. This nonce will be used as an ingredient in the making of the shared secret. 3. Session ID, 0 if the client wishes to establish a new session. 4. Cipher list, a list of ciphers supported by the client. 5. Compression list, a list of compression methods supported by the client. Both the entries in the cipher list (4) and the compression list (5) is ordered by the client’s preferences.

Step 2. Server to client: SERVER HELLO and others Upon receiving the CLIENT HELLO message, the server responds by a SERVER HELLO message. This message is formatted much similar to the CLIENT HELLO message, containing the following: 1. SSL/TLS version that will be used for the rest of the session’s communication. This is decided by the server’s abilities and the client’s wishes in the previous step. 2. RANDOM2, a random nonce, chosen by the server, later to be used in the shared secret. 3. The server will choose a cipher for the communication that is supported by both the server and the client and that has the highest precedence as indicated by the client. 4. The server will choose compression method for the communication. As with the cipher, the server chooses among the methods supported by the client.

Immediately following the SERVER HELLO message the server will deliver its certificates in a SERVER CERTIFICATE message.

9 Depending on which cipher method that is used and the contents of the server certificate, the server might next send a SERVER KEY EXCHANGE message, initiating the creation of the keys used for the encrypted communication. The server now hands over initiative to the client by sending a SERVER HELLO DONE message.

Step 3. Client to server: CLIENT KEY EXCHANGE and others Unless client certificates are used (see Section 4.4) the client now establishes the final ingredient of the master secret, calculating a pre master secret and encrypting this with the server’s public key.

Both parties now have the necessary information to encrypt data to send and decrypt data received. The client now sends a CHANGE CIPHER SPEC message. This message indicates that from now on the client will use the agreed encryption method with the established parameters.

The client finalizes its round by sending a CLIENT FINISHED message (encrypted since this mes‐ sage follows the CHANGE CIPHER SPEC).

Step 4. Server to client: CHANGE CIPHER SPEC and others The server also has the necessary information to perform encryption and decryption of the traffic. It confirms this by sending a CHANGE CIPHER SPEC and a (encrypted) SERVER FINISHED mes‐ sage. This is the last step of the handshake.

2.2.2. SSL/TLS Record Protocol After the handshake is completed transfer of payload data can begin. The TLS Record Protocol has four main tasks before transmitting data further by use of the TCP:  Fragmentation  Compression (optional)  Application of a MAC  Encryption

Algorithms and keys used for these tasks depend on agreed parameters during the handshake. The workings of the SSL/TLS Record Protocol are illustrated in Figure 3 below.

Figure 3: SSL/TLS Record Protocol Figure based on an illustration by Bishop [9]

10 2.3. Threats and attack vectors The words threat and attack are used with different definitions. In this thesis the word threat is used according to Bishop’s definition: A threat is a potential violation of security [9]. Furthermore Bishop uses the word attack to describe an action that can lead to an instantiation of a threat, that is; the actual violation of security. We will use the word attack vector to describe means or methods to execute an attack.

2.4. Malicious Software (Viruses, Worms, Trojan Horses and Rootkits) The exact definition of malicious software (also known as malware or malicious code) differs some‐ what between stakeholders in the computer security industry. Since some actors [11] distinguish between malware and malicious code we will refrain from using the former term.

The author suggests the following definition based upon definitions available from numerous actors [12, 13, 14]: [12], [13], [14]

Malicious software (also known as malicious code, or abbreviated as malware) is a common name for all kinds of unwanted software such as viruses, worms, Trojan horses etc. This soft‐ ware is often designed to infiltrate or damage a computer system without the owner’s know‐ ledge or consent.

Viruses are generally acknowledged as programs requiring user intervention to spread [15]. They spread to other files on the infected computer but do not actively propagate themselves (i.e. a person needs to copy or send the infected file in order to spread the virus to other computers).

As opposed to viruses, worms actively spread themselves between computers, often using vulnera‐ bilities in operating systems or other software. Worms can also be spread by e‐mail or so called drive‐by‐downloads, where a vulnerability in the browser (or plug‐in) is used to infect a computer visiting a malware spreading web site [16]. The latter form of malware is often combined with phishing2 to get the user to visit the web site. It is open for discussion whether this behavior consti‐ tutes a virus or a worm but the nomenclature is of less importance for this thesis.

Trojan horses are software pretending to be something useful, but also bear a malicious part. For example an attacker could augment a popular photo editing software with code allowing him to get remote access to computers installing the software. By spreading the modified software on peer‐to‐ peer networks a great population can be reached and the receivers may spread the Trojan further believing they just share a great commercial application.

A rootkit is a collection of malicious software that aims to hide its existence from legitimate users of a system. For instance a rootkit can deploy its own version of the program ps (process status) that gives information about all running processes on a system except the ones concealed by the rootkit. Rootkits may also be implemented on kernel level [17] or as virtual machines [18].

2 Phishing is an instance of the social engineering attack vector, further discussed in Section 3.2.7.

11 2.5. Untrusted Clients vs. Trusted computers In this thesis we aim to identify suitable authentication mechanisms to provide secure authentica‐ tion from untrusted clients. The notion “untrusted clients” should not be confused with the concept of Trusted Computing (TC). In this section we will explain these notions further.

2.5.1. Untrusted Client Different stakeholders can have different perspectives on the confidence of a client’s computer and whether it should be regarded as trusted or not. For example, the author assumes his home com‐ puter (updated with the latest patches and well known antivirus program) is quite safe and indeed consider it as trusted. At the same time his bank wisely might assume that all connected users origi‐ nate from untrusted clients.

Deciding whether a client is trusted or not is hence a subjective declaration and must be put into context on the topic of what data we aim to protect. When choosing an appropriate authentication method not only its strength must be taken into account; usability and user acceptance must also be considered.

2.5.2. Trusted Computing Trusted Computing (TC) is an established term describing the concept of a hardware platform that prevents tampering with software. TC is promoted by the Trusted Computing Group (TCG), which consists of well known corporations in the computer industry such as Intel, Microsoft, IBM, HP, Sun and many more. [19]

TCG suggests implementation of TC by a Trusted Platform Module (TPM), which is a special chip attached to the motherboard or integrated in the computer’s CPU. The TPM will enforce policies regarding which operating system and software that should be trusted to execute on the computer. Furthermore, the TPM provides authentication mechanisms to let the software decide whether or not access to data per se will be allowed. Such policies enforced by cryptographic methods could for example prevent opening of classified word documents on computers outside an organization, or prevent playback of DRM‐protected media [20].

TC could be used to address the problem with malicious software (e.g. computer viruses, Trojan horses, root kits etc.) but is also controversial due to issues regarding privacy, censorship, DRM and supplier lock up [21].

Although TC would solve a lot of the issues presented in this text, we choose not to relate it to our definition of untrusted client. A trusted computer could be made untrusted (e.g. by attaching a hardware keylogger); vice versa we can have high confidence in a computer even though it is not a “trusted computer” in the definition of TCG.

2.5.3. What is Secure Authentication? If we presume that a particular client used in authentication is untrusted, we must assume that all data flowing through this client can be intercepted. Hence, it is not possible to protect the confiden‐ tiality of data. As will be shown in Chapter 4 it is possible to protect the login (so it cannot be used later on) and in particular protect isolated transactions from taking place.

When implementing any system containing sensitive data we must not disregard the confidentiality element. However, confidentiality is commonly reached by using SSL/TLS which we assume gives

12 sufficient protection given that the client can be trusted and the user is adequately skilled. All in all, in the upcoming evaluation of authentication methods focus will be put exclusively on data integrity.

2.6. Java ME Later on in this thesis we will touch upon Java Platform Micro Edition (Java ME), which will be our tool for developing the authentication method that will be suggested in Chapter 5.

Java ME is not a full specification of a programming language in itself. Depending on the type of device (smart card, cell phone, personal digital assistant etc.) different features are available.

Java ME is based on three parts:  Configurations  Profiles  Optional APIs

A configuration targets a wide range of devices. At the time of writing there exist two configurations. The Connected Limited Device Configuration (CLDC) is targeted to devices with limited memory, CPU power and other capabilities. The Connected Device Configuration (CDC) is targeted to more advanced devices like high end PDAs. A profile specifies a set of APIs targeting a specific family of devices. The most prominent profile is the Mobile Information Device Profile (MIDP). Most Java enabled cell phones implement CLDC+MIDP in addition to a set of optional APIs, some of them vendor specific [22]. Applications based on the MIDP profiles are often referred to as MIDlets. MID‐ lets are grouped into MIDlet suites [23].

When developing Java ME applications targeted to generic cell phones one should aim not to use vendor specific APIs. If it is not possible to avoid vendor specific function calls one must pay atten‐ tion to how the application will behave on different brands (or models) of cell phones.

2.6.1. Java ME API Access Control As of version 2.0 of the MIDP specification [24] access to certain sensitive APIs are restricted and regulated based on the concept of Protection Domains. An API might for instance be considered sensitive if a method call accesses private data or entails a cost of the device owner (e.g. a HTTP request issued on a cell phone utilizing per‐byte billing). A protection domain constitutes a set of permissions.

A MIDlet suite is tied to a specific protection domain when signed with an appropriate code signing certificate. A suite which is not signed at all or signed with a certificate issued by an unknown CA is considered untrusted and belongs to the untrusted protection domain.

The MIDP 2.0 specification suggests three protection domains in addition to the untrusted domain:  Manufacturer Domain  Operator Domain  Trusted Third Party Domain

MIDlet suites belonging to the manufacturer domain must be signed with a key validated to the manufacturer protection domain root certificate available in the mobile device. MIDlet suites belonging to the operator domain accordingly must be validated to the operator protection domain root certificate, typically available in the SIM card. Depending on the manufacturer, device model and operator different trusted third party protection domain root certificates are available.

13 Each restricted API may have its own set of permissions restricting which protection domains that should be allowed to use the API and whether the user should be prompted to allow the method call or not. [25]

The cost of code signing certificates in conjunction with lack of any standard set of CA root certifi‐ cates associated with the Trusted Third Party Domain can make it somewhat difficult to target a wide range of devices. Self signed certificates will not work since the MIDP specification explicitly states that new root certificates downloaded by the user must not be accepted when validating trusted third party applications [25].

2.6.2. Java ME Security and Trust Services API The Security and Trust Services API (SATSA) [26] constitutes an optional API available on some mobile devices. The API provides methods for cryptographic operations and access to Security Elements (SEs). A SE provides secure storage for sensitive data (e.g. private keys) and usually comes in the form of smart cards even though it is possible for the device manufacturer to integrate a SE in the device hardware. If properly prepared by the operator, the SIM card may be used as a SE. The device may also provide a dedicated slot for SE smart cards.

According to the API definition the use of the SE communication features provided by SATSA is restricted to trusted MIDlet suites (meaning applications must belong to the operator, manufacturer or trusted third party domain).

We opt not to use SATSA in the suggested implementation in order to support as many existing devices as possible.

14 Chapter 3 Attack Vectors

This chapter will provide an enumeration of the most prominent attack vectors against authentica‐ tion. The main purpose of this chapter is to support a ranking of different authentication methods provided in Chapter 4. In order to support this ranking each attack vector will be classified as basic, medium or advanced. These three levels represent an assessment of how much effort an attacker needs to put in and how skillful an attacker needs to be in order to successfully carry out each type of attack.

Attacks against the server side authentication software per se (e.g. a buffer overflow vulnerability in the handling of an authentication request) will not be included in this chapter. We acknowledge this as an extremely important aspect of the implementation of an authentication system but consider such vulnerabilities as generic problems that hold for any authentication method.

3.1. Classification of Attack Vectors As this chapter will show, there certainly exist many threats against IT systems relying on correct authentication of their users. When considering countermeasures against any IT security related threat one should weight costs of defense parameters to the expected damage and frequency of successful attacks (e.g. intrusions). This process may be performed in the form of a risk analysis. Analogous, an attacker may perform a similar analysis weighting the cost (effort) needed towards the pay off of a successful attack3.

The consequential damage of an intrusion is not always easily measured in financial factors. A clas‐ sical example is the question regarding how damage to a company’s reputation should be valued in financial terms. The analogous question may rise when considering countermeasures. What are the costs of employees or customers getting frustrated every time they use a complicated IT system (or a user friendly system requiring a user unfriendly authentication tool)?

The author believes that a fair ranking of authentication methods must consider the sophistication and effort needed of an attacker to successfully penetrate the method since these properties have impact on the likelihood of an attack. To simplify matters without losing context we define three categories of attack vectors; basic, medium and advanced. In the ranking each attack vector will be weighted in respect to how intricate it is to carry out.

3 Reasoning about security from the attacker’s perspective has great potential towards finding new threats. One method to systematically accomplish this is attack trees [85].

15 3.1.1. Active vs. Passive Attacks United States National Institute of Standards and Technology (NIST) defines an active attack as “an attack on the authentication protocol where the attacker transmits data to the claimant or verifier.” A passive attack is respectively defined as “an attack against an authentication protocol where the attacker intercepts data traveling along the network between the claimant and the verifi‐ er, but does not alter the data.” [27]

Active attacks are substantially more difficult and complex to perform than passive ones since they must occur in real time. In addition it is also easy to differentiate active attacks from passive ones; therefore we will use this concept for classification of attack vectors.

In order to make a more distinct categorization we will differentiate attack vectors that can circum‐ vent authentication without penetration of client, server nor the communication between them.

3.1.2. Definition of Attack Vector Classes We will consider attack vectors as basic if they hold all the following properties:  Attacks can be carried out without penetration of the computer used by the claimant  Attacks can be carried out without penetration of the communication between the claimant’s computer and the verifying server  Attacks are passive

We will consider attack vectors as medium if:  Attacks do not qualify as basic  Attacks are passive

Furthermore, we will consider attack vectors as advanced, meaning attack vectors belong to the advanced category if and only if:  Attacks are active 3.2. Basic Level Attack Vectors According to the definitions above (Section 3.1.2) the following attacks are classified as belonging to the basic level:  Guessing and dictionary  Brute force  Shoulder surfing  Password reuse  Keyloggers (implemented in hardware or software)  Passive social engineering We opt to categorize keyloggers belonging to this level since they can be installed by a legitimate user.

16 3.2.1. Guessing and Dictionary attacks For knowledge based authentication (see Chapter 4, i.e. passwords), the most basic approach to breach security is to simply try to guess the users’ passwords.

Users that are allowed to choose their own passwords often make weak choices; that is passwords with low entropy4. Even though IT systems may enforce their users to choose passwords with certain properties such policies do not guarantee good passwords. The Swedish IT Incident Center (SITIC), recommends passwords of “a minimum of 8 characters consisting of at least three of the following four classes of characters: upper‐case, lower‐case, digits and non‐alphanumerical characters” [28]. A system enforcing SITIC’s recommendation would still allow a naive user to choose say “Laura‐80” as password. This password might be relevant for an attacker to try if she knew that the user is married to a woman named Laura who is born in 1980. It should be mentioned that SITIC also advice against choosing passwords related to personal information, but such rules are much more difficult to enforce. Password guessing is commonly automated with the help of password dictionaries of which numerous are available on the Internet [29].

To defend themselves from automated attacks, systems can temporarily lock accounts after a certain number of invalid login attempts. Knowing that such procedures are in place however give attackers opportunity for Denial of Service attacks (DoS).

3.2.2. Brute Force Attacks The concept of brute force is inherited from cryptography where the term depicts the strategy of systematically trying every possible key in order to find a valid decryption (or encryption) key [4]. Analogous in authentication brute force refer to trying every possible password. The success of brute force highly depends on the password entropy. As with other automated attacks, locking pro‐ cedures can be applied to defend from these attacks.

3.2.3. Shoulder Surfing A rather direct approach when breaching knowledge based authentication is to wait for the claimant to input his password and pick it while it is entered. The most obvious and low‐tech approach is shoulder surfing, that is to watch when the user types (or in other way enters) the password. This is less fruitful if the attacker is not known to the claimant. If an attacker has physical access to the area where the password is entered a camera can be used to intercept the password. The latter is a common case in modern ATM skimming attacks [30].

3.2.4. Password Reuse When users are allowed to choose their own passwords it is common that the same password is reused in several systems. This is unfortunate since these different systems not necessarily reflect the same security requirements. There have been numerous attacks where passwords have been compromised as less protected systems have been penetrated; the compromised passwords have in some cases thereafter been used to attack much more sensitive systems. [31, 32, 33, 34]

[31][32][33][34]

4 Entropy denotes the level of uncertainty. High entropy will thus imply a password that is hard to guess or systematically search for.

17 Attackers can gain from the behavior of reusing passwords not only by compromising less protected systems, they can also set up Internet services requiring users to register and voluntarily give out their passwords (a form of social engineering).

3.2.5. Hardware Keylogger If the attacker can get undisturbed access to the claimant’s computer a hardware keylogger [35] can be installed. A hardware keylogger module can be installed between the keyboard and the computer or be made absolutely stealth by placing it inside the keyboard (see Figure 4 below).

Figure 4: A hardware keylogger to be mounted inside a keyboard casing

The hardware keylogger is especially difficult to notice since it cannot be detected by antivirus or anti spy‐ware software. Even the most cautious user that brings his computer home from office every day (or locks it up in a safe) may leave his keyboard unattended at his workplace and have a keylogger installed by a malicious coworker or someone else with physical access to the keyboard.

Commercial keyloggers are available and commonly have an integrated memory that can be accessed for example by mounting the keylogger as an USB drive [36]. One can imagine a hardware keylogger that transmits its contents wireless, but practical implementations of this are not known to the author.

From an attacker’s perspective there are some significant drawbacks of using hardware keyloggers; the attacker must have physical access to the victim’s computer or keyboard and there is a risk of exposure when installing and harvesting the keylogger. Depending on motivation of the attacker the cost5 related to each keylogger unit may be discouraging.

3.2.6. Software Keylogger Keyloggers can also be implemented in software [35] making the cost per installation insignificant and allowing capturing of data to be performed over the Internet. Software keyloggers can be purposely installed by any legitimate user having administrative privileges but may also arrive as malware or be installed with the help of a computer intrusion.

Apart from logging key strokes a software based logger may also take screen captures at chosen times (e.g. on every mouse button down event) in order to bypass on screen passwords (see Section 4.2.2).

5 At the time of writing (December, 2009) commercial keyloggers were available for about €30 [36].

18 3.2.7. Social Engineering Strong passwords are hard to guess and infeasible to brute force, so why not just ask the user to give his password away? This is one application of social engineering [37]; a group of techniques that builds upon deceiving and manipulating users to give away information they are not supposed to give away. An extensive collection of methods is provided by former black‐hat Kevin Mitnick in the book Art of deception: Controlling the Human Element of Security [38]. Mitnick focuses primarily on human‐to‐human contacts like phone or personal visits.

Human‐to‐human contact seems to be the most efficient social engineering technique for targeted attacks. To reach a broader mass of victim phishing [39] (social engineering by e‐mail) is more effec‐ tive since it is so easy (and cheap) to send unsolicited email that have a genuine look.

Even badly performed attacks, for example e‐mails that do not have an authentic look and contains a lot of spelling errors, seem to be accepted by a small percentage of the receivers [40]. Even a slight fraction of targets falling for an attack can give high outcome if the targeted population is large enough.

Besides tricking users to give out their passwords or other personal information, phishing can be used to spread malicious code used for keylogging or even more advanced attacks. This could be done either by exploiting vulnerabilities in the mail application, include malware as attached files or supplying a URL where a drive‐by‐download [16] is performed.

Passive forms of phishing and other forms of social engineering can be mitigated using authentica‐ tion data (i.e. one time passwords) with a short time span of validity. Social engineering could however be applied as an active attack where the attacker immediately uses the credentials cap‐ tured. When we perform the ranking in Chapter 4 both passive and active social engineering will be accounted for.

3.3. Medium Level Attack Vectors According to our definition in Section 3.1.2; attack vectors that are passive but not qualify as basic are defined as medium. This holds for the following attack vectors:  Theft of credentials by intrusion  Passive eavesdropping of network traffic 3.3.1. Theft of Credentials by Intrusion Some credentials can be stolen from the computer used by the claimant. For example passwords can be cached in memory and software SSL/ TLS certificates (see Section 4.4.1) are stored on the user’s computer, easily copied by an attacker with full access to the computer’s file system.

3.3.2. Eavesdropping of Network Traffic Eavesdropping (also known as sniffing) of network traffic is an attack vector that can be applied if the attacker has access to the network at some point between the claimant and the server and if the authentication is not encrypted. Even if the traffic is encrypted eavesdropping can be successful if the encryption algorithm is weak or the encryption keys used are compromised.

To prevent from eavesdropping authentication is commonly deployed over SSL/TLS. It is important to note that SSL only offers protection as long as the users do not accept fake certificates in which case a man in the middle attack (see Section 3.4.1) can be performed. Unfortunately it is common

19 that users do not understand the principles behind SSL, which makes it rather easy to find users willing to accept fake certificates [41].

Also note that the use of SSL adds very little security if the attacker has gained full access to the claimant’s computer in which case it is trivial to replace the SSL‐stack with a modified version that allows eavesdropping on unencrypted data.

Eavesdropping may occur here! User

ssh ssh server

ssh

Internet Firewall Firewall DMZ Internal network

Figure 5: Opportunity for eavesdropping when bouncing via an external server

The most serious threat of eavesdropping emerges when using an intermediate server to ‘bounce’ a remote login. The motivation for such behavior can be either laziness or practical. Figure 5 above illustrates this phenomenon with the following example: A user wants to connect to a secure shell (ssh) server residing on the internal network, but access to this server is prohibited by the firewalls. The web server, residing in the demilitarized zone (DMZ), however accepts ssh connections, and the requested ssh server accepts ssh connections from within the DMZ. The user can fulfill his task by first logging in on the web server and from there initiating a new ssh session to the ssh server. The web server, if it has vulnerabilities, now has become an excellent point to harvest user passwords.

3.4. Advanced Level Attack Vectors According to our definition in Section 3.1.2 all active attack vectors are defined as advanced. This holds for the following attack vectors:  Active social engineering  Active eavesdropping of network traffic  Man in the middle  Man in the browser  Session hijacking

20 3.4.1. Man in the Middle Man in the middle attacks constitutes a quite large group of very potent attacks. The basic principle is to get the claimant to connect to the attacker instead of the legitimate server without the claimant noticing this (see Figure 6 below). When the attacker is in place in the middle of the traffic flow she can capture authentication data and use it to authenticate herself. [42] For instance if the claimant is about to perform a transaction using web banking the attacker can reside passive in the network flow until the time that the claimant enters an account number that money should be sent to. At this time the attacker can simply replace the account number with her own.

Attacker

Client Server

Figure 6: Man in the middle attack scheme

In order to be useful for the attacker, the forwarding of network traffic must reside on the application level. It is not sufficient to just forward the TCP stream since the traffic most probably will be encrypted with SSL. To achieve this, the attacker faces three challenges: 1. Redirect traffic so that it passes the attacker 2. Decrypt SSL traffic without the claimant noticing 3. Encrypt SSL traffic without the server noticing

Man in the middle attacks are trivial to carry out if the claimant’s computer has been broken into. In this case it is sufficient to alter the local hosts file to direct connections to the attacker and install a self signed certificate in the web browser to disable SSL/TLS‐warnings.

If penetration of the user’s computer is infeasible, attacks can be directed towards the DNS server using techniques like DNS spoofing or DNS cache poisoning. The effect of such attacks will be forged replies to DNS queries sent by the claimant. [43]

A less sophisticated option is to register a DNS name similar to the target server’s name. This can be used on its own catching claimants who misspell the DNS name. The attack can also be used in conjunction with phishing. Users are more probable to follow a link they recognize, but may not discover the difference between the correctly spelled domain name mysecretbank.com and the following variants:  mysecrentbank.com  my.secretbank.com  mysecretbank.org  mysecret‐ bank.com/loginsecure.asp?id=8392cxmc2223455nhczzjhjasdnasxzhasjkdhajskdhaskcxkzxxzz [email protected] (the real domain here is “somethingphishy.com”; the characters preceding the @‐sign will be interpreted as login data)

21 Other ways to perform man in the middle attacks include router table manipulation in order to redirect traffic to the attacker by manipulating the infrastructure of the claimant’s local network. Yet another option is for the attacker to supply her own WLAN evil twin access point [44], which can be configured to redirect traffic destined to the target web site or simply deliver a forged DNS server through DHCP.

3.4.2. Man in the Browser A man in the browser attack works similar to a man in the middle attack. Traffic flow can be altered in real time making the user authenticate forged transactions. However the man in the browser attack is localized to the user’s own computer by manipulating the web browser. The browser can for instance be attacked by replacing dynamic libraries (e.g. DLL‐files) and browser extensions [45]. The malicious browser code can be installed the same way as any malware (see Section 2.3).

3.4.3. Session Hijacking In a session hijacking attack the attacker aims to take over the session established between two parties [42]. If a claimant is authenticated and his session is hijacked, the attacker can appear as the claimant. Session hijacking originally referred to TCP sessions [46], for which SSL/TLS is designed to offer protection [10]. Session hijacking is however applicable to other network layers as well. In particular cookie based HTTP session management [47] may be vulnerable [48].

User Server 1. Login

2. Cookie

r 3 e . s S u te a s l a 4 c r . o a D o e o k p S i p e A . 4

Attacker

Figure 7: Attacker executing a session hijacking attack

Figure 7 above illustrates an example of a session hijacking attack. When a user logs in to the web site provided by the server a cookie is assigned to identify the user in upcoming requests. If an attacker is able to steal the cookie for example through a cross site scripting attack [48], he can use the server and appear as the user. If the server defends against session hijacking by disallowing simultaneous requests, the attacker can execute a denial of service attack against the user.

In order to defend itself from this attack the server can store the IP address of the claimant and associate this with an identifier of the session cookie. This will make the attack significantly harder to perform since the attacker must now also forge his IP address in order to succeed with the attack. A conclusion from the above is that this attack vector is not related to the authentication method per se but rather to the session management of a connection. We therefore opt not to include it in the upcoming comparison of methods.

22 3.5. Other Attack Vectors Additional attack vectors not mentioned so far are physical theft and attackers threatening users to give away their credentials. Both of these attack vectors are relevant when designing for ultimate security. We consider all authentication methods to be vulnerable towards these attacks. Passwords may be written down and these notes may be stolen. Tokens (one time password generators, cell phones, smartcards etc.) may all be stolen. This threat can be mitigated to some extent by PIN code protection. We need to be aware of these attack possibilities, but opt to not include them in the upcoming ranking of authentication methods since we believe all methods presented to be vulnera‐ ble to about the same extent. Furthermore we consider design of systems to minimize impact of blackmailed employees or malicious users to be beyond the scope of authentication and this thesis.

Chapter 4 Authentication Methods

This chapter provides an overview of some current authentication methods as well as some methods proposed by the research community. For each method an assessment is made on how well it holds up to the attack vectors enumerated in Chapter 3. Finally a ranking of all the methods is carried out.

Traditionally authentication methods have been classified into the following three groups [2]:  Knowledge based – something you know  Token based – something you have  Biometrics based – something you are

Sometimes location ‐ where you are – is defined as a fourth group of authentication [9]. As stated in Section 1.4, biometric authentication methods will not be considered in this thesis.

4.1. Threat Assessment and Ranking of Methods In absence of any established process assessing authentication methods with respect to threats the following approach will be used:

For each method the applicability of every enumerated attack vector will be assessed. We define applicabilityv,m as the applicability of attack vector, v, on authentication method, m. Applicabil‐ ity will be assessed`a on a scale from 0 to 3 (interpreting as 0 = insignificant, 1 = low, 2 = medium and 3 = high). Stating that passive social engineering is fully feasible when attacking traditional password would thus result in high applicability; hence applicability passivesocialengineering, password  3 bc Each authentication method/attack vector pair rating will be weighted according to the classification of the attack vector as presented in the Chapter 3. Basic level attack vectors will be weighted 3x, medium level 2x and advanced level attack vectors will be weighted 1x. For each method the total score will be summarized as:

Score m  X weight v Bapplicability v, m àattackvector, v à à For example, passive social engineering is classified as a basic level attack vector. Hence; the contri‐ buting score of the example above would be:

, 339

25 The resulting ranking should be interpreted with caution. We therefore do not suggest that it can be used to conclude that method x is exactly n times as good as method y. We do however aspire to conclude that method x is stronger or weaker than method y without quantifying the difference.

In the following presentation each category of authentication methods will be followed by a threat assessment. The summarized threat assessment and ranking is presented in Table 4 (see page 43).

4.2. Knowledge Based Authentication Knowledge based authentication embrace all authentication methods based on some secret infor‐ mation. In optimal circumstances this information should be unknown to all but the entity that is to be authenticated.

4.2.1. Passwords Passwords as a method for authentication on computers have been around since the early 1960s when the first time‐sharing systems where introduced [1]. Still today password authentication is by far the most common authentication method [49].

Passwords are easy to deploy and well recognized by users. Passwords however have several weak‐ nesses when it comes to security. It tends to be hard to get users to choose passwords with good entropy [50] and even when users choose good passwords these are often written down. Another significant problem with passwords is that it is common for users to reuse the same password on different systems [51].

Furthermore, keylogging is one of the rudimental threats we can expect on a computer infected with malware. Keylogging can also be performed with legitimate software installed by the computer’s owner, or be made absolutely stealth using a hardware keylogger.

4.2.2. On Screen Mouse Entered Passwords Since passwords are so easily intercepted with hardware keyloggers or with keylogger malware there have been suggestions to attend this threat by the implementation of on screen keyboards. An on screen keyboard forces the user to input his password using only the mouse, circumventing any keylogger attached to the keyboard or keylogger software. The use of on screen keyboards was implemented by Citibank UK in 2005 [52].

Although the method with on screen passwords makes it somewhat harder to intercept the pass‐ word, it only mitigates the most basic threats and hardly attacks that are targeted towards specific web sites. There are Trojans, like W32/Dumaru [53], which are able to capture a piece of the screen surrounding the mouse pointer at each click. Other methods interact with the web browser API to capture entered characters in a more direct manner [54]. Not only does this method add very little defense towards malware, the problem with shoulder surfing is much more considerable when a password is entered this way.

26 4.2.3. Threat Assessment The assessment below is based on our findings shown above and in Chapter 3. For a more concise overview the reader is refereed to Table 4 on page 43.

Guessing and Dictionary attacks User chosen passwords with low entropy are subject to guessing attacks. These attacks can to some extent be mitigated with the enforcement of a password policy requiring the use of a good mix of characters, numbers and special characters and a certain length of the password. As long as users have the possibility to choose their own passwords it is infeasible to fully cover for the risk of guess‐ able passwords. We therefore consider this attack vector to have a medium level of applicability for all knowledge based methods.

Brute Force Attacks Brute force search of passwords can be mitigated by the combination of a password policy enforcing appropriate entropy and a mechanism for ‘slowing down’ systematic attempts to test passwords. The latter kind of mechanism may however be used for DoS attacks. When assuring sufficient pass‐ word entropy or using available countermeasures we consider this attack vector to have low appli‐ cability for all knowledge based authentication methods.

Shoulder Surfing Shoulder surfing is applicable to all knowledge based authentication methods. We consider on screen entered passwords to be more exposed than passwords typed using the keyboard since one can follow each click easier than shoulder surfing of a keyboard input. Hence we consider this attack vector to have medium applicability towards traditional passwords and high applicability towards on screen passwords.

Password Reuse The problem with password reusing is applicable to all knowledge based authentication methods. Even if the user herself is not allowed to choose passwords, an assigned password can be used at other unrelated systems. Practical examples have shown that compromise of less secured systems unleash attacks on much more critical systems using this attack vector. We therefore consider this attack vector to have high applicability towards all knowledge based authentication methods.

Hardware Keylogger Commercial hardware keylogger solutions, which store every key stroke of a keyboard are available. We have not found any hardware keylogger solution targeting on screen input and therefore consid‐ er this method to have high applicability towards traditional passwords and insignificant applicability towards on screen passwords.

Software Keylogger Keylogging software targeting both keyboard and mouse based input is available. We therefore consider this attack vector to have high applicability towards all knowledge based authentication.

Theft of Credential by Intrusion Some software (e.g. web browsers) may cache passwords, other software may cache used pass‐ words in memory and leave passwords in memory until overwritten or computer is powered down. The first method can be mitigated by the user simply denying the browser to store passwords. The

27 latter method may be mitigated by software developers. We therefore consider this attack vector to be applicable on a medium level for all knowledge based authentication methods.

Other Attack Vectors We consider all other attack vectors enumerated in Chapter 3 to be fully applicable to all knowledge based authentication. For motivation hereof we refer the reader to Chapter 3.

4.3. Token Based Authentication; One Time Passwords Token based authentication implies that some physical object is needed to successfully authenticate. This object may be everything from a physical key crafted in metal, a smart card, an electronic device or a piece of paper. Many implementations of token based authentication combine the token with some required knowledge (e.g. a one time password generator protected by a PIN code).

In this section we focus strictly on different applications of one time passwords. A one time pass‐ word is, like the name reveals, consumed after a successful authentication and is not used a second time.

4.3.1. One Time Pads The simplest form of one time passwords is a list of passwords which is shared by the server and the user. The server may store the passwords in clear text or in hashed form.

When a user is logging in the server may ask for the next available password or a password with a specific ID. One time passwords can be combined with a static password forming a two factor authentication.

Some Swedish banks, like Skandiabanken, use one time pads (see Figure 8 below) in conjunction with soft certificates (see Section 4.4.1). OTPW (One time password login package) [55] is a basic system for the use of one time pads together with a number of systems, including ssh servers on Linux and Unix. An example of a onetime pad generated with OTPW is shown in Figure 9 below.

Figure 8: One time pad from the Swedish bank Skandiabanken

000 E:pXU 016 J7/sE 032 raq5N 048 =Om:v 064 ViHa7 080 H9wKQ 001 wapgo 017 sDTbr 033 ssK3: 049 U+x8C 065 Mc4JP 081 iSMr2 002 mm:+9 018 v=KpO 034 VxnJt 050 CIPzJ 066 sjze: 082 bGi9C 003 yNYho 019 Is+Yu 035 :MtHX 051 ONzhE 067 umLJA 083 %B5xy 004 Yy/A8 020 TWo6t 036 +oUcs 052 e2SOJ 068 jYNCB 084 6t2%E 005 nQswR 021 /m%EH 037 5SPU/ 053 9THG: 069 Ic93E 085 rXXpY 006 zXjnW 022 pI3Xu 038 BEoxq 054 rirJN 070 pzPEm 086 8d:5A 007 Myx9o 023 om%6h 039 T%G8n 055 i:VxW 071 wWBfJ 087 :PS5i 008 Hnkzj 024 iiWZj 040 Jt3=: 056 XeKZ7 072 aUXVU 088 YgL=v 009 =r7fR 025 k4xrP 041 xtsPc 057 :e8XY 073 X+Jxb 089 cnSCi 010 JNt5p 026 9r35t 042 %jtKc 058 b2y+R 074 bMdgg 090 ihSJE 011 X8jT% 027 NmwzV 043 rBhOi 059 V7UbI 075 22bZL 091 qPDzQ 012 qSavI 028 fQXrF 044 sHtZZ 060 /vwOM 076 uQbtU 092 5yyKV 013 2XC=6 029 qyk%j 045 y7:WV 061 odFCI 077 SYmeN 093 Z+NIr 014 U+qdx 030 =:Yp9 046 BVMB9 062 K%K:% 078 6qufS 094 f:ISJ 015 rWNMc 031 HAgx9 047 Sh8Wh 063 %ZoWN 079 yU=FR 095 hNnRe

!!! REMEMBER: Enter the PREFIX PASSWORD first !!!

Figure 9: One time pad generated with OTPW

One time passwords also come in the form of electronic devices that outputs one password at a time. Such a device could simply store a large number of passwords shared with the server, much like the printed tokens. A more efficient way however, is to use a base secret and an algorithm to generate passwords as the user needs them. Such a scheme was first suggested by Lamport [56] in 1981 and further developed in the S/KEY system [57] and OTP system [58]. These algorithms provide the foundations of more modern algorithms.

4.3.2. Short Time Valid One Time Passwords Even though one time passwords mitigate a lot of attack vectors they are still vulnerable to a number of attacks, some of which can be mitigated by limiting the time span the password is valid. Since these kind of one time passwords are dynamic they cannot come in the form of printed pads; instead they are generated on a hard‐ or software token or delivered out of band6 (e.g. by SMS).

Hardware tokens which produce short time valid one time passwords must contain a clock which is used in the generation of the password. According to Nash et al. [59] it is common to separate the authentication process to a specialized authentication server. The full suggested workflow for gene‐ rating and validating a short time valid password is depicted in Figure 10 below.

6 Using a different medium for authentication than the medium used for other communication of claimant and verifier [61].

29 Requested service (e.g. web server) Token

Shared key Clock 1 . R eq d ue r st o pa sw ss as w P or . d d 3 r o y w n s e s d / a t P p

. e Hash-function c 4 c A

User . d 5 Truncate to 6-8 or sw digits as P 12345678 2. Shared key Clock

Authentication server

Hash-function

Truncate to 6-8 digits

Compare with user supplied password

Figure 10: Generation of a short time valid one time password Figure based on PKI Implementing and Managing E-security by Nash et al. [59]

A short time valid one time password is generated in the following way: 1. The user requests a password from the token by pushing a button or entering a PIN code. 2. The token combines the values of the internal clock with a key that is shared with the authentication server. This combination is inputted into a secure hash function and the output from the hash is truncated to 6‐8 characters to make the password manageable by the user. 3. The user types the generated password at a login prompt or on a web page and sends it to the server. 4. The password is sent to the authentication server which computes the same password according to the shared secret and the server’s internal clock. 5. The server side generated password is compared with the password supplied by the user and a response (accept or deny) is given to the calling server.

Clock based tokens typically update the time based part of the password seed every 60 seconds [59]. The password generated however has to be valid a little longer than this interval. Since it may take a few seconds (or more) for the user to enter the password after it has been generated there is a great chance that the clock changes value from the time of generation until the time of check. Moreover due to physical factors7 the clock in the token will eventually get out of sync compared to the clock in the authentication server. Due to this fact the server needs to be able to synchronize its clock and store the difference as a delta‐value associated with each token.

7 For example temperature may affect components used to measure time [59].

30 If the server is unable to match the password at the expected clock value, one alternative is to successively try to match the password within F 1, F 2, , F i minutes difference (where i defines an inner window in which the password is accepted). Upon a match the server adds the dif‐ ference to the stored delta‐value for use at the next session. If no match is found within this interval the server may keep trying an outer window F i  1 , F i  2 , , F i  n . If a match is found in this interval the server asks the user to authenticateà again;à if the passwordà still matches about the same difference, the user is accepted and the delta‐value is stored for upcoming sessions.

Tokens may also include a counter to further increase entropy in the generation of the password. This technique demands that the server is able to synchronize with the device if the user extracts passwords that are never used. Such synchronizations can be made according to the same principles as with clocks. Clocks and counters of tokens are sometimes referred to as a moving factor [60], as they represent an entity that is steadily changing and which value never will reoccur.

Instead of implementing the functionality described above, one time passwords may be delivered by SMS text messages utilizing an out of band channel [61].

4.3.3. ChallengeResponse Based One Time Passwords One time passwords can also be composed using a challenge‐response scheme. Upon login the server gives a challenge and expects a response (password) from the claimant. As with other forms of one time passwords challenge‐response algorithms may or may not be time dependent. Challenge response may also be used in conjunction with a counter.

Apart from the challenge the technique is very similar to other short time valid passwords. The response is generated based on the challenge and a secret key, and possibly a clock and a counter, all but the challenge internal to the token. A sample scheme using a synchronized clock, but no counter, is shown in Figure 11 below.

Figure 11: Generation of short time valid password based on server generated challenge Figure based on PKI Implementing and Managing E-security [59]

One might assume challenge‐response methods to be more secure than counter based, time depen‐ dent, one time passwords. In general, this is however not the case. For an attacker to compromise challenge‐response based authentication he either needs to get access to the shared key or fool the user to generate a valid password. The same holds for counter based one time passwords. We hence suggest that the challenge per se does not add any difficulty for the attacker. The exception of this is if the challenge itself bears some meaning for the user in the current context, for example if the amount and the account number used are included in the challenge when authenticating a transac‐ tion of money. For an example of a possible attack scenario including challenges we refer the reader to the man in the middle threat assessment (see Section 4.3.4, page 35).

4.3.4. Threat Assessment By never using the same password twice (unless by random) we immediately eliminate a large number of attack vectors to an insignificant applicability for all one time password authentication methods, particularly in the basic and medium level classes.

Note that we opt to not differentiate from token generated one time passwords and passwords delivered by SMS text messages. In this context we consider the SMS channel to be trusted.

Guessing, Dictionary and Brute Force Attacks One time password should be generated in an unpredictable manner; hence password guessing will not be an applicable attack vector. However precautions must be taken to stop brute force attacks. This can be accomplished by delay or lock out mechanisms as suggested in Section 3.2.1. With

32 appropriate lock out mechanisms in place we consider the applicability of these attack vectors to be insignificant for all one time password based methods.

Shoulder Surfing Shoulder surfing is applicable to one time pads if passwords are shown before they are used, like the one time pad in Figure 8 (see page 28). One time pads can come in the form of a scratch‐pad to reduce exposure of unused passwords. Passwords may however still be extracted in advance and the user might or might not notice this. One time passwords which do not utilize a time component might be compromised in the same manner, once the user executes a log in previously stolen pass‐ words are however made invalid. We conclude that the applicability of shoulder surfing attacks is high with respect to printed one time pads and medium with respect to token generated one time passwords (without a time component). Short time valid and challenge‐response based one time passwords however effectively mitigates this attack vector.

Password Reuse and Keyloggers The attack vectors password reuse and keyloggers are mitigated using one time passwords. Pass‐ words will not be reused and attackers will not benefit from logging passwords unless they are used immediately in an active attack (a form of man in the browser attack). We therefore consider the applicability of these vectors to be insignificant towards one time passwords.

Passive and Active Social Engineering With one exception all passive attacks are efficiently mitigated by the use of time dependent one time passwords, since the password expires before the attacker has the opportunity to use it. For static one time passwords however a passive social engineering attack may succeed if the attacker harvests the password and uses it before the claimant performs his next authentic login. In an active attack the attacker may use the password as soon as the claimant has been fooled to give it away; hence it will still be valid.

We consider an attack to be less probable if transaction dependent challenge‐response is used as authentication method. Using challenges consistently in a context related to a specific purpose will, according to our belief, increase the probability that the user recognizes valid and invalid use.

We suggest applicability according to Table 1 below.

33 Table 1: Assessment of applicability of social engineering attacks towards one time passwords

Printed one Token gener‐ Short time valid Challenge‐ Transaction depen‐ time pads ated one time one time pass‐ response dent challenge‐ pads words response

Passive Social High High Insignificant Insignificant Insignificant Engineering

Active Social High High High High Low Engineering

Passive and Active Eavesdropping For the attacker to successfully utilize eavesdropping he needs to get hold of the password before it is used, since a one time password expires at the time of use. A passive eavesdropping attack will thus not be successful since the password will no longer be valid.

When performed in an active approach a race condition is however possible. If the attacker is able to both capture the password and make his authentication request arrive first to the server he wins the race. The attacker may increase his chances by performing a DoS attack. When using time depen‐ dent one time passwords the server might protect itself against this kind of attack by limiting access to the claimant’s IP address for some time after an initial request to authenticate. This approach may be circumvented if the attacker can take over or forge the claimant’s IP address.

A challenge‐response mechanism would protect against this attack given that the challenge is tied to other session data (i.e. the claimant’s IP address), forcing the attacker to spoof his IP address in order for the attack to be successful. A transaction dependent challenge response will not offer extra protection per se, but may further prevent the attacker to modify a transaction.

We suggest applicability according to Table 2 below.

Table 2: Assessment of applicability of eavesdropping attacks towards one time passwords

Printed one Token gener‐ Short time valid Challenge‐ Transaction depen‐ time pads ated one time one time pass‐ response dent challenge‐ pads words response

Passive Eave‐ Insignificant Insignificant Insignificant Insignificant Insignificant sdropping

Active Eave‐ High High Medium Low Insignificant sdropping

Theft of Credentials by Intrusion Since the one time password is expired after use the attacker will not be able to steal the password in retrospect from a compromised computer. Intrusion may however facilitate an eavesdropping attack which we have covered for above. We consider the applicability of intrusion by itself as a way to compromise one time password as insignificant.

34 Man in the Middle, Man in the Browser One time passwords will not protect against man in the middle or man in the browser attacks unless using transaction dependent challenge‐response.

The following attack scenario may be used to exploit transaction independent challenge response authentication (and other one time password schemes). The scenario can be applied both for man in the middle and man in the browser attacks.

Assume that the user Alice wants to pay a bill and that the attacker Eve wants to steal money from Alice’s account. The scenario also includes Alice’s bank located on the web at http://www.very‐ securebank.com. Eve has built a web site that looks exactly like Alice’s bank web site, but located at http://www.malwareinc.com. Alice’s computer has previously been compromised by Eve. More spe‐ cifically Eve has modified the hosts file so verysecurebank.com points to malwareinc.com. Further‐ more Eve has imported her own root certificate into Alice’s browser.

Eve Alice Eve Alice

Compromised malware.inc verysecurebank.com computer verysecurebank.com Requ Compromised malware.inc est transfer o t f $100 computer o the electrica Request tra l company nsfer of funds Reque to Eve st login page Request login nge page challe andom ge R challen orm & nge Login f Challe ge challen Respo orm & nse Login f Response Response

Figure 12: First part of a man in the middle attack Figure 13: Second part of a man in the middle attack

When Alice requests the log in form from her bank, she is unknowingly communicating with malwa‐ reinc.com, which belongs to Eve. malwareinc.com forwards Alice’s request to the real web site, the bank returns a random challenge which malwareinc.com then returns to Alice. The web browser is using SSL/TLS and no warnings are shown, so everything seems fine to Alice, who provides the correct response to the challenge (see Figure 12 above). At this time Eve can access Alice’s account. Even if the bank presents further random challenges when payment is to be made, Eve can fool Alice as illustrated in Figure 13 above.

The demonstrated scenario illustrates particularly how random challenges provide no increase of security compared to other short time valid passwords. Security is increased radically by associating the challenge with a value that the user can verify for herself, without involving the communication channel on which the challenge is transmitted.

By associating the challenge with a value in this way and adequately educate the user we state that phishing, man in the middle and man in the browser attacks are all mitigated. This example however only covers the specific scenario of transferring money between bank accounts; in other scenarios it might be hard or impossible to identify a challenge that can be tied to the current context.

We consider the applicability of the discussed attack vectors to be highly applicable to all methods presented in this section except for transaction dependent challenge‐response.

35 4.4. Token Based Authentication; Public Key Infrastructure In Chapter 2 we introduced SSL/TLS communication. We also supplied a thorough walk through the handshake process. In the scheme presented in Chapter 2, SSL/TLS was only used to prove the server’s identity and support encryption of traffic. In this section we study how SSL/TLS can be used for authentication of the claimant as well. This is sometimes referred to as Public Key Infrastructure (PKI) [2].

4.4.1. Soft SSL/TLS Certificates Using SSL/TLS to prove a claimant’s identity is carried out much in the same way as when the server is authenticated by the client. When client authentication is performed the handshake process is slightly modified according to Figure 14 below.

Client Server

CLIENT HELLO: -SSL/TLS Version -Random 1 -Session ID -Cipher list -Compression list

SERVER HELLO: -SSL/TLS Version -Random 2 -Session ID -Cipher -Compression SERVER CERTIFICATE SERVER KEY EXCHANGE CERTIFICATE REQUEST SERVER HELLO DONE CLIENT CERTIFICATE CLIENT KEY EXCHANGE -pre CERTIFICATE VERIFY CHANGE CIPHER SPEC E(CLIENT FINISHED)

CHANGE CIPHER SPEC E(SERVER FINISHED)

Figure 14: SSL/TLS handshake process utilizing client authentication

Right before finishing the first response of the handshake message the server will request a client certificate by sending a CERTIFICATE REQUEST message.

The client responds with its certificate embedded in CLIENT CERTIFICATE message right before establishing the pre shared secret. Immediately after the CLIENT KEY EXCHANGE the client will verify its certificate by sending a CERTIFICATE VERIFY message.

36 In the verification the client uses its private key to sign the concatenation of all previous handshake messages (starting from CLIENT HELLO, including all client and server messages up to CLIENT KEY EXCHANGE). Signing the handshake messages has two particularly important effects. First, the signature is tied to the server since the server’s signature is included in the handshake messages. Secondly, the signature is tied to the current session since the random nonce from CLIENT and SERVER HELLO is included.

When the server has verified the CERTIFICATE VERIFY message the client is authenticated and communications proceeds as with regular SSL/TLS traffic described in Chapter 2.

4.4.2. Smart Card Encapsulated SSL/TLS A weakness with soft certificates is the fact that the private key can easily be copied from a compromised client, enabling passive attacks. This threat can be mitigated by putting the private key on a tamper resistant hardware device with the capability to use the private key for decryption and signing, but from which it is infeasible to extract the key itself. This device commonly comes in the form of a smart card used in a standalone reader or integrated in a USB token. The smart card has an integrated CPU and OS providing cryptographic capabilities.

An example of this scheme using SSL/TLS is shown in Figure 15 below. The figure shows the certifi‐ cate and the private key stored on the smart card. The certificate is not secret and can be requested directly, but the private key is used only inside the card and cannot be extracted by the client.

Hardware token (e.g. smart card) Client Server CLIENT HELLO SERVER HELLO SERVER CERTIFICATE SERVER KEY EXCHANGE CERTIFICATE REQUEST REQUEST CERTIFICATE SERVER HELLO DONE

CERTIFICATE* CLIENT CERTIFICATE CLIENT KEY EXCHANGE

REQUEST SIGNATURE

Signature is calculated by using the private key stored on the card.

CERTIFICATE VERIFY SIGNATURE E(CLIENT FINISHED)

CHANGE CIPHER SPEC E(SERVER FINISHED)

*CERTIFICATE may be cached by Client

Figure 15: SSL/TLS authentication using a hardware token

Even though an attacker that has compromised the client cannot extract the private key he can send commands to the card requesting the card to sign arbitrary data, possibly authenticating as the client to various services. To prevent this, the card can be protected by a PIN code that must be

37 entered prior to each use of the private key. This also protects the card from being used by an attacker that has gained physical access to the card (e.g. by pick pocketing).

Depending on card and application the PIN code can be entered via the computer’s keyboard or on a separate keypad on the card reader, the latter being resistant to malware keyloggers. There also exist cards and card readers with biometric capabilities, authenticating the user by fingerprint.

4.4.3. Threat Assessment By implementing PKI technologies like SSL/TLS a wide amount of threats are mitigated. By never using the same password twice (unless by random) we immediately eliminate a large number of attack vectors to an insignificant applicability for all one time password authentication methods. There are however some exceptions.

Basic Level Attack Vectors All basic level attack vectors, as we define them in Chapter 3, are eliminated when using PKI as described in this section. All these attack vectors target passwords, which are eliminated (or only used in conjunction with the cryptographic techniques presented) when using PKI.

Theft of Credentials by Intrusion Soft SSL/TLS client certificates reside, together with their private key, on the client’s computer. If an attacker has gained access to a computer storing these credentials it is trivial for the attacker to copy the certificate and the private key. This is a major drawback of soft SSL/TLS certificates. The authen‐ tication method may be used in conjunction with other methods (e.g. passwords). Combining client certificates with passwords may provide protection towards trivial attacks, but the attacker who has access to the client’s computer is probably also able to steal the password (as was discussed in Section 4.2.3).

Hard SSL/TLS certificates residing on a smart card may be used by an attacker in an active attack if the smart card is not protected by a PIN code. The attacker is not able to copy the private key of the smart card but might be able request the card to sign arbitrary data. If the smart card is discon‐ nected or protected by a PIN code the attack will be stopped; in this case the signing capabilities of the private key will not be available.

We suggest this attack vector to have high applicability regarding soft SSL/TLS certificates and low applicability towards hard certificates.

Active and Passive Social Engineering We suggest that tricking a user to extract and give away his soft client certificate and corresponding private key is much harder than for instance his password. The latter could simply be requested on a web page, but to extract a certificate quite complex series of operations are necessary. A Trojan horse stealing the certificate is a possibility. Regarding hard certificates the whole idea is to make it infeasible to extract the private key from the card.

Active attacks are a bit more probable to succeed since the attacker could ‘guide’ the user through the attack. Assume an application where the user can access sensitive data using a PKI based solution. Such a user could still be fooled to voluntarily lookup the data and give it to the attacker. This is an attack vector that will only be mitigated by proper user education.

38 We suggest ranking of applicability according to Table 3 below.

Table 3: Assessment of applicability of social engineering attacks towards PKI

Soft SSL/TLS Certificates Hard SSL/TLS Certificates

Passive Social Engineering Low Insignificant

Active Social Engineering Low Insignificant

Active and Passive Eavesdropping Assuming that the encryption algorithms that are used are not broken, SSL/TLS offers protection against eavesdropping. Even if an attacker is able to capture the network traffic on its way between client and server no credentials can be stolen thanks the encryption and key exchange of the hand‐ shake process. We therefore suggest the applicability of these attack vectors regarding PKI based solutions to be insignificant.

Man in the Middle As long as the cryptographic mechanisms of the certificates are not broken, man in the middle attacks are efficiently mitigated when using both client and server SSL/TLS certificates. Note that using only server certificates also offers protection as long as the client is not compromised, does not have an erroneously trusted root certificate installed and the user does not accept invalid certifi‐ cates. This attack vector will thus in this case have insignificant applicability.

Note that man in the middle would be applicable if the trusted root certificate is compromised, for instance by social engineering against the CA. We consider the probability of such an attack succeeding to be insignificant.

Man in the Browser SSL/TLS can be viewed as an extra layer in the five‐layer Internet Protocol Stack [62] (see Figure 16 below). A browser hijacking attack executes inside the browser so an attacker may modify traffic between the user and the server before traffic is encrypted and signed by the SSL/TLS protocol. Hence SSL/TLS offers no protection against man in the browser attacks. We therefore consider this attack vector to have high applicability towards SSL/TLS based authentication methods.

Figure 16: The Internet protocol stack extended with SSL/TLS

39 4.5. Authentication Methods Suggested by the Research Commu nity In this section we introduce two different authentication methods suggested by the research community; secure web authentication with cell phones and camera‐based authentication.

4.5.1. Secure Web Authentication with Mobile Phones Wu et al. [63] have suggested an authentication method named Secure web authentication with mobile phones. This method uses the out of band authentication technique. The model proposes the following workflow (see Figure 17 below):

User Client – possibly compromised 1. Request web page

7. Allow traffic Remote service

5. Confirm or 3. Web page incl. cancel login 2. HTTP request RANDWORD

4. SMS with RANDWORD 7. Allow traffic and login URL

WAP capable Security proxy cell phone 6. HTTP request

Figure 17: Workflow of “Secure web authentication with mobile phones” Illustration based on description and figure by Wu et al. [63]

1‐2. The user requests some remote service by directing her browser to a security proxy. 3. The security proxy returns a web page containing a random word (referred to as the session name). 4. The security proxy sends a SMS to the user’s cell phone. The SMS contains the session name from Step 3 and a link that directs the phone’s browser to a web page where the user may confirm or cancel the login. 5‐6. The user confirms (or cancels) login by making the appropriate choice in the phone’s browser. 7. Given that the user confirms login, the security proxy allows traffic between client and remote service.

The model further proposes that the user gets the choice to lock her account if she does not confirm the login in step 5. Furthermore the user should be able to log out from the remote service using the URL sent to the cell phone in the case she forgets to log out when leaving the client.

4.5.2. CameraBased Authentication Clarke et al. [64] suggest an authentication method where users are equipped with a trusted device. The device provides the ability to support what is defined as a Unidirectional Authentication with Secure Approval Channel (UASAC). UASAC provides integrity checks of messages sent from a secure proxy to the user as well as an operation that lets the user send a message to the proxy stating that the user has approved an authenticated message previously received by the proxy.

40 User Security Proxy

Untrusted computer and untrusted network

User’s trusted Application Server device

Figure 18: Flow of secured data (bi-directional) using camera-based authentication Illustration based on description and figure by Clark et al. [64]

Furthermore Clark et al. suggests that any UASAC can be used to construct a Bidirectional Channel (BAC). A BAC is defined as a channel implementing integrity checks of messages sent between the user and the proxy and vice versa.

Clark et al. propose two implementations of UASAC using a camera equipped trusted device. One implementation is based on information encoded in black and white pictures, the other implementa‐ tion adopt optical character recognition.

If every bit of data in the communication between the user and the security proxy took the way through the user’s trusted device the properties of BAC would allow us to trust the full communica‐ tion (see Figure 18 above). This would however require the user to only interact with the trusted device. Also it must be possible to encode all required information in the picture or OCR data.

If we reduce the proposed setup to protect an authentication before letting the user communicate directly via the untrusted computer the method would practically be the camera based equivalent of challenge‐response based one time passwords. This application of the method will be considered in the threat assessment below.

4.5.3. Threat Assessment This section presents the threat assessment of secure authentication with mobile phones and camera based authentication.

Basic Level Attack Vectors Using both methods presented in this section we mitigate the basic class of attack vectors to an insignificant level of applicability. As with one time passwords there simply are no predictable pass‐ words to guess or search for. Caution must still be taken to provide sufficient key length to stop brute force attacks. One can note that a brute force attack of the method Secure Web Authentica‐ tion with Mobile Phones would flood the authentic user with SMS messages.

Medium Level Attack Vectors Medium level attack vectors will also be mitigated to insignificant applicability. Social engineering and eavesdropping attacks will in no case be useful since the correct verification link, or challenge, are generated dynamically by respective security proxy. No data will reside on any untrusted client that may be used to compromise these methods.

41 Active Social Engineering As with one time passwords, one might imagine a phishing attack fooling the user to visit a web site believing that he visits the authentic web site. The fake web site might contact the real web site and fetch all data necessary for authenticating the user. We consider this attack vector as highly applica‐ ble for both authentication methods.

Active Eavesdropping Given that the camera based method would tie some factor in the challenge (picture) to the active session this method would protect against active eavesdropping/race condition attacks by the same principles as challenge‐response based one time passwords, as discussed in Section 4.3.4.

The Secure web authentication with mobile phones method states that the random word should be tied to a specific session (hence the term ‘session name’). Given that the user does his job and do verify the session name this provides sufficient protection against eavesdropping attacks.

We consider the applicability of this attack vector to be low for both methods presented.

Man in the Middle and Man in the Browser As long as we only protect the authentication and not upcoming data transfer by an authentication method we cannot protect against a man in the middle attack. We have previously concluded that SSL/TLS client certificates and transaction dependent challenge‐response do offer protection since they authenticate the data transferred even after authentication. As we only consider camera based authentication for an initial authentication, this method do not mitigate man in the middle attacks.

Neither does secure web authentication with mobile phones mitigate man in the middle attacks. As long as the user has passed authentication an attacker is free to modify data transferred.

For the same reasons none of the methods offer protection against man in the browser attacks. We therefore consider the applicability of man in the middle and man in the browser attacks as high for both methods.

4.6. Threat Assessment Summary and Comments The threat analyses of the previous sections are summarized in Table 4 below. Note that the analys‐ es do not consider the strength protecting access to different tokens. For instance, transaction dependent challenge‐response has received an excellent ranking, but we have not considered how the user is authenticated before the token is distributed. Imagine an implementation where the account number is considered secret and this is all you need in order to receive the token when visiting your local bank office (no ID is requested). Such an implementation should not be ranked with excellent score, but rather according to passwords. Analogous considerations hold for most methods.

Another issue with the ranking is that we do not differentiate upon the consequences of an authen‐ tication breach. Is authentication repeatable without any additional effort, as in the case of pass‐ words or the compromise of a private key of a PKI solution? The ranking method might be extended with additional weighting on this property.

42 Table 4: Comparison chart

Authentication Methods

0 Insignificant

one

1Low

dependent

2Medium PKI valid

response response

password pads ‐ ‐

certificate 3High Based

one ‐ phones

generated card

time

certificates,

authentication passwords pads

time

TLS time

screen

Camera Authentication mobile Web smart Hard challenge Soft challenge Transaction One time Short one Token time passwords Printed Passwords On Basic level (passive) Guessing & Dictionary 2 2 00000 00 00 Brute force 1 1 00000 00 00 Shoulder surfing 2 3 32000 00 00 Password reuse 3 3 10000 00 00 Key logger hardware 3 0 00000 00 00 Key logger software 33 00000 00 00 ss Social engineering 33 33000 10 00 vector Medium level (passive) Theft by intrusion 22 00000 30 00 Attack Eavesdropping 33 00000 00 00

Advanced level (active) Social engineering 33 33331 10 33 Eavesdropping 33 33210 00 11 Man in the middle 33 33330 00 33 Man in the browser 3 3 33330 33 33

Ranking (lower is better) 73 67 33 27 11 10 1 13 3 10 10

Chapter 5 Suggested Authentication Method

As a part of this thesis an authentication application has been implemented and deployed on a VPN appliance. We choose to call this application Smokey (Synchronizable Mobile Key). This chapter proposes the authentication method to implement and presents a usability analysis conducted on a prototype of the Smokey application. Furthermore the algorithm used is introduced. Finally new attack vectors entailed by the proposed application are analyzed. All in all this chapter aims to describe the ‘what and why’ of the suggested application.

5.1. Choice of Authentication Method An explicit goal of the application is to provide an appropriate combination of protection and usabili‐ ty. To attain this balance we aim to mitigate the basic and medium level attack vectors, as for the rest prioritizing usability.

Studying the comparison chart in Table 4 (see page 43) we find several candidate methods that fulfill our security requirements. Table 5 below shows these candidates as well as our judgment of usabili‐ ty and practical limitations.

Assuming that intended users in general are equipped with mobile phones we argue that Short time valid or challenge‐response based one time passwords are the choices that best fit our purpose. We suggest that a successful method should not be dependent on cell phone coverage or be limited to a single cell phone operator. Other options remaining require users to carry extra hardware or are simply not realistic to deploy using current technology. Furthermore, we argue that a short time valid one time password generator is more user friendly than a challenge response based one, since the latter requires more input (key strokes) by the user.

As we concluded in the threat assessment in Section 4.3.4 challenge‐response offers better protec‐ tion towards race condition attacks following active eavesdropping compared to short time valid one time passwords. However, since both methods mitigate the basic and medium level attacks we opt to value the usability benefits of one time passwords higher than the extra protection gained by challenge‐response.

45 Table 5: Overview of candidate authentication methods

Candidate method Comment Short time valid one time passwords generated Possible to develop using cell phones. by token

Challenge‐response based one time passwords Possible to develop using cell phones.

Transaction dependent challenge‐response Infeasible to decide what a transaction is on a VPN connection.

Hard certificates (smart card) Requires extra hardware and drivers. Will not support mobility of users.

Short time valid one time passwords delivered Requires connectivity and cell phone coverage at by SMS use. A small delay may occur at each delivery of SMS.

Secure web authentication with mobile phones Requires connectivity and cell phone coverage at use. A delay would occur at each login as the phone establishes HTTP connection.

Camera based authentication Very complex to develop.

A disadvantage with short time valid one time passwords however is the risk of the user to get out of sync with the server; either by generating too many passwords without using them or by drift of device clock versus the clock of the server. Particularly the latter may prove to be a problem when it comes to cell phones since users themselves can change the clock. In order to meet these disadvan‐ tages we suggest that a cell phone based authentication application should be able to use out of band channels (i.e. the cell phone network; HTTP or SMS) to synchronize time and counter with the server.

5.2. Prototype Some requirements have already been specified in Section 5.1 and most of the functional aspects of a one time password generator are pretty straightforward. Moreover the author was keen to capture usability aspects and assure that assumptions made regarding usability were not altogether incorrect. For this reason we opt to begin the design phase with the development of a prototype, continuing with a usability study before formulating any requirement specification.

The prototype consists of a simple Java ME application developed for a Sony Ericsson K530i cell phone. The application consists of a welcome screen (see Figure 19) 8 and a password display screen (see Figure 20). Furthermore the prototype has stubs (placeholders) in menus for a synchronization option, but lacks any personalization or synchronization functionality. All passwords where ‘generat‐ ed’ from a static list of passwords. The application prototype is accompanied by a www login form (see Figure 21).

8 The actual prototype was targeted to Swedish talking users. The text shown in these screen shots have been translated into English.

46 The main goal when designing the prototype was to minimize user input and make it obvious what constitutes output that the user is expected to enter in the login form. Unfortunately the process of actually starting a Java application requires a lot of navigation in the cell phone’s menus. In the usa‐ bility study we try two methods to mitigate this potential problem. First we write detailed instruc‐ tions on how to navigate to the applications menu where the applet is located. Then we evaluate the effect of a preinstalled shortcut. The shortcut reduces five keystrokes. Complete instructions and user tasks of the usability test are included in Appendix I and II.

Besides from the search of any usability problems and evaluation of the shortcut we aspire to decide whether a four letter alphanumerical is to prefer over a six digit password. Furthermore we also want to measure how well the proposed prototype holds up in comparison with a standalone third party token. Finally we calculate a System Usability Scale (SUS) score [65] using a standardized method.

Figure 19: Prototype main screen Figure 20: Prototype showing a one time password

Figure 21: Prototype login form 5.3. Usability Analysis of Prototype The main goal with the usability analysis was to confirm that the prototype did not include any major usability issues. According to Tullis and Albert a formative usability study aims to identifying or diag‐ nostic problems and making recommendations of improvement, whereas a summative usability study focus on evaluating against certain criteria. Furthermore a formative study may settle with fewer participants than a summative one. [65]

Since our main goal is formative we settle for ten participants in the study. Having the opportunity to collect opinions from these participants we include some summative questions. The author would

47 like to stress that the outcome, aside from major usability issues, should be interpret with caution due to the limited number of participants in the study.

5.3.1. Usability Analysis Method Ten users were invited to participate in the usability analysis. The participants were chosen so that half of the participants consisted of non‐expert users; individuals who interact with computers on a daily basis but not as technicians. Expert users were chosen to fill the remaining half of the partici‐ pants group. As experts we define practicing software engineers, computer support technicians and software engineering students.

For each user an individual session was carried out, lead by the author. Each session consisted of an initial brief presentation of the background of the project and motivation of the study. The users were explicitly asked to think aloud and express any confusing details. After the presentation the users were asked to carry out the written tasks presented in Appendix I. After each group of tasks the users were asked to fill out a questionnaire (shown in Appendix I). Finally a third party stand alone token (SafeWord [66] from Aladdin Inc.) were presented after which the session was summa‐ rized with a discussion and interview.

5.3.2. Generic Usability Issues After a successful generation of a one time password and log in using the web form, users were asked to rank the statement “It was easy to generate the one time password” on a Likert scale9. The scale used in the analysis range from 1 (I strongly disagree) to 5 (I strongly agree). Mean of partici‐ pants’ answers and corresponding confidence interval (95 per cent) is shown in Figure 22 below.

"It was easy to generate the OTP"

Figure 22: Participants’ report of easiness to generate OTP:s using the prototype

Even though the participants reportedly found the task of generating one time passwords easy to accomplish, several participants stated that the instructions were somewhat confusing. Participants commenting on the instructions found them to be too detailed and requested a shorter version. Mostly expert users presented this opinion. Aside from this proposal no concrete usability problems were found during the analysis.

5.3.3. System Usability Scale The System Usability Scale (SUS) [65] consists of a set of ten statements to be ranked on a five point Likert scale. SUS is designed as a method to quickly collect users’ experiences immediately after completion of an evaluation. Each participant’s answers is used to calculate a SUS score in the inter‐

9 In a Likert scale participants rate their level of agreement to a statement [65].

48 val 0 to 100. Being well defined and repeatable SUS allows comparison of different systems score indicating their relative position regarding usability aspects.

Appropriate SUS score depends on the context in which the system is used [67]; it is therefore not possible to define what score constitutes an acceptable, good or excellent usability level. SUS scores are best used when comparing similar systems. To get a basic sense of SUS scores however Tullis and Albert, authors of the book Measuring the User Experience [68], have studied SUS evaluations avail‐ able from the ACM Digital Library. Distribution of average SUS scores found in their survey is shown in Figure 23 below.

50 40 30 20 Frequency 10 0 <=40 41‐50 51‐60 61‐70 71‐80 81‐90 91‐100 Average SUS Scores

Figure 23: Frequency distribution of SUS scores for 129 conditions from 50 Studies Figure based on data provided by www.measuringuserexperience.com [68]

The mean SUS score of the usability evaluation of Smokey is 91 (95 % confidence interval ±5.7). When comparing this score with the studies surveyed by Tullis and Albert [68] one should consider that Smokey is an application with strictly limited functionality whereas many other software are more complex. It would therefore have been alarming if Smokey did not produce a relatively high SUS score. Hence we must not draw too strong conclusions from these results; we do however consider this score as an indication that there are no serious usability problems related with the Smokey prototype.

5.3.4. Benefit of a Preinstalled Shortcut The first tasks of the usability study were to open the applications menu on the cell phone. On the cell phone used in the study this step is necessary in order to start the actual Java applet. The first set of tasks guided the user to open the applications menu using the cell phone’s ordinary workflow requiring six key strokes. In contrast the second set of tasks utilized a preinstalled shortcut allowing the menu to be opened with only one key stroke (the left button on the navigation key). After each task users were asked to rank the statement “It was easy to open the applications menu” (same scale as in Section 5.3.2).

The purpose of these questions was to decide whether the approach with a shortcut provided installed by a technician would significantly improve usability. Means of participants’ answers and corresponding confidence interval (95 per cent) are shown in Figure 24 below.

49 "It was easy to open the applications menu"

5 4 3 2 1

Without shortcut With shortcut

Figure 24: Participants’ report of easiness to open applications menu

Users seem to prefer the shortcut method using the cell phone dedicated for the prototype. When carrying on with the evaluation all users opted to use the shortcut method when starting the Smokey prototype. The fact that testing the shortcut was the most recent activity may however have influenced users to choose this method. We suggest that users should be offered the service of a technician setting up a dedicated short cut if we aim for maximum usability.

5.3.5. Comparison of Prototype versus Standalone Token After participants evaluation of the prototype the author presented the SafeWord token from Aladdin Knowledge Systems Ltd. The token is small and lightweight and the user interface consists of only one button and a six digit display. The users were asked if they would prefer the token over the Smokey prototype given that they otherwise provided equal strength in terms of security. One of the ten participants stated that he would prefer the SafeWord standalone token but also stated that he would change his mind if he could use the prototype on both his personal cell phone and the cell phone provided by his employer. The remaining nine users stated that they preferred the Smokey prototype as that would imply carrying one less device with them.

Preferred token 10 %prefer standalone token

90 %prefer Smokey prototype

Figure 25: Share of users preferring Smokey vs. standalone token

Even though this result should be interpreted with caution due to the small sample size of ten users we suggest that a one time password solution based on cell phones carries significantly higher usability than standalone alternatives.

5.3.6. Comparison of Digit versus Alphanumerical Passwords In the summarizing interview each participant was asked if he/she would prefer one time passwords consisting of six digits (e.g. 729218) or passwords consisting of four non case‐sensitive alphanumeri‐

50 cal characters (e.g. GSQ2). One of ten users stated that he would prefer digit based passwords; the remaining nine users stated that they would prefer the shorter alphanumerical passwords (see Figure 26 below). About one third of the participants did not consider this a strong issue; the remain‐ ing two thirds however considered this as an important usability parameter.

Preferred password format 10 %prefer six digits passwords

90 %prefer four alpha‐ numerical characters

Figure 26: Users’ password format preferences 5.3.7. Conclusions A number of important comments were collected from the participants during the usability study. Apart from users expressing that the instructions were too detailed comments were also provided regarding some minor layout issues of the instructions. All in all the usability evaluation suggests that the prototype does not carry any serious usability issues and that a cell phone based OTP gene‐ rator provides significantly higher usability than stand alone alternatives.

5.4. OTP Generating Algorithm In order to generate one time passwords for use with the suggested application we choose the Algorithm HOTP (HMAC‐Based One Time Password Algorithm), described in RFC 4226 [60]. Strong benefits of using the HOTP algorithm is that it is free to use, and a detailed security analysis is included in the RFC. The RFC also includes sample code which saves a bit of precious development time and assures that many pair of eyes has reviewed this critical part of the code.

In short the HOTP algorithm takes as input a secret K (shared between client and server), and an 8‐byte moving factor C. The algorithm calculates HMAC(K,C). Using SHA‐1 as hash algorithm this returns a 160 bit value. The output of the HMAC is truncated (using what the HOTP algorithm de‐ fines as dynamic truncation; moving the truncation offset according to a specified formula in order to distribute the output uniformly) to a 31 bit value. The HOTP reference implementation includes code that converts this 31 bit value to a string of six to nine digits in base‐10. Instead of using this conversion we will convert the output of the dynamic truncation to a base‐32 number. Each ‘digit’ in the converted 32‐bit number will be used as index into an array of an alphabet consisting of charac‐ ters and digits that are not easily confused with each other (for example we avoid digit 0 and letter O). The full alphabet is shown in Figure 27 below. The reference deployment will use OTP:s of length four, yielding 32 1 048 576 possible passwords (a six digit OTP has 1 000 000 combinations).

byte[] ALPHABET = { '1','2','3','4','5','6','7','8','9', 'A','B','C','D','E','F','G','H','J', 'K','L','M','N','P','Q','R','S','T', 'U','V','X','Y','Z'}; Figure 27: Alphabet used to convert output to base-32

51 The moving factor will be composed of a counter and a clock representation. The counter must be strictly increasing and secures that the same moving factor never reoccurs10. We opt to measure time in minutes since epoch11. Since we have only one parameter available as moving factor we have to combine both the counter and the clock into parameter C. Since there is plenty of space in C (64 bits) we define C according to the following simplistic approach:

In order to guarantee that no collisions of counter and clock may occur we define the maximum counter value as 999 999 999. If C is represented by a signed 2‐complement 64 bit integer, as in Java, the maximum positive value that can be hold without overflow is:

2 19.210

Assuming (somewhat optimistic) that our application will be deployed for one hundred years the maximum clock component (and maximum C in total) will be roughly:

2110 1970 366 24 60 10 7.410

This is far less than the maximum integer that C can hold which assures a unique moving factor at every key generation as there is no risk of overflow.

5.5. Security Considerations As stated in Section 4.3.2, windows of acceptable clock and counter drift must be allowed. These windows must be defined with caution in order to prevent brute force attacks. A throttling parame‐ ter (disabling accounts for a certain time after a given number of failed login attempts) is also neces‐ sary.

5.5.1. Counter and Time Window In the following we define as the server’s representation of expected clock value (epoch + drift associated with current user); analogous we define as the server’s expected counter of client.

Assume that the server accepts clock and counter drift according to:

Since the distribution of generated OTP:s appear as random we may assume that each combination of and yields different OTP:s. Given these circumstances at each login attempt there are 11 6 66 valid OTP:s. That is, the probability, , to guess the correct password at one login attempt is 66/32.

5.5.2. Throttling Parameter According to the HOTP specification [60] a throttling parameter T is defined as “… the server will refuse connections from a user after T unsuccessful authentication attempts”. In order to promote

10 Since the user can set the clock of the cell phone, the same time may actually reoccur more than once. Also, several passwords may be extracted during the same time interval. 11The Merriam-Webster Dictionary & Thesaurus [87] defines epoch as an instant of time or a date selected as a point of reference. In Java epoch is defined as midnight January 1st, 1970.

52 usability and mitigate DoS attacks throttling may be limited to disabling accounts for a certain time only (e.g. an account may be disabled for 15 minutes).

Assume that we allow three login attempts every 15 minute. Given the parameters of the previous section the number n of total attempts possible during a 24 hour period would be 2443 288. The probability to guess at least one correct password during a 24 hour period would thus be12: 1 1 0.0178 1

The author claims that this is not acceptable even for less critical applications, and certainly not for the intended use in the reference deployment. However, since we require the application to be able to synchronize clock and counter with the server using HTTP we may define rather strict clock win‐ dow, counter window and throttling parameter without compromising usability.

5.5.3. Recommended Parameters We suggest that the exact parameters used in each deployment should be configurable by system administrators but recommend (and will use) parameters according to Table 6 below:

Table 6: Recommended clock window, counter window and throttling parameters

Accepted clock drift: 2

Accepted counter drift: 03

Throttling parameters:  Lock out user for 15 minutes after 3 failed attempts. After 3 additional consecutive failed attempts lock out user indefinite‐ ly, however:  Immediately release and reset throttling after a successful resynchronization.

Using parameters according to Table 6 yields a probability of 5 4/32 20/32 to guess the password at one attempt. The throttling parameter will only allow six attempts before the account is locked and the probability to guess the correct password before the account is disabled will thus be:

6 1 1 1.1410 1

We find this probability acceptable for the intended use.

5.6. Key Exchange The HOTP algorithm depends on a shared secret, K. This secret must either be packaged with the application upon installation or a key exchange must take place after the application has been installed but before generation of any OTP:s can begin.

Considering the environment in which we intend the application to be used13, we suggest that users request an initialization key from IT support. The department issuing initialization keys will be

12 Using the binomial distribution. 13 We assume the application to be used within an organization in which there exists an internal IT department or comparable department with responsibility for creating accounts.

53 responsible for verifying the user’s identity using the same procedures that hold for other kinds of accounts created.

Entering a 160 bit secret by hand would hardly be acceptable from user perspective. Hence, the initialization key cannot provide the complete secret. Instead we suggest that the user inputs a fairly short string that will be used to exchange key with server. The string will only consist of digits to ease input.

As channels for exchanging key material we suggest using a combination of HTTP and SMS, where SMS will be used when sending unencrypted key material. One could argue that SMS is not secure enough to transfer secret data and that HTTPS would constitute a better choice. Using HTTPS would however entail two significant problems.

Various cell phones typically just include a few root certificates which differ from one cell phone manufacturer to another [69]. Hence, either we have to purchase an expensive certificate from a strictly limited number of certificate authorities, or require users to install new root certificates into their cell phone using HTTP. We assume that most users would not be capable of, or have the energy to perform a manual verification of a new root certificate.

Even worse, as far as we can tell there is no possibility to let the Java ME application detect that the user has ignored a bad certificate warning using available methods in the MIDP specification. To sum up; we have greater confidence in the security of the radio band and cell phone network transmit‐ ting SMS than the users’ ability to not ignore warnings regarding bad certificates. Moreover, SMS also has the benefit of verifying that the initialization is performed on the cell phone belonging to the user since the initialization key is tied to the phone number on the authentication server.

A detailed description of the suggested key exchange protocol is available in Section 6.2.1.

5.7. New Attack Vectors Implementing OTP:s in a cell phone induces new attack vectors that we did not consider in Chapter 3. The shared secret key must be stored on the mobile device in order for the application to be able to generate OTP:s. An attacker who gets his hands on the key will be able to generate valid OTP:s without access to the device itself (he must however still guess a valid counter and keep track of the clock).

Available attack vectors include:  Physical access to cell phone  Theft by infection of malware  Attacking phone interfaces (i.e. Bluetooth or WLAN) from short distance  Theft from a compromised computer accessing the cell phone by USB or Bluetooth

Before discussing these attack vectors in details it is necessary to understand how persistent data is stored in Java ME applications. On current cell phones (CLDC 1.1, MIDP 2.0) there are two native ways for a Java ME application to store persistent data; in a Java Record Store [70] or as regular files available on the device file system [71]. Plain files, as in the latter method, are readable by other applications running on the cell phone. If the phone has been connected with a computer by USB or Bluetooth many cell phones allow reading of files from the computer. To protect against this kind of leakage Java Record Stores may provide additional protection.

54 Java Record Stores is part of the MIDP specification which states that private record stores only shall be accessible by the MIDlet (Java ME Application) that created it [70]. Exactly how this is imple‐ mented is up to each device manufacturer. Whether the Record Store storage is accessible by Blu‐ etooth or USB also depends on the manufacturer. For instance, the author’s cell phone will prevent access to the storage if the application is stored on the cell phone memory, but do allow access over USB or Bluetooth if the application is stored on a memory card. The cell phone allows the user to choose whether the application should be stored in the cell phone’s memory or on a memory card.

There have been reports on other cell phones making it possible to access internal storage no matter where the application itself is stored [72]. Furthermore we cannot know for sure which undocu‐ mented ‘features’ and bugs that exist, if any, to extract information from the cell phone’s memory.

5.7.1. Physical Access to Cell Phone We expect differences in how sophisticated the protection of private Java Record Stores is imple‐ mented in different cell phones. Experience from cell phones tested and available research [72] suggest that we must consider extraction of the secret key to be fully feasible for an attacker who has physical access to the cell phone.

5.7.2. Theft by Infection of Malware Existing research regarding malware on cell phones tends to focus on smart phones. This does not exclude the possibility of infection of malware on less sophisticated devices, but smart phones bear a higher risk of infection than less sophisticated cell phones due to the amount of malicious code available [73].

5.7.3. Attacking the Phone Interfaces from Short Distance If the attacker can trick the user to pair a Bluetooth enabled device with a malicious computer this enables numerous possibilities for the attacker. Via Bluetooth most cell phones allow exploration of the file system (as described in Section 5.7 above). Bluetooth also allows installation of new applica‐ tions, possible malware, on the cell phone. Research suggests that users are far too willing to accept unknown file transfers from strangers [74].

5.7.4. Theft from a Compromised Computer Accessing the Cell phone by USB or Bluetooth All of the previous attack vectors are feasible, but a successful attack also requires the attacker to have access to the users’ traditional password. The attacker needs to carry out two quite different attacks to be able to compromise the authentication. However, if the user’s computer is compro‐ mised (i.e. under control of the attacker) the computer can be used both to capture the user’s tradi‐ tional password and attack the cell phone if the user connects the cell phone to the computer by Bluetooth or USB. Possible reasons to do this are to synchronize calendar or address book, or move files (e.g. mp3 music files or photos) from or to the cell phone.

Since this setup has the potential to give the attacker both the user’s password and the key needed to generate OTP:s we believe that this constitutes the most potent attack vector. As we have shown in Section 5.7, defense mechanisms exist but their efficiency unfortunately highly depends on the cell phone manufacturer and is not standardized. This is not a fully satisfying situation. The Java ME Security and Trust Services API (SATSA) [75] provides features that may mitigate the problem [69], but currently few cell phones implement this optional API.

55 5.7.5. Summary Do we still fulfill the goal of mitigating basic and medium level attack vectors? This question is open for debate. We consider the first three new attack vectors (see Section 5.7.1 ‐ 5.7.3) unlikely to succeed since we believe that the combination of a traditional password and the OTP system pro‐ vides sufficient protection. The fourth attack vector (see Section 5.7.4) is tough however. This can be mitigated with a strict user policy, which we probably will be unable to enforce. To gain full protec‐ tion we must limit the use of the application to cell phones that we verify as unlikely to compromise the secret if connected to a computer controlled by an attacker. This is a feasible strategy but we inevitably end up in the classical conflict between security and usability.

Even when the application is used on a cell phone where the attack vector in Section 5.7.4 is fully feasible, an attack still has been made far more intricate to execute compared to an attack on tradi‐ tional passwords. Each organization considering the deployment of our application must compare the risk of an attack with the load and constraints put on their users.

56 Chapter 6 Design and Implementation of Smokey

In this chapter all design decisions preceding the actual implementation of Smokey will be pre‐ sented. Code documentation is excluded due to size constraints but is available online14.

6.1. Functional Requirement Specification Using the prototype, the output of the usability study and reasoning in Chapter 5, requirements according to Table 7 below have been identified.

Table 7: Requirement specification

ID Name Fulfilled C1 Generation of OTP:s x Details Application shall provide users the possibility to generate OTP:s upon request. From the start of an initialized (C3) application, no more than one key stroke shall be necessary to generate a new OTP. Rationale Main functionality and motivation of application. Comment

ID Name Fulfilled C2 Presentation of OTP:s I x Details OTP:s shall be displayed on a screen indicating only the password, an appropriate label (i.e. "One Time Password:") and device generated menus. Rationale Make it easy for the user to identify which output that constitutes the OTP. Comment

14 http://www.hassmund.se/smokey/

57 ID Name Fulfilled C3 Presentation of OTP:s II x Details OTP:s shown shall be removed from the screen after n seconds. N may be configurable upon deployment. Rationale The OTP is only valid for a certain amount of time (S7). Showing the password for too long would induce clock drift as the server continuously synchronizes its clock with the device.

Comment

ID Name Fulfilled C4 Initialization x Details Upon the first start of application it shall enter uninitialized state. In this state the only option available to the user shall be to provide an initialization key (initkey). After input of the initkey the application shall perform initialization according to initialization protocol (G2). If a valid init key is not provided, or the initialization fails, the application shall remain in the uninitialized state.

Rationale The downloadable package does not contain key material, this is synchronized during initia‐ lization. Comment

ID Name Fulfilled C5 Synchronization x Details Application shall provide a menu option to let users initiate a synchronization of counter and clock with server. Synchronization shall be carried out according to synchronization protocol (G3). Rationale If clock or counter gets out of sync, generated OTP:s will cease to work. Comment

ID Name Fulfilled C6 Exit application x Details Application shall provide a menu option to let the user exit the application. Rationale Base functionality. Comment

58 ID Name Fulfilled C7 Key storage x Details Counter and secret key shall be stored in non‐volatile memory of the mobile device. Java RMS may be used. If any other storage mechanism is used it shall be at least as protected as Java RMS. Any key material that is generated from device hardware parameters (i.e. IMSI or IMEI) shall not be stored by the application. Rationale Enable OTP generation offline. Comment

ID Name Fulfilled G1 Password algorithm x Details Passwords shall be generated based on two moving factors: A counter which should never be allowed to decrease and clock of the device. Passwords must appear as having a random distribution in the space of possible passwords. Rationale Strengthen security. Se explanation in Chapter 4. Comment Random distribution fulfilled by using the HOTP algorithm ID Name Fulfilled G2 Initialization protocol x Details The initialization protocol shall support initialization of device application and synchronize key material between device and server. The protocol shall hold the following properties: An initialization key is provided to the user out of band. The user enters the initialization key into the device by use of keypad. Device and server should agree on key material by using SMS, the protocol may also use HTTP. No secret data shall ever pass on the HTTP channel. Both the device and the server should contribute with key material. The clock of the device shall be included in the initialization. A server assigned serial number shall be assigned to the device during initialization.

Rationale C3 Comment

59 ID Name Fulfilled G3 Synchronization protocol x Details The synchronization protocol shall support synchronization of device clock and counter with the server. The synchronization protocol shall hold the following properties: HTTP shall be used for communication. Secret key material shall not be included in the protocol. Update of counter and clock must be authenticated. The counter must never be allowed to decrease, even if an attacker is able to break authentication of the protocol.

Rationale C3 Comment

ID Name Fulfilled S1 Administrative interface I ‐ create user x Details Administrators of the system shall be able to prepare initialization of new and current users in the system. Rationale Enable end user support Comment

ID Name Fulfilled S2 Administrative interface II ‐ disable user x Details Administrators of the system shall be able to disable users. When disabled the authentica‐ tion server should always consider one time passwords sent from this user as invalid. Rationale Enable end user support Comment

ID Name Fulfilled S3 Administrative interface III ‐ search user x Details Administrators of the system shall be able to search current users based on user‐id or phone number. When displayed the administrator should have the option to carry out S1 and S2. Rationale Enable end user support Comment

60 ID Name Fulfilled S4 Authentication of users x Details A Radius15 backend shall be provided acting as authentication server. The server shall take user‐id and one time password as input and indicate whether the password is accepted or not . Rationale Base functionality Comment

ID Name Fulfilled S5 Update of moving factor x Details When a valid OTP is given during Radius authentication, counter and clock difference shall be updated according to the given password. Rationale Prevent counter and clock drift. Comment

ID Name Fulfilled S6 Acceptance of counter drift x Details The server shall accept OTP:s if the counter used for generating the OTP matches the server counter c, c+1, ..., c+n where n is configurable upon deployment of system. Rationale Automatically let the system synchronize for a minor counter drift. Comment

ID Name Fulfilled S7 Acceptance of clock drift x Details The server shall accept OTP:s if the clock used for generating the OTP matches the server clock t, the stored clock difference between server and device d, t+d, t+d±1, ..., t+d±n where n is configurable upon deployment of system. Rationale Automatically let the system synchronize for a minor clock drift. We must also allow the user to take his time to enter the password. Comment

15 See Section 7.2

61 ID Name Fulfilled S8 Logging x Details The server shall log the following events: request of initialization, request of synchroniza‐ tion, failed login, accepted login, creation of initialization key and disabling user. Rationale Help debugging possible errors. Trace events in case of user complaints. Comment

ID Name Fulfilled S9 Throttling lock out for limited time x Details After a configurable number (e.g. 3) of failed attempts the token shall be locked out for a configurable number of minutes (e.g. 15). During this time no new logins shall be accepted unless the user performs a synchronization. Rationale Protect against brute force attacks Comment

ID Name Fulfilled S10 Throttling lockout indefinitely x Details After a configurable number of lockouts (as described by S9) without any intermediate successful login the token shall be locked for unlimited time. No new logins shall be accepted unless the user performs a synchronization. Rationale Protect against brute force attacks Comment

ID Name Fulfilled S11 Release of throttling locks x Details A successful synchronization shall immediately release any active lock as well as release other throttling parameters. Rationale Support usability and provide a way to securely bypass the lock Comment

6.2. Protocol Design Requirements G2 and G3 describe necessary protocols for enabling initialization (key exchange and synchronization of clocks) and synchronization of counter and clocks. The following section provides detailed specifications of the protocols.

62 6.2.1. Initialization Protocol As stated previously, the installable Java ME application is intended to be distributed uninitialized. In order to tie an instance of the application to a specific user, initialization is carried out according to the following description, illustrated in Figure 28 below. Note that we opt not to use HTTPS due to deficiencies in the Java ME implementation of SSL/TLS described in Section 5.6.

Before the actual key exchange an initialization key must be created (see step 1 ‐ 5 in Figure 28). The initialization key is built up from three parts: Identifier (ID), user authenticator (K1) and server authenticator (K2), all of which are six digits. When initialized, the phone contacts the server over HTTP identifying and authenticating the user with ID and K1 (6). If the request is valid, the server assigns the device a serial number (7) and the phone immediately stands by listening for SMS on a non standard port. The server sends the first 15 bytes of the shared secret to the phone by SMS (8); this message is authenticated with K2. When receiving the SMS the phone decides upon the last 5 bytes of the shared secret and transmits these (encrypted with the server assigned key) over HTTP (9). Full details of this process are provided in Table 8.

1. V erify ident ity, re 4 ques . De t key liver initia lizat User 0102- ion 0222- key 9431- 2 2479- . 5512-6172 Au th 0102- Initialization Key e en 0222- nt t 9431- 5 e ica 2479- . r p t 5512-6172 I h e ni o u tia Operator ne se Initialization Key li 3 no r, ze . k . ey Initialization Key

ID: Key ID. Corresponding user ID stored in database. ID-K1-K2 6 digits (0-9). K1: Client authentication key. Used by client to prove identity when User Phone Authentication Server 6 requesting initialization. . Init: ID:K1 (http) 6 digits (0-9) stand by for SMS K2: Server authentication key. 7. OK, serialno, Used by server to prove that SMS s) containing sa_key is authentic. 8. sa_key, K2 (sm 6 digits (0-9) 9. sa_key XOR phone_key : phone_time (http) Key exchange 10. OK serialno 4 byte hex string

sa_key 15 byte hex string

phone_key 5 byte hex string

(a one byte hex string is transferred as two characters)

Figure 28: Initialization protocol

63 Step 1‐5. User requests initialization string

1. Initialization begins with the user (or a representative of the user) contacting an operator responsible for activating users. The operator presumably belongs to an IT support depart‐ ment. 2. The operator uses an administrative interface to enter username and phone number of the user into the authentication server and requests a new initialization key on behalf of the user. 3. The authentication server creates a new initialization key (18 digits), stores this in its data‐ base and display this to the operator. 4. The operator gives the initialization key to the user. 5. The user enters the initialization key when requested (upon first start of application) on the cell phone key pad.

Step 6‐10. Key Exchange Protocol are shown in Table 8 below

64 Table 8: Detailed key exchange protocol

Client to server HTTP Step 6 in Figure 28 Purpose Request a new key exchange. Authenticate the client. Template http://path-to-server? action=init1&initID=ID&initK1=K1

Variables path_to_server Server URL and CGI‐path (e.g. authenticationserver.company.com/smokeyinit.cgi) ID Digit 1‐6 of initialization key (identify client, e.g. 124586) K1 Digit 7‐12 of initialization key (authenticate client, e.g. 881122) Example http://authenticationserver.company.com/smokeyinit.cgi?acti on=init1&initID=124586&initK1=881122

Server response HTTP Step 7 in Figure 28 Purpose Indicate success or failure of previous request Template OK:serial_number or ERROR Variable serial_number Server assigned serial number represented as a 4 byte hexadecimal string (e.g. abcdef12) Example OK:abcdef12

Server to client SMS Step 8 in Figure 28 Purpose Deliver server assigned part of shared secret and authenticate the server Template K2 server_assigned_key (Note: SMS shall be sent in binary format) Variables K2 Digit 13‐18 of initialization key digits converted to their corresponding ASCII values. If K2 is “456789” server will send the bytes [34, 35, 36, 37, 38, 39]. This part of the SMS authenticates the server. server_assigned_key 15 random bytes generated by the server (e.g. [79,8a,ae,5b,ec,6c,91,1f,30,ea,90,7f,65,b1,39]) Example [34,35,36,37,38,39,79,8a,ae,5b,ec,6c,91,1f,30,ea,90,7f,65,b1,39] Comment If no SMS is received within 120 seconds of the first HTTP request the client shall abort. The server shall allow a new synchronization but must then generate a new server_assigned_key.

Client to server HTTP Step 9 in Figure 28 Purpose Deliver phone assigned part of the secret key to the server, synchronize server clock with phone and acknowledge receipt of server_assigned_key Template http://path-to-server?action=init2&initID=ID &phKey=phone_key&phTime=phone_time Variables path_to_server Server URL and CGI‐path (e.g. authenticationserver.company.com/smokeyinit.cgi) ID Digit 1‐6 of initialization key (identify client, e.g. 124586) phone_key 5 byte phone key XOR:ed16 with the last 5 bytes of the server_assigned_key from previous step. Phone key: ff00112233 together with server_assigned_key 79,8a,ae,5b,ec,6c,91,1f,30,ea,90,7f,65,b1,39 would yield the string: 6f7f74930a phone_time Minutes since epoch. (e.g. 20844732) Example http://authenticationserver.company.com/smokeyinit.cgi? action=init2&initID=124586&initK1=881122&phKey=6f7f74930a& phTime=20844732

16 The XOR with the server key is used as one time encryption to protect the key material as it is sent over HTTP, which we consider as untrusted.

Server response HTTP Step 9 in Figure 28 Purpose Indicate success or failure of previous request Template OK or ERROR Variable serial_number Server assigned serial number represented as a 4 byte hexadecimal string (e.g. abcdef12) Example OK:abcdef12

6.2.2. Synchronization Protocol In order to synchronize with the server if clock or counter of client versus server gets too large, synchronization is provided according to requirements C5 and G3 in Table 7. The synchronization protocol is much less complex than the key exchange protocol since the secret key is in place and can be used to verify each request. Synchronizations work according to the following steps, illustrated in Figure 29 below.

Shared Key

User Phone Authentication Server 1. serialno, counter

, s_ctr), RAND 2. OK, max(p_ctr 3. time, HMAC(Ke y, time|ctr|RAND) 4. OK

Figure 29: Synchronization protocol

1. Client makes a HTTP request indicating its serial number and current counter. 2. The server compares the given counter value and compares it with the counter as it is known by the server. The maximum counter is returned. The server also returns a random value, RAND (user for authentication of the client in the next step). 3. If the server responds with a valid reply, the client makes a new HTTP request giving the current time and signs the concatenation of time, new counter and RAND with the shared key. 4. The server responds with OK if the signature is valid.

The client will thus not authenticate the server, but the counter and clock is not secret. The protec‐ tion relies on the shared key. Details of the protocol are provided in Table 9 below.

66 Table 9: Detailed synchronization protocol

Client to server HTTP Step 1 in Figure 29 Purpose Request a counter and time synchronization. Update counter. Template http://path-to-server?action=synchronize& serial=serial_number&counter=client_counter Variables path_to_server Server URL and CGI‐path (e.g. authenticationserver.company.com/smokeyinit.cgi) serial_number Client’s serial number in base‐10 as assigned in the key exchange protocol. (e.g. 30). client_counter Client’s current counter in base‐10 (e.g. 36). If the client gives a smaller counter than the server synchronization shall be denied by server. Example http://authenticationserver.company.com/smokeyinit.cgi? action=synchronize&serial=30&counter=36

Server response HTTP Step 2 in Figure 29 Purpose Provide new counter to be used on successful completion. Provide a tracking ID to be used at step 3. Provide a random value (challenge) to use for authentication of client. Template OK:maxcounter:rand:request_id or ERROR Variables maxcounter The maximum value of server versus client counter. Client must abort if the given value is less than the current counter. Value shall be given as a 4 byte hexadecimal integer (e.g. 00000024). rand Random value to be used for authentication in next request. Value shall be given as a 15 byte hexadecimal integer (e.g. 20adbe78912fe0a25413782a7deaac). request_id Identifier to be used in the next step. Value shall be given as a 4 byte hexadecimal integer (e.g. 00000016). Example OK:00000024:20adbe78912fe0a25413782a7deaac:00000016

Client to server HTTP Step 3 in Figure 29 Purpose Synchronize clock and authenticate the request. Template http://path-to-server? action= synchronize& action=synchronize2&serial=serial_number&time=client_time& authentication=auth_string&requested=request_id; Variables serial_number Client’s serial number in base‐10 as assigned in the key exchange protocol (e.g. 30). client_time Client’s time represented as minutes since epoch in base‐10. auth_string HMAC‐SHA1(Key, client_time | counter_base16 | rand) where Key is the shared key (e.g. d5d130643fe3be09228556edfecef06de480ec38), client_time, rand and counter_base_16 are formatted according to step 2 and 3. Using values given values yields the following auth_string: 2652b841ae2b9f9fc56be260a1d0d37c8b3a6955 request_id Identifier as given in step 2 (e.g. 00000016). Example http://authenticationserver.company.com/smokeyinit.cgi? action=synchronize2&serial=30&time=20845950&authentication=2 652b841ae2b9f9fc56be260a1d0d37c8b3a6955&requestid=00000016

Server response HTTP Step 4 in Figure 29 Purpose Confirm synchronization or indicate error. Template OK or ERROR

67 6.3. Backend Database Design Using the requirement and protocol specifications in the previous sections we propose the database design shown in the ER diagram of Figure 30 below. Each token (device) is assigned a serial number. For each token the associated user and phone number are stored together with the shared key, counter and time offset to use. Each token might wait for initialization or may have requested syn‐ chronization.

The token entity is augmented with a property to track if the token previously was locked out as a result of failed login attempts (throttling). In order to implement the requirements S9 ‐ S11 we must also keep track of the last failed attempt as well as the total number of failed attempts and the number of times the token has been locked out without successful login. These parameters are designed to belong to the FAILED_ATTEMPT entity.

An alternative database design is shown in Figure 31. This design would allow a single user to use the application together with several cell phones. Using several phones would however require the server to keep track of which device that is used at each time. There exists a slight chance that a particular OTP would be valid for two tokens at the same time. In order to keep the application sim‐ ple we opt for the design proposed in Figure 30 below.

time_offset shared_key counter

phoneno is_locked_out

userid 1N TOKEN HAS REQUESTED SYNCHRONIZATION

serialno

request_id rand

new_counter

1 1

WAITS_FOR HAS

N 1

FAILED ATTEMPT INITIALIZATION

last_attempt throttle_level init_id server_assigned_key

fail_counter init_K2 init_K1

Figure 30: ER-diagram of backend database

Figure 31: Alternative database design allowing several tokens for each user

Figure 32: ER-diagram of Figure 30 mapped to relations

69 The mapping of the ER‐diagram (Figure 30) to relations is shown in Figure 32 above. In the figure we note a standalone table initid_pool which represents a hack in order to provide randomness and uniqueness of the key initID of table initialization. According to the specification initID is a six digit field that maps a token to be initialized to a specific user. We would prefer if this value was not easy to predict. More important: at no time two initialization keys with the same initID may exist.

Upon creation of new initialization keys we might use a random number generator to choose a new initID and then check if this already exists in the table initialization. This process, illustrated in Figure 33 below, would have to be repeated until we find a free initID. If many initialization keys are active at the same time this might lead to serious performance issues as each step in the loop would require a SQL‐query. The hack referred to takes the following approach, presented in Figure 34, instead:

Before deploying any initialization keys the initid_pool tables is populated with all integers from 0 to 999 999. When a new initID is needed a random row from the pool is picked, the requested id is removed from the pool as long as the initialization key is valid. When the initialization key is removed (for example because it has been used) the id is put back in the pool and available for reuse. It is important that we allow reuse of id:s since we are limited to 1 000 000 keys.

Figure 33: Inefficient solution when few ID:s are free Figure 34: Efficient loop-free solution

70 6.4. Server Implementation The choice of language to implement the server in is of less importance, we opt to use the Perl programming language. Perl is, in the author’s opinion, productive during development and suffi‐ ciently fast for deployment. The server application will be built as a Perl module hierarchically orga‐ nized according to Figure 35. The decision to divide the code into the sub modules shown in Figure 35 is solely made to support maintainability and make it easy to find the right place for work on different parts of the server.

ConfigParams.pm Smokey.pm otpinit.cgi

Database.pm Login.pm Initialization.pm Synchronization.pm Admin.pm HOTPAlgorithm.pm

Figure 35: Hierarchic organization of server components

As we want to support customization of the product for different needs all system administrator configurable parameters are stored in a separate module ConfigParams.pm. Customizable options include the following:  Database options (host, name, user, password, port)  SMS Request API URL  Log file  Throttling attempts; number of attempts before activating lock  Throttling time; minutes lock should be active  Throttling levels; how many times a temporary lock should be issued before locking the token indefinitely  Time unit (e.g. 60 seconds)  Time window; how much time drift that shall be accepted  Counter window; how much counter drift that shall be accepted

The mobile devices will call otpinit.cgi which will just dispatch function calls to relevant modules.

A brief summary of the different modules purposes is shown in Table 10 below.

Table 10: Organization of server code

Module Purpose Smokey.pm Generic functionality that is not specific enough to fit in any sub module Database.pm Generic database interface. Specific SQL queries are placed in other sub modules Login.pm Code related to verify login requests and implement throttling Initialization.pm Code related to initialization Synchronization.pm Code related to synchronization Admin.pm Implementation of administrative interface HOTPAlgorithm.pm Implementation of the HOTP algorithm otpinit.cgi CGI called by devices ConfigParams.pm Deployment configuration

71 6.5. Client Application Implementation As previously stated, Java ME will be used for the implementation of the client. Java ME is in practice the only available option if we want to target as many cell phones as possible. We will aim to restrict development to using the CLDC and MIDP 2.0 specifications and refrain from using vendor specific APIs in order to further support compatibility. The only exception to this regards reading the cell phone’s IMEI17 number. This is unfortunately not a part of the MIDP specification and is instead read out as a system property (e.g. System.getProperty("com.sonyericsson.imei")). The application will include code to read this property from the following vendors: Sony Ericsson, Nokia, Siemens, Samsung and Motorola.

In order to keep the source code maintainable as the application evolves we will follow the Model View Controller (MVC) design pattern [76] (or at least a variant thereof18). Smokey.java will act as our primary class and constitute the controller; it will also extend the MIDlet class. Implementing the MVC design pattern we aim to place all program logic in the Model class. The controller and model classes are shown in Figure 36 below. The figure also shows that storage of persistent data is main‐ tained by the separate class Storage.

<> Model MIDlet MessageListener -currentView -nextView +byteArrayToHexString() +byteArrayToInt() Storage +clearAndCreateStore() 1 +getServerAssignedSecret() +extractKeys() +getCounter() +generateOTP() +getSerialNumber() Smokey (controller) +getCurrentView() +increaseCounter() -model +getIMEI() +getIMEIhash() -activeView 1 +getNextView() +exitMIDLET() +getPhoneTime() +handleException() 1 +getSerial() +notifyIncomingMessage() +getSharedKey() +updateDisplay() +httpGet() +intToByteArray() +processIncomingMessage() +readStorage() +requestInitialization() +setCurrentView() +setInitFields() +setNextView() +setSerial() +startListening() +stopListening() +synchronizeClockAndCounter()

Figure 36: UML diagram of the classes: Smokey, Model and Storage

All user interaction will be managed in views and one view class is defined for each major part of the user interface. To implement minor tasks (i.e. alerts and text inputs) internal classes will be used. Figure 37 below shows all views.

As with the server application we wish to support customization of the application. In order to do this we opt to locate any configurable parameter as static variables in a separate class, called ConfigParams. It is critical that the client and the server use the same time unit (e.g. 60 seconds) when calculating OTP:s. Moreover the client must know which URL to use when requesting initializa‐ tion and synchronization. Most other options will refer to text strings.

17 International Mobile Equipment Identity 18 We will deviate from the MVC pattern allowing application behavior (controller) code in view classes.

Figure 37: UML-diagram of view classes

Chapter 7 Reference Deployment

In this chapter we show how the Smokey application can be integrated with a commercial VPN appliance. The combination of Smokey and traditional user passwords will provide a significant increase of confidence in that only valid users may connect through the VPN.

This chapter contains code snippets interspersed in the text; we opt not to reference to these code snippets as figures in order to make the presentation cleaner.

7.1. The Cisco ASA VPN Appliance As VPN appliance we will use the Cisco Adaptive Security Appliance (ASA) 5505. This device provides a lot of configurable options; most out of the scope of this thesis. In the rest of this chapter we assume that the appliance is already configured as a VPN device, however without any authentica‐ tion methods set up yet.

The Cisco ASA provides both a clientless VPN web proxy and a VPN Client (named Any Connect) installed on the user’s computer. We will show how to configure the device to use Smokey in combi‐ nation with local (traditional) passwords for authentication of users no matter if the web interface or the client is used.

We will use the Remote Authentication Dial in User Service (Radius) [77] authentication protocol to make the VPN communicate with Smokey. To allow this we use the Freeradius [78] server to tie the Radius queries generated by the VPN to the Smokey server.

7.2. Radius Authentication Protocol The Cisco ASA 5505 VPN appliance supports a variety of authentication protocols including Radius, Tacacs+ [79], Kerberos [80], LDAP [81] as well as authentication towards a Windows NT domain or a web CGI. We opt to use Radius since this protocol in essence is designed to validate users from an arbitrary source which fits our purpose nicely.

The Radius protocol provides capabilities to carry authentication, authorization and configuration information between a client, called the Network Access Server (NAS), and a Radius server. In our application we will only use a fraction of the capabilities of the Radius protocol and will thus not go into details of the protocol. In a simplistic approach our configuration can be defined as in Figure 38 below. The VPN appliance itself will constitute the NAS in terms of Radius. The NAS will query the Freeradius server which in turn is configured to use the Smokey Server API.

75 Smokey Perl API Freeradius Radius server

t s e u q t e p R e s c s c e A c s c s OTP A e c c A UserID, OTP, Password

Cisco ASA 5505 Local User NAS user DB

Figure 38: Authentication using Radius 7.3. Freeradius Configuration The full configuration of Freeradius is complex and not within the scope of this thesis. Using the default configuration however, only slight changes are necessary in order to get the server to work together with Smokey and the Cisco ASA 5505 VPN.

The first step necessary is to add the VPN as a Radius NAS client, which allows the NAS to communi‐ cate with the server. We accomplish this by adding the following section to the file /etc/raddb/clients.conf: client IP-address_of_NAS { secret = Shared_secret_of_NAS_and_Radius_server shortname = smokeyotpnas }

As shown in Section 6.4 the Smokey server provides an API to use for authentication. The function verifyOTP($userid, $otp), located in Login.pm is used to check a given username and OTP for validity. Fortunately, the Freeradius server has built in support to use Perl scripts as a source of authentication. This makes tying Freeradius to Smokey a trivial operation.

Using the guidelines of the Freeradius Rlm_perl wiki [82] the following steps are taken to configure Freeradius to use Smokey:

 Add Perl support to section Modules and state which Perl script that should responsible for authentication queries in /etc/raddb/radiusd.conf: perl { #module = /path/to/your/perl_module.pm module = /etc/raddb/smokey.pl }

 Add Perl as authentication method to the section Authentication in file /etc/raddb/radiusd.conf: Auth-Type Perl { perl }

76  Add Perl as authentication in user database file /etc/raddb/users: DEFAULT Auth-Type = Perl Fall-Through = 1

The script /etc/raddb/smokey.pl is used to process queries. Using the sample script provided with the Freeradius installation as base, all we need is to replace the default authenticate func‐ tion as below:

# Function to handle authenticate use Smokey::Login.pm sub authenticate { if (&verifyOTP( $RAD_REQUEST{'User-Name'}, $RAD_REQUEST{'User-Password'})) { return RLM_MODULE_OK; } else { return RLM_MODULE_REJECT; } } 7.4. Cisco ASA 5505 Configuration A step by step configuration of the Cisco ASA 5505 is available in Appendix III.

7.5. Sample Run Sample login screens using the fully configured Cisco ASA with Smokey are shown in Figure 39 and Figure 40 below.

Figure 39: Web based VPN login Figure 40: Any Connect VPN client login

Chapter 8 Summary and Conclusions

This chapter summarizes the outcome of this master thesis, provides some conclusions and suggests further work.

8.1. Attack Vectors, Authentication Methods and Threat Assess ment In this thesis we have identified and presented prominent attack vectors and authentication methods. In lack of any established method for comparing authentication methods we have sug‐ gested a technique to rank methods according to the applicability of identified attack vectors. The attack vectors are classified as basic, medium or advanced based on distinct and objective principles. When calculating the rank of each method consideration is taken to the classification of each attack vector. This approach allows new attack vectors to be included in future use of the ranking scheme.

8.2. Suggested Authentication Method When deciding upon the authentication methods indicated by the performed ranking we have aimed to attain an appropriate combination of security and usability. The intended users of the method are reflected in the requirements of both these parameters. We suggest the use of a cell phone as a synchronizable onetime password generator. Based on this idea we have built a proto‐ type called Smokey and conducted a usability evaluation. The evaluation confirms that we are on the right track considering the usability aspects.

The proposed solution entails new security threats, particularly regarding the storage of private keys on the cell phone. The cell phone is considered as trusted in relation to the client computer, but when interconnected with the computer via Bluetooth or USB the computer may access private key storage under certain circumstances. Given that an attacker gains access to the private storage the method may be compromised. Protection towards this kind of attack is limited to the use of certain models or educating users of the system according to the problem.

8.3. Implementation and Deployment Requirement specifications, protocol and database design have been created for the suggested system. The system itself has been implemented by a server part written in Perl and a client Java ME application. Finally we have shown how the system is deployed on a commercial VPN appliance by using the Radius authentication protocol to interconnect the VPN appliance with the server applica‐ tion.

79 8.4. Future Work The suggested scheme of ranking of authentication methods can easily be extended with new methods and new attack vectors. The current principles of weighting the impact of different attacks based on their classification is intended to be clear and unbiased. The scheme might however be improved by weighting each attack vector/method pair based on whether a successful attack gains access to credentials usable a single session or in a repeatable manner. For instance an attack dis‐ closing the private key of a PKI based method might be weighted higher than an attack disclosing a key valid for one session only. Furthermore the weighting might be influenced based on how successful attack vectors have proven to be in real world attacks. A challenge when developing the method furthermore is to enforce objectiveness.

The security threats regarding storage of private key data within the Smokey application can be mitigated by utilizing the Java ME Security and Trust Services API briefly presented in Section 2.6.2. This however requires users of the system to upgrade their cell phones to models supporting trusted third party access to Security Elements. Furthermore the Smokey application needs to be signed with a code signing certificate issued by a certificate authority trusted by all cell phones using the system.

80 Bibliography

The sources are listed in the order they first appear in the text.

[1] Smith, R. E. Authentication, From Passwords to public Keys. 2001. ISBN: 0201615991.

[2] Gollmann, D. Computer Security:John Wiley & Sons, 2006. ISBN: 0470862939.

[3] Rosen, K. H. Elementary Number Theory. 5th edition: Pearson, Addison Wesley, 2005. p. 202. ISBN: 0321237072.

[4] Trappe, W. and Washington, L. C. Introduction to Cryptography with Coding Theory: Pearson Education, 2006. ISBN: 0131862391.

[5] Rivest, R. The MD5 Message‐Digest Algorithm. The Internet Engineering Task Force. [Online] 1992. [Cited: 10 20, 2009.] http://www.ietf.org/rfc/rfc1321.txt.

[6] Eastlake, D. and Jones, P. US Secure Hash Algorithm 1 (SHA1). The Internet Engineering Task Force. [Online] 2001. [Cited: 10 20, 2009.]

[7] Ferguson, N. and Schneier, B. Practical Cryptography: Wiley Publishing Inc., 2003. ISBN: 0471223573.

[8] Krawczyk, H., Bellare, M. and Canetti, R. HMAC: Keyed‐Hashing for Message Authentication. The Internet Engineering Task Force. [Online] 1997. [Cited: 10 22, 2009.] http://www.ietf.org/rfc/rfc2104.txt.

[9] Bishop, M. Computer security art and science. Boston, MA: Addison‐Wesley, 2003. ISBN: 0201440997.

[10] Dierks, T. and Rescorla, E. RFC 5246 ‐ The Transport Layer Security (TLS) Protocol Version 1.2. The Internet Engineering Task Force. [Online] 2008. [Cited: 03 29, 2009.] http://tools.ietf.org/html/rfc5246.

[11] McAfee Inc. Glossary. Antivirus Software and Internet Security for Your PC. [Online] [Cited: 11 01, 2009.] http://home.mcafee.com/VirusInfo/Glossary.aspx?ctst=1#M.

[12] F‐Secure. Malware Code Glossary. [Online] [Cited: 02 07, 2009.] http://www.f‐secure.com/glossary/eng/malware‐code‐glossary.shtml.

[13] Wikimedia Foundation Inc. Malware. Wikipedia. [Online] [Cited: 02 07, 2009.] http://en.wikipedia.org/wiki/Malware.

i [14] Microsoft Corp. Defining Malware: FAQ. Microsoft TechNet. [Online] 2003. [Cited: 02 07, 2009.] http://www.microsoft.com/technet/security/alerts/info/malware.mspx.

[15] Kienzle, D. M. and Elder, M. C. Recent Worms: A Survey and Trends. Washington, D.C., USA: ACM, 2003. Proceedings of the 2003 ACM workshop on Rapid malcode. ISBN: 1581137850

[16] Moshchuk, A., Bragin, T., Gribble, S. D. and Levy, H. M. A Crawler‐based Study of Spyware on the Web. Department of Computer Science & Engineering, University of Washington, 2006. Proceedings of the 13th Annual Network and Distributed System Security Symposium (NDSS '06).

[17] Kruegel, C., Robertson, W. and Vigna, G. Detecting Kernel‐Level Rootkits Through Binary Analysis: IEEE Computer Society, 2004, Computer Security Applications Conference, Annual.

[18] King, S. T., Chen, P.M., Wang Y.‐M., Verbowski, C., Wang H. J. and Lorch, J.R. SubVirt: implementing malware with virtual machines. 2006. Security and Privacy, 2006 IEEE Symposium.

[19] The Trusted Computing Group. Trusted Computing Group. [Online] [Cited: 03 29, 2009.] https://www.trustedcomputinggroup.org.

[20] Oppliger, R. and Rytz, R. Does Trusted Computing Remedy Computer Security Problems? Security & Privacy, IEEE. 2005, Vol. 3, 2, pp. 16‐19. ISSN: 15407993

[21] Anderson, R. ‘Trusted Computing’ Frequently Asked Questions. [Online] 2003. [Cited: 03 29, 2009.] http://www.cl.cam.ac.uk/~rja14/tcpa‐faq.html.

[22] Sun Microsystems Inc. Java ME. [Online] http://java.sun.com/javame/index.jsp.

[23] Li, S. and Knudsen, J. Beginning J2ME Platform; From Novice to Professional. Heidelberg: Springer‐Verlag, 2005. ISBN: 1590594797.

[24] JSR 118 Expert Group. Mobile Information Device Profile for Java™ 2 Micro Edition Version 2.0. Java Community Process. [Online] November 5, 2002. [Cited: 12 27, 2009.] http://jcp.org/aboutJava/communityprocess/final/jsr118/index.html.

[25] Forum.Nokia.com. Java Security Domains ‐ Forum Nokia Wiki. [Online] November 25, 2009. [Cited: 12 27, 2009.] http://wiki.forum.nokia.com/index.php/Java_Security_Domains.

[26] JSR 177 Expert Group. Security and Trust Services API (SATSA) for Java™ 2 Platform, Micro Edition Version 1.0.1. [Online] August, 2007. [Cited: 12 27, 2009.] http://jcp.org/aboutJava/communityprocess/mrel/jsr177/index.html.

[27] Burr, W., Dodson, D.F. and Polk, W.T. Electronic Authentication Guideline, Recommendations of the National Institute of Standards and Technology: National Institute of Standards and Technology, 2006.

[28] Sveriges IT‐incidentcentrum. FR03‐01 Lösenord. PTS, SITIC, Sveriges IT‐incidentcentrum. [Online] 2005. [Cited: 03 29, 2009.] http://www.sitic.se/foerebyggande‐atgaerder/forebyggande‐rad/fr03‐01‐losenord/. ii [29] Outpost9.com. Word Lists. [Online] 2005. [Cited: 07 29, 2009.] http://www.outpost9.com/files/WordLists.html.

[30] Walsh, N. ATM fraud prompts card rethink? Card Technology Today. 2005, Vol. 17, 2, p. 10.

[31] Larsson, L. and Westerholm, J. Bilddagboken hackad ‐ 235 000 konton sprids. www.idg.se. [Online] April 11, 2008. [Cited: 03 16, 2009.] http://www.idg.se/2.1085/1.139967.

[32] Larkin, E. Safety Precautions for Monster.com Users after Hack Attack. Network World. [Online] January 27, 2009. [Cited: 03 16, 2009.] http://www.networkworld.com/news/2009/012709‐safety‐precautions‐for‐monstercom‐ users.html.

[33] Muncaster, P. Spotify user details compromised in major hack. vnunet.com. [Online] March 5, 2009. [Cited: 03 16, 2009.] http://www.vnunet.com/vnunet/news/2237872/spotify‐ hacked.

[34] stupid.domain.name. Passwords. [Online] January 3, 2008. [Cited: 03 16, 2009.] http://stupid.domain.name/node/514.

[35] Chahrvin, S. Keyloggers ‐ your security nightmare? Computer Fraud & Security. July, 2007, 7, pp. 10‐11. ISSN: 13613723.

[36] Keelog.com. [Online] [Cited: 07 29, 2009.] http://www.keelog.com/.

[37] Winkler, I. S. and Dealy, B. Information Security Technology? … Don’t Rely on It. A case study in social engineering Salt Lake City: USENIX Association, 1995. Proceedings of the 5th conference on USENIX UNIX Security Symposium, volume 5.

[38] Mitnick, K. The art of deception controlling the human element of security. Indianapolis, Ind: Wiley, 2002. ISBN: 076454280X

[39] The Anti‐Phishing Working Group. The Anti‐Phishing Working Group. [Online] [Cited: 25 06, 2009] http://www.antiphishing.org/.

[40] Jagatic, T. N., Johnson, N. A., Jakobsson, M and Menczer, F. Social phishing. Communications of the ACM. 2007, Vol. 50, 10, pp.94‐100. ISSN: 00010782

[41] Dhamija, R., Tygar, J. D. and Hearst, M. Why phishing works. New York, N.Y., USA: ACM, 2006. CHI '06: Proceedings of the SIGCHI conference on Human Factors in computing systems.

[42] Tipton, H. F. and Krause, M. Information security management handbook: Auerbach, 2004. ISBN: 0849319978.

[43] Ollmann, G. The Pharming Guide. Next Generation Security Software. [Online] [Cited: 11 01, 2009.] http://www.ngssoftware.com/papers/ThePharmingGuide.pdf.

iii [44] Eldeklint, J. and Gunnbäck, J. Practical WLAN security. Department of Computer and Information Science, Information Security, Second Course. [Online] 2009. [Cited: 11 01, 2009.] http://www.ida.liu.se/~TDDD17/oldprojects/2009/projects/014.pdf.

[45] Gühring, P. Concepts against Man‐in‐the‐Browser Attacks. [Online] January 24, 2007. [Cited: 08 03, 2009.] https://svn.cacert.org/CAcert/SecureClient.pdf.

[46] Thomsen, D. IP spoofing and session hijacking. Issue 3, 1995, Network Security, pp. 6‐11.

[47] Kristol, D. and Montulli, L. HTTP State Management Mechanism. The Internet Engineering Task Force. [Online] 2000. [Cited: 08 03, 2009.] http://tools.ietf.org/rfc/rfc2965.txt.

[48] Endler, D. The Evolution of Cross‐Site Scripting Attacks. cgiscurity.com. [Online] May 20, 2002. [Cited: 08 03, 2009.] http://www.cgisecurity.com//lib/XSS.pdf.

[49] Suo, X., Zhu, Y. and Owen, S. G. Graphical Passwords: A Survey: IEEE, 2005. Proceedings of the 21st Annual Computer Security Applications Conference.

[50] Adams, A. and Sasse, M. A. Users Are Not The Enemy. Communications of the ACM. 1999, Vol. 42, 12. ISSN:00010782

[51] Kotadia, M. ZDNet Australia. [Online] 2005. [Cited: 03 16, 2009.] http://www.zdnet.com.au/news/security/soa/Microsoft‐Write‐down‐your‐ passwords/0,130061744,139193117,00.htm.

[52] Hilley, S. Citibank cuts off bank spies with virtual keyboard Info Security magazine. [Online] February 16, 2005. [Cited: 01 30, 2009.] http://www.infosecurity‐magazine.com/news/050216_Citibank_keyboard.html.

[53] CA Inc. Win32.Dumaru.E. CA Inc. [Online] 2004. [Cited: 10 17, 2009.] http://www.ca.com/us/securityadvisor/virusinfo/virus.aspx?id=37400.

[54] Mohanty, D. Defeating Virtual Keyboard Protection. Coffee and Security. [Online] September 12, 2008. [Cited: 01 30, 2009.] http://www.coffeeandsecurity.com/resources/papers/defeat‐ vk.pdf.

[55] Kuhn, M. OTPW – A one‐time password login package. [Online] 2003. [Cited: 03 30, 2009.] http://www.cl.cam.ac.uk/~mgk25/otpw.html.

[56] Lamport, L. Password authentication with insecure communication. Communications of the ACM. 1981, Vol. 24, 11, pp. 770‐772.

[57] Haller, N. The S/KEY one‐time password system. 1994. In Proceedings of the Internet Society Symposium on Network and Distributed Systems.

[58] Haller, N., Metz, C., Nesser,P. Straw, M. A One‐Time Password System, RFC 2289. The Internet Engineering Task Force. [Online] February, 1998. [Cited: 03 23, 2009.] http://www.ietf.org/rfc/rfc2289.txt.

iv [59] Nash, A., Duane, B., Brink, D. and Joseph, C. PKI, Implementing and Managing E‐Security: RSA Press, 2001. ISBN: 0072131233.

[60] M'Raihi, D., Hoornaert, F., Naccache, D. and Ranen, O. HOTP: An HMAC‐Based One‐Time Password Algorithm. The Internet Engineering Task Force. [Online] December, 2005. [Cited: 08 10, 2009.] http://www.ietf.org/rfc/rfc4226.txt.

[61] Federal Financial Institutions Examination Council. Authentication in an Internet Banking Environment. [Online] 2001 [Cited: 08 03, 2009.] http://www.ffiec.gov/pdf/authentication_guidance.pdf.

[62] Kurose, J. F. and Ross, K. W. Computer Networking; A Top‐Down Approach: Addison Wesley, 2007. p. 48. ISBN: 0321497708.

[63] Wu, M., Garfinkel, S. and Miller, R. Secure Web Authentication with Mobile Phones. [Online] 2004. [Cited: 03 24, 2009.] http://homepage.mcs.vuw.ac.nz/~ian/shared/papers/secureweb.pdf.

[64] Clarke, D., Gassend, B., Kotwal, T., Burnside, M, van Dijk, M., Devadas, S. and Rivest, R. The Untrusted Computer Problem and Camera‐Based Authentication. Pervasive Computing. 2002.

[65] Tullis, T. and Albert, B. Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics: Morgan Kaufmann, 2008. pp. 138‐139. ISBN: 0123735580.

[66] Aladdin Knowledge Systems Ltd. SafeWord ‐ Two‐factor Authentication. [Online] [Cited: 09 30, 2009.] http://www.aladdin.com/safeword/.

[67] Brooke, J. SUS: a 'quick and dirty' usability scale. Usability Evaluation In Industry: CRC Press, 1996.

[68] Tullis, T. and Albert, B. SUS Scores from 129 conditions in 50 studies. Measuring the User Experience. [Online] [Cited: 01 09, 2009.] http://www.measuringuserexperience.com/SUS‐scores.xls.

[69] Klingsheim, A. N., Moen, V. and Hole, K. J. Challenges in Securing Networked J2ME Applications. Computer. 2007, Vol. 40, 2.

[70] Sun Microsystems Inc. javax.microedition.rms (MID Profile). Sun Developer Network. [Online] 2006. [Cited: 08 17, 2009.] http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/rms/package‐ summary.html.

[71] Mahmoud, Q. Getting Started with the FileConnection APIs. Sun Developer Network. [Online] December, 2004. [Cited: 08 17, 2009.] http://developers.sun.com/mobility/apis/articles/fileconnection/index.html.

[72] Egeberg, T. Storage of sensitive data in a Java enabled cell phone: Gjøvik University College. 2006

v [73] Mahoney, W. R. and Pokorny, C. A. Do‐It‐Yourself Guide to Cell Phone Malware. International Journal of Computer Science and Network Security. 2009, Vol. 9, 1.

[74] Carettoni, L., Merloni, C. and Zanero, S. Studying Bluetooth Malware Propagation: The BlueBag Project. IEEE Security and Privacy. 2007, Vol. 5, 2, pp.17‐25. ISSN:1540‐7993

[75] Sun Microsystems Inc. Security and Trust Services API for J2ME (SATSA); JSR 177. Sun Developer Network. [Online] [Cited: 08 18, 2009.] http://java.sun.com/products/satsa/.

[76] Sun Microsystems Inc. Java BluePrints Model‐View‐Controller. Java BluePrints ‐ J2EE Patterns. [Online] [Cited: 08 29, 2009.] http://java.sun.com/blueprints/patterns/MVC‐ detailed.html.

[77] Rigney, C., Willens, S., Rubens, A. and Simpson, W. Remote Authentication Dial In User Service (RADIUS). The Internet Engineering Task Force. [Online] June, 2000. [Cited: 09 16, 2009.] http://www.ietf.org/rfc/rfc2865.txt.

[78] The FreeRADIUS Server Project. The FreeRADIUS Project. FreeRADIUS: The world's most popular RADIUS Server. [Online] [Cited: 09 16, 2009.] http://freeradius.org/.

[79] Carrel, D. and Grant, L. The TACACS+ Protocol (draft). The Internet Engineering Task Force. [Online] 1997. [Cited: 09 16, 2009.] http://tools.ietf.org/html/draft‐grant‐tacacs‐02.

[80] Neuman, C., Yu, T., Hartman, S. and Raeburn, K. The Kerberos Network Authentication Service (V5). The Internet Engineering Task Force. [Online] 1993. [Cited: 10 10, 2009] http://www.ietf.org/rfc/rfc4120.txt.

[81] Sermersheim, J. Lightweight Directory Access Protocol (LDAP): The Protocol. The Internet Engineering Task Force. [Online] 2006. [Cited: 09 16, 2009.] http://www.ietf.org/rfc/rfc4511.txt.

[82] The FreeRADIUS Project. Rlm_perl. FreeRADIUS Wiki. [Online] [Cited: 09 16, 2009.] http://wiki.freeradius.org/Rlm_perl .

[83] ActivCard Synchronous Authentication. Presence Security Solutions. [Online] 1997. [Cited: 03 23, 2009.] http://www.presence‐security.co.uk/files/whitepapers/ synchronous_authentication.pdf.

[84] Audebert, Y. System and Method for User Authentication having Clock Synchronization. US005887065A 1999.

[85] Schneier, B. Attack Trees. Dr. Dobb's Journal December. December, 1999.

[86] Federal Financial Institutions Examination Council. [Online] [Cited: 08 03, 2009.] http://www.ffiec.gov/about.htm.

[87] Merriam‐Webster Inc. Dictionary & Thesaurus. Merriam‐Webster. [Online] [Cited: 08 12, 2009.] http://www.merriam‐webster.com/.

vi [88] Li, S. and Knudsen, J. Beginning J2ME Platform; From Novice to Professional. Heidelberg: Springer‐Verlag, 2005. ISBN: 1590594797.

[89] Cisco Systems Inc. Cisco Security Appliance Configuration Guide using ASDM. Cisco Systems Inc. [Online] 2009. [Cited: 09 17, 2009.] http://www.cisco.com/en/US/docs/security/asdm/6_2/user/guide/asdmug.pdf.

vii

Appendix I Usability Evaluation Instruction

The following instruction where used in the usability evaluation of the one time password generator prototype presented in Section 5. The instruction where printed as a booklet so that each set of tasks (related to one questionnaire) where shown on a single spread.

Usability evaluation

Prototype of a one time password authentication system

Note: This is an English translation of an originally Swedish usability study instruction. All screenshots are therefore in Swedish. 1. Introduction

Before you start the actual evaluation of the authentication tool we will give you a brief introduction to the cell phone that is used in this evaluation

When you are not in any menu the phone is said to be in stand by mode.

Task 1: Navigate to standby

The key shown to the right is called the back key.

Push and hold down the back key in order to navigate to standby mode. You may also push the back key several times instead of holding it down..

When you are done the screen shown on the big picture to the right is displayed.

You can always navigate back to standby mode by repeating task 1 above.

In order to navigate in menues you will use the navigation key. This is, the big quadratic key which really is five different keys. The round key in the middle selects a choice when inside a menu.

Task 2: Go to the main menu

Open the main menu by pushing the round key in the middle of the navigation key.

When you are done the screen to the left is displayed on the phone.

2. Open the Applications menu

In order to start the authentication application you will need to navigate to the Applications menu.

Task 3 and task 4 will help you accomplish this.

Task 3: Select ”Organizer”

This task presumes that you are in the main menu. If you are not in the main menu repeat task 1 and task 2.

Use the navigation key to select and choose Or- ganizer in the main menu. This option is indicated by a red quadrant in the picture to the right.

When you are done the picture to the left is displayed.

Task 4: Select Applications

This task presumes that you are in the menu “Organizer”. If you are not repeat task 1-3.

Use the navigation key to select and choose the Applica- tions option.

When you are done the picture to the left is displayed. 2. Open the Applications menu

Questionnaire 1

You will now be asked to respond to a questionnaire regarding the information shown on the last spread and the interaction of the cell phone. 3. Try a shortcut

It required quite a lot of key strokes in order to navigate to the Applications menu. On the phone in this evaluation there is a shortcut in order to navigate faster to the menu.

Task 5: Use the shortcut

Make sure that the phone is in standby mode (repeat task 1 if necessary).

Open the Applications menu by pressing the left part of the navigation key.

Now the Application menu should be opened once again.

Questionnaire 2

You will now be asked a few questions regarding the shortcut.. 3. Log in

Soon you will try the authentication tool. Before you start you should be aware of the following:

In most modes of the phone you may use the selection keys. The function of these keys are decided by the text shown on the screen above them.

The picture to the right shows the selection keys and the current functions tied to them.

Task 6: Start LiU OTP Suite

Open the Applications menu by whichever method you prefer. That is, repeat task 1-4 or task 1 and 5.

Select and choose LiU OTP Suite. The phone should now show the screen to the right.

Task 7: Create a new one time password

Use the selection key indicating ”New Code”.

In the yellow field on the cell phone screen the one time password will now be displayed. This should be entered on the web page. Task 8: Log in at http://test.liu.se

Navigate to the following web site using the computer in front of you. http://test.liu.se/

Username: teste99 Password: tester

Questionnaire 3

You will now be asked some questions regarding the use of the application and what you thought of the information on this spread. 4. Comparison and sum up

You will now see a demonstration of an alternative solution for generating one time passwords.

Finishing interview

You will now be ask some additional questions. Appendix II Usability Evaluation Questionnaires

The following questionnaires where used in the usability evaluation of the one time password gene‐ rator prototype presented in Section 5.

xix

Questionnaire 1

It was easy to open the program menu (task 1‐4)

Strongly disagree  Strongly agree   The instructions were helpful for opening the program menu

Strongly disagree  Strongly agree   I would have been able to open the program menu without instructions

Strongly disagree  Strongly agree

The instructions are too detailed

Strongly disagree  Strongly agree

If I would open the program menu again I would manage to do it without instructions

Strongly disagree  Strongly agree

Do you think the instructions for opening the program menu should be changed?

No  Yes (please describe in what way) ______ ______ ______ ______     Some background facts

Do you use web‐mail to access the university´s e‐mail system outside the office?

 Yes  No   Do you use any other electronic services provided by your employer outside the office (for example invoice‐, business or personell systems)? If you are a system administrator you should also count remote administration of servers).

 Yes   No  Questionnaire 2

It was easy to open the program menu (task 5)

Strongly disagree  Strongly agree   The instructions were helpful for opening the program menu

Strongly disagree  Strongly agree 

The instructions are too detailed

Strongly disagree  Strongly agree

 I would have been able to open the program menu without instructions

Strongly disagree  Strongly agree

Do you think the instructions for opening the program menu should be made more clearly?

No  Yes (please describe in what way) ______ ______ ______ ______  Questionnaire 3

I chose this method to open the program menu:  Through the main menu (task 1‐4)  Through the shortcut (task 1 & 5)

It was easy to create a one time password Strongly disagree  Strongly agree   The login form on the website was not clear enough Strongly disagree  Strongly agree

System Usability Scale Below are some standardized set of questions based on a method called the System Usability Scale. The model has many fields of application, which means that some of the questions not really fit in. Answers of the questions however provide good support to compare the tested solution with other systems, which is why I ask you to overlook the layout of the questions and answer the questions in the best way you can.

I think that I would like to use this system frequently. Strongly disagree  Strongly agree

I found the system unnecessarily complex. Strongly disagree  Strongly agree

I thought the system was easy to use. Strongly disagree  Strongly agree

I think I would need the support of a technical person to be able to use this system. Strongly disagree  Strongly agree   I found the various functions in this system to be well integrated. Strongly disagree  Strongly agree

I thought the system was too inconsistent. Strongly disagree  Strongly agree

I would imagine that most people would learn to use this system very quickly. Strongly disagree  Strongly agree

I found the system very cumbersome to use. Strongly disagree  Strongly agree

I felt very confident using the system. Strongly disagree  Strongly agree

I needed to learn a lot of things before I could get going with this system. Strongly disagree  Strongly agree

Questionnaire 4

Interview questions

Was there anything specific that you found unclear or got stranded on?

Box

Instead of using a program in the cell phone one can use a free‐standing box which would do the same thing. The box could look something like this. Please try it.

If you compare logging in with the cell phone compared with the free‐standing box, what is your impression?

The box is often found easier to use, but the solution based on the cell phone has the advantage that you do not have to carry an extra box. If you had to choose between these two solutions, which would you choose?

 Box  Cell phone

Would you use the used solution in order to access your web‐mail if you knew it would provide increased security?

 Yes, with the box  Yes, with the cell phone  No  Would you use the solution to get hold of other electronic services provided by your employer outside the office if you knew it would provide increased security (for example invoice‐, business or personell systems)? If you are a system administrator you should also count remote administration of servers).

 Yes, with the box  Yes, with the cell phone  No  Which instructions do you think you will need if you would use the system in August?

I am interested in measuring how easy it is to learn how to use the system. One method to do this is to let users try the system again after a while without using it for some time. Would you like to try the system again in August and see if you can manage it without instructions or with limited instructions? (in that case schedule a new appointment)

The system now provides a code with four signs (characters and digits). It provides almost the same security to use six digits instead. Would you prefer to enter six digits or four mixed signs?

Appendix III Configuration of the Cisco ASA 5505

This appendix illustrates how to extend a valid VPN configuration with authentication using the Smokey system. For readers using Smokey (or any other authentication mechanism) together with the Cisco ASA the author strongly recommends starting with setting up a working VPN using only a local user database and thereafter extending the configuration step by step.

In the author’s opinion the Cisco ASA 5505 can be quite complex to set up and configure. To ease configuration Cisco provides the tool Cisco Adaptive Security Device Manager (ASDM), which pro‐ vides a more user‐friendly interface than other methods available (i.e. configuration by serial or re‐ mote terminal console). For a full reference of the ASDM tool the reader is referred to the Configu‐ ration Guidei available from Cisco.

Add a Local User In our deployment we want to use both Smokey and traditional passwords. In this example we use a local user database residing in the VPN appliance for hosting the traditional passwords. Depending on how many users the system is targeted to and existing infrastructure, different strategies are appropriate. For example an organization having an existing LDAPii user database in place would probably benefit from using the LDAP authentication protocol instead of local users.

To add local accounts we log in to the ASDM utility, choose configuration and Remote Access VPN. In the tree of available configuration options we now choose AAA/Local User, and then Local Users as shown in Figure i. In the screen of Figure i we press the Add button. Now the form for adding new user details (see Figure ii) is displayed. We enter Username, Password and Access Restrictions.

i http://www.cisco.com/en/US/docs/security/asdm/6_2/user/guide/asdmug.pdf ii http://www.ietf.org/rfc/rfc2251.txt

xxv

Figure i: Adding a local user

Figure ii: Enter details of new user

xxvi Create a New AAA Server Group In order to authenticate using the Radius protocol we have to create a new AAAiii Server Group. This option is found under Remote Access VPN, AAA/Local Users, AAA Server Group. A new group is created by pressing the Add button in the top right part of the window. Now the form shown in Fig‐ ure iii below is displayed. We name the new group “Smokey” and press OK.

Next an actual server is tied to the group just created. We select the new group Smokey and press the Add button (in the middle right part of the screen). This results in the display of the form shown in Figure iv. In the reference deployment the Radius server is located on the outside of the Cisco ASA. Hence we configure the Cisco ASA to use the outside interface, enter the DNS name of the ra‐ dius server and the shared secret of clients.conf created previously.

Figure iii: Adding a new Server Group

iii Authentication, Authorization and Accounting

xxvii

Figure iv: Enter details of new Radius server

Configuring Cisco ASA to Use the Smokey AAA Server Group With the current configuration we have at least one valid user and a Radius server configured. Next we must tell the Cisco ASA to use the Radius server when authenticating users.

This is accomplished under Connection profiles found in Remote Access VPN, Network (Client) Access, and AnyConnect Connection Profiles. If the device is configured using default settings the connection profile “DefaultWEBVPNGroup” will be used for logging in with the AnyConnect Client or the Clientless web page. In order to make this profile use both Radius (Smokey) and traditional (lo‐ cal) authentication we take the following steps:

Select DefaultWEBVPNGroup under Connection profiles and press the Edit button as shown in Figure v. Now Select Smokey as AAA Server Group (Figure vi) and select Advanced, Secondary Authentica‐ tion. In this screen (shown in Figure vii) we select LOCAL as Server Group and select the checkbox “Use primary username”.

xxviii

Figure v: Edit Connection Profile DefaultWEBVPNGroup

Figure vi: Connection profile, primary authentication mechanism

xxix

Figure vii: Connection Profile, Secondary authentication mechanism

User Interface Customization As default the Cisco ASA will present the following three fields in the login form:  Username  Password  Second Password

This is not very intuitive. How should the user know which password goes where? Luckily the device allows customization of these (and many other) fields. Customization of the web based (clientless) VPN user interface is found under Remote Access VPN, Clientless SSL VPN Access, Portal, and Cus‐ tomization. Select DfltCustomization and press the Edit button to get access to all labels of the Web forms. We name the password field as “One Time Password” and the “Second password” field as “Password”.

Correspondingly customization of the client is found under Remote Access VPN, Network (Client) Access, AnyConnect Customization, GUI Text and Messages. Select language and press the “Edit” button to get access to all labels. The client will not allow as many characters in the labels as the web form; hence we name the Password field as “One Time Pwd”.

xxx

På svenska

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra- ordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/

In English

The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/