ISSN 1744-1986

T e c h n i c a l R e p o r t N O 2009/ 02

Securing Cellular Access Networks againstFraud

C Lukeman

26 October, 2009

Department of ComputingFaculty of Mathematics, Computing and TechnologyThe Open University

Walton Hall, Milton Keynes, MK7 6AAUnited Kingdom

http://computing.open.ac.uk

Securing Cellular Access

Networks against Fraud

A dissertation submitted in partial fulfilment of the requirements for the Open University’s

Master of Science Degree in Computing for Commerce and Industry

Chris Lukeman (U5065754)

1 March 2010

Word Count: 14,534

Preface

I would like to thank my supervisor Dr Samir Al-Khayatt not only for suggesting this

project but also for his helpful advice and guidance throughout the course of this

dissertation. Through this I was able to remain focussed and the dissertation to remain

on course.

I would also like to thank all those that took the time to participate in my online

questionnaire into attitudes to mobile security

Finally I would like to say a special thank you to Rachel Morton for piloting the

questionnaire and offering advice on the suitability of questions and most importantly

for proof reading this dissertation.

ii

Table of Contents

Preface...................................................................................................................... i

List of Figures......................................................................................................... vi

List of Tables .......................................................................................................... vi

Abstract………………………………………………………………………………x

Chapter 1 Introduction………………………………………………………………..1

1.1 Background to the research…………………………………………………… 1

1.2 Aims and Objectives…………………………………………………………….5

1.3 Research Question………………………………………………………….…...6

1.4 Contribution to Knowledge……………………………………………………..6

1.5 Dissertation Overview…………………………………………………………..7

Chapter 2 Literature Review…………………………………………………………9

2.1 AKA in Cellular Networks…………………………………………………….9

2.1.1…GSM AKA………………………………………………………….……..9

2.1.2 UMTS AKA………………………………………………………………..13

2.1.3 LTE/SAE AKA…………………………………………………………….18

2.2 Secure Handovers between GSM and UMTS Networks ……………………..22

2.3 SIM Card Security…………………………………………………………….23

2.4 Weaknesses in UMTS AKA…………………………………………………..24

iii

2.4.1 Anonymity…………………………………………………………………24

2.4.2 Man in the Middle Attack………………………………………………….25

2.4.3 Redirection Attack…………………………………………………………26

2.4.4 Denial of Service DoS……………………………………………..………27

2.5 Related Research………………………………………………………………..27

2.5.1 Identity Concealment………………………………………………………27

2.5.2 Mutual Authentication………………………………………………….....28

2.6 Summary……………………………………………………………………...31

Chapter 3 Research Methods……………………………………………………….32

3.1 Case Study…………………………………………………………………….32

3.2 Development of a Prototype………………………………………………….33

3.2.1 Design Phase…………………………………………………………….33

3.2.2 Implementation Phase…………………………………………………..34

3.2.3 Testing Phase…………………………………………………………...35

3.3 Questionnaire……………………………………………………..………...35

Chapter 4 Data Acquisition………………………………………………………38

4.1 Questionnaire Results………………………………………………………38

4.2 Prototype Design……………………………………………………..…….40

iv

4.2.1 Two Factor Authentication………………………………………………...41

4.4.2 Full Network Authentication………………………………………………43

4.4.3 Local Network Authentication…………………………………………….47

4.2.4 Anonymity…………………………………………………………………48

4.3 Prototype Implementation………………………………………………………49

Chapter 5 Data Analysis and Results…………………………………………………..55

5.1 Prototype Testing and Results……...………………………………………….55

5.1.1 Performance Results………………………………………………………63

5.2 Data Analysis………………………………………………………………….67

5.2.1 Security Analysis…………………………………………………………67

5.2.2 Performance Analysis…………………………………………………….70

5.2.3 Implementation Considerations………………………………………….71

5.2.4 Comparison with Other Research……………………………………….72

Chapter 6 Conclusions……………………………………………………………..74

6.1 Summary of Findings……………………………………………………..74

6.2 Future Research…………………………………………………………..76

6.3 Project Review…………………………………………………………...77

References………………………………………………………………………….79

v

Bibliography………………………………………………………………………….85

Index………………………………………………………………………………….88

Abbreviations…………………………………………………………………………90

Appendix A : Extended Abstract…………………………………………………….

Appendix B : Questionnaire…………………………………………………………97

Appendix C : Questionnaire Results………………………………………………103

Appendix D : Test Results…………………………………………………..……..113

Appendix E : Source Code…………………………………………………………136

vi

List of Figures

Figure 2.1 Simplified GSM Architecture ……………………………………………10

Figure 2.2 GSM Algorithms inside the Mobile Phone ………………………………10

Figure 2.3 Authentication Process in GSM…………………………………………...12

Figure 2.4 Simplified UMTS Architecture……………………………………………14

Figure 2.5 Authentication Vectors in AuC …………………………………………...14

Figure 2.6 Authentication Process in UMTS …………………………………………15

Figure 2.7 Cipher Algorithm in UMTS ………………………………………………16

Figure 2.8 Integrity Algorithm in UMTS……………………………………………..17

Figure 2.9 Network Architecture of LTE …………………………………………….18

Figure 2.10 Key Hierarchy in LTE Networks ………………………………………..19

Figure 2.11 Authentication Method in LTE network ………………………………..21

Figure 2.12 Handover between GSM/UMTS ………………………………………..22

Figure 2.13 IMSI Structure …………………………………………………………..25

Figure 4.1: Use case diagram for the generation of MACsn in the USIM……………42

Figure 4.2: Prototype Authentication Vectors………………………………………..45

Figure 4.3: Full Network Authentication Sequence Diagram………………………..46

Figure 4.4: IMSI Updates between Core Network Elements………………………..49

vii

Figure 4.5: Prototype GUI Interface……………………………………………….50

Figure 4.6: Flow Chart for Java Implementation of Prototype……………………51

Figure 4.7: Prototype Class Diagram ……………………………………………..52

Figure 4.8: Class Diagram for Supplementary Classes……………………………53

viii

List of Tables

Table 2.1 Authentication and Encryption Algorithms used in UMTS……………17

Table 4.1: Protocol for Java Implementation of Prototype……………………... 54

Table 5.1: Results of a Normal Authentication ………………..…………………56

Table 5.2: Results of the Re-direction Attack…………………………………….57

Table 5.3: Results of the Replay Attack………………………………………..…58

Table 5.4: Results of Mutual Authentication Test…………………………….…..58

Table 5.5: Anonymity Test………………………………………………….…….59

Table 5.6: Change of Serving Network……………………………..…………….60

Table 5.7: User Authentication Check…………………………………………....61

Table 5.8: Timestamp Check……………………………………………….…….61

Table 5.9: Wrong IMSI Check……………………………………………..……..62

Table 5.10: Authentication Parameters in (a) UMTS AKA and

(b) M801 AKA………………………………………………………64

Table 5.11: Number of bits per Message for the M801 Protocol………………..65

Table 5.12: Comparison of the number of bits transmitted between M801

Protocol and UMTS per authentication run…………………………67

Table 5.13: Comparison of M801 protocol with UMTS AKA…………………..68

ix

Table 5.14: Comparison of UMTS protocols……………………………………..72

x

Abstract

Despite improvements made in cellular security since first generation analogue

networks, there still remain a number of weaknesses in UMTS networks. This is made

more critical because the UMTS AKA is to be used in fourth generation LTE networks.

At the current time there are no known attacks against UMTS networks, but new

techniques are being developed all the time by hackers and computer processors are

becoming more powerful, which means this may not always remain. As mobile

applications move in to high value areas such mobile commerce and mobile banking

these networks will become more attractive to criminals.

Through research a number of weaknesses have been highlighted in UMTS

authentication. A number of research projects have been initiated, but to date, these

have not been satisfactory for use in a live network. This has been mainly due to lack of

compatibility with GSM. The protocol developed introduced two new ideas to cellular

authentication. The first is the use of two-factor authentication using a chip and PIN

solution. The second involves a novel way of achieving mutual authentication by using

a secret authentication code

A simulation of the protocol was produced using the client / server architecture of Java.

A series of controlled experiments were then run testing all known threats against

cellular networks including the highlighted weaknesses. The protocol successfully dealt

with all threats and in not altering the area of UMTS AKA associated with

interworking, ensured compatibility with GSM. Although successful in the tests

conducted, the experiments would need re-running using a dedicated network software

tool such as OPNET and an external security assessment by an external party to verify

the claims

1

Chapter 1 Introduction

1.1 Background to the research

January 1st 2010 marked the 25th anniversary of the launch of the UK’s first mobile

phone network (Collins, 2009). This first network in the UK was an analogue based

network called TACS (Total Access Communication System). These networks from a

security perspective were variously described as weak (Howard, 2005) or non existent

(Bais et al, 2006). No encryption of data was provided and the signals were

transmitted using Frequency Modulation (FM). This meant all calls could be quite

easily tuned into by amateur radio enthusiasts (Niemi and Nyberg, 2003). In addition

it was easy to reprogram a phone (cloning) with the user’s identity from information

gathered from over the unencrypted air interface (Arreymbi, 2006). This could all be

carried out passively without requiring any expensive equipment.

This highlighted the need for improved security in second generation networks. The

most widely used of these is GSM (Global System for Mobile Communication). GSM

is a digital network and as such is well suited to take advantage of the available digital

cryptography techniques. The primary security objective for GSM was to provide at

least the same level of security as fixed line phones. This resulted in the mobile phone

becoming the first mass communication device to employ cryptography (Howard,

2005). Cloning is prevented by the introduction of a tamper resistant smart card called

a SIM (Subscriber Identity Module). The SIM contains the IMSI, which identifies the

user to the network and a secret key (Ki), which is never transmitted. Encryption is

applied between the mobile and the base station (BTS) to prevent unauthorised

listening.

2

Despite the improvements new threats were identified (Bocan and Cretu, 2006) and

(Siddique & Amir, 2006). One problem identified was that the mobile could not

authenticate the network. This left open the possibility of an active attack known as a

false base station or man in the middle attack. The algorithms used in GSM were not

made public. This process is quite often referred to as security by obscurity. The

argument against this is that the secret will come out eventually and if released from

the start it gives the cryptography community time to check the algorithms for

weaknesses. This proved to be the case in 1997 (He, 2007) when details of the GSM

algorithms were leaked. Subsequent analysis found that a weak algorithm called

COMP-128 was being used. Within a year of the details being leaked the algorithm

was reverse engineered by researchers at UC Berkeley (Brumley, 2004). The cracking

of the algorithm resulted in the return of cloning (Brookson, 2005). The cloning of

SIM cards only appears to affect those using COMP-128 version 1 and does not

appear to affect the improved version 2 algorithm. The encryption algorithms used in

GSM also came under attack (Barkan et al, 2006). With these compromised it

becomes possible to eavesdrop on subscriber calls. Although it is not possible to listen

to live calls, the times are coming down rapidly (Gendrullis et al, 2008). In 2009 an

article in Mobile Industry Review (Mobile Industry Review, 2009) had the cost down

to $500 with a prediction that GSM eavesdropping would be common place by 2010.

At the end of 2009 Karsten Nohl published details of an attack on the GSM A5/1

algorithm (Cohen, 2009).

3

Many of the lessons learnt in GSM were corrected in third generation networks

referred to as UMTS (Universal Mobile Telecommunication System) in Europe. The

scope of UMTS security (3GPP TS 33.102, 2009) is to keep the features that worked

well in GSM such as the use of a SIM card and improve on weaknesses real or

perceived. This resulted in a new set of encryption and authentication algorithms and

these were published from the start this time and found to be trusted and secure

algorithms (Balderas Contreras and Cumplido Parra, 2004). The encryption key size

was also increased from 64 bits to 128. The security of an algorithm is related to the

key size (Chandra, 2005). There have been documented cases (Biham et al, 2005) of

attacks against A5/3 used in GSM, which is based on Kasumi. These attacks are not

considered practical and were based on 64 bit key not 128, but it is an initial sign that

the main encryption algorithm in UMTS may be vulnerable.

Mutual authentication is also introduced into UMTS. A Message Authentication Code

(MAC) is generated by the mobile’s HLR to prove it has been generated by the

legitimate network. Part of the input to the MAC is a Sequence Number (SQN)

introduced to guarantee freshness and thereby prevent replay attacks. Introduced into

UMTS networks is integrity protection to prevent the modification of messages

during transit (Niemi and Nyberg, 2003).

In spite of the improvements new threats became apparent (Bais et al, 2006). Some of

these weaknesses have carried over from GSM such as lack of anonymity. IMSI is

still sent in clear text, which could be used by IMSI catchers (Strobel, 2007) to track

the user. Although integrity protection is in place in UMTS it does not get applied

until after the initial key agreement phase. Up to this point it is possible to alter

messages or inject messages. This could be used in a Denial of Service (DoS) attack

4

(Khan et al, 2008) such as IMSI detach. An attack was published in 2004 (Meyer &

Wetzel, 2004) where a man in the middle attack is launched on a UMTS network.

This exposed a number of weaknesses in the architecture. These include how the

weaknesses in GSM can undermine UMTS security, through the requirement to be

able to perform a seamless secure handover. Also exposed in this attack is the

weakness of using sequence numbers.

Research is now moving to fourth generation networks such as Long Term Evolution

(LTE). One of the main differences with LTE networks that differ to previous

generations, is that it is totally packet based and no support will be provided for

circuit switched data. This contrasts with the first GSM networks (pre GPRS), which

provided only circuit switched. The main feature of the LTE architecture as far as this

dissertation is concerned is that it is based on UMTS AKA. This means that these

networks will also adopt a lot of the problems already highlighted for UMTS. Unlike

UMTS, LTE networks do not appear to be concentrating on finding solutions to

perceived weaknesses as well as actual.

What this overview has illustrated with the exception of the cracking of COMP-128 is

that when a weakness is identified, the solution is implemented in the next generation.

This would illustrate a lack of flexibility in the architecture. What has also come

across is that security features are implemented frequently as a result of weaknesses

being exposed in the network. This would perhaps imply that security is more reactive

than proactive. A comment by Bruce Schneier (Schneier, 2008) in relation to A5/1

could be applied to security in general when he commented “attacks always get

better; they never get worse”. Operators are now looking to move in to high value

applications such as mobile banking and commerce. This will inevitably attract

5

criminal elements. Once a weakness has been exposed it is only a matter of time

before it gets exploited through better technology. This is why research in this area is

so important and is the motivation behind this dissertation.

1.2 Aims and Objectives

Despite the increased level of security introduced into third generation networks, the

overview highlighted a number of weaknesses. Further research has shown that some

features have either not been implemented or not implemented in the manner

specified by 3GPP (Mochizuki, 2006). Many of these weaknesses are related to the

authentication process. Authentication ensures that only authorised users can access

the network. A successful authentication is also used as the launch pad to generate

other threats against the network.

The aim of this dissertation will be to analyse the weaknesses in UMTS protocols

with regard to the authentication processes. This will mainly focus on weaknesses in

anonymity and mutual authentication. The dissertation will then analyse possible

solutions to the weaknesses and as a result develop a more secure framework, which

addresses the weaknesses whilst maintaining compatibility with GSM and LTE

networks.

The new protocol will be demonstrated using a simulation package built using Java’s

client-server architecture. This will demonstrate the protocols ability to defend against

a number of attacks

6

1.3 Research Question

The primary research question this dissertation will attempt to answer will be

‘Can a more secure cellular access network be developed without altering the existing

network architecture and maintaining compatibility with GSM networks?’

To answer the primary research question a series of secondary questions need to be

posed.

(a) Can two factor authentication improve security in UMTS networks?

Should it be implemented?

(b) Can a more suitable solution to using sequence numbers be found where a

mobile controls its own challenge and avoids the need for re-synchronisation?

(c) IMSI is the way a mobile identifies itself to the network, thereby making it

possible to track the user. This compromises a user’s anonymity. Is it possible

to provide a solution where the user’s anonymity is preserved?

1.3 Contribution to Knowledge

3GPP (33.801, 2005) believe that weaknesses of UMTS networks highlighted in

section 2.4 are not feasible in practice and have included the UMTS authentication

framework in LTE networks. This is why it is important to find a solution to these

weaknesses.

This research is likely to be of particular interest to other researchers in this field

where it may compliment work they are already undertaking. The dissertation will be

of value to others that have an interest in mobile communications in general and

7

security architecture in particular. This would be expected to include personnel

working for mobile phone operators in a technical capacity and organisations whose

corporate networks are carried by mobile operators. This dissertation will be of

interest to Network Engineers that have knowledge of IP security but very little

knowledge of mobile security architectures.

1.4 Dissertation Overview

The remainder of this dissertation is structured as follows. Chapter 2 evaluates the

current body of knowledge in cellular authentication. Investigated are the

authentication architectures of three generation of cellular networks and the

interworking between them. This is followed by an assessment of the main

weaknesses affecting UMTS networks and finally concluding with a critical review of

existing research in this area.

Chapter 3 describes the research methods employed. This will cover what methods

were chosen and the rationale behind them.

Chapter 4 covers data acquisition. The chapter starts by an analysis of the results of

the online questionnaire detailed in chapter 3. This is followed by the development of

a prototype to address the issues highlighted in chapter 2. The chapter concludes by

describing the implementation of the prototype design in java.

Chapter 5 covers data analysis and results. This chapter follows on directly from

chapter 4. The prototype developed will undergo a series of tests based on the

weaknesses highlighted in chapter 2. The chapter will close with an analysis of the

results generated.

8

Chapter 6 discusses the conclusions reached and whether the research question(s)

have been successfully answered. This will be followed by recommendations for

future research. The dissertation closes with a project review.

9

Chapter 2 Literature Review

This chapter will review the current body of knowledge in cellular authentication.

This will begin by reviewing the current architectures as specified by the standards

bodies such as the GSM association and 3GPP. The focus will then move on to the

weaknesses that have resulted in the need for this research. Finally there will be a

review of other research in this area and why the problem still needs to be addressed

2.1 AKA in Cellular Networks

2.1.1 GSM AKA

Although this dissertation intends to focus on UMTS security, a review of GSM is

necessary because this is known to compromise UMTS security (Meyer, 2006). A

further reason is that interworking is a requirement of UMTS and also part of the

primary research question. The architecture of a typical GSM is shown in figure

2.1 (Aura, 2009). Although the access network in the diagram is shown as the BSC

and BTS. In reality it extends from the border of the MSC through to the Mobile

Station (MS). In the diagram the encryption is only applied between the MS and

BTS.

10

SIM Card

MS

Figure 2.1: Simplified GSM Architecture adapted from (Aura, 2009)

SRES

Ki

RAND

. Kc

Frame No Ciphered Text

Plain Text

Figure 2.2: GSM Algorithms inside the Mobile Phone (Arreymbi, 2006)

Core Network – Packet Switched

SGSN GGSN

HLR/AuC

Core Network – Circuit Switched

Radio Access Network

BTS BSC MSC/VLR GMSC

A3

A8

A5 X

11

The diagram in figure 2.2 (Arreymbi, 2006) shows the algorithm locations inside a

typical mobile phone and how they link together. On the network side A3/A8

reside with Ki in the Authentication Centre (AuC). The A5 algorithm is located in

the BTS. What this does show is the effect of having these algorithms

compromised. If the A3/A8 algorithms are compromised, the SIM would need

replacing. If A5 algorithm is compromised this would result in the replacement of

the mobile itself. The A5 algorithm has a number of versions. These are described

in a number of texts (Bocan and Cretu, 2006). A5/1 is the main encryption

algorithm and has been subjected to many attacks over the years (Barkan et al,

2006) and (Schneier, 2008). The key size in GSM is a weakness as it is only 64

bits and 10 of those are 0 leaving an effective size of 54. This is one of the reasons

why access to LTE networks will not be allowed for a GSM SIM (3GPP TS

33.821, 2009). NSA (NSA, 2009) specifies a minimum key size of 128 bits for

secret and 256 bits for top secret.

The GSM authentication protocol is illustrated in figure 2.3. The VLR uses the

IMSI or TMSI to request a number of triplets (Quirke, 2004) from the user’s

HLR/AuC. More than one set of vectors (triplets) are ordered for two reasons. The

first is to prevent repeat signalling between the VLR and AuC. The second is to

allow for the link between the two to go down. In the event that the system is still

not operational when the vectors have all been used, the system will allow an

existing vector to be used. This is a serious security threat as it allows a

compromised vector to be used.

12

Request for a Channel

Channel allocation

TMSI Identity Request IMSI IMSI (RAND, SRES, Kc) Triplets RAND SRES No Access Yes Kc (Sent to BTS) Cipher Mode Allocation of TMSI Figure 2.3: Authentication process in GSM adapted from (Quirke, 2004)

BSC BTS

=?

MS HLR/AuC MSC/VLR

13

If the SRES calculated by mobile matches the value calculated by the AuC, the

user is allowed access to the network. At this point Kc is sent to the BTS and the

BTS instructs the mobile to turn on ciphering. Once ciphering has been set a TMSI

is allocated, which protects the user confidentiality. The collection of

RAND/SRES pairs (Siddique and Amir, 2006) can be used to compromise

security. The BTS controls the encryption, so a false base station could turn

encryption off or use a weaker version. Other weaknesses are described in various

texts (Bocan and Cretu, 2006) and (Aura, 2009).

2.1.2 UMTS AKA

When 3GPP started to work on the security requirements of UMTS networks, the

main criteria was to keep the features that worked in GSM (SIM) and find

solutions to weaknesses either real or perceived (Bais et al, 2006).

The architecture of a UMTS network (figure 2.4) is similar that in figure 2.1. This

is another requirement of UMTS is that it needs to be interoperable with GSM to

aid migration (Howard, 2005) and (3GPP TS 31.900, 2009). The main difference is

in the Radio Access Network (RAN). The GSM RAN is now referred to as

GERAN and the UMTS is referred to as UTRAN. This diagram is the R99 release

(Niemi and Nyberg, 2003), which is the first UMTS release. Subsequent releases

introduce media gateways in release 4 (Kaaranen et al, 2005) and IP Multimedia

System (IMS) in release 5 (Camarillo and García-Martín, 2008). The access

network architecture remains unchanged and this is the focus of this dissertation.

14

UTRAN Network

MS

UE

Figure 2.4: Simplified R99 UMTS Architecture (Kaaranen et al,

2005)

AMF RAND

SQN K

MAC-A XRES CK IK AK

Figure 2.5: Authentication Vectors in AuC (Niemi and Nyberg, 2003)

Core Network – Packet Switched

SGSN GGSN

HLR/AuC

Core Network – Circuit Switched

GERAN Network

BTS BSC 3G MSC 3G GMSC

Node B RNC

F1 F2 F3 F4 F5

15

Radio Resource Connection (RRC)

Channel allocation

TMSI Identity Request IMSI IMSI 5 AVs RAND, AUTN XRES RES No Access Yes Cipher Mode CK, IK TMSI Allocation

Figure 2.6: Authentication process in UMTS (3GPP TS 33.102, 2009)

RNC Node B

=?

Check MAC / SQN

UE 3G MSC /VLR HLR/AuC

16

The authentication algorithms (figure 2.5) are based on milenage (Niemi and

Nyberg, 2003) a respected cryptography algorithm and details were published

unlike GSM. MAC-A is used identify the Home Network (HN) as legitimate by

the mobile. If MAC-A fails in the UE, the authentication is halted. AMF is usually

set to 0000 in live networks (Mochizuki, 2006) so this does not influence result as

intended. AK is provided and combined with SQN in an XOR operation so that

users SQN can not be tracked. If SQN fails the freshness test a re-synchronisation

is initiated by the UE. This process is described in 3GPP 33.102 (3GPP TS 33.102,

2009).

The process of encryption has also changed in UMTS (figure 2.7). F8 (based on

kasumi) effectively replaces A5.

Count-C Direction

Bearer Length

CK Keystream Block Mask Plain Text Ciphered Text Figure 2.7: Cipher Algorithm in UMTS (Kaarenen et al, 2006)

F8

X

17

Integrity protection is provided in UMTS to protect vital signalling messages. The

F9 algorithm is similar in structure to figure 2.7 (figure 2.8). XMAC-I and Fresh

perform a similar function to MAC and SQN in AUTN. If the MAC values are not

equal the command is unsuccessful. Table 2.1 shows a full list of algorithms used

in UMTS, showing which algorithm each function uses

RNC USIM

Count-I Direction Count-I Direction

Message Fresh Message Fresh

IK IK IK IK XMAC-I MAC-I

Figure 2.8: Integrity Algorithm in UMTS (Kreher and Rüderbusch 2006)

Function Purpose/Usage O: Operator Specific S: Fully Stardardised

f0 Random challenge generating function O

f1 Network authentication function O-Milenage

f1* Resynchronisation message authentication function O-Milenage

f2 User challenge-response authentication function O-Milenage

f3 Cipher key derivation function O-Milenage

f4 Integrity key derivation function O-Milenage

f5 Anonymity key derivation function for normal operation O-Milenage

f5*

Anonymity key derivation function for resynchronisation O-Milenage

f8 UMTS encryption algorithm S-Kasumi

f9 UMTS integrity algorithm S-Kasumi

Table 2.1: Authentication and Encryption Algorithms used in UMTS (Koien, 2004)

F9 F9

18

2.1.3 LTE/SAE AKA

Although LTE are currently in the planning stages, there are a number of reasons

why research in this dissertation will be relevant. The main reason is that the

UMTS AKA is to be used in these networks (3GPP TS 33.401, 2009). A second

reason is the need for intersystem handover between LTE and UMTS.

GPRS Core

Evolved Packet Core

Figure 2.9: Network Architecture of LTE (3GPP TS 33.401, 2009)

The architecture as illustrated in Figure 2.9 is proposed for LTE networks. The red

in the diagram illustrates new elements or interfaces introduced by LTE. Key

changes in the RAN are the removal of the RNCs. This functionality is now

incorporated into the eNode Bs and it is at this point that encryption occurs.

Another major change from GSM/UMTS is the removal of the MSCs. These are

circuit switched elements and LTE is an all packet switch network.

GERAN

UTRAN

SGSN

Evolved RAN MME 3GPP SAE

IP

SERVER

Non 3GPP WLAN 3GPP

PCRF

HSS

19

A GSM SIM or SIM application on UICC will not be allowed access to the

eUTRAN. The reason behind this is described in 3GPP 33.821 (3GPP TS 33.821,

2009):

LTE supports two key sizes, 128 and 256. This means R99 USIM cards will be

able to gain access to the network. There are concerns (3GPP TS 33.821, 2009)

that a key size of 128 may in future become vulnerable to developments in

quantum computers. Unlike UMTS, LTE implements a key hierarchy as illustrated

in figure 2.10. Description of the keys can be found in 3GPP TS 33.821 (3GPP TS

33.821, 2009) and (Agilent, 2009)

128 bit

AuC / USIM

HSS / UE SNID

MME / UE 256 bit

256 bit 256 or 128 bit

eNodeB

256 or 126 bit

Figure 2.10: Key Hierarchy in LTE Networks (Meyer, 2009)

Ki

CK, IK

KSN

KeNB KNASint KNASenc

KRRCint KRRCenc KUPenc

20

The authentication process in LTE is very similar to UMTS. There are a number of

key differences. The first bit of AMF is set to 1, whereas in UMTS networks AMF

is 0000. In LTE if this is not set to 1 authentication is rejected. This is why in the

authentication process, the network type must be sent. This bit will also let the MS

know what type of authentication is being carried out. In the authentication process

only one AV is fetched from HSS.

The authentication process in figure 2.11 has a number of new values GUTI

(Globally Unique Temporary Id) replaces TMSI, which was only unique within the

VLR. SNID and KSIame are used to enable a more efficient AKA when a Mobile

is in its home environment. The rest of the process is the same as UMTS and as

such will have some of same problems, as previously highlighted. LTE networks

allow an unused AV to be sent from the SGSN to the MME. The network will not

however allow this to be forwarded to another MME.

21

Radio Resource Connection (RRC)

Channel allocation

GUTI Identity Request IMSI IMSI, SNID, Network Type 1 AV RAND, AUTN, KSIame XRES RES No Access yes

Figure 2.11: Authentication method in a LTE network (3GPP TS 33.821, 2009).

eNode B

=?

Check MAC / SQN

UE HSS MME

22

2.2 Secure Handovers between GSM and UMTS

As the background research highlighted, UMTS networks have stronger security

features when compared to GSM. This can cause problems when handing over calls

between them (Meyer and Wetzel, 2006). Interworking between GSM and UMTS is

defined in 3GPP TS 31.900 (3GPP TS 31.900, 2009) and the security aspects of

secure handover in 3GPP TS 33.102 (3GPP TS 33.102, 2009).

As a result of the stronger security measures UMTS security should be provided

where possible. A GSM VLR can only perform GSM authentication (see figure 2.12).

Figure 2.12: Handover between GSM/UMTS (3GPP TS 33.102, 2009)

It does not have the capability for UMTS authentication i.e. no mutual authentication.

If a UMTS mobile is controlled by a GSM VLR, the HLR must apply a compression

function on the data.

SRES= C1(XRES) Kc = C2(CK)

This is because UMTS are longer in length. If a GSM SIM in a dual mode handset

roams into a UMTS site. Mutual authentication cannot be performed because a GSM

3G VLR

3G RAN 2G RAN 2G RAN

2G VLR

23

SIM does not possess that capability. It must however use cipher and integrity keys

suitable for a UMTS network. These are generated from Kc

CK= C3(Kc) IK= C4(Kc)

2.3 SIM Card Security

SIM cards are introduced into mobile phones in GSM with the aim of reducing

cloning. Initially this was very successful, however once the algorithm used in GSM

(COMP-128) was reverse engineered (He, 2007), cloning a SIM was possible.

Through doing this it was possible to determine Ki. Together with the IMSI this is all

that is necessary to clone a SIM card.

Initial methods of finding Ki were known as plain text attacks. This comprised of

sending a number of RANDs. A figure of 217 RANDS would be enough to determine

the Ki (Quirke, 2004). This test used repeated 2R attacks. Dejan Kaljevic used 2R, 3R,

4R, 5R attacks to reduce the amount to between 213 and 215 RANDs. This method

depending upon the speed of the SIM could retrieve Ki within 1 hour (Quirke, 2004).

There have been methods proposed to counter this (Elatec, 2007). To run COMP-128

RUN_GSM_ALGO is sent to the SIM. This generates a 12 byte output (SRES (4),

Kc(8)). One prevention method is to limit the amount of times this command can be

run, but this would limit the SIM life. Another is pattern recognition. When the

command is run several times in a short space of time, send a wrong SRES back.

An alternative method called a partitioning attack was developed by IBM (Brumley,

2004). This was based side channel attacks, which relies on leakage from the

electronics on the SIM (Mayes, 2006). This takes the form of variations in leakage

24

current or electromagnetic radiation. This enabled carefully chosen RANDs to be

used. This reduces the number of queries to as little as 8 (Brumley, 2004)

SIMs now use either COMP-128v2 or v3. This at the moment appears to be safe from

cloning (Brookson, 2005). The details are still not published so may yield future

problems. If authentication is to be considered strong (Borghino, 2006), it must

employ at least two-factor authentication. SIM alone is classed as one factor

authentication. If SIM cloning is to be prevented in the future it may be necessary to

move to two factor authentication.

2.4 Weaknesses in UMTS AKA

2.4.1 Anonymity

There are occasions when a user must send their identity (IMSI) to the network.

This is sent in clear text and there are a number of devices on the market (Strobel,

2007), which can cache IMSIs. There are also certain locations where an IMSI is

more likely to be transmitted, such as airports and tunnel exits. Sending IMSI in

clear text compromises confidentiality and privacy as specified by 3GPP (3GPP TS

33.801, 2005) and this is an essential requirement of a range of applications

including mobile voting (Barbeau and Robert, 2005).

The reason the problem is present in the three generation of networks described

can be explained by considering the conundrum posed by Thomas Aura (Aura,

2009). You have just got off an aircraft, how does the network know who you are?

Any concealment would prevent the network identifying the user.

25

3 bits 2-3 bits 9 – 10 bits

MCC = Mobile Country Code (234 UK)

MNC = Mobile Network Code (33 Orange)

MSIN = Mobile Subscriber Identity Number

Figure 2.13: IMSI Structure (3GPP TS 23.003, 2009)

Figure 2.13 shows the structure of IMSI. It is this structure that makes the IMSI

easy to identify through traffic analysis (Strobel, 2007). The MCC and MNC let

the serving network know where the user’s home network is. It is MSIN, which

identifies a user and is only known by the home network. It is in MSIN where any

identity concealment needs to be applied. There is research in this area and this is

discussed in section 2.5.1

2.4.2 Man-in-the-Middle Attack (MITM)

Researchers Ulrike Meyer and Susanne Wetzel (Meyer and Wetzel, 2004)

demonstrated how it was possible to perform a man in the middle attack on a

UMTS network despite all the security features. This attack is performed in two

phases.

MCC MNC MSIN

26

Phase one involves obtaining the mobile’s IMSI and TMSI. This is easily done in a

GSM network as encryption can be turned off. The false mobile then tries to

register with the genuine UMTS network using either the TMSI or IMSI just

obtained. In response, the network then sends RAND and AUTN. The mobile

disconnects when this is received.

Phase two involves getting the genuine mobile to register with the false base

station by sending the original the RAND and AUTN and getting it to calculate

RES. The false station re-initiates an authentication request to the network. This

time the false station has the correct RES. The AV will still be valid because it had

no acknowledgement. This method has taken advantage of lack of encryption in

authentication and backhaul with GSM.

2.4.3 Re-direction Attack

There are three actors in the authentication process (3GPP TS 33.801, 2005). These

are the user (mobile), the serving network (MSC) and the home network (HLR). In

UMTS two of them are authenticated the user by XRES and the home network by

XMAC-A. Only the serving network is not authenticated meaning an

authentication vector can be used on any serving network leading to a redirection

attack. This all changes in LTE networks, where the serving network id (SNID) is

used in the authentication process. All the research projects below use a nonce or

random number generated by the serving network in the encrypted data to prevent

this kind of attack.

27

2.4.4 Denial of Service (DoS)

Some DoS attacks are very difficult to stop such as those employing frequency

jamming. These are not consider a major concern by 3GPP (3GPP TS 33.801,

2005) as they are very localised and considered not to be worth the effort by

criminals. There is a need to prevent denial of service attacks when caused by

architecture or protocols. The data in the authentication process is sent in clear and

unprotected so vulnerable to denial of service attack. The SQN re-synchronisation

process involves the both the serving network and home network in the process. A

rogue station could continually send the user a used vector forcing it to re-

synchronise (Zhang and Fang, 2005). This would cause critical links to become

overloaded.

2.5 Related Research

2.5.1 Identity Concealment

Identity concealment covers anonymity, privacy and confidentiality. It avoids a

user being tracked by their IMSI. There are a number of research projects, which

address solely this area rather than the authentication process as a whole.

Perfect identity concealment (Barbeau and Robert, 2005) describes three possible

solutions. Their one of choice uses an IMAN (International Mobile Anonymous

Number). The IMAN is generated by hashing SQN, RAND and AK using MD5. A

new IMAN is generated every authentication request. The disadvantage of this

method is that there runs the risk of a collision with two identical IMANs. This

results in another IMAN being generated, which ultimately affects performance.

28

There are also concerns about the security of hash functions based on MD5 (United

States-Computer Emergency and Readiness Team, 2008).

A solution along similar lines is Improved User Identity Confidentiality (IUIC)

(Sattarzadeh et al, 2007). In this solution anonymous tickets are used to avoid

sending the IMSI. The tickets are generated by an Anonymous Ticket Manager

Module (ATMM). The ATMM is integrated into the AuC in the HLR. What is not

indicated is whether the ATMM is a software or hardware implementation. The

MS stores two tickets one for current use and one for future use. This method does

have a number of disadvantages. As the ticket is used in generating the vector only

one vector at a time is generated. This would result in increased network traffic if a

user needs to authenticate regularly. This would not be a problem in a LTE

network, which only generates one vector because of the key hierarchy. The

method is quite wasteful of tickets. There is only need for one ticket, which could

be replaced at the end of the authentication process. This results in three tickets

being assigned to the mobile during authentication. There are several HLR/AuCs

in a network, does each have an ATMM? How are they co-ordinated? Will they

operate in a roaming environment? If the IMSIs are identified with a particular

AuC, this could lead to a targeted DoS attack.

2.5.2 Mutual Authentication

Sequence Numbers (SQN) were introduced into UMTS networks primarily to

prevent replay attacks and in turn false base station attacks (3GPP TR 33.102,

2009). Sequence numbers have however introduced problems of their own. To

29

achieve synchronisation and re-synchronisation requires a lot of work (Lei et al,

2007). A case study of the Docomo network in Japan (Mochizuki, 2006) found due

to the complexity, time and cost considerations an insufficient implementation was

implemented. In this case a fixed value based on IMSI is used. This solution does

not provide freshness, which is the key to defeating replay attacks.

When SQN is implemented as 3GPP intended, weaknesses came to light (Meyer

and Wetzel, 2004). As SQN in the MS has a lower value (previous SQN) and an

upper limit (pre-determined), there is a limit to the value of SQN. This means if

there is no acknowledgement from the MS, the same Authentication Vector (AV)

is used again. This attack is described in more detail in the section 2.4.2.

There are researchers (Lei et al, 2007) who believe that the use of sequence

numbers is a bad idea. There are a number of research projects aimed at improving

mutual authentication and all avoid the use of sequence numbers. Involving the

serving network (SN) in the authentication process is the key to preventing a

redirection attack. AP-AKA (Zhang and Fang, 2005) includes the serving network

identity and a random number generated by the serving network in the

authentication process. The random number is also used to prevent a replay attack.

This protocol distinguishes itself in the way it distinguishes between a home

network authentication or a foreign authentication. Disadvantages are it uses

vectors so causes bandwidth load and storage costs.

VC-AKA (Lei et al, 2007) has a number of similarities with AP-AKA in how

vectors are formed. The main difference is the use of vector combination. At the

start of the process a number of vectors are loaded from the home network. When

30

these are used up it avoids fetching more by using combinations of the previous

ones. This increases the storage costs in the serving networks and mobile, as is the

case with AP-AKA. In addition the method of calculating XRES would make it

incompatible with GSM.

HH-AKA (Harn and Hsin, 2003) is the first method covered not to use vectors. In

place of vectors HH-AKA uses hash chaining and hash MAC (HMAC). The

disadvantage with using this method is twofold. Firstly the hash is a one time

function, which means there will come a point where the chain will end. The

second problem is that the hashes are based on MD5. This has been compromised

and there are recommendations against its continued use (United States-Computer

Emergency and Readiness Team, 2008). This method would also lack

compatibility with GSM.

In X-AKA (Huang and Li, 2005), the initial authentication does not prevent a

redirection attack, because it is based on an encrypted timestamp. The timestamp

itself is generated by the mobile. This may pose a number of problems (Lei et al,

2007) because of the accuracy of the time. This raises the question as to whether

the user would ever get authenticated. X-AKA’s main contribution is in reducing

bandwidth consumption between the home network and serving network. It does

this by delegating the authentication process to the serving network. This is

achieved through the use of a Temporary Key (TK) to replace Ki. The values of

XRES (XSES in this case), CK and IK are all generated off TK. Once again this is

lacking in compatibility with GSM.

31

The final protocol to look at is called Perfect Forward Secrecy (Kim et al, 2007).

This has much in common with X-AKA in bandwidth reduction processes and the

means of generating a timestamp. Unlike other methods this protocol provides

anonymity protection. This is achieved through continually encrypting the current

IMSI. This is also the only method to use public key cryptography. The authors

cite Kambourakis et al (Kambourkis et al, 2004) in saying that mobiles now have

the processing power to use public key. The same document also states the reason

public key was not adopted by 3GPP was also down to performance and lack of

compatibility with GSM.

2.6 Summary

The chapter started with a review of current cellular security and discussed the

weaknesses still present. The chapter concluded with a review of other research in this

area. Of the protocols reviewed, only AP-AKA can satisfy compatibility with GSM,

which is part of the primary research question. AP-AKA would not satisfy any of the

secondary research questions. PFS is the only protocol to provide user anonymity.

The one area that stands out above others is the lack of compatibility with GSM. This

is a fundamental requirement, which could suggest the protocols are developed in

isolation from the real systems in which they would be expected to work.

32

Chapter 3 Research Methods

The literature review carried out in chapter two will provide the most valuable source

of information for addressing the research questions. This however is not sufficient to

generate all the information required. Data will need to be collected through primary

research methods. The aim of this chapter is to discuss the research methods

employed in the dissertation and the reason for employing them.

3.1 Case Study

Critics of case studies complain of too narrow a focus (Bell, 2008), which may not be

transferable to other areas. Using a case study would be appropriate because the

weaknesses identified in one network would be applicable to another. This is because

the 3GPP specifies architecture and protocols for UMTS networks. Although

operators have freedom in implementation it is unlikely these will differ significantly

and any research findings could be equally valid in another network. The use of a case

study has previously been used in cellular security. Yujiro Mochizuki (Mochizuki,

2006) used a case study as his main research method. This focused on the differences

between the UMTS network of Docomo in Japan and that specified by the 3GPP.

The part of the research question that the dissertation answers is related to network

architecture. The primary research question, questions whether the authentication can

be made more secure without altering the existing architecture. This is influenced by

what architecture is in place already. The research projects covered in the literature

review do not consider this and appear to be developed in isolation.

33

There are two uses of case study described (Bell, 2008). The first is as the main

research method and thus the basis of the dissertation. The second is to put flesh on

the bones of the research. The case study used in this dissertation is of the latter type.

Its main purpose is to ensure that the protocol could be implemented in a live

network. The network used as the basis for the case study is the Orange network. It is

an assumption as discussed above that other networks will be of the same architecture.

The changes in the equipment would be more related to the manufacturer rather than

operator.

3.2 Development of a Prototype

“Prototypes are a means for demonstrating that something can be made to work”

(The Open University, 2007). This method is chosen in a number of projects in

mobile security (Lunde and Wangensteen, 2006). This method is entirely appropriate

for this type of dissertation as the as the aim is to develop a more secure framework

for cellular access networks. There is a need to perform testing to show that new

protocols do stop a particular threat and also achieve coherence. How will this be

achieved? This method will be completed in three distinct stages. These stages are

(a) Design

(b) Implementation

(c) Testing

3.2.1 Design Phase

The other research methods described in this chapter will all feed in to the design

of the protocol and will need to interact with each other. The aim of this stage is

34

to address both the primary question and the secondary questions. The framework

will be developed using techniques from UML (Fowler, 2003) and UMLsec

(Jürjens, 2005), such as sequence and class diagrams. UML is a respected

modelling language for security design used in a number of security dissertations

(Lloyd, 2008) and (Lunde and Wangensteen, 2006).

3.2.2 Implementation Phase

With the design phase complete, there is a need to convert the design into an

implementation in software for testing. There are a number of network simulation

products on the market that are used in the research departments of many

universities. These include OPNET IT Guru, NS2, Matlab and packet tracer.

Packet Tracer is the only one of the packages that I have used before. This is

developed by Cisco to build and test router networks and as such not suitable for

use in this dissertation. Of the other packages all would have required additional

training on how to use them without any guarantee that they would be suitable for

task in hand. Some of these also cost a deal of money to purchase. The decision is

therefore taken to build the design using Java. Java’s client-server architecture can

be used to simulate the exchange of protocols between the MS and SN. Java also

has a number of cryptography packages (Hook, 2005). Building a simulation

package using Java has been implemented before by Lars Lunde and Audun

Wangensteen (Lunde and Wangensteen, 2006) with Generic SIM Authentication

System (GAS). The advantage of using Java is that it avoids having to force the

simulation package to fit the design or compromise the design to fit the package.

35

3.2.3 Testing Phase

The testing phase, which will ultimately answer the research question, is split into

three distinct parts. The first part will assess the prototype in dealing with the

weaknesses highlighted in the literature review. The testing will be of the

controlled experiment type (Rugg and Petre, 2007). This is where selected data is

changed to simulate a threat. The tests carried out are to verify that the protocol

can eliminate a particular threat. The tests are discussed in more detail in chapter

five.

The second part will assess compatibility of the new prototype. This will include

interworking with GSM, suitability for LTE networks and suitability for roaming

environments

The third part will assess the prototype in comparison with other prototypes

covered in the literature review.

3.3 Questionnaire

One of the secondary research questions (section 1.4), considered the use of two-

factor authentication. There are generally three factors in authentication (Kemshall

and Underwood, 2007).

(a) Something you have (token)

(b) Something you are (biometrics)

(c) Something you know (password)

Something you have is a SIM card. This means any second factor would have to

36

involve the user. A survey was carried out to find out what second factor users would

want on their mobile.

Questionnaires have been used before in cellular security (Clarke, 2006) and more

specifically for authentication. In the survey undertaken by Clarke, participants said

that they did not use a PIN because their phone was never off. This is how the PIN

works, it only asks for the number when it is powered up. Desktops have an auto

locking feature, which locks the computer after a period of inactivity. This would

improve the security of mobiles, but would users want it? 3GPP (3GPP TS 33.102,

2009) specify a delay of 15 seconds maximum, but would users accept a longer delay

if it improved security? These represent three questions that a questionnaire would be

a suitable vehicle to answer.

As well as answering the questions that are linked to the research questions, a

questionnaire gives the opportunity to find a users experience of cellular security.

Most of the weaknesses highlighted in the problem overview are as a result of

research in universities. There is no evidence that weaknesses have been exploited on

a live network. This lead (Howard, 2005) to the conclusion that many of the

weaknesses have been overplayed. According to recent reports (Publictechnology,

2009) there are now over 76 million mobile phone connections in a population of

approximately 60 million. If there was a serious problem it would have come to light,

but what are individual experiences of security?

Seven methods of sampling are described (Biggam, 2008). The questionnaire is based

on convenience sampling. This is because the sample has been drawn from family,

friends, work colleagues and social groups. As such the sample can not be classed as

37

random and therefore representative of the population as a whole. There are an

estimated four billion (Design Council, 2009) subscribers in the world. One percent of

this would be 40 million. This is clearly out of the scope of this dissertation. The

questionnaire above (Clarke, 2006) attracted 189 participants. This questionnaire

attracted 64 participants, which is roughly a third of the Clarke survey.

The questionnaire (Appendix B) explained the purpose of the research and assured the

participant of confidentiality along with ethic guidelines (Bell, 2008). No question

asked was unethical in nature and worded where possible in a non technical way. To

ensure this, the questionnaire was piloted before general release using non technical

participants.

The questions themselves will be one of four types (Rugg and Petre, 2007)

(a) Open (simple)

(b) Closed (simple)

(c) Using a Likert scale

(d) Multiple choice

Closed questions in each case were followed by open questions depending upon the

answer given. This was to gain further details on any experiences. The questionnaire

asked for the persons name so that questions can be followed up but this was not

made compulsory if the person wished to withhold their name. The questionnaire was

carried out online using the services of http://freeonlinesurveys.com/.

38

Chapter 4 Data Acquisition

4.1 Questionnaire Results

The survey (appendix B) was conducted to find user attitudes to mobile security. The

questions were split into distinct parts. Questions one to five were designed to

generate a profile of the user. This was to assess if attitudes varied according to

gender, age or whether they were from a technical background. It was hoped that

there would be an even split between the genders and technical ability. The full results

are presented in appendix C. The technical / non-technical produced a 50:50 split and

the male/female produced a 45:55 split. In having an equal split helps reduce bias by

focusing on one particular group, whose views could be skewed.

Questions six to fourteen focus on user attitudes and experiences of mobile security.

The concerns related to mobile security again followed a bell curve shape with a

slight shift to not being concerned about it. Only two participants have experienced

problems with fraud. One had a phone ordered in a partners name but sent to a

different address. This is generally referred as a subscription fraud. The other was

billed for calls to a European location. This is similar to the Japanese girl described by

Yujiro Mochizuki (Mochizuki, 2006) who suffered from a billing fraud with Docomo.

Seven participants reported a lost or stolen phone. The time it was taken to spot the

loss ranged from a couple of minutes to 24 hours. None of them experienced any

misuse of their phones whilst lost but 24 hours left a lot of time. The majority of

participants (87%) had used their phones abroad. This would illustrate the need to

ensure security in roaming environments. The use of Bluetooth produced a near 3:1

split in the male participants and a near 50:50 split in female participants. Of those

39

that use Bluetooth only a third leaves it on all the time. Leaving Bluetooth on all the

time increases the risk of a number of attacks (Sapronov, 2006).There is exactly a 2:1

between those that do not use a PIN and those that do. This directly contrasts with

research at Plymouth University (Clarke, 2006), which found two thirds used a PIN.

The remaining questions focused on features they would like in future mobiles in

relation to security. The 3GPP (3GPP TS 33.102, 2009) specify a maximum delay of

15 seconds. The majority of the sample (67%) did not want an authentication delay

longer than 15 seconds. This would push against using public key encryption in the

authentication. One participant responded with the reply ‘depends what the benefits

are?’ Another commented that is smart phone took well over a minute to load before

he could use it in any case. This question was designed to find if users would back a

longer limit than 3GPP. The result is that they agree with the limit. As previously

discussed it is necessary to have at least two factor authentication, for a system to be

secure. The second factor would be something you know (password, PIN) or

something you are (biometrics). More than 50% wanted chip and PIN possibly

because of the success of this in banking. Of the remainder the split was nearly 50:50

between biometrics and passwords. Comment made by one of the participants stressed

the cost and the problem in selling the phone on, when asked about biometrics. One

other who selected chip and PIN did comment that biometrics looked more secure but

did not want it. Interestingly 67% of participants that selected chip and PIN do not use

the PIN they already have. 72% of participants would like to see an auto lock feature,

which locks the phone after a period of inactivity. As well as the security

improvement it also helps reduce false calls. As this dissertation has indicated there

are many weaknesses in the network. Mochizuki (Mochizuki, 2006) illustrated a

40

number of weaknesses due to insufficient implementation. The survey tried to

determine that if one of these weaknesses was exploited but quickly fixed, would this

affect the usage of their phone. The good news for operators is that 50% would carry

on as normal. The bad news is 50% would alter their calling habits to some extent

thereby reducing revenue. The final question in the survey assessed whether users

were prepared to use security critical applications. The results contrast sharply with

question six. The results show that females are far more negative towards the

applications than males with the exception of polling where both are equally negative.

Females are especially negative towards financial applications.

4.2 Prototype Design

The protocol design described here is developed to enable the radio access networks

of cellular operators to be more secure. The following assumptions therefore need to

be made.

• All core home network elements are assumed to be secure. This

includes MSC, HLR and SLR

• The serving network core elements are secure. This would just be the

MSC in a serving network.

• The links between core network elements are secure and the links

between serving and home networks are also secure.

• The cryptographic algorithms Kasumi and Milenage are secure

•

41

4.2.1 Two Factor Authentication

One of the secondary questions posed was ‘can two factor authentication improve

security in UMTS networks?’. Bruce Schneier (Schneier, 2005) argued that two

factor authentication would not make any difference because the nature of attacks

such as man-in-the-middle attacks could compromise two factor authentication as

well as one factor. The literature review however described how user’s details

could be cloned through SIM cloning kits or by a partitioning attack. Both methods

required access to the subscriber SIM. A further fraud which requires no additional

equipment is SIM swapping. As the questionnaire illustrated many people do not

protect their phone with a PIN. This means if the phone is left unattended the SIM

cards can be swapped enabling calls to be made at the victims’ expense. This is

less likely to be spotted than other forms of mobile theft. This illustrates that two

factor authentication would improve security.

The questionnaire found chip and PIN to be the most popular method of second

factor authentication. To achieve this, the secret key Ki is to split into two parts the

main part as now will be kept on the SIM card. The second part is the user PIN

number. The PIN will be a 4 digit decimal number as used by banks. The main part

will be adjusted so the total length will remain at 128 bits.

When the phone is powered up the user will be required to enter their PIN. The use

case for this is shown in figure 4.1.

42

<<include>>

<<include>>

<<extend>> <<extend>>

Figure 4.1: Use case diagram for the generation of MACsn in the USIM

MACsn is used in the authentication phase, which will be described in the next

section. When the phone is first powered up the user will be requested to enter

their PIN. If the authentication is successful the PIN is stored in volatile memory.

Volatile memory is where all data is lost when power is removed. As most phone

designs have the SIM behind the battery, the battery will need removing to remove

the SIM. As volatile memory is used the PIN will need re-entering if the SIM is

taken out for whatever reason. The <<extend>> notation in the diagram is a UML

(Fowler, 2003) stereotype to signify that the PIN will be obtained from the user or

memory. The reason for storing the PIN in memory is twofold. Firstly to enable

continuity of service, this would be affected by a car driver going through a no

coverage zone or tunnel. If the PIN is in memory it will be obtained from there

first. The second reason is so that the PIN can be used as it is now, a means of

locking the phone. The PIN inputted can be checked with the value stored memory.

Get data from Serving Network

Generate MACsn

Get Secure Key

User PIN Memory PIN

43

In the questionnaire 72% of participants wanted automatic locking of the mobile as

in desktop computers. The PIN would be used to unlock it again. The phone would

still be able to receive incoming calls whilst locked.

4.2.2 Full Network Authentication

The main protocol builds upon the research undertaken in ‘Providing Perfect

Forward Secrecy AKA (PFS-AKA) (Kim et al, 2007) and X-AKA (Huang and Li,

2005). MACsn (Figure 4.1) is generated in a manner similar to PFS-AKA. The

main criticism of using timestamps (Lei et al, 2007) is that the time could vary

widely between different users’ for a variety of reasons. This would result in either

having a range of acceptable timestamps so wide it would be ineffective or the

possibility that the mobile is unable to access the network. A more effective

solution would be to use the serving network to generate the timestamp. The

advantages of this are that the MSC contains charging units for generating billing

files. This means the time must be extremely accurate to ensure against over billing

and this is regulated by ofcom in the UK. The time is generated off an atomic clock

and is automatically adjusted for drift. This contrasts with the time in the phone,

which is set by the user.

The RANDs is also generated by the serving network as opposed to the phone in

other methods. The advantage of doing this is to remove some of the processing

from the phone, which is limited in processing capabilities compared to the serving

network. A second advantage is that as the RANDs, timestamp and Serving

Network ID (SNID) are appended to the phone data, it removes the possibility of

tampering with these parameters. In PFS it is stated that a replay attack can be

44

prevented by the timestamp or nonce in the MAC. As mentioned above if the

timestamp check has a wide range of acceptable values a replay attack could be

launched, which would not be detected by MAC or timestamp. In this prototype

the timestamp would prevent a replay attack because it is sent from the serving

network and not open to manipulation on the air interface. In a roaming network

the timestamp could be adjusted for time zone differences by using the country

code in SNID. The MACsn would also reject the request for the same reason.

In UMTS AKA both freshness and mutual authentication are achieved by using

sequence numbers (SQN). As discussed in the literature review sequence numbers

have a number of weaknesses. Most solutions to weaknesses in the UMTS

authentication process avoid sequence numbers and subsequent re-synchronisation

procedures. This protocol uses the timestamp as already discussed to achieve

freshness. To achieve mutual authentication an authorisation code is used. This is a

technique used by UK banks for authorising online customers. In the prototype, the

authorisation key (128 bit) will be stored in the USIM and AuC. The phone will

generate four random numbers between 1 and 32. The numbers can appear in any

order but no number will appear more than once. These random numbers form the

authorisation code. This code is included in the message sent to the serving

network (figure 4.1). Only the positions are sent the data itself is never sent. In this

way the phone controls its own mutual authentication without the need for re-

synchronisation. This is one of the secondary research questions posed. The data

from these positions together with the timestamp replace SQN and AMF. AMF in

live networks (Mujizoko, 2006) is set to 0000. The only use of the data is the least

significant bit is set to 1 in LTE networks. As this data does not contribute to the

45

authentication process it has been replaced.

The remainder of the authentication process remains as in UMTS authentication

protocol. In particular keeping IK and CK as in UMTS AKA aids inter working

with GSM as described in section 2.5. In addition no weaknesses have been

highlighted using these parameters. The new authentication vectors are illustrated

in figure 4.2. The sequence diagram is illustrated in figure 4.3

RANDh AuData

NV Ki

XMACh XRES CK IK XMACsn

Key

NV = Network Verification = Authorisation Code || Timestamp

AuData = Authorisation Data = Timestamp || SNID || RANDs || IMSI

Figure 4.2: Prototype Authentication Vectors

F1 F5 F2 F3 F4

46

RRC Request (M1)

(Ts :: Snid :: RANDs) (M2)

(MACsn :: IMSI :: AuthCode :: AuthType) (M3)

IMSI (M4)

(HLRID:: IMSI :: nIMSI) (M5)

(MACsn :: IMSI :: AuthCode :: RANDs :: Ts :: Snid) (M6)

No

Authentication Rejected

Yes

AV = (RANDh :: MACh :: CK :: IK :: XRES) (M7)

(RANDh :: MACh) (M8)

XRES (M9)

Authentication Rejected

ck{ TMSI :: nIMSI ) (M10)

Figure 4.3: Full Network Authentication Sequence Diagram

MS MSC HLR SLR

Check Validity of Timestamp

MACsn Equal?

Generate AV

Check MACh

Generate XRES

XRES Equal?

47

4.2.3 Local Network Authentication

The literature review describes how bandwidth consumption can be reduced

(Huang and Li, 2005) by delegating subsequent authentications to the serving

network. This forms the basis for the local network authentication. The

requirement is to generate a temporary secret key (TK) to replace Ki. To ensure

this is key is unique and related to the subscriber it needs to have been generated

from Ki. The protocols that employ this technique create Tks from a new function

in the HLR/AuC and append it to the Authentication Vector (AV). The solution

used in this prototype is to create Tks in the MSC by XORing CK and IK. This has

the advantage of reducing the bandwidth consumption as compared to other

methods but also avoids having to add a new key generating function in the

HLR/AuC. This is not too dissimilar to LTE networks where CK and IK are

concatenated to form Ksn (figure 2.10). The main change that needs to occur in

this model is the VLRs need to be upgraded to provide security functionality.

The sequence diagram for the local network authentication is the same as the home

network authentication except the HLR functionality is carried out by the serving

network. The main difference affects the authentication code. The authentication

key like Ki should not leave the home environment. The solution is to select four

random numbers from the temporary key. The other change involves the random

numbers. In the home network authentication, RANDs is generated by the serving

network and used to generate MACsn. The HLR generates a random number

RANDh for its challenge. In this case there is no need for the serving network to

generate two random numbers, so RANDs will be used throughout.

48

To limit the use of the temporary key a validation period is used by both PFS-AKA

and X-AKA. The solution here is to use a counter maintained by the mobile phone.

Arbitrarily the count value is set to five to match the number of AVs sent from the

HLR/AuC to the serving network in UMTS (3GPP TS 33.102, 2009). The counter

is maintained by the mobile phone to strengthen the two factor authentication. If

the count is set to zero a full network authentication is carried out indicated to the

network by AuthType being set to zero. If the count is non zero the AuthType is

set to one and a local network authentication is carried out. Once the counter

reaches five it is reset to zero. If the mobile phone is turned off and back on again

the counter is reset to zero. This is to prevent SIM swapping.

4.2.4 Anonymity

The final secondary research question posed was

‘Is it possible to provide a solution where the user’s anonymity is preserved?’

The literature review covered a number of different methods of achieving user

anonymity. The method employed is based on IUIC (Sattarzadeh et al, 2007). This

method as all the others covered relies on the HLR/AuC to generate the new IMSI.

This does not account for the way live networks operate. In the early days of the

Orange network the first two digits of the MSIN part of IMSI (figure 2.13)

indicated the subscriber HLR. This then bound the user to the HLR. This changed

to allow the subscriber to move around to balance loads between the HLRs. To

achieve this, a Service Location Register (SLR) is used as a network look up.

When an IMSI arrives at the MSC in the users’ home network, the IMSI is sent to

the SLR. This is where any allocation of anonymous IMSIs needs to be based.

49

(a) M801 Protocol (b) Other protocols

Figure 4.4: IMSI Updates between Core Network Elements

Figure 4.4 illustrates the difference in using the SLR to generate a new IMSI. This

halves the number of signalling messages and more importantly removes the need

for signalling between the MSC and HLR.

The adjustment to the SLR is to create a table of unused IMSIs. The MSIN is ten

digits long in the Orange network. This leaves a possibility for ten billion IMSIs.

When an IMSI is allocated to a user on a temporary or permanent basis it is

removed from the available list. If it is temporary it will be added back to the list

later. Figure 4.4 shows the interaction between the MSC and SLR. This increases

the amount of information between the two when compared to UMTS, but involves

less overhead than other methods. The users’ permanent IMSI is always used in

MACsn and in communication to the HLR. This avoids making changes to the

HLR.

4.3 Prototype Implementation

As detailed in section 3.4 an implementation of the prototype is to be produced using

java’s client server architecture. The prototype will be built using the netbeans IDE

6.0.1 platform. The classes provided (Appendix E) simulate the components of a

SLR SLR

HLR HLR

MSC MSC

50

cellular network. The client side comprises of the mobile phone class and SIM card

class. The mobile phone class implements a GUI interface using java.awt.* (figure

4.5) to enable user interaction. Pressing the start button simulates a full authentication

and the process this goes through is illustrated in the flow diagram (figure 4.6).

Figure 4.5: Prototype GUI Interface

51

y

n n

Mobile y

n n y

n

y

Core Network

y

Mobile y

Core Network

y

Figure 4.6: Flow Chart for Java Implementation of M801 Protocol

Start

PIN?

Start Authentication

Ts ?

Count <3?

MACsn ?

Generate MACh and XRES

Count <3?

MACh ?

Generate XRES

Failed

Failed

XRES?

Passed

52

1 Connects to 1

*

Communicates with

1

* Communicates with *

1

Communicates with *

* Connects to

1

Figure 4.7: Prototype Class Diagram

SimCard <<critical>> {secrecy = CK IK Tk AUTH_KEY KI} {integrity = XMACsn XMACh XRES}

XMACsn XMACh XRES code :Data KI AUTH_KEY CK IK Tk : Keys

#SimCard +userLogin() : Data +checkMAC() : Boolean +generateSecretKey() : Data +generateKi() : Data +authPass() : Data +createMACsn() : Data +createCK() : Data +createTK() : Data +createIK() : Data +getIMSI() : Data +findIMSI() : Data +getNewImsi() : Data +setNewImsi() : Data

Mobile Phone <<critical>> {secrecy = CK IK} {integrity = XMACsn XRES} {freshness = ts RANDs RANDh}

RANDh RANDs ts :Data imsi nImsi authCode : Data snid XRES authType XMACsn : Data CK IK : Keys

#MobilePhone +authentication() : Data +autheticationCodeGenerator() : Data +authenticationType() : Data

MobileSwitching Centre <<critical>> {secrecy = CK IK TK} {integrity = XMACsn XMACh} {freshness = ts RANDs RANDh}

XMACsn XMACh ts XRES :Data RANDs RANDh : Data CK IK TK : Keys

#MobileSwitching Centre +timeStamp() : Data +sendAuthData() : Data +fullAuthentication() : Data +localAuthentication() : Data

HomeLocationRegister <<critical>> {secrecy = CK IK} {integrity = XMACsn XMACh} {freshness = timeStamp}

XMACsn XMACh ts timeStamp :Data RANDs RANDh XRES code : Data CK IK : Keys

#HomeLocationRegister +timeStamp() : Data +checkTimeStamp() : Boolean +macSN() : Data +authentication() : Data

ServiceLocationRegister {secrecy =AUTH_KEY Ki}

HLRID imsi :Data

#ServiceLocationRegister +add() : Data +findSub() : Data +delete() : Data

AuthenticationCentre <<critical>> {secrecy = AUTH_KEY Ki}

code imsi :Data Ki Auth_Key : Keys

#AuthenticationCentre +authPass() : Data +findKi() : Data

53

The classes in figure 4.7 will simulate the equivalent elements in a live network.

Where new features are introduced these will be implemented in the relevant class to

where they would be expected to be implemented in a live network. The diagram in

figure 4.7 shows the class interaction for a full network authentication. The VLR class

is added for a local authentication. This is the same as the HLR class, whose

functionality it takes over. To aid the main classes three supplementary classes have

been created (figure 4.8). Encryption and Utils are based solutions in David Hook’s

book ‘Beginning Cryptography with Java’ (Hook, 2005) using the Java Cryptography

Environment (JCE). The SecureRandomNumber class is based on the book ‘Java

Cryptography Extensions’ (Weiss, 2004).

Figure 4.8: Class Diagram for Supplementary Classes

Secure random number class generates RANDs and RANDh for the authentication

process. This class is only implemented in the core network package (appendix D).

Encryption performs all the cryptography required such as MACsn. Utils is a

conversion class to convert between hex, binary, byte and decimal. These two classes

are implemented in both the core network package and mobile phone package. In a

SecureRandomNumber {freshness = sRand}

sRand :Data

nextBytes() : Data +getInstance() : Data

Encryption <<critical>> {secrecy = Key}

ptLength ctLength cipherText :Data plainText : Data key : Keys

#AuthenticationCentre +authPass() : Data +findKi() : Data

Utils

data :Data

toHex(byte[] data length) : Data +tohex(byte[] data) : Data +toInt() : Data

54

live network signalling message would include the source and destination addresses

as well as the service request. The signalling employed in the prototype is more

simplified than a live network. Java communicates between classes by sending

messages to them. This is the case between all the classes connected together in figure

4.7. In addition a protocol has been developed between the mobile phone class and

mobile switching centre class. This enables each of them to request services from

each other and also report status messages such as failed MACsn or authentication

successful. The prototype used is illustrated in table 4.1

Table 4.1: Protocol for Java Implementation of Prototype

As well as the protocol, the communication is achieved using classes from java’s

networking classes in java.net.*.

Code Description Direction of Communication

A Start Authentication Process Mobile Phone -> Core Network

B Failed MACsn Check Core Network -> Mobile Phone

C Challenge Sent Core Network -> Mobile Phone

D Failed Time Check Core Network -> Mobile Phone

F Request Communication Channel Mobile Phone -> Core Network

I IMSI not Found in the Database Core Network -> Mobile Phone

P Failed Mutual Authentication (MACh) Mobile Phone -> Core Network

Q Quit Application Mobile Phone -> Core Network

R Failed PIN Request three times Core Network -> Mobile Phone

S Request Authentication Core Network -> Mobile Phone

W Authentication Successful Core Network -> Mobile Phone

X Send Response to Challenge Core Network -> Mobile Phone

Z Authentication Failed Challenge Core Network -> Mobile Phone

55

Chapter 5 Data Analysis and Results

5.1 Prototype Testing and Results

Section 3.2.3 lists three areas for the testing phase. Only phase one actually involves

testing the other two are related to prototype analysis. Phase one addresses identified

weaknesses in the UMTS architecture. The testing will be accomplished using test

scenarios implemented using the Java implementation described in chapter three. The

GUI shown in figure 4.5 shows a test select number drop down box. The drop down

lists includes a number of tests described below. Pressing the Start button will execute

the selected test. The test will be a modified version of the full authentication

undertaken when the test 0 is selected, but with data changed to simulate the various

attacks (controlled experiment). Each test will produce a test report (Appendix D)

indicating stages passed and where the test scenario was rejected. The reports will be

of a similar style to statistical reports produced on a live network. The IMSIs used in

the tests are not based on real subscribers. The values were randomly selected.

Test One: Normal Authentication

It is important that an unauthorised user is not able to gain access to the network, but

equally it is important that genuine users should be able to gain access. This first test

demonstrates that a genuine user can gain access to the network. The protocol will be

run seven times. This is to enable a complete cycle of full and local network

authentications. To pass this test the prototype must demonstrate the following

characteristics (Table 5.1).

56

(i) The first authentication should be a full network authentication followed by

four local network authentications. The cycle should then repeat for every five

authentications.

(ii) The first authentication should use the users IMSI to identify itself to the

network. Subsequent authentications including full network authentication

should use the TMSI allocated.

(iii) The TMSI should be different for each authentication.

(iv) All authentications should have an authentication status of successful.

Stage Test Parameter Result

(i) First Authentication with IMSI then use TMSI

Pass

(ii) One full authentication followed by four local authentications

Pass

(iii) Authentication parameters must change with each authentication

Pass

(iv) All authentications are successful

Pass

Table 5.1: Results of a Normal Authentication

Test Two: Redirection Attack

This is when an authentication vector generated on one network can be successfully

used on another network. This is a highlighted weakness in UMTS networks, but the

57

prototype should reject it. To simulate this attack the SNID is changed just before the

MACsn is generated in the mobile for the identity of another network. If this test is

successful, the authentication should get rejected by the MACsn check (Table 5.2).

Table 5.2: Results of the Re-direction Attack

Test Three: Replay Attack

A replay attack is where a previously used vector is used to gain access to the network

for a second time. This is not perceived to be a problem with UMTS networks, but is

included in the testing phase to achieve coherence. Coherence in the context of this

dissertation means that by providing a solution to one problem you do not

inadvertently create another problem. To simulate this attack the protocol is run seven

times as in test one. On the second run the authentication data sent to the network is

also saved as a parameter called replay. When the third run is undertaken the replay

data gathered in the second run is sent to the network rather than the actual

authentication data. If the test is successful (Table 5.3) the authentication should once

again be rejected at the MACsn check.

Stage Test Parameter Result Rejection Stage

(i) Reject authentication vector sent from another serving network

Pass MACsn

58

Table 5.3: Results of the Replay Attack

Test Four: Mutual Authentication

This is also provided in UMTS networks. UMTS uses sequence numbers, which

introduced weaknesses to the UMTS network (Chapter 2). Part of the aim of this

dissertation is to find a more suitable means of providing mutual authentication. A

method based on an authentication code is described in section 4.2.2. When this test is

selected the authentication key is changed for another value. If successful (Table 5.4)

this would result in the mobile rejecting the authentication based on an incorrect

MAChn.

Table 5.4: Results of Mutual Authentication Test

Test Five: Anonymity Test

One of the aims of this dissertation is that a user should not be tracked by their IMSI.

A new IMSI should be assigned every time a home network authentication is carried

out. A solution to achieve this was described in section 4.2.4. In a normal

Test Test Parameter Result Rejection Stage

(i) Authentication fails on the third run

Pass MACsn

(ii) All other authentication runs are succesful

Pass Not Apllicable

Test Test Parameter Result Rejection Stage

(i) Reject authentication response sent from home network

Pass MAChn

59

authentication (test one) only the first run uses the IMSI. To ensure all seven runs use

the IMSI, the authorisation type will be set to 0 (full network authentication). The

TMSI in the SIM card class also needs to be set to an empty string, which will the

force the mobile to use IMSI. If successful (Table 5.5) the IMSI should display a

different value each time it is run and also should carry out a home network

authentication.

Test Test Parameter Result

(i) A new IMSI is generated every run

Pass

(ii) New IMSI from previous run is used as the current IMSI

Pass

(iii) All authentications are full authentications

Pass

(iv) All authentications are successful

Pass

Table 5.5: Anonymity Test

Test Six: Change of Serving Network

Unlike UMTS AKA, this prototype uses the identity of the serving network in the

authentication process. This is used to prevent a redirection attack as demonstrated in

test two. As the authentication parameters are bound to the serving network, if the

serving network changes these values become invalid. To overcome this if a change in

serving network is detected, a full authentication is initiated based on the new serving

network. To achieve this in the prototype, the serving network identity (snid) is

changed before the authentication parameters are sent by the network and the TMSI is

set to an empty string. TMSI is unique only within the serving network within UMTS.

60

To achieve a pass on this test (Table 5.6), the prototype must satisfy the following

requirements.

(i) All authentications must be successful.

(ii) The first two runs should be as test one. Third run must be a full

authentication using IMSI.

(iii) After the change of serving network the prototype should function as test

one.

Table 5.6: Change of Serving Network

Test Seven: User Verification

This was the sole check used in GSM, just to verify the user was genuine. It is also

used for the same purpose in UMTS. To simulate a false user, the RAND used in the

mobile is set to the one sent by the serving network, whereas the value in the home

Test Test Parameter Result

(i) All authentication runs are successful

Pass

(ii)

The third authentication run involves a change of serving network and should carry out a full authentication not local authentication

Pass

(iii) A new IMSI should be used not TMSI

Pass

(iv)

Once authenticated by the new serving network the process should follow step one

Pass

61

network uses a value generated by the HLR. This change would not have worked had

a local authentication been carried out as RANDsn is used throughout. The reason this

was used is to avoid changing the secret key and the consequences this would have. If

this test is successful (Table 5.7), the attempt will be rejected during the XRES check.

Test Test Parameter Result Rejection Stage

(i) Reject authentication challenge sent by Mobile Station

Pass XRES

Table 5.7: User Authentication Check

Test Eight: Timestamp Check

This is introduced as an anti-replay measure. It is used to provide the freshness of the

response. This is used in two of the protocols described in chapter two and there is an

implementation of SQN that also uses a timestamp. There are two ways of checking

the timestamp. The first method is the most logical. In this case the timestamp sent by

the serving network is checked by one generated by the home network and if the

difference is with in limits the timestamp check passes. This check is only performed

during full authentication. In the second method the time stamp is modified by the

mobile. In this case the test will fail the MACsn test (Table 5.8).

Table 5.8: Timestamp Check

Test Test Parameter Result Rejection Stage

(i) Reject timestamp sent by the mobile station

Pass MACsn

(ii) Reject timestamp sent by the serving network

Pass Timestamp Check

62

Test Nine: Wrong IMSI

This test is included for coherence. If an incorrect IMSI is sent three times the phone

is automatically locked by the network. This is to prevent an illegitimate user draining

the network of resources. The test is carried out by setting current IMSI to an

unknown value. If the test is successful (Table 5.9), the incorrect IMSI is rejected by

the SLR. After three attempts the phone locks.

Test Test Parameter Result Rejection Stage

(i) SLR rejects incorrect IMSI Pass SLR Check

(ii) Phone locks after three incorrect attempts

Pass Mobile Phone

Table 5.9: Wrong IMSI Check

Test Ten: PIN Check

As part of implementing two factor authentication a chip and PIN solution has been

provided. The test itself is not executed under the test scenarios but under a normal

authentication. If the PIN is incorrect it will fail the first value that requires Ki. This

will be MACsn once again. When MACsn fails it sends a failure report back to the

mobile phone to indicate PIN failure as shown in figure 4.2. If the PIN is entered

incorrectly three times the phone locks and code needs to be obtained from the

operator to unlock it. This prevents a brute force attack on the PIN

63

Test Eleven: Man-in-the-Middle Attack

This is the attack described in the literature review (section 2.4.2) carried out by

Meyer and Wetzel (Meyer and Wetzel, 2004). This test will be conducted through

analysis rather than simulation.

Assuming that the rogue station has obtained the IMSI/TMSI of the targeted mobile

as before. This time the IMSI/TMSI is sent with other authentication data such as

MACsn. It is possible that a rogue station could obtain the authentication data from

the mobile, but each request generates a new timestamp and RAND. As the home

network receives these values directly from the serving network, the rogue network

could not modify the data and would fail the MACsn test.

5.1.1 Performance Results

The performance results used in this section are based on calculation techniques

described by Al-Saraireh and Yousef (Al-Saraireh and Yousef, 2006) and

subsequently used by Hu et al (Hu et al, 2009). Table 5.11 illustrates the number of

bits each parameter consists.

64

(a)

(b)

* IMSI set to 60 bits as specified in figure 4.x rather than 128 specified by Al-Saraireh and Yousef.

** Timestamp represents year as yy not yyyy

Table 5.10: Authentication Parameters in (a) UMTS AKA (Al-Saraireh and

Yousef, 2006) and (b) M801 AKA.

Table 5.12 shows the number of bits in each message sent across the network. The

messages M1-M10 correspond to the messages in figure 4.3

Parameter Length(bits)

IMSI 60*

TMSI 32

SNID 48

Auth Type 1

RANDsn 128

RANDhn 128

Auth Code Position 20

Authentication Code 16

Timestamp 48**

MACsn 64

MAChn 64

RES 32

CK 128

IK 128

TK 128

Number of Vectors 1

Parameter Length(bits)

IMSI 60*

RAND 128

SQN 48

AK 48

AMF 16

MAC 64

CK 128

IK 128

RES 32

AUTN 128

Number of Vectors 5

65

Table 5.11: Number of bits per Message for the M801 Protocol

Number of messages sent between MS and SN

= M1 + M2 + M3 + M8 + M9 = 561 bits (M801 AKA)

= 396 bits (UMTS)

Increase in overhead = 42%

Number of messages sent between SN and HN

= M1 + M6 + M7 = 816 bits (M801 AKA)

= 652 bits (UMTS)

Increase in overhead = 25%

UMTS calculations are based on data from Al-Saraireh and Yousef. The main

difference is that the IMSI has been reduced to 60 bits as above and their

calculations include the same message twice between the serving network and

home network. The second message has been removed to enable a fairer

comparison. The above calculations are based on a single authentication run.

Message Number Link Composition

Total

Bits

M1 MS -> SN LAI + Service Request* 48

M2 SN -> MS Timestamp + SNID + RANDsn 144

M3 MS -> SN MACsn + code pos + auth type + IMSI 145

M4 SN -> HN cIMSI 60

M5 HN -> SN IMSI + nIMSI + HLRID 168

M6 SN -> HN M2 + M3 (minus auth type) 288

M7 HN -> SN XMAChn + RES + CK + IK + RANDhn 480

M8 SN -> MS XMAChn + RANDhn 192

M9 MS -> SN XRES 32

M10 SN -> MS TMSI + nIMSI 108

Total 1665

66

UMTS usually sends five AVs to the serving network and M801 AKA uses a local

authentication after the initial authentication. A fairer test would be to compare the

two over five authentications. M801 AKA performs one full authentication and

four local authentications

Number of messages sent between MS and SN

Full authentication = 561 bits

Local authentication = M1 + M2 + M3 + M8 (minus RANDhn) = 401 bits

Total = 561 + (4 * 401) = 2165 bits

UMTS = 5 * 396 = 1980 bits

Increase in overhead = 9%

Number of messages sent between SN and HN

Full authentication = 816 bits

Local authentication = 0 bits

Total = 816 + 0 = 816 bits

UMTS = 652 + (4 * 544) = 2828 bits

Reduction in overhead = 247%

67

Table 5.12: Comparison of the number of bits transmitted between M801

Protocol and UMTS per authentication run

5.2 Data Analysis

The aim of this section is to analyse the protocol based on the results in section 5.1

and the design described in section 4.2. The analysis is to be split into four distinct

areas (a) security analysis, (b) performance analysis, (c) implementation

considerations and (d) comparison with other protocols. Each will focus on a different

area of the protocol.

5.2.1 Security Analysis

Table 5.11 shows how it is anticipated that the UMTS AKA would have performed

had it undergone the series of tests illustrated in table 5.10.

Authentication Run

M801 Protocol UMTS

1 1377 3224

2 401 396

3 401 396

4 401 396

5 401 396

TOTAL 2981 4808

68

Table 5.13: Comparison of M801 protocol with UMTS AKA

In UMTS, the serving network has no active involvement in the authentication

process. As previously discussed this leads to the possibility of a redirection attack.

As table 5.2 shows the MACsn check is the main defence against a redirection

attack. MACsn or something along similar lines is used in a number of the

protocols described in the literature review. This also enables the home network to

verify the authenticity of the subscriber, which does not take place in UMTS

(Huang and Li, 2005). In test two the serving network identity (SNID) is changed

to that of another network just before MACsn gets calculated. In an actual attack of

this nature it is likely that a complete vector from another network would be used.

In the attack of test two it is the different SNID values that cause the test to fail. In

M801 protocol a new RANDsn and timestamp is generated for each authentication,

so these two parameters would also prevent a redirection attack. This would imply

that the protocol carries too much redundancy causing unnecessary bandwidth

consumption. The timestamp guarantees freshness of MACsn and also ensures that

the MAChn value is unique. Checking the timestamp can be used to detect

fraudulent activity. The SNID value is unique to the serving network. The other

Test Test Parameter M801 UMTS AKA

1 Normal Authentication Pass Pass

2 Redirection Attack Pass Fail

3 Replay Attack Pass Pass

4 Mutual Authentication Pass Pass

5 Anonymity Test Pass Fail

6 Change of Serving Network

Pass Fail

7 User Authentication Pass Pass

8 Timestamp Check Pass Not

Applicable

9 Wrong IMSI Pass Pass

10 PIN Check Pass Not

Applicable

11 Man-in-the-Middle Attack

Pass Fail

69

two values could have been generated by any network. SNID is the sole parameter

for detecting a change in network. Interestingly SNID is a key value used in LTE

networks for checking the genuineness of the serving network. Random numbers

(RANDsn) are used in all authentication protocols covered. RANDsn is the key to

preventing the replay attack in test three. If timestamp alone is used it could be

possible to pre-calculate MACsn for a particular timestamp and continually send

registration requests until that timestamp is produced. This would be quite a

challenge but not impossible. To predict the correct random number would be near

impossible. To predict the correct random number matched with correct timestamp

would be impossible.

Although UMTS networks provide mutual authentication, the method chosen is

open to criticism (Lei et al, 2007). In M801 protocol SQN and AMF have been

replaced by a timestamp and four digit authentication code. The timestamp and

code positions could belong to any subscriber so there is no need for an anonymity

key. In test four the authentication key has been changed for a different one to

simulate the process of a rogue network having the wrong authentication key. To

pass mutual authentication the rogue station would also need the secret key. This

mechanism provides enhanced security in the event the secret key is compromised.

How effective this would be is not known without further investigation. The

important point from the dissertation objectives is that the mobile has control of its

own challenge to the network.

The M801 protocol differs from other research in that it provides additional

protection against identity theft through two-factor authentication. The solution

chosen for the second factor is a chip and PIN solution as used in the banking

70

industry. This is the preferred choice of participants in the survey for this

dissertation. This is also the best solution for this environment as it is a numerical

value. The other two choices in the questionnaire would have presented more of a

challenge. The requirement for the PIN is that it should be based on a value that is

both fixed, secret and participates in the authentication process. There may be

concern that the secret key is not securely contained in the SIM, but the only other

alternative is the authentication key, which risks none of the PIN data being

selected in the authentication code. The current system only authorises the SIM

card not the user. The method selected verifies the user through their PIN code and

provides better non repudiation

5.2.2 Performance Analysis

Based on a single authentication run, the M801 protocol increases the bandwidth

consumption based on the number of bits transferred. In UMTS only the IMSI is

sent from MS to HN. All the authentication data is sent in the reverse direction. In

M801 protocol the majority of the data is sent from SN to HN.

Employing local authentication as in X-AKA (Huang and Li, 2006) in M801 can

be seen to have a big improvement mainly between SN and HN. This technique

could be used in UMTS, but managing SQN values could be a problem. The M801

protocol is more adaptable to this technique. Table 5.13 shows the difference

between the two protocols over five authentication runs in the same serving

network. The first run has the most overhead because this is when the data is

transferred from the home network. Subsequent runs have no communication with

the home network. These calculations assume that all five authentications are in the

71

same serving network and in the case of M801 protocol, the phone is not powered

off.

A problem that came to light during the wrong IMSI test is that the IMSI is only

sent after the SN authentication data has been received. If the IMSI is not valid a

number of resources have already been allocated. If the design is changed so the

IMSI is sent with the RRC request. This will enable the IMSI to be checked before

resources are allocated.

The M801 protocol performs better in a DoS attack based on IMSI. This is because

in UMTS all the resources are allocated based on nothing more than the IMSI. In

M801 protocol the user is checked earlier in the process by MACsn.

5.2.3 Implementation Considerations

Most if not all protocols do not consider how their designs would fit into a live

network. This is particularly true of interworking with GSM. Part of the research

questioned whether the protocol could be developed without altering the existing

architecture. This sections aims to analyse what changes need to be made to enable

implementation of the protocol.

No new elements are required, but a number of existing elements need modifying.

The main change would affect the Visitor Location Register (VLR). This would

need upgrading to implement the security functionality of the Authentication

Centre (AuC). These units are built on the same platform and use many of the

same components. Figure 4.2 shows the f5 function being used to generate

MACsn. It is not clear whether this could be modified for such a purpose without

72

further investigation. A second consideration may require a new algorithm based

on f1 to generate MACsn. This is so old and new type USIM cards can exist along

side each other.

To use the protocol would require the SIM card to be replaced. This would bring

the added disadvantage that the new SIM would only work in a compatible phone

preventing switching to an older phone. Finally an IMSI pool needs implementing

and managing in the SLR.

5.2.4 Comparison with Other Research

This dissertation is not the first to tackle the weaknesses in UMTS networks. Some

of these are discussed in the literature review. The aim of this section is to compare

M801 with other research and highlight what makes this protocol different and a

more suitable choice.

UMTS

AKA

AP-

AKA HH-AKA

VC

AKA X-AKA PFS

M801

AKA

Use of AVs Yes Yes Hash Chain Yes

Ticket Key

Ticket Key Ticket Key

Synchronisation (MS<->HN) Counter No No No Clock Clock Clock

Bandwidth Consumption Yes Yes No Yes No No No

Storage Overhead of SN Yes Yes No Yes No No No

Mutual Authentication (MS<->HN) MS<-HN Yes Yes Yes Yes Yes Yes

Mutual Authentication (MS<->SN) Yes Yes Yes Yes Yes Yes Yes

Compatible with GSM Yes Yes No No No No Yes

Two-Factor Authentication No No No No No No Yes

User Anonymity No No No No No Yes Yes

Prevents Redirection Attacks No Yes No Yes Yes Yes Yes

Table 5.14: Comparison of UMTS protocols

73

Table 5.15 shows a comparison of this protocol with those covered in the literature

review. Three of the protocols use a clock for synchronisation. As the clock used in

M801 is from a stable and accurate source it lacks the weakness discussed for PFS

and X-AKA. As with AP-AKA and VC-AKA, M801 protocol uses a RAND

generated from the serving network. These protocols use a second RAND

generated by the mobile. M801 protocol uses the IMSI and timestamp. This avoids

additional processing costs in the mobile.

A number of factors give M801 protocol additional security when compared to the

other six. In the others only the secret key is secret. In this protocol the

authorisation key and IMSI are used but never transmitted. This would prevent

cracking the security by comparing the inputs to the algorithms with the output as

happened in GSM. The weakness with keeping the IMSI secret is that GSM does

not employ anonymity protection.

74

Chapter 6 Conclusions

The aim of this chapter is to conclude the research with a discussion of the key

findings. This will be followed by recommendations for future research in the area of

cellular security. Finally the chapter will close with a project review

6.1 Summary of findings

In chapter one a series of primary and secondary research questions were posed. The

primary research question is

‘Can a more secure cellular access network be developed without altering the existing

network architecture and maintaining compatibility with GSM networks?’

This is a question consisting of three parts. The first part mentioned the words ‘more

secure’. In the context of this research more is used to mean that the protocol can

eliminate all threats that have previously been eliminated in GSM or UMTS networks.

In addition to this, weaknesses to threats highlighted in UMTS are also eliminated.

Based on the results in table 5.10 all threats tested were eliminated successfully.

Section 5.2 discussed the changes that are needed to implement this protocol in a live

network. Although changes need to be made in individual elements, this would not

require a change in overall architecture and the fact the elements are modular should

minimise the disruption.

One of the requirements that the 3GPP specified when developing UMTS security

was that it should be compatible with GSM. At first glance it would seem strange to

list this as a research aim; however as table 5.15 shows only AP-AKA of the research

75

projects meets this requirement. Section 2.5 details the parameters that enable

interworking between the two networks. These parameters have been left unaltered in

this protocol to achieve compatibility. In effect MACsn verifies the freshness of user

verification. XRES is primarily implemented for compatibility with GSM and it also

allows the serving network to verify the user. The answer to the primary research

question therefore is yes it is possible to produce a more secure cellular access

network within existing architecture whilst maintaining compatibility with GSM.

The remainder of this section will address the secondary questions as listed in section

1.4. Two-factor authentication would not offer anymore protection over the air

interface, but it would prevent SIM cloning using SIM readers and SIM swapping. On

this basis yes it would improve security but only of the SIM card. The second part of

the question in hindsight is a little more difficult to answer. In one respect yes it

should be implemented because it improves security. As the second factor involves

the user, the user experience needs to be taken into account when deciding whether to

implement two factor authentication. In the questionnaire 72% of participants wanted

automated locking of mobile phones, which would require a second factor (PIN) to

unlock. The answer would have to be needs further investigation through user trials,

which is beyond the scope of this dissertation.

The means of allowing the mobile to generate its own challenge was achieved using a

novel technique from the banking industry. To knowledge this is the first time this

technique has been used in this context and the first time the server has been

authenticated in this manner. This is true mutual authentication as both ends generate

a challenge and check the response. An anonymity key is not required as this is built

in and re-synchronisation is not necessary. The technique is adaptable, enabling local

76

authentication.

The final secondary question is achieved by using a pool of unused IMSIs in the SLR.

In this way an IMSI is used only once and each IMSI could be any subscriber. This

avoids tracking the user. The main disadvantage is that the IMSI pool becomes a

bottleneck depending how often a subscriber needs to perform an SLR enquiry. This

technique also increases the network load, but this affects many of the solutions that

provide anonymity. The performance aspects need further investigation.

6.2 Future Research

The testing undertaken in this research was aimed at known problems in cellular

networks. The protocol performed well in the tests but would benefit from a full

security analysis. This may be tested using one of the simulation packages identified

in section 3.2.

The one weakness this dissertation, which the dissertation did not touch upon is the

security of the handset. The network can request the IMEI of the phone at anytime but

this is separate to the authentication process. Involving the handset would involve

binding it to the SIM. This would prevent a user moving their SIMs between phones,

which is not desirable. Can a solution be found for this problem?

GSM SIMs are not allowed access to LTE networks, but UMTS SIMs are allowed

access. The question is as GSM SIMs are allowed access to UMTS networks, could a

GSM SIM gain access to a LTE network using a UMTS connection as a surrogate?

77

6.3 Project Review

Initially the dissertation intended focusing on security in the core network. Through

initial investigations into cellular security it was increasingly noticeable that the major

issues surrounded the radio access network and the research started to focus in this

area.

The research questions whilst developed to satisfy feasibility, scope, significance and

generalisation (Open University, 2007), enabled the dissertation to remain focused.

The secondary questions in particular enabled focussing on individual weaknesses,

whilst the primary question ensured that they all fitted together in a secure framework.

The question related to whether two-factor authentication should be implemented,

was in hindsight always a difficult question to answer within the scope of the

dissertation for the reasons discussed above.

Research methods were chosen based on what other researchers had used before and

what could aid data acquisition. Two methods considered and rejected were document

studies and observation studies. Document studies got rejected through not

contributing enough information to the research aims. Observation studies would have

generated ethical concerns as it would have had to focus on user security data. It also

felt that it did not contribute any data, which would aid the research objectives. Of the

methods selected Literature review and prototype design and test contributed the most

to the research. Knowledge of the operation of the cellular network through the case

study influenced in particular the anonymity protection. Without this the design would

have followed other research and developed a solution involving the HLR.

Of risks highlighted at the start of this dissertation, the two that caused the most

78

concern were time constraints and parallel studies. With unlimited time a solution

with one of the off the shelf packages could have been tried. This is a problem that

will affect all projects of this nature. A parallel study (Sharp et al, 2002) is where

someone conducts the same research at the same time. This was a problem throughout

as new solutions came to light all the time. To the knowledge the solution provided in

this dissertation has not been tried in other models except where indicated (X-AKA).

79

References

3GPP TR 33.801 V1.0.0. (2005). 3rd Generation Partnership Project; Technical

Specification Group Service and System Aspects. "Access Security Review (Release 7)"

3GPP TS 23.003. (2009). 3rd Generation Partnership Project; Technical

Specification Group Core Network and Terminals. "Numbering, addressing and identification (Release 8)".

3GPP TS 31.900 V8.0.0. (2009). 3rd Generation Partnership Project; Technical

Specification Group Core Network and Terminals; ?SIM/USIM Internal and External Interworking Aspects?.

3GPP TS 33.020 V8.0.0. (2009). 3rd Generation Partnership Project; Technical

Specification Group System Aspects; 3G Security. ?Security Related Network Functions?.

3GPP TS 33.102 V8.3.0. (2009). 3rd Generation Partnership Project; Technical

Specification Group Services and System Aspects; 3G Security;. "Security Architecture (Release 8)"

3GPP TS 33.401 V8.3.1 (2009). 3rd Generation Partnership Project; Technical

Specification Group and System Aspects; 3GPP System Architecture

Evolution(SAE). "Security Architecture (Release 8)"

3GPP TS 33.821 V2.0.0. (2009).3rd Generation Partnership Project; Technical

Specification Group and System Aspects; 3GPP System Architecture

Evolution(SAE)."Rationale and track of security decisions in Long Term Evolved (LTE) RAN / 3GPP System Architecture Evolution (SAE) (Release 8)".

Agilent. (2009). Security in the LTE-SAE Network (Tech.). Retrieved November 9, 2009, from Agilent website: http://www.home.agilent.com/upload/cmc_upload/All/Security_in_the_LTE-SAE_Network.PDF

Al Saraireh, J., & Yousef, S. (2006). A new authentication protocol for UMTS mobile networks. EURASIP Journal on Wireless Communications and Networking, 2006(2).

Arreymbi, J. (2006). Modelling to Enhance GSM Network Security. Retrieved August 7, 2009, from http://ww1.ucmss.com/books/LFS/CSREA2006/SAM5086.pdf

Aura, T. (2009). Network Security: GSM and 3G Security. Retrieved August 7, 2009, from http://research.microsoft.com/en-us/um/people/tuomaura/teaching/network-security-gsm-and-3g.pdf

80

Bais, A., Penzhorn, W. T., & Palensky, P. (2006). Evaluation of UMTS security architecture and services. In IEEE International Conference on Industrial

Informatics, 2006. Retrieved November 10, 2009, from http://publik.tuwien.ac.at/files/pub-et_11514.pdf

Balderas-Contreras, T. A., & Cumplido Parra, R. E. (2004). An Efficient Hardware

Implementation of the KASUMI Block Cipher for Third Generation Cellular

Networks.Puebla. Mexico: Mexican Council for Science and Technology.

Barbeau, M., & Robert, J. M. (2005). Perfect identity concealment in UMTS over radio access links. In Wireless And Mobile Computing, Networking And

Communications, 2005 (Vol. 2, pp. 72-77). IEEE.

Barbeau, M., Hall, J., & Kranakis, E. (2006). Detecting Impersonation Attacks in

Future Wireless and Mobile Networks. Retrieved August 7, 2009, from http://www.scs.carleton.ca/~kranakis/Papers/final-madnes.pdf

Barkan, E., Biham, E., & Keller, N. (2006). Instant Ciphertext-Only Cryptanalysis of

GSM Encrypted Communication. Haifa, Israel: Technion ? Israel Institute of Technology.

Bell, J. (2008). Doing Your Research Project 4/e. New York: Open University Press.

Biggam, J. (2008). Succeeding with Your Masters Dissertation: A Step-by-step Guide. New York: Open University Press.

Biham, E., Dunkelman, O., & Keller, N. (2005). A Related-Key Rectangle Attack on

the Full Kasumi. Haifa, Israel: Technion ? Israel Institute of Technology.

Bocan, V., & Cretu, V. (2006). Threats and Countermeasures in GSM Networks. Journal of Networks, vol. 1 iss 6.

Borghino, F. (2006). The secret life of the SIM card. Mobile Europe. Retrieved August 7, 2009, from http://www.mobileeurope.co.uk/features/112137/The_secret_life_of_the_SIM_card.html

Brookson, C. (2005). Smart card cloning is easy! (GSM SIMs) (Tech.). Retrieved August 7, 2009, from http://www.brookson.com/gsm/cardclone.pdf

Brumley, B. (2004). A3/A8 & COMP128. Lecture presented at T-79.514 Special Course on Cryptology in Helsinki University of Technology, Helsinki, Finland. Retrieved August 7, 2009, from http://www.tcs.hut.fi/Studies/T-79.514/slides/S5.Brumley-comp128.pdf

Camarillo, G., & García-Martín, M. A. (2008). The 3G IP Multimedia Subsystem

(IMS): Merging the Internet and the Cellular Worlds, Third Edition. Chichester, England: John Wiley and Sons Ltd.

Chandra, P. (2005). Bulletproof wireless security GSM, UMTS, 802.11 and ad hoc

security. Amsterdam: Newnes.

81

Clarke, Dr N. (2006). User Authentication for Mobile Devices. Retrieved August 7, 2009, from http://www.network-research-group.org/nica/Files/User%20Authentication%20for%20Mobile%20Devices.pdf

Cohen, T. (2009). Billions face identity fraud threat after hackers crack secret mobile phone codes. Daily Mail. Retrieved January 12, 2010, from http://www.dailymail.co.uk/sciencetech/article-1239298/Eavesdrop-identity-fraud-threat-billion-mobile-phone-users.html

Collins, L. (2009). Mighty Networks from Little Decisions Grow. Engineering and

Technology.

Design Council. (2009). Mobile phone security challenge (Rep.). Retrieved http://www.innovateuk.org/_assets/pdf/competition-documents/briefs/mobilephonesecuritychallenge_brief.pdf

Elatec. (2007). Introduction to SIM Cards. Retrieved August 7, 2009, from http://www.elatecworld.com/cards-services/downloads.html?no_cache=1&download_hash=01ec22ffcc89b0b1642a689f14153a13dbc40e3a.

Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling

Language. Addison Wesley.

Gendrullis, T., Novotny, M., & Rupp, A. (2008). A Real-World Attack Breaking A5/1

within Hours. Bochum, Germany.: Horst Görtz Institute for IT-Security, Ruhr-University.

Harn, L., & Hsin, W. (2003). On the Security of Wireless Network Access with Enhancements. In WiSE?03. San Diego, California: ACM.

He, S. (2007). SIM Card Security. Retrieved August 7, 2009, from http://www.crypto.ruhr-uni-bochum.de/imperia/md/content/seminare/itsss07/sim_card_security.pdf

Hook, D. (2005). Beginning Cryptography with Java. Wrox.

Howard, P. (2005). GSM and UMTS Security. In IC3 Network Security. London, England: Royal Holloway, University of London.

Hu, Y., Ma, D., & Li, X. (2009). An Improved Authentication Protocol with Less Delay for UMTS Mobile Networks. In 2009 International Conference on

Networking and Digital Society. Guizhou, China: IEEE.

Huang, C., & Li, J. (2005). Authentication and Key Agreement Protocol for UMTS with Low Bandwidth Consumption. In Proceedings of the 19th International

Conference on Advanced Information Networking and Applications

(AINA?05) (Vol. 1, pp. 392-397). Taipei, Taiwan: IEEE.

Jürjens, J. (2005). Secure Systems Development with UML. Berlin: Springer.

82

Kaaranen, H., Ahtiainen, A., Laitinen, L., Naghian, S., & Niemi, V. (2005). UMTS

Networks Architecture, Mobility and Services. New York: Wiley.

Kambourakis, G., Rouskas, A., & Gritzalis, S. (2004). Performance Evaluation of Public Key-Based Authentication in FutureMobile Communication Systems. EURASIP Journal onWireless Communications and Networking 2004, 1, 184-197.

Kemshall, A., & Underwood, P. (2007). Options for Two Factor Authentication (Rep.). Retrieved February 28, 2010, from http://www.securenvoy.com/WhitePapers/white_paper_two_factor_authentication.pdf

Khan, M., Ahmed, A. A., & Cheema, A. R. (2008). Vulnerabilities of UMTS Access Domain Security Architecture. In Ninth ACIS International Conference on

Software Engineering, Artificial Intelligence, Networking, and

Parallel/Distributed Computing (pp. 350-355). Phuket, Thailand: IEEE.

Kim, D., Cui, Y., Kim, S., & Oh, H. (2007). A Privacy Protecting UMTS AKA

Protocol Providing Perfect Forward Secrecy. Berlin Heidelberg: Springer-Verlag.

Koien, G. M. (2004). An Introduction to Access Security in UMTS. IEEE Wireless

Communications.

Kreher, R., Rüdebusch, T. (2005). UMTS signalling UMTS Interfaces, Protocols,

Message Flows and Procedures Analyzed and Explained. Chichester, West Sussex, England: John Wiley & Sons.

Lei, Y., Pierre, S., & Quintero, A. (2007). Enhancing UMTS Authentication and Key

Agreement with Vector Combination. Retrieved August 1, 2009, from http://www.ubicc.org/files/pdf/VC_AKA-last%20version_121_121.pdf

Lloyd, J. (2008). A Security Analysis of a Biometric Authentication System using

UMLsec and the Java Modeling Language (Master's thesis, Open University). Open University.

Lunde, L., & Wangensteen, A. (2006). Using SIM for Strong end-to-end Application

Authentication (Unpublished master's thesis). Norwegian University of Science and Technology. Retrieved July 30, 2009, from http://lundeweb.com/pdf/Master_Lunde_Wangensteen.pdf

Mayes, Dr K. (2006). Smart Card Platform Fingerprinting. In Securing Cyberspace

Workshop IV (SCWS4) Special purpose hardware for cryptography: Attacks

and Applications. London, England: Royal Holloway University of London.

83

Meyer, U. (2006). Secure Roaming and Handover Procedures in Wireless Access

Networks. Doctoral dissertation, University of Darmstadt.

Meyer, U. (2009). The Security Architecture of the Evolved Packet System [Scholarly project]. In IT Security at RWTH Aachen University. Retrieved August 9, 2009, from http://nds.hgi.rub.de/events/wireless_security_2009/talks/Meyer.pdf

Meyer, U., & Wetzel, S. (2004). A Man-in-the-Middle Attack on UMTS. In WiSe?04 (pp. 90-97). Philadelphia, Pennsylvania, USA: ACM.

Mobile Industry Review. (2009). GSM encryption can be cracked for $500. Mobile

Industry Review. Retrieved November 10, 2009, from http://www.mobileindustryreview.com/2009/08/gsm-encryption-can-be-cracked-for-500.html

Mochizuki, Y. (2006). Securing Against Fraud in Mobile Communications: Systems

Design and Development in 3G Mobile Networks (Master's thesis, Massachusetts Institute of Technology, 2006). Massachusetts, USA: Massachusetts Institute of Technology.

Niemi, V., & Nyberg, K. (2003). UMTS Security. New York: Wiley.

NSA. (2009). The Case for Elliptic Curve Cryptography (Tech.). Retrieved November 10, 2009, from http://www.nsa.gov/business/programs/elliptic_curve.shtml

Publictechnology. (2009). Ofcom pledges more consumer protection for mobile phone users & publishes 3G coverage maps. Publictechnology.net. Retrieved August 11, 2009, from http://www.publictechnology.net/modules.php?op=modload&name=News&file=article&sid=20657

Quirke, J. (2004). Security in the GSM System. AusMobile.

Rugg, G.& Petre, M. (2007). A Gentle Guide to Research Methods. New York: Open University Press.

Sapronov, K. (2006). Bluetooth, Bluetooth Security and New Year War-nibbling. Retrieved January 12, 2010.

Sattarzadeh, B., Asadpour, M., & Jalili, R. (2007). Improved User Identity Confidentiality for UMTS Mobile Networks. In Fourth European Conference

on Universal Multiservice Networks (ECUMN'07). Toulouse, France: IEEE Computer Society.

Schneier, B. (2005). The Failure of Two-Factor Authentication [Web log post]. Retrieved February 28, 2010, from http://www.schneier.com/blog/archives/2005/03/the_failure_of.html

84

Schneier, B. (2008). Schneier on Security [Web log post]. Retrieved August 11, 2009, from http://www.schneier.com/blog/archives/2008/02/cryptanalysis_o_1.html

Sharp, J. A., Peters, J., & Howard, K. (2002). Management of a student research

project. Aldershot, Hants, England: Gower.

Siddique, M. S., & Amir, M. (2006). GSM Security Issues and Challenges. In Seventh

ACIS International Conference on Software Engineering, Artificial

Intelligence, Networking, and Parallel/Distributed Computing, 2006. SNPD

2006. Retrieved November 10, 2009.

Strobel, D. (2007). IMSI Catcher. Bochum, Germany.: Ruhr-Universität.

Tanner, J. C. (2009). LTE: Losing its Voice. Telecom Asia, July 2009.

The Open University. (2007). M801 Research Project and Dissertation: Study Guide. Milton Keynes: The Open University.

United States-Computer Emergency and Readiness Team. (2008). MD5 vulnerable to

collision attacks (USA, Department of Homeland Security, US-CERT).

Weiss, J. (2004). Java Cryptography Extensions Practical Guide for Programmers

(The Practical Guides). Greensboro: Morgan Kaufmann.

Zhang, M., & Fang, Y. (2005). Security Analysis and Enhancements of 3GPP Authentication and Key Agreement Protocol. IEEE Transactions on Wireless

Communications, 4, 734-742.

85

Bibliography

3GPP TS 23.206 V7.5.0. (2007). 3rd Generation Partnership Project; Technical

Specification Group System Aspects;. ?Voice Call Continuity (VCC) between Circuit Switched (CS) and IP Multimedia Subsystem (IMS) (release 7)?.

3GPP TS 33.020 V8.0.0. (2009). 3rd Generation Partnership Project; Technical

Specification Group System Aspects; 3G Security. ?Security Related Network Functions?.

Bafoutsou, G., Antoniadis, N., Nikolouzou, E., & Panagopoulos, A. (2007). Regulatory Framework for Communications Security and Privacy in Greece. In ETSI Security Workshop: Future Security. Sophia-Antipolis, France: ETSI.

Bahrak, B. (2008). Cryptanalysis of GSM Encryption Algorithms Using ECC (Tech.). Retrieved August 11, 2009, from http://ee.sharif.edu/~farhat/sbisc/wgc/bahrak.pdf

Cadzow, S. W. (2005). Security mechanisms in converged networks. In Commercialising Technology and Innovation, 2005. London, England: Cadzow Commun. Consulting, Ltd.

Feng, Y. (2006). UMTS Network Level Security; Investigation on Security

Improvements (Unpublished master's thesis). Helsinki University of Technology. Retrieved August 7, 2009, from www.netlab.tkk.fi/opetus/s383310/05-06/...06/Feng_160206.ppt

Gódor, G., Váradi, B., & Imre, Dr S. (2006). Novel Authentication Algorithm of Future Networks. In Proceedings of the International Conference on

Networking, International Conference on Systems and International

Conference on Mobile Communications and Learning Technologies

(ICNICONSMCL?06). Mauritius: IEEE.

Grant, I. (2008). Data security fears increase among mobile phone users. Computer

Weekly. Retrieved November 10, 2009, from http://www.computerweekly.com/Articles/2008/02/11/229339/data-security-fears-increase-among-mobile-phone-users.htm

GSM Solutions Ltd. (2005). SIM Card Cloning Guide. Retrieved August 7, 2009, from http://www.gsmsolutionsltd.com/download/Sim_Clone_Guide_By_Gsm_Solutions_Ltd.pdf.

Guinier, D. (2005). From Eavesdropping to Security on the Cellular Telephone

System GSM. Strasbourg, France: OSIA.

Holtmanns, S., Niemi, V., Ginzboorg, P., Laitinen, P., & Asokan, N. (2008). Cellular

Authentication for Mobile and Internet Services. Chichester, West Sussex, U.K: Wiley.

86

Hunter, M. T., Clark, R. J., & Park, F. S. (2007). Security Issues with the IP

Multimedia Subsystem (IMS): A White Paper (Tech.). Georgia, USA: Georgia Institute of Technology.

I Gilliot Research. (2007). 3G Mobile Network Security. Retrieved August 7, 2009, from www.igr-inc.com/html/downloads/.../3G_MobileSecurity_Jan07.pdf.

Kasim, B., & Ertaul, L. (2005). GSM Security. Retrieved August 7, 2009, from http://www.mcs.csuhayward.edu/~lertaul/ICW3016.pdf.

Kawamoto, D. (2009). 3G and 4G market share set to rise. Retrieved August 7, 2009, from http://news.zdnet.co.uk/communications/0,1000000085,39630013,00.htm.

Køien, G. M. (2005). Privacy Enhanced Cellular Access Security. In WiSE?05. Cologne, Germany: ACM.

Lauter, K. (2004). The Advantages of Elliptic Curve Cryptography for Wireless Security. IEEE Wireless Communications, February 2004, 62-67.

Lin, Y., & Chen, Y. (2003). Reducing Authentication Signaling Traffic in Third-Generation Mobile Network. IEEE Transactions on Wireless

Communications, Vol 2Iss 3

Luna, L. (2009). Is voice over LTE a conundrum? Fierce Wireless. Retrieved August 11, 2009, from http://www.fiercewireless.com/story/voice-over-lte-conundrum/2009-07-06

Mayes, K., & Markantonakis, K. (2008). Smart Cards, Tokens, Security and

Applications. New York: Springer.

Mitchell, C. J. (2004). Security for Mobility. London: Institution of Electrical Engineers.

Nokia Siemens Networks. (2009). GSM has much to offer for many more years. Nokia Siemens Networks.

Nokia Siemens Networks. (2009b). Long Term Evolution (LTE) will meet the promise

of global mobile broadband (Tech.). Nokia Siemens Networks.

Näslund, M. (2007). Cryptography in Public Wireless Networks. Ericsson Research.

Ou, H., Hwang, M., & Jan, J. (2009). A cocktail protocol with the Authentication and Key Agreement on the UMTS. The Journal of Systems and Software, 83, 316-325.

Park, Y., & Park, T. (2008). A Survey of Security Threats on 4G Networks. In Workshop on Security and Privacy in 4G Networks. Korea: Samsung Advanced Institute of Technology.

87

Raja, S. (2006). Mobile Operators Alarmed at Vulnerability of IMS Networks. Mobile

Communications Europe, June 2006.

Russell, T. (2007). The IP Multimedia Subsystem (IMS) Session Control and Other

Network Operations. New York: McGraw-Hill Osborne Media.

Tanner, J. C. (2009). LTE: Losing its Voice. Telecom Asia, July 2009.

VoLGA - Requirements V1.3.1. (2009). Voice over LTE via Generic Access (Rep.). VoLGA.

Warren, P. (2008). Millions of mobiles are lost and discarded every year, yet their owners give little thought to the sensitive data they contain. The Guardian.

Wilson, R. (2009). First 4G LTE mobile phone call made in UK. Electronics Weekly. Retrieved from http://www.electronicsweekly.com/Articles/2009/12/14/47641/first-4g-lte-mobile-phone-call-made-in-uk.htm

Zarai, F., Boudriga, N., & Obaidat, M. (2006). Secured and Seamless Handoff in

Wireless Fourth Generation Systems (pp. 970-973). IEEE.

Zheng, Y., He, D., Tang, X., & Wang, H. (2005). AKA and Authorization Scheme For

4G Mobile Networks Based on Trusted Mobile Platform (pp. 976-980). IEEE.

88

Index

A

A5/1……………………… 2, 4, 11

Anonymity……………… 3, 5-6, 17, 24, 27, 31, 48, 58-59, 68, 73, 75-77

AP-AKA………………… 29-31, 73-74

ATMM………………….... 28

C

Case Study ………………...29, 32-33, 77

Comp-128………………….2, 4, 23-24

D

Denial of Service………….3, 27-28, 71

G

GUI……………………….50, 55

H

Handover………………….4, 18, 22

HH-AKA………………….30

I

Identity Concealment……..25, 27

IMAN………………………27

J

Java………………………..5, 7, 34, 49-51, 53-55

K

Kasumi…………………… 3, 16-17, 40

Key Hierarchy…………….19, 28

M

89

Man in the Middle Attack….2, 4, 25, 41, 63

Milenage…………………. 16-17, 40

Mutual Authentication…….3, 5, 22, 28-29, 44, 58, 69

P

PFS-AKA…………………31, 43, 48, 73

PIN………………………. 36, 39, 41-43, 62, 69-70, 75

Public Key Encryption ……31, 39

Q

Questionnaire…………….. 7, 35-38, 41, 43, 70, 75

R

Redirection Attack …….. 26, 29-30, 56, 59, 68

Replay Attack…..……….3, 28-29, 43-44, 57-58, 69

S

SQN…………………….3, 14, 16-17, 27-29, 44, 61, 69-70

T

Two-Factor Authentication …24, 35, 69, 75, 77

V

VC-AKA…………………. 29, 73

90

Abbreviations

2G Second Generation Network

3G Third Generation Network

3GPP Third Generation Partnership Project

4G Fourth Generation Network

A3 GSM Authentication Function

A5/0 No encryption applied

A5/1 Encryption Algorithm # 1

A5/2 Encryption Algorithm # 2

A5/3 Encryption Algorithm # 3

A8 GSM Cipher Key Generator

AK Anonymity Key

AKA Authentication and Key Agreement

AMF Authentication Management Function

AP-AKA Adaptive Protocol AKA

ATMM Anonymous Ticket Manager Module

AuC Authentication Centre

91

AUTN Authentication Token

AV Authentication Vector

BSC Base Station Controller

BTS Base Transceiver Station

CK UMTS Cipher Key

COMP-128 Compression Algorithm used in GSM

CS Circuit Switched

EDGE Enhanced Data Rates for GSM Evolution

f1-f5 UMTS Authentication and Key Generating Functions

f8 UMTS Encryption Algorithm

f9 Integrity Algorithm

GERAN GSM/EDGE Radio Access Network

GGSN Gateway GPRS Support Node

GMSC Gateway MSC

GPRS General Packet Radio System

GSM Global System for Mobile Communication

GUI Graphical User Interface

92

GUTI Globally Unique Temporary UE Identity

HH-AKA Harn and Hsin AKA

HN Home Network

HLR Home Location Register

HMAC Hash MAC

HSS Home Subscriber Server

IK UMTS Integrity Key

IMEI International Mobile Equipment Identity

IMAN International Mobile Anonymous Number

IMS IP Multimedia System

IMSI International Mobile Subscriber Identity

IP Internet Protocol

Kc GSM Cipher Key

Ki Secret Key used for Authentication

KSI Key Set Identifier

LTE Long Term Evolution

MAC Message Authentication Code

93

MCC Mobile Country Code

MD5 Message Digest number 5

MITM Man in the Middle Attack

MME Mobile Management Entity

MNC Mobile Network Code

MS Mobile Station

MSC Mobile Switching Centre

MSIN Mobile Subscriber Identity Number

Node B UMTS Base Station

NSA National Security Agency

PIN Personal Identity Number

PKC Public Key Cryptography

PS Packet Switched

QoS Quality of Service

RAN Radio Access Network

RAND Random Number Generated for Authentication

RES Response sent from USIM

94

RNC Radio Network Controller

RRC Radio Resource Control

RSA Encryption Algorithm

SAE System Architecture Evolution

SGSN Serving GPRS Support Node

SLR Service Location Register

SN Serving Network

SNID Serving Network ID

SQN Sequence Number

SRES Signed Response

TACS Total Access Communication System

TK Temporary Key

TMSI Temporary Mobile Subscriber Identity

TS Technical Specification

UE User Equipment

UICC Universal Integrated Circuit Card

UML Unified Modelling Language

95

UMLsec Unified Modelling Language Security

UMTS Universal Mobile Telecommunication System

USIM Universal Subscriber Identity Module

UTRAN UMTS Terrestrial Radio Access Network

VC-AKA Vector Combination AKA

VLR Visitor Location Register

XOR Exclusive or operation

XRES Expected Response sent from the network

96

Appendix A: Extended Abstract

Securing Cellular Access Networks against Fraud

Chris Lukeman

Extended Abstract of Open University MSc Dissertation Submitted 4 March 2010

Introduction

It is 25 years since the first cellular phone network was launched in the UK (Collins,

2009). These networks had next to no security. Identity theft through cloning and

listening into calls by amateur radio enthusiasts was common place. Security

increased significantly in GSM with the introduction of SIM cards and encryption.

UMTS (3G) networks built upon and improved GSM security, but new threats have

been identified in UMTS (Bocan and Cretu, 2006) networks and many of these are to

be carried over to fourth generation networks. A number of research projects have

been undertaken to provide solutions to these weaknesses, but these have introduced

weaknesses themselves or are non compatible with live networks such as GSM.

Up to now cellular phone networks have not been targeted in the same manner as

home computers. The networks 25 years ago only provide voice calls. Since then

phones, such as the new generation of smart phones are like mini computers. As the

mobile phone market has reached saturation in Western Europe, operators are looking

at security critical applications such as commerce, banking and electronic payment

systems. This will make cellular phone networks more attractive to criminals. This is

the motivation behind this research, to find a solution to the weaknesses before

criminals are able to target the network. The research question to be addressed is thus

“Can a more secure UMTS networked be developed, which addresses known

weaknesses and maintains compatibility with GSM?”

Method

In addition to the literature review, a number of other research methods were used to

aid the development of a more secure framework for cellular access networks. Part of

the aim is to improve the security of the handset through two-factor authentication,

which involves the user becoming involved in the authentication process. To aid the

choice of a second factor and to gain a greater appreciation of user experiences of

cellular networks, a survey in to user attitudes to mobile security was carried out.

To verify whether the research question was successfully answered, a prototype was

built using Java’s client/server architecture. To verify the protocol is able to detect a

number of threats a GUI interface was provided from where a series of tests could be

carried out (see figure 1).

Figure 1: GUI Interface for Authentication Simulator

Results

The results of the questionnaire indicated that a majority (53%) of participants wanted

a chip and PIN based method as used in the banking industry as the second factor in

authentication. The questionnaire also illustrated that 9/10 participants showed a

negative response to using their mobiles for commerce or banking.

Eleven tests were run on the protocol and the results are displayed in table 1.

Test Test Parameter UMTS AKA Prototype Rejection Stage

1 Normal Authentication Pass Pass Not Applicable

2 Redirection Attack Fail Pass MACsn

3 Replay Attack Pass Pass MACsn

4 Mutual Authentication Pass Pass MAChn

5 Anonymity Test Fail Pass Not Applicable

6 Change of Serving Network

Fail Pass Not Applicable

7 User Authentication Pass Pass XRES

8 Timestamp Check Not

Applicable Pass

Time Check/ MACsn

9 Wrong IMSI Pass Pass IMSI Check

10 PIN Check Not

Applicable Pass MACsn

11 Man-in-the-Middle Attack

Fail Pass MACsn

Table 1: Comparison of Security Checks between the Prototype and UMTS

Where a fail is indicated in the UMTS AKA column, this highlights one of the

weaknesses that initiated this research. The rejection stage column indicates the stage

in the protocol where the threat was eliminated.

Although not set as a project aim, performance and security are conflicting demands

on the network. Increasing the security of the network inevitably affects performance.

A technique to improve performance was used based on previous research (Huang

and Li, 2005). After the first authentication, the next four were delegated to the

element serving the user. This cut out a significant part of network traffic (table 2).

Table 2: Comparison of the number of bits transmitted between M801

Protocol and UMTS per authentication run

Analysis

The extra checks introduced into the protocol can be seen to have improved security

(table 1). The most effective of these is a message authentication code called MACsn.

This was introduced early into the process and prevents a number of frauds that were

previously possible.

In the section on results it was mentioned that security and performance are usually

conflicting requirements. Table 2 shows that by allowing the network serving the user

to perform authentication, a significant performance gain can be obtained. This is due

to less authentication data being needed from the home network. Obtaining data from

the home network is carried out in the first authentication in both cases. Subsequent

runs are more or less even. The first run in the M801 protocol is to ensure that the

serving network is genuine before delegating authentication to it.

Authentication Run

M801 Protocol UMTS

1 1377 3224

2 401 396

3 401 396

4 401 396

5 401 396

TOTAL 2981 4808

Discussion

This research has shown that it is possible to improve security without significantly

altering the architecture and also maintaining compatibility with GSM. The research

has shown this can be achieved without significantly affecting performance when

compared to UMTS.

This has been achieved by using a combination of existing research (Huang and Li,

2005) and new techniques. New techniques include the introduction of two-factor

authentication based on chip and PIN. This is introduced as an anti SIM cloning

measure. The other new technique is based on online banking. In online banking, the

user is asked for selected digits from their security number. The same technique is

used here to verify the home network as being genuine

References

Bocan, V., & Cretu, V. (2006). Threats and Countermeasures in GSM Networks. Journal of Networks, vol. 1 iss 6.

Collins, L. (2009). Mighty Networks from Little Decisions Grow. Engineering and

Technology.

Huang, C., & Li, J. (2005). Authentication and Key Agreement Protocol for UMTS with Low Bandwidth Consumption. In Proceedings of the 19th International

Conference on Advanced Information Networking and Applications

(AINA?05) (Vol. 1, pp. 392-397). Taipei, Taiwan: IEEE.

97

Appendix B: Questionnaire

98

Hello

Thank you for agreeing to participate in this questionnaire on user attitudes to mobile

security. As part of my Master of Science degree in Computing for Commerce and

Industry, I am undertaking a research project. This project aims to investigate radio

access security in cellular networks. The mobile phone forms part of the radio access

network and is consider its weakest part. It is estimated (BBC, 2005) that 10,000 mobiles

are lost or stolen every month in the UK. In additional research, it is found that 55,843

mobiles were lost in London taxis over a six month period (The Register, 2008). This

emphasises the need to improve the security of the mobile handset in the event it ends

up in the wrong hands.

In order to improve mobile phone security, it is necessary to gauge user opinions. This

questionnaire is split in to three parts. The first part (Q1-Q5) is to gather personal details.

This is so that any differences between genders / age groups can be observed. All

information submitted will be strictly confidential and will not be used outside this

dissertation. In the dissertation itself only a summary of the results will be produced. No

user will be individually identified. The second part (Q6-Q14) looks at your experiences

of mobile security. Part three (Q15-Q20) mainly looks at future features/applications of

mobile phones and what the user would like to see implemented.

Thank you for your help

Chris Lukeman

1. http://news.bbc.co.uk/1/hi/technology/4287357.stm

2. http://www.theregister.co.uk/2008/09/17/black_cab_lost_mobile_survey/

99

3) Please select your age range:

24 or under

25-36

37-48

49-64

65 or over

4) Please provide details of the type of mobile you have

Manufacturer (i.e. Nokia)

Model (i.e. 8680)

5) How would you describe yourself ?

Technical

Non-Technical

6) Which of the following sums up your attitude to mobile security?

I am very concerned about it

I have some concerns about it

I have not really thought about it much

I am not overly worried

I am not worried at all

1) Please enter your name

2) Please enter your gender :

Male

Female

100

7) Have you or anyone you know had a problem related to mobile phone security (i.e. fraudulent transactions)? if No please go to Q9

Yes

No

8) Please describe in more detail what the problem was.

9) Have you ever lost your mobile phone? If No please go to Q11

Yes

No

10) How long roughly was it before you discovered your mobile was missing?

11) Have you ever used your mobile phone abroad?

Yes

No

12) Do you use bluetooth on your phone? If No please go to Q14

Yes

No

101

13) Do you leave bluetooth connected all the time?

Yes

No

14) The SIM card in mobile phones has a locking facility based on a PIN number. Do you ever use it?

Yes

No

15) What is the maximum delay you would accept when connecting to the network?

0-5 seconds

6-10 seconds

10-15 seconds

16-20 seconds

21-30 seconds

30-40 seconds

Other (Please Specify):

16) To achieve strong authentication it is necessary to use two methods (2 factor) of authentication. In the case of mobile phones this would be a SIM card plus one other. Please choose which would be your second preferred method of authentication

Biometric (fingerprint, iris scan etc)

PIN (as in chip and pin in banking)

Password

Other (Please Specify):

102

17) Computers have a facility that enables them to be automatically locked after a period of inactivity. This prevents unauthorised users from accessing your computer. Would you like to see this feature implemented in mobile phones?

Yes

No

18) If a security loop hole was breached on a mobile network, which was quickly rectified. How would this affect the usage of your mobile phone?

Stop using your mobile

Limit the use of your mobile to essential use only

Limit the use of certain applications

Continue to use as normal

19) Which of the following applications would you consider using your mobile phone for ?

1 2 3 4 5

Definitely

Not Unlikely Not sure Probably Definitely

m-commerce(shopping)

mobile banking

voting (Elections)

Telemedicine(Access medical records, send test results etc)

103

Appendix C: Questionnaire Results

104

The Survey of Attitudes to Mobile Security was carried out between 6th July 2009

and 11th August 2009. Questions relating to gender, age and technical knowledge

were asked primarily to determine if any patterns developed between the attitudes of

different groups. In total 64 people responded to the survey. The results are

summarised as follows

Question 2: What is your gender?

45%

55%

Male

Female

Question 3: What Age range are you in?

2%

9%

22%

13%

0%0%

13%

20%

14%

8%

0%

5%

10%

15%

20%

25%

24 and

Under

25 - 36 37 - 48 49 - 64 65 or Over

Male

Female

105

Question 4: What type of mobile do you have?

Varied list of Mobiles

Question 5: Would you describe yourself as Technical or non Technical?

86%

20%

50%

14%

80%

50%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Male Female Total

Technical

Non-Technical

Question 6: What is your attitude to mobile security?

14%

34%

24%21%

7%3%

29%

43%

20%

6%

0%5%

10%15%20%25%30%35%40%45%50%

I am very

concerned

about it

I have

some

concerns

about it

I have not

really

thought

about it

much

I'm not

overly

worried

I'm not

worried at

all

Male

Female

106

Question 7: Have you or anyone you know experienced mobile phone fraud?

97%

3%

Yes

No

Question 8: Please describe in more detail what the problem was

Someone had ordered a phone using their partner’s details

Incorrectly billed for calls to a European location.

Question 9: Have you ever lost or had your mobile phone stolen?

11%

89%

Yes

No

107

Question 10: How long roughly was it before you discovered your mobile was

missing?

Seven participants reported losing or having their phone stolen. The time to discover

this ranged from a couple of minutes to one day

Question 11: Have you ever used your mobile phone abroad?

87%

13%

Yes

No

108

Question 12: Do you use Bluetooth on your phone?

72%

51%

61%

28%

49%

39%

0%

10%

20%

30%

40%

50%

60%

70%

80%

Male Female Total

Yes

No

Question 13: Do you leave Bluetooth connected all the time?

26%

74%

Yes

No

109

Question 14: The SIM card in mobile phones has a locking facility based on a

PIN number. Do you ever use it?

34%

66%

Yes

No

Question 15: What is the maximum delay you would accept when connecting to

the network?

24%

21%

24%

7%

14%

0%

10%

14%

31%

20%

3%

14%

17%

0%0%

5%

10%

15%

20%

25%

30%

35%

0-5

secs

6-10

secs

10-15

secs

16-20

secs

21-30

secs

30-40

secs

Other

Male

Female

110

Question 16: To achieve strong authentication it is necessary to use two methods

(two factors) of authentication. Please choose which would be your second

preferred method of authentication

22%

53%

25%

Biometrics

Chip and PIN

Password

Question 17: Computers have a facility that enables them to be automatically

locked after a period of inactivity. This prevents unauthorised users from

accessing your computer. Would you like to see this feature implemented in

mobile phones?

72%

28%

Yes

No

111

Question 18: If a situation occurred that resulted in a security loophole being

found where someone could impersonate you on the network, but this loophole

was quickly closed. How would this affect the future usage of your mobile?

6%

22%

22%

50%

Stop using your mobile

Limit the use of your

mobile to essential use

only

Limit the use of certain

applications

Continue to use as

normal

Question 19: Would you consider using your mobile phone for mobile

commerce/mobile banking/ mobile voting/ Telemedicine?

55%

66%

48%52%

14%

0%

7%

14%

31%34%

45%

34%

0%

10%

20%

30%

40%

50%

60%

70%

Mobile

Commerce

Mobile

Banking

Mobile Voting Telemedicine

Negative

Neutral

Positive

(a) Male Response

112

77% 78%

48%

64%

8%3%

14% 14%16%19%

38%

22%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

Mobile

Commerce

Mobile

Banking

Mobile Voting Telemedicine

Negative

Neutral

Positive

(b) Total Response

94%89%

49%

74%

3% 6%

20%14%

3% 6%

31%

11%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Mobile

Commerce

Mobile

Banking

Mobile Voting Telemedicine

Negative

Neutral

Positive

(c) Female Response

113

Appendix D: Test Results

114

=====================================

Test 1 : Normal Authentication

=====================================

Report Number : 5001

IMSI : 234334286219354

TMSI : 802a196b

Invoking Event : Full Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234334286219354

RANDsn : bbc754222223cec05f55fd50ce42e424

RANDhn : 6f8991b1a972877062a9e56c66a8ddc7

Cipher Key : c343a03ce8cac3628d0ec995a063eb0

Integrity Key : 85a966c622916a9b352cec96d81cd73

XRES : cd98aeb5219383cb

XMACsn : 9e06bef80bbc3f89

XMACh : 46d7c4a032a275cd

Authentication Status : Successful Authentication

Report Number : 5002

IMSI : 234334286219354

TMSI : 9c334c0d

Invoking Event : Local Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 802a196b

RANDsn : 5aa024479fad47a7e29b659511622e89

RANDhn : 5aa024479fad47a7e29b659511622e89

Cipher Key : 1e1a5fe50ae3d73b1c2b6313a6a38fd

115

Integrity Key : aa54f54b98b1ed29643ae570847b408

XRES : 966583f8c724e6d0

XMACsn : a26e26f188d229a1

XMACh : 873c0c4f88855314

Authentication Status : Successful Authentication

Report Number : 5003

IMSI : 234334286219354

TMSI : d80566ed

Invoking Event : Local Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 9c334c0d

RANDsn : d9d449de53721cd0bca3d90d422c6a71

RANDhn : d9d449de53721cd0bca3d90d422c6a71

Cipher Key : c800458bc6b4cc0f92e3e3c23bf58ff

Integrity Key : e16a893882ff4ea45d56ee9c23025f3

XRES : aec76c90166d9887

XMACsn : b166f863a88cd318

XMACh : f3da39d2fc2ebb47

Authentication Status : Successful Authentication

Report Number : 5004

IMSI : 234334286219354

TMSI : ae632318

Invoking Event : Local Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : d80566ed

116

RANDsn : bafabca2f3730e7fd0d0d77fa5868ffe

RANDhn : bafabca2f3730e7fd0d0d77fa5868ffe

Cipher Key : d7467ce65fde23b6331d1297ce68937

Integrity Key : ded0c2c4419edb9970d535e7e81831e

XRES : 4b1bbe56b6c4cefa

XMACsn : d9db272051c9e29f

XMACh : 6265a1c3f7be7b2d

Authentication Status : Successful Authentication

Report Number : 5005

IMSI : 234334286219354

TMSI : a5cfc7ea

Invoking Event : Local Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : ae632318

RANDsn : f9dd695a3596456a049435ba9d003411

RANDhn : f9dd695a3596456a049435ba9d003411

Cipher Key : e11b787b90fcafee42890248b1360aa

Integrity Key : 9c179bb6c8c91eb9dcb1355dbf413e2

XRES : 4f70cf708c0f5c5a

XMACsn : 1d1409f23f6b97d0

XMACh : a8d03587dfbfe64d

Authentication Status : Successful Authentication

Report Number : 5006

IMSI : 234334286219354

TMSI : de098a65

Invoking Event : Full Authentication

117

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : a5cfc7ea

RANDsn : a6d401addac52fdb1186e04202280407

RANDhn : 92fa26c08c197a0bda7f7340e62029ab

Cipher Key : ca9db42cca43912149c99e2bb702b3e

Integrity Key : 8477ab152a7ff8dc406af8e4262a8d4

XRES : d026061b3dd9ee9

XMACsn : 6c2a2475da485629

XMACh : ff90264fb50ab398

Authentication Status : Successful Authentication

Report Number : 5007

IMSI : 234334286219354

TMSI : 57262e4b

Invoking Event : Local Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : de098a65

RANDsn : 07d0de010a7f9a743cf69c9a0660c846

RANDhn : 07d0de010a7f9a743cf69c9a0660c846

Cipher Key : 856191325d54a5bc76df9a12932d9cb

Integrity Key : ca8895d74d6eee9c2918f681695bfb6

XRES : 2789889c6943f42a

XMACsn : 3248a79802da91c2

XMACh : eb6a29b32317ec3d

Authentication Status : Successful Authentication

118

=================================

Test 2: Redirection Attack

=================================

Report Number: 5001

IMSI: 234334286219354

TMSI: null

Invoking Event: null

Serving Network ID: 4522198427

MSISDN: 447207638702

Current IMSI: 234334286219354

RANDsn: 77f1351b0b437af3cbad16e96abbdac5

RANDhn:

Cipher Key: null

Integrity Key: null

XRES: null

XMACsn: a2823164dbabdf64

XMACh: null

Authentication Status: Server Network Test Failed (XMACsn)

119

=================================

Test 3: Replay Attack

=================================

Report Number: 5001

IMSI: 234334286219354

TMSI : af4f637c

Invoking Event : Full Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234334286219354

RANDsn : c6bad2e0871113543246a96000c01a4c

RANDhn : af34fdfaee60ccdeca88dd147c923a3f

Cipher Key : 9f95bdccb7126d5ee9d7b6bd10d7edd

Integrity Key : 61673c82f9da975153c9933f969a5dd

XRES : ae5bc8488dd0eb90

XMACsn : dd2f5a94876f0814

XMACh : 44849fc415146da7

Authentication Status : Successful Authentication

Report Number: 5002

IMSI : 234334286219354

TMSI : 4f3600cd

Invoking Event : Local Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : af4f637c

RANDsn : 2c319c54cef40f4f8ceaf4e3b044cf90

RANDhn : 2c319c54cef40f4f8ceaf4e3b044cf90

Cipher Key : 043974271a161ad9888c99d2ed07423

120

Integrity Key : 00304b70ddc198fa60896cfc80239ba

XRES : ceb5f117a6bc66f5

XMACsn : facce47c497b34cf

XMACh : 5ffddaa8c5c7764e

Authentication Status : Successful Authentication

Report Number : 5003

IMSI : 234334286219354

TMSI : 4f3600cd

Invoking Event : Local Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 4f3600cd

RANDsn : 2087175901acd349f50a17ff0b28df7e

RANDhn : 2c319c54cef40f4f8ceaf4e3b044cf90

Cipher Key: 043974271a161ad9888c99d2ed07423

Integrity Key: 00304b70ddc198fa60896cfc80239ba

XRES: ceb5f117a6bc66f5

XMACsn: 1f5bc1506e5100be

XMACh: 5ffddaa8c5c7764e

Authentication Status : Server Network Test Failed (XMACsn)

Report Number : 5004

IMSI : 234334286219354

TMSI : 1508ac48

Invoking Event : Local Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 4f3600cd

121

RANDsn : 8bf01452e5189bc667dcb4e522b99d01

RANDhn : 8bf01452e5189bc667dcb4e522b99d01

Cipher Key : 360c75dc7b1f84cef1eb92a1b0dcd79

Integrity Key : d9794092c4e142eb42340f40ea0185d

XRES : 7e193e9c7e388d84

XMACsn : 17251891c1c3a5e4

XMACh : 9df83cb9eacdd36c

Authentication Status : Successful Authentication

Report Number : 5005

IMSI : 234334286219354

TMSI : 90c7c7a0

Invoking Event : Local Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 1508ac48

RANDsn : 7f45818d95fd5553a0fc6f6cb80ee799

RANDhn : 7f45818d95fd5553a0fc6f6cb80ee799

Cipher Key : c3b13933a89fe8576fd44703e4cf1a5

Integrity Key : b6ba2a155a2dbd0f1bba22713305b42

XRES : a889501682b39ac9

XMACsn : 4bd2b83623376e50

XMACh : 3875d564fd20c21c

Authentication Status : Successful Authentication

Report Number : 5006

IMSI : 234334286219354

TMSI : 5e604e01

Invoking Event : Local Authentication

122

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 90c7c7a0

RANDsn : 8580f97ed9706821d699b030f7344829

RANDhn : 8580f97ed9706821d699b030f7344829

Cipher Key : 25fbeb192f2a472f6a15ae0b7c58746

Integrity Key : 74c819bc60bed75ec36e04110c8f3ce

XRES : ec35b82076dfbc4e

XMACsn : e2edf67625f80486

XMACh : 84bdce7cf31dae3

Authentication Status : Successful Authentication

123

=================================

Test 4: Mutual Authentication

=================================

Report Number: 5001

IMSI: 234334286219354

TMSI: null

Invoking Event: Full Authentication

Serving Network ID: 2343357087

MSISDN: 447207638702

Current IMSI: 234334286219354

RANDsn: be45f9e6b766c941e529b9af61b10adc

RANDhn: 19d4e294fb45f838f16a4eb35fe94610

Cipher Key: null

Integrity Key: null

XRES: null

XMACsn: f8f836fde726ec90

XMACh: 49e3437cb16b1c5d

Authentication Status: Server Network Test Failed (XMAChn)

124

=================================

Test 5 : Anonymity Test

=================================

Report Number : 5001

IMSI : 234334286219354

TMSI : c78efc4b

Invoking Event : Full Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234334286219354

RANDsn : 488ed17a61a45f082d1ba22681710787

RANDhn : 6cfc34a5907ee271596f7aa4999bcbf9

Cipher Key : d1a0b69abac689f0888e329f7a44feb

Integrity Key : 2ebedb916f780f1857deab1006e9341

XRES : a6ca6a836357f71e

XMACsn : 5c717e5fca81ea72

XMACh : 907b4428d6a4d516

Authentication Status : Successful Authentication

Report Number : 5002

IMSI : 234334286219354

TMSI : fa0efa7a

Invoking Event : Full Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234332514657521

RANDsn : 4d697080b1b7bc76b1fe7f7a2b7d8b81

RANDhn : c43e665bbf104b46272b3e372a0120bf

Cipher Key : 3f04a568cf2ccd45b7fbb8b73dde191

125

Integrity Key : 0b6faa92460a0f6b1da926772a11fe1

XRES : bbe6a6577c02d2a6

XMACsn : e26ace27e9f5335b

XMACh : 7a4e0604e7df4153

Authentication Status : Successful Authentication

Report Number : 5003

IMSI : 234334286219354

TMSI : d0a00554

Invoking Event : Full Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234332845621589

RANDsn : f335034e6e370a6d0c80b16601ae94ca

RANDhn : d03d67f8f5f3ac49f85706e5f8063bc2

Cipher Key : 48626654a5868014bbebe2e012f79c5

Integrity Key : 76e566f9b8d40a203e712eca3889bac

XRES : d9e6c1a5d0a871c3

XMACsn : 63810737f2548af8

XMACh : 9b7f34974ceea124

Authentication Status : Successful Authentication

Report Number : 5004

IMSI : 234334286219354

TMSI : 3d6736bc

Invoking Event : Full Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234337465235874

126

RANDsn : 45d992918d00e458fda5aabf786795fa

RANDhn : 9fd4c1f1f7c73757246e62aea9ea0c3b

Cipher Key : 0c5d396423fe03c34f78a9e45fc4413

Integrity Key : 09a8988524add86e962a23cd76197e4

XRES : 2f1cb1d13e9959b9

XMACsn : 637c0a0a6292b131

XMACh : 12ea9a9c9e472209

Authentication Status : Successful Authentication

Report Number : 5005

IMSI : 234334286219354

TMSI : 3cdcd989

Invoking Event : Full Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234331285496345

RANDsn : dc968d0fd4d2d94bf039bc65a676de16

RANDhn : 2087f471de6f3c7dd63cbf29de246238

Cipher Key : 770bc9fc6dbb27073836e6aadb0e1b8

Integrity Key : 9e221e790fcc2074bbeda784ee39889

XRES : b6f65dea60a23b0c

XMACsn : adc5793254a7b436

XMACh : 469820e67fe0ee12

Authentication Status : Successful Authentication

Report Number : 5006

IMSI : 234334286219354

TMSI : 6309bc06

Invoking Event : Full Authentication

127

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234335625813467

RANDsn : 1f490a0b44c70a889e2150e116b3c7a5

RANDhn : 38f08699281e814674b1bfa7d4e293b9

Cipher Key : a4ce1bced4e3b9c71af402168a29fbc

Integrity Key : cdda75fa219382a443a1a6558611d95

XRES : cebfbd0c14da70f3

XMACsn : d7d36cc57456f53e

XMACh : f5e9f4984404415d

Authentication Status : Successful Authentication

Report Number : 5007

IMSI : 234334286219354

TMSI : 6633cac5

Invoking Event : Full Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234333215973121

RANDsn : 6bbd21cb360a6c81f31bbffe460de48e

RANDhn : b5f4c47d1476a838b035500a208e1ba1

Cipher Key : 5bab2a73e567fde9d7e739cae7c95a7

Integrity Key : 5c901b43deb916c8d34e9777f4dfbe1

XRES : 1843276e68144564

XMACsn : 1960a1a7d7d9bfbc

XMACh : fac9c69489247a17

Authentication Status : Successful Authentication

128

=================================

Test 6: Change Serving Network

=================================

Report Number : 5001

IMSI : 234334286219354

TMSI : e510804a

Invoking Event : Full Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234334286219354

RANDsn : 78d832a239d693f83702aefbef11a1f3

RANDhn : c43b0833ed32351bc2e1085db8a2b6fc

Cipher Key : daee59099b77cb28a4be2405ee58e27

Integrity Key : 636825e1d03f695b75b86a67cd0d401

XRES : ddd04d8552b196cb

XMACsn : 3e54c346c6ae8df6

XMACh : 39e9a9b0e79d07e9

Authentication Status : Successful Authentication

Report Number : 5002

IMSI : 234334286219354

TMSI : 3b0b0ceb

Invoking Event : Local Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : e510804a

RANDsn : d546ea7f55d11ce015ed9a3d2e9b2c0d

RANDhn : d546ea7f55d11ce015ed9a3d2e9b2c0d

Cipher Key : 51dea52ffe6ec48a6ee82448d918b8e

129

Integrity Key : aaf4c9b84856099d29280a9d02948e9

XRES : 91da48852f7f590a

XMACsn : 9d962c2d94d07fd8

XMACh : 6d25ac5aeb0aeda1

Authentication Status : Successful Authentication

Report Number : 5003

IMSI : 234334286219354

TMSI : 544008d6

Invoking Event : Full Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 3b0b0ceb

RANDsn : a4b203c7e46a66fb67f1272df310759c

RANDhn : 317a445c103dbd0279e29127a3d880ab

Cipher Key : b32cd6b1f61b9250c01846b7908f9d2

Integrity Key : 79c22c5ca822d4bbdbac0b13b7a3c7d

XRES : f307012d9b2c25e

XMACsn : ee11b170395c8d41

XMACh : 350355b2d2db9560

Authentication Status : Successful Authentication

Report Number : 5004

IMSI : 234334286219354

TMSI : 1d768ef6

Invoking Event : Local Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 544008d6

130

RANDsn : af893c5d7cb2188d12f2d887098b2b30

RANDhn : af893c5d7cb2188d12f2d887098b2b30

Cipher Key : 996b7213428bf5fd020d85168910009

Integrity Key : 7259c73386d8a4fd9a7329a011ad28b

XRES : ae013b3cc3c542e0

XMACsn : 60c32f96e5584fe3

XMACh : f30666402cba5cb7

Authentication Status : Successful Authentication

Report Number : 5005

IMSI : 234334286219354

TMSI : 29d07bff

Invoking Event : Local Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 1d768ef6

RANDsn : 4e1d988c8287742f2b6e6558bf8386bb

RANDhn : 4e1d988c8287742f2b6e6558bf8386bb

Cipher Key : dfdc168a6a406644690c7608916ea4a

Integrity Key : 7b3e0520b834c937e4d140805f3c7be

XRES : f77df3ae74302580

XMACsn : 74b332f10726670e

XMACh : 52c49983ad1de00f

Authentication Status : Successful Authentication

131

=================================

Test 7 : User Authentication

=================================

Report Number : 5001

IMSI : 234334286219354

TMSI : null

Invoking Event : Full Authentication

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234334286219354

RANDsn : 8204071e4cc98316bfde1b910c4111a3

RANDhn : 8204071e4cc98316bfde1b910c4111a3

Cipher Key : bc14bf00bf8ada839b300464a419386

Integrity Key : b72eed8611fd5a35a95542fc2b51492

XRES : 6ea3401b10334e78

XMACsn : 2aed6fce915e1e1c

XMACh : 51ff7b9e2a7da20c

Authentication Status : Failed user authentication (XRES)

132

=================================

Test 8: Timestamp Check

=================================

Report Number : 5001

IMSI : 234334286219354

TMSI : null

Invoking Event : null

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234334286219354

RANDsn : 99feb4628b7e6dd8b0a256eb0880e3a6

RANDhn :

Cipher Key : null

Integrity Key : null

XRES : null

XMACsn : 5cf929f001cedea1

XMACh : null

Authentication Status : Incorrect Timestamp produced

133

=================================

Test 9 : Wrong IMSI

=================================

Report Number : 5001

IMSI : 234334286219354

TMSI : null

Invoking Event : null

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234335682571044

RANDsn : 70d384e2cf5b1362d34a6fd77627a9b1

RANDhn :

Cipher Key : null

Integrity Key : null

XRES : null

XMACsn : 71a76380790bc58f

XMACh : null

Authentication Status : IMSI / TMSI not found

Report Number : 5002

IMSI : 234334286219354

TMSI : null

Invoking Event : null

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234335682571044

RANDsn : d666ba1366e55ddf5a6849aa0a2a52e9

RANDhn :

134

Cipher Key : null

Integrity Key : null

XRES : null

XMACsn : 81042e266245d2ae

XMACh : null

Authentication Status : IMSI / TMSI not found

Report Number : 5003

IMSI : 234334286219354

TMSI : null

Invoking Event : null

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234335682571044

RANDsn : 3a4455a72bb24005367916d288e2568a

RANDhn :

Cipher Key : null

Integrity Key : null

XRES : null

XMACsn : ef41ab315db189b7

XMACh : null

Authentication Status : IMSI / TMSI not found

Exceeded Allowed number of attempts

Report Number : 5006

IMSI : 234334286219354

TMSI : null

Invoking Event : null

135

Serving Network ID : 2343357087

MSISDN : 447207638702

Current IMSI : 234335682571044

RANDsn : 3a4455a72bb24005367916d288e2568a

RANDhn :

Cipher Key : null

Integrity Key : null

XRES : null

XMACsn : ef41ab315db189b7

XMACh : null

Authentication Status : IMSI / TMSI not found

136

Appendix E: Source Code

137

Mobile Phone Class

package M801_Mobile_Phone;

3

4 import java.awt.event.ActionEvent;

5 import javax.swing.*;

6 import java.awt.*;

7 import java.io.*;

8 import java.awt.event.*;

9 import javax.swing.event.*;

10 import java.util.*;

11 import java.text.*;

12 import java.net.*;

13 import java.math.*;

14

15

16 public class MobilePhone extends JFrame implements ActionListener {

17

18 //GUI instance variables

19 private TextField randhId, randsId, xmacsnId, imsiId;

20 private TextField authCodeData, snId, timeStampId, authPass;

21 private TextField numOfMsg,timeTaken, xmachId, serverMsg, xresData;

22 private JComboBox testSelection;

23 private JButton exit, clear, start, test;

24 private JPanel lowerMiddle, messagePanel, buttonFrame, buttonPanel;

25 private JPanel dataPanel, dataPanelOne, dataPanelTwo, dataPanelThree;

26 private JPanel dataPanelFour, testPanel;

27 private JLabel randhnLabel, imsiLabel,xmacsnLabel;

28 private JLabel randsnLabel, authPassLabel, xmachLabel;

29 private JLabel timeStampLabel, xresLabel, snidLabel, testLabel;

30 private JLabel numOfMsgLabel, timeTakenLabel, serverMsgLabel, authCodeLabel;

31 private Color success, fail, neutral;

32

33

34 //Stream instance variables

35 private InputStream is;

36 private OutputStream os;

37 private FileOutputStream fos;

38 private PrintStream report;

39

40 // Reader and writer variables for Core Network communication

41 private PrintWriter pw;

42 private BufferedReader bf;

43

44 // Core Network communication variables

45 private String result;

46 private Socket socket;

47 private final boolean FLUSH = true;

48

49 // Protocol variables

50 private boolean falseAttempts;

51 private String imsi, tmsi, newImsi, randsn, xmacSn, typeOfAuth;

52 private String xres, xmach, randh, servingNetwork, timeStampStart;

53 private int authType, count, pinCount, authAttempts, attempts, numOfAttempts;

54 private String authCodePos, authCode, snid, timeStampFinish, replayData;

55 private String currentImsi, authenticationStatus, testNum, timestamp;

56 private String[] response;

57 private SimCard sim;

58

59

60 //Constructor

61

62 public MobilePhone(String ClientSoftware)

63 {

64 super(ClientSoftware);

65

66 // Set up the Data panel

67 dataPanel = new JPanel();

68 randsnLabel = new JLabel("RANDs", JLabel.RIGHT);

69 randsnLabel.setForeground(Color.white);

70 randsnLabel.setFont(new Font("New Times Roman", Font.BOLD, 14));

138

71 randsId = new TextField(35);

72 randhnLabel = new JLabel("RANDh", JLabel.RIGHT);

73 randhnLabel.setForeground(Color.white);

74 randhnLabel.setFont(new Font("New Times Roman", Font.BOLD, 14));

75 randhId = new TextField(35);

76 xmacsnLabel = new JLabel("XMACs", JLabel.RIGHT);

77 xmacsnLabel.setForeground(Color.white);

78 xmacsnLabel.setFont(new Font("New Times Roman", Font.BOLD, 14));

79 xmacsnId = new TextField(35);

80 xmachLabel = new JLabel("XMACh", JLabel.RIGHT);

81 xmachLabel.setForeground(Color.white);

82 xmachLabel.setFont(new Font("New Times Roman", Font.BOLD, 14));

83 xmachId = new TextField(35);

84 imsiLabel = new JLabel("IMSI ", JLabel.RIGHT);

85 imsiLabel.setForeground(Color.white);

86 imsiLabel.setFont(new Font("New Times Roman", Font.BOLD, 14));

87 imsiId = new TextField(35);

88 xresLabel = new JLabel("XRES ", JLabel.RIGHT);

89 xresLabel.setForeground(Color.white);

90 xresLabel.setFont(new Font("New Times Roman", Font.BOLD, 14));

91 xresData = new TextField(35);

92 authCodeLabel = new JLabel("Auth Code", JLabel.RIGHT);

93 authCodeLabel.setForeground(Color.white);

94 authCodeLabel.setFont(new Font("New Times Roman", Font.BOLD, 14));

95 authCodeData = new TextField(12);

96 timeStampLabel = new JLabel("Time Stamp", JLabel.RIGHT);

97 timeStampLabel.setForeground(Color.white);

98 timeStampLabel.setFont(new Font("New Times Roman", Font.BOLD, 14));

99 timeStampId = new TextField(16);

100 snidLabel = new JLabel("SNID ", JLabel.RIGHT);

101 snidLabel.setForeground(Color.white);

102 snidLabel.setFont(new Font("New Times Roman", Font.BOLD, 14));

103 snId = new TextField(12);

104

105 // Colour Schemes

106 Color background = new Color(205,92,92);

107 Color area = new Color(25,25,112);

108 success = new Color(173,255,47);

109 fail = new Color (255,0,0);

110 neutral = new Color(255,255,255);

111

112

113 //Set up lower lowerMiddle panel

114 lowerMiddle = new JPanel();

115 numOfMsgLabel = new JLabel("Number of Messages", JLabel.RIGHT);

116 numOfMsgLabel.setForeground(Color.white);

117 numOfMsgLabel.setFont(new Font("New Times Roman", Font.BOLD, 14));

118 numOfMsg = new TextField(3);

119 timeTakenLabel = new JLabel("Time Taken", JLabel.RIGHT);

120 timeTakenLabel.setForeground(Color.white);

121 timeTakenLabel.setFont(new Font("New Times Roman", Font.BOLD, 14));

122 timeTaken = new TextField(10);

123 authPassLabel = new JLabel("Auth Pass?", JLabel.RIGHT);

124 authPassLabel.setForeground(Color.white);

125 authPassLabel.setFont(new Font("New Times Roman", Font.BOLD, 14));

126 authPass = new TextField(4);

127

128

129 // Set up the Message Panel

130 messagePanel = new JPanel();

131 serverMsgLabel = new JLabel("Network Messages", JLabel.LEFT);

132 serverMsgLabel.setForeground(Color.white);

133 serverMsgLabel.setFont(new Font("New Times Roman", Font.BOLD, 14));

134 serverMsg = new TextField(75);

135

136

137 // Set up Test Panel

138 testPanel = new JPanel();

139 testLabel = new JLabel("Select Test Number", JLabel.LEFT);

140 testLabel.setForeground(Color.white);

141 testLabel.setFont(new Font("New Times Roman", Font.BOLD, 14));

142 String[] testItems = {"0.No Test Selected","1.Redirection Attack",

143 "2.Replay Attack", "3.Mutual Authentication",

144 "4.Anonymity Test", "5.Change Serving Network",

145 "6.User Authentication","7.Timestamp Check",

146 "8.Wrong IMSI"};

139

147 testSelection = new JComboBox(testItems);

148

149

150

151 // Create a new canvas using grid layout for the three panels

152 GridLayout layout = new GridLayout(8, 0);

153 setLayout(layout);

154 dataPanelOne = new JPanel();

155 dataPanelTwo = new JPanel();

156 dataPanelThree = new JPanel();

157 dataPanelFour = new JPanel();

158 FlowLayout panelOne = new FlowLayout(FlowLayout.LEFT, 40, 20);

159 FlowLayout panelTwo = new FlowLayout(FlowLayout.LEFT, 40, 0);

160 FlowLayout panelThree = new FlowLayout(FlowLayout.LEFT, 40, 0);

161 dataPanelOne.setLayout(panelOne);

162 dataPanelTwo.setLayout(panelTwo);

163 dataPanelThree.setLayout(panelTwo);

164 dataPanelFour.setLayout(panelThree);

165 dataPanelOne.add(randsnLabel);

166 dataPanelOne.add(randsId);

167 dataPanelTwo.add(imsiLabel);

168 dataPanelTwo.add(imsiId);

169 dataPanelThree.add(xmacsnLabel);

170 dataPanelThree.add(xmacsnId);

171 dataPanelFour.add(snidLabel);

172 dataPanelFour.add(snId);

173 dataPanelOne.add(randhnLabel);

174 dataPanelOne.add(randhId);

175 dataPanelTwo.add(xresLabel);

176 dataPanelTwo.add(xresData);

177 dataPanelThree.add(xmachLabel);

178 dataPanelThree.add(xmachId);

179 dataPanelFour.add(authCodeLabel);

180 dataPanelFour.add(authCodeData);

181 dataPanelFour.add(timeStampLabel);

182 dataPanelFour.add(timeStampId);

183 add(dataPanelOne);

184 add(dataPanelTwo);

185 add(dataPanelThree);

186 add(dataPanelFour);

187 dataPanelOne.setBackground(area);

188 dataPanelTwo.setBackground(area);

189 dataPanelThree.setBackground(area);

190 dataPanelFour.setBackground(area);

191 dataPanel.setBackground(area);

192

193 //Set up the lower Middle frame

194 FlowLayout lowerMiddleFrame = new FlowLayout(FlowLayout.LEFT, 40, 10);

195 lowerMiddle.setLayout(lowerMiddleFrame);

196 lowerMiddle.add(numOfMsgLabel);

197 lowerMiddle.add(numOfMsg);

198 lowerMiddle.add(timeTakenLabel);

199 lowerMiddle.add(timeTaken);

200 lowerMiddle.add(authPassLabel);

201 lowerMiddle.add(authPass);

202 add(lowerMiddle);

203 lowerMiddle.setBackground(area);

204

205

206

207 //Set up the Message Panel

208 FlowLayout messageFrame = new FlowLayout(FlowLayout.LEFT, 40, 20);

209 messagePanel.setLayout(messageFrame);

210 messagePanel.add(serverMsgLabel);

211 messagePanel.add(serverMsg);

212 add(messagePanel);

213 messagePanel.setBackground(area);

214

215 //Set up the Test Panel

216 FlowLayout testFrame = new FlowLayout(FlowLayout.LEFT, 40, 20);

217 testPanel.setLayout(testFrame);

218 testPanel.add(testLabel);

219 testPanel.add(testSelection);

220 add(testPanel);

221 testPanel.setBackground(area);

222

140

223

224 // Set up the Button Panel

225 buttonFrame = new JPanel(new BorderLayout());

226 FlowLayout buttonFramePanel = new FlowLayout(FlowLayout.CENTER, 100, 10);

227 start = new JButton("Start");

228 clear = new JButton("Clear");

229 exit = new JButton("Quit");

230 test = new JButton("Test");

231 buttonPanel = new JPanel();

232 buttonPanel.setLayout(buttonFramePanel);

233 buttonPanel.add(start);

234 buttonPanel.add(test);

235 buttonPanel.add(clear);

236 buttonPanel.add(exit);

237 buttonFrame.add(buttonPanel, BorderLayout.SOUTH);

238 add(buttonFrame);

239 buttonFrame.setBackground(area);

240 buttonPanel.setBackground(background);

241

242 //Register Buttons

243 exit.addActionListener(this);

244 start.addActionListener(this);

245 clear.addActionListener(this);

246 test.addActionListener(this);

247

248

249

250 this.addWindowListener(new WindowCloser());

251 setSize(850, 600);

252 setVisible(true);

253 setResizable(false);

254 setLocation(100,100);

255

256 //Connect to Core Network

257 initConnection();

258 sim = new SimCard();

259 count=0;

260 servingNetwork = "";

261

262 }

263

264 //Initialse input/output streams

265 public void initConnection()

266 {

267

268 try

269 {

270 socket = new Socket("127.0.0.1",4444);

271 is = socket.getInputStream();

272 bf = new BufferedReader(new InputStreamReader(is));

273 os = socket.getOutputStream();

274 pw = new PrintWriter(os,FLUSH);

275 fos = new FileOutputStream ("C:\\Documents and Settings\\Test

Report.txt");

276 report = new PrintStream(fos);

277

278

279 }

280 catch (IOException e)

281 {

282 System.out.println("Trouble contacting the server " + e);

283 e.printStackTrace();

284 }

285 }

286

287 // Timestamp used timing authentication process

288 public String timeStamp()

289 {

290 DateFormat dateFormat = new SimpleDateFormat("mmss");

291 java.util.Date date = new java.util.Date();

292 return dateFormat.format(date);

293 }

294

295 // Clears all text boxes on the GUI

296 private void clear() throws IOException

297 {

141

298 randsId.setText("");

299 randhId.setText("");

300 imsiId.setText("");

301 xresData.setText("");

302 authCodeData.setText("");

303 authPass.setText("");

304 numOfMsg.setText("");

305 timeTaken.setText("");

306 xmacsnId.setText("");

307 xmachId.setText("");

308 snId.setText("");

309 timeStampId.setText("");

310 serverMsg.setText("");

311 authPass.setBackground(neutral);

312 }

313

314

315 //Close down all input/output streams on exiting

316 private void quit() throws IOException

317 {

318 pw.println("Q");

319 pw.close();

320 os.close();

321 bf.close();

322 is.close();

323 fos.close();

324 report.close();

325 socket.close();

326 System.exit(0);

327 }

328

329 // Authorisation code position generator

330 private String authorisationCodeGenerator()

331 {

332 ArrayList<String> al = new ArrayList<String>();

333 int num =32;

334 for (int n=1; n<num; n++)

335 {

336 String sd = ""+n+"";

337 al.add(n-1, sd);

338 }

339

340 Random generator = new Random();

341 int randomIndex[];

342 int code[];

343 code = new int[4];

344 randomIndex = new int[4];

345 for (int i=0; i<4; i++)

346 {

347 randomIndex[i] = generator.nextInt(num-1);

348 code[i] = Integer.parseInt(al.get(randomIndex[i]));

349 num = num - 1;

350 al.remove(randomIndex[i]);

351 }

352

353 authCode = (code[0]+":"+code[1]+":"+code[2]+":"+code[3]);

354 return authCode;

355 }

356

357 // Determine type of authentication to be used

358 public int authenticationType (int count, int imsiLength)

359 {

360 if (count==0 || imsiLength==15)

361 {

362 authType = 0;

363 }

364 else{

365 authType = 1;

366 }

367 return authType;

368 }

369

370 private class WindowCloser extends WindowAdapter

371 {

372

373

142

374 public void windowClosing(WindowEvent e)

375 {

376

377 try

378 {

379 pw.println("Q");

380 pw.close();

381 os.close();

382 bf.close();

383 is.close();

384 fos.close();

385 report.close();

386 socket.close();

387 System.exit(0);

388 }

389 catch (IOException ex)

390 {

391 System.out.println("Trouble contacting the server " + ex);

392 }

393 }

394 }

395

396 // Produce test summary to file

397 public void testReport()

398 {

399 report.println("");

400 report.println("");

401 int reportNumber = attempts+5000;

402 report.println("Report Number : "+reportNumber);

403 report.println("IMSI : "+imsi);

404 report.println("TMSI : " +tmsi);

405 report.println("Invoking Event : " +typeOfAuth);

406 report.println("Serving Network ID : " +snid);

407 report.println("MSISDN : "+sim.getMsisdn());

408 report.println("Current IMSI : "+currentImsi);

409 report.println("RANDsn : " +randsn);

410 report.println("RANDhn : " +randh);

411 report.println("Cipher Key : " + sim.getCk());

412 report.println("Integrity Key : "+sim.getIk());

413 report.println("XRES : " +xres);

414 report.println("XMACsn : " +xmacSn);

415 report.println("XMACh : " +xmach);

416 report.println("Authentication Status : "+authenticationStatus);

417 report.println("");

418 report.println("");

419

420 }

421

422 public void testBanner()

423 {

424 if (testNum.equals("0.No Test Selected"))

425 {

426 report.println("=====================================");

427 report.println(" Test 1 : Normal Authentication ");

428 report.println("=====================================");

429 numOfAttempts = 7;

430 }

431 if (testNum.equals("1.Redirection Attack"))

432 {

433 report.println("=================================");

434 report.println(" Test 2 :Redirection Attack ");

435 report.println("=================================");

436 numOfAttempts = 1;

437 }

438 if (testNum.equals("2.Replay Attack"))

439 {

440 report.println("=================================");

441 report.println(" Test 3 : Replay Attack ");

442 report.println("=================================");

443 numOfAttempts = 6;

444 }

445 if (testNum.equals("3.Mutual Authentication"))

446 {

447 report.println("=================================");

448 report.println(" Test 4 : Mutual Authentication ");

449 report.println("=================================");

143

450 numOfAttempts = 1;

451 }

452 if (testNum.equals("4.Anonymity Test"))

453 {

454 report.println("=================================");

455 report.println(" Test 5 : Anonymity Test ");

456 report.println("=================================");

457 numOfAttempts = 7;

458 }

459 if (testNum.equals("5.Change Serving Network"))

460 {

461 report.println("=================================");

462 report.println(" Test 6 : Change Serving Network ");

463 report.println("=================================");

464 numOfAttempts = 5;

465 }

466 if (testNum.equals("6.User Authentication"))

467 {

468 report.println("=================================");

469 report.println(" Test 7 : User Authentication ");

470 report.println("=================================");

471 numOfAttempts = 1;

472 }

473 if (testNum.equals("7.Timestamp Check"))

474 {

475 report.println("=================================");

476 report.println(" Test 8 : Timestamp Check ");

477 report.println("=================================");

478 numOfAttempts = 1;

479 }

480 if (testNum.equals("8.Wrong IMSI"))

481 {

482 report.println("=================================");

483 report.println(" Test 9 : Wrong IMSI ");

484 report.println("=================================");

485 numOfAttempts = 5;

486 }

487

488

489 }

490

491 // Initialise variables before authentication process

492 public void initialValues()

493 {

494 pinCount=0;

495 authAttempts=0;

496 timeStampStart="";

497 randh="";

498 replayData="";

499 timeStampFinish="";

500 authenticationStatus="";

501 attempts=0;

502 falseAttempts = false;

503 }

504

505 // Main mobile station authentication procedure

506 public void authentication() throws Exception

507 {

508 initialValues();

509 int numOfMessages=0;

510 testNum = (String)testSelection.getSelectedItem();

511 testBanner();

512

513 try {

514 timeStampStart= timeStamp();

515 while (attempts < numOfAttempts)

516 {

517 if (!(falseAttempts))

518 {

519 if (pinCount >= 3 || authAttempts >= 3)

520 {

521 report.println("Exceeded Allowed number of attempts");

522 falseAttempts = true;

523 authPass.setText("Fail");

524 authPass.setBackground(fail);

525 attempts=numOfAttempts;

144

526 serverMsg.setText("Your Phone is now locked." +

527 " Please contact customer services");

528 start.setEnabled(false);

529

530 }

531 else

532 {

533 pw.println("F");

534 numOfMessages++;

535 result = bf.readLine();

536 response = result.split(",");

537

538 if(response[0].equals("S"))

539 {

540 if (testNum.equals("7.Timestamp Check"))

541 {

542 timestamp = "20091223092335";

543 }

544 else

545 {

546

547 timestamp = response[3];

548 }

549

550 randsn = response[1];

551

552 if (testNum.equals("1.Redirection Attack"))

553 {

554 snid="4522198427";

555 }

556 else

557 {

558 snid = response[2];

559 }

560

561 snId.setText(snid);

562 timeStampId.setText(timestamp);

563 randsId.setText(randsn);

564 if (testNum.equals("5.Change Serving Network")&&

attempts==2)

565 {

566 servingNetwork = "4522198427";

567 sim.resetTmsi();

568 }

569

570 if (!(servingNetwork.equals(snid)))

571 {

572 count = 0;

573 this.servingNetwork = snid;

574 }

575 if (testNum.equals("8.Wrong IMSI"))

576 {

577 currentImsi="234335682571044";

578 }

579 else

580 {

581 if (testNum.equals("4.Anonymity Test"))

582 {

583 sim.resetTmsi();

584 }

585 currentImsi = sim.getIndentification();

586 }

587 authType = authenticationType(count,

currentImsi.length());

588

589 imsi = sim.getImsi();

590 imsiId.setText(imsi);

591 String aucData = imsi+timestamp+randsn+snid;

592 xmacSn = sim.createXmacSn(aucData, authType);

593 authCodePos = authorisationCodeGenerator();

594 authCodeData.setText(""+authCodePos);

595 String authenticationData =currentImsi + "," + xmacSn +

596 "," +authCodePos+ "," + authType;

597

598 if (testNum.equals("2.Replay Attack")&& attempts==0)

599 {

145

600 replayData = authenticationData;

601 }

602 if (testNum.equals("2.Replay Attack")&& attempts==2)

603 {

604 pw.println("A," + replayData);

605 }

606 else

607 {

608 pw.println("A," + authenticationData);

609 }

610

611 xmacsnId.setText(""+xmacSn);

612 numOfMessages++;

613 result = bf.readLine();

614 response = result.split(",");

615

616 if (response[0].equals("D"))

617 {

618 serverMsg.setText("Incorrect Timestamp produced");

619 authenticationStatus = "Incorrect Timestamp produced";

620 authAttempts++;

621 authPass.setText("Fail");

622 authPass.setBackground(fail);

623 }

624

625 if (response[0].equals("B"))

626 {

627 serverMsg.setText("Server Network Test Failed");

628 authenticationStatus = "Server Network Test

Failed(XMACsn)";

629 authPass.setText("Fail");

630 authPass.setBackground(fail);

631 pinCount++;

632 }

633 if (response[0].equals("I"))

634 {

635 serverMsg.setText("IMSI / TMSI Failed");

636 authenticationStatus = "IMSI / TMSI not found";

637 authPass.setText("Fail");

638 authPass.setBackground(fail);

639 pinCount++;

640 }

641 if(response[0].equals("C"))

642 {

643 if (authType == 0)

644 {

645 typeOfAuth = "Full Authentication";

646 randh = response[1];

647 xmach = response[2];

648 xmachId.setText(""+xmach);

649 }

650

651 if (authType == 1)

652 {

653 typeOfAuth = "Local Authentication";

654 randh = randsn;

655 xmach = response[1];

656 xmachId.setText(""+xmach);

657 }

658

659 randhId.setText(randh);

660 if (testNum.equals("3.Mutual Authentication"))

661 {

662 sim.setTestNumber("3.Mutual Authentication");

663 }

664

665 if (sim.checkMac(randh, xmach, authCodePos, timestamp))

666 {

667 if (testNum.equals("6.User Authentication"))

668 {

669 randh = randsn;

670 }

671 xres = sim.createXres(randh);

672 xresData.setText(xres);

673 pw.println("X," +xres);

674 numOfMessages++;

146

675 result = bf.readLine();

676 response = result.split(",");

677

678 if (response[0].equals("W"))

679 {

680 authPass.setText("Pass");

681 authPass.setBackground(success);

682 authenticationStatus = "Successful

Authentication";

683 serverMsg.setText("Successful Authentication");

684 tmsi = response[1];

685 sim.setTmsi(response[1]);

686 newImsi = response[2];

687 sim.setNewImsi(newImsi);

688

689 count++;

690 if (count == 5)

691 {

692 count = 0;

693 }

694 }

695

696 if (response[0].equals("Z"))

697 {

698 authPass.setText("Fail");

699 authPass.setBackground(fail);

700 authAttempts++;

701 authenticationStatus = "Failed user

authentication (XRES)";

702 serverMsg.setText("User Authentication

Fails");

703 }

704 }

705 else

706 {

707 serverMsg.setText("Network not Authenticated");

708 authenticationStatus = "Server Network Test

Failed(XMAChn)";

709 authAttempts++;

710 authPass.setText("Fail");

711 authPass.setBackground(fail);

712 }

713 }

714 }

715

716

717 numOfMsg.setText(""+numOfMessages);

718

719 }

720 }

721 attempts++;

722 testReport();

723 }

724

725 }catch (IOException ex) {

726 authPass.setText("Fail");

727 authPass.setBackground(fail);

728 ex.printStackTrace();

729 }

730 timeStampFinish = timeStamp();

731 long timestamp1 = Integer.parseInt(timeStampStart);

732 long timestamp2 = Integer.parseInt(timeStampFinish);

733

734 long TimeStamp=timestamp2 - timestamp1;

735 timeTaken.setText(TimeStamp+" Seconds");

736 }

737

738

739

740 // Process commands on selection

741 public void actionPerformed(ActionEvent ae)

742 {

743

744 String cmd = ae.getActionCommand();

745 try

746 {

147

747

748 if (cmd.equals("Quit"))

749 {

750 clear();

751 quit();

752 }

753

754 if (cmd.equals("Start"))

755 {

756 clear();

757 authentication();

758 }

759

760 if (cmd.equals("Clear"))

761 {

762 clear();

763 }

764

765 if (cmd.equals("Test"))

766 {

767 clear();

768

769 }

770

771

772

773 }

774 catch (Exception e)

775 {

776 authPass.setText("Fail");

777 authPass.setBackground(fail);

778 System.out.println("Oops there is a real problem" +e);

779 e.printStackTrace();

780

781 }

782

783 }

784 public static void main(String[] args) {

785 String title = "M801 Prototype Authentication Simulator";

786 MobilePhone mp = new MobilePhone(title);

787

788 }

789

790 }

791

792

SIM Card Class – Carries out security tasks done by SIM card

package M801_Mobile_Phone;

3

4 import javax.crypto.*;

5 import java.text.*;

6 import java.math.*;

7 import java.util.*;

8 import java.security.*;

9 import javax.crypto.spec.SecretKeySpec;

10 import javax.swing.*;

11 import javax.swing.JOptionPane;

12 import java.io.*;

13

14

15

16 public class SimCard {

17 private Encryption crypt;

18 private String xres, rand, authorisationKey, code, imsi, nIMSI, cIMSI, passCode;

19 private String xmacs, xmacm, autn, AV, ck, ik, tk, secretKey, ki, k1, k, pinKey;

20 private String memoryKey, userKey, aki, tmsi, identification, test, userVal;

21 private int authType, simCount;

22 private StringBuffer sb;

23 private SecretKeySpec key;

148

24 private static final String AUTHORISATION_KEY =

"6d9e3c34a6960ae4b43fd5043b9ea13c";

25 private static final String KI = "62170867cd2e488dcb93c83dbbfc5";

26 private static final String FALSE_KEY = "7a4db82d1e2740b4a922188b96a26a33";

27 private static final String IMSI = "234334286219354";

28 private static final String MSISDN = "447207638702";

29

30

31

32

33 public SimCard()

34 {

35

36 crypt = new Encryption();

37 memoryKey = "";

38 tmsi="";

39 test="";

40 userKey = "";

41 ki = "";

42 nIMSI = "";

43 simCount=0;

44

45 }

46

47 public String pinCodeRequest()

48 {

49 passCode = JOptionPane.showInputDialog(null," " +

50 "Please Enter Your 4 Digit PIN Code",JOptionPane.QUESTION_MESSAGE);

51 int pin = Integer.parseInt(passCode);

52 DecimalFormat number = new DecimalFormat("0000");

53 number.setMinimumIntegerDigits(4);

54 number.setMaximumIntegerDigits(4);

55 number.setDecimalSeparatorAlwaysShown(false);

56 String pinNumber = number.format(pin);

57 return pinNumber;

58 }

59

60 public String userLogin()

61 {

62 if (memoryKey.equals(""))

63 {

64 userKey = pinCodeRequest();

65 return userKey;

66 }

67 else

68 {

69 return memoryKey;

70 }

71 }

72

73 public void setTestNumber(String test)

74 {

75 this.test = test;

76 }

77

78

79 public boolean checkMac(String randh, String xmach, String authCode,

80 String timestamp)

81 throws Exception

82 {

83

84 byte[] Ki = new BigInteger(ki,16).toByteArray();

85 key = new SecretKeySpec(Ki, "AES");

86 code = randh+authorisationCode(authCode)+timestamp;

87 byte[] random = new BigInteger(code, 16).toByteArray();

88 String xmacmh = Conversion.toHex(crypt.encryptMac(random, key));

89 xmacm = xmachTrimming(xmacmh);

90 return (xmacm.equals(xmach));

91 }

92

93 public String createXres(String randh)throws Exception

94 {

95 byte[] Ki = new BigInteger(ki,16).toByteArray();

96 key = new SecretKeySpec(Ki, "AES");

97 byte[] randH = randh.getBytes("UTF8");

98 String xresult = Conversion.toHex(crypt.encryptXres(randH, key));

149

99 xres = xmacsTrimming(xresult);

100 ik = createIk(randh);

101 ck = createCk(randh);

102

103

104

105 if (authType == 0)

106 {

107 tk = createTk(ck, ik);

108

109 }

110

111 if (memoryKey.equals(""))

112 {

113 memoryKey = userKey;

114 }

115

116

117 return xres;

118 }

119

120 public String xmacsTrimming(String xmac)

121 {

122 String xmac1 = xmac.substring(0,16);

123 String xmac2 = xmac.substring(16,32);

124 String xmac3 = xmac.substring(32,48);

125 String xmac4 = xmac.substring(48,64);

126 String xmac5 = xmac.substring(64,80);

127 String xmac6 = xmac.substring(80,xmac.length());

128

129 BigInteger numX1 = new BigInteger(xmac1,16);

130 BigInteger numX2 = new BigInteger(xmac2,16);

131 BigInteger numX3 = new BigInteger(xmac3,16);

132 BigInteger numX4 = new BigInteger(xmac4,16);

133 BigInteger numX5 = new BigInteger(xmac5,16);

134 BigInteger numX6 = new BigInteger(xmac6,16);

135

136 BigInteger xorOp1 = numX1.xor(numX2);

137 BigInteger xorOp2 = xorOp1.xor(numX3);

138 BigInteger xorOp3 = xorOp2.xor(numX4);

139 BigInteger xorOp4 = xorOp3.xor(numX5);

140 BigInteger xorOp5 = xorOp4.xor(numX6);

141 return xmacs = xorOp5.toString(16);

142 }

143

144 public String xmachTrimming(String xmac)

145 {

146 String xmac1 = xmac.substring(0,16);

147 String xmac2 = xmac.substring(16,32);

148 String xmac3 = xmac.substring(32,48);

149 String xmac4 = xmac.substring(48,xmac.length());

150

151 BigInteger numX1 = new BigInteger(xmac1,16);

152 BigInteger numX2 = new BigInteger(xmac2,16);

153 BigInteger numX3 = new BigInteger(xmac3,16);

154 BigInteger numX4 = new BigInteger(xmac4,16);

155

156

157 BigInteger xorOp1 = numX1.xor(numX2);

158 BigInteger xorOp2 = xorOp1.xor(numX3);

159 BigInteger xorOp3 = xorOp2.xor(numX4);

160 return xmacs = xorOp3.toString(16);

161 }

162

163

164

165 public String createXmacSn(String data, int authType)throws Exception

166 {

167 this.authType = authType;

168 ki = generateSecretKey(authType);

169 simCount++;

170 byte[] Ki = new BigInteger(ki, 16).toByteArray();

171

172 key = new SecretKeySpec(Ki, "AES");

173

174 byte[] auData = new BigInteger(data, 16).toByteArray();

150

175 String xmacsn = Conversion.toHex(crypt.encryptMac(auData, key));

176 xmacs = xmacsTrimming(xmacsn);

177

178 return xmacs;

179 }

180

181 public String newIdentites(byte[] response) throws Exception

182 {

183 byte[] Kc = new BigInteger(ck,16).toByteArray();

184 SecretKeySpec CK = new SecretKeySpec(Kc, "AES");

185 String rawData = Conversion.toHex(crypt.decrypt(response, CK));

186 return rawData;

187 }

188

189 public String authorisationCode (String authorisationData)

190 {

191 String[] data = authorisationData.split(":");

192 sb = new StringBuffer();

193

194 for(int i=0; i<=3; i++)

195 {

196 int index = Integer.parseInt(data[i]);

197

198 if (authType == 0)

199 {

200 if (test.equals("3.Mutual Authentication"))

201 {

202 String stringCode = FALSE_KEY.substring(index-1, index);

203 sb.append(stringCode);

204 }

205 else

206 {

207 String stringCode = AUTHORISATION_KEY.substring(index-1,

index);

208 sb.append(stringCode);

209 }

210

211 }

212 if (authType == 1)

213 {

214 String stringCode = tk.substring(index-1, index);

215 sb.append(stringCode);

216 }

217

218

219 }

220 code = sb.toString();

221

222 return code;

223

224 }

225

226 public String generateKi()

227 {

228

229 int kint = Integer.parseInt(userLogin());

230 pinKey = Integer.toHexString(kint);

231

232

233 if (KI.length()==29)

234 {

235 userVal = pinKey.substring(0,3);

236 }

237 if (KI.length()==28)

238 {

239 userVal = pinKey.substring(0,4);

240 }

241 k = KI+""+userVal;

242 return k;

243 }

244

245 public String generateSecretKey(int authType)

246 {

247 if (authType == 0)

248 {

249 aki = generateKi();

151

250

251 }

252 if (authType == 1)

253 {

254 aki = tk;

255

256 }

257

258 return aki;

259 }

260

261

262 //Generate Cipher Key

263

264 public String createCk(String randS)throws Exception

265 {

266 byte[] rands = randS.getBytes("UTF8");

267 ck = Conversion.toHex(crypt.encryptCipher(rands, key)).substring(1,

32);

268 return ck;

269 }

270

271 // Generate Integrity Key

272

273 public String createIk(String randS)throws Exception

274 {

275 byte[] rands = randS.getBytes("UTF8");

276 ik = Conversion.toHex(crypt.encryptIntegrity(rands, key)).substring(1,

32);

277 return ik;

278 }

279

280 public String getCk()

281 {

282 return ck;

283 }

284

285

286 public String getIk()

287 {

288 return ik;

289 }

290

291 // Generate Temporary Key

292

293 public String createTk(String ck, String ik)

294 {

295 BigInteger numCk = new BigInteger(ck,16);

296 BigInteger numIk = new BigInteger(ik,16);

297 BigInteger xorOp = numCk.xor(numIk);

298 tk = xorOp.toString(16);

299 return tk;

300 }

301

302 public String getMsisdn()

303 {

304 String msisdn = MSISDN;

305 return msisdn;

306 }

307

308 public void resetTmsi()

309 {

310 tmsi="";

311 }

312

313 public String getIndentification()

314 {

315

316 if (tmsi.equals(""))

317 {

318

319 identification = findImsi();

320

321 }

322 else

323 {

152

324 identification = getTmsi();

325 }

326

327 return identification;

328 }

329

330 public String findImsi()

331 {

332 if (nIMSI.equals(""))

333 {

334 cIMSI = getImsi();

335 return cIMSI;

336 }

337 else{

338

339 cIMSI = getNewImsi();

340 return cIMSI;

341 }

342 }

343

344 public String getImsi()

345 {

346 this.imsi = IMSI;

347 return imsi;

348 }

349

350 private String getNewImsi()

351 {

352 return nIMSI;

353 }

354

355 public void setNewImsi(String nImsi)

356 {

357 this.nIMSI = nImsi;

358 }

359

360 private String getTmsi()

361 {

362 return tmsi;

363 }

364

365 public void setTmsi(String tmsi)

366 {

367 this.tmsi = tmsi;

368 }

369

370 }

371

372

HomeLocationRegister Class

package M801_Core_Network;

3

4 import javax.crypto.*;

5 import java.math.*;

6 import java.util.*;

7 import java.security.*;

8 import java.text.*;

9 import java.io.*;

10 import javax.crypto.spec.SecretKeySpec;

11

12

13 public class HomeLocationRegister {

14 private int hlrId;

15 private SecureRandomNumber srn;

16 private Cryptography crypt;

17 private AuthenticationCentre auc;

18 private String xres, code, imsi;

19 private String ik, ck, xmach, xmacsn, xmac;

20 private SecretKeySpec key;

21 private int hlrCount;

22 private String secretKey, failureReport;

23

153

24 // Constructor

25

26 public HomeLocationRegister()

27 {

28 auc = new AuthenticationCentre();

29 hlrCount=0;

30 srn = new SecureRandomNumber();

31 crypt = new Cryptography();

32

33 }

34

35 // Generate a timestamp for authentication checks

36

37 public String timeStamp()

38 {

39 DateFormat dateFormat = new SimpleDateFormat("yyyyMMddHHmmss");

40 java.util.Date date = new java.util.Date();

41 return dateFormat.format(date);

42 }

43

44 // Check MACsn sent by the subscriber

45

46 public boolean MACsn(String rands, String xmac, String timestamp,

47 String imsi, String snid) throws Exception

48 {

49 byte[] Ki = new BigInteger(secretKey,16).toByteArray();

50 key = new SecretKeySpec(Ki, "AES");

51 code = imsi+timestamp+rands+snid;

52 byte[] auData = new BigInteger(code, 16).toByteArray();

53 String xmacs = Utils.toHex(crypt.encryptMac(auData, key));

54 xmacsn = Utils.xmacsTrimming(xmacs);

55 return (xmacsn.equals(xmac));

56 }

57

58 // Check validity of time stamp sent

59

60 public boolean checkTimeStamp(String timestamp)

61 {

62 String timestampHlr = timeStamp().substring(timeStamp().length()-6,

63 timeStamp().length());

64 String time2 = timestamp.substring(timestamp.length()-6,

65 timestamp.length());

66 long timestamp2 = Integer.parseInt(timestampHlr);

67 long timestamp1 = Integer.parseInt(time2);

68 long timeDiff = timestamp2-timestamp1;

69 if ((timestamp2 - timestamp1) <100)

70 {

71 return true;

72 }

73 else

74 {

75 return false;

76 }

77 }

78

79 // Generate authentication vector for the serving network

80

81 public String Authentication(String rands, String xmac, String authCode,

82 String timestamp, String imsi, int hlrID,

83 String snid)throws Exception

84 {

85 this.imsi = imsi;

86 this.hlrId = hlrID;

87 this.xmac = xmac;

88 boolean timeCheck = checkTimeStamp(timestamp);

89 secretKey = auc.findKi(imsi, hlrId);

90 boolean snCheck = MACsn(rands, xmac, timestamp, imsi, snid);

91 hlrCount++;

92 if (!(timeCheck))

93 {

94 failureReport = "Time Check Failed";

95 return failureReport;

96 }

97 else if (!(snCheck))

98 {

99 failureReport = "Serving Network Failed";

154

100 return failureReport;

101 }

102 else

103 {

104

105 byte[] Ki = new BigInteger(secretKey,16).toByteArray();

106 key = new SecretKeySpec(Ki, "AES");

107 byte[] randomh = srn.getNextSecureRandom(16);

108 String randh = Utils.toHex(randomh);

109 byte[] randH = randh.getBytes("UTF8");

110 String xresult = Utils.toHex(crypt.encryptXres(randH, key));

111 xres = Utils.xmacsTrimming(xresult);

112 String data = randh+auc.authPass(authCode)+timestamp;

113 byte[] message = new BigInteger(data,16).toByteArray();

114 String xmachn = Utils.toHex(crypt.encryptMac(message, key));

115 xmach = Utils.xmachTrimming(xmachn);

116 ck = Utils.toHex(crypt.encryptCipher(randH, key)).substring(1,32);

117 ik = Utils.toHex(crypt.encryptIntegrity(randH, key)).substring(1,32);

118 String auData = randh+","+xmach+","+xres+","+ik+","+ck;

119 return auData;

120 }

121

122

123

124 }

125

126

127 }

128

129

130

MobileSwitchingCentre Class

package M801_Core_Network;

3

4

5

6 /* This is the main server class for this simulator snd also controls

7 other core network elements such as SLR, VLR, HLR and AuC. The class is

8 represents the functionality carried out by the MSC/VLR in a UMTS network

9

10 Chris Lukeman 2010 */

11

12 import java.io.*;

13 import java.math.BigInteger;

14 import java.net.*;

15 import java.util.*;

16 import java.text.*;

17 import javax.crypto.*;

18 import java.security.*;

19

20

21

22 public class MobileSwitchingCentre implements Runnable {

23

24 //Instance variables

25

26 private ServiceLocationRegister slrEnq;

27 private HomeLocationRegister hlrEnq;

28 private VisitorLocationRegister vlrEnq;

29 private HashMap tmsiMap, hlrMap;

30 private String challenge, resp, command, tmsi, identifier;

31 private String xres,ik, ck,tk, timestamp, snid, rands;

32 private String authCodePos, subData, imsi, xmac, nIMSI, newIdentity;

33 private SecureRandomNumber srn;

34 private String[] request, authData;

35 private BigInteger numCk, numIk, xorOp;

36 private int authType, hlrId, mscCount;

37 private static final String SNID = "2343357087";

38 private boolean operational = true;

39

40

41

155

42 //Stream instance variables

43 private InputStream is;

44 private OutputStream os;

45

46 // Reader and writer variables for server communication

47 private PrintWriter pw;

48 private BufferedReader bf;

49

50

51 // Server communication variables

52

53 private Socket socket;

54 private final boolean FLUSH = true;

55

56 // Constructor

57

58 public MobileSwitchingCentre()

59 {

60 srn = new SecureRandomNumber();

61 slrEnq = new ServiceLocationRegister();

62 hlrEnq = new HomeLocationRegister();

63 vlrEnq = new VisitorLocationRegister();

64 tmsiMap = new HashMap();

65 hlrMap = new HashMap();

66 mscCount=0;

67 timestamp="";

68 rands="";

69 snid="";

70

71 }

72

73 // Generate a time stamp for authentication

74

75 public String timeStamp()

76 {

77 DateFormat dateFormat = new SimpleDateFormat("yyyyMMddHHmmss");

78 java.util.Date date = new java.util.Date();

79 return dateFormat.format(date);

80 }

81

82 // Send authentication request to mobile station

83

84 private void sendAuthData()

85 {

86 timestamp = timeStamp();

87 snid = SNID;

88 rands = Utils.toHex(srn.getNextSecureRandom(16));

89 String initialisation = "S,"+rands+","+snid+","+timestamp;

90 pw.println(initialisation);

91 }

92

93 // Ask SLR for details of subscriber

94

95 private boolean slrQuery (String imsiData)

96 {

97 String slrResult = slrEnq.findSub(imsiData);

98 if (slrResult.equals("IMSI not found"))

99 {

100 return false;

101 }

102 else

103 {

104 String [] slrData = slrResult.split(":");

105 nIMSI = slrData[2];

106 hlrId = Integer.parseInt(slrData[1]);

107 imsi = slrData[0];

108 return true;

109 }

110 }

111

112 // Find the subscriber IMSI through association with its TMSI

113

114 private boolean setIMSI(String Identifier)

115 {

116 if (tmsiMap.containsKey(Identifier))

117 {

156

118 imsi=(String)tmsiMap.get(Identifier);

119 hlrId = (Integer)hlrMap.get(imsi);

120 return true;

121 }

122 else

123 {

124

125 return false;

126 }

127 }

128

129 /* Helper method to determine whether TMSI(8 digits)

130 or IMSI(15 digits) has been used as an identifier */

131

132 private boolean findLocalIMSI(String Identifier)

133 {

134

135 if (Identifier.length()== 8)

136 {

137 return setIMSI(Identifier);

138 }

139

140 else if (Identifier.length()== 15)

141 {

142 return slrQuery(Identifier);

143 }

144

145 else

146 {

147 return false;

148 }

149

150 }

151

152 /* Method carries out a full authentication involving

153 the subscribers home network */

154

155 private void FullAuthentication()

156 {

157 try

158 {

159 identifier = request[1];

160 xmac = request[2];

161 authCodePos = request[3];

162 if (!(findLocalIMSI(identifier)))

163 {

164 pw.println("I");

165 }

166 else

167 {

168

169 subData = hlrEnq.Authentication(rands, xmac, authCodePos,

170 timestamp, imsi, hlrId, snid);

171

172 mscCount++;

173 if (subData.equals("Time Check Failed"))

174 {

175 pw.println("D");

176 }

177

178 else if (subData.equals("Serving Network Failed"))

179 {

180 pw.println("B");

181 }

182

183 else

184 {

185 authData = subData.split(",");

186 challenge = authData[0]+","+authData[1];

187 xres = authData[2];

188 numCk = new BigInteger(authData[4],16);

189 numIk = new BigInteger(authData[3],16);

190 xorOp = numCk.xor(numIk);

191 tk = xorOp.toString(16);

192 pw.println("C,"+ challenge);

193 }

157

194 }

195 }

196 catch(Exception ex)

197 {

198 ex.printStackTrace();

199 }

200

201 }

202

203 // Authentication process carried out with no home network involvement

204

205 private void LocalAuthentication()

206 {

207 try

208 {

209 identifier = request[1];

210 xmac = request[2];

211 authCodePos = request[3];

212

213 if (!(findLocalIMSI(identifier)))

214 {

215 pw.println("I");

216 }

217 else

218 {

219 subData = vlrEnq.Authentication(rands, xmac, authCodePos,

220 timestamp, imsi, snid, tk);

221

222 if (subData.equals("Serving Network Failed"))

223 {

224 pw.println("B");

225 }

226

227 else

228 {

229 authData = subData.split(",");

230 challenge = authData[1];

231 xres = authData[2];

232 pw.println("C,"+ challenge);

233 }

234 }

235 }

236 catch(Exception ex)

237 {

238 ex.printStackTrace();

239 }

240

241 }

242

243 // Check the subscriber response to the challenge sent out

244

245 private void challengeResponse()

246 {

247 resp = request[1];

248 if (xres.equalsIgnoreCase(resp))

249 {

250

251 ck = authData[3];

252 ik = authData[4];

253 if (tmsiMap.containsKey(tmsi)) {

254 tmsiMap.remove(tmsi);

255 }

256 tmsi = Utils.toHex(srn.getNextSecureRandom(4));

257 newIdentity = tmsi +","+ nIMSI;

258 tmsiMap.put(tmsi, imsi);

259 hlrMap.put(imsi, hlrId);

260 pw.println("W," + newIdentity);

261

262 }

263 else

264 {

265 pw.println("Z,");

266 }

267 }

268

269

158

270 private void quit()throws IOException

271 {

272 operational = false;

273 pw.close();

274 os.close();

275 bf.close();

276 is.close();

277 socket.close();

278 System.out.println("...Streams closed down");

279 System.exit(0);

280 }

281

282 // Process requests received from the subscriber

283

284 private boolean handleCommand()throws IOException

285 {

286 operational = true;

287 String ch = bf.readLine();

288

289 request = ch.split(",");

290

291 command = request[0];

292

293 if (command.equals("Q"))

294 {

295 quit();

296 }

297

298 if (command.equals("A"))

299 {

300 authType = Integer.parseInt(request[4]);

301 if (authType == 0)

302 {

303 FullAuthentication();

304 }

305 else

306 {

307 LocalAuthentication();

308 }

309 }

310

311 if (command.equals("F"))

312 {

313 sendAuthData();

314 }

315

316 if (command.equals("X"))

317 {

318 challengeResponse();

319 }

320

321 return operational;

322

323 }

324

325 // Start up the Core Network

326

327 public void run()

328 {

329 try

330 {

331 System.out.println("The Core Network is now active .... ");

332 ServerSocket ss = new ServerSocket(4444);

333

334 //loop forever, accepting one subscriber at a time

335 while (true)

336 {

337 socket = ss.accept();

338 is = socket.getInputStream();

339 bf = new BufferedReader(new InputStreamReader(is));

340 os = socket.getOutputStream();

341 pw = new PrintWriter(os,FLUSH);

342 System.out.println("...Streams set up");

343

344 while (operational)

345 {

159

346 handleCommand();

347

348 }

349

350 }

351

352 }

353 catch (Exception ex)

354 {

355 ex.printStackTrace();

356 }

357

358 }

359

360

361 public static void main(String[] args) {

362

363 Thread CoreNetwork = new Thread(new MobileSwitchingCentre());

364 CoreNetwork.start();

365 }

366

367 }

368

369

AuthenticationCentre Class

package M801_Core_Network;

4

5 import java.math.*;

6 import java.util.*;

7

8

9 public class AuthenticationCentre {

10 private HashMap hlr45Auc;

11 private HashMap hlr17Auc;

12 private HashMap hlr21Auc;

13 private StringBuffer sb;

14 private static final String AUTH_KEY = "27AC85421DF469AF";

15 private String code;

16

17

18 public AuthenticationCentre()

19 {

20

21 hlr45Auc = new HashMap();

22 hlr17Auc = new HashMap();

23 hlr21Auc = new HashMap();

24

25 hlr45Auc.put("234335786932118","6d9e3c34a6960ae4b43fd5043b9ea13c");

26 hlr17Auc.put("234334286219354","62170867cd2e488dcb93c83dbbfc5e57");

27 hlr21Auc.put("234336438629325","affef583a770fbd0a0ee21c6091f2367");

28 hlr45Auc.put("234337552762894","5ce18a74cd8531454c3c9af0c68b570f");

29 hlr17Auc.put("234338484215051","6cf54798d7bdd5ef41c62cf8c4a53cfa");

30 hlr45Auc.put("234332566568921","8b1a5757744cc458b0dfdf118fd4b392");

31 hlr17Auc.put("234334871256924","5ec0687ed2866bac055eef2f6f06efcf");

32 hlr21Auc.put("234332589631471","7a4db82d1e2740b4a922188b96a26a33");

33 hlr45Auc.put("234332365417859","1835ebeaeec1aa8bcacace833a6724b3");

34 hlr17Auc.put("234332467319826","fee0aa149bfb08ef8a4cce2e1d965c44");

35 }

36

37

38

39 public String authPass (String authCode)

40 {

41 String[] data = authCode.split(":");

42 sb = new StringBuffer();

43

44 for(int i=0; i<=3; i++)

45 {

46 int index = Integer.parseInt(data[i]);

47 String stringCode = AUTH_KEY.substring(index, index+1);

48 sb.append(stringCode);

49 }

160

50 code = sb.toString();

51 return code;

52

53 }

54

55

56

57 public String findKi(String imsi, int hlrId)

58 {

59 String ki = "";

60 System.out.println("STAGE FOUR - IMSI = " +imsi+" HLR = "+hlrId);

61 switch(hlrId)

62 {

63

64 case 17: ki = (String) hlr17Auc.get(imsi);

65 break;

66

67 case 45: ki = (String) hlr45Auc.get(imsi);

68 break;

69

70 case 21: ki = (String) hlr21Auc.get(imsi);

71 break;

72

73 }

74 System.out.println("STAGE FIVE - KI = " +ki);

75 return ki;

76 }

77

78

79

80 }

81

82

ServiceLocationRegister Class

package M801_Core_Network;

3

4 import java.util.*;

5 import java.io.*;

6

7 /* This class simulates the functionality of the Service Location Register

8 * (SLR)in the core network. It is used as a subscriber look up to find

9 * which HLR is hosting the subscriber

10 */

11

12

13

14 public class ServiceLocationRegister {

15

16 private Map hlrTable, newIMSI, oldIMSI;

17 private String imsi, nImsi, oImsi, slrData, hlr;

18 private ArrayList imsiPool;

19

20 public ServiceLocationRegister()

21 {

22 //Set up the databases with some subscriber values.

23 hlrTable = new HashMap();

24 add("234335786932118","45");

25 add("234334286219354","17");

26 add("234336438629325","21");

27 add("234337552762894","45");

28 add("234338484215051","17");

29 add("234332566568921","45");

30 add("234334871256924","17");

31 add("234332589631471","21");

32 add("234332365417859","45");

33 add("234332467319826","17");

34

35 newIMSI = new HashMap();

36 newIMSI.put("234335786932118","234335786932118");

37 newIMSI.put("234334286219354","234334286219354");

38 newIMSI.put("234336438629325","234336438629325");

39 newIMSI.put("234337552762894","234337552762894");

161

40 newIMSI.put("234338484215051","234338484215051");

41 newIMSI.put("234332566568921","234332566568921");

42 newIMSI.put("234334871256924","234334871256924");

43 newIMSI.put("234332589631471","234332589631471");

44 newIMSI.put("234332365417859","234332365417859");

45 newIMSI.put("234332467319826","234332467319826");

46

47 oldIMSI = new HashMap();

48 oldIMSI.put("234335786932118","234335786932118");

49 oldIMSI.put("234334286219354","234334286219354");

50 oldIMSI.put("234336438629325","234336438629325");

51 oldIMSI.put("234337552762894","234337552762894");

52 oldIMSI.put("234338484215051","234338484215051");

53 oldIMSI.put("234332566568921","234332566568921");

54 oldIMSI.put("234334871256924","234334871256924");

55 oldIMSI.put("234332589631471","234332589631471");

56 oldIMSI.put("234332365417859","234332365417859");

57 oldIMSI.put("234332467319826","234332467319826");

58

59

60

61 // Set up initial IMSI pool with data

62

63 imsiPool = new ArrayList();

64

65 imsiPool.add("234332514657521");

66 imsiPool.add("234332845621589");

67 imsiPool.add("234337465235874");

68 imsiPool.add("234331285496345");

69 imsiPool.add("234335625813467");

70 imsiPool.add("234333215973121");

71 imsiPool.add("234332546774415");

72 imsiPool.add("234334291345496");

73 imsiPool.add("234334521222176");

74 imsiPool.add("234337418529634");

75 imsiPool.add("234332483876157");

76 imsiPool.add("234335578123578");

77 imsiPool.add("234334882875642");

78 imsiPool.add("234331764328987");

79 imsiPool.add("234331549742648");

80 imsiPool.add("234332976341579");

81 imsiPool.add("234339125743659");

82 imsiPool.add("234332154289654");

83 imsiPool.add("234334918625497");

84 imsiPool.add("234332323456784");

85 imsiPool.add("234332156985632");

86 imsiPool.add("234337795634895");

87 imsiPool.add("234331364789525");

88 imsiPool.add("234334526875687");

89 imsiPool.add("234334112556897");

90 imsiPool.add("234332124589651");

91 imsiPool.add("234332012358994");

92 imsiPool.add("234331658023587");

93 imsiPool.add("234332020256896");

94 imsiPool.add("234332587012581");

95

96

97 }

98

99 // Add a new subscriber to the database.

100

101 public void add(String imsi, String HLRID)

102 {

103 if(hlrTable.containsKey((String)imsi))

104 {

105 throw new IllegalArgumentException

106 ("This IMSI already exists in the database");

107

108 }else{

109 hlrTable.put(imsi, new String (HLRID));

110 }

111 }

112

113 //Delete a subscriber from the database

114

115 public void delete(String imsi)

162

116 {

117 hlrTable.remove(imsi);

118 }

119

120 /* Locate the subscribers IMSI by looking in the table of previously used

121 * IMSIs

122 */

123

124 public String findOldImsi(String imsi)

125 {

126 Map.Entry entry;

127

128 Iterator iter = oldIMSI.entrySet().iterator();

129 while (iter.hasNext())

130 {

131 entry = (Map.Entry) iter.next();

132 if (entry.getValue().equals(imsi))

133 {

134 oImsi = (String)entry.getKey();

135

136 }

137

138 }

139 return oImsi;

140 }

141

142 // Locate the subscribers IMSI by looking in the table of New IMSIs

143

144 public String findNewImsi(String imsi)

145 {

146 Map.Entry entry;

147

148 Iterator iter = newIMSI.entrySet().iterator();

149 while (iter.hasNext())

150 {

151 entry = (Map.Entry) iter.next();

152 if (entry.getValue().equals(imsi))

153 {

154 nImsi = (String)entry.getKey();

155

156 }

157

158 }

159 return nImsi;

160 }

161

162 /* Find whether the subscriber has identified themselves using the new

163 * or old IMSIs, find the subscribers HLR and assign a new IMSI

164 */

165 public String findSub(String imsiData)

166 {

167 slrData = "IMSI not found";

168 if (newIMSI.containsKey(imsiData))

169 {

170 imsi = (String) newIMSI.get(imsiData);

171 oImsi = findOldImsi(imsi);

172 oldIMSI.remove(oImsi);

173 if (!(oImsi.equals(imsi)))

174 {

175 imsiPool.add(oImsi);

176 }

177 oldIMSI.put(imsiData, imsi);

178 newIMSI.remove(imsiData);

179 nImsi = (String)imsiPool.get(0);

180 imsiPool.remove(nImsi);

181 newIMSI.put(nImsi, imsi);

182 hlr = (String) hlrTable.get(imsi);

183 slrData = imsi+":"+hlr+":"+nImsi;

184

185 }

186

187 else if (oldIMSI.containsKey(imsiData))

188 {

189

190 imsi = (String) oldIMSI.get(imsiData);

191 nImsi = findNewImsi(imsi);

163

192 hlr = (String) hlrTable.get(imsi);

193 slrData = imsi+":"+hlr+":"+nImsi;

194

195 }

196 return slrData;

197 }

198

199 }

200

201

Encryption Class

package M801_Mobile_Phone;

2

3 import java.security.*;

4 import javax.crypto.*;

5 import javax.crypto.spec.SecretKeySpec;

6 import java.math.*;

7

8 public class Encryption {

9 int ctLength;

10 int ptLength;

11 Cipher cipher;

12 SecretKeySpec key;

13

14

15 public byte[] encryptCipher(byte[]bytes, SecretKeySpec key)

16 throws Exception

17 {

18 cipher = Cipher.getInstance("blowfish/ECB/NoPadding", "BC");

19 byte[] cipherText = new byte[bytes.length];

20 System.out.println("got here!!!!");

21 cipher.init(Cipher.ENCRYPT_MODE, key);

22 ctLength = cipher.update(bytes, 0, bytes.length, cipherText, 0);

23 ctLength += cipher.doFinal(cipherText, ctLength);

24 return cipherText;

25 }

26

27 public byte[] encryptIntegrity(byte[]bytes, SecretKeySpec key)

28 throws Exception

29 {

30

31 cipher = Cipher.getInstance("DESede/ECB/NoPadding", "BC");

32 byte[] cipherText = new byte[bytes.length];

33 cipher.init(Cipher.ENCRYPT_MODE, key);

34 ctLength = cipher.update(bytes, 0, bytes.length, cipherText, 0);

35 ctLength += cipher.doFinal(cipherText, ctLength);

36 return cipherText;

37 }

38

39

40 public byte[] encryptMac(byte[]bytes, SecretKeySpec key)

41 throws Exception

42 {

43

44 cipher = Cipher.getInstance("AES/ECB/PKCS7Padding", "BC");

45 cipher.init(Cipher.ENCRYPT_MODE, key);

46 byte[] cipherText = new byte[cipher.getOutputSize(bytes.length)];

47 ctLength = cipher.update(bytes, 0, bytes.length, cipherText, 0);

48 ctLength += cipher.doFinal(cipherText, ctLength);

49 return cipherText;

50 }

51

52

53 public byte[] encryptXres(byte[]bytes, SecretKeySpec key)

54 throws Exception

55 {

56

57 cipher = Cipher.getInstance("AES/ECB/PKCS7Padding", "BC");

58 cipher.init(Cipher.ENCRYPT_MODE, key);

59 byte[] cipherText = new byte[cipher.getOutputSize(bytes.length)];

60 ctLength = cipher.update(bytes, 0, bytes.length, cipherText, 0);

61 ctLength += cipher.doFinal(cipherText, ctLength);

164

62 return cipherText;

63 }

64

65

66 public byte[] decrypt(byte[] cryptedBytes, SecretKeySpec key)

67 throws Exception

68 {

69 cipher = Cipher.getInstance("AES/ECB/NoPadding", "BC");

70 byte[] plainText = new byte[ctLength];

71 cipher.init(Cipher.DECRYPT_MODE, key);

72 ptLength = cipher.update(cryptedBytes, 0,cryptedBytes.length ,

plainText, 0);

73 ptLength += cipher.doFinal(plainText, ptLength);

74 return plainText;

75 }

76

77

78 }

79

80

Utils Class

package M801_Core_Network;

4 import java.math.*;

5

6 /* This class is based on the Utils class produced in

7 * Beginning Java Cryptography(Hook, 2005). The class

8 * is used to perform conversions for the main elements

9 */

10

11 public class Utils {

12

13

14 private static String digits = "0123456789abcdef";

15

16

17 public static String toHex(byte[] data, int length)

18 {

19 StringBuffer buf = new StringBuffer();

20

21 for (int i = 0; i != length; i++)

22 {

23 int v = data[i] & 0xff;

24

25 buf.append(digits.charAt(v >> 4));

26 buf.append(digits.charAt(v & 0xf));

27 }

28

29 return buf.toString();

30 }

31

32

33 public static String toHex(byte[] data)

34 {

35 return toHex(data, data.length);

36

37 }

38

39 public static int toInt(String hex)

40 {

41 int i = Integer.valueOf(hex, 16).intValue();

42 return i;

43

44 }

45

46 // Converts MACsn to a 64 bit output

47 public static String xmacsTrimming(String xmac)

48 {

49 String xmac1 = xmac.substring(0,16);

50 String xmac2 = xmac.substring(16,32);

51 String xmac3 = xmac.substring(32,48);

52 String xmac4 = xmac.substring(48,64);

53 String xmac5 = xmac.substring(64,80);

165

54 String xmac6 = xmac.substring(80,xmac.length());

55

56 BigInteger numX1 = new BigInteger(xmac1,16);

57 BigInteger numX2 = new BigInteger(xmac2,16);

58 BigInteger numX3 = new BigInteger(xmac3,16);

59 BigInteger numX4 = new BigInteger(xmac4,16);

60 BigInteger numX5 = new BigInteger(xmac5,16);

61 BigInteger numX6 = new BigInteger(xmac6,16);

62

63 BigInteger xorOp1 = numX1.xor(numX2);

64 BigInteger xorOp2 = xorOp1.xor(numX3);

65 BigInteger xorOp3 = xorOp2.xor(numX4);

66 BigInteger xorOp4 = xorOp3.xor(numX5);

67 BigInteger xorOp5 = xorOp4.xor(numX6);

68 return xorOp5.toString(16);

69 }

70

71 // Converts MACh to a 64 bit output

72 public static String xmachTrimming(String xmac)

73 {

74 String xmac1 = xmac.substring(0,16);

75 String xmac2 = xmac.substring(16,32);

76 String xmac3 = xmac.substring(32,48);

77 String xmac4 = xmac.substring(48,xmac.length());

78

79 BigInteger numX1 = new BigInteger(xmac1,16);

80 BigInteger numX2 = new BigInteger(xmac2,16);

81 BigInteger numX3 = new BigInteger(xmac3,16);

82 BigInteger numX4 = new BigInteger(xmac4,16);

83

84

85 BigInteger xorOp1 = numX1.xor(numX2);

86 BigInteger xorOp2 = xorOp1.xor(numX3);

87 BigInteger xorOp3 = xorOp2.xor(numX4);

88 return xorOp3.toString(16);

89 }

90

91 }

92

93

Secure Random Number Class

package M801_Core_Network;

4

5 import java.security.*;

6 import java.security.SecureRandom;

7

8 // This class is based on the class produced by Jason Weiss(Weiss, 2007).

9

10

11

12 public class SecureRandomNumber {

13

14

15 private SecureRandom sRand;

16

17

18 public byte [] getNextSecureRandom (int bits) {

19 try{

20

21 sRand = SecureRandom.getInstance("SHA1PRNG");

22

23

24 }catch (NoSuchAlgorithmException e) {

25

26 e.printStackTrace();

27 }

28 final byte [] bytes = new byte[bits];

29 sRand.nextBytes(bytes);

30 return bytes;

31 }

32

33

166

34 }

35

36

Visitor Location Register Class

1

2 package M801_Core_Network;

3

4 /* This class represents the Visitor Location Register (VLR)

5 * in the core network. This is a subsytem of the MSC and

6 * is used in this prototype to carry out local authentication

7 */

8

9

10 import javax.crypto.*;

11 import java.math.*;

12 import java.util.*;

13 import java.security.*;

14 import java.text.*;

15 import javax.crypto.spec.SecretKeySpec;

16 import java.io.*;

17

18

19 public class VisitorLocationRegister {

20 private HashMap vlrTmsi;

21 private SecureRandomNumber srn;

22 private Cryptography crypt;

23 private AuthenticationCentre auc;

24 private String xres, rand, code, secretkey, imsi;

25 private String ik, ck, xmach, xmacsn, xmac, xmacs;

26 private SecretKeySpec key;

27 private String secretKey;

28 private StringBuffer sb;

29

30

31 public VisitorLocationRegister()

32 {

33 srn = new SecureRandomNumber();

34 crypt = new Cryptography();

35 vlrTmsi = new HashMap();

36 vlrTmsi.put("6d9e3c34","234335786932118");

37 vlrTmsi.put("62170867","234334286219354");

38

39 }

40

41 // Check MACsn sent by the subscriber

42

43 public boolean MACsn(String rands, String xmac, String timestamp,

44 String imsi, String snid) throws Exception

45 {

46 byte[] Ki = new BigInteger(secretKey,16).toByteArray();

47 // byte[] Ki = secretKey.getBytes("UTF8");

48 key = new SecretKeySpec(Ki, "AES");

49 code = imsi+timestamp+rands+snid;

50 byte[] auData = new BigInteger(code, 16).toByteArray();

51 xmacs = Utils.toHex(crypt.encryptMac(auData, key));

52 xmacsn = Utils.xmacsTrimming(xmacs);

53 return (xmacsn.equals(xmac));

54 }

55

56 public byte[] cipherActivation(String ck,String Data) throws Exception

57 {

58 System.out.println("CK IS : "+ck);

59 byte[] newData = new BigInteger(Data, 16).toByteArray();

60 byte[] Kc = new BigInteger(ck, 16).toByteArray();

61 SecretKeySpec CK = new SecretKeySpec(Kc, "AES");

62 byte[] encryptedData = crypt.encryptData(newData, CK);

167

63 return encryptedData;

64

65 }

66

67

68 // Generate authentication code for mutual authentication

69

70 public String authPass (String authCode)

71 {

72 String[] data = authCode.split(":");

73 sb = new StringBuffer();

74

75 for(int i=0; i<=3; i++)

76 {

77 int position = Integer.parseInt(data[i]);

78 String stringCode = secretKey.substring(position-1, position);

79 sb.append(stringCode);

80 }

81 code = sb.toString();

82 return code;

83

84 }

85

86 // Generate local authentication vector

87

88 public String Authentication(String rands, String xmac, String authCode,

89 String timestamp, String imsi,String snid,

90 String tk) throws Exception

91 {

92 this.imsi = imsi;

93 this.xmac = xmac;

94 secretKey = tk;

95

96 if (MACsn(rands, xmac, timestamp, imsi, snid))

97 {

98 byte[] Ki = new BigInteger(secretKey,16).toByteArray();

99 key = new SecretKeySpec(Ki, "AES");

100 byte[] randS = rands.getBytes("UTF8");

101 String xresult = Utils.toHex(crypt.encryptXres(randS, key));

102 xres = Utils.xmacsTrimming(xresult);

103 String data = rands+authPass(authCode)+timestamp;

104 byte[] message = new BigInteger(data,16).toByteArray();

105 String xmachn = Utils.toHex(crypt.encryptMac(message, key));

106 xmach = Utils.xmachTrimming(xmachn);

107 ck = Utils.toHex(crypt.encryptCipher(randS, key)).substring(1,32);

108 ik = Utils.toHex(crypt.encryptIntegrity(randS, key)).substring(1,32);

109 String auData = rands+","+xmach+","+xres+","+ik+","+ck;

110 return auData;

111 }

112 else

113 {

114 String failureReport = "Serving Network Failed";

115 return failureReport;

116 }

117

118

119 }

120

121

122 }

123

124