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
SE-581 83 Linköping, Sweden
Linköpings universitet
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
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 ... 14Chapter 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
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
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
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 NetworkFigures
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 ... 69Figure 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
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 ... 71Chapter 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
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
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 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
` aa
k mod m
` ak 2
Z
, p k
` a2
B0,m @ 1
C 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 computey
h x
` a but given y it is computationally infeasible to find an x . such thaty
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‐bit output; that ish
SHA1`k
a2
B0,2
160@
1
C. Secure hash functions have applications in several authentication algorithms that will be discussed in this thesis.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 interval, for instance B0,2160@1C. Ideally the output of a MAC should be a random mapping from all 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
b c h K
b Lopad
c|| h
bK
Lipad
c|| m
d e 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.
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
` a b c Anyone authenticating the signature needs Alice’s verification key verify to carry out the process:verify m, sig m
b ` ac t, t 2 good , bad
R SIn 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
b ` ac d e If the requirements of the secure hash functions are met it is infeasible to find a message such thath m.
` a h m
` a. 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.
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. Signed by TERENA SSL CA using key: 0c bd 93... Certificate cn: www.liu.se O: Linköpings universitet Key ID: c0 d0 ao....
Signed by UTN-USERFirst-Hardware using key: a1 72 5f... Certificate cn: TERENA SSL CA Key ID: 0c bd 93... Signed by
AddTrust External CA Root using key: ad bd 98... Certificate cn: UTN-USERFirst-Hardware Key ID: a1 72 5f... Signed by
AddTrust External CA Root using key: ad bd 98...
Certificate
cn:
AddTrust External CA Root
Key ID: 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.
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. 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 SERVER HELLO DONE CLIENT KEY EXCHANGE -pre CHANGE CIPHER SPEC E(CLIENT FINISHED)
CHANGE CIPHER SPEC E(SERVER FINISHED)
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 EncryptionAlgorithms 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]
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
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 givessufficient 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.
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.
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].
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 passiveFurthermore, 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.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.
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
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 traffic3.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
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.
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 DMZ Internal network Internet User ssh ssh Firewall Firewall ssh server
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.
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 cmm@somethingphishy.com (the real domain here is “somethingphishy.com”; the characters preceding the @‐sign will be interpreted as login data) Server Attacker Client
