CYBER SECURITY FOR

GSM DATA PROTECTION

M.Engr. Thesis

Presented

By

OBODOEZE, Fidelis Chukwujekwu

REGISTRATION NUMBER: 2008366007F

To

Department of Electronic & Computer Engineering

Nnamdi Azikiwe University
Awka

In fulfilment for the awards of M.Engr. (Hons) in Electronic &

Computer Engineering

DECEMBER 2010
POSTGRADUATE M.Engr. Project Thesis

ELECTRONIC & COMPUTER ENGINEERING

DEPARTMENT

NNAMDI AZIKIWE UNIVERSITY

AWKA

ANAMBRA STATE
NIGERIA

ii
 CYBER SECURITY FOR

GSM DATA PROTECTION

BY

OBODOEZE FIDELIS CHUKWUJEKWU

iii
 CERTIFICATION
I hereby certify that the work reported in this thesis is my own and that works

performed by others are appropriately cited.

------------------------------------------------
Signature of the Author:

iv
 APPROVAL
This Master Thesis is hereby approved having met the requirements for the award of

Masters in Engineering (MEngr.) in Electronic & Computer Engineering of Nnamdi

Azikiwe University Awka, Nigeria.

-------------------------------------
Signature of Project Supervisor PROF. H.C INYIAMA

Date: …………………………

----------------------------------------
Signature of Project Supervisor ENGR. DR. V.I IDIGO

Date:……………………………

------------------------------------------
Signature of Head of Department ENGR. DR. V.I IDIGO

Date:…………………………….

-------------------------------------------
Signature Dean of Faculty of Engineering PROF. ONYEYILI

Date:………………………………

---------------------------------------------
Signature Dean School of Postgraduate PROF. LUKE ANIKE
Studies

Date:…………………………………..

-----------------------------------------------
Signature of External Examiner

Date: ……………………………………

v
 ACKNOWLEDGEMENT
For making this Masters programme a dream come true and for their invaluable

contributions to this Master thesis, I owe so much to my supervisor Prof. H.C Inyiama

and co-supervisor Engr. Dr. V.I Idigo. May God replenish all your energy.

I equally thank my colleagues in the M.Engr Class for making this programme

exciting and a lot of fun. I wish you the best in your future endeavours.

Finally, I would like to thank my wife, Nkechi and my little angel DivineMiracle for

being there for me during this arduous journey to completing this Master programme.

vi
 DEDICATION

I dedicate this Masters Thesis project to first of all my GOD, The Almighty Father, in

whom I owe all my accomplishment including this thesis and to my biological

parents, Mr. & Mrs. J.O Okakpu for bringing me into this world and for all their

efforts so far in seeing that I become what I am today.

vii
 ABSTRACT

With the increasing use of extensive IT and Telecommunication systems for sensitive
or safety-critical applications, the matter of IT and Telecommunication security is
becoming more important. For the computer system, and its related applications,
including data, to be trustworthy, it must be secured. This project covers all aspects of
Computer System security. This project equally understudied the security of data as it
affects mobile systems vis-à-vis Global System for Mobile Telecommunications
(GSM). The existing security algorithms in the GSM network were understudied and
critical flaws found in them that cannot guarantee the security and confidentiality of
user’s data during communication session. This poses a great threat in sensitive and
safety-critical environments such as financial institutions, Military, Educational, or
even in espionage establishments such as State Secret Services (SSS) and security
establishments. This Masters project finally proffered solution to these flaws found in
GSM security system by adopting a software-based approach. A computer-based
program was written in JAVA programming language to provide end-to-end data
(SMS only) encryption in two-way communication using compatible MIDP mobile
phones or other portable communication devices.

viii
 TABLE OF CONTENTS
PAGE
Cover Page i
Title Page iii
Certification iv
Approval v
Acknowledgement vi
Dedication vii
Abstract viii
Table of Contents ix
List of Figures xii
List of Tables xiii

CHAPTER ONE: INTRODUCTION 1

1.0 Background to the study 1

1.1 Aims and Objectives of the Project 4
1.2 Justification for the Study 5
1.3 Scope of the Project 5
1.4 Limitations of the Project 6
1.5 Block Diagram overview of the Project Stages 7
1.6 Project Report Organisation 8

CHAPTER TWO: REVIEW OF RELATED LITERATURE 10

2.0 Computer and Cyber Security 10

2.0.1 Introduction 10
2.0.2 Computer and IT Security Domain 13
2.0.3 Security threats and Attacks 14
2.0.4 What is Computer and Cyber Security? 18

2.1 Types of Attacks 19

2.2 GSM Technology 29

2.2.1 GSM Properties 30
2.2.2 The Mobile Station 31
2.2.3 The Base Transceiver Station 31
2.2.4 The Base Station Controller 32
2.2.5 The Mobile Switching Centre 32
2.2.6 The Equipment Identity Register 33
2.2.7 Subsystems 33
2.2.8 GSM –Frequencies 34
2.2.9 FDMA and TDMA 36

ix
2.3 GSM Security Architecture 37
2.3.1 GSM Security Model 39
2.3.2 A3, The MS Authentication Algorithm 41
2.3.3 A8, The Voice-Privacy Key Generation Algorithm 42
2.3.4 A5/1, The Strong Over-the-Air Voice-Privacy Algorithm 44
2.4 GSM attack scenarios 47
2.4.1 Brute-Force Attack against A5 47
2.4.2 Divide-and-Conquer Attack against A5 48
2.4.3 Accessing the Signalling Network 49
2.4.4 Retrieving the Key from the SIM 51
2.4.5 Retrieving the Key from the SIM over the Air 53
2.4.6 Retrieving the Key from the AuC 54
2.4.7 Cracking the A8 Algorithm 54
2.4.8 Altering of Data Messages 55

2.5 SMART Cards 55

2.5.1 Types of SMART Cards 56
2.5.2 SMART cards standards 57
2.5.3 Smart Card Applications for Mobile Networks 60

2.6 Cryptography 60
2.6.1 Java Cryptography 60
2.6.2 Digital Signature 61
2.6.3 Symmetric Algorithm 61
2.6.4 Asymmetric Algorithm compared with Symmetric 62

2.7 Java In-Built Security Technologies 62

2.7.1 The Basic Security in MIDP 63
2.7.2 SATSA-CRYPTO (JSR-117) 63
2.7.3 Bouncy Castle API 64

2.8 Mobile Messaging 64

2.8.1 Short Message Service (SMS) 64
2.8.2 Message Size 65

2.9 Conclusion 66

CHAPTER THREE: METHODOLOGY AND SYSTEM ANALYSIS 69

3.0 Methodology 69
3.0.0 Possible Causes of error during transmission of SMS from one
End to another 71
3.0.1 SMS Message Data Format 72
3.0.2 Why Use JAVA? 73

x
3.1 JAVA Technologies used 74
3.1.1 J2ME 74
3.1.2 MIDP 74
3.1.3 JSR 76
3.1.4 MIDlet 76
3.1.5 CDLC 77
3.1.6 Bouncy Castle API 78
3.1.7 Obfuscation of Bouncy Castle JAR files using Proguard 79
3.1.8 Integrated Development Environment (IDE) for the Project 81
3.1.9 Application Deployment as JAR and JAD files 81

3.2 Structured Analysis & Design Method 82

3.2.1 TOP-Down Structured Design Approach 82
3.2.2 Bottom-Up Structured Design Approach 86

CHAPTER FOUR: SYSTEM DESIGN AND DEVELOPMENT 87

4.1 Introduction 87
4.2 System Specification 87
4.3 The SecureSMS MIDlet JAVA program flowcharts 90
4.3.1 The Program Source codes 101
4.3.2 The Program Input and Output Interface 101
4.3.3 The Project Block diagram 106

CHAPTER FIVE: SYSTEM IMPLEMENTATION 107

5.1 Software Implementation 107

5.1.2 Over the Air (OTA) 108
5.1.3 Bluetooth 108
5.1.4 IrDA 108
5.1.5 USB Cable 108

5.2 System Testing 109

5.2.1 The Test Plan 109
5.2.2 Testing on the JAVA™ Platform Micro Edition
SDK 3.0 Emulator of NETBEANS 6.8 IDE 109
5.2.3 Final Testing on compatible mobile phones 115
5.3 Performance Evaluation 117

CHAPTER SIX: SUMMARY & CONCLUSION 118

6.1 Introduction 118

6.2 Project Summary 118
6.3 Summary of Achievements 119

xi
6.4 Problems encountered and solutions 120
6.5 Recommendations 121
6.6 Suggestions for further improvements 121
6.7 Conclusion 122

References 123
Appendix A: Program Source codes 128
Appendix B: Acronyms used in the project 140
Appendix C: Average processing speed of cipher and digest algorithms 143

xii
 LIST OF FIGURES

FIGURES PAGE

1.1 The Block diagram of the Research and Project Stages 7

2.1 Domain of Computer and IT Security 13
2.2 Architecture of the GSM Network 31
2.3 FDMA in GSM 900 36
2.4 TDMA in GSM 900 36
2.5 Mobile Station Authentication 39
2.6 Frame encryption and decryption 40
2.7 User Authentication 41
2.8 Signed Response (SRES) calculation 42
2.9 Session Key (Kc) calculation 43
2.10 COMP128 calculation 43
2.11 Keystream Generation 44
2.12 An example LSFR with feedback polynomial of x6+x4+x 45
2.13 A5 LSFR Construction 45
2.14 SIM Card Smart card in a GSM Mobile phone 57

3.1 End-to-end encryption and decryption of SMS data 70

3.2 SMS Message Format 73
3.3 The JAVA Environment 74
3.4 EncryptedSMS MIDlet class illustration 83
3.5 Sending Message Sequence 84
3.6 Receiving Message Sequence 85
3.7 Incorrect Password 85

4.1 Program Flowchart or class diagram relating the project

classes or modules 89
4.2 Program Flowchart relating the methods in the entire program 90
4.3 Program Flowchart depicting relationship between the main class
and SendScreen class 95

4.4 Program Flowchart depicting relationship between the main class

and ReceiveScreen class 96

4.5 Program Flowchart depicting relationship between the main class

and the MessageCodec class 98

4.6 Program Flowchart depicting relationship between the main class

and ReportScreen class 99

4.7 Program Flowchart depicting relationship between the main class

and ErrorScreen class 100

xiii
4.8 Sending Message Sequence 101
4.9 Receiving Message Sequence 102
4.10 Incorrect Password 103
4.11 secureSMS MIDlet program source code in
NETBEANS 6.8 IDE 104
4.12 secureSMS MIDlet program project successfully built in
NETBEANS 6.8 IDE 105
4.13 The SMS Security Project Block diagram 106

5.1 secureSMS Project in NETBEANS 6.8 IDE Environment 110

5.2 secureSMS MIDlet program being executed by the default Sun
Wireless JAVA Emulator integrated in NETBEANS 6.8 IDE 111

5.3 The JAVA Emulator prompting the user to enter the phone number,
the secret/confidential message and add a security digest 112

5.4 secureSMS MIDlet program being executed by the Default Sun Wireless
JAVA Emulator. 112

5.5 The JAVA Emulator asking the recipient to enter the password/private key to
decode and read the encrypted message 113

5.6 The password entered to decode and read the secret message 113

5.7 secureSMS MIDlet program being executed by the Default JAVA™ Platform
Micro Edition SDK 3.0 Emulator Operation Report after successfully sending
a confidential message to recipient phone number 123456789 114

5.8 Screenshots of SecureSMS MIDlet being used to send a

Secure SMS to another phone 115
5.9 Screenshots of SecureSMS MIDlet being used to receive and decode
a secured message sent from another phone 116

xiv
 LIST OF TABLES

TABLES PAGE

Table 2.1 GSM 900 GSM 1800 35

Table C:1 Average Processing Speed of the cipher algorithms with
Bouncy Castle API 143
Table C:2 Average Processing Speed of the Message Digest algorithms
With Bouncy Castle API 144

xv
 CHAPTER ONE
INTRODUCTION

1.0 Background to the Study

The term security lacks meaning until one has defined what is to be secured and for

whom. Likewise, security is difficult to comprehend without a potential threat. Mobile

phones for third-generation mobile systems (3G) have several security stakeholders for

which the mobile platform must provide security services. Moreover, the potential threats

may differ from stakeholder to stakeholder.

The first class of security stakeholders, users, expects that mobile phones will offer secure

and reliable communication – that is, they assume their phones can be trusted to handle

sensitive tasks, such as e-commerce transactions. The main threats to this class of

stakeholders are malicious software, such as viruses and Trojans, or weak or misbehaving

security mechanisms. The second class of stakeholders, mobile network operators, relies

on phone network identification mechanisms (related to billing capability) and network-

related software.

Criminal-minded users or hostile software must not be allowed to circumvent these

mechanisms.

Operators thus require that the integrity of software can be guaranteed when the mobile

phone is in operation. They also want to be certain that users cannot break SIM lock

mechanisms.

A third class of security stakeholders, content providers, wants to be paid for the content

(music, pictures, videos and software) that users download. It also wants to know that

1
users cannot (mis)use their phones to illegally copy or distribute content. This is where

digital rights management (DRM) functions come into play. However, DRM mechanisms

alone cannot provide all necessary security. To provide a DRM solution that meets

content provider requirements, the mobile phone platform must contain security functions

that guarantee secure execution and code integrity.

Security is usually measured in terms of a set of basic aspects [1]:

- confidentiality,

- integrity,

- authentication and

- authorization.

- Non-repudiation

Confidentiality is ensuring that the data is hidden from those that are not supposed to see
it.

Confidentiality of data is achieved by cryptographically transforming original data, often

called, plaintext, into cipher text, which hides the content of plaintext. This operation is

realized as a parameterized transformation that keeps the controlling parameter secret.

The controlling parameter is often called a key. The transformation is called encryption.

With a key it is easy to perform the inverse transform or decryption. Without the key,

decryption would be difficult.

Integrity is about ensuring that data has not been replaced or modified without

authorization during transport or storage. This is achieved using cryptographic transforms

and a key. Additional information must also be added to the plaintext to verify its

integrity.

2
Authentication is the procedure by which a unit (the claimant) convinces another unit

(the verifier) of its (correct) identity. Authentication is different from authorization, which

is the process of giving a person or entity permission to do or have access to something.

Non-repudiation is ensuring that someone who sent a message does not deny that he is the

one that sent it by using security processes such as digital signature.

There are two major classes of cryptographic mechanisms: symmetric and asymmetric. In

symmetric mechanisms, the same key is used for encryption and decryption. Examples of

symmetric confidentiality mechanisms are

• block ciphers, such as DES and AES; and

• stream ciphers, such as the GSM A1, A2 and A3 algorithms.

Integrity is often protected using symmetric mechanisms. Integrity-protection algorithms

are also called message authentication codes (MAC). The most popular MAC is the

HMAC algorithm. Because the key in symmetric mechanisms can be used to decrypt

content, it must be kept secret from all but legitimate users of the encryption scheme.

Asymmetric mechanisms use separate pairs of keys for encryption transform and

decryption transform. The public key can be made publicly available, but the private key

must never be revealed. Asymmetric mechanisms are typically used for distributing keys

(for example, a symmetric key) or for digital signing purposes. A public key can be used

to encrypt a symmetric key, which in turn, can only be decrypted by the legitimate

3
receiver using the corresponding private key. A private key may also be used to digitally

sign data. The signature can be verified by anyone who knows the corresponding public

key. The RSA scheme is widely known example of an asymmetric cryptographic

algorithm.

A lot of research works have been done already in this regard; and it has been proved that

most if not all the existing algorithms being employed by GSM companies as security

measures have been broken. Equally the smart-card in GSM phones , SIM card can be

cloned and as such more research need to be done to protect sensitive and critical data

where GSM technologies are employed.

This Masters thesis focuses on ways through which sensitive user’s data can be further

protected (especially short message services (SMS)) against threat by malicious and

criminally-minded users. Equally, all other areas of Information and System security are

equally researched by the project.

1.1 Aims and Objectives of the Project

The aims and objectives for the project are as follows:

- To understudy how GSM works with respect to various security algorithms

inbuilt into it.

- To understudy all the existing GSM cryptographic algorithms and expose their

strengths and shortcomings

- To proffer solution to the shortcomings inherent in original encryption

algorithms found in GSM technologies by using software-based approach to

4
 develop a MIDlet program in JAVA that can be used to further secure and

protect user’s sensitive and critical data (SMS only) using Bouncy Castle

JAVA cryptographic Application Programming Interface (API).

- To test run the security JAVA MIDlet software program in compatible Mobile

Information Device Profile (MIDP) phones or mobile devices engaged in end-

to-end GSM data communication session.

1.2 Justification for the Study

Mobile phones are used on a daily basis by hundreds of millions of users, over radio

links. Unlike a fixed phone, which offers some level of physical security (i.e. physical

access is needed to the phone line for listening in), with a radio link, anyone with a

receiver is able to passively monitor the airwaves.

Mobile phones are equally used in several sensitive and mission critical environment e.g.

financial, military, educational e.t.c. where integrity and privacy of data need not be

compromised.

Therefore it is highly important that reasonable technological security measures are taken

to ensure the privacy of user's phone calls and text messages (and data), as well to prevent

unauthorized use of the service being run by the mobile phone applications.

1.3 Scope of the Project

This study will cover:

- the data security in Global System Mobile Communication (GSM); all the existing

security algorithms will be analysed and their strengths and weaknesses

highlighted.

5
- Software will be used to solidify where weaknesses exist in the GSM data using a

MIDlet JAVA program developed in Bouncy Castle Java cryptographic API. Therefore,

a software program will be written in JAVA programming language to improve the

security features of GSM data where integrity of user’s data are critical and need not be

compromised. This Master’s project will focus on developing a software application that

will protect user’s Short Message Service (SMS) data only.

1.4 Limitations of the Project

1. This application can only be implemented on Java-enabled phone which

supports Mobile Information Device Profile (MIDP) 2.0.

2. Both the sender and recipient have to install the security software: secureSMS

software application in their mobile phones in order to implement the solution

and send and read encrypted and secure SMS.

3. The two people engaged in a two-way communication must switch on their

mobile phones to be able to send and receive the secure SMS data.

4. The application does not have a Record Management Store facility yet, so the

mobile phones cannot store the sent and received SMS data for future

reference.

5. The security application can only work in an environment where Global System

for Mobile Telecommunication (GSM) or Universal Mobile Telecommunications System

(UMTS) network is available and cannot work yet on CDMA (Code Division for

Multiple Access) network.

6
1.5 Block Diagram overview of the Project Stages

The block diagrams of the Research and Project stages are depicted below:

STAGE 1

Research and analysis of

GSM technologies and GSM Data Security and existing GSM

Security algorithms

STAGE 2

Software development

- Development of a MIDlet JAVA computer program to further strengthen GSM

data (SMS only) using Bouncy Castle JAVA Cryptographic API in NetBeans IDE

STAGE 3

Implementation of 2 programs developed in JAVA

Test-running, Deployment and implementation of the programs
developed in STAGE 3 above

Fig 1.1. The Block diagram of the Research and Project Stages

7
1.6 Project Report Organisation

This master thesis report is structured as follows:

Chapter 1, Background Information: This chapter gives general background

information on security in Computer System, Information System and Security of data in

GSM data and the problems inherent in them.

The chapter also captures the Aims and Objectives of the research project, the

Justification for embarking on the research project on Information and GSM data security

a well as the objectives and scope of the study.

Chapter 2, Literature Review: Various relevant literature and facts that pertain to the

subject study: GSM technologies and GSM data security are highlighted. Also

highlighted are the Java data security technologies that are employed in the project to

strengthen the deficiencies noted in existing GSM security.

Chapter 3, Methodology & System Analysis: To provide further security for data in

mobile devices in combination of existing encryption algorithms inbuilt in GSM mobile

devices during communication session (SMS), a MIDlet JAVA program is written

developed with BouncyCastle cryptographic Application Programming Interface (API).

This chapter highlights more of ins and outs of the JAVA technologies used in this

project.

Chapter 4, System Design and Development: This chapter handles the full program

design for the development of the security program to protect user’s GSM SMS data

8
using JAVA programming language and NETBEANS 6.8 Integrated Development

Environment.

Chapter 5, System Implementation: This chapter handles full testing, running,

deployment and implementation of the two programs written in Chapter 4 above to use to

strengthen the existing GSM algorithms and to provide simulation exercise for the

existing GSM security algorithms. The JAVA MIDlet secure SMS program is deployed

using Cable to PC as well as Over the Air (OTA) communication running on compatible

MIDP 2.0 Nokia phones such as Nokia 2700 Classic to implement the solution.

Chapter 6, Summary and Conclusion: A synopsis of the achieved goals of the

implementations is shown. Problems encountered in the project and the way out of them

are equally highlighted. Furthermore, recommendation for future work on the project is

given and finally this chapter gives a concluding remark on the project.

References cover all the cited works of other people used in this Master thesis.

Appendix A: Covers the program sources codes for the project

Appendix B: Covers used GSM and other acronyms and their full meaning.

9
 CHAPTER TWO
REVIEW OF RELATED LITERATURE

This chapter presents a general background to the thesis and covers the theoretical basis

of the research area and past research done on the subject.

2.0 Computer and Cyber Security

2.0.1 Introduction

The biggest challenge facing the whole world now in the area of application and use of

computer and computer-related resources is the issue of security. Governments of many

countries spend billions of dollars to procure and maintain computer and IT resources for

use in various government ministries, agencies and parastatals. Private sector

establishments like financial, research institutions, industrial firms, etc. deploy huge

amount of fund in the procurement and installation of computer and IT resources and yet

if care is not taken to address the critical concern of myriads of security threats that now

exist everywhere and every time, all these huge capital expenditure will amount to

exercise in futility.

The importance of security of computer resources: data, hardware, software,

telecommunication bandwidth and information cannot be overemphasized. Concerted and

coordinated efforts must therefore be made by all tiers of governments of world

economies to confront and address the monster threatening the successful application of

computer and its resources towards the realisation of computerisation goal of every

economy.

10
Computer Security is usually measured in terms of a set of basic aspects [1]:

- confidentiality,

- integrity,

- authentication and

- authorization

- Non-repudiation

Confidentiality is ensuring that the data is hidden from those that are not supposed to see
it.
Confidentiality of data is achieved by cryptographically transforming original data, often

called, plaintext, into cipher text, which hides the content of plaintext. This operation is

realized as a parameterized transformation that keeps the controlling parameter secret.

The controlling parameter is often called a key. The transformation is called encryption.

With a key it is easy to perform the inverse transform or decryption. Without the key,

decryption would be difficult.

Integrity is about ensuring that data has not been replaced or modified without

authorization during transport or storage. This is achieved using cryptographic transforms

and a key. Additional information must also be added to the plaintext to verify its

integrity.

Authentication is the procedure by which a unit (the claimant) convinces another unit

(the verifier) of its (correct) identity. Authentication is different from authorization, which

is the process of giving a person or entity permission to do or have access to something.

Non-repudiation is ensuring that someone who sent a message does not deny that he is the

one that sent it by using security processes such as digital signature.

11
There are two major classes of cryptographic mechanisms: symmetric and asymmetric. In

symmetric mechanisms, the same key is used for encryption and decryption. Examples of

symmetric confidentiality mechanisms are

• block ciphers, such as DES and AES; and

• stream ciphers, such as the GSM A1, A2 and A3 algorithms.

Integrity is often protected using symmetric mechanisms. Integrity-protection algorithms

are also called Message Authentication Codes (MAC). The most popular MAC is the

HMAC algorithm. Because the key in symmetric mechanisms can be used to decrypt

content, it must be kept secret from all but legitimate users of the encryption scheme.

Asymmetric mechanisms use separate pairs of keys for encryption transform and

decryption transform. The public key can be made publicly available, but the private key

must never be revealed. Asymmetric mechanisms are typically used for distributing keys

(for example, a symmetric key) or for digital signing purposes. A public key can be used

to encrypt a symmetric key, which in turn, can only be decrypted by the legitimate

receiver using the corresponding private key. A private key may also be used to digitally

sign data. The signature can be verified by anyone who knows the corresponding public

key. The RSA scheme is widely known example of an asymmetric cryptographic

algorithm [1].

12
2.0.2 Computer and IT Security Domain [2].

Safety

Safety deals with protection against unintentional physical, social, spiritual, financial,

political, emotional, occupational, psychological, educational or other types of undesired

consequences of system failures.

Typical design methods:

- Fail-Safe: in case of failure, fallback into a safe (usually static) state

- Fault-Tolerance: In case of failure, continue operation on reduced QoS level

(graceful degradation)

Computer & IT Security

Safety Security Privacy

(Functional) (Attacks)

Fig. 2.1: Domain of Computer and IT Security

Security
Protection against intentional attacks, in particular concerning

- Confidentiality

- Integrity

- Availability

- Non-Observability

- Accountability / Non-Repudiation

- Liability

- Anonymity / Pseudonymity

- Authenticity (as part of AAA: Authentication, Authorization, Accounting)

13
Privacy

Protection against misuse of information, in particular concerning

- Personal data and misuse by third parties

- harm to personal rights

2.0.3 Security threats and Attacks

According to Kothapalli [3], many security threats now exist. A threat can be noticed or

unnoticed when an intruder accesses a computer or a computer network without

authorisation. An intruders’ goal could be access to either copy or use the key, to change

the key or to block the legitimate owner's use of the key by e.g. erasing it. The threats are

for example that a computer can be infected by importing infected files. If the infected

file is executed, then the malicious code may give different problems.

When a computer system is connected to the Internet unauthorized users may try to

intrude into the computer system and access valuable information.

Attacks disrupt the security goals. They affect the confidentiality, integrity and

availability. How are the security goals disrupted? A successful attack on a system on the

Internet can pose a major threat because it can influence the system performance and

services used by millions of user as postulated by Ali Abbas [4]. Suppose the hacker

generates a malicious code on the Internet, the malicious program looks for loopholes in

computers, and it will gain the operating system privileges. Once infected with malicious

code, a computer may be remotely controlled by a hacker, via the Internet.

14
Attacks target the computers or networks, such as power systems and financial systems.

The attacks target IT in two different ways [3].

1. Direct attacks against an information system “through the wires” alone [i.e.

Hacking]

2. The attack can be from the inside as a result of compromising a trusted party

with access to the system.

The preparation for an attack may sometimes proceed slowly or in several phases to

initiate the attack.

Some compromised computers become part of an automatic “bot network,” quietly

performing espionage by transmitting data or intermediate preparatory instructions back

and forth from Secure storage of encryption keys compromised computers while awaiting

a special final activation signal originating from the attacker.

The final activation phase may direct all compromised computers to inundate a targeted

computer with bogus messages or insert phony data into critical computer systems,

causing then to malfunction at a crucial point or affect other computers. Some recent

computer attacks have focused on only a single new computer vulnerability and have

been seen to spread worldwide through the Internet with astonishing speed.

This section has been subdivided into different parts giving an explanation about attacks

from hackers, attacks on computers, attacks by malicious code, attacks on smart cards and

attacks on PDAs [3].

15
Attacks from hackers

Kothapalli [3] stated in his findings that there is a risk that an unauthorized user will

intrude into the system to access, change or block availability of the encryption keys. For

example if the hacker blocks the availability of the encryption keys, then the owner can't

decrypt his own message. A hacker can try to find security bugs in the operating system,

and try to maximize the access [5]. To access passwords or encryption keys, it is not

necessary to have maximum access to the system.

Hackers use a variety of tools to attack a system. Each of the tools has distinct

capabilities.

We describe the most popular tools from each of the following categories [6].

- Port scanners

- Vulnerability scanners

- Rootkits

- Sniffers

Port Scanners

Port scanners are probably the most commonly used scanning tools on the Internet. These

tools scan large IP spaces and report on the systems they encounter, the ports available

and other information, such as OS types. A popular port scanner is Network Mapper

Nmap [7, 3].

16
Vulnerability Scanners

Vulnerability scanners search for a specific vulnerability or scan a system for all potential

vulnerabilities. Vulnerability tools are freely available. The hackers use the tool to scan

systems and evaluate vulnerabilities to intrude into the system. One available

vulnerability scanner is Nessus [6].

Rootkits

According to findings from Kothapali [3], the computer and network users may today

face a hacker gaining root-level access to a system. This, in essence, gives the intruder

administrative control over the machine and thus an opportunity to cause serious

problems. This means, if the hackers use rootkits, they can install them on a victim's

computer to gain administrative access, and they can hide their presence on a system,

making them difficult to detect. Some of the tasks performed by rootkits are

 Modify system log files to remove evidence of the intruder’s activities.

 Modify system tools to make detection of an intruder’s modifications more

difficult.

 Create hidden back-door access points to the system.

 Use the system as a launch point for attacks against other networked systems.

Sniffers

Also according to Kothapali [3], in his findings, Network sniffing or just “sniffing” is

using a computer to read all network traffic. To perform sniffing, a network interface

must be put into promiscuous mode so that it forwards, to the application layer, all the

network traffic, not just network traffic destined for it. The Solaris OE includes a tool

17
called “snoop” that can capture and display all network traffic seen by a network interface

on the system. While being relatively primitive, this tool can quite effectively gather

clear-text user IDs and passwords passing over a network. Many popular protocols in use

today such as Telnet, FTP, IMAP, and POP-3 do not encrypt their user authentication and

identification information. Once a system is accessed, an intruder typically installs a

network sniffer on the system to gain additional user ID and password information, to

gather information about how the network is constructed and to learn what it is used for

[8]. This performance depends on the network.

2.0.4 What is Computer and Cyber Security?

Computer security involves all types of security threats that affect the computer system

and its related resources: data, hardware, software, information, telecommunication

bandwidth and computer services and their corresponding security counter measures to

protect the computer systems and its resources eradicate the threats by preventing or

eradicating the security threats.

There are many ways of defining what Computer and IT security or Cyber security is all

about; in this thesis, the following definition will be used:

“[Computer and IT] security deals with the prevention and detection of unauthorised actions by
users of a computer system.”[5]

18
2.1 Types of Attacks

Kothapali [3], in his research findings stated that major hacker attack types include:

- Malicious code (viruses, Trojan horses and worms)

- Wire trapping/Eavesdropping

- Intrusion

➢ Back door

➢ Brute force

➢ Dictionary attack

➢ Denial of Service (DoS) attack

Attacks by malicious code

Malicious code is code added to or changed in a software system in order to intentionally

cause harm or subvert the intended function of the computer [9]. Malicious code is

rapidly becoming a problem for industry, government and individuals.

Malicious code includes viruses, worms, and Trojan horses.

Viruses are pieces of malicious code that attach to host programs and copy themselves

into other programs when the infected program is executed.

Worms are particular to networked computers. Instead of attaching themselves to a host

program, worms carry out programmed attacks to start a process on other computers.

A Trojan horse is a program with an unwanted side effect. The program could give the

impression of doing something useful, but it could also actually do something useful. It is

called a Trojan horse because the program also contains a side-effect that the user does

not know and does not want.

19
Examples of malicious code damage

 Erasing or overwriting data on a computer.

 Encryption of files in a crypto viral extortion attack.

 Corrupting files in some subtle way.

 Upload and download files.

 Spreading other malware, such as viruses. In such a case the Trojan horse is also

called a dropper or vector.

 Setting up networks of zombie computers in order to launch DoS attacks or send

spam.

 Making screenshots.

 Logging keystrokes to steal information such as passwords and credit card

numbers.

 Phish for bank or other account details, which can be used for criminals activities.

 Installing a backdoor on a computer system [10].

 Most important of all: malicious code may search for stored encryption keys.

Wiretapping/eavesdropping [3]

This is an attack that intercepts and accesses data and other information contained in a

flow in a communication system. Originally, the term applied to a mechanical connection

to an electrical conductor. It now refers to reading information from any medium used for

a link or even directly from a node, gateway or switch. For example if we access the key

from a hard disk, there is a possibility that they can wiretap the key while transferring

from the hard disk to the operating system.

20
Eavesdropping is the intercepting of conversations by unintended recipients. One who

participates in eavesdropping (i.e. someone who secretly listens in on the conversations of

others) is called and eavesdropper. The origin of the term comes from situation in which

people would literally hide out in the eavesdrop to listen in on private conversations. For

example if we access the key from a hard disk, there is a possibility that an attacker can

listen to the commands and maybe then can apply those commands to get the key.

Intrusion [3]

This means that a hacker tries to break the security of, and gain access to, someone else's

system without being invited. If the hacker breaks the security, then the hacker can copy

the encryption keys or modify the keys. For example if the hacker modified the

encryption key, then the owner will loose the valuable information, because the owner

cannot decrypt his message with the modified encryption key.

Back door [3]

A back door is a means of access to a computer program that bypasses security

mechanisms. A programmer may sometimes install a back door so that the program can

be accessed for troubleshooting or other purposes. However attackers often use back

doors that they detect or install themselves, as part of an exploit.

Dictionary attack

A dictionary attack is a type of attack which is used for breaking a password-protected

computer and tries to find out a decryption key or pass phrases by searching large number

of possibilities [11, 12, 3].

21
Dictionary attack is a technique for defeating cipher or authentication mechanism.

Dictionary attacks work because many computer users and businesses insist on using

ordinary words as passwords.

Dictionary attacks are rarely successful against systems that employ multiple-word

phrases, and unsuccessful against systems that employ random combinations of uppercase

and lowercase letters mixed up with numerals. A form of dictionary attack is often used

by spammers. A message is sent to every e-mail address consisting of a word in the

dictionary, followed by at the symbol (@), followed by the name of a particular domain.

Lists of given names (such as frank, George, Judith, or Donna) can produce amazing

results. So can individual letters of the alphabet followed by surnames (such as csmith,

jwilson, or pthomas). E-mail users can minimize their vulnerability to this type of spam

by choosing usernames according to the same rules that apply to passwords and

decryption keys -- long, meaningless sequences of letters interspersed with numerals [13].

Brute-force attack

A Brute force attack consists of trying every possible code, combination, or password

until the right one is found [14]. A brute force attack is a method to obtain the user

authentication without the user's notice [15].

Denial of Service attack

A denial-of service attack (DoS attack) is an attempt to make a computer resource

unavailable to its intended users. Typically the targets are high-profile web servers, and

the attack attempts to make hosted web pages unavailable on the Internet. A Denial of

Service attack blocks the legal user's access to the server.

22
Attacks on smart cards

Smart cards provide security benefits. This can be incorporated in cryptographic protocols

that can protect the data from unauthorized users. However, the protection strength is

being overestimated by most of the users [16].

Unfortunately there are some tampering techniques to break the smart cards. Those

attacks are divided into four major attacks [17].

1. Microprobing

2. Software attacks

3. Eavesdropping

4. Fault generation

5. Cloning

Microprobing can be used to access the chip surface directly. We can observe,

manipulate, and interfere with the integrated circuit. Software attacks use the normal

communication interface of the processor and exploit security vulnerabilities found in the

protocols, cryptographic algorithms, or their implementation.

Eavesdropping techniques monitor, with high time resolution, the analog characteristics

of all supply and interface connections and any other electromagnetic radiation produced

by the processor during normal operation. Fault generation techniques use abnormal

environmental conditions to generate malfunctions in the processor that provide

additional access. Cloning entails exact duplicate production of IME number of the smart

card such as in SIM card of GSM.

23
Invasive attacks [3]

All microprobing techniques are invasive attacks. This involves a tampering of the device

which is clear for anyone. In fact most of the techniques listed here require an utter

destruction of the card hardware.

Physical invasive attack [3]

The physical attacks are performed to read the contents of memory or modify it through

probes. In a physical attack the probes act a major role to read the contents of data buses,

wires can be cut and alternative circuits can be added. Such attacks are conceivable, but

they require chemicals and acids to remove protective plastic layers around the smart card

processors.

Chemical solvents, etching and staining materials: These materials are able to decapsulate

and accurately de-layer smart card chips. The surface of the chip reveals the various

building blocks in the chip.

After this process the chip is accessible for optical or electrical analysis. In modern days

multiple layer chips are using this as an essential step in reverse engineering. The staining

is an advanced etching technique that uses differences in etching speed to reveal subtle

material differences that define the ones and zeros.

Micro-probing attack [3]

This is an invasive attack. The major component for this tool is a special optical

microscope and the attacker installs a probe. The probe consists of a metal shaft that holds

a long tungsten-hair. These allow the attacker to contact on-chip bus lines without

24
damaging them. This probe is connected via an amplifier to a digital signal processor card

that records or overrides processor signals and also provides the power, clock, reset, and

I/O signals needed to operate the processor via pins.

Non-invasive attacks [3]

“Non-invasive attacks are particularly dangerous in some applications for two reasons.

Firstly, the owner of the compromised card might not notice that the secret keys have

been stolen; therefore it is unlikely that the validity of the compromised keys will be

revoked before they are abused. Secondly, non-invasive attacks often scale well, as the

necessary equipment (e.g., a small DSP board with special software) can usually be

reproduced and updated at low cost”.

Timing analysis attack

These “attacks are based on measuring the time it takes for a unit to perform operations.

This information can lead to information about the secret keys”. To measure the time

required to perform private key operations, an attacker finds the fixed exponents, the

factors of the RSA keys, and break other cryptosystems. If a unit is vulnerable, the attack

is computationally simple and often requires only known cipher text. Cryptosystems are

often simple and require only cipher text. Cryptosystems often take slightly different time

to process different inputs. The performance characteristics typically depend on both the

encryption key and the input data (e.g. plaintext or cipher text). “Attacks exist which can

exploit timing measurements from vulnerable systems to find the entire secret key” [18].

25
Software attacks [3]

A number of attacks can be performed via software. For example, a Trojan horse

application could be used. The rogue application must be planted on an unsuspecting

user’s workstation.

Glitch attack

Most of the information below is from [19]. This is also a non-invasive attack “In a glitch

attack, the attacker deliberately generates a malfunction that causes one or more flip-flops

to adopt the wrong state. The aim is usually to replace a single critical machine

instruction with an almost arbitrary other one. Glitches can also aim to corrupt data values

as they are transferred between registers and memory”. Of the many fault-induction

attack techniques on smart cards that have been discussed in the recent literature, it has

been observed that glitch attacks are the ones most useful in practical attacks.

Attacks on PDAs

The threats for PDAs, that users need to be concerned with typically fall into one of these

three categories:

1. Identity Theft

2. Viruses and data corruption

3. Vulnerabilities of PDAs

One of the biggest security risks to PDAs is that these devices are handled in such a way

that they are easily forgotten and someone can easily steal them. For that reason securing

the data on the device in standalone mode is probably the best type of precaution users

26
can take. The second risk is because of viruses. Because of these problems encryption

solutions exist for PDAs to maintain security for both the data and links used to

communicate with remote systems and networks. By using an encryption product to

secure either the link to the desktop hot-sync system or for wireless surfing, you basically

need to wrap up your PDA traffic in a VPN. To protect the PDA from wireless

vulnerabilities you should install a VPN client on your PDA [20].

Identity Theft

This can be divided into two different tasks namely, password theft and theft of the PDA

itself. Both of them have the same similarities as the password theft or the theft of the

PDA would reveal the total personal data being stored in the device.

For example, if a user stores his personal details like the bank PIN numbers for his

accounts, then you can estimate what would be the consequences for this.

To protect from such a type of errors, it is always necessary to change your passwords

frequently and keep your important files in an external storage device.

Viruses and data corruption

For any software application there are always viruses associated with them. A virus is a

self-replicating program that spreads by inserting copies of itself into other executable

code or documents. The first virus that was found affecting the PDA’s was the Brador

virus, which attacks through an email or a download very easily. This virus helps to

access the PDA remotely. The most interesting thing for this virus is that it attacks the

Windows CE and then it simply copies itself to the svchost.exe file in the Windows auto

run folder and seizes control over the system after a restart.

27
The only solution for this is to install antivirus software. If the virus attacks, then the

antivirus software centres recommend /Windows/StartUp/svchost.exe to be deleted and

fully restore or reinstall the Windows CE [21].

Vulnerabilities of PDA’s

PDAs are most vulnerable to attacks during transport or through services and protocols

used.

Networked PDAs are vulnerable to synchronization and also to resource exhaustion

attacks.

Active sync and 802.11 wireless vulnerabilities are commonly seen in Windows based

PDAs. Active sync is a protocol that is used over a serial port of the PDA and this can

also be attacked. This synchronization can take place over a serial link or over a network.

Synchronization over a serial link: This is the most direct active sync connection that can

be established by connecting to the serial port of a PC. After this the PC will be prompted

to authenticate if and only if the device is set to required authentication. This

authentication is a 4 decimal digit called a Personal Identification Number (PIN). If the

PIN is correct, then the device will be connected and file transfers can take place from

PDA to PC or vice-versa. But if the PIN is incorrect then there will be two more chances

for the user to connect before the connection is broken. However it was observed that

there is no need to reconnect the device. A soft connection reset is enough to establish a

new connection. The key to this vulnerability is the trust relationship between the PDA

and the PC. Since the PDA acts as an authentication server, it should not trust the client

PC and the software running on it [22].

28
2.2 GSM Technology [23]

As early in the 1980s many countries in Europe witnessed a rapid expansion of analogue

cellular telephone system, however, each country developed its own system, and

interoperability across borders became a limiting factor. In 1982, the conference of

European post and telecommunications (CEPT), an association of telephone and

telegraph operators in Europe, established a working group to develop a new public land

mobile system to span the continent. Because their working language was French, the

group was called the group special mobile (GSM).

GSM (Global System for Mobile communication) is a digital mobile telephone system

that is widely used in Europe. About 85.5 million subscribers use GSM in Nigeria alone

[24]. GSM uses a variation of Time Division Multiple Access (TDMA) and is the most

widely used of the three digital wireless telephone technologies (TDMA, GSM, and

CDMA). GSM digitizes and compresses data, then sends it down a channel with two

other streams of user data, each in its own time slot. GSM operates in the 900MHz,

1800MHz, or 1900 MHz frequency bands.

GSM is the de facto wireless telephone standard in Europe and about over 35 million

subscribers to GSM services are now in Africa [23]. GSM has over one billion users

worldwide and is available in 190 countries. Since many GSM network operators have

roaming agreements with foreign operators, users can often continue to use their mobile

phones when they travel to other countries.

29
GSM together with other technologies is part of an evolution of wireless mobile

telecommunication that includes High-Speed Circuit-Switched Data (HCSD), General

Packet Radio System (GPRS), Enhanced Data GSM Environment (EDGE), and Universal

Mobile Telecommunications Service (UMTS).

2.2.1 GSM Properties [23]

 Cellular radio network

 Digital transmission up to 9600 bit/s

 Roaming (mobility among different network providers, international)

 Good transmission quality (error recognition and correction)

 Scalable

 Worldwide 900 million subscribers

 Europe: over 300 million subscribers

 Security mechanisms provided (authentication, authorisation, encryption)

 Good usage of resources (frequency- and time-multiplex)

 Integration with ISDN and analogue telephone network

30
Fig 2.2. Architecture of the GSM network [25]

2.2.2 The Mobile Station [26]

The Mobile Station (MS) is the user equipment in GSM. The MS is what the user can see

of the GSM system. The station consists of two entities, the Mobile Equipment (the phone

itself), and the Subscriber Identity Module (SIM), in form of a smart card contained

inside the phone.

2.2.3 The Base Transceiver Station [26]

The Base Transceiver Station (BTS) is the entity corresponding to one site

communicating with the Mobile Stations. Usually, the BTS will have an antenna with

several TRXs (radio transceivers) that each communicate on one radio frequency. The

link-level signalling on the radio-channels is interpreted in the BTS, whereas most of the

higher-level signalling is forwarded to the BSC and MSC. Speech and data-transmissions

31
from the MS is recoded in the BTS from the special encoding used on the radio interface

to the standard 64 kbit/s encoding used in telecommunication networks. Like the radio-

interface, the interface between the BTS and the BSC is highly standardized, allowing

BTSs and BSCs from different manufacturers in one network.

2.2.4 The Base Station Controller [26]

Each Base Station Controller (BSC) controls several hundred BTSs. The BSC takes care

of a number of different procedures regarding call setup, location update and handover for

each MS.

2.2.5 The Mobile Switching Centre [26]

The Mobile Switching Centre is a normal ISDN-switch with extended functionality to

handle mobile subscribers. The basic function of the MSC is to switch speech and data

connections between BSCs, other MSCs, other GSM-networks and external non-mobile-

networks. The MSC also handles a number of functions associated with mobile

subscribers, among others registration, location updating and handover. There will

normally exist only a few BSCs per MSC, due to the large number of BTSs connected to

the BSC. The MSC and BSCs are connected via the highly standardized A-interface

[GSM0808]. However, due to the lack of standardization on Operation and Management

protocols, network providers usually choose BSCs, MSCs and Location Registers from

one manufacturer.

32
2.2.6 The Equipment Identity Register [26]

The Equipment Identity Register (EIR) is an optional register. Its purpose is to register

IMEIs of mobile stations in use. By implementing the EIR the network provider can

blacklist stolen or malfunctioning MS, so that their use is not allowed by the network.

Note that this has not been done in Nigeria by GSM service provider companies so there

is rampant reintroduction of stolen handsets both intra and inter networks.

2.2.7 Subsystems [23]

 Radio Sub System (RSS)

- RSS = MS + BSS

- BSS = BTS+ BSC

 Network Sub System (NSS)

- NSS = MSC+ HLR + VLR + GMSC

- Operation Sub System

 OSS = EIR + AuC

 Handles handovers

 Radio Sub System (RSS)

- RSS = MS + BSS

- BSS = BTS+ BSC

 Network Sub System (NSS)

- NSS = MSC+ HLR + VLR + GMSC

- Operation Sub System

 OSS = EIR + AuC

33
2.2.8 GSM –Frequencies [23]

GSM-900:

 Uplink: 890,2 MHz – 915 MHz (25 MHz)

 Downlink: 935,2 MHz – 960 MHz (25 MHz)

 Uplink-Downlink distance: 45 MHz

Frequency Division Multiple Access[23]

 Channels are 200 kHz wide.

 124 pairs of channels

 Frequency band 890-915 MHz

 935-960 MHz

 1710-1785 MHz

 1805-1880 MHz

 Border spacing 25 MHz 75 MHz

 Duplex spacing 45 MHz 95 MHz

 Carrier spacing 200 kHz 200 kHz

 Carriers 124 374

 Timeslots per carrier 8

 Multiple access TDMA/FDMA

 Typical cell range <300m – 35 km <100m – 15 km

 Handset Power 0.8 & 8 W 0.25 & 1 W

34
Time Division Multiple Access

 8 connections each channel

 Theoretical 124*8 = 992 channel to use.

GSM-1800:

 Uplink: 1725,2 - 1780,4 MHz

 Downlink: 1820,2 - 1875,4 MHz

 Uplink-Downlink distance: 95 MHz

 384 pairs of channels

GSM 900 and GSM 1800 [23]

GSM 900 GSM 1800 GSM 900 GSM 1800

Frequency band 890 890-915 MHz 1710-1785 MHz

935-960 MHz 1805-1880 MHz

Border spacing 75 MHz 25 MHz 75 MHz

Duplex Spacing 45 MHz 95 MHz

Carrier Spacing 200 KHz 200 kHz

Carriers 124 374

Timeslots per carrier 8 8

Multiple Access TDMA/FDMA TDMA/FDMA

Typical cell range <300m – 35km <100m – 15km

Handset Power 0.8 & 8W 0.25 & 1W

Table 2.1 : GSM 900 GSM 1800

35
GSM link [23]

 Full rate-Channel (Speech) 13 kBit/s

 Half rate-Channel (Speech) 6.5 kBit/s

 GSM-Data-Channel 9.6 kBit/s

2.2.9 FDMA and TDMA

Fig 2.3: FDMA in GSM 900

36
Fig 2.4: TDMA in GSM 900

2.3 GSM Security Architecture [27]

GSM security issues such as theft of service, privacy, and legal interception continue to

raise significant interest in the GSM community. The purpose of this study is to raise

awareness of these issues with GSM security.

GSM is the most widely used cellular mobile phone system in the world with over 100

million GSM subscribers. GSM was one of the first digital mobile phone systems to

follow the analogue era. Widely known problems with GSM's analogue counter parts

were the possibility of phone fraud through cloning phones and thus calling in someone

else's expense, and the possibility of someone intercepting the phone call over the air and

eavesdropping on the discussion. The GSM system was supposed to correct these

37
problems by implementing strong authentication between the MS and the MSC, as well as

implementing strong data encryption for the over-the-air transmission channel between

the MS and the BTS.

The GSM specifications were designed by the GSM Consortium in secrecy and were

distributed only on a need-to-know basis to hardware and software manufacturers and to

GSM network operators. The specifications were never exposed to the public, thus

preventing the open science community around the world from studying the enclosed

authentication and enciphering algorithms as well as the whole GSM security model. The

GSM Consortium relied on Security by Obscurity, i.e. the algorithms would be harder to

crack if they were not publicly available. According to the open scientific community,

one of the basic requirements for secure cryptographic algorithms is that the security of

the crypto system lies solely on the key. This is known as Kerckhoffs' assumption. The

algorithm in question should be publicly available, so that the algorithm is exposed to the

scrutiny of the public. According to the general opinion no single entity can employ

enough experts to compete with the open scientific community in cryptanalysing an

algorithm. Thus, the algorithms designed and implemented in secrecy will probably be

somehow cryptographically weak and contain design faults. Eventually, the GSM

algorithms leaked out and have been studied extensively ever since by the open scientific

community. Interesting facts have been discovered since then, during the cryptanalysis of

the A3, A5 and A8 algorithms.

38
2.3.1 GSM Security Model [27]

The GSM security model is based on a shared secret between the subscriber's home

network's HLR and the subscriber's SIM. The shared secret, called Ki, is a 128-bit key

used to generate a 32-bit signed response, called SRES, to a Random Challenge, called

RAND, made by the MSC, and a 64-bit session key, called Kc, used for the encryption of

the over-the-air channel. When a MS first signs on to a network, the HLR provides the

MSC with five triples containing a RAND, a SRES to that particular RAND based on the

Ki and a Kc based again on the same Ki. Each of the triples is used for one authentication

of the specific MS. When all triples have been used the HLR provides a new set of five

triples for the MSC [27, 28].

When the MS first comes to the area of a particular MSC, the MSC sends the Challenge

of the first triple to the MS. The MS calculates a SRES with the A3 algorithm using the

given Challenge and the Ki residing in the SIM. The MS then sends the SRES to the

MSC, which can confirm that the SRES really corresponds to the Challenge sent by

comparing the SRES from the MS and the SRES in the triple from the HLR. Thus, the

MS has authenticated itself to the MSC. Figure 2.5.

Figure 2.5: Mobile Station Authentication

39
The MS then generates a Session Key, Kc, with the A8 algorithm using, again, the

Challenge from the MSC and the Ki from the SIM. The BTS, which is used to

communicate with the MS, receives the same Kc from the MSC, which has received it in

the triple from the HLR. Now the over-the-air communication channel between the BTS

and MS can be encrypted.

Each frame in the over-the-air traffic is encrypted with a different keystream. This

keystream is generated with the A5 algorithm. The A5 algorithm is initialized with the Kc

and the number of the frame to be encrypted, thus generating a different keystream for

every frame. This means that one call can be decrypted when the attacker knows the Kc

and the frame numbers. The frame numbers are generated implicitly, which means that

anybody can find out the frame number at hand. The same Kc is used as long as the MSC

does not authenticate the MS again, in which case a new Kc is generated. In practice, the

same Kc may be in use for days. The MS authentication is an optional procedure in the

beginning of a call, but it is usually not performed. Thus, the Kc is not changed during

calls (Figure 2.6).

Figure 2.6: Frame encryption and decryption

40
Only the over-the-air traffic is encrypted in a GSM network. Once the frames have been

received by the BTS, it decrypts them and sends them in plaintext to the operator’s

backbone network [28].

Fig 2.7: User authentication

2.3.2 A3, The MS Authentication Algorithm [27]

The A3 is the authentication algorithm in the GSM security model. Its function is to

generate the SRES response to the MSC's random challenge, RAND, which the MSC has

received from the HLR. The A3 algorithm gets the RAND from the MSC and the secret

key Ki from the SIM as input and generates a 32-bit output, which is the SRES response.

Both the RAND and the Ki secret are 128 bits long (Figure 2.8).

41
Figure 2.8: Signed response (SRES) calculation

Nearly every GSM operator in the world uses an algorithm called COMP128 for both A3

and A8 algorithms. COMP128 is the reference algorithm for the tasks pointed out by the

GSM Consortium. Other algorithms have been named as well, but almost every operator

uses the COMP128 except a couple of exceptions [29].

The COMP128 takes the RAND and the Ki as input, but it generates 128 bits of output,

instead of the 32-bit SRES. The first 32 bits of the 128 bits form the SRES response [30].

2.3.3 A8, The Voice-Privacy Key Generation Algorithm

The A8 algorithm is the key generation algorithm in the GSM security model. The A8

generates the session key, Kc, from the random challenge, RAND, received from the

MSC and from the secret key Ki. The A8 algorithm takes the two 128-bit inputs and

generates a 64-bit output from them. This output is the 64-bit session key Kc [30]. See

Figure 2.9. The BTS received the same Kc from the MSC. HLR was able to generate the

Kc, because the HLR knows both the RAND (the HLR generated it) and the secret key

Ki, which it holds for all the GSM subscribers of this network operator. One session key,

Kc, is used until the MSC decides to authenticate the MS again. This might take days.

42
Figure 2.9: Session key (Kc) calculation

As stated in 2.3.2, COMP128 is used for both the A3 and A8 algorithms in most GSM

networks. The COMP128 generates both the SRES response and the session key, Kc, on

one run. The last 54 bits of the COMP128 output form the session key, Kc, until the MS

is authenticated again. Note that the key length at this point is 54 bits instead of 64 bits,

which is the length of the key given as input to the A5 algorithm. Ten zero-bits are

appended to the key generated by the COMP128 algorithm. Thus, we have a key of 64

bits with the last ten bits zeroed out. This effectively reduces the keyspace from 64 bits to

54 bits. This is done in all A8 implementations, including those that do not use COMP128

for key generation, and seems to be a deliberate feature of the A8 algorithm

implementations [30].

Figure 2.10: COMP128 calculation

Both the A3 and A8 algorithms are stored in the SIM in order to prevent people from

tampering with them. This means that the operator can decide which algorithms to use

43
independently from hardware manufacturers and other network operators. The

authentication works in other countries as well, because the local network asks the HLR

of the subscriber's home network for the five triples. Thus, the local network does not

have to know anything about the A3 and A8 algorithms used.

2.3.4 A5/1, The Strong Over-the-Air Voice-Privacy Algorithm

The A5 algorithm is the stream cipher used to encrypt over-the-air transmissions. The

stream cipher is initialized all over again for every frame sent. The stream cipher is

initialized with the session key, Kc, and the number of the frame being de/encrypted. The

same Kc is used throughout the call, but the 22-bit frame number changes during the call,

thus generating a unique keystream for every frame [31]. See Figure 2.11.

Figure 2.11: Keystream generation

The A5 algorithm used in European countries consists of three LSFRs of different lengths

[32]. See Figure 2.11. The combined length of the three LSFRs is 64 bits. The outputs of

the three registers are XORed together and the XOR represents one keystream bit. The

LSFRs are 19, 22 and 23 bits long with sparse feedback polynomials. All three registers

are clocked, based on the middle bit of the register. A register is clocked if its middle bit

44
agrees with the majority value of the three middle bits. For example, if the middle bits of

the three registers are 1, 1 and 0, the first two register are clocked or if the middle bits are

0, 1 and 0, then the first and third register are clocked. Thus, at least two registers are

clocked on every round [28]. See Figure 2.12.

Figure 2.12: An example LSFR with feedback polynomial of x6 + x4 + x

Figure 2.13: A5 LSFR construction

The three LSFRs are initialized with the session key, Kc, and the frame number. The 64-

bit Kc is first loaded into the register bit by bit. The LSB of the key is XORred into each

of the LSFRs. The registers are then all clocked (the majority clocking rule is disabled).

All 64 bits of the key are loaded into the registers the same way. The 22-bit frame number

45
is also loaded into the register in the same way except that the majority clocking rule

applies from now on. After the registers have been initialized with the Kc and the current

frame number, they are clocked one hundred times and the generated keystream bits are

discarded. This is done in order to mix the frame number and keying material together.

Now 228 bits of keystream output are generated. The first 114 bits are used to encrypt the

frame from MS to BTS and the next 114 bits are used to encrypt the frame from BTS to

MS. After this, the A5 algorithm is initialized again with the same Kc and the number of

the next frame [30, 31].

Since the first GSM systems, other A5 algorithms have been designed and implemented.

The main motivation has been that the original A5 encryption algorithm is too strong to

export to the Middle East. Thus, the first 'original' A5 algorithm was renamed A5/1. Other

algorithms include A5/0, which means no encryption at all, and A5/2, a weaker over-the-

air privacy algorithm. Generally, the A5 algorithms after A5/1 have been named A5/x.

Most of the A5/x algorithms are considerably weaker than the A5/1, which has the time

complexity of 2^54 at most as, shown above. The estimated time complexity of A5/2 is as

low as 2^16. This encryption is used in the USA. The other A5 implementations have not

leaked. Thus, there are no real facts about them, just guesses and assumptions [29, 33,

34].

46
2.4 GSM attack scenarios [27]

The interesting question about the GSM security model is whether a call can be

eavesdropped, now that at least one of the algorithms it depends on has been proven

faulty.

Scientists around the world seem to be unanimous that the over-the-air interception and

real time decoding of a call is still impossible regardless of the reduced key space [29].

But there seem to be other ways of attacking the system that are feasible and seem to be

very real threats. There are also many attacks that are realistic, yet do not abuse any of the

faults in the security algorithms.

2.4.1 Brute-Force Attack against A5 [27]

A real-time brute-force attack against the GSM security system is not feasible, as stated

above. The time complexity of the attack is 2^54 (2^64 if the ten bits were not zeroed

out). This requires too much time in order to be feasible in eavesdropping on GSM calls

in real time. It might be possible to record the frames between the MS and the BTS and

launch the attack afterwards though.

If we have a Pentium III class chip with approximately 20 million transistors and the

implementation of one set of LSFRs (A5/1) would require about 2000 transistors, we

would have a set of 10,000 parallel A5/1 implementations on one chip. If the chip was

clocked to 600 MHz and each A5 implementation would generate one output bit for each

clock cycle and we would need to generate 100+114+114 output bits, we could try

approximately 2M keys per second per A5/1 implementation. A keyspace of 2^54 keys

47
would thus require about 900,000 seconds, 250 hours, with one chip. The attack can be

optimized by giving up on a specific key after the first invalid keystream bit. This would

cut the required time down by one third. The attack can also be distributed between

multiple chips, thus drastically decreasing the time required.

2.4.2 Divide-and-Conquer Attack against A5 [27]

A divide-and-conquer attack manages to reduce the complexity from 2^54 of the brute-

force attack to 2^45, which is a relatively dramatic change (2^9 = 512 times faster

[31].The divide-and-conquer attack is based on a known-plain-text attack. The attacker

tries to determine the initial states of the LSFRs from a known keystream sequence. The

attacker needs to know 64 successive keystream bits that can be retrieved if the attacker

knows some cipher text and the corresponding plain text [35]. This depends largely on the

format of the GSM frames sent back and forth. The GSM frames contain a lot of constant

information, e.g. frame headers. The required 64 bits might not always be known, but 32

to 48 bits are usually known, sometimes even more. Keep in mind that the attacker needs

only one 64-bit plain text segment.

In short the divide-and-conquer attack is implemented by guessing the content of the two

shorter LSFRs and then computing the third LSFR from the known keystream. This

would be a 2^40 attack, if the clockings of the first two registers were not dependent on

the third register. Because the middle bit of the third register is used for clocking, we have

to guess about half of the bits in the third register between the clock bit and the LSB as

well. This fact increases the time complexity from 2^40 to 2^45 [29].

48
However, Golic [35], has proposed another divide-and-conquer attack based on the same

assumptions with the average complexity of 2^40.16. Golic showed that only 2^62.32

internal states could be reached from the 2^64 initial states. Based on this assumption, he

describes how to obtain linear equations by guessing n bits in the LSFRs. By solving

these linear equations, one could recover the initial states of the three LSFRs. The

complexity of solving the linear equations is 2^41.16. On average, one would resolve the

internal state with 50 per cent chance in 2^40.16 operations.

Golic [35] also proposed a Time-Memory Trade-Off Attack based on the Birthday

Paradox in the same paper. The objective of the attack is to recover the internal states of

the three LSFRs at a known time for a known keystream sequence corresponding to a

known frame number, thus reconstructing the session key, Kc.

2.4.3 Accessing the Signalling Network

As the two examples above clearly state, the A5 algorithm is not secure

cryptographically, as there is another more feasible attack than the brute-force attack and

it is not secure in practice either, because the brute-force attack in itself is not very hard to

implement with current hardware. Yet, the algorithm is secure enough to prevent over-

the-air call interception and real-time encryption cracking. Unfortunately, the air waves

between the MS and the BTS are not the only vulnerable point in the GSM system.

49
As stated earlier, the transmissions are encrypted only between the MS and the BTS.

After the BTS, the traffic is transmitted in plain text within the operator’s network [28,

36].

This opens up new possibilities. If the attacker can access the operator's signalling

network, he will be able to listen to everything that is transmitted, including the actual

phone call as well as the RAND, SRES and Kc. The SS7 signalling network used in the

operator's GSM network is completely insecure if the attacker gains direct access to it

[36].

In another scenario, the attacker could attack the HLR of a particular network. If the

attacker can access the HLR, he will be able to retrieve the Kis for all the subscribers of

that particular network. Luckily the HLR is usually a bit more secure than the rest of the

network, thus making it a slightly less probable point of entry, yet not completely

improbable either keeping in mind the potential gain involved [36]. Accessing the

signalling network is not very difficult. Although the BTSs are usually connected to the

BSC through a cable, some of them are connected to the BSC through a microwave or

even a satellite link. This link would be relatively easy to access with the right kind of

equipment. Most of the commercially available equipment for GSM eavesdropping seem

to use this particular vulnerability. Unfortunately it is not possible verify this, because the

equipment and specifications are available only to law enforcement personnel and such.

The microwave link might be encrypted, however, depending on the hardware

manufacturer, thus making it slightly more difficult to monitor it [36]. It is really a

question about whether the attacker wants to crack the A5 encryption protecting the

session of a specific MS or the encryption between the BTS and the BSC and gaining

50
access to the backbone network. The possibility of accessing the cable leaving the BTS

should not be ruled out either. This might be a very real threat and an attack could go

undetected for a long time, if implemented carefully. The ability to tap on to the data

transmitted between the BTS and BSC would enable the attacker to either monitor the call

by eavesdropping on the channel throughout the call or he could retrieve the session key,

Kc, by monitoring the channel, intercept the call over the air and decrypt it on the fly.

Now that he knows the Kc, the real-time encryption is not a problem.

Another approach is through social engineering. This approach should not be

underestimated although it sounds ludicrous. The attacker might pretend to be a repair

man or such, enter a suitable building and install a wire tap. He might also bribe an

engineer to do it for him or to give him all the Kis for all the subscribers of that particular

operator. The possibilities are countless and real.

2.4.4 Retrieving the Key from the SIM [27].

The security of the whole GSM security model is based on the secret Ki. If this key is

compromised the whole account is compromised. Once the attacker is able to retrieve the

Ki, he can not only listen to the subscribers calls, but also place calls billed to the original

subscriber's account, because he can now impersonate the legitimate subscriber. The

GSM network has trip wires for this: If two phones with the same ID are powered at the

same time, the GSM network notices this, makes a location query for the phones, notices

that the 'same' phone is in two different locations at the same time, and closes the account,

thus preventing the attacker and the legitimate subscriber from placing calls [29]. But this

51
is not relevant if the attacker is only interested in listening to the calls of the subscriber, as

is assumed in this study. In this case, the attacker can stay passive and just listen to the

call, thus staying invisible to the GSM network.

The Smartcard Developer Association and the ISAAC security research group discovered

a flaw in the COMP128 algorithm that effectively enabled them to retrieve the secret key,

Ki, from a SIM [29]. The attack was performed on a SIM they had physical access to, but

the same attack is applicable when launched over-the-air as well.

The attack is based on a chosen-challenge attack that works, because the COMP128

algorithm is broken in such a way that it reveals information about the Ki when the

appropriate RANDs are given as arguments to the A8 algorithm. The SIM was accessed

through a smartcard reader connected to a PC. The PC made about 150.000 challenges to

the SIM and the SIM generated the SRES and the session key, Kc, based on the challenge

and the secret key. The secret key could be deduced from the SRES responses through

differential cryptanalysis. The smartcard reader used in implementing the attack could

make 6.25 queries per second to the SIM card. So the attack required about eight hours to

conduct. The results had to be analyzed as well, but this was apparently very quick,

compared to the actual attack. Thus, the attacker needs to have physical access to the

target SIM for at least eight hours. This is still very reasonable.

Again this vulnerability is also applicable in a social engineering scenario. One can

assume that a corrupt GSM dealer would clone SIM cards in this way and then sell the

cloned cards to third parties who wish to remain anonymous and do not want to buy

legitimate SIMs. One could also try to sell a cloned SIM to a certain person in order to be

able to eavesdrop on his calls later. A corrupt employee might also provide the attacker

52
with the SIM card of the victim, so that the attacker can clone the SIM and later

eavesdrop on the owner's calls. These are all very realistic scenarios in which the

vulnerability found in the COMP128 algorithm compromises the whole security model of

the GSM system, thus leaving the subscribers in the open with no security at all.

2.4.5 Retrieving the Key from the SIM over the Air [27].

The SDA and ISAAC researchers are confident that the same SIM-cloning attack could

be launched over the air as well. Unfortunately, they can probably not confirm their

suspicions, because the necessary equipment is illegal in the United States. The over-the-

air attack is based on the fact that the MS is required to respond to every challenge made

by the GSM network [29, 36]. If the signal of the legitimate BTS is over powered by a

rogue BTS of the attacker, the attacker can bomb the target MS with challenges and re-

construct the secret key from these responses. Again the MS has to be available to the

attacker over the air for the whole time it takes to conduct the attack. It is not known how

long the attack would take when conducted over the air. Estimates vary from eight to

thirteen hours [29].

The attack might be conducted in a subway, where the signal of the legitimate BTS is not

available, but the phone is still turned on. The subscriber would be unaware of such an

attack though the fact that the battery of the phone has run out slightly quicker than usual

might make him suspicious. The attack can also be performed in parts: instead of

performing an eight-hour attack, the attacker could tease the phone for twenty minutes

53
every day on the victim's way to work. Once the SIM is cloned, the SIM-clone is usable

until the subscriber gets a new SIM, which in practice does not happen very often.

In another scenario, the subscriber is on a business trip in another country. The attacker

has somehow bullied the local GSM operator to perform this attack on the subscriber’s

phone. The attacker would again be able to reconstruct the Ki based on the MS's SRES

answers and the attack would probably go unnoticed, because the challenges originate

from a legitimate network. Keep in mind that the local network does not know anything

about the Ki, because the triples originate from the HLR of the subscribers home network.

Thus, the local network has to deduce the Ki from the A3 responses.

2.4.6 Retrieving the Key from the AuC

The same attack used in retrieving the Ki from a SIM card can be used to retrieve the Ki

from the AuC. The AuC has to answer to requests made by the GSM network and return

valid triples to be used in MS authentication. The procedure is basically identical to the

procedure used in the MS to access the SIM card. The difference is that the AuC is a lot

faster in processing requests than a SIM card is, because it needs to process a lot more

requests compared to one SIM card. The security of the AuC plays a big role in whether

this attack is possible or not and that is out of the scope of this research c.

2.4.7 Cracking the A8 Algorithm [27]

Another possibility is that someone will be able to crack the A8 key generation algorithm

and retrieve the secret key, Ki, based on the random challenge, RAND, the session key,

Kc, and the SRES response (assuming the same algorithm is used for both A3 and A8 as

is the case with COMP128) with a minimal amount of work. For example, the attacker

54
may find a RAND that produces the Ki as a result (an over simplified example). All three

variables are obtained relatively easily. The RAND and SRES are sent over the air in

plain text and the session key Kc can be relatively easily deduced from the encrypted

frames and the known plain text given enough time. A vulnerability like this in the key

generation algorithm would of course devastate the whole GSM security model and give

the GSM Consortium something to think about when designing their next security

algorithms.

2.4.8 Altering of Data Messages

Once a call has been hijacked, the attacker decides on the content. The attacker can listen

to the content of the message being sent by the victim, and send his own version. The

attacker can stop the message, or send his own message. This compromises the integrity

of GSM traffic.

2.5 Smart Cards [37]

Smart cards in the wireless marketplace provide: improved network security through user

identification, a facility for storing user data, and a mechanism for recording various

service data events. These capabilities enable improved service customization and

portability in a secure environment, especially suited for various transaction based

services.

Smart cards are tamper resistant and utilize ISO-standardized Application Protocol Data

Units (APDU) to communicate with host devices via PIN codes and cryptographic keys.

55
2.5.1 Types of Smart Cards [37]

Contact Cards and Contactless Cards

Contact Cards require insertion into a smart card reader with a direct connection to a

conductive micro-module on the surface of the card.

Contactless Cards require only close proximity (a few inches) of a reader.

Categories of Smart Cards

 Integrated Circuit (IC) Microprocessor Cards: Allow for adding, deleting, or

manipulating information in memory, allowing for a variety of applications and

dynamic read/write capabilities. Most Smart Cards in use for mobile applications

are of this type.

 IC Memory Cards: Can store data, but do not have a processor on the card.

 Optical Memory Cards: Can only store data, but have a larger memory capacity

than IC memory cards.

56
2.5.2 Smart Card Standards [37]

ISO 7816 is the international standard for Smart Cards.

SIM

The introduction of smart cards for wireless communications occurred in the early 1990’s

when GSM networks deployed the Subscriber Identity Module (SIM) – a security module

initially deployed to provide a facility for challenge/response authentication for GSM

subscribers.

Fig. 2.14 : SIM card smart card in a GSM mobile phone

SIM hardware consists of a microprocessor, ROM, persistent EEPROM memory, volatile

RAM, and a serial I/O interface. SIM software usually consists of an operating system,

file system, and application programs. As with all smart cards, the SIM relies on the card

terminal – the GSM handset – for battery and clock.

57
STK

The SIM evolved to incorporate the use of the SIM Toolkit (STK) - an important API for

securely loading applications to the SIM. STK allows the mobile operator to

create/provision services by loading them into the SIM without changing anything in the

GSM handset. One convenient way for loading applications to the SIM is over-the-air via

Short Message Service (SMS). Once loaded, applications on the SIM can be activated via

various event triggers registered by the application at the STK. Occurrences such as an

incoming/outgoing call or SMS message, call duration, and/or location of the mobile can

all act as triggers. Control software with the SIM monitors such events and reports

activities via SMS to a network based application server. This facilitates excellent

systems for smart card based value-added services such as mobile prepay and location

based services.

Java Card [37]

The Java card sits on top of the smart card OS, allowing application programmers’ access

for deployment of services independent of the hardware and OS of the smart card.

Executable code is platform independent, meaning that any card incorporating a Java

Card interpreter can run the same application. When coupled with the STK, the Java card

allows services to load and run on cards from different vendors.

58
UIM [37]

Introduced by the CDMA Development Group and the 3GPP2, the Removable User

Identity Module (R-UIM) card represents a smart card for use with CDMA based mobile

phones.

WIM [37]

Introduced with WAP specification 1.2, the WAP Identification Module (WIM) provides

end-to-end security for WAP, improving on version 1.1 which only provided transport

security between the handset and the WAP gateway.

S@T [37]

The SIM Alliance has proposed a SIM Alliance Toolkit (S@T) as an industry standard

for WAP based services for via any GSM phase 2+ phone that is not WAP enabled. The

SIM Alliances states that one of the key benefits of S@T is the availability of WAP based

services to non-WAP phones. Furthermore, all WAP browsers earlier than version 1.2 do

not support WIM, making S@T and an enabler of secure transactions thanks to the SIM.

59
2.5.3 Smart Card Applications for Mobile Networks [37]

Smart Cards may be used for a variety of applications such as financial services and

mobile prepay. Ability for them to store personal user-related information allows them to

be used for key data such as personal preferences, health history, and financial

information such as account balances. The ability to dynamically update the information

is a key attribute.

2.6 Cryptography

According to Knudsen [38], the writer of Java Cryptography, has described that

cryptography is the art of secret writing. Generally, cryptography is one of the branches

of mathematics. It uses an algorithm to encrypt the information and transforms it to

unreadable format. The reverse process is decryption. It is always used for authentication,

integrity and confidential purpose. Normally, cryptography is applied in the network

security and data protection such as secure transaction, email, and important file.

Symmetric and asymmetric algorithms are two famous algorithms in cryptography [39].

2.6.1 Java Cryptography [39]

Java cryptography is the cryptography that is used in Java application for security

rationale. Java Security API (Application Programming Interfaces), which is a library

written by Sun, has hid those complexities of mathematic. User only uses the security

concept when writing the associate code and leaves the library to deal with the underlying

details. In moving to informational society, the need to keep privately classified

60
information has raised urgently. Internet causes anonymity. Malicious hackers can mimic

to be someone else to perform illegal business transaction and cause the fraud. Therefore,

awareness on preventing the unauthorized person from accessing and modifying the

private data has also increased.

Due to the above mentioned phenomenon, Java cryptography has come out with the

solution such as Signature and Cipher to overcome those security concerns. The digital

signature is like the real signature that can identify yourself as whom you declared you

are. It supports for non-repudiation, which does not allow impersonation to be occurred.

Furthermore, it is difficult to make changes on the message which is digitally signed.

Thus, the integrity of data is preserved. The main contribution of cipher is the ability to

perform encryption and decryption on secret information. Encrypted message is in

unreadable mess. The person who has the right access is able to decrypt the message and

reach the sensitive message content.

2.6.2 Digital Signature [39]

In public key cryptography, two electronic-generated keys are chosen, which are public

key and private key. To perform digital signature on digital data or message, private key

is used. This private key is kept privately by the owner. It is hard to forge the digital

signed message.

2.6.3 Symmetric Algorithm [39]

There is a lot of symmetric algorithm available for cryptography purpose. As mentioned

before, the security of algorithm depends on the chosen algorithm and decided key length.

61
Generally, the algorithm uses a secret key to change the normal text into unreadable

cipher text (encryption) and then use back the same key and algorithm to get back to the

original text.

Symmetric encryption is simple, fast, and easy to apply on digital message. This is the

main reason why it is so popular in electronic commerce (E-commerce). The execution

speed on performing encryption and decryption is within 10 milliseconds with minimal

computer power. The mobile devices such as cell phone and Personal Digital Assistance

(PDA) phone take longer time (within 100 milliseconds) due to low processor power. The

publicly used symmetric algorithms are DES, Triple DES, AES, Blowfish, RC2 and RC5.

2.6.4 Asymmetric Algorithm compared with Symmetric

Asymmetric encryption is different with symmetric encryption in several features. First,

two electronic keys (public key and private key) are used in the operation of asymmetric

encryption and decryption. Symmetric encryption needs the agreement of both parties on

the shared key. The possibility of key disclosure is high. In asymmetric encryption, public

key can be distributed freely while the private key is known and kept only by the owner.

This concept has successfully eliminated the worry in sharing the same key with others

especially for group communication. It is difficult to ensure the shared key is not known

to the public when there is large number of group members.

2.7 Java In-Built Security Technologies [2]

The security in JAVA SE (JAVA Standard Edition) is basically JAVA Cryptography

(JCE since JDK 1.4). The class is known as javax.crypto. This is used for encryption and

decryption purposes.

62
2.7.1 The Basic Security in MIDP [2]

The security classes that are inbuilt into J2ME (JAVA 2 platform for Micro Edition) for

MIDP (Mobile Information Device Platform) devices such as Mobile Phones, Personal

Digital Assistants (PDAs), Out-of-the Box TV, etc are as follows:

- SATSA Crypto (JSR-117)

- Bouncy Castle API

SATSA Crypto (JSR-117) is a subset of JAVA Cryptography Extension (JCE).

MIDP 2.0 compatible devices such as some Nokia mobile phones such as

- Mandates HTTPS

- Optionally supports JAVA Security API

- Does not support JAVA Cryptography Extension but optionally supports its

subset SATSA Crypto (JSR-117)

- Equally supports Bouncy Castle Security API

2.7.2 SATSA-CRYPTO (JSR-117) [2]

SATSA-CRYPTO features include:

- Message digests: used to create a "fingerprint" of a piece of data (aka hashvalue)

- Algorithms: e.g. SHA-1 or RipeMD

- Digital signatures: useful for verifying data integrity, generated using a private key

(much harder to forge compared to message digests)

- Ciphers: decryption/encryption algorithms

- Typically symmetric only

63
2.7.3 Bouncy Castle [2]

Bouncy Castle is a third-party JAVA cryptographic security algorithm which contains

hundreds of security ciphers and digests needed for encryption and decryption in a JAVA

MIDlet program.

Bouncy Castle features include:

- Lightweight Cryptography API

- Implementation that works in MIDP/J2ME

- Supports (asymmetric) public-key algorithms

- particularly useful: java.math.BigInteger

2.8 Mobile Messaging

Mobile messaging can be referred as the exchange of messages over mobile networks. In

secureSMS program, it means the text message communication via mobile phone over

GSM/UMTS network. SecureSMS user is allowed to send and receive SMS by using

handset whenever and wherever the GSM/UMTS cellular telephone networks are

available.

2.8.1 Short Message Service (SMS)

Lately, SMS has replaced the traditional way of human communication. The change is caused

by the changing lifestyle, flexibility of network and advance technology in mobile device.

SMS is one of the communication protocols that used to exchange information in text

message between mobile handsets. SMS is transformed into data packet when travel in

GSM/UMTS network and this technology operates approximately in real time mode.

The previous use of SMS is for one way communication such as news, stocks report, and

weather forecast. Today, SMS is practiced as the easiest, fastest and cheapest daily

64
communication tool. The usage of SMS expands greatly by the rapid growth of mobile

application. SMS has switched from conventional human communication to system-device

communication. Some of the software applications are programmed to send alert to mobile

device and receive control command from particular handset in SMS. For example, vehicle

tracking service uses the SMS to notify car stolen cases and uses the mobile SMS to remotely

control home appliances.

Unfortunately, there is no guarantee on message delivery over all cellular networks. Those

mobile users have the risk of message delay or loss. The worst thing is the message may be

delivered to the wrong person. With the store-and-forward mechanism in Short Message

Service Center (SMSC), the message will be queued for later retransmission [40]. However,

this mechanism cannot solve the issue in exposing the message to adversary or unintended

person. SecureSMS offers a solution to deal with the above issue by encrypting the message

with trusted encryption algorithm.

Those encrypted messages are in unreadable form. Therefore, the secret is preserved in case

of faulty transmission or illegal attack by unauthorized person.

2.8.2 Message Size

The message size of SMS varies for different languages use. Generally, it is 160

characters for Alphabetic characters (A-Z). There are two standard for Alphabetic

character which is 7-bit American Standards Committee on Information Interchange

(ASCII) code and 8-bit Extended Binary Coded Decimal Interchange Code (EBCDIC).

ASCII code is the most popular character codes used which consists of alphabetic

characters, operators, punctuation symbols, control characters and number [41].

65
The Signaling System 7 (SS7) protocol set the packet size to 140 octets. For translation, it

is equivalent to 160 ASCII 7-bit characters, 140 EBCDIC 8-bit characters, and 70

Chinese 16-bit characters [40]. The Chinese character must be encoded by using the 16-

bit UCS-2 (2-byte Universal Character Set) character encoding.

The maximum characters can be used in SMS is less than the declared amount. This is

because the user data header (UDH) takes out some of the portion of message. UDH is

needed for message segmentation. Sometimes, user needs to send a long message that

exceeds the total length of SMS. In this situation, the SMS splits into two data packets.

The UDH is responsible to store the information about these data packets.

When the multiple data packets reach the recipient phone, UDH able to reassemble them

to the original message based on the stored information.

2.9 Conclusion

The GSM security model is broken on many levels and is thus vulnerable to numerous

attacks targeted at different parts of an operator's network.

Assuming that the security algorithms were not broken, the GSM architecture would still

be vulnerable to attacks targeting the operator's backbone network or HLR and to various

social engineering scenarios in which the attacker bribes an employee of the operator, etc.

Further more, the secretly designed security algorithms incorporated into the GSM system

have been proven faulty. The A5 algorithm used for encrypting the over-the-air

transmission channel is vulnerable against known-plain-text and divide-and-conquer

attacks and the intentionally reduced key space is small enough to make a brute-force

attack feasible as well. The COMP128 algorithm used in most GSM networks as the

66
A3/A8 algorithm has been proved faulty so that the secret key Ki can be reverse

engineered over-the-air through a chosen challenge attack in approximately ten hours.

All this means that if somebody wants to intercept a GSM call, he can do so. It cannot be

assumed that the GSM security model provides any kind of security against a dedicated

attacker. The required resources depend on the attack chosen. Thus, one should not rely

solely on the GSM security model when transferring confidential data over the GSM

network.

In addition to the possibility of call interception, the faulty COMP128 algorithm makes

SIM cloning a threat as well, thus making it possible for an attacker to place calls at

someone else's expense. However, the reality is that although the GSM standard was

supposed to correct the problems of phone fraud and call interception found in the analog

mobile phone systems by using strong crypto for MS authentication and over-the-air

traffic encryption, these promises were not kept. The current GSM standard and

implementation enables both subscriber identity cloning and call interception. Although

the implementation of cloning or call interception is a little bit more difficult, due to the

digital technology that is used, compared to the analog counterparts, the threat is still very

real, especially in cases where the transmitted data is valuable. Basically, we are where

we used to be with the analog cell phones when it comes to security although the GSM

Consortium tries to deny it.

67
For GSM data to be seen to be secure and confidential, more work is needed to provide

additional security. Extra measures must therefore be taken to cryptographically secure

GSM data especially Short Message Service (SMS) programmatically.

68
 CHAPTER THREE
METHODOLOGY AND SYSTEM ANALYSIS

3.0 Methodology

From the research and analysis carried out in Chapter 2 of the study on the existing GSM

security algorithms meant to provide security services for user’s data, it is very clear that

the possibility of an attacker breaking any of them is very easy. Most of the security

algorithms meant to protect user data (SMS, Voice, Service etc.) during communication

have been broken, so for one to use GSM communication that is required in a sensitive

and mission critical environment where confidentiality of data is paramount, there must

be extra need to further protect such data.

In the research work, software based approach will be used to further strengthen the

security algorithms embedded in GSM Technologies.

This project will attempt to reduce the security lapses noticed in the existing security

algorithms of GSM platforms by increasing the security of data (SMS only) during GSM

communication session. A software program, a JAVA MIDlet for Micro 2 platform Micro

Edition (J2ME) will be developed using Bouncy Castle JAVA Cryptographic Application

Programming Interface inside Java Wireless Toolkit for J2ME IDE to further provide

protection of sensitive Short Message Service (SMS) data during communication. Bouncy

Castle API contains quite a lot of GSM cryptographic algorithms that can be combined in

a MIDlet application to further secure a GSM data such as SMS.

69
For this project, a secure channel is established between two MIDP devices (two

compatible Nokia phones or/and a PC running a JAVA Emulator inbuilt into the

NETBEANS 6.8 IDE used to develop the security solution.

To ensure that the SMS remains confidential, a password-based cipher is used to encrypt

the message’s content.

For SMS to be secure during communication there must be confidentiality and integrity

of the message. Authentication is achieved by simply looking at the message itself, which

includes the sender’s phone number. Encrypting the message provides confidentiality,

and a message digest can be used to ensure integrity.

Using a key K1, sender S encrypts message M1 and sends M. The recipient R receives

message and using the key decrypts it into M2. Provided they share the same password

(private key), so that K1=K2, and no errors happen during transmission, R will recover

the message so that M1=M2. The process of encryption and decryption of SMS data in

the project is depicted by the figure below.

M
M1 M2
100100101

K1 K2

S R

Fig 3.1 : End-to-end encryption and decryption of SMS data

70
3.0.0 Possible Causes of error during transmission of SMS from one end to
another

According to GSMFavourites.com [42], possible causes of error that can be returned to an

SMS Centre (SC) from a Mobile Station (MS) during transmission include:

1. Unknown subscriber - Message is rejected because there is no directory number

for the mobile subscriber (GSM 09.02).

2. Teleservice not provisioned - Message is rejected because the recipient MS has

no SMS subscription (GSM 09.02).

3. Call barred - Message is rejected due to barring of the MS (see GSM 09.02,

description of the barring supplementary service, GSM 02.04 and 03.11, and

description of Operator Determined Barring, GSM 02.41 and 03.15).

4. Facility not supported - The message is rejected due to no provision of the SMS

in the VPLMN (GSM 09.02).

5. Absent subscriber - The message is rejected because there was no paging

response (GSM 04.08), the IMSI record is marked detached (GSM 09.02), or the

MS is subject to roaming restrictions (GSM 09.02).

6. MS busy for MT SMS: The message is rejected because of congestion

encountered at the visited MSC.

7. SMS lower layers capabilities not provisioned - Message rejected due to MS

not being able to support the SMS. The short message transfer attempt is rejected

either due to information contained in the class-mark, or the MSC not being able

to establish connection at SAPI (GSM 04.08 and 09.02).

8. Error in MS: message rejected due to an error occurring within the MS at

reception of a short message (lack of memory or protocol error).

71
9. Illegal subscriber - Message rejected because of failed authentication.

10. Illegal equipment - Message rejected because the MS was black-listed.

11. System failure - Message rejected due to network or protocol failure.

12. Memory capacity exceeded - Message rejected because the MS doesn't have

enough memory.

However, if the recovered (decrypted) SMS message, M, is tampered with, then the

message digest length of the recovered (decrypted) message will not be the same with the

original message digest used to send the message. In that situation an error message will

be generated by the program and the receiver, R, denied the access to see the message, M.

Please see the complete program flowchart in section 4.2 (Fig. 4.2) of this thesis for the

details in the calculation of the message digest length of the SMS message.

3.0.1 SMS Message Data Format

The SMS is simply a byte array containing a header, the ciphered text, and an optional

message’s digest. The header includes two bytes of metadata and two bytes containing the

size of the cipher text. The first two bytes can be used to indicate properties of the

message. In this SMS security program in this thesis, the last bit of the header is used to

specify whether a digest was appended to the message.

72
 Metadata Size PAYLOAD Digest

Header Ciphered Text

(4 bytes)

Figure 3.2: SMS Message format

3.0.2 Why use JAVA?

I decided to adopt JAVA technologies for developing the proposed secure SMS data

application because of several advantages JAVA has to offer for developing applications

for memory-limited mobile devices such as mobile phones, Personal Digital Assistants

(PDAs), TV set-top boxes, and printers.

- JAVA is already deployed on billions of devices, supported by leading tool

vendors, and used worldwide.

- JAVA is a full-fledged Object Oriented Programming (OOP) language and

easily lends itself to easy software development using Top-down design

approach

- JAVA programming language has thousands of in-built security classes that

developers can easily take advantage to further secure mobile applications and

devices.

- JAVA has version that can be installed and deployed in memory limited

devices such as phones, PDAs and so on.

73
3.1 JAVA TECHNOLOGIES USED

3.1.1 J2ME

Java 2 Platform, Micro Edition (J2ME) provides a robust, flexible environment for

applications running on mobile and other embedded devices—mobile phones, personal

digital assistants (PDAs), TV set-top boxes, and printers. Java ME includes flexible user

interfaces, robust security, built-in network protocols, and support for networked and

offline applications that can be downloaded dynamically. Applications based on Java ME

are portable across many devices, yet leverage each device's native capabilities.

3.1.2 MIDP

The Mobile Information Device Profile (MIDP) is a key element of the Java 2 Platform,

Mobile Edition (J2ME). When combined with the Connected Limited Device

Configuration (CLDC), MIDP provides a standard Java runtime environment for today's

most popular mobile information devices, such as cell phones and mainstream personal

digital assistants (PDAs). The MIDP specification was defined through the Java

Community Process (JCP) by an expert group of more than 50 companies, including

leading device manufacturers, wireless carriers, and vendors of mobile software. It

defines a platform for dynamically and securely deploying optimized, graphical,

networked applications.

CLDC and MIDP provide the core application functionality required by mobile

applications, in the form of a standardized Java runtime environment and a rich set of

Java APIs. Developers using MIDP can write applications once, then deploy them quickly

to a wide variety of mobile information devices. MIDP has been widely adopted as the

platform of choice for mobile applications. It is deployed globally on millions of phones

74
and PDAs, and is supported by leading integrated development environments (IDEs).

Companies around the world have already taken advantage of MIDP to write a broad

range of consumer and enterprise mobile applications.

MIDP Specifications

MIDP 2.1(JSR 118)

The latest MIDP 2.1 specification does not bring new features and UI but instead it

focuses to reduce device fragmentation by specifying a consistent set of Java technologies

that must present in MIDP 2.1 capable phone. MIDP 2.1 also reinforced MIDP 2.0

specification by making LCDUI layout directive mandatory,

javax.microedition.io.SocketConnection and javax.microedition.io.HTTPConnection is no

longer optional and other requirements.

MIDP 2.0 (JSR 118) is a revised version of the MIDP 1.0 specification. New features

include an enhanced user interface, multimedia and game functionality, more extensive

connectivity, over-the-air provisioning (OTA), and end-to-end security. MIDP 2.0 is

backward-compatible with MIDP 1.0, and continues to target mobile information devices

like mobile phones and PDAs.

MIDP 1.0 (JSR 37) is the original specification, which provides core application

functionality required by mobile applications, including basic user interface and network

security.

75
3.1.3 JSR (Java Specification Requests)

The Java Community Process or JCP, established in 1998, is a formalized process that

allows interested parties to get involved in the definition of future versions and features of

the Java platform.

The JCP involves the use of Java Specification Requests (JSRs) — the formal

documents that describe proposed specifications and technologies for adding to the Java

platform. Formal public reviews of JSRs take place before a JSR becomes final and the

JCP Executive Committee votes on it. A final JSR provides a reference implementation

that is a free implementation of the technology in source code form and a Technology

Compatibility Kit to verify the API specification.

A JSR describes the JCP itself. As of 2009, JSR 215 describes the current version (2.7) of

the JCP.

3.1.4 MIDlet

A MIDlet is an application that uses the Mobile Information Device Profile (MIDP) of

the Connected Limited Device Configuration (CLDC) for the Java ME environment.

J2ME applications are called MIDlets.

Technically, a MIDlet is a set of classes designed to be run and controlled by the

application management software. The MIDlet must contain a class that extends the

javax.microedition.midlet.MIDlet class. The methods in this class allow the

application manager to create, start, pause, and destroy the application.

76
3.1.5 CLDC

The Connected Limited Device Configuration (CLDC) is a specification of a

framework for Java ME applications describing the basic set of libraries and virtual-

machine features that must be present in an implementation. The Connected Limited

Device Configuration (CLDC) defines the base set of application programming interfaces

and a virtual machine for resource-constrained devices like mobile phones, pagers, and

mainstream personal digital assistants. When coupled with a profile such as the Mobile

Information Device Profile (MIDP), it provides a solid Java platform for developing

applications to run on devices with limited memory, processing power, and graphical

capabilities.

The CLDC was developed under the Java Community Process as JSR 30 (CLDC 1.0) and

JSR 139 (CDC 1.1).

CLDC Specifications

CLDC 1.1 (JSR 139): CLDC 1.1 is a revised version of the CLDC 1.0 specification, and

includes new features such as floating point and weak reference support, in additional to

other enhancements. CLDC 1.1 is backward compatible with CLDC 1.0, and continues to

target small and resource-constrained devices with the objective of maintaining a tight

footprint.

CLDC 1.0 (JSR 30): CLDC Version 1.0 (JSR 30) is the first release of the CLDC

specification, which provides a compact virtual machine and basic libraries for resource-

constrained devices.

77
 J2EE J2SE profile profile MIDP

CDC CLDC

JAVA 2, MICRO EDITION JavaCard

Fig. 3.3 : The JAVA Environment

3.1.6 Bouncy Castle

Several third-party packages are currently available to supply the lack of encryption

libraries in the MIDP specification [MIDP1.0] [MIDP2.0] [MIDP 2.1]. One of the best

known is Bouncy Castle [BC]. The Legion of Bouncy Castle is a Web community that

produces an open-source Java implementation of cryptographic algorithms. Bouncy

Castle includes a clean-room implementation of the Java Cryptography Extension (JCE)

and, more significantly, a version targeted to the Java 2 Platform, Micro Edition

(J2ME™).

Bouncy Castle for J2ME has a lightweight API that includes a simple cryptographic

framework and a large number of algorithms such as block ciphers, public-key ciphers,

message digests, etc. It also contains generalized interfaces like BlockCipher, Digest, etc.,

making it easy to switch algorithms and find the right balance between strength and

speed.

78
The version used in this example is Release 1.18, which is approximately 530 KB in size.

The size of the library makes it indispensable to reduce the size of the MIDlet by means

of obfuscation. The obfuscator should remove all unused classes and methods. In

addition, Bouncy Castle uses a few Java classes not available in MIDP, such as

java.security.SecureRandom. The obfuscator must rename those classes to avoid conflicts

with the security policy of the MIDP device.

3.1.7 Obfuscation of Bouncy Castle JAR file using Proguard

The size of the Bouncy Castle JAR file for J2ME is about 530 kilobytes. The size is due

to the large number of ciphers, digests, and utility classes implemented in Bouncy Castle.

Since one would normally use only one or two of those algorithms, obfuscation is a very

effective means to reduce the size of the MIDlet’s JAR file.

One commonly used obfuscator is Proguard, which is very effective in reducing the size

of the JAR file by removing unnecessary classes and methods. Proguard has been

incorporated into Sun’s Wireless Toolkit, but the default obfuscation parameters are not

adequate for processing the Bouncy Castle API.

The obfuscation of Bouncy Castle presents some special challenges. In particular, some

of the algorithms require Java classes that are not available in CLDC. Examples of this

are the java.security.SecureRandom and java.math.BigInteger classes. To solve this

problem, Bouncy Castle’s J2ME version ships with implementation of those classes for

J2ME. This creates some difficulties because MIDP implementation should reject classes

that are under the java and javax packages for security reasons.

79
Obfuscation with Proguard doesn’t necessarily solve this problem, since package names

are preserved. For example, the java.security.SecureRandom class will become

java.security.a and the device will reject it anyway. Proguard offers a solution — the –

defaultpackage option. This option will move all the classes to a specific package or

remove the package name altogether. It should be noted that by using the –defaultpackage

option the MIDlet main class package name will change. The JAD and MANIFEST files

must reflect this to work properly.

If it becomes necessary to unpack the already obfuscated JAR file (for instance, for

preverification), it is also wise to use the –dontusemixedcaseclassnames option.

Otherwise, Proguard may rename the classes using letters in upper- and lowercases like a

and A, when it runs out of names. This may happen when obfuscating Bouncy Castle

because of the large number of classes involved. Mixed-case classes are legal but there

can be problems when unpacking the file in operating systems that don’t distinguish files

with different cases.

Below is a possible Proguard configuration file that will correctly obfuscate Bouncy

Castle:

-libraryjars midpapi.zip

-injars EncryptedSMS.jar

-outjar EncryptedSMS_o.jar

-keep -keep public class * extends javax.microedition.midlet.MIDlet

-defaultpackage

-dontusemixedcaseclassnames

In the secureSMS program developed in this project, Bouncy Castle obfuscation was set

to the highest mark, i.e. 100% and unused additional classes was removed during

compilation and building of the source codes.

80
3.1.8 Integrated Development Environment (IDE) for the Project

The development environment (IDE) for the J2ME MIDlet secure SMS program will be

NetBeans IDE. The NetBeans 6.8 IDE is an open-source integrated development

environment. NetBeans IDE supports development of all Java application types (Java SE

including JavaFX, (Java ME, web, EJB and mobile applications) out of the box. Among

other features are an Ant-based project system, Maven support, refactorings, version

control (supporting CVS, Subversion, Mercurial and Clearcase).

3.1.9 Application Deployment as JAR and JAD files

MIDlets are packaged together in suites inside a .jar (Java ARchive) file with a Manifest file

indicating which classes implement which MIDlet. As well as the Java classes, the .jar

file can contain other resources such as images or sound files. A .jad file contains the

location of the .jar as well as the list of MIDlets in the suite and other attributes.

The .jad (Java Application Descriptor) file describing a MIDlet suite is used to deploy

the applications in one of two ways:

-
Over the air (OTA) deployment involves uploading the .jad and .jar files to a

Web server which is accessible by the device over HTTP. The user downloads

the .jad file and installs the MIDlets onto a MIDP device (compatible mobile

phone).

- Local deployment requires the MIDlet files to be transferred to the MIDP

device (a compatible mobile phone) over a non-network connection, such as

81
 Bluetooth, Cable or IrDa (Infra-rays) and may involve device-specific

software.

The secure SMS solution to be developed in this Master Thesis will employ one or more

of these deployment techniques to test-run and implement the project.

3.2 Structured Analysis & Design Method

For the design of the two programs in JAVA for this project:

- For the secure MIDlet J2ME application that will handle the

encryption/decryption of SMS data in the mobile phone during

communication and

- the simulation program that will be used to simulate existing GSM algorithms,

consideration will be given to a structured design approach.

Two types of structured design exist:

- Top-Down and

- Bottom-Up approach of design.

3.2.1 TOP- Down Structured Design Approach

Top-Down design approach makes very easy the breaking of the program design into

smaller simpler chunks. Java uses Object-Oriented Programming (OOP) and hence use

classes for most of its implementation; Top-down design approach suites OOP paradigm

of JAVA programming language. The two programs in this project will be developed

using Top-Down design Approach.

82
The illustration in fig. 3.4 depicts clearly the secure SMS MIDlet application to be

developed later in the project using Top-Down design Approach:

MessageCodec

Uses Uses

SendScreen ReceiveScreen
Creates
Creates
ReportScreen
EncryptedSMS
MIDlet
ErrorScreen

Fig. 3.4: EncryptedSMS MIDlet class illustration

From the figure above, the secure SMS MIDlet program is composed of the main

EncryptedSMS MIDlet class and two screens (SendScreen and ReceiveScreen classes.

MessageCodec class or module is a utility class containing methods that create the

BlockCipher and Digest objects and methods to pack and unpack messages. ReportScreen

is used to display the result of the encryption and decryption process and can also display

an HEX view of the binary message.

83
User Interface

The secure SMS MIDlet program has screens for sending and receiving encrypted

messages. On the sending side, the user interface provides a form containing several

fields used to compose the message. The handling of the Send command will verify that

all fields have been filled and that the password is at least eight characters long (eight

characters are necessary for DES; other algorithms may vary). The secure SMS MIDlet

program then encrypts and sends the message. After delivery it will display a report of the

process including a measure of the duration of the process.

Fig 3.5 : Sending Message Sequence

On the receiving end, the user interface displays an announcement and a field to enter the

message’s password. As previously noted, this illustration assumes that users will

privately exchange passwords. The MIDlet also has a screen to report the received

message’s content.

84
Fig 3.6: Receiving Message Sequence

In case of error, for example, when entering the wrong password, a report will show the

exception’s message on the ErrorScreen.

Fig 3.7: Incorrect Password

85
3.2.2 Bottom-Up Structured Design Approach

Bottom-Up design is very good for starting up complex software project from its simplest

form up to the most sophisticated form (i.e. Supra System). The programs for this project

will make use of classes which is ideally suited to Top-down structured design approach,

therefore for the purpose of this project; Bottom-Up design approach will not be used.

The next chapter, Chapter Four will present the Design of the two programs (the secure

SMS MIDlet and GSM Simulation program, their flowcharts as well as program codes.

86
 CHAPTER FOUR
SYSTEM DESIGN AND DEVELOPMENT

4.1 Introduction

SecureSMS is Java application which is built in an object-oriented platform. It is made up of

6 classes and modules. Because of this Top-down design approach has been adopted for the

design and development of this project.

The project was designed and developed using JAVA programming language which is widely

adopted for Object oriented projects. Moreover, JAVA is the defacto programming language

for millions of portable and embedded devices in the market place.

NetBeans 6.8 Integrated Development Environment (IDE) was used to develop the project in

JAVA 2 Platform for Micro Edition (J2ME). The security program is tested using the inbuilt

JAVA™ SDK 3.0 Emulator and subsequently deployed to actual compatible mobile phones.

4.2 System Design Specification

The secureSMS program is a security GSM data protection and confidentiality program in

Java programming language (Java 2 Platform for Micro Edition) that will protect user’s

SMS data engaged in an end-to-end communication.

The JAVA program secureSMS is made up 6 different modules or classes –

1. EncryptedSMS MIDlet class

2. SendScreen class

87
3. ReceiveScreen class

4. MessageCodec class

5. ReportScreen class

6. ErrorScreen class

EncryptedSMS MIDlet

This is the main class and controls the state changes between two screens. It also owns

the message connection and registers itself as a message listener waiting for incoming

messages. When sending a message, the SendScreen method will launch a new thread

that will take care of sending the message. The SMS port used for the connection is read

from the JAD file under the port property.

88
 The program flowchart relating the Class relationship between the main class
EncryptedSMS MIDlet and other five classes is depicted below

ReportScreen ErrorScreen

ReceiveScreen EncryptedSMS MIDlet SendScreen

Main class or module

MessageCodec

Fig 4.1: Program flowchart or Class Diagram relating the project classes or modules

89
 START

Initialize
Message Connection Screens,
Message Address Port,
Logo Image

Build SMS Message Connection String,

Initiate SMS Message Connection

Add Message Listener

Obtain MIDlet Vendor Application

Property

Fig 4.2: Program flowchart relating the methods in the entire program

90
 1

INPUT FORM DATA:

Recipient phone number, Message,
Password, Add Digest

NOT
OKAY Generate Error Message
Crosscheck if INPUT
FORM DATA are or Exception
OKAY?

OKAY

Create a cipher engine e.g. Blowfish,

DES, AES, Rinjadael etc. to encrypt the
plaintext message

Create a Digest Engine to ensure

integrity e.g. MD5 (), SHA1 etc.

Create a new Binary Message

Perform encryption on the plaintext message

Compute total time of encryption using the

cipher engine

Compute the overall message size and length

of ciphered text to be sent to recipient

91
 2

Send encrypted message i.e.

ciphered text to recipient
phone number

Recipient inputs secret

password to decode
encrypted password

NOT
If Password is Correct Generate Error Message
Correct? or Exception

Correct

Compute the overall message size and

length of ciphered text received from
sender

FALSE
If digest size/length of Generate Error Message
message sent and message or Exception
received are the same?

TRUE

Decode encrypted Message

Decrypt message content

DISPLAY OR OUTPUT
decrypted message to Recipient

End

92
The main class, the EncryptedSMS class contains the following components that make

the program to function effectively:

- MessageConnection: to initialize and open up the port to allow message

connection and to close connection that is not needed again.

- MessageListener: to listen to the port to determine whether new message has

arrived or not

- ErrorConnection : to monitor errors or exception and invoke ErrorScreen

class to make necessary error report

- GetAppProperty: to obtain the Application properties like Vendor name,

Application name etc.

- BinaryMessage : to create and send a new message upon removal of old

message

- ReceiveScreen handler: to prepare a message handler to receive new

incoming messages

- messageContent: to prepare a new message payload and add message digest

and cipher and connect to ReportScreen

93
SendScreen Class or Module

This class is responsible for the presentation of form to enable the user enter the required

parameters:

- Phone number

- Message body

- Password/private key

- Add digest to message

This class is invoked by the main class EncryptedSMS MIDlet to present the user (the

Sender), the interface to enter the required parameters and afterwards passes control back

to the Main Class.

The following flowchart in fig 4.3 depicts the Interaction between the main class and the

SendScreen class:

94
 EncryptedSMS MIDlet class

(Main class)
Invokes the SendScreen Class

SendScreen Class
Calls the method to request User’s
Input Data: Phone no, message,
password, message digest

Enter phone no,

message, password,
add digest

YES
NO Checks if phone no,
password, message,
add digest =okay

Fig 4.3: Program flowchart depicting relationship between the main class and SendScreen class

ReceiveScreen Class or Module

This class is responsible for the presentation of form to enable the user enter the required

parameters to decode and read the sent message. The required parameter is

95
 - Password/private key used to encrypt and send the message

This class is invoked by the main class EncryptedSMS MIDlet to present the user

interface to enter the required parameter and afterwards passes control back to the Main

Class. The following flowchart depicts the Interaction between the main class and the

ReceiveScreen class.

EncryptedSMS MIDlet class

Main class

ReceiveScreen Class

User enter
password/private key

YES
NO Checks if password
entered = the
password one used to
encrypt the message

Fig 4.4 : Program flowchart depicting relationship between the main class and ReceiveScreen
class

96
MessageCodec Class or Module

This class is responsible for the adding of Bouncy Castle cryptographic classes such as

ciphers, digests and it is also responsible for the encryption and decryption of messages

when invoked by the main class, EncryptedSMS MIDlet class.

In summary, this class handles the following operations:

- Add message digest

- Add cipher or encryption engines

- Encrypt message

- Decrypt message

- Passes control back to main class

This class is invoked by the main class EncryptedSMS MIDlet to handles message

encryption and decryption and then closes up.

The following flowchart depicts the Interaction between the main class and the

MessageCodec class.

97
 EncryptedSMS MIDlet class

Main class

MessageCodec Class

Add digest
Add cryptographic engines
Encrypt message
Decrypt message

Fig 4.5: Program flowchart depicting relationship between the main class and MessageCodec

class

ReportScreen Class or Module

This class is responsible for showing or display of the output status of the secureSMS

program success or failure. The class presents a report screen or interface to the user upon

a successful decryption of encryption and decryption of the message. It equally displays

the time taken to handle encryption and decryption processes by the cryptographic

engines or algorithms.

98
In summary, this class handles the following operations:

- Display of successful encryption process

- Display of successful decryption process

This class is invoked by the main class EncryptedSMS MIDlet to handles output report to

the User and then closes up by the User.

The following flowchart depicts the Interaction between the main class and the

ReportScreen class

EncryptedSMS MIDlet class

Main class

ReportScreen Class

Displays successful encryption

process

Displays successful decryption

process

Fig 4.6 : Program flowchart depicting relationship between the main class and ReportScreen
class

99
ErrorScreen Class or Module

This class is responsible for the showing or display of error or exceptions encountered

during the execution of the program. For instance, incorrect parameters like phone

number, password etc. are alerted to the user using this class.

This class is invoked by the main class EncryptedSMS MIDlet to handles display of error

messages to the User.

The following flowchart in fig 4.7 depicts the Interaction between the main class and the

ReportScreen class.

EncryptedSMS MIDlet class

Main class

ErrorScreen Class

Displays error messages to the user

Fig 4.7: Program flowchart depicting relationship between the main class and ErrorScreen
class

100
4.3.1 The Program Source Codes

The program source codes for the six (6) classes or modules used in this project-

EncryptedSMS MIDlet, SendScreen, ReceiveScreen, MessageCodec, ReportScreen,

ErrorScreen are documented in Appendix A.

4.3.2 The Program Input and Output Interface

The User Interface (Input and Output Interface Screens)

The secure SMS MIDlet program has screens for sending and receiving encrypted

messages. On the sending side, the user interface provides a form containing several

fields used to compose the message. The handling of the Send command will verify that

all fields have been filled and that the password is at least eight characters long (eight

characters are necessary for DES; other algorithms may vary). The secure SMS MIDlet

program then encrypts and sends the message. After delivery it will display a report of the

process including a measure of the duration of the process.

The Input Interface Screens (Send Screen and Report Screen)

Fig 4.8 : Sending Message Sequence

101
The Output Interface Screens (Receive Screen and Report Screen)

On the receiving end, the user interface displays an announcement and a field to enter the

message’s password. As previously noted, this illustration assumes that users will

privately exchange passwords. The MIDlet also has a screen to report the received

message’s content.

Fig 4.9 : Receiving Message Sequence

The Output Screen (The Error Screen)

In case of error, for example, when entering the wrong password, a report will show the

exception’s message on the ErrorScreen.

102
Fig 4.10 : Incorrect Password

103
Fig. 4.11 : secureSMS MIDlet program source codes (classes) in NETBEANS 6.8 IDE

104
Fig. 4.12: SecureSMS MIDlet program project successfully built in NETBEANS 6.8 IDE

105
 The Project Block Diagram

Plaintext, P Plaintext
Encryption Decryption
Method Method

Encryption Cipher Text Decryption

Key, K Key, K

Sender, S Symmetric Key Receiver, R

Generator

Secure Channels with

Confidentiality and Authentication

Encryption method=Block cipher engine (e.g. Blowfish) and message digest (MD5 ())

Fig. 4.13: The SMS security Project Block Diagram

106
 CHAPTER FIVE: SYSTEM IMPLEMENTATION

This chapter covers the system implementation: the deployment and test-running of the

completed secureSMS JAVA MIDlet program developed in Chapter Four of this thesis.

The secureSMS JAVA MIDlet was developed (built, compiled, preverified, run and

tested) in NETBEANS 6.8 IDE. The program is equally deployed and tested in actual

MIDP 2.0 compatible devices using Nokia 2700 Classic, Nokia 2720a fold and Nokia

3110 Classic mobile phones. Equally any other compatible MIDP 2.0 mobile phone could

be used for actual implementation of the project.

5.1 Software Implementation

For the system i.e. the secure SMS JAVA MIDlet program meant to add additional

security to SMS data engaged in an end-to-end communication session, the compiled,

pre-verified and obfuscated JAVA file secureSMS.JAR and the accompanying .JAD files

created in Chapter Four will first of all be deployed in any of the following platforms

using Nokia PC Suite for the respective MIDP 2.1 compatible mobile phones:

- Over the Air (OTA)

- Bluetooth

- IrDA

- USB Cable

The secureSMS MIDlet program developed in this Research employed both Over the Air

(OTA) and USB Cable connecting a Nokia 2700 phone to a PC running the program

on NETBEANS 6.8 IDE . The MIDlet JAR and JAD files were then transferred to the

two MIDP 2.0 compatible Nokia 2700 phones.

107
5.1.2 Over the Air (OTA)

This entails uploading the .JAR and .JAD files from a computer to a web server on the

Internet and then using WAP on the compatible mobile phones to access the URL of the

web server and then download and install the files to the mobile phone over the air

interface. For instance, the JAR and JAD files could be uploaded using a CPANEL File

Manager of a web server hosted on the Internet

(http://SecureSMS.naijamatrix.com/securesms.htm) and accessed via the mobile phones

over the air (OTA) and downloaded and installed onto the targeted mobile phones.

5.1.3 Bluetooth

The entails uploading the .JAR and .JAD files from a computer having a Bluetooth

wireless adapter to a compatible mobile phone with a Bluetooth device as well. In fact,

virtually all mobile phones now come bundled with inbuilt Bluetooth adapter. The

computer is paired with the mobile phone on Bluetooth network and transfer of files take

place effortlessly using Nokia PC Suite.

5.1.4 IrDA

IrDA entails using the Infra-rays shortwave wireless network on the computer to transfer

the .JAD and .JAR files to a compatible mobile phone having an IrDA network.

5.1.5 USB Cable

This method is one of the easiest; it entails using installed PC Suite (for instance Nokia

PC Suite software) in the computer to easily transfer the .JAD and .JAR files to a

compatible MIDP 2.0 mobile phone connected by an USB cable using Nokia PC Suite.

108
5.2 System Testing

5.2.1 The Test plan

The test plan is to use JAVA Emulator software to test-run the secure SMS JAVA MIDlet

program .JAR and .JAD files on a virtual machine first and then test the same on the real

JAVA machine (i.e. compatible MIDP 2.0 mobile devices/phones) and compare the

results. The results should be the same.

5.2.2 Testing on the JAVA PLATFORM Micro Edition SDK 3.0 EMULATOR

This built version of the secureSMS JAVA MIDlet program was tested using inbuilt

JAVA™ Platform Micro Edition SDK 3.0 Emulator integrated with the NETBEANS 6.8

IDE on the development computer. The JAVA emulator software allows testing to be

carried out on a virtual machine before final testing is carried out on the real machine i.e.

the compatible MIDP 2.0 devices such as Nokia compatible mobile phones. This is also

known as simulation.

The result of the testing carried out on the NETBEANS 6.8 IDE with the inbuilt JAVA™

Platform Micro Edition SDK 3.0 Emulator is shown in Fig 5.1.

109
Fig. 5.1 : secureSMS Project in NETBEANS 6.8 IDE Environment

110
Fig 5.2: secureSMS MIDlet program being executed by the Default Sun Wireless
JAVA™ Platform Micro Edition SDK 3.0 Emulator integrated in NETBEANS 6.8 IDE

111
Fig 5.3 Fig 5.4

Fig 5.3: The JAVA Emulator prompting the user to enter the phone number, the
secret/confidential message and add a security digest

Fig. 5.4: secureSMS MIDlet program being executed by the Default Sun Wireless JAVA
Emulator. Here user enters phone number 123456789, the confidential message and
added a digest to encrypt the confidential message

112
Fig. 5.5 Fig. 5.6

Fig. 5.5 : The JAVA Emulator asking the recipient to enter the password/private key to
decode and read the encrypted message

Fig. 5.6 : The password entered to decode and read the secret message.

113
Fig.5.7 : secureSMS MIDlet program being executed by the Default JAVA™ Platform
Micro Edition SDK 3.0 Emulator
Operation Report after successfully sending a confidential message to recipient phone
number 123456789

114
5.2.3 Final testing (Testing on the real compatible MIDP 2.0 phones)

The final testing are carried out on the real JAVA machines i.e. on compatible MIDP 2.0

mobile phones like Nokia 2700, Nokia 311 0C, Nokia 2720 engaged on an end-to-end

SMS communication session.

The result screenshots are shown below:

Figures 5.8 : Screenshots of SecureSMS being used to send a secure SMS to another phone
(i.e. Receiver phone , number +2347065239183) from sender’s phone number 08062926794.

115
Figure 5.9 : Screenshots of SecureSMS being used to receive and decode a secure SMS
message sent from another phone (Sender’s phone, number 08062926794) to Receiver (i.e.
phone number 07065239183)

116
5.3 Performance Evaluation

The secure SMS JAVA MIDlet program worked to expectations going from the results

obtained from the JAVA PLATFORM Micro Edition SDK 3.0 EMULATOR and the

real MIDP 2.0 compatible devices such as Nokia 2700 and Nokia 2720 MIDP 2.0 mobile

phones. The same result should be expected in any other device-dependent SDK JAVA

Emulators or compatible MIDP 2.0 mobile phones such as Nokia 6300 Navigator, Nokia

5320 XpressMusic, N76, N77, N78, N79, E34, E35 etc.

However, the speed of the execution of the encryption and decryption processes is

directly proportional to the cryptographic digest engines being used. Here, in this project,

Blowfish Algorithm cipher engine was faster than other common engines. See Appendix

C for the Table showing the speed of encryption/decryption of cryptographic cipher

engines and digest engines used in this project as contained in Bouncy Castle

cryptographic API.

117
 CHAPTER SIX: DISCUSSIONS, SUMMARY & CONCLUSION

6.1 Discussions

SecureSMS JAVA MIDlet security program worked to expectations going from the

results obtained in section 5.2.2 of this thesis report. The program, according to

expectations worked in a Sun JAVA Standard Emulator as well as in the real MIDP 2.0

compatible mobile devices. The secureSMS security program made encryption of SMS

data engaged in an SMS end-to-end communication session possible at the Sender’s end

and equally permitted the SMS data to be decrypted and viewed by the Receiver at the

other end provided the Receiver entered the exact private key(secret password) used by

the Sender to encrypt and send the SMS data. It therefore means that without the

possession of the private key (secret password), anyone that intercepts the SMS data

cannot decrypt and read the content of the SMS message. So, the SMS data is protected

from man-in-middle Over the Air (OTA) Interception and eavesdropping.

6.2 Project Summary

Thorough research work was carried out on the GSM Security model of GSM Operators

and it was very clear that most, if not all, of the GSM Security algorithms have been

cracked and compromised. Therefore, there is cogent need to develop other ways of

protecting user’s GSM data, especially in situations where confidentiality and privacy are

paramount.

This research project tried in that direction by developing a security solution in JAVA

programming to protect users’ confidential and private SMS data.

118
Equally, the objectives set out at the beginning of this research work have been achieved

and they are outlined in section 6.3 of this research report.

6.3 Summary of Achievement

This research carried out in the Master thesis achieved the following set objectives:

1. Research and Analysis of the GSM network

2. Research and Analysis of the GSM Security model and architecture

3. Research of the existing GSM security algorithms : A3, A5, A8 and

COMP128

4. Analysis of the strengths and weaknesses of these algorithms.

5. Design and implementation of a security software solution in JAVA

programming language to protect and secure user’s privacy and sensitive GSM

data engaged in an end-to-end SMS communication session.

The following findings were made during the research work:

1. That the GSM security algorithms implemented by most GSM operators

worldwide, Nigeria inclusive, are done in secrecy and most of them have

leaked out and subsequently cracked or compromised.

2. That a lot attacks have been carried out by attackers to determine the strengths

of these algorithms and it was discovered that these algorithms are weak and

therefore cannot protect user’s data especially in sensitive, safety and mission-

critical environments.

119
 3. That there is need for additional work to be done to further secure user’s data

during communication session

The secureSMS JAVA MIDlet program developed in the thesis in Chapters 3 and 4 have

been tested and solved this problem especially in the protection of user’s SMS data.

6.4 Problems encountered and solutions

During the course of this Masters Research work, a lot of problems were encountered:

1. I had a lot of difficulty implementing a secure SMS data using one of JAVA

inbuilt JAVA Cryptography Extension (JCE) classes SATSA API. SATSA

API is very difficult to program; luckily I had an easy way through an

alternative JCE classes, Bouncy Castle API, which was used to encrypt and

decrypt the SMS data.

2. I also encountered some problems during obfuscation of the JAR file after

compilation and pre-verification using Proguard. I corrected the problem by

modifying the proguard code and adjusting the proguard obfuscation level to

the highest.

3. I encountered a lot of problems using different versions of the Development

tools: NETBEANS. I eventually settled with NETBEANS 6.8 which delivered

the anticipated results.

Another problem encountered was to secure Voice data over the air. This is very

difficult to accomplish. In fact, in many JAVA forums on the internet, it was claimed

that it is not possible to encrypt and decrypt Voice over the air except one does that

for Voice data using VOIP (Voice Over Internet Protocol) but I still believe that it can

120
 be done; afterall an Israeli company has done that already for military application and

they are selling the software on the website www.gold-lock.com for around $500. I

eventually settled on programming a security solution for SMS only.

6.5 Recommendations

- I recommend that further research work be done to encrypt Voice data over the air

and not necessarily the clamoured VOIP approach, because most voice data

involve over the air approach.

- I also recommend that the secureSMS MIDlet solution be improved upon and

deployed and used in very important sectors in Nigeria economy where the

security of user data is of utmost importance such as Nigerian Police, Nigerian

Army, Nigerian Navy, Nigerian Air force, State Security Services (SSS), Nigeria

Defence Academy and other security outfits in the country. Equally, financial

sector like Banks, finance institutions, Educational Institutions are not left out.

The project can be improved upon to cater for the security needs of e-commerce

applications of sectors like finance and import/export. Citizens desiring privacy

and confidentiality in their data communication should also use this secureSMS

Solution.

6.6 Suggestions for further improvements

Further research work can be done to improve on the secure SMS MIDlet program.

- This security solution does not have a storage facility (Record Management

System, RMS) because of time-constraint for the development of the

project. Effort can be made in this direction by future researchers in Nigeria

121
 to develop this area so as to allow users of the software solution store SMS

sent and received using this security solution.

- Effort can still be made to find ways to combine more than one cryptographic

algorithms to make cracking the security algorithms a hard nut.

- Further research work can be geared in direction of GSM voice security.

6.7 Conclusion

The importance of the security of GSM data: SMS, Voice, Service etc. cannot be over-

emphasized in this IT age where GSM communication is used by over 85 million people

only in Nigeria alone. GSM has become the basic means of communication today;

millions of people rely on GSM backbone to conduct businesses, maintain relationships

and shape their life in many ways. The confidentiality and privacy of their dealings and

communication must be guaranteed and not compromised. Sensitive and mission-critical

GSM data must be protected from the hands of criminal-minded individuals as this thesis

tried to achieve.

More work need to be done to protect the confidentiality and privacy of GSM data of

subscribers, especially subscribers in highly critical and sensitive environments.

Therefore, all stake holders must put hands on deck to ensure that these objectives are

realised.

122
 REFERENCES

[1] Christian Gehrmann and Per Stahl. “Mobile Platform Security,” in Erricsson
Review No.2, pg.1, 2006.

[2] Thomas Strang. WS2007/2008. Lecture, Topic: “Programming Mobile Devices,

Security Aspects.” University of Innsbruck. Pg 15,18,19,20.

[3] Purushothan Kothapalli. “Secure Storage of Encryption Keys.” Masters Thesis,

University of Linkoping, Sweden, May 2007.

[4] Ali Abbas, Abdulmotaleb El Saddik and Ali MiriGESTS. “State of the Art
Security Taxonomy of Internet Security: Threats and Countermeasures.”
International Trans. Computer Science and Engr. Vol.19, 2005.

[5] Dieter Gollman. Computer Security. New York, NY, USA: John Willey and Sons,
August 1999.

[6] Alex Noordergraaf. “How Hackers Do It: Tricks, Tools, and Techniques.”
[Online].Available:http://pdf.textfiles.com/security/816-4816-10.pdf , 2002
[March 28, 2010].

[7] Eric Goetz, Garett Jones and Brent Kesler. “News Brief about Port Scanners.”
[Online].Available: http://csdl2.computer.org/comp/mags/sp/2005/01/j1009.pdf
[April 3, 2010].

[8] Wolfgang Rankl and Wolfgang Effing. Smart Card Handbook. New York, NY,
USA: John Willey and Sons, 2000.

[9] Christopher Aryton (2003). “Security+Exam Guide.”

[10] Eugene Lockett Sung Kyu Park, Guangcheng Jiang, Mike Riddle. “Security
Aspects of Smart Card.” Term Project CS574, Fall 2003, San Diego State
University, USA, Nov. 3, 2003.

[11] Tech-faq. “Dictionary Attack.” [Online]. Available:

http://www.tech-faq.com/dictionary-attack.html [March 28, 2010].

[12] Margus Frendenthal, Sven Heiberg and Jan Willemson. “Personal Security
Environment on Palm PDA,” in Proc. 16th Annual Computer Security Application
Conference (ACSA’00), 2000.

[13] Wikipedia. “Dictionary Attack.” [Online] Available:

http://en.wikipedia.org/wiki/Dictionary-attack [March 27, 2010].

123
[14] Udo W. Pooch, Gregory B. White, A. Eric and Fisch. Computer System and
Network Security. San Antonio, Texas, USA: Seenchgix, 1996.
[15] Imperva. “Brute Force Attack.” [Online]. Available:
http://www.imperva.com/resources/glossary/brute-force.html [March 28, 2010].

[16] Rankl W. and Effing W. Smart Card Handbook. New York: John Willey, 2000.

[17] Oliver Kömmerling and Markus Günther. “Design Principles for Tamper-
Resistant Smart card Processors,” in Proc. USENIX Workshop on Smart Card
Technology (Smartcard ’99), Chicago, Illinois, USA, May 10-11, 1999.
USENIX Association, pg. 9-20, ISBN 1-880446-34-0. [Online].Available:
www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf [March 31, 2010].

[18] Hagai Bar-El. “Known attacks against Smart Cards.” [Online]. Available:
http://www.discretix.com/PDF/Known Attacks against Smart Cards.pdf [March
11, 2010].

[19] Stefano Zanero. “Smart Card Content Security.” [Online]. Available:

http://home.dei.polimi.it/zanero/papers/scsecurity.pdf [March 28, 2010].

[20] David Melnick, Mark Dinman and Alexander. “PDA Security,” in incorporating
handhelds into the Enterprise, Professional 1 edition. New York: Murator
McGraw-Hill, July 25, 2003.

[21] Joel Strauch (2004). “PDA Virus Found in the Wild.” [Online]. Available:
http://www.pcworld.com/article/117278/article.html [March 22, 2010].

[22] WindowsSecurity.Com. “Securing your Pocket PC.” [Online]. Available:

http://www.windowsecurity.com/articles/Securing-Pocket-PC.html [March 28,
2010].

[23] GSM Association. “GSM World.” [Online]. Available: www.gsmworld.com

[March 28, 2010].

[24] Nigerian Communication Commission (NCC). “Subscribers Statistical Data.”

Internet: www.ncc.gov.ng , Jan 1, 2010[April 2, 2010].

[25] Moe Rahnema. “Overview of the GSM System and Protocol Architecture.”
IEEE Magazine, 2002.

[26] John Scourias (2009). “Overview of the Global System for Mobile
Communication.” [Online]. Available:
www.shoshm.uwaterloo.ca/~jsconna/GSM/gsmreport.html. [May 11, 2010].

[27] Lauri Pesonen (1999). “GSM interception”. Department of Computer Science and
Engineering, Helsinki University of Technology. [Online]. Available:

124
 www.diaunisa.it/professori/ads/corso-security/www/CORSO-P.html. [April
18, 2010].

[28] David Margrave (2010). “GSM Security and Encryption”. [Online]. Available:
http://www.hackcanada.com/blackcrawl/cell/gsm/gsm-secur/gsm-secur.html
[March 18, 2010].
[29] Cryptome.org (2009). “Crack A5”. [Online]. Available:
http://cryptome.org/jya/crack-a5.htm [August 18, 2010].
[30] M. Briceno, I. Goldberg and D. Wagner. An Implementation of the GSM A3A8
Algorithm, 1999. [Online]. Available: http://www.scard.org/gsm/a3a8.txt ,
www.gsm-security.net/papers/a3a8.shtml [March 29, 2010].

[31] Anderson Ross (1994). “A5 - The GSM Encryption Algorithm”. [Online].
Available: www.tscm.com/phone/gsmcipher.html [March 20, 2010].

[32] Bruce Schneier. “Applied Cryptography”, 2nd Ed., Wiley, New York, 1996,
pp. 758.

[33] Robert McMillan (2010). “Crack A5.” [Online]. Available:

www.networkworld.com/news/2010/072210-new.html [March 18, 2010].

[34] Brian Prince (2009). “Crack A5.” [Online]. Available:

www.eweek.com/c/a/security/Mobile-Phone-Encryption-crack-Downplayed-
by-GSMA-621396/gsm-cracking-software-is.html [March 19, 2010].

[35] Jovan Dj. Golic. (1999). “Cryptanalysis of Alleged A5 Stream Cipher.”

[Online]. Available: http://jya.com/a5-hack.htm [March 18, 2010].

[36] H. Karl. “Email Communications.” 1999.

[37] Mobilein.com. “Smart Cards Mobile in a Minute”. Internet:

www.mobilein.com/smart-cards.htm , 2001[13th March 2010].

[38] Jonathan B. Knudsen. “Java Cryptography.” 1st Edition. O'Reilly Media, 1998,
pp 6.

[39] Lai Ngan Kuen. “Mobile Messaging using Public Key infrastructure.” Masters
Degree Project Report, Department of Computer Science, Faculty of Computer
Science and Information Technology, University Malaya, Malaysia, 2008.

125
[40] ETSI. (July, 1996). “Technical realization of the Short Message Service: Point-to-
Point.” GSM 03.40, version 5.3.0. [Online]. Available:
http://www.shaplov.ru/files/GSM/GSM_03.40_5.3.0.pdf [June 22, 2010].

[41] Carl Hamacher, Zvonko Vranesic and Safwat Zaky. “Appendix E: Characters
Codes,” in Computer Organization, 5th Edition, McGraw Hill Education, 2002.

[42] GSMFavorites.Com. “Error conditions that can return to an SC from an MS.”

Internet: www.gsmfavorites.com/documents/sms/ SMS FAQ and SMS
knowledgebase.htm , 2010 [November 8, 2010].

126
THE APPENDIXES

127
 APPENDIX A

PROGRAM SOURCE CODES FOR THE secureSMS MIDlet program

EncryptedSMSMIDlet.java class

/******************** EncryptedSMSMIDlet class: The main class used in the

secureSMS application **
** Fidelis C. Obodoeze **** fidelisobodoeze@gmail.com**** version 0.0.1
**********************************************/

import java.io.*;
import javax.microedition.io.*;
import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;
import javax.wireless.messaging.*;
// Main class which inits the connection and create the screens
// It owns the MessageConnection and Display
public class EncryptedSMSMIDlet
extends MIDlet
implements MessageListener, Runnable
{
private final Image logo;
private final SendScreen displayable;
private int port;
private MessageConnection conn;
private Message nextMessage;
public EncryptedSMSMIDlet()
{
// init basic parameters
logo = makeImage("/logo.png");
try
{
port = Integer.parseInt(getAppProperty("port"));
}
catch (Exception e)
{
// in case the property is missing or with a wrong format
port = 6535;
}
ErrorScreen.init(logo, Display.getDisplay(this));
displayable = new SendScreen(this);
}
public void startApp()
{

128
// Build the connection string
String connection = "sms://:" + port;
try
{
// Initiate the connection and add listener
conn = (MessageConnection) Connector.open(connection);
conn.setMessageListener(this);
}
catch (IOException e)
{
ErrorScreen.showError("Exception creating message connection to " + connection,
displayable);
}
Displayable current = Display.getDisplay(this).getCurrent();
if (current == null)
{
// shows splash screen
String text = getAppProperty("MIDlet-Name") + "\n" +
getAppProperty("MIDlet-Vendor");
Alert splashScreen = new Alert(null,
text,
logo,
AlertType.INFO);
splashScreen.setTimeout(3000);
Display.getDisplay(this).setCurrent(splashScreen, displayable);
}
else
{
Display.getDisplay(this).setCurrent(current);
}
}
public void pauseApp()
{
}
public void destroyApp(boolean unconditional)
{
try
{
// Close the connection on exit
if (conn != null)
{
conn.close();
}
}
catch (IOException e)
{
// Ignore since we are closing anyway
}

129
}
// Asynchronous callback for inbound message.
public void notifyIncomingMessage(MessageConnection conn)
{
if (conn == this.conn)
{
try
{
// Create a ReceiveScreen upon message removal
BinaryMessage incomingMessage = (BinaryMessage) conn.receive();
ReceiveScreen handler = new ReceiveScreen(this, incomingMessage);
Display.getDisplay(this).setCurrent(handler);
}
catch (IOException e)
{
ErrorScreen.showError("Exception receiving message " + e.getMessage(), displayable);
}
}
}
// Send message in a different thread
public void run()
{
if (nextMessage != null)
{
try
{
conn.send(nextMessage);
}
catch (IOException e)
{
ErrorScreen.showError("Exception sending message(s) " + e.getMessage(), displayable);
}
}
nextMessage = null;
}
// loads a given image by name
static Image makeImage(String filename)
{
Image image = null;
try
{
image = Image.createImage(filename);
}
catch (Exception e)
{
// use a null image instead
}
return image;

130
}
void showMessage(String message)
{
ErrorScreen.showError(message, displayable);
}
void SendScreen(String number, String plainText, String password, boolean addDigest)
{
if (conn != null)
{
// create a new message
BinaryMessage binarySMS = (BinaryMessage) conn.newMessage(
MessageConnection.BINARY_MESSAGE);
String address = new StringBuffer("sms://").append(number).append(":").
append(port).toString();
binarySMS.setAddress(address);
// do encryption
long difference = System.currentTimeMillis();
try
{
byte[] messageContent = MessageCodec.encodeMessage(plainText, password,
addDigest);
// measure how long does it take to encrypt
difference = System.currentTimeMillis() - difference;
if (messageContent != null)
{
binarySMS.setPayloadData(messageContent);

StringBuffer report = new StringBuffer(

"Encryption successful using cipher ")
.append(MessageCodec.createEngine().getAlgorithmName());
if (addDigest)
{
report.append(" and digest ").append(MessageCodec.createDigest().
getAlgorithmName());
}
report.append(" took ").append(difference).append(
" ms. Overall message size is ").
append(messageContent.length).append(" and uses ").append(
conn.numberOfSegments(binarySMS)).append(" segments");
showReport(report.toString(), messageContent); nextMessage = binarySMS;
// send the message in another thread
new Thread(this).start();
}
}
catch (Exception e)
{
showMessage(e.getMessage());
}

131
}
else
{
showMessage("No connection available");
}
}
// shows the main screen
void showMain()
{
Display.getDisplay(this).setCurrent(displayable);
}
void showReport(String result, byte[] content) {
Display.getDisplay(this).setCurrent(new ReportScreen(this, result, content,
content.length));
}
}

MessageCodec.java

/******************** MessageCodec class: A class used in the secureSMS

application **
** Fidelis C. Obodoeze **
** fidelisobodoeze@gmail.com **
** version 0.01 **
**********************************************/
import org.bouncycastle.crypto.*;
import org.bouncycastle.crypto.digests.*;
import org.bouncycastle.crypto.engines.*;
import org.bouncycastle.crypto.modes.*;
import org.bouncycastle.crypto.paddings.*;
import org.bouncycastle.crypto.params.*;
import java.io.*;
// The class MessageCodec encodes and decodes messages
class MessageCodec
{
final static int OPTION_DIGEST = 0x1;
// Creates a BlockCipher Engine, for example DES or AES or Blowfish
static BlockCipher createEngine()
{
return new CBCBlockCipher(new BlowfishEngine());
}
// Creates a Digest Engine, for example MD5 or SHA1
static Digest createDigest()
{
return new MD5Digest();

132
}
// Do the encoding of the message including the headers, encrypted content and digest

static byte[] encodeMessage(String plainText, String password, boolean addDigest)

throws Exception
{
byte content[] = plainText.getBytes();
byte key[] = password.getBytes();
// Create the cipher. Modify createEngine to use another Engine
BufferedBlockCipher cipherEngine = new PaddedBufferedBlockCipher(createEngine());
// Initialize the cipher for encryption
cipherEngine.init(true, new KeyParameter(key));
byte[] cipherText = new byte[cipherEngine.getOutputSize(content.length)];
byte[] digest = null;
// Do encryption
int cipherTextLength = cipherEngine.processBytes(content, 0, content.length,
cipherText, 0);
cipherEngine.doFinal(cipherText, cipherTextLength);
// add a digest if required
if (addDigest)
{
Digest digestEngine = createDigest();
int digestSize = digestEngine.getDigestSize();
digest = new byte[digestSize];
digestEngine.update(content, 0, content.length);
digestEngine.doFinal(digest, 0);
}
// Create temporary streams
ByteArrayOutputStream out = new ByteArrayOutputStream();
DataOutputStream dout = new DataOutputStream(out);
// write length
dout.writeShort(cipherText.length);
// write options
int options = (addDigest) ? OPTION_DIGEST : 0;
dout.writeShort(options);
// write cipher text
out.write(cipherText);
// write digest
if (addDigest)
{
out.write(digest);
}
return out.toByteArray();
}
// Decodes a message reading the header, decrypting the content and verifying the
password
static String decodeMessage(byte[] messageContent, String password)
throws Exception

133
{
byte key[] = password.getBytes();
// create utility streams
ByteArrayInputStream in = new ByteArrayInputStream(messageContent);
DataInputStream din = new DataInputStream(in);
// read the message content
int cipherTextLength = din.readShort();
int options = din.readShort();
byte[] cipherText = new byte[cipherTextLength];
in.read(cipherText, 0, cipherTextLength);
byte[] digest = null;
Digest digestEngine = createDigest();
// If the message contains a digest read it
if ((options & OPTION_DIGEST) == 1)
{
int digestSize = digestEngine.getDigestSize();
digest = new byte[digestSize];
in.read(digest, 0, digestSize);
}
// Create decryption engine
BufferedBlockCipher cipherEngine = new PaddedBufferedBlockCipher(createEngine());
// Initialize the cipher for decryption
cipherEngine.init(false, new KeyParameter(password.getBytes()));
byte[] plainText = new byte[cipherEngine.getOutputSize(cipherTextLength)];
// do encryption
int size = cipherEngine.processBytes(cipherText, 0, cipherTextLength, plainText, 0);
cipherEngine.doFinal(plainText, size);
// It is important to do trimming to remove possible padding
String resultText = new String(plainText).trim();
// verify the text digest
if ((options & OPTION_DIGEST) == 1)
{
// calculate the digest of the resulting text
plainText = resultText.getBytes();
digestEngine.update(plainText, 0, plainText.length);
byte[] calculatedDigest = new byte[digestEngine.getDigestSize()];
digestEngine.doFinal(calculatedDigest, 0);
// compare digests size
if (calculatedDigest.length != digest.length)
{
throw new Exception("Digest size mismatch");
}
// compare byte per byte

for (int i = 0; i < calculatedDigest.length; i++)

{
if (calculatedDigest[i] != digest[i])

134
{
throw new Exception("Digest mismatch. Integrity of the message compromised");
}
}
}
return resultText;
}
}

SendScreen.java

import java.io.*;
import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;
import javax.wireless.messaging.*;

class SendScreen
extends Form
implements CommandListener
{
private final Command sendCommand, exitCommand;
private final TextField number, text, password;
private final ChoiceGroup checksum;
private final EncryptedSMSMIDlet parent;
public SendScreen(EncryptedSMSMIDlet parent)
{
super("Send Confidential/Secure SMS");
this.parent = parent;
// init UI
sendCommand = new Command("Send", Command.OK, 1);
exitCommand = new Command("Exit", Command.EXIT, 1);
number = new TextField("Enter Phone number", "", 20, TextField.PHONENUMBER);
text = new TextField("Enter the message", "", 300, TextField.ANY);
password = new TextField("Enter password", "", 24, TextField.PASSWORD);
checksum = new ChoiceGroup("Add digest", ChoiceGroup.EXCLUSIVE, new
String[]{"Yes", "No"}, null);
// create the form
append(number);
append(text);
append(password);
append(checksum);
addCommand(sendCommand);
addCommand(exitCommand);
setCommandListener(this);
}
public void commandAction(Command cmd, Displayable displayable)

135
{
if (cmd == sendCommand)
{
// verify that all is in place
if (number.getString().length() == 0)
{
parent.showMessage("Enter the Phone No");

else if(text.getString().length() == 0)
{
parent.showMessage("Enter the message");
}

else if(password.getString().length() < 8)

{
parent.showMessage("Password must be up to 8 xters");
}

else
{
// send the message
parent.SendScreen(number.getString(), text.getString(), password.getString(),
checksum.getSelectedIndex() == 0);
}
}
if (cmd == exitCommand)
{

parent.notifyDestroyed();
}
}
}

ReceiveScreen.java

/******************** ReceiveScreen class: A class used in the secureSMS

application **
** Fidelis C. Obodoeze **
** fidelisobodoeze@gmail.com **
** version 0.0.1 **
**********************************************/

import java.io.*;

136
import javax.microedition.lcdui.*;
import javax.wireless.messaging.*;
class ReceiveScreen
extends Form
implements CommandListener
{
private final Command decodeCommand, backCommand;
private final EncryptedSMSMIDlet parent;
private final BinaryMessage message;
private final TextField password;
ReceiveScreen(EncryptedSMSMIDlet parent, BinaryMessage message)
{
super("Got Confidential/Secured SMS");
this.message = message;
this.parent = parent;
// init UI
decodeCommand = new Command("Decode", Command.OK, 0);
backCommand = new Command("Back", Command.BACK, 0);
password = new TextField("Enter message's password", "", 256,
TextField.PASSWORD);
append("Received message from " + message.getAddress());
append(password);
addCommand(decodeCommand);
addCommand(backCommand);
setCommandListener(this);
}
public void commandAction(Command cmd, Displayable displayable)
{
if (cmd == decodeCommand && password.getString().length()>0) {
decode(message);
removeCommand(decodeCommand);
}
if (cmd == backCommand) {
parent.showMain();
}
}

private void decode(BinaryMessage message)

{
try
{
byte payload[] = message.getPayloadData();
// measure how long does it take to decrypt
long difference = System.currentTimeMillis();
String result = MessageCodec.decodeMessage(payload, password.getString());
difference = System.currentTimeMillis() - difference;
parent.showReport("Decoded message in " + difference + " ms: " + result, payload); }
catch (Exception e)

137
{
parent.showMessage(e.getMessage());
}
}
}

ReportScreen.java

/******************** ReportMessage class: A class used in the secureSMS

application **
** Fidelis C. Obodoeze **
** fidelisobodoeze@gmail.com **
** version 0.0.1 **
**********************************************/

import org.bouncycastle.util.encoders.Hex;
import javax.microedition.lcdui.*;
class ReportMessage
extends TextBox
implements CommandListener
{
private final Command backCommand, viewHexCommand;
private final byte[] content;
private final int size;
private final EncryptedSMSMIDlet parent;
ReportScreen(EncryptedSMSMIDlet parent, String text, byte[] content, int size)
{
super("Operation Report!", text, 256, TextField.ANY);
this.content = content;
this.size = size;
this.parent = parent;
backCommand = new Command("Back", Command.BACK, 0);
addCommand(backCommand);
setCommandListener(this);
}
public void commandAction(Command cmd, Displayable displayable)
{
if (getMaxSize() > finalText.length())
{
result = finalText.substring(0, finalText.length() - 3) + "...";
}
setString(result);
}
if (cmd == backCommand)
{
parent.showMain();
}

138
}
}

ErrorScreen.java

/******************** ErrorScreen class: A class used in the secureSMS application

**
** Fidelis C. Obodoeze **
** fidelisobodoeze@gmail.com **
** Version 0.0.1 **
**********************************************/
import javax.microedition.lcdui.*;
class ErrorScreen
extends Alert
{
private static Image image;
private static Display display;
private static ErrorScreen instance = null;
private ErrorScreen()
{
super("Error Detected!");
setType(AlertType.ERROR);
setTimeout(5000);
setImage(image);
}
static void init(Image img, Display disp)
{
image = img;
display = disp;
}
static void showError(String message, Displayable next)
{
if (instance == null)
{
instance = new ErrorScreen();
}
instance.setTitle("Error");
instance.setString(message);
display.setCurrent(instance, next);
}
}

139
 APPENDIX B

A3 The authentication algorithm used in the GSM system. Currently the

COMP128 algorithm is used as the A3/A8 implementation in most GSM
networks.

A5 The encryption algorithm used in the GSM system. There are various
implementations named A5/1, A5/2, ... The A5/1 is known as the strong over-
the-air voice-privacy algorithm. A5/x (A5/2 ...) are weaker implementations
targeted at foreign markets out side of Europe. There is also an A5/0
algorithm, which encloses no encryption at all.

A8 The key generation algorithm used in the GSM system. Currently COMP128
algorithm is used as the A3/A8 implementation in most GSM networks.

AuC Authentication Center. The AuC register is used for security purposes. It
provides the parameters needed for authentication and encryption functions
(RAND, SRES and Kc). The RAND is a random challenge generated
randomly. The other two parameters are generated from the RAND and the
subscriber's Ki using the A3 and A8 algorithms. These parameters help to verify
the user's identity (SRES) and provide the session key (Kc).

BSC Base Station Controller. The BSC acts as a common node between multiple BTSs
that together form one BSS and the backbone network.

BSS Base Station Subsystem. The BSS connects the Mobile Station and the NSS. It is
in charge of the transmission and reception. The BSS can be divided in two
parts: The Base Transceiver Station (BTS) or Base Station.

The Base Station Controller (BSC).

BTS Base Transceiver Station, a base station the MS communicates with.
COMP128 A one-way function that is currently used in most GSM networks
for A3 and A8. Unfortunately the COMP128 algorithm is broken so that it gives
away information about its arguments when queried appropriately. This is an
undesired and unacceptable side effect in a one-way function.

GPRS General Packet Radio Service. GPRS is used to implement high speed data
transmission between the MS and some other party. GPRS utilizes multiple
BTSs in the same BSS. The MS sends different packets to different BTSs which
are reconstructed at the SGSN.
This enables the MS to use a higher transmission speed than one transmission
channel can handle.

GSM Global System for Mobile communications, a mobile phone system based on
multiple radio cells (cellular mobile phone network).

140
HLR Home Location Register. The HLR is part of the AuC. The HLR provides the
MSC with triples specifying a random challenge and a SRES and a Kc based
on the Ki of a specific subscriber and the random challenge. The HLR is also
responsible for knowing the location of the MS at all times.

ISAAC Internet Security, Applications, Authentication and Cryptography. A small

research group in the Computer Science Division at the University of
California, Berkeley. http://www.isaac.cs.berkeley.edu/

Kc The secret session key used to encrypt over-the-air traffic between the BTS
and the MS. The Kc is generated after every authentication initialized by the
MSC. The Kc is calculated from the Ki and from the random challenge sent by
the MSC with the A8 GSM Interception http://www.dia.unisa.it/professori/ads/corso-
security/www/CORSO-9... 3 of 14 12/11/2009 10:29 algorithm. The MS and the HLR
both calculate the Kc independently of each other. The Kc is never transmitted
over-the-air.

Ki Ki is the secret key shared between the SIM and the HLR of the subscriber's
home network.

LSB Least Significant Bit.

LSFR Linear Shift Feedback Register. A register that generates an output bit based
on its previous state and a feedback polynomial.

MS Mobile Station, the mobile phone.

MSC Mobile services Switching Center, the central component of the NSS. The MSC
performs the switching functions of the network. It also provides a connection to
other networks.

NSS Network and Switching Subsystem, its main role is to manage the
communications between the mobile users and other users, such as mobile users,
ISDN users, fixed telephony users, etc. It also includes data bases needed in
order to store information about the subscribers and to manage their
mobility.

SDA The Smartcard Developers Association is a non-profit organization trying to

provide developers non-proprietary information about smartcards.
http://www.scard.org/

SGSN Serving GPRS Support Node. A SGSN delivers packets to MSs within its service
area through multiple BTSs. A SGSN also communicates with a HLR in order to
authenticate MSs to enable encrypted communications. In GPRS then SGSN
authenticates the MS instead of the MSC.

141
SIM Subscriber Identity Module. The SIM identifies a subscriber. The subscriber
can use multiple GSM phones with one SIM. All calls are charged on the same
account and the subscriber's phone number stays the same. The SIM card
contains IMSI, Ki and the A3 and A8 algorithms. The SIM is supposed to be
tamper-proof, so that the Ki cannot be retrieved from it.

SRES Signed RESponse. This is the response the MS returns to a challenge made by
the MSC during the MS authentication thus authenticating itself to the MSC
(or SGSN in the case of GPRS).

Signalling System 7 is used in most intelligent networks as a signalling protocol. SS7

is defined by ITU-T.

Symmetric Cryptography
In symmetric cryptography, the same key is used for both encryption and
decryption.

VLR Visitor Location Register.

The VLR stores triples generated by the HLR when the subscriber is not in his
home network. The VLR then provides the MSCs with these triples when
necessary.

142
 APPENDIX C

Table C: 1

Average Processing speed of the cipher algorithms with Bouncy Castle API

The table only provides a relative speed comparison. The lower the number, the faster the

algorithm performs the task.

Cipher Algorithm Average speed to process a 224-byte plain

text message x 100 times
Blowfish 501

DES 787

3DES 1,997

Rinjadael 3,858

AES-Fast 601

AES-Middle 1,463

AES-Light 1,432

IDEA 881

RC2 1,107

RC5 542

(Source: Forum.Nokia.com)

143
Table C: 2

Average Processing speed of the Message digest algorithms with Bouncy Castle API

The table below presents the same measurements for creating a digest of the same plain
text:

Digest Algorithm Average Processing Time (ms) x 100 times

MD5 422

SHA1 667

(Source: Forum.Nokia.com)

144