124
An Ontology for Generic Wireless Authentication 1 Declaration Herewith, I declare that I have written this thesis myself and no other sources than listed in the references have been used. Asma Alazeib Stuttgart, 07.October.2005

GSM Authentication

  • Upload
    garry54

  • View
    4.625

  • Download
    1

Embed Size (px)

Citation preview

Page 1: GSM Authentication

An Ontology for Generic Wireless Authentication 1

Declaration

Herewith, I declare that I have written this thesis myself and no other sources than listed

in the references have been used.

Asma Alazeib Stuttgart, 07.October.2005

Page 2: GSM Authentication

An Ontology for Generic Wireless Authentication 2

Acknowledgements

I would like to thank first and foremost my supervisors in Alcatel SEL AG, Dr. Stephan

Rupp and Andreas Diehl for all their help, support, follow ups and encouragement. I

thank them for the weekly meetings held, for all the guidance and assistance and for all

the times they were there whenever I needed advice and support.

I would also like to thank Prof. Klaus Schünemann and Prof. Wolfgang Meyer for

supervising me at the Hamburg University of Technology during my master thesis and

for their help and support.

Special thanks also goes to Franz Josef Banet and Matthias Duspiva who were always

there to answer my questions, spent several hours clarifying my doubts, and whom

supported me throughout my thesis.

Never ending thanks also goes to the former Telematics group of Alcatel SEL AG, now

the mm-lab company for being my entrance point in Alcatel and for making the

company feel like home, for all the moral support, encouragement and for always being

there for me in every case. Special thanks go to Lothar Krank, Ronald Prestin, Martin

Geiger, Bernd Herrmann, Michael Meiser, Wolfgang Schäffer, Michael Koch, Horst

Idler, Gerald Sander, Claus Hirdes, Andreas Streit and Sandra Steege.

Warm wishes go to all my friends that I’ve encountered during my stay in Germany, each

person has made a positive influence in my life and in very special and different ways. I

thank them for the making me see life from other aspects and whom have greatly

contributed to the person I am today.

Last but not least, I would like to thank all my family members for believing in me and

for their encouragement.

Page 3: GSM Authentication

An Ontology for Generic Wireless Authentication 3

Table of Contents

Declaration......................................................................................................................................1

Acknowledgements........................................................................................................................2

1 Introduction...............................................................................................................................10

1.1 Restructuring Telecommunication Networks...............................................................12

1.1.1 Physical Consolidation of Subscriber Data ...........................................................13

1.1.2 Logical Consolidation of Subscriber Data .............................................................13

1.1.3 Harmonization of Interfaces....................................................................................13

2 Authentication in Wireless Networks ....................................................................................16

2.1 Security in wireless networks...........................................................................................16

2.2 Introduction to Authentication.......................................................................................17

2.3 Introduction to GSM networks ......................................................................................18

2.3.1 GSM Network Components....................................................................................19

2.3.1.1 Radio Subsystem ................................................................................................19

2.3.1.2 Base Station Subsystem.....................................................................................19

2.3.1.3 Network and Switching Subsystem.................................................................20

2.3.2 Visited Access/Core Network, Operator Home Network .................................21

2.3.3 Numbers and Identities ............................................................................................21

2.3.3.1 International Mobile Subscriber Identity .......................................................21

2.3.3.2 Mobile Subscriber Integrated Services Digital Network Number..............22

2.4 Security in GSM Networks..............................................................................................24

2.4.1 GSM Authentication .................................................................................................24

2.4.2 Security Algorithms in GSM....................................................................................26

2.4.2.1 A3 Algorithm......................................................................................................26

2.4.2.2 A5 Algorithm......................................................................................................27

2.4.2.3 A8 Algorithm......................................................................................................27

2.5 Introduction to UMTS networks....................................................................................28

2.5.1 UMTS Network Components .................................................................................29

2.5.1.1 User Equipment.................................................................................................29

2.5.1.2 UMTS Terrestrial Radio Access Network .....................................................29

2.5.1.3 Core Network.....................................................................................................30

2.6 Security in UMTS networks.............................................................................................31

2.6.1 UMTS Authentication ..............................................................................................32

2.6.1.1 UMTS Authentication Vector..........................................................................34

Page 4: GSM Authentication

An Ontology for Generic Wireless Authentication 4

2.6.1.2 USIM Authentication ........................................................................................36

2.6.2 Security Algorithms in UMTS .................................................................................37

2.7 Introduction into the Internet Protocol Multimedia Sub-System in UMTS

networks....................................................................................................................................38

2.7.1 Identities in the IMS system.....................................................................................40

2.7.1.1 Private User Identities .......................................................................................40

2.7.1.2 Public User Identities ........................................................................................40

2.7.1.3 Public Service Identities ....................................................................................41

2.8 Introduction to Wireless Local Area Networks............................................................42

2.9 Security in WLAN networks ...........................................................................................43

2.9.1 802.11 ..........................................................................................................................43

2.9.2 Wired Equivalent Privacy.........................................................................................43

2.9.3 Wi-Fi Protected Access ............................................................................................44

2.10 WLAN Security Architecture ........................................................................................44

2.10.1 802.1X.......................................................................................................................44

2.10.2 Authentication, Authorization and Accounting Server .....................................46

2.10.3 Certificate Based Authentication...........................................................................47

2.10.3.1 Public Key Infrastructure ...............................................................................47

2.10.4 Password Based Authentication............................................................................48

2.10.5 Extensible Authentication Protocol .....................................................................48

2.10.5.1 Lightweight Extensible Authentication Protocol........................................49

2.10.5.2 EAP Transport Layer Security.......................................................................49

2.10.5.3 Protected Extensible Authentication Protocol............................................50

2.10.5.4 EAP- Subscriber Identity Module.................................................................51

3 Ontologies and the Semantic Web.........................................................................................55

3.1 The Semantic Web ............................................................................................................55

3.2 Ontologies ..........................................................................................................................56

3.2.1 Origin ..........................................................................................................................56

3.2.2 Definition....................................................................................................................57

3.2.2.1 In Philosophy .....................................................................................................57

3.2.2.2 In Artificial Intelligence ....................................................................................57

3.2.3 Ontology Approaches...............................................................................................58

3.2.3.1 Description Logics.............................................................................................58

3.2.3.2 Frame-based .......................................................................................................58

Page 5: GSM Authentication

An Ontology for Generic Wireless Authentication 5

3.2.3.3 Predicate Logic...................................................................................................59

3.2.4 The Web Ontology Language..................................................................................59

3.2.4.1 OWL Lite ............................................................................................................60

3.2.4.2 OWL DL.............................................................................................................60

3.2.4.3 OWL Full ............................................................................................................61

3.2.5 OWL Language Constructs .....................................................................................61

3.2.5.1 Classes..................................................................................................................61

3.2.5.2 Properties ............................................................................................................62

3.2.5.3 Operators ............................................................................................................65

3.2.6 Ontology Tools..........................................................................................................66

3.2.6.1 Protégé.................................................................................................................66

3.2.6.2 RenamedABox and Concept Expression Reasoner Professional...............66

3.2.6.3 Graphical Visualization .....................................................................................67

3.2.7 Protégé-OWL Concepts ...........................................................................................67

3.2.8 Ontology Development............................................................................................68

3.2.8.1 Why Develop an Ontology ..............................................................................68

3.2.8.2 Steps in Developing an Ontology ...................................................................69

4 An Ontology for Generic Wireless Authentication.............................................................72

4.1 Class Overview ..................................................................................................................72

4.2 Ontology Classes and Subclasses....................................................................................73

4.2.1 The Algorithm class ..................................................................................................73

4.2.2 The AuthenticationMethod class ............................................................................74

4.2.3 The AuthenticationType class .................................................................................74

4.2.4 The Certificate class ..................................................................................................75

4.2.5 The CertificateComponent class .............................................................................75

4.2.6 The Code class ...........................................................................................................76

4.2.7 The DataBase class....................................................................................................76

4.2.8 The Identity class.......................................................................................................76

4.2.9 The Key class .............................................................................................................77

4.2.10 The Network class...................................................................................................78

4.2.11 The Number Class ..................................................................................................78

4.2.12 The Service class......................................................................................................79

4.2.13 The UserData class..................................................................................................80

4.2.14 The Subscriber class................................................................................................81

Page 6: GSM Authentication

An Ontology for Generic Wireless Authentication 6

4.3 Disjoint Classes..................................................................................................................81

4.3.1 The Algorithm class disjoints ..................................................................................82

4.3.2 The AuthenticationMethod class disjoints ............................................................82

4.3.2.1 The EAP-SIM subclass .....................................................................................82

4.3.2.2 The EAP-TLS subclass .....................................................................................83

4.3.2.3 The LEAP subclass ...........................................................................................83

4.3.2.4 The PEAP subclass ...........................................................................................83

4.3.3 The AuthenticationType class disjoints .................................................................84

4.3.3.1 The CertificateBased subclass ..........................................................................84

4.3.3.2 The ChallengeResponse subclass ....................................................................84

4.3.3.3 The MutualAuthentication subclass................................................................84

4.3.3.4 The NetworkAuthentication subclass.............................................................84

4.3.3.5 The PasswordBased subclass ...........................................................................84

4.3.3.6 The UserAuthentication subclass ....................................................................85

4.3.4 The Certificate class disjoints...................................................................................85

4.3.5 The CertificateComponent class disjoints .............................................................85

4.3.5.1 The IssuerName, SerialNumber, Signature, Subject, ValidFrom, ValidTo

and PublicKey subclasses ..............................................................................................85

4.3.5.2 The SignatureAlgorithm subclass ....................................................................85

4.3.6 The Code class disjoints ...........................................................................................86

4.3.7 The Database class disjoints ....................................................................................86

4.3.8 The Identity class disjoints .......................................................................................86

4.3.9 The Key class disjoints..............................................................................................86

4.3.9.1 The DerivedKey subclass .................................................................................86

4.3.9.2 The GeneratedKey subclass .............................................................................86

4.3.9.3 The StaticKey subclass......................................................................................87

4.3.10 The Network class disjoints...................................................................................87

4.3.11 The Number class disjoints....................................................................................87

4.3.12 The Service class disjoints ......................................................................................87

4.3.12.1 The BasicService subclass...............................................................................87

4.3.12.2 The SupplementaryService subclass..............................................................87

4.3.12.3 The MultimediaService subclass ....................................................................87

4.3.13 The UserData class disjoints..................................................................................88

4.4 Inconsistencies from Disjoint classes.............................................................................88

Page 7: GSM Authentication

An Ontology for Generic Wireless Authentication 7

4.5 Class Properties .................................................................................................................89

4.5.1 hasIdentity ↔ isIdentityOf .......................................................................................89

4.5.2 hasNetworkIdentity ↔ isNetworkIdentityOf.......................................................89

4.5.3 hasUserName ↔ isUserNameOf ...........................................................................89

4.5.4 hasAuthenticationMethod ↔ isAuthenticationMethodOf ..................................89

4.5.5 hasAuthenticationType ↔ isAuthenticationTypeOf ............................................90

4.5.6 hasCertificate ↔ isCertificateOf ..............................................................................90

4.5.7 hasPassword ↔ isPasswordOf .................................................................................90

4.5.8 hasBasicService ↔ isBasicServiceOf .......................................................................90

4.5.9 hasSupplementaryService ↔ isSupplementaryServiceOf .....................................90

4.5.10 hasDatabase ↔ isDatabaseOf ................................................................................90

4.5.11 hasChallenge ↔ isChallengeOf .............................................................................91

4.5.12 hasSecretKey ↔ isSecretKeyOf.............................................................................91

4.5.13 hasExpectedResponse ↔ isExpectedResponseOf .............................................91

4.5.14 hasTriplets ↔ isTripletsOf .....................................................................................91

4.5.15 hasInput ↔ isInputOf.............................................................................................91

4.5.16 hasOutput ↔ isOutputOf.......................................................................................91

4.5.17 hasNumber ↔ isNumberOf...................................................................................92

4.5.18 hasSubscriber ↔ isSubscriberOf ...........................................................................92

4.5.19 Stores ↔ isStoredIn .................................................................................................92

4.5.20 hasAlgorithm ↔ isAlgorithmOf ...........................................................................92

4.6 Identification of a new is-a relationship.........................................................................92

4.7 Initial ontology tests and reasoning................................................................................93

Page 8: GSM Authentication

An Ontology for Generic Wireless Authentication 8

4.8 Property Restrictions and Defining Classes ..................................................................94

4.8.1 Restrictions defining the f1 class.............................................................................94

4.8.2 Restrictions defining the EAP-SIM class...............................................................96

4.8.3 Restrictions defining the Subscriber class..............................................................98

4.8.4 Restrictions defining the IMSI class .......................................................................99

4.9 Asserted and Inferred Hierarchy.................................................................................. 101

5 Installation and Testing......................................................................................................... 102

5.1 Installation Guidelines................................................................................................... 102

5.2 Loading the Ontology ................................................................................................... 102

5.3 Encountered Problems.................................................................................................. 103

5.3.1 Enumerated Classes ............................................................................................... 103

5.3.2 Defining values for properties instead of individuals........................................ 104

5.3.3 allValuesFrom, someValuesFrom and Disjoint classes .................................... 105

5.3.4 Defining Cardinalities ............................................................................................ 106

6 Summary and Conclusions ................................................................................................... 107

6.1 Summary.......................................................................................................................... 107

6.2 Further research.............................................................................................................. 108

6.3 Areas of application ....................................................................................................... 109

References .................................................................................................................................. 110

Abbreviations............................................................................................................................. 116

Appendix A................................................................................................................................ 120

Appendix B ................................................................................................................................ 123

Page 9: GSM Authentication

An Ontology for Generic Wireless Authentication 9

Table of Figures

Figure 1: Current status of telecommunication networks......................................................11

Figure 2: Distributed Subscriber Data ......................................................................................12

Figure 3: Physical and Logical Consolidation of Data............................................................14

Figure 4: GSM Network Architecture ......................................................................................18

Figure 5: IMSI Number Format ................................................................................................22

Figure 6: MSISDN Number Format.........................................................................................23

Figure 7: Authentication in GSM Networks............................................................................24

Figure 8: UMTS Network Architecture....................................................................................28

Figure 9: Authentication in UMTS Networks .........................................................................32

Figure 10: UMTS Authentication Vector .................................................................................34

Figure 11: USIM Authentication ...............................................................................................36

Figure 12: IMS Subsystem Architecture ...................................................................................38

Figure 13: WLAN Overview ......................................................................................................42

Figure 14: WLAN Security Architecture ..................................................................................44

Figure 15: EAP-SIM Architecture .............................................................................................51

Figure 16: EAP-SIM Authentication.........................................................................................53

Figure 17: Overview of Asserted Ontology Hierarchy...........................................................72

Figure 18: Disjoint Classes..........................................................................................................81

Figure 19: Incorrect disjoint definition - Inconsistent class ..................................................88

Figure 20: Ontology tests and reasoning results......................................................................93

Figure 21: f1 Class Restrictions..................................................................................................94

Figure 22: EAP-SIM Class Restrictions....................................................................................96

Figure 23: Subscriber Class Restrictions...................................................................................98

Figure 24: IMSI Class Restrictions ............................................................................................99

Figure 25: Asserted and Inferred Hierarchy.......................................................................... 101

Figure 26: Enumerated Classes and OWL-FULL Error..................................................... 104

Figure 27: Defining a value for an Object Property - OWL FULL Error ....................... 105

Figure 28: Integration of Future domains ............................................................................. 109

Page 10: GSM Authentication

An Ontology for Generic Wireless Authentication 10

1 Introduction

The increase in network complexity in telecommunication systems has given rise to the

need of restructuring telecommunication networks.

Today networks are structured in such a way, that the introduction of new network

elements and network services significantly increase the complexity of networks for

network operators. Thus making it difficult to deploy and integrate new services and

domains into existing networks, as well as complicating the maintenance and

management of such networks.

Examples for telecommunication networks are mobile and wireless networks. The

original architecture for mobile networks was based on supporting the mobility of phone

calls. The extension of such networks and the difficulty of maintaining such extensions

were not put into consideration while designing these networks.

Today several network domains exist in mobile and wireless networks. Each domain

brings along with it new services, features and applications. And each domain requires

the introduction of new network elements, thus further contributing to the complexity of

networks.

Each network element requires its own independent set of services, applications and

subscriber data. As well as interfaces and protocols to communicate with each other.

Subscriber data is required for the new network elements existing within the network,

which is sometimes redundant across the different nodes. Each network node owns its

own subscriber profile (data), which is sometimes replicated and distributed across the

network. This complicates access to data and makes it impossible to obtain and maintain

a complete profile of a specific network subscriber, since all data related to a subscriber is

distributed along the network. Managing the network elements becomes difficult and

operating expenses involved for network planning and maintenance of such networks

also increases.

Another problem that arises from the current architecture of networks today is the

integration of several networks and domains (e.g. the integration of UMTS and WLAN

networks). The current architecture was not designed to support the integration of new

networks and services. The never-ending extensions of these networks will only make it

impossible in the future to maintain such networks.

Page 11: GSM Authentication

An Ontology for Generic Wireless Authentication 11

The following points summarize the problems that arise from the way

telecommunication networks are structured today:

• Several domains

• Several network elements within each domain

• Inaccessible data due to vendor specific systems for the network elements

• Separate set of subscriber data for each network element

• Redundant subscriber data across the network elements

• Several protocols and interfaces to communicate between the nodes

• Increased complexity

• Increased expenses

The following figure illustrates the current status in telecommunication networks today:

Figure 1: Current status of telecommunication networks

Domain 4

Node 1

Node 2

Node 3

Node 4

Domain 2

Node 1

Node 2

Node 3

Node 4

Domain 3

Node 1

Node 2

Node 3

Node 4

Domain 1

Node 1

Node 2

Node 3

Node 4

For the purpose of this thesis the restructuring of the GSM, UMTS and WLAN domains

are considered. In particular the authentication specific data related to a certain

subscriber is modelled for the next generation profile register.

Page 12: GSM Authentication

An Ontology for Generic Wireless Authentication 12

1.1 Restructuring Telecommunication Networks

Next Generation Networks (NGNs) are introduced in this thesis as a solution to the

previously mentioned problems. The introduction of such networks reduces the

complexity of current networks, but only to a certain extent.

The concept behind a NGN is the separation of data from applications. Subscriber data

is one of the most vital components of a network, and in today’s networks this data is

not centrally accessible. Data today is not separated from the applications they belong to

and this data is locally stored, distributed and inaccessible by other applications. Such an

arrangement also causes the increase of operating and maintenance efforts and costs.

A NGN solves these problems by providing a common storage for subscriber data ,

which is accessible to all applications. This common profile store is also referred to as the

Next Generation Profile Register (NGPR). It simplifies data management and the

interfaces needed for applications to access the data; it also enables the re-use of data

among the various applications.

The following figure illustrates the distribution of subscriber data among the three

network domains:

Figure 2: Distributed Subscriber Data

Page 13: GSM Authentication

An Ontology for Generic Wireless Authentication 13

Three approaches considered for the simplification of telecommunication networks

today, and that complement each other are the following:

• Physical Consolidation of Subscriber Data

• Logical Consolidation of Subscriber Data

• Harmonisation of Interfaces

1.1.1 Physical Consolidation of Subscriber Data

Physical consolidation of data enables better data management, by storing data belonging

to a subscriber in dedicated data servers. Data is stored in one physical location and the

data servers can then be accessed via a common data interface. This process simplifies

the integration of new application servers and network management, enables faster

introduction of new services, and enables direct access to the data by different systems

and applications.

1.1.2 Logical Consolidation of Subscriber Data

Logical consolidation of subscriber data provides a common data model that provides

meaning to subscriber data, and that describes this data. It solves the problem of the

multiple independent subscriber sets of a certain subscriber, which are distributed across

the network. It also associates subscriber data to the subscriber and provides the

definition of data objects. The logical model can be used in conjunction with a common

data interface.

1.1.3 Harmonization of Interfaces

The number of interfaces and protocols needed to communicate between network

nodes, increases with the increase of new network elements and new functions. This

further complicates the integration of new services and functions within a network. A

solution to this is to isolate interfaces from the applications and third party applications,

and to provide a common standard interface, instead of several interfaces and protocols.

The following figure illustrates the logical and physical consolidation of subscriber data

for the three mentioned domains:

Page 14: GSM Authentication

An Ontology for Generic Wireless Authentication 14

WLAN Subscriber Data

Figure 3: Physical and Logical Consolidation of Data

This thesis concentrates on the Logical Consolidation of Subscriber data, in specific

authentication specific data for GSM, UMTS and WLAN networks.

In order to create a logical model for subscriber data it is important to choose an

appropriate modelling language for modelling the data stored in the subscriber profiles

[61].

Relational models are not sufficient to describe the data for the logical model, the

Unified Modelling Language (UML) focuses on the operational properties and run time

data, the Extensible Markup Language (XML) and XML schema provide and define the

structure of data, the Resource Description Framework (RDF) and RDF Schema define

the data model for objects and the relationship between objects. It also provides a

terminology for expressing classes and properties. The appropriate method evaluated for

modelling the logical data was using the Semantic Web to provide meaning for the data.

The most suitable language evaluated for the description of the data was the Web

Ontology Language (OWL), which supports sharing and distribution of knowledge, a

richer vocabulary for modelling and which focuses on the structural properties of a

domain [49][52].

The thesis is organized in the following manner: this chapter provides an introduction to

the thesis and the motivation behind the work performed. Chapter two provides an

overview of GSM, UMTS and WLAN networks. The main focus of this chapter is the

UMTS Subscriber Data GSM Subscriber DataLogical Consolidation of Data

Physical Consolidation of Data

Page 15: GSM Authentication

An Ontology for Generic Wireless Authentication 15

authentication procedures for each network. Chapter three describes the Semantic Web,

ontologies (a knowledge based used to model the data), the Web Ontology Language and

the tools needed to model an ontology. Chapter four describes the ontology created with

the Protégé Tool. The ontology provides the definition of classes, the properties and the

relationships between the classes. Chapter five describes the installation requirements

needed to create the ontology, how the ontology can be loaded and a list of errors during

testing the consistency of the ontology. The summary of the work achieved, the

conclusions and open issues are described in Chapter 6.

Page 16: GSM Authentication

An Ontology for Generic Wireless Authentication 16

2 Authentication in Wireless Networks

2.1 Security in wireless networks

Security has become an important issue in current mobile and wireless networks. As the

security measures for such networks increase, the tools and techniques used to attack

such networks also increases.

Wireless communications security in simple terms, is the procedures or methods used for

protecting the communication between certain entities. (An entity could be a user or a

device requesting network access). Protection mechanisms are used to protect the entity

from any third party attacks, such as impersonating an identity, revealing a specific

identity, data-hijacking or data modification, eavesdropping and so forth.

Dedicated technologies for securing data and communication are required in wireless

networks, which vary according to the type of wireless technology deployed. Security in

mobile and wireless networks covers various issues, from authentication of a user

accessing a certain network, to data encryption and data integrity. Thus three major

aspects are considered in securing wireless networks: [5]

• Access control (Authentication)

• Confidentiality

• Anonymity [5]

Authentication is used to prove the identity of a certain entity requesting access to a

network. This is used so that the network operator is able to verify that the mobile

subscriber in the case of GSM and UMTS networks is really who he/she claims to be.

This reduces the possibility for mobile identity impersonation [6] [7].

Encryption is used to ensure the confidentiality of data. Data integrity guarantees that

the data is not modified or destroyed in any way, thus sensitive signalling information

and data are protected against eavesdropping attacks.

Anonymity is another security aspect that protects user identity, making it hard to track

the whereabouts of a certain user. Anonymity is achieved using temporary identities [6].

Page 17: GSM Authentication

An Ontology for Generic Wireless Authentication 17

The scope of this thesis only addresses the authentication procedures of mobile and

wireless networks, specifically GSM, UMTS and WLAN networks. Other security aspects

are not within this scope.

2.2 Introduction to Authentication

Authentication is the process of uniquely proving an identity to a certain service, network

or device and the verification of the given identity. Upon successful identity verification,

access to certain services, networks or devices are granted.

The kind of access and services granted depends on the privileges given to the specific

entity requesting authentication. In the case the identity is not proven (unsuccessful

authentication), no access is granted to the entity requesting access.

The simple form of authentication is providing a user name and password, which is

mainly the case in internet based authentication (e.g. email, online shopping, etc…) and

in some wireless based networks. However, different types of authentication exist

depending on the complexity of a certain system. Dedicated systems require a complex

procedure of authentication involving the use of secret keys, tokens, certain credentials,

digital certificates or signatures, complex algorithms and encryption methods and more

[7] [8].

Several authentication methods exist, depending on the technology used and the type of

information or services requiring access.

In the following, the authentication procedures of GSM, UMTS and WLAN networks

are discussed in detail.

Page 18: GSM Authentication

An Ontology for Generic Wireless Authentication 18

2.3 Introduction to GSM networks

The Global System for Mobile Communication (GSM) is a second generation (2G)

network and is the largest existing 2G network. Second generation refers to the fact that

the system uses digital signals in contrast to first generation networks, where analogue

signals were used [5].

The GSM network comprises of several network components that interact and function

with each other. For the purpose of this thesis, only the components involved in the

authentication process of GSM networks will be described and illustrated.

The following figure illustrates a general overview of the GSM authentication specific

network architecture. (All other elements not related to authentication are not illustrated

or addressed):

BSS

RSS NSS

BTS

MS BSC

Visited Access Network Visited Core Network Home Network

AuCHLRVLRMSC

Mobile Device

Figure 4: GSM Network Architecture

The GSM network comprises of three subsystems, namely the Radio Subsystem (RSS),

the Network and Switching Subsystem (NSS) and the Operation Subsystem (OSS) [1] [4].

The OSS is not discussed in this thesis.

Page 19: GSM Authentication

An Ontology for Generic Wireless Authentication 19

2.3.1 GSM Network Components

2.3.1.1 Radio Subsystem

The RSS [9] [4] deals with all the radio aspects of a network and is responsible for the

following components it comprises:

2.3.1.1.1 Mobile Station

The Mobile Station (MS) [3] [4] consists of two major components:

2.3.1.1.1.1 Mobile Equipment

The Mobile Equipment (ME) is the actual mobile device a user uses to establish calls and

other telephony services. The ME communicates with the radio channel and provides

various services to the user of the mobile device.

2.3.1.1.1.2 Subscriber Identity Module

The Subscriber Identity Module (SIM) [3] is located inside the ME and contains

subscriber specific data. This data is used for identifying a subscriber to the network via

the International Mobile Subscriber Identity (IMSI). Authentication specific data is also

stored inside the SIM (e.g. algorithms, secret key), which are later used for key generation

[4] [6].

Two security services are implemented for the SIM card. The first security mechanism

for the SIM is access control, which controls a user from accessing the card and the

information and services provided upon card access. This is provided via a secret

Personal Identification Number (PIN), which the user has to enter before gaining access

to the SIM. The second security mechanism provided is the network challenge and

response mechanism described in section (2.4.1).

2.3.1.2 Base Station Subsystem

The Base Station Subsystem (BSS) [1] [3] [4] is responsible for all radio functions and

comprises of the Base Station Transceiver (BTS) and the Base Station Controller (BSC).

These two components together support the radio interface. The responsibilities of the

BSS are then assigned to the following two components:

Page 20: GSM Authentication

An Ontology for Generic Wireless Authentication 20

2.3.1.2.1 Base Transceiver Station

The Base Transceiver Station (BTS) takes care of the communication with the mobile

station, and is responsible for radio specific functions (sending and receiving) [4]

2.3.1.2.1 Base Station Controller

The Base Station Controller (BSC) is responsible for the switching between several BTSs,

and for the switching of radio channels. The BSC provides the necessary control

functions and physical links between the Network Subsystem (NSS), via the Mobile

Switching Center (MSC) and the BTS [1] [3] [4].

2.3.1.3 Network and Switching Subsystem

The NSS [3][4] comprises of the Mobile Switching Center (MSC), the Home Location

Register (HLR) and the Visitor Location Register (VLR). The NSS provides switching

services between GSM and external networks, and maintains the location registers

needed to manage and administer subscribers.

2.3.1.3.1 Mobile Switching Center

The Mobile Switching Center (MSC) is the switching node in the NSS that controls all

MS connections. It provides telephony switching services to fixed and mobile networks.

It links the NSS to the RSS via the BSC. Several BSCs can belong to a single MSC [1] [3]

[4].

2.3.1.3.2 Home Location Register

The Home Location Register (HLR) is the main subscriber profile register, and contains

all data related to a mobile subscriber. This data includes but is not limited to the

following: the mobile subscriber’s identity, represented as the International Mobile

Subscriber Identity (IMSI) (also stored in the SIM card), administrational information,

service subscription and service specific data and location information [1] [2] [3] [4].

2.3.1.3.3 Visitor Location Register

The Visitor Location Register (VLR) is a subscriber profile containing temporary

information, and is distributed in the network according to geographical locations. The

VLR along with the MSC are responsible for handling mobile subscribers visiting an area

Page 21: GSM Authentication

An Ontology for Generic Wireless Authentication 21

outside their home network. Certain administrational data is replicated in the VLR from

the HLR in order to provide service provisioning and call control. Information about the

visiting subscriber is retrieved from the HLR and stored in the VLR as a temporary

record [1] [2] [3] [4].

2.3.1.3.4 Authentication Center)

The Authentication Center (AuC) is a register that is logically part of the HLR.

Authentication specific data for a given subscriber is stored in the AuC. It is responsible

for storing the secret key of a subscriber (section 2.4.1). Other tasks of the AuC include

the generation of authentication parameters needed for authentication and encryption,

proving the identity of a subscriber and providing protection mechanisms for a

subscriber’s SIM card [1] [3] [4].

2.3.2 Visited Access/Core Network, Operator Home Network

The Visited Access Network is the radio network accessed by the mobile station. Access

is accomplished via the BSS.

The Visited Core Network is the switching part of the network, and is a network other

than the home network the subscriber is registered at. Visited Core Networks can be

located at various national or international locations. The MSC and VLR reside at this

network [6].

The Operator Home Network is the original network the mobile subscriber is registered

at. The HLR and AuC reside in this network.

2.3.3 Numbers and Identities

2.3.3.1 International Mobile Subscriber Identity

The International Mobile Subscriber Identity (IMSI) is a unique 15 digit identifier for a

mobile subscriber. It is stored in the SIM card of the mobile station, and is assigned to a

mobile subscriber at the time of subscription. It is used to identify a subscriber to a given

network (i.e. GSM, UMTS networks). The main purpose of the IMSI is to allocate

International Mobile Station Identities (INMSI) to stations. Mobile subscribers do not

have access to this number or have any knowledge of it. Although this number is stored

in the SIM card, it cannot be reached via a telephone call. Thus, the number is not made

public.

Page 22: GSM Authentication

An Ontology for Generic Wireless Authentication 22

The IMSI is made up of three codes:

• Mobile Country Code (MCC)

• Mobile Network Code (MNC) – 2 digits

• Mobile Station Identification Number (MSIN) – 10 digits

o HLR-Number

o Subscriber Number (SN)

MCC MNC MSIN

Figure 5: IMSI Number Format

The Mobile Country Code is a three digit code, specifying a list of predefined mobile

country codes that identify a mobile station in mobile networks. The MCC for Germany,

for example is 262 and each country has its own respective MCC.

The Mobile Network Code is the code, which identifies the home network of the mobile

subscriber. E.g. in Germany the codes 01, 02 and 03 are used to identify the T-Mobile,

Vodafone and E-Plus networks respectively. This code is 2 digits in Europe and 3 in

North America.

The Mobile Station Identification Number is a unique identifier, consisting of 10 digits

that identify a mobile subscriber to the network. The MSIN consists of two parts, the

first part represents the logical HLR address (HLR-Number) and consists of two digits

and the second part is an identifier representing the subscriber number (SN) [2] [10] [11].

2.3.3.2 Mobile Subscriber Integrated Services Digital Network Number

The Mobile Subscriber Integrated Services Digital Network Number (MSISDN) is the

mobile subscriber’s telephone number, which is associated with the IMSI. Several

MSISDN numbers can be assigned to a single IMSI and are also stored on the SIM card.

Together the IMSI and MSISDN are used for call setup and call routing.

The MSISDN is made up of the following codes:

• Country Code (CC)

Page 23: GSM Authentication

An Ontology for Generic Wireless Authentication 23

• National Destination Code (NDC)

• Subscriber Number (SN)

o HLR-Number (HLR#)

o Individual Subscriber Number (ISN)

CC NDC SN(HLR# + ISN)

Figure 6: MSISDN Number Format

The CC is consists of 1 – 3 digits and represents the code for the country. The NDC is

consists of 2 – 3 digits and indicates the type of telephone number being called. In the

case of mobile networks it indicates the code for the specific operator, E.g. 179 for the

O2 network operator. The CC and the NDC together are used of routing purposes.

The SN is a 10 digit number and consists of two parts; the HLR number representing the

logical address of the HLR and the ISN, which is a number assigned to the subscriber [2]

[10] [12].

Page 24: GSM Authentication

An Ontology for Generic Wireless Authentication 24

2.4 Security in GSM Networks

As described in section 1.1, the security issue covers three main aspects:

• Authentication

• Confidentiality

• Anonymity

In GSM networks Authentication is achieved by a challenge-response type of

authentication (described in section 2.4.1), and by the encryption of the radio channel,

which also guarantees confidentiality. Anonymity is achieved by the use of temporary

identities (i.e. the Temporary Mobile Subscriber Identity TMSI), which is a temporary

identity assigned to the IMSI [5] [6]. Only the Authentication part will be described in

this thesis.

2.4.1 GSM Authentication

The following figure illustrates a general overview of the authentication procedure in

GSM Networks:

Figure 7: Authentication in GSM Networks

Page 25: GSM Authentication

An Ontology for Generic Wireless Authentication 25

GSM authentication is a challenge-response type of authentication. The mobile station

initiates the authentication procedure, by issuing an authentication request. The home

network generates a response and sends a challenge to the mobile station, in order to

calculate the same response. If both responses generated from the home network and the

mobile station match, then authentication is achieved, and access to the network is

granted. Below a detailed description of the authentication procedure and the

components involved in authentication are given.

A new mobile subscriber is given a SIM card, in which relevant information about a

subscriber is stored. The SIM card contains the necessary keys and algorithms needed for

the authentication procedure, which enables a subscriber to connect to the home

network.

A secret key referred to as Ki is stored in the SIM card of the mobile subscriber, and in

the Authentication Center of the home network of the mobile operator. This key remains

secret and is never transmitted from the AuC or SIM card. The Ki is a unique 128-bit

key. The whole authentication procedure depends on the privacy/secrecy of this key.

The concept behind the challenge-response type of authentication is to prove that the

secret key, stored in the SIM card of the mobile station is the same as the key stored in

the AuC.

The authentication procedure begins when a mobile station, requests access to the

network. This is achieved via an authentication request, in which the mobile device sends

out the IMSI as a request for authentication. The IMSI is broadcasted to a corresponding

MSC, which in turn forwards this information to the HLR in the home network, and also

the VLR in the visited network.

The AuC is associated with the HLR, and is responsible for storing authentication

specific parameters. After the reception of the IMSI by the AuC, a random number

(RAND) is generated using the received IMSI and the stored secret key Ki. The RAND

number is a 128-bit key, and represents the challenge to be sent to the SIM by the home

network.

The AuC and SIM card contain authentication algorithms, namely the A3 algorithm for

authentication and the A8 algorithm for key generation (explained in section 1.4.1). With

the help of these algorithms an Expected Response key (XRES), which is 32-bits long,

and a Cipher key (Kc), 64-bits long are generated.

Page 26: GSM Authentication

An Ontology for Generic Wireless Authentication 26

The XRES is used to verify if the SIM can generate the same response, and is based on a

symmetric mechanism. The Kc is used for encrypting calls between the mobile and base

stations, and is a temporary session key.

Upon generating these keys, the HLR sends out an authentication response known as

triplets, which consists of the (RAND, XRES and Kc). The triplets are generated and

stored in the VLR for each subscriber. The MSC then forwards the RAND number of

the generated triplets to the mobile station. This RAND number is sent as a challenge to

the mobile station, and challenges the mobile station to calculate the same response

generated by the AuC.

With the use of the A3 and A8 algorithms, the RAND number and Ki key are used to

calculate the RES and a Kc. The RES is then forwarded to the MSC/VLR, and a

comparison of RES and XRES is made. If both responses match, the authentication

procedure is successful and the mobile station gains access to the network and its

services. If, however the XRES and RES don’t match, then access is denied to the

mobile station and the authentication procedure fails [5] [6] [15].

2.4.2 Security Algorithms in GSM

Three security algorithms exist in GSM networks, namely the A3 authentication

algorithm, the A5 ciphering/deciphering algorithm and the A8 ciphering key generation

algorithm. These three are used in order to provide different security features and

techniques, including authentication and protection of the radio link, which guarantees

privacy of calls and user data [13] [14] [15].

2.4.2.1 A3 Algorithm

The A3 algorithm is the authentication algorithm for GSM networks, and resides on the

SIM card of the mobile subscriber, and on the HLR/AuC of the home network. The

implementation of the A3 algorithm is network specific and depends on the network

operator.

The A3 algorithm is a non-recursive algorithm, meaning that the output generated from

the input cannot be used to derive or guess the inputs. Thus, the output gives no

indication about the input. The main purpose of this algorithm is to authenticate the

identity of a mobile subscriber.

Page 27: GSM Authentication

An Ontology for Generic Wireless Authentication 27

The A3 algorithm generates the XRES on the network side and the RES on the mobile

side. Both the XRES and RES are a 32-bit long key and are generated from Ki and

RAND [13] [14] [15].

2.4.2.2 A5 Algorithm

The A5 algorithm is the ciphering/deciphering algorithm, and resides on the mobile

station of a subscriber and on the BSS. The A5 algorithm is used for protecting data sent

from the mobile station, and the BSS and vice-versa, this provides the privacy of data

and calls.

The Kc ensures that all calls are encrypted between the MS and the BSS. The A5

algorithm is a standardized algorithm, but this algorithm can only be obtained with a

specific license from the GSM Association [5]. Although the A5 algorithm is

standardized, its specification remains undisclosed [5] [13] [14] [15].

2.4.2.3 A8 Algorithm

The A8 algorithm is the ciphering key generation algorithm, as with the A3 algorithm it

also resides on the SIM card and HLR/AuC. Its implementation is network specific and

it is also a non-recursive algorithm.

The A8 algorithm is used for generating the Kc, which is a session key and is used for

encrypting voice and data traffic. The Kc is generated from the Ki and RAND and is 64-

bits long [13] [14] [15].

Page 28: GSM Authentication

An Ontology for Generic Wireless Authentication 28

2.5 Introduction to UMTS networks

The Universal Mobile Telecommunications System (UMTS) is one of the new third

generation (3G) networks. 3G networks build on 2G networks with the General Packet

Radio Service (GPRS) support, which are known as 2.5G networks. 2.5G networks

support packet switching domains. A UMTS network also provides for inter-operability

with a GSM network and is an extension of existing GSM networks [18].

UMTS networks support the circuit and packet switched domains, and are backward

interoperable with GSM/GPRS networks [5][18] [19].

UMTS networks provide enhanced data transmission rates and a wider range of services,

including multimedia and IP based services [5] [6] [16].

The following figure illustrates the UMTS network architecture, (only components

related to authentication are illustrated):

Core Network

RNC

Visited Access Network Visited Core Network Home Network

AuCHLR

VLRMSC

Circuit Switched Domain

3G SGSN

Packet Switched DomainUTRAN

RNS

BTS

MS

UE

Node B

BSC

BSS

MS/UE

Mobile Device

Figure 8: UMTS Network Architecture

Page 29: GSM Authentication

An Ontology for Generic Wireless Authentication 29

The UMTS network consists of the following components: [16] [17] [18]

• User Equipment (UE)

• UMTS Terrestrial Radio Access Network (UTRAN)

• Core Network (CN)

2.5.1 UMTS Network Components

2.5.1.1 User Equipment

The UE consists of the mobile device and the Universal Subscriber Identity Module

(USIM) card. The UE separates between the user device functionality and the USIM

functionality [16].

The USIM is similar in functionality to the SIM of the GSM network. The USIM is more

enhanced in terms of security. The keys and algorithms used for authentication and

encryption are stored on the USIM. Subscriber specific data and several identities are also

stored on the USIM [15].

2.5.1.2 UMTS Terrestrial Radio Access Network

The UTRAN is the new access network for UMTS networks, which uses different

multiple access methods than previous GSM networks [17]. It is responsible for network

access procedures, mobility and resource allocation [4].

UTRAN is subdivided into individual Radio Network Subsystems (RNS), which consists

of the following components [16] [17]:

2.5.1.2.1 Radio Network Controller

The RNC is the controlling unit of the UTRAN and is responsible for communicating

with the UE. It performs radio specific functions and maintains the connection to the

CN for each UE. It functions like the BSC of GSM networks, and provides switching

functions between other RNCs [16]. The RNC is connected to one or several Node Bs

[17].

Two types of RNCs exist, namely Serving Radio Network Controllers (SRNC) and

Drifting Radio Network Controllers (DRNC) [4] [18]. The SRNC is responsible for

Page 30: GSM Authentication

An Ontology for Generic Wireless Authentication 30

controlling the connection to the CN, while the DRNC is responsible for the connection

to the UE and offers additional resources [4] [18].

2.5.1.2.2 Node B

Node-Bs are the base stations of the UMTS network, and several Node-Bs can be

connected to one RNC. Each Node-B can serve one or several radio cells. A Node-B

fulfils almost the same functionalities as a BTS in GSM networks [16]. A Node B is

mainly responsible for the transmission and reception of data [17].

2.5.1.3 Core Network

The CN consists of two domains: the Circuit Switched (CS) domain, and the Packet

Switched domain (PS). The CN in UMTS is an enhanced version of the GSM core

network with GPRS.

Each domain has its specific components. The CS domain includes the MSC and VLR as

its components, and provides circuit switched functionalities such as calls and switching

of calls. The PS domain includes the 3G Serving GPRS Support Node (SGSN) as its

component, which is responsible for the delivery of data packets to and from the UE.

The SGSN takes the role of the MSC/VLR of the CS domain. The PS domain provides

IP-Based services. Components like the HLR and AuC are shared by both CS and PS

domains [17] [18].

Page 31: GSM Authentication

An Ontology for Generic Wireless Authentication 31

2.6 Security in UMTS networks

Security in UMTS networks is based and built on the existing GSM security mechanisms.

However, UMTS has far more security mechanisms than in GSM, and is more enhanced

in terms of security [6].

Robust security mechanisms of GSM networks have been adopted into UMTS networks.

Compatibility with GSM networks is ensured in order to ease inter-working operations

between the networks [21].

New security services have been introduced into UMTS networks as well as new

domains. This required the introduction of new security mechanisms [5].

Some of the major security enhancements in UMTS networks are as follows:

• Mutual Authentication; not only is the subscriber authenticated by the network,

the subscriber can also authenticate the network. The subscriber can ensure that

he/she is connecting to a trusted network.

• Integrity Protection; enhanced algorithms and keys to ensure data integrity.

• Network Security; security between and within different networks.

• Secure Services and Applications; enhanced security features for services and

applications [21].

• Interoperability and Roaming; standardized security features, enabling network to

network interoperability and roaming [20].

Page 32: GSM Authentication

An Ontology for Generic Wireless Authentication 32

2.6.1 UMTS Authentication

The following figure illustrates the authentication procedure in UMTS networks:

Figure 9: Authentication in UMTS Networks

UMTS authentication is based on a challenge-response type of authentication, similar to

that of GSM networks. It is based on the existing GSM infrastructure and is built on

GSM authentication and security mechanisms [5] [6].

UMTS authentication provides mutual authentication [5] [6], meaning that the network a

certain subscriber is connecting to is authenticated. Details about the exact mutual

authentication procedure are described below.

The UE initiates the authentication procedure by sending an authentication request,

which can be in the form of different subscriber identities:

• The IMSI.

• The Temporary Mobile Subscriber Identity (TMSI). This is a temporary

identity, used instead of the IMSI in order to avoid the user’s identity from

being continuously transferred via the network.

• Packet-TMSI (P-TMSI), for the packet switched domain [5].

IMSI IMSIAuthentication Request

Authentication Response

RAND, AUTN, XRES, CK, IK

(Quintets)

Authentication Request

RAND, AUTN

Serving Network

RES = XRES

Home Network

HLR AuC

User Equipment

USIM

UE

RES

MSC SGSNVLR

RAND K AUTN

SQNRES CK IK

SQN

XRES

RAND K

AUTN CK IK

Page 33: GSM Authentication

An Ontology for Generic Wireless Authentication 33

These identities are also used in 2G GSM networks, apart from the P-TMSI, which is

used in 2.5G networks.

A permanent secret key (K) – 128 bits - resides in the USIM of the UE and in the AuC

of the home network. As with GSM authentication, this key is never transmitted and is

always kept secret.

The user’s identity is verified by the Serving Network (SN) or the visited core network.

Access to the network is granted by the SN if the verification procedure is successful.

The SN forwards the authentication request (IMSI) to the HLR/AuC of the Home

Network (HN). An authentication vector, called (Quintets) is generated as the

authentication response and is returned back to the SN. Using the IMSI, the AuC then

generates a Random Number (RAND) – 128 bits – and a Sequence Number (SQN) – 48

bits. This SQN is chosen in ascending order in order to later check the freshness of the

SQN, and thus the freshness of the generated authentication vector sent to the USIM.

The SQN and RAND number are then used, with the help of the f1, f2, f3, f4 and f5

functions/algorithms to generate the authentication vector. These functions are all non-

recursive, and it is important to note that the output of one function cannot reveal any

information about the input of another function [5].

The inputs for the authentication vector are the RAND, SQN and K, which is stored in

the AuC. The authentication vector consists of the following keys: the Expected

Response (XRES) generated using the f2 function and is 32 – 128 bits; the Cipher Key

(CK) generated using the f3 function and is 128 bits; the Integrity Key (IK) generated

using the f4 function an is 128 bits; the Authentication Token (AUTN), which is a

concatenation of different keys (explained below) and is 128 bits.

An authentication response is then sent out to the Serving Network in a form of

quintets, this authentication response is made out of the following keys: (RAND, AUTN,

XRES, CK and IK). The SN keeps a copy of the XRES to compare it with the RES that

will be generated on the USIM. The SN sends a challenge to the USIM in the form of the

RAND and the AUTN keys. This challenge is used in the USIM along with K as inputs

for the authentication procedure on the USIM side. The generated output consists of the

following keys; Response (RES) 32 – 128 bits, generated by the f2 function, the SQN 48

bits, the Cipher Key (CK) and the Integrity Key (IK), generated by the f3 and f4

functions respectively.

Page 34: GSM Authentication

An Ontology for Generic Wireless Authentication 34

The authentication procedure on the USIM starts upon the reception of RAND and

AUTN. The importance of sending these two keys is for the mutual authentication

process. The AUTN can only be computed by the AuC of the home network. Therefore,

the UE is able to verify that it is connecting to a trusted network; a network that holds

the same secret as the USIM (i.e. K) [19].

The RES is then forwarded to the SN, and is evaluated against the XRES response

received from the Home Network. If both responses match then the UE is authenticated

to access the network [5] [6] [19].

2.6.1.1 UMTS Authentication Vector

The following figure illustrates the authentication vector generated in the AuC. It is

important to understand this authentication vector, in order to understand how UMTS

performs mutual authentication. Up till now, only the UE has been authenticated to use

the network, the second step of authentication is performed on the USIM side, where the

UE checks whether it is connecting to a trusted network or not.

Figure 10: UMTS Authentication Vector

The generation of the authentication vector on the home network side begins with the

reception of the IMSI (authentication request) from the UE. A fresh SQN and a RAND

number are generated. SQN proves to the USIM that the generated authentication vector

Page 35: GSM Authentication

An Ontology for Generic Wireless Authentication 35

is fresh. Five one way functions (f1, f2, f3, f4 and f5) [5] are used for generating the

authentication vector.

The f1 and f2 functions/algorithms are message authentication functions. The input of

the f1 function is the RAND, K, SQN and the Authentication and Management Field

(AMF) a 16 bit key. The AMF is an operator-specific key, and is used for operator-

specific functions in the authentication procedure. The output of the f1 function is the

Message Authentication Code (MAC) a 64 bit key, which is an algorithm or a one way

hash that computes bits and a secret key to generate a fixed-length of bits [20]. Its

purpose is for verifying that the inputted bits have not been altered in some way or the

other.

The f3, f4 and f5 functions are key generating functions, which all take the RAND and K

as inputs. The f2 function generates the XRES, and is used to compare the RES

generated on the USIM side for subscriber authentication. The f3 and f4 functions

generate the CK and IK keys respectively for ciphering and integrity protection purposes

on the air interface. The f5 function generates an Anonymity Key (AK) 48 bit, which is

used to conceal the generated sequence number SQN [5] [19].

Page 36: GSM Authentication

An Ontology for Generic Wireless Authentication 36

2.6.1.2 USIM Authentication

The following figure illustrates the authentication procedure on the USIM of the UE:

Figure 11: USIM Authentication

f1

RAND

f5 f2 f4f3

RES CK IKAK

AKSQNSQN

+

AMF

MAC

XMAC

MAC = XMAC?

AUTN

USIM

+

K

The functions f1 – f5 are ordered in a different manner on the USIM as compared with

the functions on the AuC. In USIM authentication the f5 function must generate outputs

before the f1 function. The authentication procedure starts with the computation of the

Anonymity Key (AK). This key is generated from the inputs of RAND and K using the

f5 function, which is used to conceal the SQN preventing any leakage of user identity

through the SQN.

The functions f2, f3 and f4 take the RAND and K as inputs and generate RES, CK and

IK respectively. The input of the f1 function is a bit more complicated; two keys from

the AUTN namely SQN and AK are concatenated with the AK, which is generated from

the f5 function in the following manner: SQN = (SQN ⊕ AK) ⊕ AK [19]. This SQN is

then an input for the f1 function along with the AMF key. The f1 function generates the

Expected MAC (XMAC) a 64 bit key as its output. This value (XMAC) is compared to

the MAC of the AUTN key, which is a concatenation of the SQN, AK, AMF and MAC

Page 37: GSM Authentication

An Ontology for Generic Wireless Authentication 37

in the following way: AUTN = SQN ⊕ AK || AMF || MAC [19]. If both MACs

match, authentication of the network is completed and the USIM verifies that it is

connected to a trusted network [5] [19].

2.6.2 Security Algorithms in UMTS

The main algorithms in UMTS networks concerned with authentication are the f1, f1*,

f2, f3, f4, f5 and f5* functions. These functions are operator-specific and only reside on

the AuC of the home network and the USIM of the UE.

Each of these functions is a one-way function. The functions are used for computing the

authentication vector. The importance of these functions lies in that the output of one

function cannot reveal any information about the other functions [5].

The f1 function is the network authentication function and is responsible for the

generation of the MAC key on the network side and the XMAC key on the USIM side.

The f1* function is the resynchronization message authentication function and is used

for resynchronization purposes.

The f2 function is the user authentication function and is responsible for the generation

of the XRES key on the network side and the RES key on the USIM side.

The f3 function is the CK derivation function. It generates the CK on both the network

and USIM side.

The f4 function is the IK derivation function. It generates the IK on both the network

and USIM side.

The f5 function is the AK derivation function for normal operation. The AK is

generated using the f5 function on both the network and USIM side.

The f5* function is the AK derivation function for resynchronization and is used for

resynchronization purposes [5] [6].

Page 38: GSM Authentication

An Ontology for Generic Wireless Authentication 38

2.7 Introduction into the Internet Protocol Multimedia Sub-System in UMTS networks

The IP Multimedia Sub-System (IMS) plays a major role in UMTS networks as of the

UMTS release number 5 [5].

The IMS is an application layer, residing on top of the packet switched domain of the

UMTS network. It is independent of the access network, and supports various types of

networks and devices [5]. The main intention of the IMS is to provide multimedia

services and applications to end users. IMS also supports roaming services for mobile

networks [5] [23]. A multimedia service is a service that supports two or more kinds of

multimedia services for telecommunication networks. Services can be for example, video

and audio downloading and streaming, text messaging, web browsing, etc… [22]

The following figure illustrates an overview of the IMS system architecture in mobile and

fixed networks:

GMSC

GGSN

RNC

VLRMSC

SGSN

UTRAN

RNS

BTSMS

UENode B

BSCBSS

PLMN / PSTN /ISDN

Fixed Access Networks /

WLAN

Core Network

I-CSCF S-CSCF

Home IMS

Visited IMS

P-CSCF

HSS

Figure 12: IMS Subsystem Architecture

Page 39: GSM Authentication

An Ontology for Generic Wireless Authentication 39

The IMS consists of the following components:

• The Home Subscriber Server (HSS)

• Proxy-Call Session Control Function (P-CSCF)

• Interrogating-Call Session Control Function (I-CSCF)

• Serving-Call Session Control Function (S-CSCF)

• Gateway GRPS Support Node (GGSN); also supported in UMTS and 2.5G

networks [22].

The HSS is the main database of the IMS network. The HLR and AuC are integrated

into this database, and subscriber specific, location-related data and user identities are is

stored in this database.

The CSCF consists of three types that perform different functions within the network:

The P-CSCF is the first contact point in the IMS. It is responsible for forwarding

registration requests and responses, to and from the mobile device and the I-CSCF. The

P-CSCF resides in the visited network, and is assigned to a terminal supporting IP

Multimedia (E.g. mobile phone, laptop, computer, etc…). It is also responsible for the

confidentiality and integrity of messages sent in the network.

The I-CSCF is responsible for contacting the respective S-CSCF within the home

network via the HSS. Its main task is the assignment of an S-CSCF, routing, and

forwarding of requests and responses to the relevant S-CSCF.

The S-CSCF is responsible for session control and session management. In addition,

authentication and subscriber specific data are stored in the S-CSCF, which are retrieved

from the HSS. The S-CSCF is assigned to an IMS terminal, and performs the

authentication of an IMS user. Registration requests received by the S-CSCF are

forwarded to the HSS [5] [22] [23].

The I-CSCF and S-CSCF reside in the home network of the IMS.

The GGSN is a gateway between the IMS and UMTS networks, and represents the

entrance point to the IMS system.

The IMS supports the access of other networks like; Fixed Access Networks, Wireless

Local Area Networks (WLAN), Public Land Mobile Networks (PLMN), Public Switched

Telephone Networks (PSTN) and Integrated Services Digital Networks (ISDN). The

Page 40: GSM Authentication

An Ontology for Generic Wireless Authentication 40

latter three can be accessed by GSM networks via, the Gateway Mobile Switching Center

(GMSC) [23].

Authentication in the IMS is performed, via the IMS Authentication and Key Agreement

(AKA) mechanism, which is a challenge/response type of authentication and which is

analogous to UMTS authentication. The IMS uses the IMS Subscriber Identity Module

(ISIM), in the UE instead of the USIM and SIM in UMTS and GSM networks

respectively [5].

2.7.1 Identities in the IMS system

Several identities exist in the IMS system, which are used to uniquely identify a user or a

service of the IMS system. These identities are; Public User Identities, Private User

Identities and Public Service Identities and are briefly described in the following:

2.7.1.1 Private User Identities

Every user of an IMS system has one private user identity, used to identify the user of the

IMS system. This identity is assigned by the home network, and it takes the form of a

Network Access Identifier (NAI). An NAI is a standardized way to identify users to a

network during authentication via a username or a username@realm. Private user

identities are static, and are used to identify information related to a specific subscriber

(subscriber and authentication information), which is stored in the HSS. Apart from the

private user identity being stored in the HSS, it is also stored in the ISIM of the UE and

also in the S-CSCF. The private user identity takes a similar function as that of the IMSI

in GSM and UMTS networks. The private user identity is authenticated during user

registration [23] [24] [25].

2.7.1.2 Public User Identities

One or more public user identities can be allocated to a user of an IMS system. A user

should obtain at least one public user identity, which is also stored in the ISIM. This

identifier is used for communication purposes with other IMS users. It is also used by

external users to address a user. The public user identity takes the form of a

telephone:URL number or a URL. Public user identities are used to identify information

related to a specific subscriber within the HSS, but unlike private user identities, public

user identities are not authenticated by the network. IMS terminals are tied to public user

identities by the S-CSCF [24] [25].

Page 41: GSM Authentication

An Ontology for Generic Wireless Authentication 41

2.7.1.3 Public Service Identities

Private and public user identities are used to identify users within an IMS system.

However, public service identities are used for identifying the various services available to

the IMS via application servers. Each public service identity is bound to a service of the

IMS [24].

Page 42: GSM Authentication

An Ontology for Generic Wireless Authentication 42

2.8 Introduction to Wireless Local Area Networks

A WLAN is a local area network that does not use wires to communicate between the

stations, instead high frequency radio waves are used for communication. An example of

WLAN networks is the 802.11 standard defined by the IEEE [26].

The following figure illustrates an overview of a WLAN network:

Target Network

Access Point

Wireless Station 1

Wireless Station 2

Figure 13: WLAN Overview

The main components involved in a WLAN network are the mobile station, which could

be any mobile device (E.g. a laptop, Personal Digital Assistant (PDA)), the wireless

Access Point (AP) that performs the task of a wired hub – the AP acts as an entry point

to access the target network- , and some kind of authentication server performing,

authentication and granting access to the network via the AP [8].

In the following the WLAN security architecture will be explained along with concepts

relating to WLAN authentication.

Page 43: GSM Authentication

An Ontology for Generic Wireless Authentication 43

2.9 Security in WLAN networks

2.9.1 802.11

The 802.11 is a standard developed by the IEEE for wireless networks. The specification

defines the interface between a wireless station, and an access point or another wireless

station. The 802.11 also specifies how access to a WLAN is achieved or in other words

how authentication of WLANs is implemented. Authentication in 802.11 networks is

based on authenticating a wireless station rather than a user [29].

In order for a wireless station to connect to another station or access point, the initiating

station must prove its identity, to the receiving wireless station or access point. This is

achieved via various authentication methods, which depend on the type of authentication

method deployed.

The 802.11 is a family of standards, and several specifications of this standard exist,.

Amongst these are; 802.11, 802.11a, 802.11b, 802.11g. Each specification differs from

the other in the spectrums/multiplexing methods, transmission rates and bandwidths

[27].

2.9.2 Wired Equivalent Privacy

The Wired Equivalent Privacy (WEP) key is used, between a wireless client, and an AP,

in order to encrypt data being sent from the client to the AP, and to decrypt the same

data on the AP. It is a standard defined by the IEEE 802.11 Working Group for data

encryption. WEP keys are static keys, and are used as session keys, to enable

communication of the client and the AP. If the client is not able to detect the AP’s WEP

key, access to the network is blocked from the client. As the name implies, WEP was

developed to be as secure as that of wired networks that is why it is termed as equivalent.

This fact does not hold, since many flaws have been detected in this encryption scheme.

Many enhancements have been made to WEP and it is deployed by several

authentication methods [30].

Page 44: GSM Authentication

An Ontology for Generic Wireless Authentication 44

2.9.3 Wi-Fi Protected Access

Wi-Fi Protected Access (WPA) is an enhancement over the vulnerable WEP encryption

scheme. All flaws in WEP have been addressed in WPA. WPA provides authentication,

key management and encryption mechanisms, to secure a wireless network [31].

2.10 WLAN Security Architecture

Unlike GSM and UMTS networks, security in WLAN networks is not standardized.

WLANS are implementation specific, and depend on the technology deployed and

chosen on the wireless devices and access points. Another issue to put into consideration

when securing wireless networks is, how secure the network should be, and what are the

costs of implementing such security, these factors influence the type of security

mechanisms deployed.

The following figure illustrates the general security architecture for a WLAN:

Figure 14: WLAN Security Architecture

2.10.1 802.1X

The 802.1X is an essential element in securing WLAN networks. It is a standard from the

IEEE, and is used for port-based network access control. Authentication of wireless

stations (e.g. laptop, access point) is performed via this standard, and is based on the

EAP protocol [33]. The 802.1X is the authentication framework, and the EAP methods

deployed are the authentication algorithms [29].

Page 45: GSM Authentication

An Ontology for Generic Wireless Authentication 45

Authentication methods in wireless networks must fulfil certain minimum requirements;

amongst these requirements are the following:

• Generation of session keys for authentication, confidentiality and integrity

purposes.

• Support for mutual authentication between client and access point, thus

preventing rogue (impersonating) access points.

• Protection against eavesdroppers and man in the middle attacks, this can be

ensured using session keys for message authentication, data confidentiality and

data integrity.

• Protection against dictionary attacks [33].

Three components are involved in the 802.1X framework:

• The client – the wireless station

• The authenticator – the access point

• The authentication server – the AAA server [cisco 2]

The client initiates the connection procedure, by associating itself to the access point, and

issuing an EAP Start Request. At this point, the access point blocks the communication

between the client and the network, until the authentication procedure is completed, (i.e.

until the client presents correct authentication data (user ID and password/certificate)

and is verified).

The access point requests the identity of the client, by issuing an EAP Request Identity

message. The client replies to this message via an EAP Response message containing its

identity. This information is forwarded to the AAA server.

Authentication is achieved depending on the authentication method deployed. The

access point, grants the client the right to access the network upon the reception of an

accept message, unsuccessful authentication leads to a reject message. Keys (session key

and broadcast keys) are derived when the client authenticates the authentication server

[29].

The 802.1X, along with the EAP authentication methods provide centralized

authentication and dynamic key generation and distribution. Authentication methods in

Page 46: GSM Authentication

An Ontology for Generic Wireless Authentication 46

WLAN can be of different types, the ones described in this chapter are password based

and certificate based methods.

2.10.2 Authentication, Authorization and Accounting Server

The basic purpose of an Authentication Authorization and Accounting (AAA) server is

to control access to a wireless network.

Authentication in wireless networks grants or denies a client the right to access a

network, depending on the validity of credentials the client presents. This could be in the

form of a user name and password, security tokens or digital certificates.

Authorization specifies what rights a client is entitled to during the connection to the

network. This includes but is not limited to session time, access to certain

resources/groups, etc…

Accounting is used for tracking a user, and for billing purposes. The user name and

connection duration are stored for this purpose.

Several types of authentication servers exist. The AAA server based on the Remote

Authentication Dial In User Service (RADIUS) protocol is discussed in this thesis.

Remote Authentication Dial In User Service (RADIUS) The Remote Authentication Dial In User Service (RADIUS) is a protocol, used for

providing authentication, authorization and accounting services between an access point

and an authentication server (a RADIUS server or any other kind of AAA server). It

provides a central user database [35] that can be accessed by different servers, in order to

authenticate users (validate credentials) as well as provide configuration information,

such as the type of service to deliver to the user (authentication) and accounting services,

based on the user’s usage of the network.

A RADIUS server supports several methods for authentication (RFC 2138). In simple

terms, a RADIUS server checks for the validity of a user, requesting access to a network.

It authorizes the user to access the network, if the information stored in a database is

verified [34].

Page 47: GSM Authentication

An Ontology for Generic Wireless Authentication 47

2.10.3 Certificate Based Authentication

It is necessary to understand the underlying terminologies of certificates in order to

understand certificate based authentication.

2.10.3.1 Public Key Infrastructure

A Public Key Infrastructure (PKI) is an infrastructure composed of digital certificates,

certifying authorities (CA), public keys and private keys. The concept behind a PKI is

that parties/entities, trying to communicate with each other via the internet, can be

verified and authenticated against who they really claim to be via authorizing and

certifying authorities. Public and private keys are managed by a PKI. Public keys are

signed and verified by trusted certifying authorities [36] [37].

2.10.3.1.1 Digital Certificates

A digital certificate is an electronic identity used to prove the identity of a certain

party/entity. This certificate is approved by a certifying authority, and signed by the

certifying authority’s private key. Access to certain resources can be obtained using digital

certificates [38]. A certificate is obtained via a CA.

A digital certificate consists of the following according to the X.509 standard:

• A digital signature

• Version

• Serial Number

• Signature Algorithm

• Issuer Name

• Validity period

• Subject

• Public key [39]

2.10.3.1.2 Certifying Authority

A certifying authority is a trusted third party that issues digital certificates, and verifies the

validity of public keys [39].

Page 48: GSM Authentication

An Ontology for Generic Wireless Authentication 48

2.10.3.1.3 Public Key

A public key is a number belonging to a certain entity. This key is distributed among

entities that interact with the entity owning this key. The public key is used for verifying a

digital signature and is used for encryption [39].

2.10.3.1.4 Private Key

A private key is a number belonging to a certain entity and is not known to any other

entity. The private key is used for computing signatures and decryption. Public and

private keys exist in pairs and correspond to each other; a message can be decrypted by a

private key upon the reception of a public key associated with that private key [39].

2.10.3.1.5 Digital Signature

A digital signature is a digital code, verifying that the sender is the one issuing the

electronic message. The digital signature, also verifies that the contents of the electronic

message have not been altered.

2.10.4 Password Based Authentication

In password based authentication, the password is not directly transmitted to the access

point from the client. Instead a password hash or secret key is generated from the

password to protect it from being sniffed across the network. The secret key or password

hash is calculated via a hash function, which provides a one way encryption of the

password. The password is shared between the network and the client. The network

calculates the password from the received secret key [29].

2.10.5 Extensible Authentication Protocol

Messages for the purpose of authentication, are sent from the wireless device to the

authentication server via the Extensible Authentication Protocol (EAP), which is an

envelope consisting of different types of authentication methods. EAP is a general

authentication protocol, supporting various authentication procedures. Our

concentration for this thesis will be EAP authentication methods for password and

certificate based authentication [33].

Page 49: GSM Authentication

An Ontology for Generic Wireless Authentication 49

The EAP protocol defines several types of authentication methods, amongst them are

the following:

• Lightweight Extensible Authentication Protocol (LEAP)

• Extensible Authentication Protocol – Transport Layer Security (EAP-TLS)

• Protected Extensible Authentication Protocol (PEAP)

• Extensible Authentication Protocol – Subscriber Identity Module (EAP-SIM)

2.10.5.1 Lightweight Extensible Authentication Protocol

LEAP, is a password based authentication protocol that authenticates the user rather

than the device. Authentication is performed according to the user name and password

provided. No certificates are used in this type of authentication. Mutual authentication of

the client and authentication server is performed in this protocol, which depends on the

existence of a secret key, and the user’s password that is shared between the client and

the network.

An authentication challenge is sent to the client, from the authentication server. The

client responds to the authentication challenge with the hashed password. The

authentication server retrieves relevant authentication information, from a database to

create a response to the authentication request. The response generated by the

authentication server is then compared to the one received from the client. The client

authenticates the authentication server in a similar fashion. A dynamic session key called

WEP is generated upon successful authentication. Successful authentication ends with an

EAP-Success method [28].

2.10.5.2 EAP Transport Layer Security

EAP TLS is a certificate based authentication method, and is based on the TLS protocol

(RFC 2246), which is the present version of the Secure Socket Layer (SSL).

SSL is used by web browsers to secure transactions within web applications [29].

In EAP-TLS, certificates are used on both the client and server side for authentication.

The client authenticates the authentication server via a digital certificate, sent to the client

by the authentication server, and checks for the validity of the certificate. The server in

turn authenticates the client in a similar manner. Upon the reception of the EAP-Success

Page 50: GSM Authentication

An Ontology for Generic Wireless Authentication 50

message, the dynamic session keys are generated and network access is granted to the

client [28].

2.10.5.3 Protected Extensible Authentication Protocol

The PEAP protocol is a hybrid of EAP-TLS and any other EAP authentication method.

It is a certificate based authentication method. Server side authentication is performed via

EAP-TLS and the use of digital certificates is employed. For client side authentication

any EAP method can be deployed, which is transported via a secure TLS tunnel.

Certificates are not required for client authentication in PEAP.

As with the authentication of the server in EAP-TLS, PEAP performs the same

procedure of requiring and verifying a digital certificate, from the authentication server.

After verification of the server’s side certificate, an encrypted tunnel, between the client

and the authentication server is created. The tunnel is a secure path, for authenticating

the client via non-mutual EAP methods, like EAP-Message Digest 5 (EAP-MD5) or

EAP-Challenge Handshake Authentication Protocol (EAP-CHAP) (RFC 2284, RFC

1994). Upon successful client authentication the EAP-Success message is sent and

session keys are derived [28] [29].

Page 51: GSM Authentication

An Ontology for Generic Wireless Authentication 51

2.10.5.4 EAP- Subscriber Identity Module

The following figure illustrates the general overview of a WLAN accessing a

GSM/UMTS network via EAP-SIM:

Figure 15: EAP-SIM Architecture

EAP-SIM is an authentication method, designed to provide mutual authentication

between a WLAN client and an AAA server, using the GSM network for accounting and

billing purposes. It is especially useful in the case of hotspots, where a user of a WLAN

network can easily gain access to the internet via a mobile phone. As the name implies,

EAP-SIM uses the EAP framework and GSM system for authentication and encryption.

It is based on the authentication procedure between the SIM card and mobile network’s

AuC. Thus, EAP-SIM acts as a bridge between wireless and mobile networks, namely

WLAN and GSM networks.

For EAP-SIM, the wireless station requires a SIM reader, which could be in the form of

a smart card, USB stick, PC access cards, etc…

The overview scenario of an EAP-SIM protocol is that a wireless station, connected to a

SIM card reader, requests access to a network via an AP. The AP forwards the request to

an authentication server, which retrieves authentication data from an authentication

Page 52: GSM Authentication

An Ontology for Generic Wireless Authentication 52

center via a GSM gateway. The GSM gateway is responsible for translating requests from

an authentication server into GSM syntax. After the retrieval of the authentication data,

several messages are exchanged to and from the client and authentication server. Upon

successful authentication, the client gains access to the network.

Before successful authentication of the client and network, the communication ports are

blocked from the client by the AP. The client is not able to send any messages to the

network except for the authentication specific messages (EAP and EAP-SIM messages).

After authentication is completed, the client is able to communicate with the network

and the AP unblocks the ports from the client.

The EAP-SIM mechanism is more secure than the stand alone GSM system for

authentication, since it provides mutual authentication of the client and the network.

Another factor is that client’s session key, is never transmitted via the radio interface with

EAP-SIM, thus less data is exposed in comparison to GSM networks.

EAP-SIM functions in a way that it retrieves several GSM triplets from the AuC, and

combines them together in order to generate a session encryption key. This encryption

key is more secure than the GSM counterpart.

For the communication of the EAP-SIM between the client and the network, the EAP-

SIM protocol and the EAP-SIM authenticator code are implemented on the client. The

authenticator code is responsible for handling server side EAP-SIM messages, and is also

responsible for communicating with the AuC. Messages sent from the AAA server to the

AuC are translated into GSM specific messages [28].

EAP-AKA is used for 3G networks, namely UMTS networks and is similar in concept to

EAP-SIM but with more enhanced security features. EAP-AKA is not addressed in this

thesis.

Page 53: GSM Authentication

An Ontology for Generic Wireless Authentication 53

EAP-SIM Authentication The following figure illustrates WLAN authentication via the EAP-SIM protocol:

Figure 16: EAP-SIM Authentication

The EAP-SIM authentication procedure starts, when the client sends an EAP-over-LAN

(EAPOL) Start message to the AP. This message informs the AP that the authentication

procedure will be carried out via EAP. The AP responds to the EAPOL Start message,

with an EAP Request Identity message, which requests the network identity of the user.

This identity is forwarded from the client to the authentication server via the AP in the

form of an EAP Identity Response.

The user’s network identity takes the following syntax: 0 <IMSI>@<realm>, where

IMSI represents the subscriber’s identity number and realm represents the network

AAA ServerAccess Point HLR AuC

MAC_XRES =

MAC_XRES

EAP Request Network Identity

EAPOL Start

0<IMSI>@realm

EAP Identity Response

0<IMSI>@realm

EAP Identity Response

Get GSM Triplets

GSM Triplets

RAND, XRES, Kc

EAP-SIM Start Response(RAND)

EAP-SIM Start Response(RAND)

EAP-SIM Challenge

RAND, MAC_RAND

EAP-SIM Challenge

RAND, MAC_RAND

Wireless Station

Calculate MAC_RAND

MAC_RAND =

MAC_RAND Server

Authenticated

Calculate XRES, Kc,

MAC_XRESMAC_XRES

Challenge Response

MAC_XRES

Challenge Response

Calculate MAC_XRES

Client Authenticated

Session KeyEAP-Success Accept

Broadcast KeySession Key

EAP-SIM Start EAP-SIM Start

Page 54: GSM Authentication

An Ontology for Generic Wireless Authentication 54

operator’s domain name. The network identity is used for WLAN authentication

purposes.

The authentication server determines the EAP type being used, and sends an EAP-SIM

Start message to the client. The client responds via an EAP-SIM Start Response message

that carries the RAND number generated from the SIM. After reception of the EAP-

SIM Start Response message, the authentication server retrieves several GSM triplets

from the AuC of the GSM network provider. A gateway is needed in order to translate

the request from the AAA server’s syntax to GSM specific syntax.

An EAP-SIM Challenge message is created from the RAND number, received from both

the client’s SIM and the triplets from the GSM response. This challenge consists of the

AuC’s RAND number and a Random Message Authentication Code (MAC_RAND),

which is 160 bits long.

A MAC_RAND number is calculated separately on the SIM card, and is compared to the

one received from the authentication server in the EAP-SIM Challenge. If both

MAC_RAND numbers are equal, the first step of mutual authentication is completed

and the server is authenticated.

Upon successful server authentication, the SIM generates the XRES and Kc for the

respective RAND numbers received. Another number is also generated, which is the

Expected MAC Response (MAC_XRES).

The MAC_XRES is sent by the client to the authentication server as a response to the

challenge sent. The authentication server separately calculates a MAC_XRES, and

compares it to the one received from the SIM. If both MAC_XRES are equal, the

second step of mutual authentication is completed and the client is authenticated to the

server.

Session encryption keys are generated on the SIM and authentication server. An Accept

message is sent from the authentication server to the AP, along with an encapsulated

EAP-Success message (which is sent to the client) and the client’s session key. The

client’s session key, is sent to the client from the AP via a Broadcast key. Authentication

at this stage is completed and the client is able to access the network [28].

Page 55: GSM Authentication

An Ontology for Generic Wireless Authentication 55

3 Ontologies and the Semantic Web

3.1 The Semantic Web

“The Semantic Web is not a separate Web, but an extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation.” [40]. “The Semantic Web is a mesh of information linked up in such a way as to be easily processable by machines, on a global scale. You can think of it as being an efficient way of representing data on the World Wide Web, or a globally linked database.” [41] The Semantic Web is used to express the meaning of content, to machines. It is used to

provide machine readable content, on the web, to machines and processes. This content

can be easily processed, and manipulated in a meaningful way.

The current state of the Web today, only provides information accessible and

understandable by humans. No semantics are expressed, or provided for the contents of

the different web pages displayed. Thus, vital information cannot be used automatically,

without manual insertion, or processing into some sort of application or database.

As the first definition of the Semantic Web states, it is an extension of the current Web.

This extension is in the form of three main components of the Semantic Web:

• The Expression of Meaning

• The Representation of Knowledge

• The Collection of Information

The meaning of content can be expressed, in order to enable machine readability, rather

than just being used, for displaying content to humans, and which has no real value to

processes or machines. Providing meaning to content enables the Web to be a resource,

for processable data and information.

Knowledge is represented in a structured way, which can be inferred according to various

rules, thus enabling logical deduction and reasoning of data. This facilitates new

information to be derived from existing information. The method of representing

knowledge in such a way is called Knowledge Representation.

Common meanings of information are collected in what is known as an ontology. The

ontology can undergo inference rules, which can be used to reach common meanings

Page 56: GSM Authentication

An Ontology for Generic Wireless Authentication 56

among terms, and can be used for the creation of new meaning. The machine is able to

read the ontology, and provide a user with more meaningful information [40].

Various languages and tools have been developed for the Semantic Web. The most

popular are, the eXtensible Modelling Language (XML) – used to add arbitrary structure

to documents without expressing the meaning of the structures, the Resource

Description Framework (RDF) – used to express meaning and used to exchange

knowledge on the Web, and the Web Ontology Language (OWL) – used for sharing and

distributing knowledge. OWL is an ontology language, which supports knowledge

management, and advanced Web searches [40] [42].

The ontologies section takes a deeper look into ontologies and explains ontologies in

more detail.

The most popular languages developed for the Semantic Web, and which are World

Wide Web Consortium (W3C) recommendations are as follows:

• XML and XML-Schema; provides structured syntax for documents (XML), restrict

the structure of XML and extend it with dataypes (XML-Schema), but which also

provide no semantic meaning for the documents.

• RDF and RDF-Schema; using XML syntax provide a datamodel for objects and

define the relationships between the datamodels (RDF). RDF-Schema provides a

terminology to express RDF datamodels using classes and properties.

• OWL; provides more terminology for expressing the relationships between the

classes and properties. It provides more terminology for the description of classes

and properties [51]. OWL differs from XML-Schema, in that it represents

knowledge of a certain domain rather than just being a message format [52].

3.2 Ontologies

3.2.1 Origin

The term Ontology originates from philosophy and describes the nature of being in its

different aspects. Ontology relates back to many years and has had a long history.

Ontology in the field of metaphysics is the study, of existence and the relationships that

relate to this existence. It attempts to answer questions like; what defines the nature of

beings, what are its main characteristics/properties, what relationships exist among

Page 57: GSM Authentication

An Ontology for Generic Wireless Authentication 57

different beings, and how can they be defined, what are the main causes of being, what

different entities exist in beings and what rules govern them, etc…

Ontologies remained in the domain of philosophers, linguistics, librarians and knowledge

representation researchers, until the recent adoption of the term in computer science and

its usage in Artificial Intelligent (AI) research [43].

3.2.2 Definition

3.2.2.1 In Philosophy

“That department of the science of metaphysics, which investigates and explains the nature and essential properties and relations of all beings, as such, or the principles and causes of being” [44].

“A branch of metaphysics concerned with the nature and relations of being” [45].

“A particular theory about the nature of being or kinds of existence” [45].

3.2.2.2 In Artificial Intelligence

“A systematic arrangement of all the important categories of objects or concepts, which exist in some field of discourse, showing the relations between them. When complete, an ontology is a categorization of all the concepts in some field of knowledge, including the objects and all of the properties, relations, and functions needed to define the objects and specify their actions. A simplified ontology may contain only a hierarchical classification (a taxonomy) showing the type subsumption relations between concepts in the field of discourse. An ontology may be visualized as an abstract graph with nodes and labelled arcs representing the objects and relations” [47]. “An ontology defines a common vocabulary for researchers who need to share information in a domain. It includes machine-interpretable definitions of basic concepts in the domain and relations among them” [49].

“An Ontology is a formal, explicit specification of a shared conceptualization” [48]. Ontologies are designed for the purpose of knowledge sharing and re-use. An Ontology

is formal if a machine is able to interpret its meaning. It is explicit if the ontology concepts

and the constraints applied to the ontology are explicitly defined. It is a specification

because it describes the concepts of a certain domain in an actual manner. It is a shared

view or concept of a particular domain and finally, conceptualization refers to the fact that

the ontology represents an abstract analysis/vision of a certain nature or reality.

An important point to put into consideration when addressing ontologies, is that apart

from ontologies defining information or data as formal semantics, which can be

interpreted and processed by machines (machine-understandable). They also define real

Page 58: GSM Authentication

An Ontology for Generic Wireless Authentication 58

world semantics, which enables humans to understand the machine understandable

content, thus permitting reuse and ontology sharing [46] [50].

3.2.3 Ontology Approaches

Ontologies can be expressed in various ways, and different approaches exist for defining

concepts and the relations of concepts in a certain domain. A brief description between

three approaches, namely Description Logics, Frame-based and Predicate Logic is given

in the following:

3.2.3.1 Description Logics

Description Logics, is a language based on logics and is used represent domain

knowledge, based on logical representations of knowledge, and the reasoning of the

described knowledge.

A first step in representing a domain is the definition of concepts, related to and relevant

for this domain. These concepts can be described, in terms of properties and restrictions

that must be satisfied, in order for the concepts to belong to the described domain.

Reasoning of the concepts, represented in the knowledge base (the ontology and its

instances), is used to infer new information about the domain from the already existing

knowledge.

Description Logics also support the classification of concepts and individuals, which

expresses the child and parent hierarchies amongst the defined concepts [50] [60].

3.2.3.2 Frame-based

Modelling in Frame based approaches, consists of classes and local class properties. It

takes more of an object oriented approach in defining a domain. Frames (classes)

describe an individual, or a set of individuals in a certain domain, thus representing

knowledge of a concept in that domain.

Properties of a class can be reused by other classes with other range values and value

restrictions. Frames in a Frame-based system are interconnected and follow a hierarchy,

such that the properties defined for parent frames, are inherited by those of the child

frames. Properties can take specified values, or can be computed values [50] [59].

Page 59: GSM Authentication

An Ontology for Generic Wireless Authentication 59

An ontology in Frame-based systems, is made up of class definitions, and the connecting

relationships between the classes and properties, functions, objects and relating axioms

[50].

3.2.3.3 Predicate Logic

In Predicate Logic, the relationship(s) between subjects and objects are expressed.

Predicate logic is based on predicates. A Predicate is an expression that expresses (a)

relationship(s) between terms, e.g. the predicate “is a” in “GSM is a second generation

network”. Thus, GSM is the subject and second generation network is the object.

The most important elements in predicate logic are constants, predicates, variables,

formulas and quantifiers.

Constants are the names used in predicate logic, and represent the vocabulary used.

Predicates as explained, define the relationships between terms. Variables represent

terms, and are used as place holders for objects that represent individuals. Terms can also

be objects and constants. Formulas form expressions that have meanings, which are a

combination of individual terms. Quantifiers indicate the number of objects asserted to a

predicate. Two types of quantifiers are, the universal quantifier that asserts a predicate to

all objects, and the existential quantifier that asserts a predicate to some objects [58] [50].

Closed sentences are the result of combined terms that formulate expressions. A

knowledge base in predicate logic is represented by a set of sentences [50].

3.2.4 The Web Ontology Language

Several ontology languages exist, which depend on the ontology approach being used, is

a matter of preference, and also a matter of what purposes the ontology is used for. For

the purpose of this thesis, the Web Ontology Language is chosen and is discussed in the

following in detail.

The Web Ontology Language (OWL) is a language, created specifically for designing,

defining, creating and instantiating Web Ontologies. OWL is used for creating and

describing classes, properties and their instances, as well as defining the relationships that

exist between these classes and properties [52].

OWL is needed, and is used to provide machine-readable content to applications that

need to process the content of the web rather than just display Web content. This in

turn, facilitates greater machine interpretability of Web content, than that provided by

Page 60: GSM Authentication

An Ontology for Generic Wireless Authentication 60

other web languages (XML, XML-Schema, RDF and RDF-Schema). OWL is an

extension of these technologies [51].

The use of OWL can be summarized into the three following points:

• The description of a certain domain via the definition of classes and properties.

• The definition of the relationships existing among these classes and properties.

• The reasoning of the defined classes, properties and relationships, which prove

the defined logic of the described domain, and verify its consistency [52].

OWL is divided into three sublanguages; OWL-Lite, OWL-DL and OWL Full, which

differ from each other in the level of expressivity. Each sublanguage is an extension of its

predecessor, and is designed according to what the required ontology should describe.

Making a choice of which sublanguage to choose is based on the level of expressivity

required for the ontology, and which best suits the needs of the ontology.

OWL represents an important part of the Semantic Web. It allows the collection of

information from distributed sources, by relating ontologies together. This enables web

resources to be accessible to processes, via the description of the resource’s web content

[52].

3.2.4.1 OWL Lite

Is the simplest form of OWL ontologies and provides simple classification support, and

simple constraints [51].

3.2.4.2 OWL DL

OWL DL is based on Description Logics, as the abbreviations DL imply. With OWL DL

full support of the OWL constructs is included. These constructs can only be expressed

under certain restrictions. OWL DL supports reasoning mechanisms, thus

inconsistencies of the described domain and concepts can be tested, in an ontology

conforming to OWL DL. OWL DL represents an extension for OWL Lite, and provides

better expressivity and maximum expressiveness, with the assurance that what is

deducted from the ontology is computable [51].

Page 61: GSM Authentication

An Ontology for Generic Wireless Authentication 61

3.2.4.3 OWL Full

OWL Full is an extension of OWL DL, and full support of the OWL constructs is given

in OWL Full, without any restrictions. OWL Full provides for maximum expressiveness,

but without any computational assurances. OWL Full provides some reasoning

mechanisms, but complete reasoning for OWL Full is unlikely to be implemented.

3.2.5 OWL Language Constructs

OWL is used to define classes, instances and properties, in addition to describing the

relationships between the defined classes and properties. The basic language elements of

OWL are built on these concepts, and the most important ones are described in the

following [52]:

3.2.5.1 Classes

A class represents a concept, which is represented by a name and a set of rules, or

restrictions that qualify individuals to become members of the class. Individuals that

share common characteristics (properties) can be grouped into one or several classes.

Classes and individuals are, described by the properties assigned to the classes, and by the

relationships existing among the properties of a class.

Classes can be sub-classed, forming a hierarchy and a class may have several sub-classes.

The subclass inherits its characteristics from the super or parent class, and it may have

one or more parent class. Multiple inheritance is supported.

Subclasses and instances of a class are, sometimes used interchangeably, and can be

confused from the meaning. The main difference is that a subclass is used, to describe a

subset of the class. Instances are used to state that the individual described, is an actual

member of the class, and not a member that can be further characterized or subset.

OWL Full supports classes and instances, while OWL DL does not [52].

3.2.5.1.1 Enumerated Classes

An Enumerated Class is a class that consists, of an enumerated number of individuals

that belong to the class. Only the exact number of members that are specified in an

enumerated class can be members of the defined class. Enumerated classes are described

Page 62: GSM Authentication

An Ontology for Generic Wireless Authentication 62

using the oneOf construct, the class consists of oneOf the enumerated members and

nothing more [51] [52].

3.2.5.1.2 Disjoint Classes

Disjoint classes describe the difference between classes, and state that one class cannot

have the same instance(s) as another class that it is disjoint with. This helps a reasoner in

detecting inconsistencies between classes. What is an instance in class A cannot be an

instance in class B, if both classes are declared as disjoint [51] [52].

3.2.5.2 Properties

Properties describe individuals that belong to a class. They define general and specialized

facts about an individual. Relationships among individuals are defined using properties.

The same property can be re-used by several classes. This is achieved by specifying rules,

or restrictions for a particular individual. Therefore, the rules are specific to that

particular individual, and are not a tied to the property. Applying restrictions to

properties is a method, for defining the relationships between individuals of a class.

As with classes, properties can have sub-properties that further classify or define the

property, and that form a hierarchy of properties. A sub-property can have multiple

properties as a parent, or super-property. Sub-properties inherit the super-property’s

characteristics [52].

The two important types of properties in OWL are datatype properties and object properties:

• datatype properties; define the relationship between instances of classes, RDF

literals or XML Schema datatypes.

• object properties; define the relationship between instances of two or more

classes.

3.2.5.2.1 Property Domains and Ranges

Domains and ranges can be defined for properties, which relate individuals of one class

(the domain), to individuals of another class (the range), via a specific property.

Domains specify the individuals the property can be applied to. A range limits the values

a property can have, only the individuals specified in the range, can be values of the

specified property.

Page 63: GSM Authentication

An Ontology for Generic Wireless Authentication 63

3.2.5.2.2 Property Characteristics

Properties can be further specified, by assigning certain characteristics to a property. The

following describes the characteristics that can be applied to a property in OWL [52]:

3.2.5.2.2.1 TransitiveProperty

Transitive properties are properties, which relate one individual to another, via a

common individual. E.g. considering two individuals (individual 1 and individual 2), are

related to each other via a property, if a third individual (individual 3), is related to

individual 2 via the same property, it can be deducted that individual 1 is also related to

individual 3 via the same property. This is a transitive property [53].

3.2.5.2.2.2 SymmetricProperty

In symmetric properties, individual 1 is related to individual 2, via a property. And

individual 2 is related to individual 1, via the same property [53].

3.2.5.2.2.3 FunctionalProperty

Functional properties can also be referred to as single valued properties, and are

properties that can take only one individual as its value. If a functional property is applied

to two individuals, it can be deducted that these two individuals, represent the same

individual. The minimum cardinality allowed for a functional property is zero and the

maximum cardinality is 1 [51] [53].

3.2.5.2.2.4 InverseOf

An inverse property relates individual 1 to individual 2, via a property and relates

individual 2 to individual 1 via another property, which is its inverse property. A property

can be the inverse of another property [51].

3.2.5.2.2.5 InverseFunctionalProperty

An inverse functional property, states that the inverse property is functional (i.e. has only

one individual as its value) [51].

3.2.5.2.3 Property Restrictions

Page 64: GSM Authentication

An Ontology for Generic Wireless Authentication 64

Property restrictions are, rules applied to properties, in order to specify which and how

many individuals can belong to a certain class. A restriction is used, for describing an

unknown class, which consists of individuals satisfying the restriction (e.g. individuals

belonging to a certain group or that satisfy certain criteria). Property restrictions can be

classified into quantifier restrictions; (existential quantifiers and universal quantifiers),

hasValue restrictions and cardinality restrictions. These are addressed in the following

[51] [53]:

3.2.5.2.3.1 Quantifier Restrictions

Three parts make up a quantifier restriction; the first part is the type of quantifier

(existential or universal), the second part is the property involved in assigning the

restriction, and the third part is, the class from which values/individuals, are to be taken

from, in order to create an anonymous class that satisfies the restriction (The creation of

a group of values satisfying the condition).

3.2.5.2.3.2 Existential Quantifiers

Existential restrictions (someValuesFrom) are assigned to a property, and denote that at

least one individual of a class, associated with the restricted property belongs to an

unknown class. This unknown class forms the values of the defined restriction. (E.g. the

someValuesFrom restriction denotes that class A, has a set of individuals (at least one)

from class B, because it fulfils the property A). In other words, there exists at least one

kind of relationship between two or more classes [53].

3.2.5.2.3.3 Universal Quantifiers

Universal restrictions (allValuesFrom), as existential restrictions are assigned to a

property, and denote that only individuals of a specific class associated with the restricted

property belong to an unknown class, resulting from the property restriction. Individuals

from other classes cannot belong to this unknown class. (E.g. the allValuesFrom denotes

that class A can only have individuals from class B that fulfil the property A) [53].

3.2.5.2.3.4 hasValue Restrictions

The hasValue restriction relates individuals, from an unknown class to a specific

individual. It states that the unknown class has a particular value, which is a specified

individual [53].

Page 65: GSM Authentication

An Ontology for Generic Wireless Authentication 65

3.2.5.2.3.5 Cardinality Restrictions

Cardinality is used, to specify the number the number of relationships that can be

associated to a particular individual, via a specific property. In OWL minimum

cardinality, maximum cardinality and cardinality, can be defined for properties, and which

express the minimum, maximum and arbitrary number of occurrences respectively.

Cardinality values start from 0 and are never negative values [53].

3.2.5.3 Operators

Operators are used to define the characteristics of a class. Logical combinations of

classes can be performed with operators, such as; the intersection, union and

complement of classes. New class definitions can be created with the use of operators

[53].

3.2.5.3.1 intersectionOf

The intersectionOf operator performs a logical ‘AND’ operation, between two or more

classes. It combines the features of the classes specified, into a new class. Individuals of

the intersected classes become individuals of the new class [53].

3.2.5.3.2 unionOf

The unionOf operator performs a logical ‘OR’ operation between two or more classes,

and combines either the characteristics of all the specified classes, or one of the classes

into a new class. (E.g. if a union operation is performed for class A and class B, the

resulting class would be the individuals, of class A and B, or would be either one of

them) [53].

3.2.5.3.3 complementOf

The complementOf operator selects the individuals that do not belong to the specified

class.

Page 66: GSM Authentication

An Ontology for Generic Wireless Authentication 66

3.2.6 Ontology Tools

Several tools for editing and creating ontologies exist. For the purpose of this thesis, the

Protégé tool with the Protégé OWL Plug-in were used as an ontology editor, the Racer

tool as an ontology reasoner and the GraphViz tool as a tool to visualize the ontology.

Descriptions of each tool are provided in the following:

3.2.6.1 Protégé

Protégé was developed as a tool for developing ontologies. Apart from the development

of ontologies, Protégé also supports the customization of data entry forms, and data

entry. It is an open source tool, and provides a knowledge-base framework, based on

Java and which can be extended, via customized Application Programming Interfaces

(API) and Plugins. Extensions can provide different kinds of components, such as;

graphs, tables, images, etc…as well as providing support for different storage formats,

such as; XML, RDF(S), OWL and HTML [54].

The Protégé OWL Plug-in

The Protégé OWL Plug-in is a complex extension of the Protégé tool, which is called

Protégé Core. With Protégé OWL, it is possible to edit OWL ontologies and perform

description logic reasoning, and OWL-related services (classification, consistency

checking and ontology testing).

Formats like RDF(S), OWL Lite, OWL DL, and OWL Full are supported by the Protégé

OWL Plugin. Extensions that include custom tabs and widgets can be added.

Protégé OWL provides a library of reusable components, and a very flexible architecture,

which can be extended in various ways. Protégé OWL, becoming an architecture for the

building of ontology based Semantic Web applications can be foreseen [55].

3.2.6.2 RenamedABox and Concept Expression Reasoner Professional

RenamedABox and Concept Expression Reasoner Professional (RacerPro) is a

Description Logics reasoner, and knowledge representation system. It supports

consistency checking (verifying the possibility of a class having instances and marking out

Page 67: GSM Authentication

An Ontology for Generic Wireless Authentication 67

inconsistent classes), and classification (inferring new concepts, classes, relations, etc…

from the existing asserted concepts) [55] [56].

Inferred concepts correspond, to the deduction of new content and meaning from

existing content (computed concepts). Asserted concepts are concepts which are defined

in a certain domain, (manual definition of concepts).

A knowledge base in description logics consists of, TBoxes (ontologies) that represent

the knowledge of a certain domain, and ABoxes that represent the instances of the

TBoxes domain knowledge.

RacerPro can be used in many application fields, among them are the Semantic Web and

Knowledge Engineering fields [56].

3.2.6.3 Graphical Visualization

GraphViz is an open source visualization software used for representing graphs.

Structured information can be represented as graphs and diagrams. GraphViz takes

graph descriptions from external sources in simple text languages like, XML for example

to generate graphs and diagrams.

GraphViz also supports manual editing of graphs, via test files or with the use of a graph

editor [57].

GraphViz is used in Protégé for visualizing the ontology, in terms of its structured

hierarchy (subclasses and superclasses). It also provides visualization for the asserted and

inferred hierarchies of the ontology.

3.2.7 Protégé-OWL Concepts

Protégé-OWL follows the OWL language constructs in the definition of an ontology, or

knowledge base (which is basically an ontology with instances). A few additional points

to understand, which are not part of the OWL construct are:

• Asserted/Inferred Conditions/Hierarchy/Model

• Necessary and Sufficient/Necessary Conditions

An asserted condition/hierarchy/model is what is manually defined, while creating the

ontology. Asserted models have not undergone any kind of logical classification or

reasoning.

Page 68: GSM Authentication

An Ontology for Generic Wireless Authentication 68

An inferred condition/hierarchy/model is the asserted condition/hierarchy/model after

reasoning has been performed (automatic computation of the assertions). New

information is deducted according to logic in the inferred model, and also classification

checking is performed. The results of information deduction and classification, is the

information that is displayed in the inferred condition/hierarchy/model.

While defining restrictions on classes, a differentiation between necessary conditions and

necessary and sufficient conditions must be made. Necessary conditions relate to

Primitive or Partial classes, while necessary and sufficient conditions relate to Defined or

complete classes.

Defined classes are classes that consist of at least one set of necessary and sufficient

conditions. Necessary and sufficient conditions imply, that the necessary conditions

defined, in order for an individual to qualify in being a member of a class, are not only

necessary for class membership, but are also sufficient for the individuals, satisfying the

conditions in becoming class members.

Primitive classes are classes that consist of at least one set of necessary conditions.

Necessary conditions imply that, certain conditions need to be satisfied, in order for an

individual to become a member of the defined class. It does not imply, however, that any

individual that satisfies the defined conditions must be an individual of the defined class

[53].

3.2.8 Ontology Development

Two issues in ontology development are addressed in this thesis. The first, is the reasons

why anyone would want to develop an ontology, and the second, is the steps involved in

the development of an ontology, and what points should be put into consideration.

3.2.8.1 Why Develop an Ontology

Several reasons exist to develop an ontology, some important reasons could be one of

the following:

• The sharing of common understandings.

• The sharing of information structures.

• The reuse of domain knowledge.

• The analysis of domain knowledge.

Page 69: GSM Authentication

An Ontology for Generic Wireless Authentication 69

• The separation of domain knowledge and operational knowledge [49].

3.2.8.2 Steps in Developing an Ontology

The development of an ontology differs from the traditional object oriented

development, in that object oriented modelling, is based on the operational properties of

a class and its methods. Ontology modelling is based on the structural properties of a

class [49].

There is no right or wrong way for the design and development of an ontology, different

approaches can be used. This thesis concentrates on the following approach:

The first point to consider while developing an ontology, is the domain the ontology is

being developed for. A proper understanding of the intended domain should be

performed, and the definition of the domain’s components, and the relationships that

exist between these components should be clarified.

An ontology defines concepts of the real world, which is a fact that should be put into

consideration in ontology development. Therefore, the concepts defined in the ontology,

must relate to the real concepts and relationships, in the real world domain. It must be

clear what the ontology will be used for in order to decide the details of the ontology.

Ontology development is an iterative process, and should be extensible and maintainable.

The evaluation of an ontology should be performed after its initial design, and the

testing, debugging and discussion of the concepts and relationships should also be

carried out. This is performed, in order to determine whether the ontology actually

describes the intended domain or not. Refinements of the ontology are then carried out,

and the iterative process of ontology development continues throughout the ontology’s

lifecycle.

Ontology development includes the definition of the domain concept (classes) and the

arrangement of these classes in a certain hierarchy. The definition of the properties,

property values, and the definition of the relationships, existing amongst the concepts.

The following lists and describes the steps that could be followed in developing an

ontology:

• The determination of the ontology’s scope and domain.

• The re-usage of existing ontologies.

Page 70: GSM Authentication

An Ontology for Generic Wireless Authentication 70

• The enumeration of the ontology’s important terms

• The definition of classes and its hierarchy.

• The definition of class properties.

• The description of property features.

• The instantiation of class instances.

In determining the scope and domain of an ontology, it is important to think of

questions that will help in constructing the ontology, and defining its main concepts. The

level of detail that the ontology should describe is also a critical issue to consider.

Questions to consider could be:

Q: What should the ontology describe?

Q: Who will the ontology be useful for, and for what purposes?

Q: What kinds of questions should the ontology be able to answer?

The re-usage of ontologies could save a lot of effort, by just taking already existing

ontologies and refining them, or extending them according to the intended use.

The enumeration of terms is helpful in determining the contents of an ontology, e.g. the

enumeration of the concepts the ontology will define, the concepts properties and

characteristics, etc…

Several approaches in defining the class hierarchy could be used, e.g. a top-down

approach; which defines the most general terms first, and then goes down to specializing

each term definition, a bottom-up approach; which defines the specific terms first and

then goes up to the most general term definitions, or a combination of both approaches.

After the definition of the concepts (classes of an ontology) further descriptions can be

given to these concepts, by defining the properties of a concept, and its relationships to

the other concepts in the ontology.

More specialized descriptions can be applied to the properties. This is performed by

describing what types of concepts can exist within another concept, the number of times

a certain property can occur for a concept and so forth.

The last step of the ontology development would be the instantiation of class instances.

An instance is the value filled in for a certain property, of an individual belonging to a

class [49].

Page 71: GSM Authentication

An Ontology for Generic Wireless Authentication 71

Ontologies can be classified and checked for consistency using a reasoner. RacerPro is

one example for an ontology reasoner.

Page 72: GSM Authentication

An Ontology for Generic Wireless Authentication 72

4 An Ontology for Generic Wireless Authentication

The Protégé 3.0 tool with the Protégé-OWL plugin, was used for the development of the

Generic Wireless Authentication Ontology. RacerPro and several older versions of Racer

were used, to classify and create the inferred hierarchy and check for consistencies in the

ontology. For the visualization of the class hierarchy, the GraphViz tool was used along

with the OWLViz plugin.

4.1 Class Overview

The following figure illustrates a general overview of the ontology’s class hierarchy:

Figure 17: Overview of Asserted Ontology Hierarchy

The ontology consists of 14 main classes, which are divided into subclasses. The super

class (not visualized here), is owl:thing which is part of the OWL language defined by the

W3C. It represents the set that contains all individuals. All individuals in an ontology are

subclasses of owl:thing [53].

Page 73: GSM Authentication

An Ontology for Generic Wireless Authentication 73

The main ontology classes are: the Algorithm class, the AuthenticationMethod class, the

AuthenticationType class, the Certificate class, the CertificateComponent class, the Code

class, the Database class, the Identity class, the Key class, the Network class, the Number

class, the Service class, the UserData class and the Subscriber class. These classes are

related to the description of authentication data stored in the profile registers for GSM,

UMTS and WLAN networks and are explained in detail in the following section.

4.2 Ontology Classes and Subclasses

Classes and subclasses describe an is-a relationship. An individual cannot be a subclass of

a certain class if it does not fulfil the is-a relationship. E.g. an A3 algorithm is-a

Algorithm, therefore the A3 individual is a subclass of the Algorithm class.

4.2.1 The Algorithm class

The Algorithm class is the parent class of the authentication specific algorithms, used in

GSM and UMTS networks.

The Algorithm class contains the following subclasses:

• A3

• A8

• f1

• f1_ (corresponds to f1*)

• f2

• f3

• f4

• f5

• f5_ (corresponds to f5*)

The A3 and A8 algorithms represent the authentication algorithms in GSM networks.

The f1 - f5_ algorithms represent the UMTS network algorithms. Details about these

algorithms can be found in sections (2.4.2 and 2.6.2). The Algorithm class is declared as

disjoint from the other classes in the ontology, because an algorithm cannot be the same

Page 74: GSM Authentication

An Ontology for Generic Wireless Authentication 74

individual as any other class in the ontology. (E.g. an Algorithm cannot be a service or an

identity).

4.2.2 The AuthenticationMethod class

The AuthenticationMethod class is the parent class of the authentication types, used in

WLAN networks. It describes some of the EAP authentication methods.

The AuthenticationMethod class contains the following subclasses:

• EAP-SIM

• EAP-TLS

• LEAP

• PEAP

The AuthenticationMethod class is declared disjoint from all of the classes in the

ontology, except for the AuthenticationType class, because an authentication method can

be both an authentication method and an authentication type. E.g. LEAP, which exists in

the AuthenticationMethod class is a password based type of authentication method. The

password based characteristic is a subclass of the AuthenticationType class, therefore,

these two classes cannot be declared as disjoint. More details on the EAP authentication

methods can be found in section (2.10.5.2 ).

4.2.3 The AuthenticationType class

The AuthenticationType class describes the type of authentication an authentication

method can be.

The AuthenticationType class contains the following subclasses:

• CertificateBased

• ChallengeResponse

• MutualAuthentication

• NetworkAuthentication

• PasswordBased

• UserAuthentication

Page 75: GSM Authentication

An Ontology for Generic Wireless Authentication 75

Certificate based authentication is described in section (2.10.3), challenge response

authentication is described in section (2.4.1), mutual authentication means that the type

of authentication is performed on the network side as well as on the user side, network

authentication means that only the network is authenticated, password based

authentication is described in section (2.10.4), and user authentication means that only

the user is authenticated. The AuthenticationType class is declared disjoint from all the

classes in the ontology, except for the AuthenticationMethod class. An authentication

type can be one type of authentication method. However, specific disjoints can be

declared within the members of the AuthenticationType class. More on disjoints in

section (4.3).

4.2.4 The Certificate class

The Certificate class is an empty class that takes individuals of the CertificateComponent

class as values. This is described in the following section.

4.2.5 The CertificateComponent class

The CertificateComponent class describes the components that make out a digital

certificate as described in section (2.10.3).

The CertificateComponent class contains the following subclasses:

• IssuerName

• PublicKey

• SerialNumber

• Signature

• SignatureAlgorithm

• Subject

• ValidFrom

• ValidTo

• Version

Page 76: GSM Authentication

An Ontology for Generic Wireless Authentication 76

4.2.6 The Code class

The Code class describes the codes that are part of the IMSI and MSISDN. Details on

the codes contained in the IMSI and MSISDN can be found in section (2.3.3).

The Code class contains the following subclasses:

• CountryCode

• MobileCountryCode

• MobileNetworkCode

• NationalDestinationCode

4.2.7 The DataBase class

The Database class describes the databases used by the GSM, UMTS, IMS and WLAN

networks. Individuals of other classes are linked to subclasses of the database class, since

several individuals are stored in the databases, defined as children of the database class.

The DataBase class contains the following subclasses:

• AuC

• HLR

• HSS

• UserDatabase

The AuC and HLR are also subclasses of the HSS class, and are later removed from the

hierarchy in the inferred model. This will be discussed later on in this chapter. Details

about the AuC, HLR, HSS and user database can be found in section (2.3.1.1 and 2.7).

4.2.8 The Identity class

The Identity class describes the identities used in the GSM, UMTS, IMS and WLAN

networks.

The Identity class contains the following subclasses:

• IMSI

• NAI

• PrivateUserIdentity

Page 77: GSM Authentication

An Ontology for Generic Wireless Authentication 77

• PublicServiceIdentity

• PublicUserIdentity

• UserNetworkIdentity

• URL

• Realm

• IPAddress

• UserName

The UserNetworkIdentity is the identity used, to identify the user of a network to a

network. The IPAddress and Realm are also used for identification purposes.

Details about the IMSI, NAI, public service, private and public user identities are

described in section (2.7.1).

4.2.9 The Key class

The Key class is subdivided into three subclasses; the DerivedKey class, the

GeneratedKey class and the StaticKey class, which are also sub-classed. The Key class

describes the keys used, in the authentication process of the networks, and that are used

for verification purposes. The DerivedKey class describes the keys that are derived from

other keys, or that result of an algorithm computation. The GeneratedKey class contains

the generated keys, like the RAND and SQN numbers. The StaticKey class, contains the

keys that are static, and that are not created dynamically, like the secret key (Ki) of GSM

and UMTS networks, or the public and private keys of a certificate.

The DerivedKey class contains the following subclasses:

• AK

• AMF

• AUTN

• IK

• Kc

• MAC

Page 78: GSM Authentication

An Ontology for Generic Wireless Authentication 78

• MAC_RAND

• MAC_XRES

• RES

• XMAC

• XRES

The GeneratedKey class contains the following subclasses:

• RAND

• SQN

The StaticKey class contains the following subclasses:

• Ki

• PrivateKey

• PublicKey

4.2.10 The Network class

The Network class is the domain of the ontology modelling. All classes in the ontology

correspond to one or more of the networks described in the network class.

The Network class consists of the following subclasses:

• GSM

• IMS

• UMTS

• WLAN

4.2.11 The Number Class

The Number class describes the numbers associated with the IMSI, IMSDN, and

numbers associated to a public user identity. Details about these numbers can be found

in section (2.3.3).

The Number class contains the following subclasses:

• HLRNumber

Page 79: GSM Authentication

An Ontology for Generic Wireless Authentication 79

• MSISDN

• MobileSubscriberIdentificationNumber

• SubscriberNumber

• IndividualSubscriberNumber

• FixedTelephoneNumber

4.2.12 The Service class

Three types of services are distinguished in the Service class, namely; basic services,

supplementary services, and multimedia services. The Service class describes the types of

services available for a subscriber. Multimedia services are available for UMTS and

WLAN networks and include several services like the Multimedia Messaging Service

(MMS).

The BasicService class contains the following subclasses:

• SMS

• Speech

The SupplementaryService class contains the following subclasses:

• CallBarring

• CallDivert

• CallWaiting

• ConferenceCall

• CustomerCareBilling

• DataService

The MutlimediaService subclass contains the following subclasses:

• AudioDownload

• AudioStream

• MMS

• VideoDownload

Page 80: GSM Authentication

An Ontology for Generic Wireless Authentication 80

• VideoStream

• WebBrowsing

4.2.13 The UserData class

The UserData class describes personal user data needed for a subscription to a mobile

service (GSM, UMTS or WLAN). Information includes banking details, personal details

(name, address, etc…). Session duration, also a subclass of the UserData class is used to

record the duration of usage and is used for billing purposes in WLAN networks. The

Password subclass of the UserData class is associated with the AuthenticationType class

for password based authentication.

The UserDataClass contains the following Subclasses:

• AccountHolder

• AccountNumber

• BankCity

• BankCode

• BankCountry

• City

• Country

• FirstName

• HouseNumber

• LastName

• Password

• PostalCode

• SessionDuration

• State

• StreetName

Page 81: GSM Authentication

An Ontology for Generic Wireless Authentication 81

4.2.14 The Subscriber class

The Subscriber class is an empty class that uses individuals of other classes as its values.

E.g. using a property it can be used to describe that a subscriber is a subscriber of a

certain service.

4.3 Disjoint Classes

The following figure illustrates a snapshot of the Protégé-OWL tool, and the disjoint

classes declared for the CertificateComponent class:

Figure 18: Disjoint Classes

In developing an ontology it is important to notice which classes should be declared as

disjoint and which should not. Inconsistency errors occur, if classes that should logically

not be disjoint, are declared as disjoint from each other. Disjointness means that one

class cannot be the same as the other class, or have the same meaning. E.g. a Network is

not a Database, therefore, the Network class must be declared as disjoint from the

Database class, otherwise the reasoner understands that a Network is a Database.

Page 82: GSM Authentication

An Ontology for Generic Wireless Authentication 82

When a class is not disjoint it expresses an is-a relationship. E.g. An authentication

method is-a authentication type.

Disjointness can be applied to a class as a whole, or to parts of a class. Specifying that

only part of the class is disjoint from another class, or vice-versa.

A subclass inherits its disjointness to other classes, from its super class and cannot be

disjoint from its super class. Logical errors occur in the ontology, when checking for

consistency. An error is generated, if a subclass is declared as disjoint from its super class.

The following section goes into detail about the disjointness of the classes in the

ontology:

4.3.1 The Algorithm class disjoints

The Algorithm class is disjoint from all the classes in the ontology, except for the

SignatureAlgorithm subclass of the CertificateComponent class. A SignatureAlgorithm is

also an Algorithm, it is not declared as disjoint from the Algorithm class for this reason.

All subclasses of the Algorithm class, namely (A3, A8, f1, f1_, f2, f3, f4, f5 and f5_) are

disjoint from each other, and are also disjoint from the SignatureAlgorithm class. An A3

algorithm is not an A8 algorithm, this case also holds for the other members of the class.

A SignatureAlgorithm is not an A3 algorithm.

4.3.2 The AuthenticationMethod class disjoints

The AuthenticationMethod class is disjoint from all classes in the ontology, except for

the AuthenticationType class. An authentication method e.g. EAP-SIM is an

authentication type e.g. ChallengeResponse type.

4.3.2.1 The EAP-SIM subclass

The EAP-SIM subclass is disjoint from all its siblings (an EAP-SIM method is not an

EAP-TLS method for example). It is also disjoint from the following subclasses of the

AuthenticationType class; CertificateBased, PasswordBased, NetworkAuthentication and

UserAuthentication. This is because EAP-SIM is neither a certificate based, password

based, network authentication or user authentication type of authentication. What is

meant by user and network authentication is that, the authentication method only

authenticates the user, or only authenticates the network.

Page 83: GSM Authentication

An Ontology for Generic Wireless Authentication 83

EAP-SIM is not disjoint from the ChallengeResponse and MutualAuthentication classes,

because EAP-SIM is a challenge response type of authentication method. It performs

mutual authentication of the network and the user.

4.3.2.2 The EAP-TLS subclass

The EAP-TLS subclass is disjoint from all its siblings (EAP-SIM, LEAP and PEAP). It is

also disjoint from the PasswordBased, ChallengeRepsonse, and UserAuthentication

subclasses of the AuthenticationType class. EAP-TLS does not perform any

authentication, based on password, or challenge response mechanisms. It does not

authenticate the user of a network.

Classes that are not declared disjoint from the EAP-TLS class are; the CertificateBased,

MutualAuthentication and NetworkAuthentication classes. EAP-TLS authentication is

based on certificates. It performs mutual authentication of the network and user, and it

also authenticates the network only in conjunction with the PEAP authentication

method.

4.3.2.3 The LEAP subclass

The LEAP subclass is disjoint from all its siblings, and is also disjoint from the

CertificateBased and NetworkAuthentication subclasses of the AuthenticationType class.

LEAP is a certificate based type of authentication, and it does not authenticate the

network only (i.e. it provides mutual authentication of the client and network).

The classes that are not disjoint from the LEAP class are; the ChallengeResponse,

MutualAuthentication, PasswordBased and UserAuthentication classes. LEAP is a

password based type of authentication. In this type of password based authentication, a

challenge is sent in return for a response. This is performed in order to calculate the same

secret, which enables a user to be authenticated. LEAP performs mutual authentication

of the network and user, and also performs authentication of the user only in

conjunction with PEAP authentication.

4.3.2.4 The PEAP subclass

The PEAP subclass is disjoint from all its siblings (EAP-TLS, LEAP and EAP-SIM). It is

not disjoint from any member of the AuthenticationType class, since the PEAP method

is a certificate type of authentication method. It performs mutual authentication, it uses

Page 84: GSM Authentication

An Ontology for Generic Wireless Authentication 84

the EAP-TLS to authenticate the network, and any type of EAP method to authenticate

the user. Network only authentication, user only authentication, password based

authentication and challenge response type of authentication are supported by this class.

4.3.3 The AuthenticationType class disjoints

The AuthenticationType class is disjoint from all the classes in the ontology, except for

the AuthenticationMethod class. The concept behind the classes being disjoint from each

other or not is the same as that for the AuthenticationMethod classes, except that it is in

reverse order.

4.3.3.1 The CertificateBased subclass

The CertificateBased subclass is disjoint from all its siblings, (a certificate based type of

authentication is not a password based type of authentication or a challenge response

type of authentication, etc…). It is also disjoint from the EAP-SIM and LEAP classes.

The CertificateBased subclass is not disjoint from the EAP-TLS and PEAP classes.

4.3.3.2 The ChallengeResponse subclass

The ChallengeResponse subclass is disjoint from all its siblings, (MutualAuthentication,

CertificateBased, etc…). It is also disjoint from the EAP-TLS class.

The ChallengeResponse subclass is not disjoint from the EAP-SIM, LEAP and PEAP

classes.

4.3.3.3 The MutualAuthentication subclass

The MutualAuthentication subclass is disjoint from all its siblings. It is not disjoint from

any of the AuthenticationMethod subclasses, since all the authentication methods

described in the AuthenticationMethod class perform mutual authentication.

4.3.3.4 The NetworkAuthentication subclass

The NetworkAuthentication subclass is disjoint from all its siblings and from the EAP-

SIM and LEAP classes. It is not disjoint from the PEAP and EAP-TLS classes, since

these methods can perform authentication of only the network.

4.3.3.5 The PasswordBased subclass

Page 85: GSM Authentication

An Ontology for Generic Wireless Authentication 85

The PasswordBased subclass is disjoint from all its siblings, from the EAP-TLS, and

EAP-SIM classes. It is not disjoint from the PEAP and LEAP classes, since password

based authentication is what LEAP is based on, and PEAP can use an EAP password

based method to authenticate the user.

4.3.3.6 The UserAuthentication subclass

The UserAuthentication subclass is disjoint from all its siblings, from the EAP-TLS, and

EAP-SIM authentication methods. It is not disjoint from the PEAP or LEAP classes,

since these methods provide authentication of the user only, in conjunction with PEAP

authentication.

4.3.4 The Certificate class disjoints

The Certificate class is disjoint from all the classes in the ontology, since no other class in

the ontology is-a Certificate.

4.3.5 The CertificateComponent class disjoints

The CertificateComponent class is disjoint from all classes in the ontology, except for the

Public Key subclass of the StaticKey subclass of the Key class. A public key is both a

certificate component and a static key, therefore they are not declared as disjoint from

each other. The PublicKey class has two super classes: the CertificateComponent class

and the StaticKey class.

4.3.5.1 The IssuerName, SerialNumber, Signature, Subject, ValidFrom, ValidTo

and PublicKey subclasses

The IssuerName, SerialNumber, Signature, Subject, ValidFrom and ValidTo subclasses,

are all disjoint from each other and their siblings. Nothing can be an issuer name and a

serial number for example.

These subclasses classes are also disjoint from the Algorithm class, since the algorithm

class is not declared as disjoint from the CertificateComponent class.

4.3.5.2 The SignatureAlgorithm subclass

The SignatureAlgorithm subclass is disjoint from all its siblings, and from the subclasses

of the Algorithm class. Nothing can be a SignatureAlgorithm and a A3 algorithm.

Page 86: GSM Authentication

An Ontology for Generic Wireless Authentication 86

4.3.6 The Code class disjoints

The Code class is disjoint from all the classes, except for the Number class. A code is-a

number, therefore it is not declared as disjoint from the number class. The subclasses of

the code class are all disjoint from each other, and also the subclasses of the number class

are disjoint from the subclasses of the code class. E.g. The CountryCode subclass of the

Code class is disjoint from the MSISDN subclass, of the number class, because a country

code is not an MSISDN number.

4.3.7 The Database class disjoints

The Database class is disjoint from all classes in the ontology, no class in the ontology,

except for the subclasses of the class DataBase is-a database. The subclasses of the

DataBase class are disjoint from each other. A HLR database is not a user database, an

authentication database or a home subscriber server database.

4.3.8 The Identity class disjoints

The Identity class is disjoint from all classes of the ontology, except for the UserData

class. An identity can represent user data; therefore the classes are not disjoint from each

other. The subclasses of the Identity class are all disjoint from each other e.g. an IMSI is

not a NAI. Subclasses of the UserData class are also disjoint from the subclasses of the

Identity class. A password for example is not a public user identity.

4.3.9 The Key class disjoints

The Key class is disjoint from all the classes in the ontology, except for the PublicKey

class of the CertificateComponent class.

4.3.9.1 The DerivedKey subclass

The DerivedKey subclass is disjoint from all of its siblings, (GeneratedKey class and

StaticKey class). The subclasses of the DerivedKey class are also disjoint from each

other.

4.3.9.2 The GeneratedKey subclass

The GeneratedKey class is disjoint from its siblings, (DerivedKey class and StaticKey

class). The subclasses of the GeneratedKey class are also declared as disjoint from each

other.

Page 87: GSM Authentication

An Ontology for Generic Wireless Authentication 87

4.3.9.3 The StaticKey subclass

The StaticKey class, as the DerivedKey and GeneratedKey classes is disjoint from its

siblings. The subclasses of the StaticKey class are also disjoint from each other.

4.3.10 The Network class disjoints

The Network class is disjoint from all the classes in the ontology. A network is not any

other type of concept declared in the ontology, therefore it must be declared as disjoint

from all the other classes.

4.3.11 The Number class disjoints

The Number class is disjoint from all the classes in the ontology, except for the Code

class. A number is-a code and is therefore not declared as disjoint from the code class.

The subclasses of the number class are all disjoint from each other, and the subclasses of

the code class are also disjoint from the subclasses of the number class.

4.3.12 The Service class disjoints

The Service class is disjoint from the other classes in the ontology. A Service is not any

other type of concept defined in the ontology, therefore it is declared as disjoint.

4.3.12.1 The BasicService subclass

The BasicService subclass is disjoint from the SupplementaryService subclass and its

subclasses. Nothing can be both a BasicService and a SupplementaryService.

4.3.12.2 The SupplementaryService subclass

The SupplementaryService subclass is disjoint from the BasicService subclass, for the

same reason mentioned above. The subclasses of the Supplementary subclass are also

disjoint from each other. E.g. the CallBarring and CallDivert subclasses are disjoint from

each, other because a call barring service is not a call diverting service.

4.3.12.3 The MultimediaService subclass

The MutilmediaService subclass also contains subclasses, which are all disjoint from each

other. E.g. the VideoDownload and AudioDownload subclasses are disjoint from each

other, because a video download service is not an audio download service.

Page 88: GSM Authentication

An Ontology for Generic Wireless Authentication 88

4.3.13 The UserData class disjoints

The UserData class is disjoint from all classes of the ontology, except for the Identity

class. User data can represent an Identity, therefore the UserData class and the Identity

class are not disjoint from each other. Subclasses of the UserData class are disjoint from

each other. Subclasses of the Identity class are also disjoint from the subclasses of the

UserData class.

4.4 Inconsistencies from Disjoint classes

Declaring classes as disjoint could result in reasoning errors that state that a class is

inconsistent. For example, the following figure illustrates an inconsistency in the

PublicKey class.

Figure 19: Incorrect disjoint definition - Inconsistent class

This inconsistency appeared because the Key and CertificateComponent class were

declared as super classes of the PublicKey class. At the same time, the whole

CertificateComponent class was declared as disjoint from the Key class.

Page 89: GSM Authentication

An Ontology for Generic Wireless Authentication 89

The solution to this problem was to make sure that the PublicKey class was not declared

as disjoint in the Key class, and also in the CertificateComponent class.

4.5 Class Properties

Properties link two individuals together, by describing a certain relationship between

them.

The Ontology consists of some of the following properties and inverse properties that

describe how classes are related to each other: (Appendix A lists all the properties in the

ontology)

4.5.1 hasIdentity ↔ isIdentityOf

The hasIdentity property describes that an individual, has the value of another individual

as its identity. The inverse property describes that an individual is an identity of another

individual.

4.5.2 hasNetworkIdentity ↔ isNetworkIdentityOf

The hasNetworkIdentity property describes that one individual or more, has the value of

another individual or more as its network identity. The inverse property implies the same,

but in reverse order (i.e. an individual is the network identity of another individual).

4.5.3 hasUserName ↔ isUserNameOf

The hasUserName property describes that an individual, has the value of another

individual as its user name. The inverse property describes that an individual is a user

name of another individual.

4.5.4 hasAuthenticationMethod ↔ isAuthenticationMethodOf

The hasAuthenticationMethod property describes that one or more individuals, are

related to one or more other individuals via this property. It means that an individual has

another individual, with an authentication method as it value via the

hasAuthenticationMethod property. The inverse property implies that an individual is an

authentication method of another individual.

Page 90: GSM Authentication

An Ontology for Generic Wireless Authentication 90

4.5.5 hasAuthenticationType ↔ isAuthenticationTypeOf

The hasAuthenticationType property, describes that an individual, has the value of

another individual as its authentication type. The inverse property, describes that an

individual, is an authentication type of another individual.

4.5.6 hasCertificate ↔ isCertificateOf

The hasCertificate property, describes that an individual, has the value of another

individual as its certificate. The inverse property describes that an individual, is a

certificate of another individual.

4.5.7 hasPassword ↔ isPasswordOf

The hasPassword property, describes that an individual, has the value of another

individual as its password. The inverse property, describes that an individual, is a

password of another individual.

4.5.8 hasBasicService ↔ isBasicServiceOf

The hasBasicService property, describes that an individual, has the value of another

individual as its basic service. The inverse property, describes that an individual, is a basic

service of another individual.

4.5.9 hasSupplementaryService ↔ isSupplementaryServiceOf

The hasSupplementaryService property, describes that an individual, has the value of

another individual as its supplementary service. The inverse property, describes that an

individual, is a supplementary service of another individual.

4.5.10 hasDatabase ↔ isDatabaseOf

The hasDatabase property, describes that an individual, has the value of another

individual as its database. The inverse property, describes that an individual is a database

of another individual.

Page 91: GSM Authentication

An Ontology for Generic Wireless Authentication 91

4.5.11 hasChallenge ↔ isChallengeOf

The hasChallenge property, describes that an individual, has the value of another

individual as its challenge. The inverse property, describes that an individual, is a

challenge of another individual.

4.5.12 hasSecretKey ↔ isSecretKeyOf

The hasSecretKey property, describes that an individual, has the value of another

individual as its secret key. The inverse property, describes that an individual, is a secret

key of another individual.

4.5.13 hasExpectedResponse ↔ isExpectedResponseOf

The hasExpectedResponse property, describes that an individual, has the value of

another individual as its expected response. The inverse property, describes that an

individual, is an expected response of another individual.

4.5.14 hasTriplets ↔ isTripletsOf

The hasTriplets property, describes that an individual, has the value of other individuals

as its triplets. The inverse property, describes that individuals, are triplets of another

individual.

4.5.15 hasInput ↔ isInputOf

The hasInput property, describes that an individual, has the value of another individual as

its input. The inverse property, describes that an individual, is an input of another

individual.

4.5.16 hasOutput ↔ isOutputOf

The hasOutput property, describes that an individual, has the value of another individual

as its output. The inverse property, describes that an individual, is an output of another

individual.

Page 92: GSM Authentication

An Ontology for Generic Wireless Authentication 92

4.5.17 hasNumber ↔ isNumberOf

The hasNumber property, describes that an individual, has the value of another

individual as its number. The inverse property, describes that an individual, is a number

of another individual.

4.5.18 hasSubscriber ↔ isSubscriberOf

The hasSubscriber property, describes that an individual, has the value of another

individual as its subscriber. The inverse property, describes that an individual, is a

subscriber of another individual.

4.5.19 Stores ↔ isStoredIn

The Stores property, describes that an individual, stores the value of another individual.

The inverse property, describes that an individual, is stored by another individual.

4.5.20 hasAlgorithm ↔ isAlgorithmOf

The hasAlgorithm property, describes that an individual, has the value of another

individual as its algorithm. The inverse property, describes that an individual, is an

algorithm of another individual.

4.6 Identification of a new is-a relationship

After the definition of the class properties, a new is-a relationship was identified. This

relationship should have been expressed in a super class – subclass relationship.

The NAI is an Identity, and belongs to the Identity class. However, the NAI is also a

Private user Identity and must therefore be a subclass of the class PrivateUserIdentity.

Thus NAI has two super classes, namely Identity and PrivateUserIdentity.

The ontology process continues in this manner, with the identification of new concepts

and new hierarchies. It is an iterative process.

Page 93: GSM Authentication

An Ontology for Generic Wireless Authentication 93

4.7 Initial ontology tests and reasoning

Until this point, only the classes and properties of the ontology have been defined. Initial

testing and reasoning of the ontology is performed, which checks whether the properties

have been well defined and also checks for the consistencies between classes of the

ontology.

The following figures illustrate a list of errors generated from the ontology tests and from

reasoning:

Figure 20: Ontology tests and reasoning results

The NAI is inconsistent due to the fact that it was identified and declared as a subclass of

the PrivateUserIdentity and that it is still disjoint from its siblings. Removing the disjoint

characteristic from the NAI makes the class consistent. Inconsistent classes are marked

with a red circle around the class name.

Page 94: GSM Authentication

An Ontology for Generic Wireless Authentication 94

4.8 Property Restrictions and Defining Classes

Classes are described and defined by creating restrictions on the defined properties.

Properties restrict the individuals that belong to a specific class, thus enabling the

description of the characteristics of a class.

A class restriction takes the following form; (the class name (the restriction, the property,

the filler)). The class name is the class that the restriction is defined for, the restriction

can be either one of the following (an existential quantifier, a universal quantifier, a has

value restriction, equal cardinality, minimum or equal cardinality and maximum or equal

cardinality) the property is any property defined for the classes, and the filler can be a

class and individual or instance of a class or a data type).

The following, explains in detail some classes and how they are defined:

4.8.1 Restrictions defining the f1 class

The following figure illustrates the conditions defined for the f1 class:

Figure 21: f1 Class Restrictions

Page 95: GSM Authentication

An Ontology for Generic Wireless Authentication 95

The f1 class belongs to the Algorithm class, which means that f1 is an algorithm. The f1

algorithm has an AMF as its authentication management field, and all authentication

management fields are AMF, this is described with the; f1(∀

hasAuthenticationManagementField AMF) expression. Where ∀, expresses a universal

quantifier, and in this case means “only” (only AMF as an authentication management

field). The hasAuthenticationManagementField is the property, and the AMF is a class,

which is a subclass of the DerivedKey class.

The f1 class, only has the XMAC key as its expected message authentication code; f1(∀

hasExpectedMessageAuthenticationCode XMAC). And only the MAC key as its message

authentication code; f1(∀ hasMessageAuthenticationCode MAC). It only has the Ki Key

as its secret key, only the RAND key as its random number, and only the SQN key as its

sequence number; f1(∀ hasSecretKey Ki,, ∀ hasRandNumber RAND, (∀

hasSequenceNumber SQN). This relationship, can also be described as; f1(hasSecretKey

(allValuesFrom Ki, hasRandNumber allValuesFrom RAND, hasSequenceNumber

allValuesFrom SQN).

The f1 class has only SQN “AND” AMF “AND” Ki “AND” RAND keys as its inputs,

this is expressed by the following expression; f1(∀ hasInput SQN, ∀ hasInput AMF, ∀

hasInput Ki, ∀ hasInput RAND), or; f1(hasInput (allValuesFrom SQN, allValuesFrom

AMF, allValuesFrom Ki, allValuesFrom RAND)).

The f1 class is only an algorithm of the UMTS network, this is expressed as f1(∀

isAlgorithmOf UMTS), or; f1(isAlgorithmOf (allValuesFrom UMTS). The f1 class is

stored in BOTH the AuC, and the HSS; f1(∀ isStoredIn AuC, ∀ isStoredIn HSS), or;

f1(isStoredIn (allValuesFrom AuC, allValuesFromHSS).

The output of the f1 class can be either the XMAC key or the MAC key, this is expressed

by the following expression; f1(∃ hasOutput XMAC ⊔ MAC), or f1(someValuesFrom

XMAC ⊔ MAC).

Page 96: GSM Authentication

An Ontology for Generic Wireless Authentication 96

4.8.2 Restrictions defining the EAP-SIM class

The following figure illustrates the conditions defined for the EAP-SIM class:

Figure 22: EAP-SIM Class Restrictions

The EAP-SIM class belongs to the AuthenticationMethod class. This indicates that EAP-

SIM is an authentication method. The EAP-SIM class has a challenge response and a

mutual authentication type of authentication. This is expressed by; EAP-SIM(∀

hasAuthenticationType ChallengeRepsonse, ∀ hasAuthenticationType

MutualAuthentication) or; EAP-SIM(hasAuthenticationType (allValuesFrom

ChallengeRepsonse, allValuesFrom MutualAuthentication).

The EAP-SIM class, has the RAND and MAC keys as its challenge, and the

MAC_RAND and MAC_XRES keys as its challenge response, this is expressed by;

EAP-SIM(∀ hasChallenge RAND, ∀ hasChallenge MAC) or EAP-SIM(hasChallenge

(allValuesFrom RAND, allValuesFrom MAC)) and EAP-SIM(∀ hasChallengeResponse

MAC_RAND, ∀ hasChallengeResponse MAC_XRES) or; EAP-

Page 97: GSM Authentication

An Ontology for Generic Wireless Authentication 97

SIM(hasChallengeResponse (allValuesFrom MAC_RAND, allValuesFrom MAC_XRES)

respectively.

The MAC_RAND, the random message authentication code and MAC_XRES, the

expected response message authentication code, are described in the EAP-SIM class by

EAP-SIM(∀ hasRandomMessageAuthenticationCode MAC_XRES) and EAP-SIM(∀

hasExpectedResponseMessageAuthenticationCode MAC_RAND) respectively.

The UserNetworkIdentity is the network identity of an EAP-SIM method. This

restriction is defined in the following way; EAP-SIM(∀ hasNetworkIdentity

UserNetworkIdentity).

The triplets (RAND “AND” Kc “AND” XRES) are the triplets used by the EAP-SIM

method. This is expressed by; EAP-SIM (∀ hasTriplets RAND, ∀ hasTriplets Kc, ∀

hasTriplets XRES).

The EAP-SIM method is an authentication method of BOTH GSM and WLAN

networks; this is expressed by; EAP-SIM(∀ isAuthenticationMethodOf GSM, ∀

isAuthenticationMethodOf WLAN).

Page 98: GSM Authentication

An Ontology for Generic Wireless Authentication 98

4.8.3 Restrictions defining the Subscriber class

The following figure illustrates the conditions defined for the Subscriber class:

Figure 23: Subscriber Class Restrictions

The Subscriber class only has individuals, as user data that belong to the UserData class.

The UserData class contains all personal details of a user, e.g. first name, last name,

address, country, etc…The following expression describes that the subscriber class only

has UserData individuals, as its user data; Subscriber(∀ hasUserData UserData).

A subscriber has a user name, IMSI and UserNetworkIdentity as identities. This is

expressed by; Subscriber(∀ hasIdentity UserName, ∀ hasIdentity IMSI, ∀ hasIdentity

UserNetworkIdentity). A subscriber has a public user identity; Subscriber(∀

hasPublicUserIdentity PublicUserIdentity), and a private user identity; Subscriber(∀

hasPrivateUserIdentity PrivateUserIdentity).

Page 99: GSM Authentication

An Ontology for Generic Wireless Authentication 99

A subscriber is subscribed to basic, supplementary and multimedia services; Subscriber(∀

isSubscribedTo BasicService, ∀ isSubscribedTo SupplementaryService, ∀ isSubscribedTo

MultimediaService).

A subscriber is a subscriber of GSM, UMTS and WLAN networks; Susbscriber(∀

isSubscriberOf UMTS, ∀ isSubscriberOf GSM, ∀ isSubscriberOf WLAN).

4.8.4 Restrictions defining the IMSI class

The following figure illustrates the conditions defined for the IMSI class:

Figure 24: IMSI Class Restrictions

The IMSI class is a member of the Identity class, meaning that an IMSI is an identity.

The IMSI has a mobile station ISDN number as its number; IMSI(∀ hasNumber

MSISDN). The IMSI is made up of the following parts; the mobile station identification

Page 100: GSM Authentication

An Ontology for Generic Wireless Authentication 100

number, and the mobile network code and the mobile country code. This is expressed by

IMSI(∀ hasPart MobileStationIdentificationNumber, ∀ hasPart MobileNetworkCode, ∀

hasPart MobileCountryCode).

The IMSI is an identity of a subscriber and is part of a user network identity, this is

expressed by; IMSI(∀ isIdentityOf Subscriber) and; IMSI(∀ isPartOf

UserNetworkIdentity) respectively.

The IMSI is stored in the HLR, AuC and the HSS, this is expressed by IMSI(∀

isStoredIn HLR, ∀ isStoredIn AuC, ∀ isStoredIn HSS).

Page 101: GSM Authentication

An Ontology for Generic Wireless Authentication 101

4.9 Asserted and Inferred Hierarchy

An asserted hierarchy is a manually defined view of the ontology. When classifying an

ontology with a resoner, the reasoner performs automatic computation of the defined

ontology and creates an inferred hierarchy of the ontology.

The following figure illustrates the asserted and inferred hierarchy in the ontology:

Figure 25: Asserted and Inferred Hierarchy

In the inferred hierarchy, the NAI is now the subclass of the PrivateUserIdentity class,

this is because in the asserted hierarchy it was defined to be a child of both the

PrivateUserIdentity, and the Identity class, which is a super class of the

PrivateUserIdentity class. The changes are marked in blue in the inferred hierarchy.

Page 102: GSM Authentication

An Ontology for Generic Wireless Authentication 102

5 Installation and Testing

5.1 Installation Guidelines

In order to create the ontology, an editor to edit ontologies was needed. The ontology

editor used for this thesis was the Protégé Tool version 3.0 available from

protégé.stanford.edu.

The Racer tool was used for reasoning and classification of the ontology. Several versions

of the racer tool exist; the current version is RacerPro available from www.racer-

systems.com. For the purpose of this thesis the racer reasoner version 1.7.23

For the graph visualization of the ontology, the GraphViz tool and the OWL-Viz plug-in

were used. GraphViz is available at http://www.graphviz.org/ and the OWL-Viz plug-

in is a component of the Protégé OWL plug-in from protégé.stanford.edu.

The installation of the Protégé tool is simple; after following the installation procedures

that appear on the screen, the editing tool is ready for use. For visualization, the

GraphViz Tool should be installed (follow screen instructions) and the OWL-Viz plugin

should configured to be used, this is done in the Protégé editor by clicking on Project

Configure… and selecting the OWL-Viz Tab, and clicking on the OK button.

Racer is a .exe file, which should be run with Protégé or when classifying the ontology is

required. RacerPro can only be used upon registration and upon obtaining a license.

5.2 Loading the Ontology

Two types of files for the generic wireless authentication ontology, namely a file with an

extension of .owl, which is the file described in the Web Ontology Language and a file

with an extension of .pprj, which is the protégé project file.

To load the .pprj file, simply click on File Open and choose the file from the

appropriate directory.

To load the .owl file, click on File Build New Project and then select the owl file from

the appropriate directory.

Page 103: GSM Authentication

An Ontology for Generic Wireless Authentication 103

5.3 Encountered Problems

The following describes some of the problems encountered while developing the

ontology:

5.3.1 Enumerated Classes

It was not possible to define an enumerated class. The complete ontology was

inconsistent upon the execution of the reasoner. The reason for the inconsistent

ontology was because of the definition of two enumerated classes as follows:

The f1AuCInput class, which was an enumerated class containing the inputs of the f1

algorithm on the AuC side. And the f1USIMInput class, which was an enumerated class

containing the inputs of the f1 algorithm on the USIM side. The intention of this was to

define a union of the f1 algorithm inputs, which takes the value of either the enumerated

class f1AuCInput class, or the enumerated class f1USIMInput.

Upon classification of the ontology (the execution of the reasoner), the ontology was

classified as an OWL-FULL ontology, and not as an OWL-DL ontology, therefore the

whole ontology was classified as inconsistent.

Page 104: GSM Authentication

An Ontology for Generic Wireless Authentication 104

The following figure illustrates the generated error:

Figure 26: Enumerated Classes and OWL-FULL Error

The ontology became consistent again after the removal of the enumerated classes.

5.3.2 Defining values for properties instead of individuals

A private user identity, consists of a user name, the “@” sign and the realm

(username@realm). Restrictions for the PrivateUserIdentity class have been defined, to

identify the parts belonging to a private user identity. The following expressions are some

definitions of the PrivateUserIdentity class; PrivateUserIdentity(∀ hasPart UserName, ∀

hasPart Realm. When defining an additional restriction, stating that the “@” sign is also

part of the PrivateUserIdentity as follows; PrivateUserIdentity(∀ hasPart “@”) an

inconsistency in the ontology occurred. This inconsistency stated that the ontology was

classified as an OWL-FULL ontology, and not as an OWL-DL ontology.

The following figure illustrates the generated error:

Page 105: GSM Authentication

An Ontology for Generic Wireless Authentication 105

Figure 27: Defining a value for an Object Property - OWL FULL Error

5.3.3 allValuesFrom, someValuesFrom and Disjoint classes

Several inconsistencies appeared in the ontology when trying to define classes with the

someValuesFrom restriction.

For example, an inconsistency occurred, when defining that the PEAP class has an

authentication type that can be either password based, or challenge response based

authentication types, using the someValuesFrom restriction.

The expression was as follows; PEAP(∃ hasAuthenticationType (PasswordBased ⊔

ChallengeResponse)). This expression returned an inconsistency in the PEAP class.

However, when using the allValuesFrom restriction for the password based and

challenge response base classes, the PEAP class was no longer inconsistent. PEAP(∀

hasAuthenticationType PasswordBased, ∀ hasAuthenticationType ChallengeResponse).

Page 106: GSM Authentication

An Ontology for Generic Wireless Authentication 106

The same rule holds when trying to define that the f1 algorithm can be stored in either

the AuC or the HSS. f1(∃ isStoredIn (AuC ⊔ HSS), this rule returns an inconsistency.

Therefore, it was defined that the f1 algorithm is stored in BOTH the AuC and the HSS.

This type of error also occurred, if classes were declared as disjoint from each other.

When removing the disjointness of classes, it was possible to define some restrictions

with the someValuesFrom restriction. An example of which is given;

The A3 and f2 algorithms generate the responses XRES and RES on the AuC and USIM

side respectively. When defining that the A3 algorithm takes either XRES, or RES as its

output value, via the following expression; A3(∃ hasOutput XRES ⊔ RES) the A3 class

was consistent. However, when defining the same rule for the f1 algorithm; f1(∃

hasOutput XRES ⊔ RES) an inconsistency in both the A3 and f1 algorithm classes arose.

This was because the A3 and f1 algorithms were declared as disjoint from each other.

When removing the disjointness of the A3 and f1 algorithm, the reasoner did not classify

these classes as inconsistent. However, an A3 algorithm is not an f1 algorithm; therefore

they must be defined as disjoint.

5.3.4 Defining Cardinalities

Inconsistencies in the PrivateUserIdentity, PublicUserIdentity and PublicServiceIdentity

classes occurred, when defining cardinalities for each class.

The definition that a subscriber can have only one private user identity, and one or more

public user identities, was not possible without returning any inconsistencies.

The following rule was defined; Subscriber(= hasPrivateUserIdentity =1) and

Subscriber(≥ hasPublicUserIdentity ≥ 1) this rule did not hold true.

Another attempt, was to define that each multimedia service is assigned to exactly one

public service identity, the following rule was defined; MultimediaService(=

hasPublicServiceIdentity =1) this rule did not hold true as well, and resulted in an

inconsistency.

Page 107: GSM Authentication

An Ontology for Generic Wireless Authentication 107

6 Summary and Conclusions

6.1 Summary

This thesis addressed the issues of the current status in telecommunication networks

today, and discussed an approach of how to better restructure telecommunication

networks, in order to achieve less complexity and better data management. It also

addressed the separation of data, from the applications and proposed a common view

and understanding of physically and logically storing the data. In particular subscriber

data, which today, is distributed among several network nodes, and is not accessible by all

applications. Therefore, the Next Generation Profile Register was introduced as one

method of restructuring telecommunication networks today.

Providing a logical description of subscriber data was the motivation of this thesis. The

domains concerned for modelling the subscriber data, were the authentication specific

data of a certain subscriber in GSM, UMTS and WLAN networks.

The analysis of GSM, UMTS and WLAN networks was performed, especially in terms of

authentication, and in terms of what parameters of a subscriber is stored, and in which

profile registers.

In order to describe the data, it was also necessary to understand the relationships

between subscriber data, stored in the registers. It was also necessary to provide a

meaning for each term by defining rules.

Evaluation of different modelling methods was also performed. The decision of

describing the data in a semantic way was taken and in particular, using the OWL

language, due to the way data can be logically described, related and shared among a

particular domain. Therefore, the analysis of the Semantic Web, and the approaches used

to describe data via the semantic web were also analysed. For the purpose of this thesis,

the Web Ontology Language was chosen to describe the data using the Protégé Tool.

The description of data was performed, by building an ontology, which is a knowledge

base that describes data. The domain of GSM, UMTS and WLAN networks was broken

down into classes and properties, each class representing a concept, and each property

representing a link between the concepts. The definition of each class, was performed by

Page 108: GSM Authentication

An Ontology for Generic Wireless Authentication 108

defining restrictions for each class, indicating how classes are related to each other and

which individuals can belong to a certain class.

The ontology provides a logical description of the data, stored in profile registers of

GSM, UMTS and WLAN networks in one logical view.

Testing of the ontology was performed using a reasoning tool named Racer, which was

used to classify the ontology, and to check for inconsistencies in the ontology.

Using OWL to describe data provides better expressivity of data in comparison to other

modelling techniques. It also enables the re-use and sharing of data among domains, and

enables an easier translation of data between systems. This simplifies the complexity of

managing data between systems in current networks today, and solves the problem of

closed vendor specific systems. It also enables an easier integration of data from several

other domains and for the integration of future networks.

6.2 Further research

The ontology describes authentication specific data for GSM, UMTS and WLAN data.

However, subscriber data stored in WLAN networks needs to be further analysed,

further defined, and further described in the ontology. The relationships between the

concepts also need to be verified from an external point of view, and several discussions

upon the approach for defining the ontology from a domain expert point of view needs

to be performed [49].

Description of other types of data, in the above mentioned domains also needs to be

integrated into the ontology. E.g. data related to specific applications, location

management, etc…

Page 109: GSM Authentication

An Ontology for Generic Wireless Authentication 109

The following figure illustrates the future view of the ontology with the integration of

several other domains:

Ontology for Subscriber Data

Billing

CRM

Admin

TTYPE

Bluetooth

GSM/UMTS

WLAN

Figure 28: Integration of Future domains

Other domains other than the ones previously mentioned include Bluetooth networks,

description and integration of TTYPE services, which describe the type of mobile device

a subscriber has (the type of screen; color, black and white, size, etc…). This is used to

determine what type of device a subscriber owns, in order to push multimedia services to

the subscriber. Other domains include, but are not limited to administrational data,

Customer Relationship Management (CRM) data, and Billing data.

6.3 Areas of application

Ontologies are mainly used and widespread in the bio-medical sector, where several

ontologies in this field have been developed, for the use of describing the human

anatomy and biological terms. Several other ontologies have been defined, which include

but are not limited to the following; ontologies for ethology, which describe the

behaviour of animals [63], ontologies for describing mathematical terms, ontologies that

describe the different parts of a camera, and also an ontology defined by the National

Cancer Institute, which is an NCI Thesaurus. More examples of ontologies can be found

in [64].

Page 110: GSM Authentication

An Ontology for Generic Wireless Authentication 110

References

[1] Global System for Mobile Communication (GSM), Online-Education Tutorial, International Engineering Consortium, http://www.iec.org/online/tutorials/gsm, 9th September 2005.

[2] Introduction to GSM, Article, Performance Technologies, Inc., http://www.pt.com/products/gsmintro.html, 9th September 2005.

[3] Overview of the Global System for Mobile Communications, Report, John Scourias, http://ccnga.uwaterloo.ca/~jscouria/GSM/gsmreport.html, 9th September 2005.

[4] Mobile Communications Chapter 4: Wireless Telecommunication Systems, Course work, Prof. Dr.- Ing. Jochen Schiller, http://www.inf.fu-berlin.de/inst/ag-tech/resources/material/English/PDF-Handout/C04-Wireless_Telecommunication_Systems.pdf, 9th September 2005.

[5] Valtteri Niemi and Kaisa Nyberg, UMTS Security, John Wiley & Sons, Ltd., 2003.

[6] GSM and UMTS Security, Presentation, Peter Howard, Vodafone Group R&D, http://www.isg.rhul.ac.uk/msc/teaching/sc3/sec3slides/SC3-2004-7.pdf, 9th September 2005.

[7] EAP Methods for 802.11 Wireless LAN Security, Online-Education Tutorial, International Engineering Consortium, http://www.iec.org/online/tutorials/eap_methods/index.html, 9th September 2005.

[8] Designing a Secure WLAN with the HP-UX AAA RADIUS Server, Whitepaper, Hewlett-Packard Development Company, L.P., http://docs.hp.com/en/WLANs-AAA/WLANs-AAA.pdf, 9th September 2005.

[9] Radio Subsystem, Technical Definition, Siemens AG, http://networks.siemens.com/communications/lexicon/5/f008225.htm, 9th September 2005.

[10] Kennziffern von GSM, Article, UMTS Link, http://umtslink.at/GSM/gsm_kennziffern.htm, 9th September 2005.

[11] Numbering Plans Guide, E.212: International Identification Plan for Mobile Terminals and Mobile Users, Article, SpraakMaker Telecom, http://www.numberingplans.com/index.php?goto=guide&topic=E212, 9th September 2005.

Page 111: GSM Authentication

An Ontology for Generic Wireless Authentication 111

[12] Numbering Plans Guide, E.164: The International Public Telecommunication Numbering Plan, Article, SpraakMaker Telecom, http://www.numberingplans.com/index.php?goto=guide&topic=E164, 9th September 2005.

[13] GSM Security Algorithms, Article, GSM Association 2005, http://www.gsmworld.com/using/algorithms/index.shtml. 9th September 2005.

[14] GSM Interception, White Paper, Lauri Pesonen, Helsinki University of Technology, http://www.dia.unisa.it/professori/ads/corso-security/www/CORSO-9900/a5/Netsec/netsec.html, 9th September 2005.

[15] Digital Cellular Telecommunications System (Phase 2+); Security Related Network Functions (GSM 03.20 version 6.1.0 Release 1997), Technical Specification, ETSI, Valbonne – France, http://www.3gpp.org/ftp/Specs/archive/03_series/03.20/, 9th September 2005.

[16] Universal Mobile Telecommunications System (UMTS) Protocols and Protocol Testing, Online Education Tutorial, International Engineering Consortium, http://www.iec.org/online/tutorials/umts/topic02.html, 9th September 2005.

[17] Overview of the Universal Mobile Telecommunication System (Draft, July 2002), Draft Overview, UMTSWorld.com, http://www.umtsworld.com/technology/overview.htm, 9th September 2004.

[18] GSM and UMTS Technology System Architecture, Article, Mobileguru Ltd., http://www.mobileguru.co.uk/Mobile_Technology_globe.html, 9th September 2005.

[19] Security Mechanisms in UMTS, Paper, Stefan Pütz, Roland Schmitz, Tobias Martin, http://fb1.hdm-stuttgart.de/skripte/Internetsecurity_2/Papers/UMTS-SecurityMechanisms.pdf, 9th September 2005.

[20] Security in UMTS – Integrity, Paper, Telenor R&D, Runar Langnes, Tom E. Aamodt, Trond Friisø, Geir Køien, Øyvind Eilertsen, http://www.telenor.com/rd/pub/not01/sec_UMTS.PDF, 9th September 2005.

[21] 3G Security Principles, Presentation, Myagmar, Gupta - UIUC 2001, http://choices.cs.uiuc.edu/MobilSec/posted_docs/3G_Security_Overview.ppt, 9th September 2005.

[22] Overview of 3GPP Release 5, Summary of all Release 5 Features, Technical Document, ETSI Mobile Competence Centre, http://www.3gpp.org/Releases/Rel5_features_v_2003_09_09.doc, 9th September 2005.

[23] The Internet Multimedia Subsystem, Presentation, Thomas Belling, Siemens, WiMAX Forum, http://www.wimaxforum.org/

Page 112: GSM Authentication

An Ontology for Generic Wireless Authentication 112

[24] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 5), Technical Specification, Valbonne – France, http://www.3gpp.org/ftp/Specs/archive/23_series/23.228/, 9th September 2005.

[25] IP Multimedia Subsystem, Tutorial, Johannes Stadler, Forschungszentrum Telekommunikation Wien, http://www.ftw.at/ftw/events/tutorials/IMS_Tutorial_050331_Part_IIb.pdf, 9th September 2005.

[26] Glossary: Intel® PRO/Wireless 2200BG Network Connection User’s Guide, Glossary, Intel Corporation, http://support.intel.com/support/wireless/wlan/pro2200bg/userguide81/glossary.htm, 9th September 2005.

[27] What is 802.11?, Definition, webopedia.com, http://www.webopedia.com/TERM/8/802_11.html, 9th September 2005.

[28] Cisco SAFE: Wireless LAN Security in Depth – Version 2, White Paper, Sean Convery, Darrin Miller, Sri Sundaralingam, Mark Doering, Pej Roshan, Stacey Albert, Bruce McMurdo, Jason Halpern, Cisco Systems Inc., San Jose, California, USA, http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solutions_white_paper09186a008009c8b3.shtml, 9th September 2005.

[29] A Comprehensive Review of 802.11 Wireless LAN Security and the Cisco Wireless Security Suite, White Paper, Cisco Systems Inc., http://www.cisco.com/en/US/products/hw/wireless/ps430/products_white_paper09186a00800b469f.shtml, 9th September 2005.

[30] How to Build a Secure WLAN, Article, Cisco Systems Inc., http://www.cisco.com/en/US/about/ac123/ac114/ac173/ac168/about_cisco_packet_feature09186a00800b443c.html, 9th September 2005.

[31] Wi-Fi Protected Access, WPA2 and IEEE 802.11, Questions and Answers, Cisco Systems Inc., http://www.cisco.com/en/US/products/hw/wireless/ps430/products_qanda_item0900aecd801e3e59.shtml, 9th September 2005.

[32] IEEE 802.1X, Definition, Wikipedia Encyclopedia, http://en.wikipedia.org/wiki/802.1x, 9th September 2005.

[33] EAP Methods for 802.11 Wireless LAN Security, Online-Education Tutorial, International Engineering Consortium, http://www.iec.org/online/tutorials/eap_methods/, 9th September 2005.

Page 113: GSM Authentication

An Ontology for Generic Wireless Authentication 113

[34] Remote Authentication Dial In User Service (RADIUS), RFC 2138, C. Rigney Livingston, A. Rubens Merit, W. Simpson Daydreamer, S. Willens Livingston, The Internet Engineering Taskforce, http://www.ietf.org/rfc/rfc2138.txt, 9th September 2005.

[35] Using RADIUS for WLAN Authentication, Part 1, Article, Lisa Phifer, http://www.wi-fiplanet.com/tutorials/article.php/3114511, 9th September 2005.

[36] What is PKI?, Definition, webopedia, http://www.webopedia.com/TERM/P/PKI.html, 9th September 2005.

[37] Definition of Public Key Infrastructure, Definition, M-Tech Information Technology Inc., http://mtechit.com/concepts/public_key_infrastructure.html, 9th September 2005.

[38] Introduction to Digital Certificates, Tutorial, veriSign Australia Pty Ltd., http://www.verisign.com.au/repository/tutorial/digital/intro1.shtml, 9th September 2005.

[39] X.509 Certificates and Certificate Revocation Lists (CRLs), Article, Sun Microsystems Inc., http://java.sun.com/j2se/1.3/docs/guide/security/cert3.html, 9th September 2005.

[40] The Semantic Web, Article, Tim Berners Lee, James Hendler and Ora Lassila, Scientific American, May 17, 2001, http://www.scientificamerican.com/print_version.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21, 12th September 2005.

[41] The Semantic Web: An Introduction, Tutorial, Sean B. Palmer, http://infomesh.net/2001/swintro/, 12th September 2005.

[42] Semantic Web, Overview, W3C, http://www.w3.org/2001/sw/, 12thSeptember 2005.

[43] Ontologies Come of Age, Paper, Deborah L. McGuinness, Knowledge Systems Laboratory, Stanford University, CA., http://www.ksl.stanford.edu/people/dlm/papers/ontologies-come-of-age-mit-press-(with-citation).htm, 12th September 2005.

[44] Ontology, Definition, Webster’s Revised Unabridged Dictionary (1913).

[45] Ontology, Definition, Merriam – Webster Online Dictionary, http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=Ontology&x=0&y=0, 12th September 2005.

Page 114: GSM Authentication

An Ontology for Generic Wireless Authentication 114

[46] Using Ontologies, Enabling Knowledge Sharing and Reuse on the Semantic Web, Technical Report, Jos de Bruijn, Digital Enterprise Research Institute, Austria, http://www.deri.at/publications/techpapers/documents/DERI-TR-2003-10-29.pdf, 12th September 2005.

[47] Ontology, Definition, The Collaborative International Dictionary of English v.0.48, http://dict.diodesign.co.uk/index.pl, 12th September 2005.

[48] A Translational Approach to Portable Ontology Specifications, Technical Report, Thomas R. Gruber, Knowledge Systems Laboratory, http://tomgruber.org/writing/ontolingua-kaj-1993.pdf, 12th September 2005.

[49] Ontology Development 101: A Guide to Creating your First Ontology, Publication, Natalya F. Noy and Deborah L. McGuinness, Stanford University, Stanford CA., http://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html, 12th September 2005.

[50] Dieter Fensel, Ontologies: A Silver Bullet for Knowledge Management and Electronic Commerce, Springer-Verlag Berlin Heidelberg 2004.

[51] OWL Web Ontology Language Overview, Recommendation, Deborah McGuinness, Frank van Harmelen, W3C, http://www.w3.org/TR/owl-features/, 12th September 2005.

[52] OWL Web Ontology Language Guide, Recommendation, Michael K. Smith, Chris Welty, Deborah L. McGuinness, W3C, http://www.w3.org/TR/owl-guide/, 12th September 2005.

[53] A Practical Guide to Building OWL Ontologies Using the Protégé-OWL Plugin and CO-ODE Tools, Edition 1.0, Guide, Matthew Horridge, Holger Knublauch, Alan Rector, Robert Stevens, Chris Wroe, The University of Manchester, Stanford University, http://www.co-ode.org/resources/tutorials/ProtegeOWLTutorial.pdf, 12th September 2005.

[54] Protégé Official Website, http://protege.stanford.edu/, 12th September 2005.

[55] The Protégé OWL Plugin: An Open Development Environment for Semantic Web Applications, Publication, Holger Knublauch, Ray. W. Fergerson, Natalya F. Noy and Mark A. Musen, Stanford Medical Informatics, Stanford School of Medicine, Stanford – CA., http://protege.stanford.edu/plugins/owl/publications/ISWC2004-protege-owl.pdf, 12th September 2005.

[56] RacerPro User’s Guide, Version 1.8, User Guide, Racer Systems GmbH & Co. KG, www.racer-systems.com, 12th September 2005.

Page 115: GSM Authentication

An Ontology for Generic Wireless Authentication 115

[57] GraphViz – Graph Visualization Software, About, http://www.graphviz.org/, 12th September 2005.

[58] Predicate Logic Terms and Symbols, Peter Suber, Earlham College, Course Material, www.earlham.edu/~peters/courses/log/terms3.htm, 19th September 2005.

[59] Frame Based Systems, Paper, Bernhard Nebel, http://www.cs.umbc.edu/771/current/papers/nebel.html, 19th September 2005.

[60] Basic Description Logics, Course Material, Franz Baader, Werner Nutt, www.inf.unibz.it/~franconi/dl/course/dlhb/dlhb-02.pdf, 19th September 2005.

[61] Restructuring the Telecommunication Networks, Simplification of the Network Infrastructure by implementing Storage Networks and Web Services techniques, EVOLUTE Workshop, S. Rupp, R. Lopez-Aladros, F.J. Banet, M.Duspiva, Alcatel SEL AG, http://www.linecity.de/pdfs/HETNET_2003_Paper.pdf, 30th September 2005.

[62] Open Biomedical Ontologies, http://obo.sourceforge.net/, 30th September 2005.

[63] Ontologies for Ethology, Paper, Peter E. Midford, http://www.mesquiteproject.org/ontology/, 30th September 2005.

[64] Protégé OWL Plugin – Ontology editor for the Semantic Web, List of Ontologies, http://protege.stanford.edu/plugins/owl/owl-library/index.html, 30th September 2005.

Page 116: GSM Authentication

An Ontology for Generic Wireless Authentication 116

Abbreviations

2G Second Generation Networks 2.5G Second and a half Generation Networks 3G Third Generation Networks 802.11 A WLAN network standard defined by the IEEE 802.1X Standard for securing WLAN networks defined by the IEEE A A3 An Authentication Algorithm in GSM Networks A5 A Ciphering/Deciphering Algorithm in GSM Networks A8 A Key Generation Algorithm in GSM Networks AAA Authentication Authorization and Accounting ABoxes Represent Instances of TBoxes AI Artificial Inteliigence AK Anonymity Key AKA Authentication and Key Agreement AMF Authentication Management Field AP Access Point API Application Programming Interface AuC Authentication Center AUTN Authentication Token B BSC Base Station Controller BSS Base Station Subsystem BTS Base Transceiver Station C CA Certifying Authority CC Country Code CK Cipher Key CN Core Network CRM Customer Relationship Management CS Circuit Switched ‘ D DL Description Logics DRNC Drifting Radio Network Controller E EAP Extensible Authentication Protocol EAP-AKA EAP-Authentication and Key Agreement EAP-CHAP EAP-Challenge Handshake Authentication Protocol

Page 117: GSM Authentication

An Ontology for Generic Wireless Authentication 117

EAP-MD5 EAP-Message Digest 5 EAP-OL EAP Over LAN EAP-SIM EAP-Subscriber Identity Module EAP-TLS EAP-Transport Layer Security F f1 – f5 UMTS Authentication Functions G GGSN Gateway GPRS Support Node GMSC Gateway Mobile Switching Center GPRS General Packet Radio Service GraphViz Graphical Visualization GSM Global System for Mobile Communication H HLR Home Location Register HLR-Number Logical HLR Address HSS Home Subscriber Server HTML Hypertext Markup Language I I-CSCF Interrogating Call Session Control Function ID Identification IEEE Institute of Electrical and Electronics Engineers IK Integrity Key INMSI International Mobile Station Identity IMS IP Multimedia Subsystem IMSI International Mobile Subscriber Identity IP Internet Protocol ISDN Integrated Services Digital Network ISIM IMS Subscriber Identity Module ISN Individual Subscriber Number K K Secret Key Kc Cipher Key Ki Secret Key L LEAP Lightweight Extensible Authentication Protocol M MAC Message Authentication Code

Page 118: GSM Authentication

An Ontology for Generic Wireless Authentication 118

MAC_RAND Random Message Authentication Code MAC_XRES Expected Message Authentication Code Response MCC Mobile Country Code ME Mobile Equipment MMS Multimedia Messaging Service MNC Mobile Network Code MS Mobile Station MSC Mobile Switching Center MSIN Mobile Station Identification Number MSISDN Mobile Station Integrated Services Digital Network Number N NAI Network Access Identifier NCI National Cancer Institute NDC National Destination Code NGN Next Generation Network NGPR Next Generation Profile Register Node B UMTS Base Station NSS Network Switching Subsystem O OSS Operation Subsystem OWL Web Ontology Language OWL-DL OWL- Description Logics OWL-Viz OWL-Visualization P PC Personal Computer P-CSCF Proxy Call Session Control Function PDA Personal Digital Assistant PEAP Protected Extensible Authentication Protocol PIN Personal Identification Number PKI Public Key Infrastructure PLMN Public Land Mobile Network PPRJ Protégé Project Extension PS Packet Switched PSTN Public Switched Telephone Network P-TMSI Packet-Temporary Mobile Subscriber Identity R RACER RenamedABox and Concept Expression Reasoner RacerPro RenamedABox and Concept Expression Reasoner Professional RADIUS Remote Authentication Dial-In User Service RAND Random Number RDF Resource Description Framework RES Response RNC Radio Network Controller

Page 119: GSM Authentication

An Ontology for Generic Wireless Authentication 119

RNS Radio Network Subsystem RSS Radio Subsystem S S-CSCF Serving Call Session Control Function SGSN Serving GPRS Support Node SIM Subscriber Identity Module SMS Simple Message Service SN Serving Network SN Subscriber Number SQN Sequence Number SRNC Serving Radio Network Controller SSL Secure Socket Layer T TBoxes Represents Ontologies TLS Transport Layer Security TMSI Temporary Mobile Subscriber Identity TTYPE Mobile Terminal Type U UML Unified Modelling Language UMTS Universal Mobile Telecommunication System URL Universal Resource Locator USB Universal Serial Bus USIM Universal Subscriber Identity Module UTRAN UMTS Terrestrial Radio Access Network V VLR Visitor Location Register W W3C World Wide Web Consortium WEP Wired Equivalent Privacy WLAN Wireless Network WPA Wi-Fi Protected Access X X.509 Standard for Digital Certificates XMAC Expected Message Authentication Code XML Extensible Modeling Language XRES Expected Response

Page 120: GSM Authentication

An Ontology for Generic Wireless Authentication 120

Appendix A

Appendix A lists the classes and subclasses of the ontology

Class Subclass Subclass of subclass Algorithm A3

A8 F1 F1_ F2 F3 F4 F5 F5_

n/a

AuthenticationMethod EAP-SIM EAP-TLS LEAP PEAP

n/a

AuthenticationType CertificateBased ChallengeResponse MutualAuthentication NetworkAuthentication PasswordBased UserAuthentication

n/a

Certificate n/a n/a CertificateComponent IssuerName

PublicKey SerialNumber Signature SignatureAlgorithm Subject ValidFrom ValidTo Version

n/a

Code CountryCode MobileCountryCode MobileNetworkCode NationalDestinationCode

n/a

Database AuC HLR HSS UserDatabase

n/a

IMSI NAI

n/a

PrivateUserIdentity NAI

Identity

PublicServiceIdentity UserNetworkIdentity URL Realm

n/a

Page 121: GSM Authentication

An Ontology for Generic Wireless Authentication 121

IPAddress UserName DerivedKey AK

AMF AUTN IK Kc MAC MAC_RAND MAC_XRES RES XMAC XRES

GeneratedKey RAND SQN

Key

StaticKey Ki PrivateKey PublicKey

Network GSM IMS UMTS WLAN

n/a

Number FixedTelephoneNumber HLRNumber MSISDN MobileSubscriberIdentificationNumber SubscriberNumber IndividualSubscriberNumber

n/a

BasicService SMS Speech

MutlimediaService AudioDownload AudioStream MMS VideoDownload VideoStream WebBrowsing

Service

SupplementaryService CallBarring CallDivert CallWaiting ConferenceCall CustomerCareBilling DataService

UserData AccountHolder AccountNumber BankCity BankCode BankCountry City Country FirstName

n/a

Page 122: GSM Authentication

An Ontology for Generic Wireless Authentication 122

HouseNumber LastName Password PostalCode SessionDuration State StreetName

Subscriber n/a n/a

Page 123: GSM Authentication

An Ontology for Generic Wireless Authentication 123

Appendix B

The following appendix lists the properties and the inverse of each property if applicable:

Property Inverse Property has Algorithm isAlgorithmOf hasAnonymityKey isAnonymityKeyOf hasAuthenticationManagementField isAuthenticationManagementFieldOf hasAuthenticationMethod isAuthenticationMethodOf hasAuthenticationType isAuthenticationTypeOf hasBasicService isBasicServiceOf hasCertificate isCertificateOf hasChallenge isChallengeOf hasChallengeResponse isChallengeResponseOf hasData isDataOf hasDatabase isDatabaseOf hasExpectedMessageAuthenticationCode isExpectedAuthenticationCodeOf hasExpectedResponse isExpectedResponseOf hasExpectedResponseMessageAuthenticationCode

isExpectedResponseMessageAuthenticationCodeOf

hasIdentity isIdentityOf hasInput isInputOf hasIntegrityKey isIntegrityKeyOf hasIssuerName isIssuerNameOf hasMessageAuthenticationCode isMessageAuthenticationCodeOf hasMultimediaService isMultimediaServiceOf hasNetworkIdentity isNetworkIdentityOf hasNumber isNumberOf hasOutput isOutputOf hasPart isPartOf hasPassword isPasswordOf hasPrivateUserIdentity isPrivateUserIdentityOf hasPublicKey isPublicKeyOf hasPublicServiceIdentity isPublicServiceIdentityOf hasPublicUserIdentity isPublicUserIdentityOf hasQuintets isQuintetsOf hasRandNumber isRandNumberOf hasRandomMessageAuthenticationCode isRandomMessageAuthenticationCodeOf hasResponse isResponseOf hasSecretKey isSecretKeyOf hasSequenceNumber isSequenceNumberOf hasSerialNumber isSerialNumberOf hasSessionKey isSessionKeyOf hasSignature isSignatureOf hasSignatureAlgoritm isSignatureAlgoritmOf hasSubject isSubjectOf hasSubscriber isSubscriberOf

Page 124: GSM Authentication

An Ontology for Generic Wireless Authentication 124

hasSupplementaryService isSupplementaryServiceOf hasTriplets isTripletsOf hasUserName isUserNameOf hasValidityFrom isValidityFromFieldOf hasValidityUntil isValdityToFieldOf hasVersion isVersionOf isAssociatedWith n/a isSubscribedTo n/a isStoredIn stores