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

    i 

    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. 

 

 

    iii 

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 

 

 

 

    v 

     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 

vi 

 

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 

    vii 

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 

viii 

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 

 

 

    ix 

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 

 

 

    xi 

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 

xii 

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 

 

 

    xiii 

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 

 

 

    1 

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.

2 

 

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.   

    3 

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. 

    5 

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

ak modm` a

 

 k 2Z, p k` a

2 0,m@ 1B 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 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‐bit  output;  that  is hSHA1 k` a

2 0,2160@ 1

B C

.  Secure  hash  functions  have  applications  in  several 

authentication algorithms that will be discussed in this thesis. 

6 

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  0,2160@1

B C

. 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,mb c

h KL opadb c

|| h KL ipadb c

|| md 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. 

    7 

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` a

b c

t, t 2 good , badR S

 

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` a

b c

d e

 

If the requirements of the secure hash  functions are met  it  is  infeasible to find a message   such 

that h 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. 

8 

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.seO: Linköpings universitetKey ID: c0 d0 ao....

Signed by UTN-USERFirst-Hardware using key: a1 72 5f...

Certificate

cn: TERENA SSL CAKey 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. 

    9 

 

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-CompressionSERVER CERTIFICATESERVER KEY EXCHANGESERVER HELLO DONECLIENT KEY

EXCHANGE-preCHANGE CIPHER SPECE(CLIENT FINISHED)

CHANGE CIPHER SPECE(SERVER FINISHED)

10 

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]

 

    11 

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.

12 

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 

    13 

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. 

14 

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. 

    15 

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].

16 

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.   

    17 

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.

18 

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].

    19 

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 

20 

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 

DMZInternal network

Internet

User

ssh

ssh

Firewall Firewall

ssh server

Eavesdropping may occur here!

    21 

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=8392cxmc2223455nhczzjhjasdnasxzhasjkdhajskdhaskcxkzxxzzcmm@somethingphishy.com  (the real domain here is “somethingphishy.com”; the characters preceding the @‐sign will be interpreted as login data)  

   

Server

Attacker

Client

22 

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]. 

 

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.  

1. Login

2. Cookie

3. Steal cookie

4. A

ppea

r as

user

User Server

Attacker

4.DoS

    23 

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.  

 

 

    25 

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 

applicability v, m` a

 as the applicability of attack vector, v, on authentication method, m. Applicabil‐

ity will be assessed 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, passwordb c

3 

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` a

Xattackvector, v

weight v` a

Bapplicability v, m` a

 

For example, passive social engineering is classified as a basic level attack vector. Hence; the contri‐

buting score of the example above would be: 

,3 3 9 

26 

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. 

   

    27 

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 

28 

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

 

    29 

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].

30 

 

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].

User

Hash-function

Shared key Clock

12345678

1. Request password

2. Password

Hash-function

Truncate to 6-8 digits

Shared key Clock

Authentication server

Token

3. Pass

word

4. P

assw

ord

5. A

ccep

t/den

y

Compare with user supplied password

Requested service (e.g. web server)

Truncate to 6-8 digits

    31 

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` a

,F i 2` a

,,F i n` a

. 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. Challenge­Response 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. 

32 

 

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  

    33 

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. 

34 

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

  Printed one time pads 

Token gener‐ated one time pads 

Short time valid one time pass‐words 

Challenge‐response 

Transaction depen‐dent challenge‐response 

       Passive Social Engineering  

High  High  Insignificant Insignificant Insignificant 

Active Social Engineering 

High  High  High High Low 

       

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 time pads 

Token gener‐ated one time pads 

Short time valid one time pass‐words 

Challenge‐response 

Transaction depen‐dent challenge‐response 

       Passive Eave‐sdropping  

Insignificant  Insignificant Insignificant Insignificant Insignificant 

Active Eave‐sdropping  

High  High  Medium Low Insignificant 

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. 

    35 

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. 

 

 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.  

Eve

Compromised computer

Alice

malware.inc verysecurebank.com

Request login pageRequest login page

Login form & challenge

Login form & challenge

Response

Eve

Compromised computer

Alice

malware.inc verysecurebank.com

Request transfer of $100to the electrical companyRequest transfer of funds

to Eve

Random challenge

Challenge

Response

Response

36 

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. 

 

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. 

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-CompressionSERVER CERTIFICATESERVER KEY EXCHANGECERTIFICATE REQUESTSERVER HELLO DONE

CLIENT CERTIFICATECLIENT KEY EXCHANGE-preCERTIFICATE VERIFYCHANGE CIPHER SPECE(CLIENT FINISHED)

CHANGE CIPHER SPECE(SERVER FINISHED)

CERTIFICATE REQUEST

CLIENT CERTIFICATE

CERTIFICATE VERIFY

    37 

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. 

 

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  

Client Server

CLIENT HELLO

SERVER HELLOSERVER CERTIFICATESERVER KEY EXCHANGECERTIFICATE REQUESTSERVER HELLO DONEREQUEST CERTIFICATE

CHANGE CIPHER SPECE(SERVER FINISHED)

Hardware token(e.g. smart card)

CLIENT CERTIFICATECLIENT KEY EXCHANGE

CERTIFICATE*

REQUEST SIGNATURE

SIGNATURECERTIFICATE VERIFYE(CLIENT FINISHED)

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

*CERTIFICATE may be cached by Client

38 

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. 

    39 

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

40 

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): 

 

 

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. Camera­Based 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. 

1. Request web page

2. HTTP request

3. Web page incl. RANDWORD

4. SMS with RANDWORD and login URL

5. Confirm or cancel login

6. HTTP request

7. Allow traffic

7. Allow traffic

Client – possibly compromised

Security proxy

Remoteservice

WAP capable cell phone

User

    41 

 

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.  

User

Application Server

Untrusted computer and untrusted network

User’s trusteddevice

Security Proxy

42 

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. 

Table 4: Comparison chart

Passw

ords

On screen 

passw

ords

Printed one

time pads

Token generated

one tim

e pads

Short tim

e valid

 one 

time passw

ords

One tim

e passw

ord

challenge‐response

Transaction dependent 

challenge‐response

Soft TLS certificate

Hard certificates, 

smart card PKI

Web authen

tication / 

mobile phones

Cam

era‐Based

 

Authen

tication

Basic level (passive)

Guessing & Dictionary 2 2 0 0 0 0 0 0 0 0 0

Brute force 1 1 0 0 0 0 0 0 0 0 0

Shoulder surfing 2 3 3 2 0 0 0 0 0 0 0

Password reuse 3 3 1 0 0 0 0 0 0 0 0

Key logger hardware 3 0 0 0 0 0 0 0 0 0 0

Key logger software 3 3 0 0 0 0 0 0 0 0 0

Authentication Methods

s

0 Insignificant

1 Low

2 Medium

3 High

Social engineering 3 3 3 3 0 0 0 1 0 0 0

Medium level (passive)

Theft by intrusion 2 2 0 0 0 0 0 3 0 0 0

Eavesdropping 3 3 0 0 0 0 0 0 0 0 0

Advanced level (active)

Social engineering 3 3 3 3 3 3 1 1 0 3 3

Eavesdropping 3 3 3 3 2 1 0 0 0 1 1

Man in the middle 3 3 3 3 3 3 0 0 0 3 3

Man in the browser 3 3 3 3 3 3 0 3 3 3 3

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

Attack vectors

    45 

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. 

   

46 

Table 5: Overview of candidate authentication methods

Candidate method  Comment 

Short time valid one time passwords generated by token  

Possible to develop using cell phones. 

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 by SMS 

Requires connectivity and cell phone coverage at 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.

    47 

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 

48 

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. 

 

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].

1

2

3

4

5

"It was easy to generate the OTP"

    49 

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.  

 

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. 

0

10

20

30

40

50

<=40 41‐50 51‐60 61‐70 71‐80 81‐90 91‐100

Frequency

Average SUS Scores

50 

 

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. 

 

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‐

1

2

3

4

5

"It was easy to open the applications menu"

Without shortcut With shortcut

Preferred token

90 % prefer Smokey prototype

10  % prefer standalone token

    51 

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. 

 

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

Preferred password format

90 % prefer four alpha‐numerical characters

10 % prefer six digits passwords

52 

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: 

10  

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 1 9.2 10  

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.4 10  

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: 

5 

0 5 

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.

    53 

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  24 4 3288. The probability to guess at least one correct password during a 24 hour period would thus be12: 

11

1 0.0178 

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:  

0 3

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: 

161

1 1.14 10  

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.

54 

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. 

    55 

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. 

56 

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. 

 

 

    57 

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/

58 

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    

  

 

   

    59 

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    

  

 

   

60 

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    

  

 

   

    61 

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

62 

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. 

    63 

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. 

 

Figure 28: Initialization protocol

   

User

Operator

Authentication ServerUser Phone6. Init: ID:K1 (http)

8. sa_key, K2 (sms)

9. sa_key XOR phone_key: phone_time (http)

7. OK, serialno, stand by for SMS

10. OK

1. Verify identity, request key

2. Authenticate user,

enter phoneno.3. key

4. Deliver initialization key0102-0222-9431-2479-

5512-6172

Initialization Key

5. Initialize

0102-0222-9431-2479-

5512-6172

Initialization Key

ID-K1-K2

Initialization Key

ID: Key ID. Corresponding user ID stored in database.6 digits (0-9).

K1: Client authentication key. Used by client to prove identity when requesting initialization.6 digits (0-9)

K2: Server authentication key. Used by server to prove that SMS containing sa_key is authentic. 6 digits (0-9)

serialno 4 byte hex string

sa_key 15 byte hex string

phone_key 5 byte hex string

Key exchange

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

64 

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 

 

    65 

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 requestTemplate  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.

66 

   Server response  HTTP Step 9 in Figure 28

Purpose  Indicate success or failure of previous requestTemplate  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. 

 

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. 

   

Authentication ServerUser Phone1. serialno, counter

3. time, HMAC(Key, time|ctr|RAND)

2. OK, max(p_ctr, s_ctr), RAND

4. OK

Shared Key

    67 

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?

ac-tion=synchronize2&serial=30&time=20845950&authentication=2652b841ae2b9f9fc56be260a1d0d37c8b3a6955&requestid=00000016 

     Server response  HTTP Step 4 in Figure 29

Purpose  Confirm synchronization or indicate error.Template  OK

or ERROR 

 

68 

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. 

TOKEN

INITIALIZATION

1

N

WAITS_FOR

serialno

userid

phoneno

shared_key

counter

time_offset

init_id

init_K1init_K2

server_assigned_key

1 NHAS REQUESTED SYNCHRONIZATION

request_id

new_counter

rand

is_locked_out

1

1

HAS

FAILED ATTEMPT

last_attempt

fail_counter

throttle_level

 

Figure 30: ER-diagram of backend database

    69 

 

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

 

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

70 

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  

 

    71 

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. 

 

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 

Smokey.pm

HOTPAlgorithm.pmLogin.pmDatabase.pm Initialization.pm Synchronization.pm Admin.pm

ConfigParams.pm otpinit.cgi

72 

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. 

 

Smokey (controller)-model-activeView

+exitMIDLET()+handleException()+notifyIncomingMessage()+updateDisplay()

Model-currentView-nextView

+byteArrayToHexString()+byteArrayToInt()+clearAndCreateStore()+extractKeys()+generateOTP()+getCurrentView()+getIMEI()+getIMEIhash()+getNextView()+getPhoneTime()+getSerial()+getSharedKey()+httpGet()+intToByteArray()+processIncomingMessage()+readStorage()+requestInitialization()+setCurrentView()+setInitFields()+setNextView()+setSerial()+startListening()+stopListening()+synchronizeClockAndCounter()

1

1

Storage

+getServerAssignedSecret()+getCounter()+getSerialNumber()+increaseCounter()

1

MIDlet<<interface>>

MessageListener

 

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.

    73 

 

Figure 37: UML-diagram of view classes

 

    75 

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. 

76 

 

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 }

Cisco ASA 5505NASUser

FreeradiusRadius server

OTP

Localuser DB

Smokey Perl API

UserID, OTP,Password

Acces

s Req

uest

Acces

s Acc

ept

    77 

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

    79 

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.  

80 

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. 

    i 

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. 

ii 

  [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/. 

    iii 

  [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. 

iv 

  [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. 

    v 

  [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 

vi 

  [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/. 

    vii 

  [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. 

 

 

    ix 

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 there-fore 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. 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 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.

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.

Task 2: Go to the main menu

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.

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

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”

Task 4: Select Applications

2. Open the Applications menu

You will now be asked to respond to a questionnaire regarding the informa-tion shown on the last spread and the interaction of the cell phone.

Questionnaire 1

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 neces-sary). Open the Applications menu by pressing the left part of the navigation key. Now the Application menu should be opened once again.

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

Questionnaire 2

3. Try a shortcut

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 cur-rent functions tied to them.

3. Log in

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 6: Start LiU OTP Suite

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.

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.

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/ Log in using the one time password you generated in task 8 and the fol-lowing credentials. Username: teste99 Password: tester

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.

    xix 

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. 

 

 

Questionnaire 1

 It was easy to open the program menu (task 1‐4)    Strongly disagree  Strongly agreeThe instructions were helpful for opening the program menu    Strongly disagree  Strongly agreeI 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     NoDo 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 agreeThe 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 agreeThe 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 agreeI 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      NoWould 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      NoWhich 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?  

    xxv 

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

xxvi 

 

Figure i: Adding a local user

 

 

Figure ii: Enter details of new user

 

    xxvii 

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

xxviii 

 

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”. 

    xxix 

 

Figure v: Edit Connection Profile DefaultWEBVPNGroup

 

 

Figure vi: Connection profile, primary authentication mechanism

xxx 

 

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”. 

 

 

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/

© Johannes Hassmund