secure, privacy assured mechanisms for heterogeneous ... · for heterogeneous location network....

Secure, Privacy Assured Mechanisms forHeterogeneous Contextual Environments

by

Harikrishna Vasanta

Bachelor of Engineering,Bharathiar University, India1999Master of Information Technology,QUT, Australia2001

Thesis submitted in accordance with the regulations forDegree of Doctor of Philosophy

Information Security InstituteFaculty of Information Technology

Queensland University of Technology

February 2006

Keywords

Heterogeneous location networks, Context aware computing, Pervasive computing,

Ubiquitous computing, Secure system design, Network security.

iii

Abstract

Location information is used to provide a diverse range of services to users such as

emergency, navigation, billing, security, information and advertising services. This

information is derived from a broad range of indoor and outdoor technologies. The

location information thus derived is of different granularity, different co-ordination

system and is controlled by numerous service providers. In addition to this, broad

selections of devices are used for providing these services.

Having a diverse range of applications requiring location information at different

levels of granularity, the need to export location information across multiple devices

and the existence of different location determination technologies necessitates the need

for heterogeneous location network. These networks derive location information from

multiple sources and provides various location-based services to users irrespective of

the medium, device or technology used. Security, user privacy and management of

location information are some of the important issues that need to be addressed.

The main contribution of this thesis is the design of a secureand privacy assured

heterogeneous location architecture. A formal methodology was chosen to design the

heterogeneous location architecture. The design of the architecture resulted in a novel

key distribution protocol and a model for information flow that can be easily

encapsulated into applications or architectures having similar requirements.

The research also resulted in the enhancement of a proposed location framework

for securing critical infrastructures using context-aware self-defending objects. The

proposed enhanced framework helps to negate the security vulnerabilities introduced

through the use of general-purpose computer systems in critical infrastructures.

v

Contents

Keywords iii

Abstract v

Declaration xvii

Previously Published Material xix

Acknowledgements xxi

1 Introduction 1

1.1 Outcomes of Research . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Organisation of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Analysis and Classification of Location Systems 7

2.1 Location Based Applications . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Emergency Services . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Navigation Services . . . . . . . . . . . . . . . . . . . . . . 9

2.1.3 Tracking Services . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.4 Security Services . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.5 Billing Services . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.6 Advertising Services . . . . . . . . . . . . . . . . . . . . . . 11

2.1.7 Information Services . . . . . . . . . . . . . . . . . . . . . . 12

2.1.8 Entertainment Services . . . . . . . . . . . . . . . . . . . . . 12

2.1.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Location Sensing Mechanisms . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Angle of Arrival (AOA) . . . . . . . . . . . . . . . . . . . . 14

2.2.2 Time of Arrival (TOA) and Time Difference of Arrival (TDOA) 15

2.2.3 Signal Strength and Signal to Noise Ratio . . . . . . . . . . .15

vii

2.2.4 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.5 Hybrid Techniques . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Technologies for Location Determination . . . . . . . . . . . .. . . 17

2.3.1 Electromagnetic Waves . . . . . . . . . . . . . . . . . . . . . 17

2.3.2 Radio Frequency Based Systems . . . . . . . . . . . . . . . . 17

2.3.3 Infrared Based Systems . . . . . . . . . . . . . . . . . . . . . 19

2.3.4 Ultrasonic Based Systems . . . . . . . . . . . . . . . . . . . 19

2.3.5 Magnetic Tracking . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.6 Physical Tracking . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4 Classification of Location Technologies . . . . . . . . . . . . .. . . 20

2.4.1 Precision of Location Information Obtained . . . . . . . .. . 21

2.4.2 Tracking Mechanism . . . . . . . . . . . . . . . . . . . . . . 21

2.4.3 Nature of Application . . . . . . . . . . . . . . . . . . . . . 22

2.4.4 Derivation of location information . . . . . . . . . . . . . . .24

2.5 Need for Heterogeneous Location Networks . . . . . . . . . . . .. . 25

2.6 Issues in Heterogeneous Location Networks . . . . . . . . . . .. . . 25

2.6.1 Location and Resource Discovery . . . . . . . . . . . . . . . 26

2.6.2 User Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.6.3 Data Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.6.4 Hardware Characteristics . . . . . . . . . . . . . . . . . . . . 30

2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3 Design Methodology 33

3.1 System Development Methodology . . . . . . . . . . . . . . . . . . . 33

3.1.1 Build and Fix Approach . . . . . . . . . . . . . . . . . . . . 34

3.1.2 Staged or Waterfall Approach . . . . . . . . . . . . . . . . . 34

3.1.3 Spiral Approach . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1.4 Recursive/ Parallel/ Object Oriented Approach . . . . .. . . 35

3.2 Secure System Design . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.1 Requirements for Secure System Design . . . . . . . . . . . . 36

3.2.2 Evolution of Secure System Design . . . . . . . . . . . . . . 37

3.2.3 Formal Approaches to Secure System Design . . . . . . . . . 38

3.3 Methodology for Secure Architecture Design . . . . . . . . . .. . . 39

3.3.1 Formal Techniques Used . . . . . . . . . . . . . . . . . . . . 41

3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

viii

4 Requirement Analysis and Preliminary Design 51

4.1 Requirement Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.1.1 User Requirements . . . . . . . . . . . . . . . . . . . . . . . 53

4.1.2 ASP Requirements . . . . . . . . . . . . . . . . . . . . . . . 53

4.1.3 Network Operator Requirements . . . . . . . . . . . . . . . . 53

4.1.4 Location Server Requirements . . . . . . . . . . . . . . . . . 54

4.1.5 Government and Legislative requirements . . . . . . . . . .. 54

4.1.6 General Requirements . . . . . . . . . . . . . . . . . . . . . 54

4.1.7 Security Requirements . . . . . . . . . . . . . . . . . . . . . 54

4.1.8 Additional Requirements . . . . . . . . . . . . . . . . . . . . 54

4.2 Design of Heterogeneous Architecture . . . . . . . . . . . . . . .. . 55

4.2.1 Existing Privacy Architectures . . . . . . . . . . . . . . . . . 55

4.2.2 Discussion on Existing Architectures . . . . . . . . . . . . .56

4.2.3 Proposed Framework for Heterogeneous Location Networks . 57

4.3 Preliminary Analysis of Frameworks . . . . . . . . . . . . . . . . .. 58

4.3.1 Trust Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3.2 Latency Analysis . . . . . . . . . . . . . . . . . . . . . . . . 64

4.4 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.4.1 Based on Security . . . . . . . . . . . . . . . . . . . . . . . 65

4.4.2 Based on Performance . . . . . . . . . . . . . . . . . . . . . 66

4.4.3 Based on Trust . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5 Heterogeneous Location Architecture 69

5.1 Overview of Framework . . . . . . . . . . . . . . . . . . . . . . . . 70

5.2 Protocols for the Framework . . . . . . . . . . . . . . . . . . . . . . 71

5.3 Design of provably secure 3PKD protocol . . . . . . . . . . . . . .. 72

5.3.1 A New Protocol Secure in the AM . . . . . . . . . . . . . . 72

5.3.2 New Authenticators . . . . . . . . . . . . . . . . . . . . . . 74

5.3.3 Secure Protocols in the UM . . . . . . . . . . . . . . . . . . 77

5.4 Synthesis of Framework and Protocols . . . . . . . . . . . . . . . .. 78

5.4.1 Configuration and Registration of User Policy . . . . . . .. . 79

5.4.2 Registration of Privacy Policy by the ASP . . . . . . . . . . .79

5.4.3 Providing the Requested Service . . . . . . . . . . . . . . . . 80

5.4.4 Request for Location from Location Server . . . . . . . . . .82

5.4.5 Providing the Requested Service . . . . . . . . . . . . . . . . 83

ix

5.5 Comparing the Heterogeneous Architecture to the Requirements . . . 84

5.5.1 User Requirements . . . . . . . . . . . . . . . . . . . . . . . 84

5.5.2 ASP Requirements . . . . . . . . . . . . . . . . . . . . . . . 84

5.5.3 Network operator Requirements . . . . . . . . . . . . . . . . 85

5.5.4 Location Server Requirements . . . . . . . . . . . . . . . . . 85

5.5.5 Government and Legislative requirements . . . . . . . . . .85

5.5.6 General Requirements . . . . . . . . . . . . . . . . . . . . . 85

5.5.7 Security Requirements . . . . . . . . . . . . . . . . . . . . . 86

5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6 Location Data Management 89

6.1 Specification of Model . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.1.1 Description of Model . . . . . . . . . . . . . . . . . . . . . . 91

6.1.2 Formal Representation of Model . . . . . . . . . . . . . . . . 94

6.1.3 Proof of Security . . . . . . . . . . . . . . . . . . . . . . . . 99

6.2 Benefits of Using Formal Methods . . . . . . . . . . . . . . . . . . . 101

6.3 Extension to Assure Anonymity . . . . . . . . . . . . . . . . . . . . 103

6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

7 Implementation and Post-Analysis 105

7.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

7.1.1 Location Server . . . . . . . . . . . . . . . . . . . . . . . . . 106

7.1.2 Network Operator . . . . . . . . . . . . . . . . . . . . . . . 109

7.1.3 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

7.1.4 ASPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.2 Results and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 116

7.2.1 Collection Technique . . . . . . . . . . . . . . . . . . . . . . 116

7.2.2 Testing Platform . . . . . . . . . . . . . . . . . . . . . . . . 117

7.2.3 Client Perspective . . . . . . . . . . . . . . . . . . . . . . . 118

7.2.4 Network Operator . . . . . . . . . . . . . . . . . . . . . . . 123

7.2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

8 Heterogeneous Location Architecture for Security Services 127

8.1 Background Information . . . . . . . . . . . . . . . . . . . . . . . . 128

8.1.1 Security Aware Applications and Access Control . . . . .. . 129

8.1.2 Self-Defending Objects (SDOs) . . . . . . . . . . . . . . . . 130

x

8.1.3 Self Securing Devices . . . . . . . . . . . . . . . . . . . . . 131

8.1.4 Critical Control Systems . . . . . . . . . . . . . . . . . . . . 131

8.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

8.3 The Proposed Secure Context-based Architecture . . . . . .. . . . . 135

8.3.1 Self-defending Objects And Control Systems . . . . . . . .. 135

8.3.2 Overview of the Access Control Mechanism . . . . . . . . . 136

8.3.3 The Authorisation Mechanism . . . . . . . . . . . . . . . . . 136

8.3.4 Authorisation Communication Protocols . . . . . . . . . . .. 139

8.4 An Implementation Scenario . . . . . . . . . . . . . . . . . . . . . . 142

8.4.1 Analysis of the infrastructure . . . . . . . . . . . . . . . . . . 142

8.4.2 Four Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 143

8.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

9 Conclusion 147

9.1 Summary of Research . . . . . . . . . . . . . . . . . . . . . . . . . . 147

9.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

9.2.1 Location Based Applications . . . . . . . . . . . . . . . . . . 149

9.2.2 Location and Information Management . . . . . . . . . . . . 149

9.2.3 Privacy Policies and Anonymity . . . . . . . . . . . . . . . . 149

9.2.4 Secure System Design . . . . . . . . . . . . . . . . . . . . . 150

A Proofs for security protocols 151

A.1 Proof of security – 3PKD in AM . . . . . . . . . . . . . . . . . . . . 151

A.2 Proof of Security– MT-authenticator . . . . . . . . . . . . . . . .. . 153

B The Possum verification script 157

Bibliography 165

xi

List of Figures

3.1 System Development Life Cycle . . . . . . . . . . . . . . . . . . . . 40

3.2 Processes in Each Stage . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1 Proxy Centric Approach . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2 Client Centric P3P . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3 Server Centric Architecture . . . . . . . . . . . . . . . . . . . . . . .60

5.1 Overview of Framework . . . . . . . . . . . . . . . . . . . . . . . . 70

5.2 The Protocol 3PKD . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.3 Signature Based MT-Authenticator Using Time Stamps . . .. . . . . 75

5.4 MAC Based MT-Authenticator . . . . . . . . . . . . . . . . . . . . . 77

5.5 A Full-Fledged Authenticator . . . . . . . . . . . . . . . . . . . . . 77

5.6 A Key Transport Protocol Secure in the UM . . . . . . . . . . . . . .78

5.7 Registration of Privacy Policy by the User . . . . . . . . . . . .. . . 79

5.8 Registration of Privacy Policy by the ASP . . . . . . . . . . . . .. . 80

5.9 Protocol for Selection of ASP by User and Establishment of Secure

Communication between the User and ASP . . . . . . . . . . . . . . 82

5.10 Request for Location by User . . . . . . . . . . . . . . . . . . . . . . 83

5.11 Providing the Requested Service . . . . . . . . . . . . . . . . . . .. 83

5.12 Number of Cryptographic Operations Required . . . . . . . .. . . . 86

6.1 Flow of Information in ASP and Application Security Classes . . . . 92

6.2 Information Flow When Adding an Application . . . . . . . . . .. . 93

6.3 Information Flow When Removing an Application . . . . . . . .. . 93

7.1 Semantic Location Services . . . . . . . . . . . . . . . . . . . . . . . 109

7.2 Client Delay with Encryption Disabled vs Number of ASPs (1 User) . 120

7.3 Client Delay with Encryption Enabled vs Number of ASPs (1User) . 120

7.4 Client Delay with Encryption Enabled vs Number of ASPs (5Users) . 121

xiii

7.5 Client Delay with Encryption Enabled vs Number of ASPs (10 Users) 122

7.6 Client Delay Request ASP List vs Number of ASPs . . . . . . . . .. 123

8.1 Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

8.2 The Authorisation System . . . . . . . . . . . . . . . . . . . . . . . 137

8.3 Request for Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

8.4 Authorisation Request . . . . . . . . . . . . . . . . . . . . . . . . . 140

8.5 Making the Authorisation Decision . . . . . . . . . . . . . . . . . .. 141

8.6 Authorisation Response . . . . . . . . . . . . . . . . . . . . . . . . . 142

8.7 Reponse for Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

xiv

List of Tables

2.1 Location Based Application . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Physical and Symbolic Location Systems . . . . . . . . . . . . . .. 22

4.1 Trust Grading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.2 Trust Relationship for Client Centric Approach . . . . . . .. . . . . 61

4.3 Trust Relationship for Server Centric Approach . . . . . . .. . . . . 62

4.4 Trust Relationship for Network Operator Centric Approach . . . . . . 63

4.5 Trust Relationship for Location Server Centric Approach . . . . . . . 63

4.6 Comparison of the Number of Connections Required . . . . . .. . . 65

4.7 Comparison Based on Security Services Required . . . . . . .. . . . 66

4.8 Comparison Based on the Level of Trust Required . . . . . . . .. . . 67

4.9 Overall Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.1 Protocol Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.1 The State Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.2 User’s Required Level of Anonymity . . . . . . . . . . . . . . . . . .103

7.1 Client Delay (in ms), Cryptography Enabled . . . . . . . . . . .. . . 119

7.2 Client Delay (in ms), Cryptography Disabled . . . . . . . . . .. . . 119

7.3 Network Operator Delay per Operation (in ms), Cryptography Enabled 124

7.4 ASP List Generation Comparison (milliseconds) . . . . . . .. . . . . 124

7.5 Average Time Taken to Generate an ASP Chunk (10 ASP Load) .. . 124

8.1 Protocol Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

xv

Declaration

The work contained in this thesis has not been previously submitted for a degree or

diploma at any higher education institution. To the best of my knowledge and

belief, the thesis contains no material previously published or written by another person

except where due reference is made.

Signed:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Date: . . . . . . . . . . . . . . . . . . . . .

xvii

Previously Published Material

The following papers have been published and contain material based on the content

of this thesis.

[1] Harikrishna Vasanta, John W. Holford, William J. Caelliand Mark Looi. Ar-

chitecture for securing critical infrastructures using context-aware self-defending

objects. Inproceedings of The Fifth Asia-Pacific Industrial Engineering and Man-

agement Systems Conference, December 2004. ISBN: 0-9596291-8-1 .

[2] Harikrishna Vasanta, Terry Tin, Colin Boyd, Mark Looi and Juan Manuel

Gonzalez Nieto. A secure framework for user privacy in heterogeneous location

networks. Inproceedings of First International Workshop on Mobility Aware Tech-

nologies and Applications, Volume 3284 of Lecture Notes in Computer Science,

pages 264–294. Springer-Verlag, October 2004. ISBN: 3-540-23423-3.

[3] Richard Au, Harikrishna Vasanta, Kim Kwang Choo, Mark Looi. A user centric

anonymous authorisation framework in ecommerce environment. In proceedings

of Sixth International Conference on Electronic Commerce,(ICEC 2004), pages

148–158. ACM, October 2004. ISBN: 1-58113-930-6.

[4] Terry Tin, Harikrishna Vasanta, Colin Boyd and Juan Manuel Gonzalez Nieto.

Protocols with Security Proofs for Mobile Applications. Inproceedings of 9th

Australasian Conference on Information Security and Privacy (ACISP 2004), Vol-

ume 3108 of Lecture Notes in Computer Science, pages 358–369. Springer-Verlag,

July 2004. ISBN: 3-540-22379-7.

[5] Chris Wullems, Harikrishna Vasanta, Mark Looi and Andrew. J. Clark. A Broad-

cast Authentication and Integrity Augmentation for Trusted Differential GPS in

Marine Navigation. Inproceedings of Cryptographic Algorithms and Their Uses,

pages 125–139. QUT, July 2004. ISBN: 1-74107-064-3.

xix

Acknowledgements

At first, I would like to express my deep gratitude and thank mysupervisors Professor

Mark Looi and Professor Colin Boyd for their vision, guidance, and support at every

stage of this long and amusing journey. I am also indebted to Professor Ed Dawson for

providing me with the best facilities and a very good research environment.

I had an opportunity to work with a number of researchers in the centre. Some of

the research presented in this thesis was because of this collaboration. I acknowledge

their contributions. I would like to thank all my co-authorsin various research papers,

Andrew Clark, Chris Wullems, Jared Ring, John W. Holford, Juan Manuel Gonzalez

Nieto, Kim Kwang Choo (Raymond), Richard Au, Terry Tin and William J. Caelli

(Bill). I am greatfull to Kaplai Viswanathan for being a mentor and a very good friend.

Special thanks goes to all those beautiful minds with whom, Ihad the privilege to

share my room and views, Jason Smith, Mina Yao, Kevin Tham, Paul-Eric, Loo Tang

Seet, David Ross, John W. Holford, Jimmy and Chris Wullems. Iwould also like to

thank those whom I have the privilege of sharing my thoughts and knowing at ISI,

Yvonne Hitchcock, Mark Branagan, Jason Reid, Ernest Foo, Greg Maitland, Lauren

May, Selwyn Russell, Riza Aditya, Praveen Gauravaram, Kun Peng and many more.

I would like to thank Christine Orme and Elizabeth Hansford for simplifying the

amount of paperwork and university bureaucracy. Many thanks also to Matt Bradford,

Sam Lor, Ricco Lee and Steven Roberts of the secure network laboratory. I would like

to thank all my colleges in Information Systems and SEDC.

This thesis is a result of the encouragement, support and help of a number of very

great souls. I am highly in-dept to all my teachers, a galaxy of great friends from my

childhood till date, my wife and my immediate family for their trust in me and for

teaching me to trust myself and test my boundaries. To acknowledge their contribution

individually would exceed the page limit of this thesis.

The thesis is because of a dream that was seeded by my parents in my childhood. I

am very grateful to them. They were the best parents a child can ever ask for.

xxi

Chapter 1

Introduction

The field of computing and communication has evolved from itstraditional

boundaries. New technologies are widely being accepted by people through out the

world. This evolution has blurred the barriers between the fields of computation and

communication. The emergence of wireless technology has fully interconnected the

electronic world. New computation mechanisms have enhanced the means

to communicate through a variety of technologies like emails, chat to voice to

video. A wide range of devices can currently be used for performing computation and

communication effectively. The new devices are small, lighter and not confined to

single desks. Interactions with computation have now emerged as environmental and

communal experiences rather than a virtual and private world.

The integration of these technologies and the ability to interconnect the various

computing devices provides greater mobility. It also provides the infrastructure re-

quired for determining the environment surrounding the user. This facilitates enhanced

human computer interaction providing better services to users based on contextual in-

formation like the user’s current location. This field of computing is called“Context

aware computing”.

The concept of context aware computing is widely accepted and has great com-

mercial worth. However, many technical and ethical issues need to be addressed for

contextual services to be widely accepted and adopted across the world. These issues

include the privacy of the user, security of the communications, ability to determine

the contextual information of the user cautiously, abilityto effectively communicate

in a heterogeneous environment (multiple devices, multiple technologies, and multiple

1

2 Chapter 1. Introduction

platforms) and management of contextual information. Thisresearch was initiated to

study the field of context aware computing and design a secureand privacy assured

architecture that can explore the effective use of contextual information across multiple

devices, domains, access technologies and networks.

To achieve our goal, we set up a few technical objectives overthe lifetime of the

project. These are:

1. To identity the key requirements and explore diverse scenarios for designing a

comprehensive, integrated, privacy assured, security framework for the hetero-

geneous location networks that provide, end-to-end protection and robustness

against attacks.

2. To ensure that the designed heterogeneous location architecture sets a new stan-

dard in the design of secure systems by:

• using a wide range of formal mechanisms for designing the secure system

such that the resultant system not only incorporates the advantages of the

various formal mechanisms but enhances the overall security of the hetero-

geneous location network.

• designing provably secure communication protocols for heterogeneous net-

works which are light weight and ensure connectivity and ease of manage-

ment in wired and wireless mediums.

• modelling information flow mechanisms that can effectivelymanage the

flow of information between the users, service providers andnetwork op-

erators without the compromise of user’s privacy preferences or security

requirements.

3. To analyse and explore the field of context aware computing, to ensure contex-

tual information, like the location of the user, is effectively used for providing a

diverse range of critical and non-critical services.

1.1 Outcomes of Research

The study accomplished the majority of goals that were established at the beginning of

the project. This section presents a brief summary of these contributions.

1.1. Outcomes of Research 3

• Methodology for secure system design : We developed a methodology for

designing secure systems by combining the approaches of “Correctness by con-

struction” [4] and “Security system approach” [32]. The proposed approach di-

vided the overall system into sub-stages. A suitable formalmechanism was used

at every sub-stage of the system design. The sub-stages werethen integrated

resulting in secure heterogeneous location architecture.

• Secure and privacy assured framework : A detailed requirement analysis

was carried out and important requirements for the architecture were identified.

A secure and privacy assured heterogeneous location framework was designed

based on an evolutionary approach to meet the desired requirements. The design

provided a choice of two frameworks. The frameworks were analysis for trust,

latency and computational requirements. Based on the results of the post anal-

ysis, the network centric proxy approach was chosen to be most suitable to meet

the desired requirements. The work was published at the“First International

Workshop on Mobility Aware Technologies and Applications”, (MATA 2004).

• Secure communication protocols : A novel provably secure three party key

distribution protocol was designed for the proposed framework. The protocol

was designed using the Canetti-Krawczyk approach [11]. This provably se-

cure protocol was published in a research paper titled,“Protocols with Security

Proofs for Mobile Applications” at the 9th Australasian Conference on Infor-

mation Security and Privacy (ACISP 2004). In addition to the Key distribu-

tion protocols, additional secure communication protocols were designed for the

framework.

• Information flow model: A model to check and restrict the flow of information

between various service providers was designed. The mechanism was repre-

sented in Z [85]. Possum animation tool [97] was used to verify the model.

The model can be extended to control the level of anonymity and granularity of

location information divulged to service providers.

• Implementation and analysis of the heterogeneous locationarchitecture : The

architecture was implemented and was analysed to verify if the system addressed

the identified requirements. Unified Modelling Language (UML) was used for

development of the architecture. The results that were obtained coincided with

the initial analysis and met the desired objectives. The analysis also provided the

required proof of concept for the proposed architecture.


• Securing critical infrastructure using context aware self-defending objects:

An architecture was designed to secure critical infrastructures using the location

of the user and self defending objects. The architecture wasanalysed using

a case study. The results were presented at the“Fifth Asia-Pacific Industrial

Engineering and Management Systems Conference” (APIEMS 2004).

Collaborations among researches during the course of the research resulted in two

additional contributions. Since these were not directly related to the key objectives of

the research, they are not explained as part of this Thesis. Readers are advised to go

through the research papers for an in-depth understanding of these contributions.

• New vulnerabilities were discovered in the existing DGPS infrastructure. A

novel solution to address the identified vulnerabilities was designed and im-

plemented. The findings were presented in a paper titled“ A Broadcast Au-

thentication and Integrity Augmentation for Trusted Differential GPS in Marine

Navigation ” in the proceedings of Cryptographic Algorithms and Their Uses.

• A new user-centric anonymous authorisation framework for E-Commerce envi-

ronments was designed. The credential-based approach allows a user to gain

access rights anonymously from various service providers who may not have

pre-existing relationships. The approach can be extended to heterogeneous lo-

cation networks, providing anonymous authorisation to service providers. The

work resulted in a research publication titled“ A user centric anonymous autho-

risation framework in ecommerce environment”which was presented at Sixth

International Conference on Electronic Commerce (ICEC 2004).

1.2 Organisation of Thesis

The thesis is structured as follows:

• Chapter 2 explores the field of context aware computing. A review of the various

location based applications, location sensing mechanismsand existing technolo-

gies for location determination are presented. The chapteralso (1) classifies the

existing technologies, (2) analyses the various issues that need to be addressed

in the field of heterogeneous location networks, and (3) summarises the need for

heterogeneous location architecture.

1.2. Organisation of Thesis 5

• Chapter 3 presents the existing approaches to design systems, emphasising

the need for secure system design. The methodology adopted for the design

of secure heterogeneous location architecture and a brief review of the formal

mechanism used in the design are described in this chapter.

• Chapter 4 collects the requirements for designing a secure heterogeneous loca-

tion architecture and presents the results of the preliminary analysis of an evolu-

tionary approach chosen to design a heterogeneous locationframework

• Chapter 5 describes the provably secure 3 Party Key Distribution (3PKD) pro-

tocol designed for the proposed framework. Integration of the 3PKD and other

communication protocols with the framework along with the comparison of the

resulting architecture with the requirements is also presented in this chapter.

• Chapter 6 proposed a methodology for managing location information across

multiple service providers. The model is formally represented using Z and the

functionality explored using the Possum animation tool.

• Chapter 7 presents the results of the prototype implementation of the heteroge-

neous location architecture. This chapter also presents a brief analysis of the

results.

• Chapter 8 explores the ability to extend the proposed architecture by using lo-

cation information for providing security to critical infrastructures. The chapter

introduces the user to the field of “ Self Defending Objects ” and, using a case

study, displays how insider and outsider attacks can be easily mitigated using the

proposed approach.

Finally, Chapter 9 concludes by summarising the main results of this work. It also

proposes some future directions for the research initiatedby this thesis.

Chapter 2

Analysis and Classification of Location

Systems

Context aware computing, is a mobile computing paradigm where applications use

contextual information (e.g. user location) to provide different services to users.

The last few years have seen a tremendous growth in this new field of computing.

Location information can be derived using the Global Systemfor Mobile Communi-

cations (GSM), the Global Positioning System (GPS), Wireless Local Area Networks

(LANs) and other proprietary technologies like Active Badges [100] and Radar [6].

Most of the existing location based service providers are independent in nature.

The location information derived by the service provider isof a varying level of

granularity, from pinpointing the exact location of the user to confining the user to

a known perimeter. The services provided are also device specific. There is limited

portability to provide services across different devices like Personal Data Assistant

(PDA), laptops and mobile phones. These kinds of location networks are called “Ho-

mogeneous location networks”.

The integration of location information, derived from multiple sources like GSM

and GPS to form a common location data set, can help the service providers offer a

wider range of services to the users. The ability to provide the services in different

devices can further enhance the mobility and result in aheterogeneous location

network. A heterogeneous location network is one that derives location information

from multiple sources and provides various location-basedservices to users irrespec-

tive of the device used.

7

8 Chapter 2. Analysis and Classification of Location Systems

Currently there is a general move towards heterogeneous data access with the net-

work operator being able to consolidate the billing, transparency of data access and

authentication over a number of technologies such as GSM, 3rd generation (3G) and

wireless LAN network. For example, (1)dual band phones support both 3G and GSM

technologies, and (2) new integrated devices can provide support to Wireless LAN

and General Packet Radio Service (GPRS). The integration oflocation technologies

and the ability to provide the user with a range of services independent of the device

enhances mobility and provides the ability to manage the networks easily.

The move towards heterogeneous data acquisition and management can benefit

the user, network operators and service providers. It can help the user to manage

and configure the privacy policies easily. The approach can provide the user with the

flexibility to choose the granularity of location information to disclose it to a service

provider. The network operators can manage the networks more efficiently and the

service providers can provide a wide range of services to theusers in an heterogeneous

environment.

For effective use of the location information and design of heterogeneous location

networks, issues like the privacy of the user, security of the communication medium,

collection of location information in a centralised mannerand creation of a centralised

location dataset need to be addressed.

This chapter briefly discuses the various services being provided using location in-

formation, the technologies that are currently available,the different mechanisms used

for location information and the issues that needs to be explored. The chapter also clas-

sifies the various location based services and the location determination mechanisms.

2.1 Location Based Applications

The last few years have seen a tremendous growth in the use of portable devices with

wireless connectivity in the networked world. This has led to a market, which provides

users with services based on their location information. The market value of these

location based services is expected to be worth to the tune of40 billion US dollars by

the year 2006 [43].

The growth of location-based services mainly relies on greater user participation.

It further requires that the user trust the service provider. The service provider should

provide an assured level of privacy to the user and should notmisuse the user location

information [23, 84]. In most of the current location determination systems, the net-

2.1. Location Based Applications 9

work operator can track the location of users with a varying degree of accuracy and is

responsible to store the information. The location information derived by the network

operator can be used to provide various kinds of services.

2.1.1 Emergency Services

The E-911 emergency system was the first location based outdoor application and was

commissioned by the US Federal Communications as a mandatory requirement in the

year 1994 [29, 58]. The system required cellular networks toprovide the loca-

tion of the users within 125 meters, to emergency services byOctober 2001. Similar

emergency systems are also discussed by various other countries like European Union,

Japan, Canada and Australia [5, 67].

Emergency services can be either user triggered systems or automated emergency

response systems. E-911 system is an example of user triggered emergency response

system. There are systems that are partly automated like theLondon Ambulance Ser-

vices Computed Aided Dispatch (LASCAD) [39]. LASCAD aims atautomating the

dispatch of ambulances to patients by tracking the locationof the caller and the ambu-

lance. The system determines the nearest ambulance and dispatches the ambulance to

pick up the patient needing emergency services. Emergency Position Indicating Radio

Beacons (EPIRB) is an automated emergency system used to provide services to ma-

rine, air and land emergency callers by alerting rescue authorities and indicating the

location of the user [24].

Location information can also be used for designing indoor emergency alarm sys-

tem. The Duress Alarm System (DAS) designed in the year 1993 was used to track

prisoners inside the prison [22]. Contextual information like the location and temper-

ature can be used effectively for providing emergency services to fire fighters. Siren

system was designed to gather contextual information of fire-fighters through a wire-

less mesh network [56]. This information has also been very useful in designing a

mechanism that can successfully control bush fires.

2.1.2 Navigation Services

Location based navigation services are used to assist usersin managing traffic, provid-

ing road directions and guiding users in outdoor and indoor environments. Navstar is a

GPS based navigation service and was designed to assist US defence forces in outdoor

environments [75]. The system met the requirement Initial Operational Capability


(IOC) on December 8, 1993 and since then has been extensivelyused for commercial

navigation. The first commercial GSM based traffic monitoring application was de-

signed by Finnish mobile operator, Radiolinja, and a software expert from Karlsruhe,

PTV in the year 2003. The new system was designed to provide every minute real-time

traffic information to the subscribers [95].

Active badges were the first indoor location determination technology and were

designed to assist users to navigate in indoor and limited outdoor environments [101,

100]. These were also used for determining the location of users inside office en-

vironments and guide them across large campuses. Similar location determination

technologies like the Active campus [47], Cricket locationsystems [71], Cyber guide

systems [64] have also emerged to provide similar assistance to users. Most of these

technologies have emerged from universities. These were designed to assist staff and

students in the university campuses.

2.1.3 Tracking Services

During the early years, tracking was mainly restricted to critical military infrastructure

being transported across the country. With the commercial availability of GPS and

other location determination mechanisms there are more innovative tracking applica-

tions. Currently equipment, vehicles, children and pets are being tracked using a wide

range of technologies like GPS, GSM, Wireless LAN, cameras,and other biometric

mechanisms like foot pressure and body temperature [2, 74].

Location based tracking services are also used for trackingstatic equipment and

devices in indoor office environments. Equipment tracking using Radio Frequency

Identity (RFID) is expected to be worth Au$ 5-20 billion by the year 2005 in Europe.

Equipment can also be tracked using Bats [103]. MicroTRAKgps.com has designed a

tracking mechanism that can help find a car in a parking space.GPSAlwaysNear.com

has a mechanism to locate a moving car and this is used for fleetmanagement and

to protect cars against theft [36]. Tracking services are used for tracking children,

employees and pets. Whereby Wireless designed GPS based child tracking system

that could assist parents to supervise their children [36].

2.1.4 Security Services

Contextual information, like the location of the user, can be used for authentication

and authorisation of users. Location can also be used for providing strong authentica-


tion in intranet environments and for authorising users in critical control systems. Looi

presented an architecture in which location information was used to enhance authenti-

cation in internet banking [65].

Wullems et al. presented an access control mechanism that incorporated location

information into the authorisation process [105]. In that system, an authenticated user

was only permitted to remotely access resources while theirPDA remained within

a specified area. A mechanism for protecting critical infrastructure with the use of

location based access control mechanisms and self defending objects is proposed in

this thesis in chapter 8. To authenticate a user or authorisea request, based on location

information, the location information needs to be derived securely and its transmission

tamper-proof. The use of location-based services in the security services is expected to

be on the rise in the years ahead, once the security and privacy drawbacks in existing

location determination mechanism are addressed.

2.1.5 Billing Services

The integration of the user’s communication medium to a single domain to provide

the user with a greater range of services has given rise to billing users based on their

current location. This is essential, as separate and disconnected origins of location

information cannot be used effectively for providing the user with a diverse range of

applications. Thus, the service providers bill their customers based on the location

from where calls originate [55]. In addition, service providers provide free calls to

users within a fixed domain or fixed radius from which the call originates.

2.1.6 Advertising Services

The ability to promote a product to a customer within a geographic area by analysing

user behaviour and shopping habits and then deliver targeted advertisements, coupons

and promotions to wireless internet devices, including phones, PDAs and two-way

pagers is expected to enhance business prospects. The location is usually determined

by the tie up with the current network operator, analysing the user’s Internet address,

advertising through the local wireless LAN and/or by examining registration informa-

tion the user may have handed over to the advertiser.

Shopping mall assistance is also currently available in major malls across the USA

and used to guide customers. Cyber guide designed by the Future Computing Group

at the Georgia Institute of Technology’s Graphics, Visualisation and Usability (GVU)


Centre [64] is an example of a service that acts both as a location based informa-

tion service and advertising service. The Information Society Technologies (IST) Pro-

gramme of the European Commission called ELBA (European Location Based Adver-

tising) also aims at delivering innovative location based advertising mechanisms for its

users [62]. MoMa-project is mobile media-initiative of German ministry of economics

that intends provisioning of contextual based services forthe mobile marketing [76].

2.1.7 Information Services

Mobile yellow pages, location based paging, location-based navigation and product

advertisements are the commonly used location based information services. Most of

the previously discussed applications can also be debated to belong to a class of infor-

mation service being provided to the user.

Location based guiding of users during tours, visiting universities campuses and

in shopping malls are commonly available in the market. Active campus is a system

that was designed by University of California with contributions from Microsoft re-

search and Hewlett-Packard [47]. The system was designed for guiding students in

the campus and for providing, various other services like buddy finder, mark updates

in a wireless mobile environment. Cyber guide is also a similar location based infor-

mation service that is used for guiding the users in tours andshopping malls [64].

MOBILOCO Buddy Alert is a location based information service that informs the user

when friends are around [30].

Location based Yellow Pages are also becoming very popular.Other major areas

of application include the ability to find the nearest service provider such as petrol

stations, post offices, ATMs, fast food centres and supermarkets. The service has be-

come an essential part of the current 3G mobile infrastructures and are provided by

all the network service providers like Skymo Location Services, Telmap, Singtel and

Ericsson’s Mobile Positioning System (MPS).

2.1.8 Entertainment Services

With the major population of mobile phone users still young and GPS and other lo-

cation based mobile handsets emerging, there is a growing movement towards games

and other kinds of entertainment to be provided to users on this platform. The location

based entertainment industry aims at providing interactive multi player games a user

can play head-to-head against other user. Examples of location based games include,


Pirates!, a game that uses proximity-sensing technology and was designed by Nokia

Research Centre in Finland and the PLAY research studio in Sweden [14]. Also there

are other location based games emerging like ARQuake, Majestic [53].

Most of these games assign various roles to users based on their location. These

games also use other contextual information like the proximity to other players, and

mood of the player to enhance the gaming experience of users.The games also use

behaviour patterns of users to redefine the game to create more interactive and enter-

taining scenarios for the user to play [69]. One of the major concerns for the design of

these games has been the level of uncertainty that can be allowed for the users and its

effects on the psychology of the user [12]. Other location based entertainment services

include interactivity, synchronising motion, and other advanced technologies with fea-

ture film and video simulations to provide a very good alteredreality simulation [69].

2.1.9 Summary

Type of Existing services Payment model Examplesservice

Emergency Caller Instigated Free E-911, E112services Automated responses User paid LASCAD, EPIRB

Navigation Traffic management Free Finnish Mobilesservices Road directions User paid Navstar

Office assistance User paid Active BadgesMall assistance Free Cyber Guide

Tracking Tracking users User paid Smart floorservices Tracking equipment User paid RFID

Vehicle tracking User paid GPSalwaysNearSecurity User Authentication Freeservices User Authorisation FreeBilling Location Based Free Orange Mobilesservices Billing

Advertising Free ELBAservices

Information Yellow pages User Paid Skymoservices Travel services User Paid

Paging services User PaidEntertainment Games User Paid Pirates

services Interactive Movies User Paid

Table 2.1: Location Based Application

Though a detailed discussion of the various applications along with the advan-

tages and disadvantages would be very useful, this is beyondthe scope of this thesis.

The area is rapidly increasing and the application and services provided are integrated


with day-to-day activities of users. Location based applications are still emerging and

day-to-day applications will soon be provided based on the user’s location and other

contextual information. It would be right to conclude this section with a quote by Mark

Weiser,“The most profound technologies are those that disappear. They weave them-

selves into the fabric of everyday life until they are indistinguishable from it” [104].

2.2 Location Sensing Mechanisms

All the existing location sensing mechanisms aim to determine location information to

a precision that can be suitable for using in the designed location based applications.

Currently, there is no standard location sensing mechanism. While there are many

location determination technologies most of these rely on one of the basic mechanisms

discussed in this section. Some current technologies rely on more than one mechanism

to effectively determine the location. This section investigates the various mechanisms

that are currently available for determining the location of a user.

2.2.1 Angle of Arrival (AOA)

The determination of location based on the angle of arrival has been used in outdoor

and indoor environments. Examples of indoor location determination systems using

the angle of arrival mechanisms are the 802.11b Active campus and Active badges

systems. Most of these technologies also use Time Of Arrival(TOA) along with angle

of arrival to precisely and accurately determine the location of the user [90].

In the angle of arrival mechanism, the user has a device that continuously emits

signals that are received by the tower carrier’s antenna’s.The Angle of Arrival equip-

ment then combines the angles derived from at least two towers and determines the

location of the user.

The advantage of this systems is the need for only two towers for determining the

location compared to a minimum of three base stations for determining the location

based on the time of arrival mechanism to be discussed in subsection 2.2.2. Given

the appropriate conditions the location determined by the user is more precise and

accurate.

The major disadvantage of this mechanism is that single radio signals are highly

reflective in nature. Thus, the mechanism is not suitable forhigh-density areas and

indoor office environments. The mechanism also needs highlydirectional antennas to

capture the radio.

2.2. Location Sensing Mechanisms 15

2.2.2 Time of Arrival (TOA) and Time Difference of Arrival (T DOA)

Other commonly used location sensing mechanisms are the Time Of Arrival (TOA)

and the Time Difference Of Arrival (TDOA) mechanisms. The Code Division Multi-

ple Access (CDMA) based E-911 outdoor emergency location determination system

uses the TDOA for location determination. Several indoor location systems such as

the Cricket location system [71] and the Dallas prison guardsystem [22] use this

mechanism for location determination.

As the name suggests, the TOA mechanism uses the time of arrival of a signal from

the emitting device to the antenna [89] to determine the location of the user. The user

device emits a signal, which is received by the antennas of the service provider. The

antennas pass this to the mobile switching center. The TOA equipment at the mobile

switching center measures the difference in time when the signal arrived at the antenna

site and translated this to a latitude and longitude.

The errors in estimating the absolute propagation time leads to inaccurately in de-

termining the location of the user. To overcome this error, the TDOA sensing mech-

anism was proposed. The mechanism uses the arrival time of the signal between the

base stations sending the signal and receiving the signal for location determination.

The major disadvantage of this mechanism is that processingdelays and no-line

of sight errors result in inaccurately sensing the locationof the user. The mecha-

nism requires forced handover to determine the TOA measurements. In addition, the

mechanism requires expensive network modifications and at least three base stations

to determine a location. In spite of these drawbacks, this mechanism supports existing

GSM phones.

2.2.3 Signal Strength and Signal to Noise Ratio

The strength of the radio signal at a particular location canbe used for indoor location

determination. RADAR, an indoor location determination technology designed by

Microsoft research labs is one of the earliest location determination mechanisms that

used signal strength for location sensing [6]. Other indoorlocation determination

mechanisms like Castro and Muntz use the signal to noise ratio for location sensing.

The principle behind this sensing mechanism is the generation of location finger-

prints that are collected by performing a site survey of the Received Signal Strength

(RSS), and the Signal to Noise Ratio (SNR) from multiple access points [99]. The

entire area is covered by a rectangular grid of points. A database matching the RSS,


and SNR to the values at the point of the grid is calculated. The vector of values at a

point of grid is called a location fingerprint. The location is determined by querying

the database for the location matching the received signal strength.

The advantage of this location determination mechanism lies in the greater preci-

sion of the location information in indoor environments. Due to multiple reflection and

radio signal strength absorption, techniques like AOA, TOA, TDOA do not provide the

same precession. Since this mechanism requires mapping of the surroundings The it

can not be widely deployed in outdoor environments.

2.2.4 GPS

The Global Positioning System (GPS) is also one of the methods that is widely used

for the determination of the user location. GPS devices determine the devices latitude

and longitude using data received from the satellites. GPS uses TOA and TDOA for

determination but differs in that it uses four satellite signals (Base stations) to compute

the location of the user. The location information that is derived is in three dimensions

(Latitude, Longitude, and Altitude). GPS method is a handset based location deter-

mination mechanisms while Angle of Arrival, Time Difference of Arrival and Signal

Strength and Signal to Noise Ratio methods are network server based. Location infor-

mation that is derived through network based determinationmechanism is usually sent

to a location server that can then be provided to various service providers. In a hand-

set based location determination mechanism, the location information resides with the

user. The user can then choose to provide the information to the location server. The

main drawback of GPS is the inability to use in indoor environments.

2.2.5 Hybrid Techniques

Using of multiple sensing technologies has been very usefulfor achieving greater ac-

curacy and precision of the user’s location. Most of the commercial location systems

use this approach for calculating the location with accurate precision. Duress Alarm

location determination uses triangulations and time of arrival for location determina-

tion [22]. Radar uses signal strength and triangulation forlocation determination [6].

Most of the outdoor location determination technologies use a combination of Angle

of arrival, time of arrival, and time difference of arrival for location determination.

2.3. Technologies for Location Determination 17

2.3 Technologies for Location Determination

Determining location was an essential need for many centuries. Celestial navigation

and Bathymetric navigation was used to determine the in geographical location by

ships for many centuries [88]. The location information determined by this pro-

cess was highly inaccurate. With the exploration of electromagnetic spectrum and

the emergence of radio waves for communications, new location determination mech-

anisms like GPS have evolved that can determine the locationwith greater precision.

Apart from electromagnetic waves, physical proximity, magnetic tracking and com-

puter vision systems have also been explored for accurate location determination. In

this section we explore the commonly used location determination technologies along

with the advantages and disadvantages of these technologies.

2.3.1 Electromagnetic Waves

Every celestial body radiates energy of a particular wavelength. The energy passes

through space at the speed of light (300,000 km/sec) in the form of sinusoidal waves

called electromagnetic waves [81]. The frequency of these waves ranges from105

to 1018 Hertz. These waves were discovered by Heinrich Rudolf Hertzin 1888 and

are classified by their wavelength and frequency as radio waves, microwave, infrared

light, visible light, ultraviolet light, X-rays and gamma rays [81]. The electromagnetic

spectrum is a systematic arrangement of the electromagnetic waves based on their

wavelength and frequency.

Marconi in 1895 designed the first practical wireless telegraph system by using

the radio waves. Radio waves are electromagnetic waves witha frequency range of

105 Hertz to 109 Hertz [81]. Though the entire electromagnetic spectrum canbe

used for communication, the higher frequency electromagnetic waves (1016 Hertz and

above) have ionising properties causing radiation poisoning. Thus, these waves are

not used for communication. Most of the existing location determination technologies

use radio wave as transmission medium though ultrasonic andinfrared-based location

determination mechanism is used for indoor location determination.

2.3.2 Radio Frequency Based Systems

The radio frequency based location determination mechanisms are the most common

outdoor and indoor location determination technologies currently available. The radio


frequency based location determination mechanisms can be classified as infrastructure

based Radio Frequency (RF) systems, Ad-hoc radio frequencybased systems and Cel-

lular based systems [106]. The infrastructure and RF based systems are mainly used

for indoor location determination while cellular systems like GSM are used for outdoor

location determination.

The most common radio wave indoor location determination mechanisms oper-

ate in the 2.4GHz or 5GHz band. This frequency range does not require licensing

and is open for public use. Most of the indoor technologies use 802.11b wireless

LAN, 802.11a wireless LAN, Bluetooth, or Radio beacons as their backbone infras-

tructure for location determination. Some common examplesare the active office sys-

tem, RADAR by Microsoft research and the Dallas Prison guardsystem.

The outdoor location determination technologies mainly rely on the cellular in-

frastructure provided by the service providers. These operate in licensed frequencies

that are regulated by the government. The usual operation frequencies of the cellular

based systems are from 824-960MHz in most countries [87]. Cellular networks are

designed using either the Time Division Multiple Access (TDMA) or Code Division

Multiple Access (CDMA) mechanism [16]. Enhancements like GPRS and Enhanced

Data Rates for Global Evolution (EDGE) are on the rise to upgrade these traditionally

voice carrying channels to carry data.

One of the most common location determination mechanisms that use radio waves

for location determination is the Global Positioning system (GPS). GPS is a satellite-

based radio navigation system designed by the US Departmentof Defence that deter-

mines locations by using 27 earth-orbiting satellites (24 in operation and three extras in

case one fails) that revolve around the globe [28]. GPS receivers use low-power radio

signals from the GPS satellites to determine the location. The location is determined

using trilateration mechanism. The system was opened for public use in 1990 and since

then is one of the most commonly used outdoor location determination mechanism.

The reason for using radio waves for almost all reliable wireless communications

is because they can travel long distances and can pass through obstacles at low fre-

quencies. The major drawback of radio waves is that they are highly susceptible to

interference from other electric equipment. In addition, they are easily absorbed by

interferences like walls and indoor furniture.

2.3. Technologies for Location Determination 19

2.3.3 Infrared Based Systems

Infrared waves operate in the frequency range of1012 to 1015 Hz. Infrared based

location determination technologies are mainly used in indoor environments. A high

data rate of transmission is possible using infrared rays. In addition, the spectrum is not

regulated; less expensive, can be easily secured against eavesdropping and has fewer

interference issues. The limitations of using infrared is that it consumes excessive

power, has lower range (Max 10 m with line of sight) and is affected by background

radiation due to infrared light. The Active badge location determination system was

the first location determination technology and used infrared rays for communication

[101].

2.3.4 Ultrasonic Based Systems

Ultrasonic waves that operate in the frequency range of 40 kHz are also used for lo-

cation determination. These are usually beacons that are used to transmit the signal

and the location is determined based on the time of arrival ortime difference of arrival

as discussed in subsection 2.2.2. The Active office and Cricket location systems are

some of the most common location determination systems thatuse ultrasonic waves

for location determination [103]. Ultrasonic beacons are used along with radio waves

for better location determination.

The advantage of using ultrasonic waves is that they are not easily affected by the

reflective materials that effect the propagation of the radio signals. These are only

prone to interference by noise in the ultrasonic range. The disadvantage of using ultra-

sonic waves for communication is that the speed varies with temperature, pressure and

humidity. In addition, it is slow and has low update rates.

2.3.5 Magnetic Tracking

Location can also be tracked by measuring the change in the position and orientation

from the reference point. The mechanism uses a direct mechanical connection be-

tween a reference point and the target. Location determination using magnetic track-

ing is mainly used for motion capture and is primarily groundbased or body based.

Boom developed by Fake Space Labs is an example of a magnetic tracking system [7].

Similar systems include the Distributed Magnetic Local-Positioning System (DMLPS)

designed by Prigge et al. [78].


Magnetic location based systems have the advantage of high accuracy rates, high

update rates and are not influenced by the environmental factors as in the case of ultra-

sonic, infrared or radio waves. Since these systems need to be linked to the reference

point for location determination, they are only suitable for indoor environments.

2.3.6 Physical Tracking

Location is also determined by identifying the user in a known geographical environ-

ment. This is usually carried out using the location fingerprinting mechanisms dis-

cussed in subsection 2.2.2. These are mainly used for indooroffice environments

where a biometric mechanism already exists for access control. The existing access

control mechanisms are used for identification of the user and profiling the user. Use

of magnetic swipe cards, logs into computer, and tracking using multiple cameras are

examples of physical tracking of users [88].

The Active floor system designed by The Olivetti and Oracle Research Laboratory

in 1997 and the Smart floor location system designed by Georgia Institute of Tech-

nology are some examples of determining the location of the user based on the user’s

biometric information [2, 74]. These systems use foot pressure to trace the user. This

is then used to determine the location of the user.

The systems are limited to the indoor environment and do not assure the precision

of the user location. The determination of location based onphysical mechanisms can

also be falsified. These are the major limitations in determining the location of a user

based on the user’s physical presence.

2.4 Classification of Location Technologies

Classification of location technologies remains a big challenge. Researchers in the

field have used all possible permutations and combinations to determine location in-

formation accurately and to use the same effectively. The technologies, the accuracy

of location determined the applications that are used for location determination and the

mechanisms used for location sensing are all different.

We attempt to classify location mechanisms under four different banners. The first

classification is based on the nature of location information obtained, the second on

the technology used for location determination, the third on the nature of service and

payment mechanism used for providing the service and finallywe classify location

information based on how location information is obtained.

2.4. Classification of Location Technologies 21

2.4.1 Precision of Location Information Obtained

Hightower and Boriellio classified location information based on the precision of the

information derived as physical and symbolic location determination mechanisms [49].

Though most of the mechanisms try to pinpoint the location ofthe user precisely, de-

pending on the nature of the technology used for location determination the accuracy

of these mechanisms usually makes it impossible to determine accurate location.

Physical Location Systems

The location determination mechanisms that can accuratelydetermine location infor-

mation of the in users are called the physical location systems. Examples of physical

location determination mechanisms are the Global positioning system in the outdoor

range and the Active floor location system in the indoor environment. Most of the

physical tracking mechanisms discussed ( subsection 2.3.6) fall under the category of

physical location systems.

Symbolic Location Systems

Location determination mechanisms that confine the location information of the user

to a geographic region are called symbolic location systems. GSM is an example of an

outdoor symbolic location determination mechanism and wireless LAN based indoor

location determination mechanisms like RADAR and Active office can be classified as

symbolic location determination mechanisms.

2.4.2 Tracking Mechanism

Baratoff et.al classified tracking mechanisms as active andpassive mechanisms [7].

The classification is based on whether the source to track is being attached to the tar-

get (active tracking) or if the source was independent and location is determined by

observing the source from a distance (passive tracking).

Active Tracking Mechanism

Active tracking mechanisms are also called tagged locationdetermination mecha-

nisms. All electromagnetic tracking mechanisms are a form of active tracking mecha-

nisms. Active badges, bats, mobile phones and PDA fall underthe category of active


Tracking Physical/ Used Mechanism Used Environment ExampleMechanism Symbolic

802.11 Symbolic Triangulation Indoor RADARSymbolic Signal strength Indoor Spot OnPhysical Location Indoor LEASE

fingerprintingSymbolic Time of arrival Indoor Active Campus

GPS Physical Triangulation Outdoor EPIRBGSM Symbolic Time of arrival Outdoor E-911

TriangulationRadio Beacons Symbolic Triangulation and Indoor DALAS

Time of arrivalUltrasonic Symbolic Time of arrival Indoor Active office

BATSRF+Ultrasonic Physical Triangulation and Indoor Cricket

Time of arrivalInfrared Physical Angle Of Arrival Indoor Active Badge

Time of arrivalMagnetic tracking Physical Signal strength Indoor

Cameras Physical Biometric Recognition IndoorPhysical proximity Physical Signal strength Indoor Smart floors

Active floors

Table 2.2: Physical and Symbolic Location Systems

tracking mechanisms. Active tracking mechanisms can be used in both indoor and

outdoor environments.

Passive Tracking Mechanisms

Tracking of users based on observations like the use of cameras or foot pressures can

be categorised under passive tracking mechanisms. As largegeographical coverage

is required to track users, passive tracking mechanisms arenot suitable for outdoor

location determination systems.

2.4.3 Nature of Application

It is essential to classify heterogeneous location networks based on the nature of service

provided as the level of privacy, security requirement, quality of service and the control

of user information mainly depends on the nature of service being provided to the

user. Location based applications can be classified as paid emergency services, unpaid

emergency/security services, user paid services and free location based services.

2.4. Classification of Location Technologies 23

Paid Emergency Services

Paid emergency services are usually automated emergency response systems. An Ex-

ample of this system is the EPIRBS which is used for automatedemergency responses.

Since the user pays for service, the expectation for the quality of service being provided

to the user is high. Since these are emergency systems the granularity of location infor-

mation required needs to be precise and the control of the location information should

always be transferred to the service provider during an emergency. An automated

emergency tracking mechanism is usually an active trackingmechanism that provides

the location information to the user when emergency alarms are triggered. The issue of

location privacy can be addressed by designing policies that can automatically override

privacy preferences during emergency scenarios.

Unpaid Emergency/ Security Services

Services like the E-911 emergency and security services discussed in subsection 2.1.4

require that the location information is not tampered with and the location of the user

is accurately determined. The user personal privacy does not count as a factor in these

applications as the user needs to be tracked to provide theseservices to the user. Secu-

rity of the location information needs to be protected as theinformation should not be

tampered or spoofed. Thus, confidentiality and integrity ofthe information needs to be

protected. In most of the existing government based emergency services the network

operators are required to provide the precise location information of the user. In the

case of location based authentication and authorisation, the service providers need to

automatically track the user. The user should not be able to modify the location infor-

mation to gain unauthorised access inside a building. Thus preferences of user privacy

are always overridden in security and emergency applications.

User Paid Services

User paid location based services require that the user havecontrol over the location

information being provided. Also the security of the communications need to be secure

and there should be non-repudiation between the user and service provider for payment

purposes. A high quality of service should be provided to theuser.


Free Services

The user should have greater control over the level of location information that can be

provided to the service provider for location based serviceprovided at no cost to the

user. This is essential to assure the privacy of the user is protected. The user should

have the ability to determine the granularity of location information being provided to

the service provider.

Thus, the classification of location-based services based on the nature of the appli-

cation provides the requirements and expectations in termsof the privacy requirements,

security requirements and the quality of service provided to the user.

2.4.4 Derivation of location information

Location based service are reliant on the location information. Based on how the

location information is derived, location services can be classified as handset based

location determination mechanism or network operator based location determination

mechanisms.

Handset based location determination mechanism

In a Handset based location determination mechanism the location information is de-

rived and provided to the user at the user device. In this model, it is the responsibility

of the location device to provide the results to the locationserver. The location infor-

mation is either calculated at the network operator and thensend to the user device

for distribution or the user device calculates the locationinformation at the device it

self. An example of a former is the GPS system. In GPS the location of the user is

determined by satellites and then send to the user device. Indevices such as cricket,

location system the location is calculated at the user’s device.

Network operator based location determination

In a network operator based location determination mechanism, the location informa-

tion is derived by the network operator and used by the network operator to provide

the services to the users. GSM mobile positioning system derives location information

through a Network operator based location determination mechanism.

2.5. Need for Heterogeneous Location Networks 25

2.5 Need for Heterogeneous Location Networks

Currently location technologies are independent and the location information obtained

is of varied granularity. In addition, the services provided by the service providers are

device dependent. For example, network operators as Telstra (a local network operator

in Australia) provides a range of user services to their customers. These services in-

clude (1) wireless Hotspot services offering internet access, (2) wide CDMA(3G) data

services, and (3) mobile services like GSM/GPRS. These services are also provided in

a range of devices like mobile phones, laptops, PDA and desktop computers.

Location information can be used effectively if this information generated from

multiple sources can be consolidated to form a single location data set, and provide

robustness to users to configure the preferred privacy policies once and register these

with the service provider. But existing mechanisms requirethe user to configure the

policies each time a different technology is used for the same service provider. This

requires the changing the policies every time there is a change in the device or the

technology that is used to access the service. The ability toconfigure from a range

of devices and using any technology provided by the network operator gives greater

flexibility to manage the privacy preferences.

The common location data set created with the help of information derived from

multiple sources can be used for providing a wider range of services to users. The lo-

cation information can also be useful to provide various security services to the users.

Authentication and authorisation of the user can be provided based on the user’s lo-

cation. Also access control policies can be generated basedon location information

[105, 65]. The shift towards a heterogeneous architecture provides an environment for

better growth of the technology in multiple domains. This shift towards heterogeneous

location architecture is beneficial to all the participating entities. It assures the privacy

and security of the user is protected every time and is consistent. The user has greater

flexibility and the way location information is used is transparent to the user.

2.6 Issues in Heterogeneous Location Networks

Heterogeneous location networks have certain issues that need to be addressed as with

all emerging technologies. Certain issues like the hardware characteristics of the de-

vices, and security of wireless medium, are problems that have been inherited from

the parent wireless and mobile technologies. Issues such asthe privacy of the user, the

collection of the location information in a centralised manner, and creation of a cen-


tralised location dataset, are specific to the field of heterogeneous location networks.

It is thus essential that these issues be addressed to effectively use the heterogeneous

location networks.

2.6.1 Location and Resource Discovery

One of the requirements for heterogeneous location networks has been for the location

information about the user to be continuous. This requires that the location information

of the user is collected from all the location determinationmechanisms and stored in

a centralised dataset [31]. Also currently there is no standardised location representa-

tion and each application has its own representation [21]. Therefore certain issues like

location representation, location collection and generation of common location dataset,

need to be resolved before location information can be used in a heterogeneous envi-

ronment.

Location Representation

Location should be represented in a format that is:

1. well understood by the global community which benefits widespread adoption,

2. simple enough to be easily processed by computers there byallowing fast re-

sponses, and

3. in an organised manner for the information to be easily managed and used effec-

tively.

Coordination System

Currently there are many different ways to represent location information. Various

standardisation bodies have designed and specified location information that is in var-

ious representations. The most commonly available location representation formats

are:

• Cartesian Plane (x,y,z)

• Polar (◦, radius)

• UTM Universal Transverse Mercator (Easting and Northing)

• Longitude, Latitude, Altitude

2.6. Issues in Heterogeneous Location Networks 27

Granularity of Location Information

Granularity is a measure of the level of location information provided to a service

provider. The granularity of the location information is critical in managing privacy

concerns of users. In addition, it may be essential to managethe various levels of lo-

cation information that is required for different kinds of applications provided by the

service provider. Geopriv has devised a granularity level that can be easily managed

by the user based on the user requirements. GeoPriv group is the Internet Engineer-

ing Task Force (IETF) charter for Geographic Location Privacy [26]. The location

information is divided as follows:

• A = no granularity change required

• B = 10 kilometre radius (or within a defined latitude/longitude quadrant)

• C = 100 kilometre radius (or within larger defined quadrant)

• D = local or municipal civil designation (e.g., city)

• E = state or regional civil designation (e.g., state)

• F = national designation (e.g., country)

• G = time zone

Location Collection

As discussed in section 2.3, there are various location determination technologies

that are available for indoor and outdoor environments. These are mostly standalone

technologies and the control of the location information inmost of these technologies

lies with the network operator providing the service.

For effectively determining the user location the minimum requirement is for one

physical location determination mechanism that can exactly pinpoint the location of

the user. Based on the physical location obtained the granularities can then be cul-

tivated to form the required location data set. Since physical location determination

mechanisms are not practical in outdoor mechanisms for continuous tracking of the

user, there is a need for at least one symbolic location determination mechanisms. The

physical location determination mechanism can integrate with the symbolic location

determination mechanism thus providing the precise location of the user for the design

of a heterogeneous location dataset.


To take advantage of widespread deployments of location determination capable

networks, we require a mechanism that combines all these technologies together. Lin

has proposed means of combining the various location determination technologies

to a common location dataset [63]. Lin also identifies the need for addressing co-

ordination systems, supporting or conflicting results, andvariances of granularity and

accuracy. Jussi et al. also proposed a mechanism for aggregation of location data from

multiple sources that have been associated with a single mobile device [63].

Location Server

A centralised location server provides the ability to device location information from

the various network providers, and the user devices. Since the location information

derived from the service providers is of different formats and of different levels of

granularity this cannot be used effectively to provide location based services in an

heterogeneous location network.

A centralised location server can derive the location information from (1) the user

hand held device and/or (2) from the network operator, refinethe location according

to a required format and provide the information to a serviceprovider as specified by

the user. The use of a centralised location server will also allow the user to control the

flow of the location information to different service providers.

The OMA Location Working Group [73] defines a simple and secure access method

that allows Internet applications to query location information from a wireless network,

irrespective of its underlying air interface technologiesand positioning methods. The

specification also provides Mobile Location Protocol that can be used by an ASP to

request location information from a location server.

The location server determines the location information based of the mechanisms

described in the earlier section. The location server can bea central entity that obtains

the location information from the network operators that derive the location informa-

tion and the user hand held devices (is provided by the user).

The mobile location protocol provides five different service options in which loca-

tion can be requested from a location server. Of these, the standard location immedi-

acy service and the Triggered Location Reporting Service are useful for the proposed

framework. The Standard Location Immediate service is usedwhen a (single) location

required as one-time information. The Triggered Location Reporting Service is service

used when the user location is at a specific time interval or onthe occurrence.

One of the major drawback with the creation of a centralised location server is that

2.6. Issues in Heterogeneous Location Networks 29

a successful attack on the server can compromise the privacyof all the registered users.

It is thus essential to secure the information in the location server. Also where required

the identity of the user should be protected (during storage).

2.6.2 User Privacy

The location of the user is determined by the network operator in most of the exist-

ing technologies (GSM, wireless LAN). The network operatorhas the responsibility to

safeguard the information. When service provider requestslocation information, the

network operator provides the information with an authorisation from the user. The

authorisation is requested with a pop up message asking if the user wants to provide

the information to the service provider or not. The user has no control over what gran-

ularity of information is passed to the service provider andhow the service provider

uses the information provided by the network operator [31].

The current mechanism of user authorisation does not provide the required level of

privacy. Recently various governments, standardising organisations and researchers in

the field have stated the need for user’s to have greater control over location informa-

tion and the use of the location information to be transparent [19]. The fair information

practices Act [57] explicitly states the need for transparency in collection and using

personal information of user’s. The location information provides a dynamic update of

the users whereabouts to the service providers. This makes location information more

sensitive than the information commonly collected by the service providers.

The first legislation towards user location privacy was enacted by the US senate

in 2001. The “Location Privacy Protection Act of 2001” emphasises the need for

location privacy [19]. The legislation clearly states the need to inform the user on the

use, disclosure, retention and access to user location information. The legislation also

highlights the need for security, integrity and a technology neutral framework to assure

user location privacy. Similar legislation also exists in the European Union and Japan

[59].

Standardisation organisations like the World Wide Web Consortium and Open Mo-

bile Alliance (Previously WAP) have also emphasised the need to assure location pri-

vacy [102]. Since Preferential Privacy Policy (P3P) has been quite successful to assure

privacy in the internet environment and meets the requirements of the fair information

policies, the WAP-W3C forum thus endorsed the need for architectures similar to P3P

to assure user location privacy [25]. The drawbacks posed bywireless environments

and mobile devices were some of the major drawbacks from using the existing P3P


architecture in assuring location privacy. Thus, it was emphasised that similar architec-

tures like P3P that can suit the mobile and wireless environments need to be designed.

A similar endorsement was also made by the Geo Priv group [26]. The group also

listed some of the requirements for assuring location privacy in mobile and wireless

medium and emphasised the need for a heterogeneous approachfor location privacy.

3GPP group [1] and GSM LCS [37] standards also provided requirements for location

privacy in 3G and cellular environments.

2.6.3 Data Privacy

Data privacy is very important and needs to exist with user privacy. This is essential, as

user privacy without security of the user information and the communication medium

is a wasted notion. Without proper protection of user information even an extensive

privacy framework would provide insufficient user privacy [23]. Highlighting this

requirement is the 4th National Privacy Principle in the Privacy Act [35], that is, the

requirement to provide data protection regardless of the means of collection of the

data. Chapter 4 summaries the security properties requiredfor protecting user privacy

in heterogeneous location networks.

2.6.4 Hardware Characteristics

Workstations may range from simple PDAs to powerful notebook computers. The

power constraints of hand held devices and in the lower bandwidth than wired networks

remain an open ended issue [13]. In addition, in heterogeneous location network the

services provided to the users are independent of the deviceused for accessing the

service. Thus it is essential that the services provided to the users are not constrained

by the device used to request a service [31].

2.7 Conclusion

A heterogeneous location network can enhance the ability ofcontext aware computing.

These networks can provide the user with an ability to use location information to

request a wide range of services and are beneficial to all participating entities. Though

there exist the necessary building blocks for the design of such a network, there is

a need to integrate these fragmented technologies to form a heterogeneous location

architecture that is independent on any specific technology.

2.7. Conclusion 31

The heterogeneous location architecture provides a platform for commercial and

secure critical systems to uniformly run on a single platform. This necessitates the need

for a highly secure and fault tolerant architecture. Thus, we explored the use of various

formal techniques at each stage of our architecture development. Since a single formal

technique is insufficient and cannot meet the needs that involve the broader system

development life cycle process, we proposed a modification to the existing approach

to the design of secure systems that can incorporate the advantages of leading formal

approaches in system design. The next section of thesis, discusses the approach along

with a brief review of the various formal mechanisms that were used for the design of

the heterogeneous architecture.

Chapter 3

Design Methodology

Heterogeneous location architecture helps network operators provide users with a wide

range of critical and non-critical location based services. As emphasised in section 2.6,

issues of security and privacy need to be addressed for effective use of these networks.

Traditional development methodologies are inadequate forsecure system design as

they often leave numerous defects. In addition, in many cases security is incorporated

as a subsystem rather than as an integral part of the system. These make the systems

vulnerable to a wide range of attacks. Security vulnerabilities are often caused by

defective specification, design and implementation.

In this chapter, we look at existing system design approaches. We identify a suit-

able system design methodology for the design of the proposed architecture. We also

explore various formal mechanisms that can be used for secure system design.

3.1 System Development Methodology

There exists a wide range of system and software developmentmethodologies. Most of

them follow similar life cycle stages and share similar goals and objectives. The best

methodology is usually a combination of existing methodologies or selection of the

best methodology suiting the required design. This sectionprovides a brief overview

of the most commonly used methodologies for system design.

33

34 Chapter 3. Design Methodology

3.1.1 Build and Fix Approach

The Build and fixapproach is the earliest system development methodology. This

methodology is used for designing small ad-hoc and temporary systems and is not

suitable to design large systems, as any change in the initial development of the system

requires changes in the overall system development. This methodology also requires

flexible time management. The methodology relies on the experience of the individual

staff members in the organisation and does not require a detailed requirement analysis.

This fix and fly approachto system design is not suitable for designing secure system

and new systems with different requirements [46].

3.1.2 Staged or Waterfall Approach

The waterfall approach is the widely used industrial methodology. The methodology

has a sequence of steps. The first step needs to be completed before the start of the next

step. The approach is suitable for large projects and formalorganisations that have

high risks in the area of budget and schedule predictability. The approach is regarded

as highly impractical by a number of researchers because of the formal approach taken

for system development [20].

The various steps in the model are:

1. conceptualisation of the system. This step should considers all aspects of the

process and the interlink between the various processes,

2. The second step is the system analysis. This involves the gathering of the re-

quirements according to the customer needs,

3. Then the system is designed in which construction detailsof the system are con-

sidered,

4. the system is implemented.

5. Finally the testing of the system is carried.

This methodology is structured and disciplined. A lot of time is spent on the design

of the system. The main drawback of this methodology is that it requires experienced

staff with perfect foresight about the product. The modification to the system or its

functionality should be kept to minimum while using this methodology.

The approach can be used for design of secure systems if thereis a perfect fore-

sight of the product. Since testing is carried out after design, any enhancements in the

3.1. System Development Methodology 35

later stage of the system development could incorporate errors not foreseen during the

design of the system.

3.1.3 Spiral Approach

The spiral model uses the concept of prototyping. The methoduses an evolutionary

approach for identifying and evaluating risks and cost. A detailed risk analysis and

cost/benefit analysis is carried out before the start of the system development life cycle

[20].

The various steps in the process are

1. determining project development requirement, reviewing alternatives and iden-

tifying constraints such as time available budget and stafftalent variants,

2. evaluating the defined alternatives and identifying the risk and choosing alterna-

tives to minimise those risks,

3. developing a prototype based on previous work and effectiveness, and finally

4. revaluating and planing the next cycle. The model defines an organised approach

to prototyping.

This methodology works well in environments with no well-defined constraints and

requirements. The advantage of the approach is its ability to detect high-risk situations

in the earlier stages of the software development. The methodology also provides

the ability to identify the potential problems during the system requirements and im-

plementation stages. The disadvantage of the approach is the significant cost due to

early risk assessment. The spiral approach is useful in the design of the secure system

development. The risk analysis carried out at an earlier stage provides the ability to in-

corporate modifications to the system without adding complexity to the overall system

development.

3.1.4 Recursive/ Parallel/ Object Oriented Approach

The recursive approach is an evolutionary approach to waterfall model. The model

involves analysing the system, building and then testing the built system [20]. In this

methodology, system development steps are incorporated ineach stage and a sequence

of steps is followed in the development. The advantage of theapproach is its flexibility


in designing the system. The disadvantage is its easy degeneration into an ad-hoc build

and fix solution rather than a detailed process for the software development.

3.2 Secure System Design

In most commercial systems, security is considered a subsystem and is often incor-

porated after the identification of the vulnerabilities in the system. Thus the existing

approaches to secure system design involves the design of the system in one of the

approaches mentioned in section 3.1 and then incorporatingsecurity using either the

“Fly-Fix-Fly” approach or the“Defence in Depth approach”(See subsection 3.2.2)

[94, 79]. The secure system approach is mainly followed for the design of sensitive

and critical systems.

3.2.1 Requirements for Secure System Design

With the advent of Internet, computer systems are exposed toa large number of vulner-

abilities. There have a large number of attacks mounted on commercial systems and

these are mainly due to inefficient system design. The following are the requirements

for secure system development process,

1. Security should be part of the initial design process of concept development

and requirement definition. This helps in reducing errors atthe earlier stages

of system development, thus enhancing the security of the system and reducing

minimal negative impact due to its introduction at a later stage of the system

development. The alternative is theFly-Fix-Fly approach which involves the

design of the system, identifying security vulnerabilities and then adding en-

hancements to the system to protect against the vulnerabilities. TheFly-Fix-Fly

approach is usually more expensive and less effective.

2. Security should be an integral part of systems rather thana subsystem or ad-

ditional components. One of the requirements is to determine the effects on

various participating entities due to the incorporation ofsecurity into the system

development. The entities should include humans, machinesand the environ-

ment.

3. Security should take a larger view of the attacks than justfailures. There have

been serious security breaches, which have not resulted in the system failure.

3.2. Secure System Design 37

The design of secure systems using an engineering approach helps in avoiding

security breaches that have not been noted or any potential attacks that has been

missed.

4. Standards and codes of practice come to existence from incorporating past expe-

riences and in-depth knowledge on the area. With the advent of new technologies

and development tools, the accumulation of best practices for proven design use

can be difficult.

5. Total security is impossible to achieve but the design of systems by the proposed

approach provides an ability to identify the conflicts and constraints with other

design goals such as operational effectiveness, performance, ease of use, time

and cost. This approach provides an ability to avoid trade offs in risk manage-

ment.

3.2.2 Evolution of Secure System Design

Design of secure systems is a necessity for various engineering disciplines. There were

several approaches taken to satisfy this requirement, but most of the current system

development processes follow the practices for designing secure systems [4]. The

practices can be broadly classified under three different categories

Fly-Fix-Fly Approach

Fly-Fix-Fly approach is derived from the methodology used in the aviation industry.

The approach involves learning from previous experiences and modifying the system

to prevent previous causes of accidents [20]. This approachis suitable for systems

that do not change dramatically and situations where learning from the experience is

very effective. The introduction of a new design leads to a large number of errors and

affects the security and safety of the overall system. It is thus inefficient for designing

new systems.

Defense in Depth Approach

Defence in depth approach is largely used in nuclear and highcritical systems where

the consequences for failure are very high. The process involves construction of mul-

tiple, independent barriers, and a high degree of single element integrity to safeguard


the system such that a single point failure does not disable the barrier [20]. The secu-

rity of these systems is high. These systems require a disturbance in the process or the

failure of a sequence of barriers for the system to fail. Thisapproach is also currently

being deployed for designing secure systems. The details are presented in chapter 8.

Secure System Design Approach

Investigations into a large percentage of the accidents in aerospace revealed a large per-

centage of these were due to deficiencies in design, operations and management. Thus

the earlier approach ofFly-Fix-Fly proved to be inadequate for design of secure sys-

tems. Thus the safety system approach was introduced by the Department of Defence

of United States of America in 1961 [4]. The approach emphasised system theory

and systems engineering approach to prevent foreseeable accidents and to minimise

the result of unforeseen ones.

The main steps in the systems approach involve identification, evaluation, elimi-

nation and control through analysis, formal design and manufacturing procedures to

enhance safety and security of systems. The main distinction between the safety crit-

ical approach and the earlier approaches ofFly-Fix-Fly andDefence in Depthis its

primary emphasis on early identification and classificationof hazards so that correc-

tive action can be taken to eliminate or minimise those hazards before the final decision

is made.

3.2.3 Formal Approaches to Secure System Design

Formal specifications of the various systems and their specifications are carried out

using mathematical notations. These were used to define the syntax, semantics pre-

cisely according to the system’s requirement. The use of a formal approach reduces

incompleteness and inconsistency in system specification.This increases the overall

effectiveness of the system and reduces the amount of reworkrequired for redesigning

the system. These advantages justify the need for formal approaches to system design.

A major disadvantage of a formal approach to system design isthe lack of a single

standard formal mechanism to represent the overall system.Two approaches that tried

to overcome this approach are (1) correctness by construction for the design of mission

critical software [4] and (2) security system approach proposed by Deng et.al. [32].

3.3. Methodology for Secure Architecture Design 39

Correctness by Construction

For safety and mission critical systems, verification and validation activities frequently

dominate the costs and account for as much as 80 percent in some cases. The main

objective of the approach is to (1) not introduce errors in the first place, (2) remove

errors as close as possible to the point of the error introduction.

The approach was used for the design of mission critical software [4]. The process

involved the following steps,

1. semi formal specification of the system,

2. thin slice prototyping of the high risk areas,

3. a template driven approach to production of similar and repetitive code, and

4. tool supported static analysis of the system as part of thecoding process and

formal certification testing.

The advantage of the correctness by construction approach is the reduction in potential

safety critical errors that are found during static analysis of the system and the semi

formal/ formal specification providing the ability to studythe system with the code and

analyse the system easily.

Security System Approach

The approach for modeling and analysis of security systems architecture was proposed

by Deng et al [32]. The proposed approach provides a mechanism to design high

dependable security systems that assures consistency and integrity. In the proposed

approach, the authors presented a case study, where a systemis subdivided and each

subsystem is then represented in different formal mechanisms and analysed. The vari-

ous subsystems were then integrated into a single formal language. The security of the

overall system was compared and the results verified that theuse of multiple formal

languages did not affect the overall security of the system.

3.3 Methodology for Secure Architecture Design

The design of heterogeneous location architecture is carried out such that the secu-

rity and privacy needs of the system are addressed as part of the system design. The


Requirement Analysis

Framework D esign

Protocols and System D esign

System Integration

Implementation and Post Analysis

Figure 3.1: System Development Life Cycle

proposed architecture design is carried out using a modifiedwaterfall approach. The

overall development life cycle is presented in Figure 3.1.

The methodology carries out a detailed analysis of the system and checks if the

system meets the desired requirements at each stage. It thenproceeds to the next stage.

This is carried out using a combination of two existing approaches (1) correctness by

construction for the design of mission critical software [4] and (2) security system

approach for modeling proposed by Deng et.al [32].

The new approach required both formal and informal mechanisms. Though there

are many formal mechanisms, a single formal mechanism was insufficient for effec-

tively representing all stages of the system development life cycle. Thus, a combination

of various formal mechanisms was required at each stage of the system design. Fig-

ure 3.2 shows the system development in each sub-stage of thesoftware development

life cycle. The use of a suitable formal mechanism at each stage and the integration of

these stages resulted in the design of the secure heterogeneous architecture that incor-

porates the advantages of the various formal approaches.

Proceed to next stage

Design analysis based on suitable formal

mechanism

Does system match the

requirements

Carry out modifications

Redesign the system

Yes No

System design b ased on r equirement

Figure 3.2: Processes in Each Stage


3.3.1 Formal Techniques Used

A wide range of formal techniques was used in the design of theproposed system. The

choice of technique was based on the best mechanism that could address the require-

ments. The formal techniques were not just used for specification and verifications of

systems but included formal symbolic notations, theories and tools for both descrip-

tion and prescribing emergent as well as obligatory behavior. The formal techniques

incorporated formal methods and descriptions used to formally represent systems.

Secure Communication Protocols

Secure communication protocols can be analysed using two different formal tech-

niques. One is the formal technique and the other is using thecryptographic approach.

Both of these approaches have been used for the design of cryptographic protocols for

assuring the correctness and flaws in protocol design.

The formal methods techniques include uses a wide range of formal tools like

model checkers, theorem provers, and type checkers to provethe protocol secure. Soft-

ware tools are very useful in checking the specifications of protocols with finite states.

The major disadvantage of the formal method approach is the difficulty of checking

implementation errors in cryptographic protocols. Furthermore, the design of the pro-

tocols is complex. It often requires human intervention to analyse the protocol. Apart

from protection against known attacks, a proof that security is equivalent to some well-

understood problem is regarded as essential.

The cryptographic approach uses reduction proofs. This is based on computational

complexity. The security of the protocols in the cryptographic community is carried

out using a reductionist approach. In this approach, security is defined in a semantic

way such that the probability of success of any random polynomial time attacker is

negligible. By reducing the hypothetical attacks to a reputedly intractable problem,

the protocols are proven secure in the sense that if the protocol is broken it is because

some computational assumption is false.

Bellare and Rogaway provided proofs for two party key exchange protocols in 1993

and extended this in 1995 for a three party key distribution protocol. The major draw-

back of these proofs was that they were long and difficult to read for the non-specialist.

In addition, any small changes in the protocols required newproofs. Thus, it was

impossible to extend the proofs or design protocols in an incremental way. Bellare,

Canetti and Krawczyk (1998) introduced the modular approach to provable security

thus addressing a few drawbacks of the earlier approach. Theapproach relied on prov-


ing protocols secure in an ideal world model and then using a secure transformation to

move them into a real world model. This approach was coined asthe Canetti-Krawczyk

approach.

The Canetti and Krawczyk Model

We present a brief description of the approach in this chapter. In the CK model the

definition of security for key-exchange (KE) protocols follows the tradition of Bellare

and Rogaway [11], and is based on a game played between the adversary and the par-

ties. In this game, protocol is modeled as a collection of programs running at different

parties. Each program is an interactive probabilistic polynomial-time (PPT) machine.

Each invocation ofπ within a party is defined as asession, and each party may have

multiple sessions running concurrently. The communications network is controlled by

an adversary, also a PPT machine, which schedules and mediates all sessions between

the parties. This is done in two ways: in two ways:

1. By means of anestablish-session request, where another party with whom

the key is to be established, and a session-id string which uniquely identifies a

session between the participants. Note that session-id is chosen by the adver-

sary, with the restriction that it has to be unique among all sessions between the

two parties involved. This allows the delivery of messages to the right proto-

col instantiation within a party. In practice, the session-id is negotiated by the

communicating parties during a preamble to the actual KE protocol.

2. By means of anincoming messagewith a specified sender.

A restriction on how the adversary activates parties existsdepending on which of

the following two adversarial models is being considered:

• Authenticated-links adversarial Model (AM)defines an idealised adversary that

is not allowed to generate, inject, modify, replay and deliver messages of its

choice except if the message is purported to come from a corrupted party. Thus,

anAM–adversarycan only activate parties using incoming messages that were

generated by other parties inπ.

• The Unauthenticated-links adversarial Model (UM)is a more realistic model in

which the adversary does not have the above restriction. Thus, aUM–adversary

can fabricate messages and deliver any messages of its choice.

Upon activation, the parties do some computations, update their internal state, and

may output messages which include the identity of the intended receiver. Two activated


parties are said to have a matching session, if they have sessions whose session-ids are

identical and they recognised each other as their respective communicating partner

for the session. In addition to the activation of parties, anadversary can perform the

following actions:

1. Corrupt a party at will, by issuing the querycorrupt, and learn the entire current

state of party including long-term secrets, session internal states and session

keys. From this point on, an adversary may issue any message in which the

adversary is specified as the sender and play the role of the party;

2. The adversary may issue the querysession-key, which returns the session key

(if any) accepted by the party during a given session;

3. The adversary may issue the querysession-state, which returns all the internal

state information of party associated to a particular session;

4. The adversary may issue the querytest-session. To respond to this query, a

random bit is selected. If the radom bit is equal to 1, then thesession key is re-

turned. Otherwise, return a random key chosen from the probability distribution

of keys generated by the protocol. This query can only be issued to a session

that has not beenexposed, i.e that has not been the subject of asession-state or

session-key queries, and whose involved parties have not been corrupted.

During the game, the adversary performs atest-session query to a party and ses-

sion of its choice. After that, the adversary is not allowed to expose the test-session.

The adversary may continue with its regular actions with theexception that no more

test-session queries can be issued. Eventually the adversary outputs a bit as its guess

on whether the returned value is the session key or a random number, then halts. The

adversary wins the game if the two session keys are same. The definition of security

follows.

Definition 1. A KE protocolπ is calledSK-securein the AM if the following properties

are satisfied for any AM-adversary .

1. If two uncorrupted parties complete matching sessions then they both output the

same key;

2. The probability that the adversary guesses correctly thebit is no more than12.


The definition of SK-secure protocols in the UM is done analogously. By distin-

guishing between the AM and the UM, Canetti and Krawczyk allow for a modular

approach to the design of SK-secure protocols. Protocols that are SK-secure in the

AM can be converted into SK-secure protocols in the UM by applying anauthentica-

tor to it. An authenticator is a protocol translatorC that takes as input a protocolπ

and outputs another protocolπ′ = C(π), with the property that ifπ is SK-secure in the

AM, thenπ′ is SK-secure in the UM. Authenticators can be constructed byapplying a

message transmission (MT) authenticatorto each of the messages of the input proto-

col.

Summary

The CK approach was used to design secure protocols in the proposed architecture.

The major steps in the process of the design were:

• Design of the basic protocol and proof that the protocol is SKsecure in the

authenticated mode.

• Design of MT authenticators and proof of the validity of the authenticators.

• Application of the MT authenticator to the basic protocol. The protocol is thus

secure and can be used in the real world environment.

The major advantage of the CK approach is the ability to definethe security of the

protocols in a real world scenario and prove the protocols secure in both ideal world

and real world environments. The process has the advantage of using reusable modules

thus providing the ability to design secure protocols rapidly. The design of the secure

communication protocols using the CK approach is describedin chapter 5.

System Modelling

The inability to accurately express the model in informal techniques in uniform, man-

ageable and readable manner due to the complexity of the model motivated using the

formal approach for system representation. We used the Z specification language for

addressing this requirement. Z provided a mechanism to describe and analyse the re-

sult in a functional manner. This was essential before the model could be incorporated

with the rest of the architecture. Z is a formal specificationlanguage, which is the com-

monly used formal language for system specification. The specification language was

designed in the late 1970s by the programming research groupwithin Oxford Univer-

sity Computing Laboratory [86]. Z uses set theory and first order predicate logic for


the design of the formal language. The Fuzz type checker [86]was used for checking

the specification. Fuzz is a collection of tools that help to check the syntax and typing

of a Z specification. Fuzz was chosen for checking as it used the current specification

language. In addition, the documents could be easily transferred for generation of La-

tex documents using Fuzz. Since Z is a non-executable language, the use of formal

validation tools such as Possum was used to further enhance the understanding and

functionality of the security model. Possum is an animationinterpreter for specifica-

tions written in Sum. Possum was developed at the Software Verification Research

Centre at the University of Queensland [27, 97]. The advantages of using such anima-

tion tools in the field of security has been demonstrated in the analysis of fair exchange

protocols [15]. The use of these animation tools helped to increase the overall security

of the model. It is very useful to check the usability of the system and explore the

limitations of these mechanisms. The advantages of using Z,Fuzz and Possum for the

design along with the detailed specification of the model is presented in chapter 6.

Z approach

A detailed description of the language can be obtained from the Z reference manual

by Spivey [86]. A Z description of the functionality of a software system consists of a

collection of structures called schemas. A schema describes the static (states, invariant

relationships) and dynamic (operations, relationships between input and output, state

changes) features of a system. The structure of the schema isas follows.

SchemaName

SchemaSignature

SchemaPredicate

The basic steps are involved in the design of the formal Z specification.

1. Based on the behavior of the model, the various sets, operations and invariants

needed to describe the model are decided.

2. A schema is used to define in the state space.

3. The operations needed to define the state changes are decided in the correspond-

ing steps.

4. The inputs and outputs of the system are identified.

5. Schemas are introduced to induce state changes for each operation.


6. For all the schemas, a verification is carried out to analyse if the precondition

and post conditions of the system satisfied.

Summary

Z was useful to express the mechanism and the model. The use ofZ helped in easy

understanding of the system by the larger research community. Using Z it was easy

to isolate the specific mechanisms independently, analyse the mechanisms and then

incorporate the mechanisms with the rest of the architecture.

Implementation and Design

Unified Modeling Language (UML) was used during the implementation of the het-

erogeneous location architecture. The choice of UML was based on its support for

object oriented concepts [68]. UML incorporates most of thetechniques used in other

modeling languages like Booch, OMT and OOSE. The following factors favored the

choice of UML.

• UML provided the flexibility to transform formally represented systems into

easy graphically viewable and easily understandable development language.

• UML provided a formal basis to understand the overall system. The ability to

represent the system graphically provided the ability to easily specify the overall

system for implementation to developers with no formal background.

• UML provided support to the development of the framework andthe models

and processes. It provided the flexibility to add new concepts and notations to

the system easily

• UML provided the ability to transform the visualised systemin the object ori-

ented and component based programming languages. This helped in the easy

implementation of the designed system represented in multiple formal mecha-

nisms

UML basics

UML is an emerging standard. It was used during the implementation and design of the

proposed system. UML is a modeling language forVisualising, specifying, construct-

ing, and documenting the artifacts of a software-intensivesystem[45]. The modeling

language consists of a collection of best engineering practices that have been proved

successful in the modeling of large and complex systems. UMLprovides a mechanism


to formally integrate systems designed in various methods to produce a single common

and widely usable modeling language during implementationof the systems. UML

uses standard graphical notations for formal meta model, that can be easily interpreted

both by humans and tools for modeling systems. The diagrams present multiple per-

spectives of the system under development at each stage of its life cycle. The diagrams

are used to present the use case, design, process, and implementation and deployment

view of the overall systems. The interlocking of these viewsprovides an overall pro-

jection of the system under development that can further be analysed and built. Four

UML diagrams were used for static and dynamic parts of the heterogeneous location

architecture. The complete implementation details along with the various UML dia-

grams used in the design of the heterogeneous location architecture are presented in

[80]. A brief overview is also presented in chapter 7.

Use case diagrams:

Use case diagrams were used to describe the sequence of actions that can be performed

by each entity. The use case diagrams have four elements, (1)the actors with whom the

system interacts, (2) the system, (3) the use cases, or services, that the system knows

how to perform, and (4) the lines that represent relationships between these elements.

Use case diagrams represent the various actions that the entities perform in the overall

system. Use case diagrams do not present the sequence in which the actions are per-

formed between the various participating entities.

Class diagram:

Class diagrams are widely used to describe the types of objects in a system and their re-

lationships. Class diagrams are useful to visualise the relationship between the various

classes, interfaces, and collaborators. Class diagrams are useful in the Object Oriented

Software design process. The class diagrams are not presented in this thesis, as these

were largely associated with the implementation and codingof the heterogeneous ar-

chitecture.

Sequence diagrams:

Sequence diagrams are used for modeling the flow of logic. These enable the behav-

ior of use cases by describing the way groups of objects interact to complete the task.

Sequence diagrams are useful to describe the usage scenarios in the system along with

the logic of a complex operation, function, or procedure. A sequence diagram consists

of an action initiator, action duration and messages. The action initiator is the entity

that initiates the message. The action duration specifies the duration of the message

and messages are a sequence of arrows or lines to represent communication between


objects. Sequence diagrams cannot be used to display the collaborations among the

various participating objects. Another disadvantage of sequence diagrams is that they

are not so good at precise definition of the system behavior.

Activity diagram:

An activity diagram is essentially a flow chart representingthe various states in the

system. These diagrams show the business and flow of the activity in the system in a

particular state. These represent the transitions and activities that cause the changes

in the object states. Activity diagrams are useful for analysis of new process concepts

and reengineering opportunities. These are used to document decisions and interac-

tions between the various participating entities.

Activity diagrams have a start and end and connect various activities through their

transactions. The transactions are represented with the use of arrows flowing between

the activities. Apart from these basics, the diagrams can represent parallel behavior,

conditional behaviors and decision logics.

3.4 Conclusion

The secure heterogeneous location architecture was designed using a modified water-

fall approach along with a broad range of formal techniques.The use of the formal

techniques helped to negate the drawbacks of the waterfall model that were discussed

in subsection 3.1.2. The ability to use a wide range of formaltechniques at each stage

of system design helped to effectiveness of formal system design approach.

The use of a wide range of formal techniques helped in:

• improving the quality of the overall system by accumulationof integrated error

free modules.

• enhancing the scope of formal system design by providing theability to specify

and analyse user interfaces and user interaction.

• adapting easily to broad range of systems by selecting the appropriate formal

technique for each process.

• reducing the amount of rework required at the end of the system design by easy

identification and fixing of drawbacks at each sub stage.

• providing the ability to identify the conflicts and constraints with other design

goals and at various stages of system design.

3.4. Conclusion 49

The proposed system design uses a combination of the best suitable formal tech-

niques for the system development. The various formal approaches have been used

independently at various stages of the system development life cycle. The system de-

velopment methodology unifies these various steps and brings out a secure system that

encapsulates the benefits of these formal techniques. Each stage of the development

life cycle is presented in the following chapters.

• Requirement analysis, the initial framework and preliminary analysis of the

framework is presented in chapter 4.

• Protocol design and system integration is described in chapter 5.

• Information flow model designed based on the Z specification is presented in

chapter 6.

• Implementation and post analysis is described in chapter 7.

Chapter 4

Requirement Analysis and

Preliminary Design

The design of a secure system requires an in depth understanding of the network goals,

traffic flows, existing state of the network and the relationship between the various

entities taking part in the system. This can be achieved by carrying out a detailed

analysis of the functional requirements of the various participating entities and security

requirements of the overall architecture. Currently thereis no research done on the

requirements for heterogeneous location networks and there does not exist any uniform

framework that can support a heterogeneous network.

In this Chapter, we have identified the requirements for heterogeneous location

networks by analysis of existing privacy architectures. Based on the analysis additional

requirements for heterogeneous location networks were found necessary for assuring

the security and privacy of the users. Further, a heterogeneous privacy framework

was designed using an evolutionary approach. This approachwas chosen, as there is

no heterogeneous location architecture to be used as a reference starting point. The

various steps in the proposed approach are

1. the identification of key issues that need to be resolved inan heterogeneous lo-

cation network,

2. analysis of existing standardised mechanisms addressing the key requirements

in similar environments like World Wide Web,

3. modifying the standardised mechanisms to suit the heterogeneous environment

51

52 Chapter 4. Requirement Analysis and Preliminary Design

based on the analysis,

4. design of a heterogeneous location architecture that addresses the identified re-

quirements and finally

5. analysing the resulting architectures for trust, security and latency.

4.1 Requirement Analysis

In this section, we present the various requirements for designing secure heteroge-

neous location architecture. The requirement analysis aggregates the major require-

ments from the Open Mobile Alliance (OMA) (Previously WAP-W3C form) for Mo-

bile Web Privacy [102], the Geo Priv group that is the IETF charter for Geographic

Location/Privacy [26], the 3GPP group [1], and the GSM LCS Standards [37]. The

requirements also include the needs raised by government legislation and researchers

in the field. We also present some additional requirements that were identified during

the research.

Heterogeneous location architecture has four major entities participating in the sys-

tem. These entities are the user, the network operator, the location server and the ap-

plication service provider. We first define the responsibilities of these entities followed

by a detailed function and security requirement analysis.

• User: The entity that requests a location based service and whose location infor-

mation needs to be protected;

• Application Service Provider (ASP): The entity that provides the service re-

quested by the user;

• Network operator: The entity that provides the required infrastructure to the

user;

• Location server: The server that derives the location information from various

sources like GPS, GSM and stores the information in a location dataset. The

location server is responsible for providing the user with the location information

when the user requests the information.

4.1. Requirement Analysis 53

4.1.1 User Requirements

The user should have the ability to:

1. Choose an ASP the user wishes to request the service.

2. Have the flexibility and ability to choose the granularityof location information

the user is willing to disclose to an Application service provider. For example

the user may be willing to disclose the exact location to an service provider who

has provider a service earlier while would like to restrict the location information

to a different service provider who is providing the servicefor the first time as

he does not trust the new service provider with the information.

3. Have control over what the ASP can and con not do with the location information

disclosed by the user.

4. Update and refine policies that define the use of location information easily.

5. Protect the identity of the user if required.

4.1.2 ASP Requirements

The ASP should adhere to the stated privacy policy and the ASPshould restrict any

collection, use, disclosure of, retention of, and access tocustomer location information

to the specific purpose that is the subject of the express authorization of the customer

concerned.

4.1.3 Network Operator Requirements

The network operator acts impartially and should act according to the fair information

practices while selecting an ASP, thus providing fair competition among similar ser-

vices. The network operator may need access to the location information for audit trail

and network management. In such scenarios, it is essential that the anonymity of the

user is protected. The network operator may also use the aggregate location informa-

tion of the users marketing purposes. An example of network operators providing such

services are Telstra-Sensis.


4.1.4 Location Server Requirements

The location server must reconcile the user location information derived from various

sources like GSM, GPS and should provide the information according to the requested

granularity.

4.1.5 Government and Legislative requirements

The location service providers should be able to disclose the location of a user for

homeland security applications and emergency services.

4.1.6 General Requirements

Only privacy policies relevant to an application should be disclosed to the ASP. The

communication should be efficient and accommodate the requirements of thin clients.

The privacy policies should be easy to export and import across networks and the

privacy policies.

4.1.7 Security Requirements

The security properties required are:

1. Mutual end-point authentication between all the participating entities;

2. Data Integrity to stop modification by unauthorized entities during transmission.

Connectionless integrity is necessary during storage of location information and

user privacy policy;

3. Data confidentiality to prevent eavesdropping (during transmission and storage)

and replay by an adversary.

4.1.8 Additional Requirements

After the analysis of requirements raised by various research groups for location pri-

vacy two additional requirements were found necessary for assuring the sensitive loca-

tion information. (1) The ASP policies should be application specific instead of a gen-

eralised privacy policy as in Privacy Preferences Project (P3P). (2) Non-repudiation

with proof of origin is required for the ASP’s privacy policythus ensuring that the

ASP’s abides to the stated privacy policy.

4.2. Design of Heterogeneous Architecture 55

4.2 Design of Heterogeneous Architecture

Based on the analysis of the various requirements and the issues identified in sec-

tion 2.6, the key issues that need to be addressed in a heterogeneous architecture are

privacy, security and heterogeneous location determination. User privacy is an issue

that need to be addressed in both web environment and heterogeneous location envi-

ronments, thus we start by analysing the existing approaches to addressing privacy in

a web environment. This is an ideal starting point due to the similarities between the

Client-Server relationship in a web environment and the Client-ASP relationship in a

heterogeneous environment.

4.2.1 Existing Privacy Architectures

The current standardised and globally accepted mechanism for addressing privacy is

the P3P approach, developed by the World Wide Web Consortium(W3C). Researchers

in the field of mobile networks have also emphasised the need for similar mechanism to

P3P for addressing privacy in mobile environments. Agrawalproposed a modification

to the P3P to assure privacy in mobile environments [3].

The P3P Approach

The P3P initiative was designed by the W3C for achieving privacy in web environment.

In the proposed approach, the service provider defines the preferred privacy policy.

The policy editor converts the preferred policy to a machine-readable XML format.

The user sets the user preferred privacy policies in the web browser. When a user

requests a service from the service provider, a user’s agentcompares the user preferred

policy with the policy of the service provider at the user’s machine. The web browser

then pops up a statement to the user on the acquiescence of theuser preferences to

the service provider’s preferences. The user can then make adecision either to accept

the current service provider preferences or for searching for another suitable service

provider. This approach is also called the client centric approach.

The Server Centric Approach

The server centric approach was proposed by Agrawal at the W3C workshop in Vir-

ginia [3]. Though similar to the P3P the major change to the server centric approach

was that the processing took place at the location of the web server. The process re-


quired the user to send the privacy policies to the service provider. The service provider

then compared the user preferences to the service providerspreferences. The results

of the comparison were sent to the user. Similar to client centric approach, the user

can then make a decision either to accept the current serviceprovider preferences or

search for another suitable service provider. This approach reduces the computation

required at the user side as opposed to the client centric approach. Thus, it was stated

to be suitable for mobile environments.

4.2.2 Discussion on Existing Architectures

The existing privacy architectures, the client centric approach and the server centric

approach, were aimed at addressing the privacy of users in the web and mobile en-

vironment respectively. Thus, any drawbacks found in the comparison do not mean

the existing architectures are unsuitable for their designed infrastructure. The require-

ments for heterogeneous location privacy encapsulate the requirements of the web and

mobile environment along with additional requirements to assure location privacy in

cellular networks. In addition, the sensitive nature of thelocation information requires

greater security. Thus, the comparison can provide an idea of the needs for location

privacy in heterogeneous networks.

Client Centric P3P

The client centric P3P approach addresses the needs for privacy in web environments.

The architecture addresses some of the key requirements like (1) the ability of the

user to choose a service provider, (2) flexibility with whichthe policies can be easily

imported and exported across networks and, (3) adherence ofthe privacy policy to the

fair information practices. Since this architecture aims to address only the requirements

of web communication, it is not suitable for mobile environments, as it requires a lot

of computation for the comparison of the policies at the user’s location.

The major drawback of this architecture is the need for the user to independently

request every service provider to provide their policies until a suitable service provider

matching user preferences can be found. Another drawback isthe lack of any mecha-

nism to verify if the service provider adheres to the stated policy. Given that the archi-

tecture was designed for web communication with major usersaccessing the service

provider from a desktop, the property of non-repudiation with proof of origin could be

implemented.

4.2. Design of Heterogeneous Architecture 57

Server Centric P3P

The server centric P3P was proposed for providing privacy inmobile environments

as the processing takes place at the location of the server instead of the client. Since

the architecture is similar to client centric P3P, it has allthe advantages of the P3P

architecture. The major drawback is the need for the user to trust the service provider

with the privacy preferences. Since there is no non-repudiation with proof of origin,

there is no assurance of misuse of information.

4.2.3 Proposed Framework for Heterogeneous Location Networks

The use of the server at the ASP to process and compare the userpolicies has compu-

tational advantages but requires a lot of trust between the user and the ASP. A means

to enhance trust is by the use of non-repudiation, but this property is not possible with

the use of symmetric key mechanisms. Therefore, the processing has to take place at

a location where there exists mutual trust between the user and the processing entity.

There are two alternate places where the processing can takeplace. It can take place at

the location server, which the user trusts, in the existing mechanism or at the network

operator whom the user trusts with the other personal information like the address and

billing information.

The proxy server centric approach is shown in Figure 4.1. Thevarious steps in the

process involve the user and ASP registering the privacy policies with the proxy server.

When the user requests a service from the proxy server, the proxy server compares the

user policies to the policies of the ASP. The proxy server then responds by providing

the user with the list of the various ASP’s who match the user policy along with the

granularity of information that the ASP requires for providing the service requested by

the user. The ASP has to provide the minimum and maximum granularity of location

information required for the requested service. The user selects the ASP and requests

the ASP for the service. The service provider provides the requested service to the

user.

The advantages of the proxy centric approach is the ability for the user to choose

the ASP and provide the information according to the granularity the user feels safe.

The computation required at the client side is reduced and also the amount of com-

munication required reduces proportionally. Additional enhancements can include the

ability for the proxy server to rank the ASP to the number of clients currently using

the service provided by the ASP can be easily incorporated. The location server or


Figure 4.1: Proxy Centric Approach

the network operator can act as proxy server. A detailed analysis is carried out in the

following section to choose the most suitable heterogeneous framework.

4.3 Preliminary Analysis of Frameworks

In this section, we analyse the proposed architecture and compare it with the exist-

ing privacy architectures. Though the client centric architecture and the server centric

architectures are not specifically designed for the proposed heterogeneous location net-

work, these approaches can also be, used if the location server and the network operator

just performed their tasks and this would not adversely effect the requirements. Thus

with slight modifications to the existing client centric andserver centric P3P architec-

ture we carry out trust, latency and security analysis. Based on the analysis carried

out, the best-suited architecture is chosen for further development and design of secu-

rity protocols.

The modified client centric and server centric approaches are shown in Figure 4.2

and Figure 4.3. The architectures are similar to the existing P3P and server centric

approach discussed in subsection 4.2.1.

4.3. Preliminary Analysis of Frameworks 59

user

Network operator

Location server

ASP

1. Request the ASP for the Policy

2. Send the Privacy Policy

3. Compare the policies and the privacy policy of the user matches with the user poliy then negociate with the ASP the terms of use

4. Terms of Use of information and start of negotiation

5. Accepted terms and the signed copy of use by the ASP

6. Request for the location

7. Provide the location


9. Provide the requested service

Figure 4.2: Client Centric P3P

4.3.1 Trust Analysis

Trust relations are expected to influence the choice of the security mechanisms. The

relations can be represented in a trust matrix [66]. An understanding of the trust

issues is required to establish confidence in the completeness of the threats and risks.

All entities are expected to act in their own self-interest.

Preliminary observations of the various participating entities reveal that there is a

requirement for high reliance on the staff of network operators and service providers.

It is thus expected that there is a need for non-repudiation in achieving the objective of

user centric privacy. The significant trust issues considered are:

1. The privacy of user data,

2. Trust with adherence to the negotiated policy,

3. Use of location information, and finally,

4. Providing the requested services.

Since trust is not uniform in all situations, it is graded into four types. These are

based on the level of trust required between the entities. This approach of grading

the trust will help to analyse the amount of trust and the level of trust required in the

different approaches.


user

Network operator

Location server

ASP

1. Request the ASP for a service and send the user policy

5. Request for the location


Policy storage

database

2. Send the user policy and compare with the ASP policy

3. Send the results of comparison

4. Send the Status of the comparisons and the ASP policy

7. Provide the signed copy of the agreed policy with the location


Figure 4.3: Server Centric Architecture

The various grades are shown in Table 4.1. The grades that areselected for the

proposed analysis are Ad-hoc and aim to only give a preliminary understanding of the

trust between the participating entities. The objective isthat this preliminary analysis

will give an understanding for the overall trust level of thesystem. Trust exists only

when two participating entities. When there is no direct interaction between the par-

ticipating entities then we considered there is no trust between the entities. If there is

minimum interaction between the two participating entities and they are expected to

behave in accordance to the existing regulations then the trust level is considered low.

An average level of trust exists if the entity trusts the other entity by providing some

additional information. For example, the level of trust between the user and network

operator is considered average because the user currently trust the network operator

and provides the network operator with billing and other personal information. A high

level of trust exists between two participating entities ifthe two entities trust each other

completely.

Client Centric Approach

The entities that participate in the client centric approach are the user, ASP, network

operator and location server. Even though the network operator does not directly par-

ticipate, it is involved in providing the network for the requested service.

There is an average level of trust required between the user and network opera-


Trust Grade Representation Description

No Trust - No interactionLow Trust * Minimum level of trustAvg Trust ** Medium level of trustHigh Trust *** There exists a complete level of trust

Table 4.1: Trust Grading

tor as the user has to trust the network operator with the personal information and also

trust the network operator to provide necessary infrastructure for the requested service.

Similarly, the user trusts the location server to provide accurate location information

at the requested granularity and location server derives the location information ac-

curately. The user trusts the ASP to provide the requested service and adhere to the

policy that has been agreed.

The network operator trusts the user will pay for the requested services. The loca-

tion server trusts the user, who is in possession of the device used for deriving location

information. The location server also trusts that the network operator provides a secure

session for the transmission of the information.

UserNetworkOperator

LocationServer

ASP

User - ** ** **NetworkOperator

* - - *

LocationServer

* * - -

ASP ** * - -

Table 4.2: Trust Relationship for Client Centric Approach

The ASP trusts that the user has provided the correct location and the user will

pay for the requested services. In addition, the ASP trusts that the network operator

provides the network for the service without any prejudice and creates a secure session

for communication between the ASP and the network operator.Table 4.2 shows the

grading of trust that is required between the various participating entities in a client

centric approach.


Server Centric Approach

The server centric approach needs a greater amount of trust between the user and the

ASP as the user has to send the policy to the server of the ASP todo the processing.

The trust matrix is shown in Table 4.3

UserNetworkOperator

LocationServer

ASP

User - ** ** ***NetworkOperator

* - - *

LocationServer

** * - -

ASP ** * - -

Table 4.3: Trust Relationship for Server Centric Approach

There is a greater amount of trust required between the user and the ASP in the

server centric approach. There is a need for greater trust required between the ASP

and the user. The user has to trust that the policy provided bythe ASP is according to

the policies practiced by the ASP. Apart from the extra levelof trust that is required,

the amount of trust between the various entities remains unchanged.

Proxy Centric Approach

The network operator or the location server can act as a proxyserver. In this approach

even if the network operator acts as a proxy server, the function requirements of the

location server and the network operator are different. Thefunctions of the location

server and the mechanisms describing the derivation of location information by the lo-

cation server is provided in Chapter 2. We analyse the trust for both these approaches.

Based on the overall analysis the best approach is chosen.

Network operator centric approach

In the network centric approach the amount of trust requiredbetween the user and the

network operator should be higher. This is required as the network operator processes

the comparison of the policies of the user and the ASP. The network operator then

provides the best ASP for the requested service. The amount of trust required between

the location server and the ASP remain the same. The network operator has to trust the

user to pay for the services requested and provide the right policy.

As shown in Table 4.4 there is a greater amount of trust required between the network


UserNetworkOperator

LocationServer

ASP

User - *** ** **NetworkOperator

** - - ***

LocationServer

** * - **

ASP * * - -

Table 4.4: Trust Relationship for Network Operator CentricApproach

operator and the ASP. The network operator has to trust that the ASP provides the

right policy to the user and updates the policy when the ASP changes the policy. The

ASP has to trust that the network operator acts fairly and provides an unbiased list of

suitable ASP’s. The network operator has to provide the service requested by the user

and establishes a secure session for communication betweenthe user and the ASP.

Location server centric approach

In the location server, centric approach the processing takes place at the location server

and the location server provides the ASP with the location information of the user. The

amount of trust required by the user at the network operator is the same as required

in the client centric or the server centric approach. The user has to trust the location

server to provide the requested granularity of informationto the ASP and to provide

the list of ASP’s providing the requested service.

The location server also needs to trust that the ASP providesthe actual policy and

informs the location server in case of updating the policy. The ASP also has to trust

that the location server is not biased and provides the best results to the user’s request.

Table 4.5 shows the trust relationship in a location server centric approach.

UserNetworkOperator

LocationServer

ASP

User - ** *** **NetworkOperator

* - - *

LocationServer

*** * - -

ASP ** * ** -

Table 4.5: Trust Relationship for Location Server Centric Approach


4.3.2 Latency Analysis

Latency is the measure of time taken during the communication for the completion of

a specific task. The key factors to be taken into consideration while deciding the best

mechanism in a mobile environment are the total number of communications required

during the communication, the number of secure connectionsrequired and finally the

amount of processing required by each entity.

There are different kinds of message transfers and different costs and degrees of

practicality associated with each message transfer. One ofthe key factors to consider

is the medium of communication. The various mediums can be,

1. local message transfer taking place within the domain,

2. message transfer that takes place inter domain in a wired medium and, finally

3. message transfer in a radio link.

The transfer of inter-domain messages does not take a lot of time. The intra domain

message transfer in wired medium is faster than message transfer taking place in a in-

tra domain wireless medium. Also it is an advantage if there can be a greater number

of offline communications that can take place reducing the time required while a par-

ticular session is in progress. The security of the communication link is also a factor

that needs to be considered while deciding on the time required for communication as

secured communications take more time than unsecured communications. This is due

to the time taken for the key establishment between the participating entities, the time

for encryption and decryption of messages, etc.

The other key factors that latency depends on are the delay and the time taken for

processing at each entity. The main processing is the comparison of the policies and

this is expected to take a lot of time when compared to the other processes. It is thus

important to consider where the processing takes place. Theprocessing at the wireless

thin client is expected to take a greater amount of time than processing taking place at

either the application server or the proxy server.

Table 4.6 gives an overview of the number of communications required in inter

domain, intra domain wired, and intra domain wireless environments for all the four

approaches being proposed. Table 4.6 also provides an account of the number of

secure connections required and number of offline communications in each approach.

It is also important to note that the data rate increases proportionally as the number

of ASP’s the user analyses before selecting the best ASP for the required service in

4.4. Observations 65

ClientCentric

ServerCentric

Network OperatorProxy

Location serverProxy

Inter domain 2 2 2 2Intra domain wired 8 10 7 12

Intra domain wireless 8 10 8 7Off line message - - 2 2

Secure links 6 8 6 7

Table 4.6: Comparison of the Number of Connections Required

the client and server centric approach. Thus if the user contactsn different ASP’s

before the selection of an ASP who suits the privacy policy ofthe user, the amount of

communication becomesn times the initial communication. The use of proxy servers

can reduce this load as the proxy server is expected to provide the list of the suitable

ASP’s. The user can then contact the respective ASP and startthe service. This is one

of the greatest advantages of the proxy-based approach.

4.4 Observations

Different approaches have different advantages. The objective of the comparisons is to

find an optimum design that can address the maximum number of concerns. The most

important issues that need to be addressed are the security,amount of trust and time

required for communication.

4.4.1 Based on Security

Encipherment, digital signatures and access control are the key security mechanisms

required to achieve the required objectives. By the use of a symmetric key encryption

mechanism, we cannot provide non-repudiation that is one ofthe key requirements.

Non-repudiation is a key requirement between the ASP and theuser as there is a great

amount of trust required but in practice, this does not exist. Transactions between the

user and the network operator require lower levels of trust compared to trust between

the user and the ASP. An alternative approach to this would befor the proxy server

to provide the required service of non-repudiation on behalf of the user. This can be

possible as there exists a level of trust between the networkoperator and the user and

there can be a digital signature mechanism between the network operator and the ASP.

Table 4.7 provides the list of possible services.


Security services Mechanism Client centric Server centricNetwork

operator proxyLocation

server proxy

Peer Entity Authentication Encipherment Yes Yes Yes YesData origin Authentication Encipherment Yes Yes Yes Yes

Access control service Access control Yes Yes Yes YesConnection confidentiality Encipherment Yes Yes Yes YesTraffic flow confidentiality Encipherment Yes Yes Yes Yes

Connection integrity Encipherment Yes Yes Yes YesConnectionless integrity Encipherment Yes Yes Yes YesNon-repudiation, origin Digital Signature No No Yes Yes

Non-repudiation, delivery Digital Signature No No Yes Yes

Table 4.7: Comparison Based on Security Services Required

4.4.2 Based on Performance

The location of the processor where the comparison of the policies takes place, and the

amount of communications required, are the key factors thatcontribute to the overall

performance of the proposed mechanism. Based on processing, the best approach

would be either the network operator or the location server acting as proxy server. The

next best approach would be the server centric approach where the ASP processes the

user policies. Client centric approach is not suitable as the thin client is expected to

take many resources for the required task to be accomplished.

Based on the number of connections required, the best approach would be the net-

work operator based approach as the number of intra-domain wired connections re-

quired is less than with the location server proxy based approach. The server centric

approach and the client centric approaches will take a lot ofresources which will in-

crease proportionally as the user searches different ASPs to choose the service provider

matching the user policy.

4.4.3 Based on Trust

The level of trust between the various entities in each approach is aggregated and

presented in Table 4.8. The trust analysis is not a complete and a foolproof analysis.

This was carried out to provide an understanding of the trustlevels in various methods.

Based on the table, the least amount of trust required is in the client centric approach

followed by the server centric approach. The network operator centric approach and

the proxy server based approach need a greater level of trust. This can be provided with

the help of non-repudiation. The network centric approach is better than the location

server centric approach as the level of trust required between the various entities is

4.5. Conclusion 67

low compared to the location server based approach, while the average level of trust

in the network, operator centric approach is greater. Thus the network operator centric

ClientCentric

ServerCentric



No Trust(-) 7 7 7 5Low Trust (*) 4 4 1 5

Average Trust (**) 5 4 5 4High Trust (***) - 1 2 2

Table 4.8: Comparison Based on the Level of Trust Required

approach is best suited for the location based services as itcan provide all the required

services and the performance is better than the other three mechanisms. The next best

approach would be the location server centric approach. Theclient centric approach

does not provide the required security and there is lot of processing capacity required

though the level of trust required is less. The server centric approach requires a greater

amount of trust that can only be provided by repudiation and the approach does not

support this security service. In addition, the amount of computation required is greater

than the network server proxy approach and the location server centric approach.

ClientCentric

ServerCentric



Security services Bad Bad Good GoodPerformance Bad Bad Very Good GoodProcessing Bad Fair Good Good

Trust Very Good Fair Good Fair

Table 4.9: Overall Comparison

4.5 Conclusion

Based on the preliminary analysis carried out it was observed that the proxy approach

is suitable for heterogeneous location networks. The best approaches suitable for the

current mechanism according to the issues considered are shown in Table 4.9. It

has also been observed that in most of the real-time scenarios the network and the

location server act together. Given the greater security advantage in the location server

based proxy approach and the limited privacy requirements for security applications,

the location server can act as a proxy for these applications. The network operator

based approach is best suited for all other location applications.


Since the design varies only in the means of providing the location information

to the ASP, we start our design for a network operator centered proxy architecture

and then propose modifications to suit the mechanism for security-based applications

in the later stage of the thesis. In the next chapter, we design secure protocols for the

framework. In addition, in this chapter, the protocols are integrated with the framework

and a post analysis of the overall architecture is carried out.

Chapter 5

Heterogeneous Location Architecture

The results of the preliminary analysis carried out in chapter 4 resulted in a section

of the heterogeneous location framework. The framework is just an overview of the

architecture. The next important stage is the design of the communication protocols.

The protocols need to meet two key requirements:

1. protocols should be secure and assure user and data privacy, and

2. protocols need to be lightweight as they are designed for mobile wireless combi-

nations and the communication between the various entitiesneed to be fast and

efficient.

The designed lightweight cryptographic protocols for the heterogeneous location

architecture need to be technology independent and have theability to operate across

multiple vendors without any restrictions on the security or computational capability

of the supporting device or operating infrastructure.

In this chapter, we design a new Key distribution and lightweight communication

protocols for the proposed framework. We integrate the protocols and the framework

resulting in the heterogeneous location architecture. A detailed analysis of the security

and computation is also carried out to verify if the architecture addresses the require-

ments presented in section 4.1.

69

70 Chapter 5. Heterogeneous Location Architecture

5.1 Overview of Framework

An overview of the framework is illustrated in Figure 5.1. The framework assures

location privacy in heterogeneous environments and accommodates the requirements

of small devices with limited computational power. The computations take place at

a proxy location with enough resources. Because the networkoperator can perform

complex computations and has access to user personal information, such as addresses

and billing information, the network operator is suitable to act as a proxy server.

user

Network operator

Location server

ASP

Policy storage

database

1. Give the privacy preferences of the user

(offline)

2. Register the policies with the network operator

(offline)

3.Store the user policy and ASP policies in the database (offline)

5. Check the user policies with the user policies and provide the list of service

providers

4.Request for a service

6.Provide the user with the list of suitable ASP

7. Send a request to the ASP with the policy

8. Send the copy of the accepted policy

9. Request for location

11. Provide the location of the user



Figure 5.1: Overview of Framework

The various steps involved in the process are:

1. The user registers the preferred privacy policy to the network operator.

2. The ASP’s register the preferred privacy policies with the network operator.

3. When the user requests a service to the network operator, the network operator

compares the user policies to the policies of the ASP’s.

4. The network operator provides the user with the list of ASP’s that match the

user’s preferred privacy policy along with the minimum and maximum granular-

ity of location information required for the application tothe user.

5. The user then selects an ASP for providing the service.

6. The ASP sends a copy of the accepted privacy policy to the user along with a

request for the location information.

7. The user requests the location server for the location information of the chosen

granularity.

5.2. Protocols for the Framework 71

8. The user then sends the location information to the ASP andthe ASP provides

the requested service to the user.

5.2 Protocols for the Framework

The typical methodology for achieving security for communications is to first establish

a session key, then encrypt all the subsequent messages withthe session key. In open

systems, public key cryptography is preferred for establishment of session keys due to

the simplicity in key management. The computational limitations of a mobile wireless

environment restrict the use to symmetric key cryptographyat the user side.

Based on the trust analysis carried out in Table 4.8 it can be assumed that there

exists considerable trust between the user and network operator. There is also a long-

term secret key shared between the user-network operator and the user-location server.

The network operator and the application server have enoughresources to perform

public key cryptography. The assumptions currently exist and are practical in nature.

Considering the need for the design of a secure architecture, it was established that

secure protocols are required. The accepted approach to theproposed mechanism is

to present the proof of security which is essential for structural correctness of new key

establishment protocols. The security proofs are long and difficult to read for the non-

specialist, making them more error-prone [61]. Another shortcoming is that a minor

change in the protocol requires a complete revision of the proof. To mitigate these

problems we use a modular approach for provable security proposed by Canetti and

Krawczyk [17]. This model is referred to as the CK model.

The model provides reusable building blocks for construction of new provably se-

cure protocols. More precisely, a module carrying a security proof can be reused for

construction of new secure protocols with other modules in the model that have been

proved secure independently. Despite all advantages of theCK approach, there exist

only a limited number of modules in different layers. With limited number of reusable

modules, the full power of the CK approach cannot be seen. By increasing the num-

ber of reusable modules, secure protocols with different requirements can easily be

constructed.

The proposed architecture requires a three-party key transport protocol involving

the network operator generating the session key. The session key is sent to the user

who shares a long-term secret key with the network operator,and then forwarded to

the ASP capable of computing public key algorithms. From theexisting library of


reusable modules, there was no suitable module in the CK approach to address these

requirements. Furthermore, there exists no suitable protocol in the literature of se-

cure protocols for this particular requirement. The lack ofa suitable candidate in the

reusable modules, led to the design of a new secure authenticated key transport proto-

col with three parties. The newly designed protocol was thenintegrated with the rest

of the secure protocols that used the existing library of reusable modules.

5.3 Design of provably secure 3PKD protocol

A detailed discussion on the design of secure protocols using the CK model and the

effectiveness of the same is presented in Chapter 3.3.1. Themajor steps in the design

of the secure protocols are as follows,

• Design of the protocol and proof that the protocol secure in the Authenticated

links Model (AM)

• Design of MT authenticators and proof of the validity of the authenticators.

• Application of the MT authenticator to the basic protocol. The resulting protocol

is thus secure and can be used in the real world environment.

The proofs for security for the proposed protocols are presented in Appendix A.

The proofs provide with the ability to analyse the security of the proposed protocols.

This section briefly provides the overview on the design of the 3PKD. The various

notations used in the protocol are presented in Table 5.1

5.3.1 A New Protocol Secure in the AM

We propose a key distribution protocol in the AM where two parties use a trusted server

(network operator) for session key generation. This protocol uses both symmetric and

asymmetric encryption.

In determination of the mechanism for setting up the sessionkey, we consider two

links: the link between the users and the network operator and the link between the

network operator and the ASPs. Since users in mobile networks share a long term se-

cret key with the network operator for basic telecommunications services, it is natural

to use a symmetric key encryption scheme on this link. It is also the best choice for

the users due to the constraints in computation of mobile devices. On the link between

5.3. Design of provably secure 3PKD protocol 73

Entities

U client requesting the service (User)S Network operator who is acting as a proxyA Application service providerLS Location server

KeysEi−j Symmetric encryption with secret key betweeni andjEi Asymmetric encryption with public key of entityikUS Long term secret key betweenU andSeX Public Key ofXdX Private key ofXσ Session key generated by the key generatorEk(m) Encryption of some messagem under keykDk(c) Decryption of some ciphertextc with keyk

ElementsSigi Signature generated by entityir i Random number generated by entityiH Hash function

MACki−j Message Authentication code generated by using symmetric key of i andjPriASP(i) Privacy policy of the ASP for applicationiPriUser Privacy policy of the user

AppName Name of the application along with minimum and maximum granularityGranReq Granularity of location information required by userLocInfo Location information of requested granularity

ReqService Service requested by the userSID Session identifier

Table 5.1: Protocol Notations

the network operator and the ASPs, we use an asymmetric key encryption scheme. We

have two reasons for this decision; (1) it is reasonable to assume that both the network

operator and the ASPs are capable of running computationally intensive algorithms,

and (2) it is difficult to securely distribute long term secret keys to all ASPs, thus lim-

iting the use of symmetric encryption schemes on this link.

Let Sbe the network operator,U be a user andA be an ASP. The sequence of the

communications link is:U → S→ U → A. Note that the link between the network

operator and the ASPs has been broken down to two links whereU relays messages

from S to A. This setting allows the users to choose different ASPs based on their

preferences.

Assume thatU shares a long term secret keykUS with S. Let eX be the public and

dX be the private key of partyX. The session key is encrypted with the long term secret

key shared betweenU andS. On the link betweenA andS, public key cryptography

is employed. Letσ be a session key generated by the key generator. We denoteEk(m)

to be encryption of some messagem under keyk. Similarly,Dk(c) denotes decryption

of some ciphertextc with key k. The protocol is shown in Figure 5.2. The proof of

security for the proposed protocol is presented in AppendixA.1.


S U A

σR← Sn(1κ)

µUR← EkUS(σ)

µAR← EeA(σ)

A, s, µU−−−−→U, s, µA−−−−→

U, s, µA−−−−→σ′ ← DkUS(µU) σ′′ ← DdA(µA)

Figure 5.2: The Protocol 3PKD

Remark1. We note the importance of the session identifiers. It is used to match con-

current sessions running by protocol participants, thus its value must be unique such

that probability of the appearance of the same value twice isnegligible. A practical im-

plementation for uniqueness of the session identifier is to enforce contributionss1, s2

from both parties. Each party then knows that the session identifier is fresh and unique

as their individual inputs form part of it. z

5.3.2 New Authenticators

The next step in the design of the protocols using the CK approach is the construction

of a new authenticator that transforms a protocol secure in authenticated networks to

a protocol secure in unauthenticated networks. The construction combines an existing

MT-authenticator with a new proposal of its kind. An MT-authenticator is the funda-

mental building block of a full-fledged authenticator and transforms a single message

flow of a secure protocol in the AM to an authenticated one in the Unauthenticated

limits Model (UM).

A Non-Interactive Signature Based MT-Authenticator

We propose a signature based MT-authenticatorλTimeSig that uses time stamps to pro-

vide freshness. In contrast to the original signature basedMT-authenticator [10], our

new MT-authenticator results in only one message in the UM for every message to be

authenticated.

Using time stamps for freshness requires synchronisation in time. In practice,

maintaining synchronisation in time is extremely expensive and is not used for commu-

nications between clients and servers. Thus, we need to accept “loosely synchronised”


A B

SigA(m, ΥA, B)−−−−−−−−−→

Figure 5.3: Signature Based MT-Authenticator Using Time Stamps

times for the scheme to be practical. In addition, the time stamp is required to be

unique. The uniqueness is maintained by the procedures for signature verification.

Time stamps could be in different formats [54, 60], but we provide an abstract

formulation for our needs. We assume that there exists a secure time serverT S which

we model as a universal time oracle available to all parties.All parties access this

oracle whenever a time stamp is required. We also assume thatthere exists a boolean

functionV which returnsTRUE or FALSEon input of a time stampΥ. If it returns

TRUE, then the time stampΥ is fresh. Otherwise,Υ is expired. Note that this function

may make decisions based on some “looseness” in time if necessary.

Let I be an initialisation function which invokes, once for each party, the key

generation algorithm of a signature scheme secure against chosen message attacks with

security parameterκ. Let SigandVer denote the signing and verification algorithms.

Let ski andpki be the private and public keys of a partyPi where all public keyspki are

known by all other parties. WheneverPi needs a time stamp, it asks the time oracle

T S(·) for a time value.

The MT-authenticatorλTimeSig is activated within some partyPi with an external re-

quest to send a unique messagem to partyPj. ThenλTimeSig invokes a two-party protocol

λTS that proceeds as follows. SinceλT

S involves only two parties, we useA andB for

their identities. PartyA sends ‘signature:SigA(m, ΥA, B)’ to B and outputs ‘A sent

message m to B’. When ‘signature:SigA(m, ΥA, B)’ arrives at partyB, B acceptsm

if the signature issuccessfully verifiedas described below. Ifm is accepted byB, B out-

puts ‘B received m from A’. This type of transmission is captured in Figure 5.3. The

security proof to show that the protocolλTimeSig is a valid MT-authenticator is presented

in section A.2.

Remark 2. Our representation in Figure 5.3 is not intended to restrictthe varieties of

signature schemes that could be used. In fact, what is required is thatB can recover

the contents of the signature upon receiving it. This could be implemented by sending

a copy of the contents in the clear or by using signature schemes with recovery where

appropriate. z

For ensuring the security ofλTimeSig , B needs to maintain a listL of received and


accepted messages by all instances run byB. PartyB maintains this list with two

operations, namely insertion and deletion of records. Letn be the maximum number

of records inL. A recordl i∈{1,...,n} = (m′, Υ′A) is added toL whenm′ is accepted byB

such thatB outputs ‘B received m′ from A’. The recordl i is removed fromL when its

associated time stampΥ′A has become invalid.

Upon receiving the messageSigA(m, ΥA, B) from A, partyB proceeds to execute

the signature verification procedures as follows. FirstlyB recovers(m, ΥA, B) from

the signature and searches for an identical time stamp from its list of recordsL. If an

entry is found, thenm is rejected. If not,B verifies the signature using the signature

verification algorithmVerpkA(m, ΥA). If the signature is invalid, thenm is rejected.

Otherwise, a new time stamp is freshly generated.

Remark 3. Instead of using time stamps for freshness for our new MT-authenticator,

we can use counters. Replacing time stamps with counters is straightforward [52] and

the resultant MT-authenticator is also non-interactive. The security proof ofλTimeSig can

easily be modified to suit the MT-authenticator that uses counters. The main difference

in the proof is the mechanism used to verify freshness of messages. z

From MT-Authenticator to Authenticator

The new MT-authenticatorλTimeSig can be made into a full-fledged authenticator in the

following manner. Letλ be an MT-authenticator that emulates a message transmis-

sion protocol (MT) in unauthenticated networks. Then a compiler Cλ, which takes a

protocolπ as input and outputs a protocolπ′, can be constructed as follows. Upon

activation ofπ, Cλ invokesλ for transmission of messages ofπ. More specifically,

whatever operations related to message transmission performed inπ, λ is activated to

do the emulated operations inπ′.

Theorem 1. Letλ be an MT-authenticator such thatλ emulates message transmission

MT in unauthenticated networks, and letCλ be a compiler constructed based onλ as

described above. ThenCλ is an authenticator.

Depending on the number of message flows in the AM, a full-fledged authenticator

can be a combination of MT-authenticators. If there is a single message flow in the

AM, a MT-authenticator is sufficient to be used as an authenticator. Otherwise, two or

more MT-authenticators need to be combined for transforming different message flows

in the AM.


A Bm−→

m, NB←−−−

m, MACkAB(m, NB, B)−−−−−−−−−−−−−−→

Figure 5.4: MAC Based MT-Authenticator

S U A

rU ∈R {0, 1}κ

←−−−−−−−−−mU, MACkUS(mU, rU, U),

SigS(mA, ΥS, A)−−−−−−−−−−→

SigS(mA, ΥS, A)−−−−−−−−−−→

Figure 5.5: A Full-Fledged Authenticator

As an example for generating a full-fledged authenticator totransform a two-

message AM protocol to a protocol secure in the UM, we recall aMAC-based MT-

authenticator of [18] and combine it with our signature-based MT-authenticator using

time λTimeSig . Other types of MT-authenticators exist, but the choice ofλMAC is suitable

to satisfy the unique requirements of the AM protocol of Figure 5.2. The MAC-based

MT-authenticator is shown in Figure 5.4 and is referred to asλMAC hereafter.

We combine the MT-authenticatorsλMAC andλTimeSig for secure transformation of pro-

tocol 3PKD. It is also applicable to other AM protocols with two message flows with

the respective computational requirements. The full-fledged authenticatorCλMAC

λTimeSig

is il-

lustrated in Figure 5.5.

5.3.3 Secure Protocols in the UM

We demonstrate the applications of our new modules in the CK model . UsingCλMAC

λTimeSig

,

we show that protocol 3PKD of Figure 5.2 can be compiled into asecure protocol

in the UM. More precisely, we compile our new three-party keydistribution protocol

3PKD of Figure 5.2 withCλMAC

λTimeSig

to obtain a secure key distribution protocol in the

UM. We denote byΥS ← T S the action thatS obtains a time from the time server

to generate a time stamp. Leta || b be the concatenation ofa andb. The resultant

secure protocol following the above procedures is shown in Figure 5.6 and is named

3PKDUM.


S U A

rU ∈R {0, 1}κ

←−−−−−−−−−

σR← Sn(1k)

µUR← EkUS(σ)

µAR← EeA(σ)

ΥS← T Ss = rU || ΥS

A, s, µU, MACkUS(A, s, µU, rU, U)−−−−−−−−−−−−−−−−−−−−−−→

SigS(U, s, µA, ΥS, A)−−−−−−−−−−−−−→

SigS(U, s, µA, ΥS, A)−−−−−−−−−−−−−→

Figure 5.6: A Key Transport Protocol Secure in the UM

The session identifiers in 3PKDUM is a simple concatenation ofrU andΥS. The

ASPA gets assurance of freshness because the checking process ensures that no time

stamp is accepted twice. Even thoughU does not check the freshness ofΥS, and

A cannot check the freshness ofrU, the combination of these values is unique. In

practice, of course, only one copy of each value is required.

5.4 Synthesis of Framework and Protocols

We design the protocols for the rest of the framework and integrate the proved secure

3PKD protocol to the proposed framework thus resulting in a secure and privacy as-

sured heterogeneous architecture. The protocols are explained in detail in each stage.

The notations used in the protocols are shown in Table 5.1.

The major steps in the proposed framework are:

• configuration and registration of the privacy policy by the user,

• registration of the privacy policy by the ASP,

• request for service and establishment of secure session,

• request for location from location server, and

• providing the requested service.

5.4. Synthesis of Framework and Protocols 79

User(U) NetworkOperator(U)PriUser−−−−−→

Figure 5.7: Registration of Privacy Policy by the User

5.4.1 Configuration and Registration of User Policy

In this stage the user configures the preferred privacy policy and sends the policy to

the network operator. The policies are written to the current W3C standards for P3P

using XML. The policies are sent to the network operator. Thenetwork operator stores

the user policy in the database. The protocol for the registration of policy is shown in

Figure 5.7.

The configuration of policies can take place in any environment the user is currently

operating in. The user policies can be configured in the desktop and transferred to the

network operator. The mobile device can send the policy to the network operator and

the network operator stores the user policy. Alternatively, services like ‘Over-The-

Air-Service-Provisioning’ (OTASP) can be used to configurethe user policy on the

web and then update these policies to the user and in the process update the network

operator. OTASP is the ability of carriers to add new types ofservices to a customer’s

handset by using the wireless network instead of requiring the customer to bring the

phone to a carrier’s location for reprogramming. OTASP is a RFC standard from the

internet society [42].

5.4.2 Registration of Privacy Policy by the ASP

The ASP has to register the preferred privacy policies. Eachapplication requires varied

granularity of information. For example, an emergency based application requires the

exact location of the user. Where as for a directory service it may be just sufficient

to just specify the region the user is located. Thus, a singleprivacy policy will not be

sufficient for all the applications that the ASP wants to provide. The policies have to

be application specific, as the location information will beused according to the nature

of application and the granularity of location informationrequired. When there is a

change in the policy for a specific application or if the ASP terminates service to a

specific application then the changes can be easily updated without changing the full

privacy policy. This approach gives better management of the user information. The

protocol for the registration of the policy by the ASP is shown in Figure 5.8.


NetworkOperator(s) ASP(A)SigASP(PriASP(AppNamej))←−−−−−−−−−−−−−−−−−−−

Figure 5.8: Registration of Privacy Policy by the ASP

There is also a need for non-repudiation between the ASP and the network oper-

ator. This property assures that the ASP adheres to the stated privacy policy and if

the ASP deviates from this, the user can hold the ASP accountable for a breach from

the stated privacy policy. To achieve this property the privacy policy of the ASP is

signed by the ASP’s private key. The higher computation capability between the ASP

and the network operator helps in the use of public key encryption mechanism. For

every application that the ASP provides service, the privacy policy will adhere to the

requirement of W3C standard for P3P. The privacy policy of the application will also

include the name of the application, validity of the policy,minimum and maximum

granularity of location information required for the application and date of creation of

privacy policy.PriASP(AppNamej) is the privacy policy of the application wherej = 1

to n represents the number of the applications the ASP intends toprovide.

The network operator stores the policy of the ASP in a database. If the ASP changes

a policy for a specific application then the ASP is required toreport the change in the

policy for the application. The network operator updates the privacy policy of the ASP

for the specific application after it receives the new policyfrom the ASP. The network

operator will always adhere to the privacy policy signed by the ASP. It is thus the

responsibility of the ASP to report the changes in the privacy policy as and when the

changes take place.

5.4.3 Providing the Requested Service

Service provisioning is an important stage of the proposed framework. We use the

3PKD protocols designed in subsection 5.3.3 and integrate them to fit the required

objectives of the proposed framework. In this stage, a list of service providers suitable

for the requested application is provided to the user by the network operator. Also the

network operator generates session keys for communicationbetween the user and the

ASP to provide the requested service. Figure 5.9 describe the process.

The various steps in the protocol are as follows:

1. The user requests the network operator for a suitable ASP matching the user’s

preferred policy for an application.


2. The network operator compares the user policy to the privacy policy of vari-

ous registered ASP for the requested application and computes the list of ASPs

matching the users preferred policy.

3. The network operator then generates the session keys for communication be-

tween the ASP and user. For all the ASPs that match the user policy a separate

session key is generated. The session IDSID is the concatenation of the time

stampΥS and random numberrU. The network operator then encrypts the gen-

erated session key with the public key of the corresponding ASP. The network

operator also encrypts the corresponding session key with the long term shared

key between the user and the network operator. A message authentication code

of the encrypted key, session identifier, a random number sent during the re-

quest, the ASP and the network operator identities is generated by the network

operator. The network operator also signs the session keys generated for the

ASP with the network operator secret key. The signature contains the session

key, a time stamp, session identifier, the identity of the user, network operator,

ASP and the privacy policy of the ASP for the requested application. The sig-

nature is encrypted with the public key of the correspondingASP. This assures

that an adversary cannot find the identity of the user and the accepted policy by

eavesdropping and looking into the information contained in the signature.

4. The network operator then sends the user the list of ASPs and the privacy policy

of the ASP containing the minimum and maximum granularity required to pro-

vide the requested service. With this, the network operatorsends the generated

session keys for the ASPs. The message is encrypted with a long-term secret

key agreed between the user and network operator. This key isdifferent from

the secret key used for generation of MAC and encryption of the session key.

The subscripti indicates a value in the list of all the ASPs sent by the network

operator to the user.

5. The user then chooses a suitable ASP from the given list andsends the encrypted

package generated by the network operator containing the signed session key and

accepted policy as a request to the ASP to provide the requested service.

This important stage provides the ability for the user to choose the service provider

that the user feels is safe and trustworthy. Also it providesthe ability to the user to

decide the granularity of information that needs to be provided. The generation of

session keys by the network operator for communication between the ASP and user


NetworkOperator(S) User(U) ASP(Aj)rU, AppName←−−−−−−−−

σ ∈R {0, 1}k

EU−S{Ai, σ, SID, MACU−S(Ai, SID, σ, rU),PriASPi(AppName), EA0 i{SigS(U, SID, σ,

ΥS, Ai, PriASPi(AppName))}−−−−−−−−−−−−−−−−−−−−→

i=(1..l)}

User choosesAj = Ai

EA{SigS(U, SID, σ, ΥS, Aj ,PriASPj(AppName))}−−−−−−−−−−−−−−−→

Eσ{PriASPj(AppName)}←−−−−−−−−−−−−−−−−−

Figure 5.9: Protocol for Selection of ASP by User and Establishment of Secure Com-munication between the User and ASP

helps in saving a large amount of computation resources at the user device. Once the

ASP gets the package, the ASP decrypts the package, checks the privacy policy and

generates the session key for the communication between theuser and ASP. The ASP

then sends an acceptance to the user. The acceptance contains the privacy policy sent

by the user and is encrypted with the session key generated bythe network operator.

The user decrypts the acceptance, verifies the privacy policy sent by the ASP and sends

a request to the location server to provide the requested location information.

Note that the session keys generated in the protocol are independent and do not

require the participation of the ASPs. This independence from the ASP participation is

useful in preserving the choices of ASP made by the user. Assume that there exist three

ASPs (A,B,C) providing a service for a requested application and the user has decided

to choose A for providing the requested service. Before receiving an explicit request

from the user, none of the ASPs (A,B,C) know about the user andremain passive. After

receiving a request, only A knows about the user. This enhances the privacy of the user,

as the preferred policy of the user remains undisclosed to the service providers, thus

stopping service providers from changing policies to matchuser privacy preferences

on the fly.

5.4.4 Request for Location from Location Server

The location server derives the user location information by collecting the location

information from a number of ASPs. The user and the location server share a long-

term symmetric key for establishment of secure communication between them. This

long-term secret key is used for secure communication between the user and location

server. The user sends a request for location information containing the user identity,


User(U) LocationServer(LS)EkLS−U{rU, GranReq, U}−−−−−−−−−−−−−−−−→

EkLS−U{GranReq, Locinfo, ΥLS

MACkLS−U(rU, GranReq, Locinfo)}←−−−−−−−−−−−−−−−−−−−−−−−

Figure 5.10: Request for Location by User

the granularity of information required and a random number. The location server

responds by sending the location information of the requested granularity. To assure

the freshness of the location information a time stamp is used. The location server also

generates a MAC of the random number, the location information and the granularity

requested. The key for the generation is different from the key used for the long-term

secret key between the user and location server. This is essential, as the compromise

of one of the keys must not lead to the compromise of all subsequent communications.

The user then decrypts the information with the shared secret key. The user checks for

the freshness of the information from the time stamp and generating the MAC. The

protocol is described in Figure 5.10. Alternatively, OMA’slocation protocol can also

used for obtaining the location information from the location server.

5.4.5 Providing the Requested Service

The user decrypts the information sent by the location server and, after the validity

of the location information and confirmation that the requested location information

is of the requested granularity, sends the information to the ASP. The ASP then uses

the information supplied to provide the service requested by the ASP. After the service

is provided the session is terminated and the session key that is used is destroyed. A

fresh key is generated if the user needs to request another application from the ASP.

The protocol is described in Figure 5.11.

User(U) ASP(A)Eσ{Locinfo, A, U, ΥLS}−−−−−−−−−−−−−−−−→

Eσ{ReqService}←−−−−−−−−−−−

Figure 5.11: Providing the Requested Service


5.5 Comparing the Heterogeneous Architecture to the

Requirements

Analysis of the designed framework is carried out by comparing the proposed frame-

work to the requirements described in section 4.1. We verifyrequirements achieved

and issues that need to be explored further to achieve the goal of a secure and privacy

assured heterogeneous location architecture.

5.5.1 User Requirements

In the proposed framework the network operator provides theuser a choice of ASPs

matching the user preferences. Figure 5.9 shows that the network operator sends

the user a listi containing the service providers. This provides the user the ability to

choose a suitable service provider. Since it is a legislative requirement for the network

operator to provide a framework for fair competition the network operator is bound to

give equal preferences to all service providers.

Since the privacy policies contain the minimum and maximum preferences for each

application required by a service provider, and these are within the requirements stated

in user preferences, the user can choose the service provider and give the granularity

of location information according to the user’s choice. Theprivacy policies of the user

and the network operator need to be similar to P3P thus allowing the easy update of

policies. Though the framework does not discuss the issue ofprivacy policy language,

this is part of work currently being carried out.

5.5.2 ASP Requirements

Although this is more of a policy and legislative requirement, the property of non-

repudiation for the policy information originating from the ASP provides a mechanism

to hold the ASP accountable when the ASP deviates from the stated policy. Non-

repudiation is provided by the signing of the privacy policies by the ASP as shown in

Figure 5.8. Though existing government legislations require the ASP to seek explicit

authorisation before providing the information to a third part there is no mechanism in

the proposed framework to address this issue.

5.5. Comparing the Heterogeneous Architecture to the Requirements 85

5.5.3 Network operator Requirements

In the current architecture the network operator needs to provide the user with a choice

and it is the decision of the user to choose the service provider. Though this does

not assure that the network operator is acting impartially,the mechanism provides a

means to choose the service provider and the granularity of information thus giving the

flexibility to the user to get a satisfactory service. The framework provides a means to

assure fair competition among all service providers whose privacy preferences match

the user preferences.

5.5.4 Location Server Requirements

Since the information is derived from multiple sources and the location data set is

created based on the location derived from various sources any discrepancies in the

location information can be easily observed. The time stampassures the freshness of

the location information. The time stamp contains the current time and the time the

location was derived thus enabling the user to check the freshness of the information.

The MAC generated with the random number sent at the initial request also further as-

sures the location information is not replayed from an adversary. This can be observed

from Figure 5.10. Since the information is sent to the user and the user then forwards

the information to the service provider, the user can verifythat the information is of

the requested granularity. Figure 5.11 describes this process.

5.5.5 Government and Legislative requirements

The proposed architecture does not address this requirement currently. We believe

that the location server will have the ability to provide thelocation information to the

government agencies for homeland security and emergency services as per the existing

rules and regulations.

5.5.6 General Requirements

The user does not disclose his preferred privacy policy to the ASP. The ASP can only

know that the user’s preferences match the ASP preferences.In addition, since the

privacy policy varies with the applications chosen by the user, the ASP providing the

service will only be able to know the preferences for the application requested by the

user.


The processing of the policies takes place at the location ofthe network operator

and the protocols designed are lightweight. Figure 5.12 provides more details on the

computational requirements of the proposed framework. Thepolicies designed are

expected to be in XML and similar to P3P policy to meet the WAP-W3C requirements

and thus can be expected to be easily imported and exported across networks. These

are policy requirements that are currently not addressed bythe framework.

Registration of user

Registration of ASP

Providing requested service

Request for location

Providing requested service

Cryptographic operations

U S S A U S A U LS U A Public key encryption - - - - - n* - - - - - Public key decryption - - - - - - 1 - - - - Digital signature - - - 1 - n* - - - - - Signature verification - - 1 - - - 1 - - - -

Symmetric key encryption/decryption

- - - - 2 1 1 2 1 1 1

Hash Function - - - - n* n* - 1 1 - - Key generation - - - - - n* - - - - - * where n is the number of ASP the server sends for the user to choose from

Figure 5.12: Number of Cryptographic Operations Required

5.5.7 Security Requirements

Mutual end-point authentication

Authentication between the user-network operator and user-location server is very im-

portant in the proposed architecture. The required authentication between these entities

can be provided by the use of existing infrastructure. Communication between the user

and the service provider takes place after the establishment of the session key and thus

is secure. Authentication override is possible as the location server is independent of

the user.

Data Integrity

Data integrity is required for all communication between the participating entities. The

use of Message Authentication Code (MAC) assures that the integrity of communica-

tions taking place between the user-network operator and user-location server. The use

of signature based authenticator for transmitting the session key between the user and

5.5. Comparing the Heterogeneous Architecture to the Requirements 87

ASP along with the time stamps assures the integrity of the session key and in turn, the

integrity of information between the user and ASP is protected. Thus, the integrity of

the information is assured between all the communicating entities.

Data Confidentiality

There are three types of important information that need to be secure between the

entities:

1. user location information between location server and user,

2. session key to be used for communication between the user and ASP generated

by network operator, and

3. communication between the user and ASP.

The long-term key agreed between the user-network operatorand user-location server

respectively assure the confidentiality of communication between the user-network op-

erator and user-location server. The session key for communication between the user

and ASP is generated by the network operator and signed by theprivate key of the

network operator. The signed session key is then encrypted with the long-term public

key of the ASP by the network operator. Thus any compromise inthe session key will

lead to the loss of integrity of the key and thus the ASP knows the key has been com-

promised. The ASP can ask for a rerun of the protocol for establishment of new keys.

The time synchronisation between the various entities and the time stamp assures the

freshness of the session key. The long-term key, agreed between the user-network op-

erator and user-location server assures the confidentiality of communication between

the user-network operator and user-location server respectively.

Additional Functional and Security Requirements

Section 6.2 in the framework specifically states that the privacy policy of the ASP

need to be application specific and the privacy policy shouldcontain the minimum

and maximum granularity required for each application to function. In addition, the

service providers to a user are selected based on the privacyrequirements of the user

to a specific application.


Non-repudiation with Proof of Origin

From Figure 5.8 it can be observed that the ASP signs the preferred privacy policy

and sends this to the network operator. This signed privacy policy provides the non-

repudiation with proof of origin from the ASP.

5.6 Conclusion

The light weight protocols ensure the security and privacy of location information in

heterogeneous environments. The architecture provides a means for assuring privacy

addressing most of the requirements posed by various research groups. This work also

resulted in a novel light weight three party key distribution protocol, which uses both

symmetric and asymmetric key distribution mechanisms. Based on the analysis in

section 5.5 it has been identified that there is a need for an access control mechanism

for assuring the privacy of user information when the information is shared between

multiple ASPs or multiple applications supported by a single ASP. The mechanism

needs to ensure that the privacy of the user is assured when the information is shared

between co-existing location based applications.

Chapter 6

Location Data Management

Management of user information is one of the key issues in protecting the privacy of

user’s. In a heterogeneous environment, location information is shared between var-

ious service providers based on the nature of the application being provided and the

granularity of the information required. Sharing of location information without proper

management may lead to the abuse of sensitive user information and user privacy may

be compromised as a result. Thus, there is a need for a well-analysed access con-

trol model for sharing of location information between various service providers and

between the various applications provided.

A formal security model is designed to protect the unintended revelation and shar-

ing of fine-grained user location information in a heterogeneous environment, reducing

the potential for information leakage. The model protects the privacy of users by us-

ing a simple access control mechanism for the management of user data. The proposed

model provides a mechanism to add and remove applications bythe application service

providers (ASP). The model is formally represented in Z and the Possum animation

tool was used to explore the functionality of the proposed security model

The need for uniform understanding of the model motivated use of formal specifi-

cation. There was also a need to test and verify the functionality of the model before

it can be incorporated into the location architecture. Thiscould not be done in a real

environment because the model was part of an architecture that was currently under

development. The model was thus specified using Z. Fuzz [86] was used to verify

the specification and the Possum interpreter [27] was used totest the functionality of

the proposed model. The use of formal mechanisms and verification tools helped us

89

90 Chapter 6. Location Data Management

to analyse the architecture and correct the vulnerabilities identified during the verifica-

tion.

6.1 Specification of Model

We briefly describe the proposed security model and the flow ofinformation in the

model. The proposed model describes how to add and remove thevarious services

provided by the ASP without diverging the location information of the user. As spec-

ified earlier each application requires a different level ofgranularity. When a service

provider provides two different kinds of application then the ASP has access to two

different granularities of location information. The ASP can then use this information

to precisely determine the location of the user. Thus, thereis a need for a well-analysed

mechanism to decide how the flow of information takes place during the addition and

removal of the service.

The lattice model specifies the flow of information between various receptacles.

Denning’s axioms on information flow form the basis for designing the lattice model

[33]. Sandhu unified the representation of the Bell-LaPadula model, the Biba integrity

model and the Chinese-Wall model using the lattice approach[83]. The work of

Sandhu points out that any model that follows the axioms proposed by Denning can

be represented by the lattice structure [82]. These effortsinspired the design of the

proposed model using the lattice structure.

The axioms proposed by Denning do not stipulate any mechanism that has to be

followed during the addition and removal of different security classes. We extend

these axioms to show the flow of information within each security class. We also

describe the flow of information during the addition of a security class and propose a

model that assures the confidentiality of the information while sharing the information

between the existing applications and the newly added application. We consider the

linear ordering on a set of security classes SC that satisfy the lattice model. It has been

shown by Denning that the lattice structure is suitable for any set of linearly ordered

security classes [33]. For the proposed model, there are only two elements in the

security class set: the minimum rights and the maximum rights. The information flows

from the minimum rights to the maximum rights.

6.1. Specification of Model 91

6.1.1 Description of Model

Let us suppose that an ASP intends to provide services to various users. The ASP has a

set of information receptacles N. These receptacles are thevarious entities participating

in the mechanism, which have access to the information aboutthe user. The various

entities (N) are the user, network operator, internal employee, and external employee.

These entities have rights to relay, request, block, initiate or store the information.

Every entity in an application has a minimum and maximum set of rights. An

application is a service that the user has requested from theASP. The minimum rights

are the most essential set of rights, which each entity must have for the application

to function. Each entity should have at least the minimum setof rights. Each entity

in an application is also assigned a maximum set of rights. Ifan entity exceeds the

maximum rights then the confidentiality of the information cannot be assured. Similar

to the application, the ASP has a set of minimum and maximum rights. These rights

of the ASP are dynamic and depend on the service the ASP wants to provide. The

minimum set of rights for the ASP initially is a null set and the maximum set of rights

for the ASP is the set of all available rights. Table 6.1 showsthe various state variables

used.

AppMinRights Minimum rights of the applicationAppMaxRights Maximum rights of the applicationASPminrights Minimum rights of the application service providerASPmaxrights Maximum rights of the application service provider

Setapps Applications for which rights have been fixedAddedapps Set of all applications that are added

Table 6.1: The State Variables

Let us now consider the flow of information in an ASP and the application. We

assume the ASP to be a security class and the flow of information between the security

classes is shown in Figure 6.1 and represented as follows.

SCASP = (ASPminrights, ASPmaxrights)

This means for the security class ASP the information flows from ASPminright to

ASPmaxrights. Similarly let the applications belong to another securityclass.

SCApp{j}= (AppMinRights, AppMaxRights)


The Flow of information with in each receptacles of the ASP and the

Application

ASPmin_rights

ASPmax_rights

ASP Application

AppMinRights

AppMaxRights

Figure 6.1: Flow of Information in ASP and Application Security Classes

wherej = 1 to n indicates which application the service provider intends to provide.

The rights assigned to the application remain static and it should not be possible to

change the rights of the application. This is critical for the functioning of the mech-

anism because it provides an assurance that the ASP cannot compromise the privacy

of the user by changing the rights of the existing application to provide the requested

service. Figure 6.1 shows the flow of information between theASP and applications.

Adding an Application

When the user requests the ASP to provide a service, the ASP has to verify whether the

requested service can be provided along with the existing applications without com-

promising the confidentiality of the user contextual information. In order to achieve

this objective the ASP has to ensure that certain conditionsare met. These conditions

control the uniform flow of information between various applications and in turn allow

uniform functioning of all the applications.

The key conditions that need to be satisfied are:

• the requested application is in the list of services the ASP intends to provide;

• the minimum rights for every entity in the ASP must be a subsetof, or equal to,

the minimum rights of the corresponding receptacle for the application that is

currently being added; and

• the maximum rights for every entity in the application is a subset of the maxi-

mum rights for the corresponding entity in the ASP.

This verification ensures that the ASP has the minimum required rights to offer

the service and the information does not flow above the current maximum rights of

the ASP. If the conditions are satisfied the ASP provides the user with the requested

service and adds the application to the set that the ASP is currently providing service


for. The ASP has to change the minimum rights and maximum rights because of the

addition of the new application. Thus, the modified minimum rights for each entity

in the ASP is the minimum rights for each entity in the ASP. Similarly the maximum

rights for each entity is the maximum rights of the entity in the application that has

been added.

The State of the application to be added

State of the ASP

ASPmin_rights

AppMaxRights

AppMinRights

ASPmax_rights

ASPmin_rights

ASPmax_rights

The changed state of the ASP after addition

an application

ASPmin_rights'

ASPmax_rights'

Figure 6.2: Information Flow WhenAdding an Application

The State of the application to be removed

State of the ASP

ASPmin_rights

AppMaxRights

AppMinRights

ASPmax_rights

ASPmin_rights

ASPmax_rights

The changed state of the ASP after removing

an application

ASPmin_rights'

ASPmax_rights'

Figure 6.3: Information Flow When Re-moving an Application

The various steps in the addition of an application by the ASPare as follows:

1. The State of the application to be added is determined. This is the minium and

maximum rights of the application to which the ASP intends toprovide service.

2. The ASP verifies its current state. This is the current Minimum and Maximum

rights all the applications provided by the ASP to the user requested the service

3. The ASP verifies if the required conditions are satisfied

4. If all the conditions are satisfied the service is providedto the user

5. The state of the ASP’s minimum and maximum rights is updated.

The flow of information after the addition of the applicationis shown in Figure 6.2.

It can be observed that when an new application is added to thelist of services that are

provided by the user, then the rights of the ASP have changed and a new set of mini-

mum rights is required for addition of any further application. It can be observed that

by the addition of a new application the information does notflow beyond the new

maximum rights of the ASP and thus assures the confidentiality of the user informa-

tion.


Removing an Application

If the ASP wants to terminate the service for a certain application then it must be able

to remove the application. This is important because this will facilitate the ASP to

provide service to other applications that could not be carried out previously. During

the removal of an application, the ASP should ensure that theprocess does not hinder

the functioning of other currently existing applications.

As with the addition of an application, during the removal ofan application the

ASP must meet certain conditions and follow a certain process. The minimum rights

of the ASP for each entity are modified to be the merger of all the existing rights of the

corresponding entities and the maximum rights of the service provider to be the sepa-

ration of all the existing maximum rights of the entity. Thiscriterion is used to assure

that the ASP goes back to the initial stage (the state before adding the application).

The various steps in removing an application by the ASP are asfollows:

1. The State of the application to be removed is determined.

2. The ASP verifies its current state.

3. The ASP removes the application from the list of services provided. The crite-

rion specified in the above section is used to update the stateof the ASP.

The proposed schema assures the confidentiality of the information when shared

between different applications by an ASP. Figure 2(b) showsthe of the information

when shared between different applications by an ASP. Figure 6.3 shows the flow of

information after removal of the application by the ASP. It can be observed that when

an application is removed then the system goes back to its initial state.

6.1.2 Formal Representation of Model

In this section, we formalise the proposed model using Z. Letthere be a set of applica-

tions that the application service provider (ASP) uses to provide services. These appli-

cations have a set of entities that have to know the contextual information to provide

the required service. The information in each application is shared between various

entities in the application. Each entity has a role and each role has certain rights as-

sociated with it. The entity can assume the roles of the user,network operator (NO),

internal employee (INTERNAL) or the external employee (EXTERNAL). The rights

specify the use of information by each role assumed by an entity. The various rights

are relay, request, block, store and initiate.


[APPLICATION]

The rights and roles of the entities are:

RIGHT ::= RELAY| REQUEST| BLOCK | STORE| INITIATE

ROLE::= USER| NO | INTERNAL| EXTERNAL

Allrights is the set of all rights.

Allrights : �RIGHT

Allrights = {RELAY, REQUEST, BLOCK, STORE, INITIATE}

State of Service Provider

We assign a minimum set of rights and a maximum set of rights for every role in the

ASP. The rights are assigned based on the kinds of applications the ASP supports and

the roles the application provides. The various schemas areInit, Set, AddandRemove.

In the Init schema we specify the initialisation of the model and the state is set to the

initial condition. TheSetoperation sets the various applications that the ASP provides

service for. TheAdd operation adds the applications that are set andRemoveis used

to remove the application that has been already added. Table6.1 above gives a brief

explanation of the various state variables used in the specification.

State

AppMinRights: ROLE× APPLICATION 7→ �RIGHT

AppMaxRights: ROLE× APPLICATION 7→ �RIGHT

Setapps: �APPLICATION

Addedapps: �APPLICATION

ASPminrights : ROLE"�RIGHT

ASPmaxrights : ROLE"�RIGHT

Initialisation of State

At the initial state, there are no applications sets and thusno application is added. Thus,

the maximum and minimum rights of the applications are null sets. The minimum right

for all the roles in the ASP is initially set to null. The maximum right for all roles in

the ASP is the maximum set of rights for the role.


Init

∆State

Setapps′ = {}

Addedapps′ = {}

dom AppMinRights′ = {}

dom AppMaxRights′ = {}

∀ r : ROLE• ASPminrights′(r) = {}

∀ r : ROLE• ASPmaxrights′(r) = Allrights

Setting the Applications

The service provider can set all the services for which it wishes to provide the ser-

vices after the initialisation. This helps to easily add andremove an application. The

condition to check if the application is already set avoids setting multiple rights for an

application. In particular, it must not be possible to change the rights for an applica-

tion that has already been added. The schema also stores the minimum and maximum

rights for all the roles in the application. One important condition that needs to be

verified is that the minimum rights of the new application is asubset or equal to the

maximum set of rights of the new application in the set schema. This is very important

for the information to flow from theAppMinRightsto AppMaxRights.


Set

∆State

app? : APPLICATION

newminrights? : ROLE"�RIGHT

newmaxrights? : ROLE"�RIGHT

app? 6∈ Setapps

∀ r : ROLE• newminrights?(r) ⊆ newmaxrights?(r)

AppMinRights′ = AppMinRights⊕

{(USER, app?) 7→ newminrights?(USER),

(NO, app?) 7→ newminrights?(NO),

(INTERNAL, app?) 7→ newminrights?(INTERNAL),

(EXTERNAL, app?) 7→ newminrights?(EXTERNAL)}

AppMaxRights′ = AppMaxRights⊕

{(USER, app?) 7→ newmaxrights?(USER),

(NO, app?) 7→ newmaxrights?(NO),

(INTERNAL, app?) 7→ newmaxrights?(INTERNAL),

(EXTERNAL, app?) 7→ newmaxrights?(EXTERNAL)}

Setapps′ = Setapps∪ {app?}

ASPminrights′ = ASPminrights

ASPmaxrights′ = ASPmaxrights

Addedapps′ = Addedapps

Adding an Application

During the addition of an application, the ASP needs to provide the name of the ap-

plication for which the service is to be provided. Firstly, the application must be set

and not already added. Secondly, the minimum rights for all roles of the ASP must be

a subset of the minimum rights of all roles for the application that is currently being

added.


Add

∆State

newapp? : APPLICATION

newapp? ∈ Setapps

newapp? 6∈ Addedapps

∀ r : ROLE• ASPminrights(r) ⊆ AppMinRights(r, newapp?)

∧ AppMaxRights(r, newapp?) ⊆ ASPmaxrights(r)

∀ r : ROLE• ASPminrights′(r) = AppMinRights(r, newapp?)

∧ ASPmaxrights′(r) = AppMaxRights(r, newapp?)

Addedapps′ = Addedapps∪ {newapp?}

Setapps′ = Setapps

AppMinRights′ = AppMinRights

AppMaxRights′ = AppMaxRights

This verification ensures the application that is added doesnot stop the existing

applications from functioning. Also the condition that themaximum rights of the

application for all roles is a subset of the maximum rights ofthe ASP checks if the

new application has more rights that can result in compromising the confidentiality of

the currently running applications. This ensures the confidentiality of the information.

If these pre-conditions are verified then the minimum rightsfor each role in the ASP

is set to be the minimum rights of the application. Similarly, the maximum rights for

each role is the maximum rights of the application.

Removing an Application

If the ASP wants to terminate providing any service then the ASP should be able to

remove the application. This will facilitate adding another application that could not

be previously added because of the existing application. During this process, it is

important that we remove only the explicit rights of the application to be removed.


Remove

∆State

old app? : APPLICATION

old app? ∈ Addedapps

Addedapps′ = Addedapps\ {old app?}

∀ r : ROLE• ASPminrights′(r) =⋃{X : �RIGHT | ∃a : APPLICATION•

a ∈ (Addedapps′) ∧ X = AppMinRights(r, a)}

∧ ASPmaxrights′(r) =⋂{X : �RIGHT | ∃a : APPLICATION•

(a ∈ (Addedapps′) ∧ X = AppMaxRights(r, a)) ∨ X = Allrights}

Setapps′ = Setapps

AppMinRights′ = AppMinRights

AppMaxRights′ = AppMaxRights

In the schema the ASP provides the application to be deleted.A check is performed

to verify if the application is in the set of applications currently being added. After this

checking, the application is removed from the set of added applications. The minimum

rights of the ASP for each role is modified to be the generalised union of all the existing

rights and the maximum rights of the service provider to be the generalised intersection

of all the existing maximum rights for each role. The proposed schema assures the

confidentiality of the information when shared between different applications by an

application service provider. The logic of the model is illustrated in the theorem below.

6.1.3 Proof of Security

Once a new application is added the minimum and maximum rights of the ASP are

changed and equal to the application’s minimum and maximum rights if these rights

are within the minimum and maximum rights of the ASP. The theorem assures that

when a subsequent application is added the minimum rights ofthe new application are

greater than the minimum rights of the ASP thus allowing the existing application to

function. In addition, the maximum rights are less than or equal to the existing rights,

thus assuring that the new application does not exceed the maximum allowable rights.

Therefore, the model assures that privacy is maintained. After the new application is

added, the maximum and minimum rights of the ASP are changed to suit the newly

added application. When an application is removed, the model assures that only the

required rights are removed and the termination of the current application does not


affect the privacy of the existing applications in ASP.

Theorem 2. The following invariant holds true for all states after the initialisation of

the system.

∀ r : ROLE, ∀a : APPLICATION•

ASPminrights(r) ⊆ ASPmaxrights(r) (6.1)

∧ a ∈ Setapps⇒ (AppMinRights(r, a) ⊆ AppMaxRights(r, a)) (6.2)

∧ a ∈ Addedapps⇒ (ASPminrights(r) ⊆ AppMinRights(r, a)

⊆ AppMaxRights(r, a) ⊆ ASPmaxrights(r)) (6.3)

Proof The proof will follow from showing:

1. After theInit operation the condition holds;

2. For each application, if the condition holds before the operation, it holds true

after the successful completion of the operation.

Since the system will not initialise when the pre conditionsfail,we implicitly assume

that failure of an operation due to the pre-conditions beingunsatisfied leaves the system

state unchanged.

Init: In theInit schema,Addedappsis null, and theAppMinRightsandAppMaxRights

are also null. Thus, the conditions are vacuously satisfied.

Set: Since theSetoperation leavesASPminrights, ASPmaxrightsand Addedapps

unchanged we only have to check Equation 6.2. But there is a precondition that

ensures Equation 6.2 is true for the new application set, while by assumption it is true

already for all other applications.

The set schema has the minimum and maximum rights for all roles in an appli-

cation, the ASP intends to provide service. TheAppMinRightsand AppMaxRights

remain Thus from the above it is true that the required condition is met before and

after the application is set.

Add: SinceSetappsis unchanged we only need check equations 6.1 and 6.3. The

new value ofASPminrights(r) is AppMinRights(r, newapp?) for all r, and the new

6.2. Benefits of Using Formal Methods 101

value ofASPmaxrights(r) is AppMaxRights(r, newapp?). But sincenewapp? is guar-

anteed to be inSetappswe know by equation 6.2 that

AppMinRights(r, newapp?) ⊆ AppMaxRights(r, newapp?)

and so equation 6.1 is satisfied. We only need to check equation 6.3fora = newapp?

which follows from the above observations.

Thenewapp? is an element ofSetappsand thus the following precondition must

be true from the condition stated in state schema.

Remove: Again only equations 6.1 and 6.3 are affected. For anyr, the new value

of ASPminrights(r) is the union ofAppMinRights(r, a) for all a ∈ Addedapps′. But

Addedapps′ is a subset ofAddedappsand we know thatASPminrights(r) ⊆ AppMinRights(r, a)

for a ∈ Addedappsso it must still hold fora ∈ Addedapps′. A similar argument shows

that ASPmaxrights(r) ⊆ AppMaxRights(r, a) for a ∈ Addedapps′. Together with

equation 6.2 this gives equation 6.3. This also establishesequation 6.1.

Since this exhausts all the operations, the theorem is proven.

When an application is removed and the service is no longer provided, theASPminrights

of the ASP is the generalised union of all existing applications after the application was

removed. Similarly theASPmaxrightsof the ASP is the generalised intersection of all

existing applications. There is no change in the pre-conditions and the post-conditions

still remain the same. Thus:

6.2 Benefits of Using Formal Methods

The use of Z for specification helped in clear by separating the pre and post conditions

of the application thus removing any doubts on the conditions under which the applica-

tion can function. This helps in the understanding of the system without any confusion

of what the functions of the designed system are. As previously stated in section 3.3.1

the use of Z helped to explore the system with tools that can help easily integrate with

this formal language and easily specify complex logic.

The use of fuzz for type checking of the specification helped to enhance the con-

fidence in the validity of the mechanism and to assure the functionality of the system.

The use of fuzz helped in achieving an error free Z specification. This could be easily

translated to sum which is a dialect used by Possum.


The use of Possum resulted in a systematic evolution of the policy. The animation

helped to analyse the state at the end of each schema. This analysis helped to validate

if the system model behaved as the specifier expected. It alsoprovided a better under-

standing of the policy. This kind of validation that provides a real time implementation

analysis also helped to understand the behavioural changesof system when the pre

conditions were changed and how it affected the system performance and functional-

ity. This contributed to a refined and secure policy.

Possum was very useful for verification of the logic. It also helped to verify the

functionality of the mechanism. Logical errors that could not be easily identified pre-

viously could be easily identified with the help of Possum. The use of Possum helped

to clearly prove the logic to the developers and show the functionality of the system.

To achieve this level of clarity about the functionality of the system helps in design-

ing the overall architecture with better understanding thus contributing to the overall

objective of designing a secure system at the upper level.

There was only one complexity faced with the use of Possum. The animation tool

took a large amount of time in processing the specification. Thus, the verification of the

logic was usually restricted to limited entity participation. It can be clearly observed

from the animation script in Appendix B that the rights were restricted to three and

the number of entities to two though the formal Z specification was designed for four

different entities with five different rights. It took around three hours to compute with

an extra entity participating in the mechanism. This was mainly the limitation of the

Trail version of the Possum animation tool. Industrial versions of the tool perform

better and handle high loads. Except for this small limitation the experience with

the use of Possum was very positive and the software was quiteuser friendly and

straightforward.

In summary the use of Z, fuzz and Possum helped in

• uniform representation of the system,

• clear demarcation of the use and the conditions under which the system needs to

function and the consequences if the limitations are exceeded,

• analysis of the system’s behaviour at each state during the process,

• proof of the logical and functional validity of the system, and

• ease of understanding and designing during the implementation stage.

6.3. Extension to Assure Anonymity 103

6.3 Extension to Assure Anonymity

Anonymity is a key property important to assure user privacy. According to the ISO

standards [96], anonymity is defined as the protection against discovery and misuse of

identity by other users. There are various levels of anonymity

1. Traceable anonymity: A trace of the anonymous message and the identity of

the sender are always kept for tracking the anonymous personwhen required.

In each session there is a different anonymous identity thatlinks the user to the

actual identity of the user.

2. Untraceable anonymity: The anonymous sender cannot be traced.

3. Untraceable pseudonymity: A continuous trace of user is maintained but this

does not bind the user to the actual identity of the user.

4. Traceable pseudonymity: A continuous trace of user is maintained and if re-

quired there is the ability to bind the identity to the actualidentity of the user.

The level of anonymity required for an application depends largely on the nature of

the service required. Section 2.4.3 provides the classification of location based appli-

cations based on the nature of application requested by the user. Table 6.2 provides

the users expected level of anonymity for various applications provided by the ASP. In

addition, the classification is interrelated and thus everyapplication has to be first clas-

sified according to the property these require and based on this the level of anonymity

and other privacy properties are added. The matrix shows thelevel of anonymity re-

quired for each of the services provided.

Security services User services

Paid services Traceable pseudonymityTraceable pseudonymitytraceable anonymity traceable anonymity

Unpaid services Traceable pseudonymity Untraceable anonymity

Table 6.2: User’s Required Level of Anonymity

The proposed model currently looks at managing user location information while

sharing location information between varied applications. This mechanism can be

effectively modified to assure that the anonymity of a user isprotected when the user

requests multiple applications from the same application service provider.


6.4 Conclusion

For a better growth of the technology every application has to be given due impor-

tance to function. The proposed model helps to group variousapplications that require

location information having similar requirements in an heterogeneous environment.

The model can be easily extended to assure the anonymity of the user when the user

requests different kinds of services from the same ASP.

The use of formal methods clearly defines the scope of the application. The use of

formal specification helped to overcome many logical and formal errors. This assures

the easy integration of the model with the proposed heterogeneous architecture. The

clear definition and enhanced security by validation and proof at the lower layer helped

to enhance the overall security of the architecture currently under development. The

use of Possum enhanced the confidence in our specification andits validity to assure

the functionality of the system.

The encapsulation of the information flow model along with the architecture in

chapter 5 fulfills one of the requirements identified in section 4.1. The next important

stage in the system design is the post analysis of architecture. This is carried out by

implementation and analysis of the architecture. The implementation was also carried

out to validate the proposed concept and the results are presented in the following

chapter.

Chapter 7

Implementation and Post-Analysis

Implementation and post analysis are important stages in system design as these help

to identify the additional enhancements required for the architecture. This also helps

to provide a proof of concept for the proposed architecture.This main objective of this

chapter is to presents a brief overview of the implementation. We also present the post

analysis results of the architecture.

Using the Unified Modelling Language (UML), the architecture was remodelled

for better architecture semantics and support for a object oriented approach to imple-

mentation. UML helped in the iterative system development of the architecture. A

brief introduction of UML and the selection of UML in design was presented in sec-

tion 3.3.1. Ring [80] provides the complete implementationdetails along with the

various UML diagrams.

7.1 Implementation

The Java programming language is used to implement the infrastructure servers (Lo-

cation Server and Network Operator) as well as the referenceClients and ASP’s. Multi

threading is used to provide a better response and throughput when multiple users are

using the system simultaneously. The implementation of allthe participating entities

is presented in the following subsections.

105

106 Chapter 7. Implementation and Post-Analysis

7.1.1 Location Server

The Location Server component of our system is a multi threaded Java application.

Location Providers

The system is designed to allow any number of third party location providers to pro-

vide, or seed, the Location Server with location information. These service providers

could be GSM Networks Operators, GPS providers, and corporate/campus wide WiFi

(802.11) wireless networks. The underlying technology used to determine the User’s

location by the Location Provider is irrelevant to the Location Server as it places an

equal waiting on all Location Providers. Location Providers send location updates

periodically or whenever a User’s location changes.

The key aspect of the Location Server is the capability to accept location infor-

mation from multiple location providers about the same userconcurrently. That is, a

user’s location may be monitored by both a GSM operator and GPS. Both technologies

can then send updates to the Location Server; the Location Server will accept both and

use one source to reinforce the other. The use of location management system pro-

posed in Chapter 6 was used to tailor the conflicting locationresults from different

location providers.

Location Providers contact the Location Server and send location updates in the

following format:

UPDATE:timestamp:uid:longitude:latitude:assurance

timestampis in UNIX time format (Number of milliseconds since Epoch) at which

the location calculation was made. This is used to ensure thefreshness of the

information contained in the location data set.

uid is the UID of the User. The Location Provider is responsible for mapping the

underlying identity (IMEI, IMSI, MAC Address, etc) to the UID used by the

System.

longitude is the measure of longitude of the user’s current location represented as

a decimal. Positive for Northern Hemisphere and negative for Southern Hemi-

sphere.

7.1. Implementation 107

latitudeis the measure of latitude of the user’s current location represented as a deci-

mal. Positive for Eastern Hemisphere and negative for Western Hemisphere.

assuranceis a value provided by the Location Provider as a measure of assurance in

the provided location information. At the stage this value is recognised yet does

not take part in location calculations.

As the location, servers are responsible for seeding the system. It is their responsi-

bility to provide reliable and correct location data. The system is based on the assur-

ance that the Location Providers being used will provide accurate location information.

Location Providers are required to provide location information in Longitude and Lat-

itude format as indicated earlier. Location Providers are responsible for converting

between the coordinate system used for detection and longitude/latitude for delivery to

the Location Server.

Cryptography

The Location Server is required to ensure the integrity of a User’s location information

and ensure that this information cannot be read during transmission to the client. The

Location Server provides this service by using two separatesymmetric keys. Both of

these keys are DES3 keys and are used for encrypting and signing respectively.

Java, through the Java Development Kit (JDK), has an extensive security API [93]

that provides DES3 (Data Encryption Standard encryption and decryption with three

56 bit keys and 8 byte blocks in CBC mode) and SHA1 support which enable the

Location Server to ensure confidentiality and integrity of communications.

To ensure confidentiality the Location Server encrypts and decrypts client commu-

nication using a long term shared secret key between the Userand the Location Server

as in equation 7.1.

plaintext= ELS−U{ciphertext} (7.1)

To ensure the validity and integrity of location results being returned to the User,

the Location Server produces a MAC of the result using a SHA1 hash seeded with a

long term shared secret key reserved for signing as shown in equation 7.2. Ideally,

HMAC is a better signature than the one proposed in Equation 7.2. Due to the limita-

tions of the JDK, the proposed signature scheme was used instead of HMAC.

Signature= SHA1{Data+ KeyLS−U} (7.2)


Storage

The Location Server stores the User Keys, Current Locations, Location History (if

required for future audit), and the Request Log. In the implementation, this stor-

age is handled by an SQL database. It would be expected however, that production

implementations would also store some or all of these in an SQL database to allow

for standardised access to the data. The reference implementation used a MySQL

[70] database and was implemented in theMySQLLocationServerDBMS class.

MySQL was chosen because, being an open source project, it isfreely available and

Java drivers were also readily available, which made connecting to the database server

straightforward.

To maintain easily portable data when storing the keys in thedatabase, the binary

representations of the keys are first Base64 encoded so that they can be stored as a

character string. Java makes available libraries for converting keys between different

formats, while the Base64 library produced by Robert Harder[48] provides support

for the actual Base64 encoding and decoding.

Semantic Services and Providers

The privacy framework hinges on the ability to obtain location information in varying

levels of granularity. For this to be possible the Location Server must be capable of

providing location responses in all the levels of granularity. This is made possible in

the reference implementation of the Location Server by the use of a Semantic Loca-

tion Service (SLS) that allows multiple Semantic Providersto be made available to the

entire Location Server. Semantic Providers are able to provide a subset of all possible

granularities and/or or a subset of all possible locations,the only restriction is that Se-

mantic Providers must implement theSemanticProvider interface. For example,

a municipality may make available a database of coordinatesto street addresses only,

therefore, if a location was requested for a coordinate not within the municipality, a

null, or unknown response would be returned. Likewise if an unsupported level of

granularity was requested. Figure 7.1 shows an example use of Semantic Location

Services.

BCC 1 Providing Street level granularity

QUT 2 Providing Room level granularity

1Brisbane City Council2Queensland University of Technology


Figure 7.1: Semantic Location Services

QLDGov 3 Providing City level granularity

These Semantic Providers are loaded at runtime by the Location Server and are

provided by third parties. Third party providers are at liberty to specify storage and

network requirements; the only restriction is implementation of the appropriate inter-

face. This allows providers to either distribute a databasewith the plug-in, or have a

plug-in that queries a server across a network connection. When a request is made by

the underlying Location Server, the Semantic Service searches through all registered

providers of the requested granularity until a response is found. The algorithm used to

produce a response for agetStreet() request is essentially:

while(response== null)

response= provider[i + +].getStreet();

In the event that none of the registered Semantic Providers was able to honour the

request, a null response is returned back to the Location Server.

7.1.2 Network Operator

The Network Operator component is a highly trusted entity that is responsible for en-

forcing user privacy policies, generation of session keys,and liaising between users

and service providers. Matching users with service providers based on privacy pref-

erences is the key role of the Network Operator. The reason the Network Operator is

trusted so highly is it is likely to provide billing servicesfor the User and as such is al-

ready trusted considerably by the User. The reference implementation of the Network

Operator is also a multi threaded Java application.

3Queensland Government


Registration

Users and service providers are required to register with the Network Operator prior

to operation. Registration is different depending on whether the entity being registered

is a user or a service provider. Users require three symmetric keys to be registered:

an encrypting key, a signing key, and a key-encrypting key. Additionally, each user

will define a privacy policy for each service class that the network operator makes

available. Service providers, on the other hand, supply theNetwork Operator with a

package containing:

1. Name of the ASP,

2. Public Key of the ASP.

In addition, for each service that an ASP provides, a packagemust be supplied to the

Network Operator containing:

1. Name of the service

2. Minimum Granularity, or the granularity level at which the service works best

3. Maximum Granularity, or the granularity level at which the service becomes

unworkable

4. Hostname on which the particular service is operating

5. Port on which the service is listening

ASP Calculation

The Network Operator’s primary role is the matching of Usersto ASP based on the ad-

vertised privacy policies of the service providers, and theuser provided privacy policies

for the service class in question. When determining which Service Providers match a

User’s privacy policy, the Network Operator performs the methodology proposed in

chapter 6. This mechanism returns a list of Service Providers that are compatible with

a User’s chosen privacy policy, or requested granularity.

Upon accepting a connection from a client, the Network Operator determines the

type of service the client is requesting. This is determinedby the value of the root

element of the message, as the protocol is XML based. This root element can be any

of the following:


• servicerequest

• privacyupdate

• privacyrequest

• profilerequest

• listservices

The operations relevant to providing a list of compatible ASPs areservicerequest

and listservices. The operations dealing with privacy policies and profiles are exam-

ined in subsection 7.1.2.Listservices causes the Network Operator to return

a list of all unique service classes that are available for users to choose from, while

servicerequest is used to request a list of ASPs.

When a service request is made the Network Operator decryptsthe client request

to obtain the service class being requested, this also verifies the validity of the request.

With this list, the Network Operator then prepares the packages to be returned to the

client. One package is created for each compatible ASP, witheach package containing:

• Users copy of session key

• ASP copy of session key

• A session Id

• The anonymous UID to give the ASP

These are generated for each compatible ASP, and encrypted and verification sig-

natures generated, finally all of these are returned to the client in an XML format. The

client is then responsible for verifying the validity of theinformation returned using

the verification signatures included.

Cryptography

As the information, being provided to and from the Network Operator is private and

sensitive, and the additional requirement that information be accurate, cryptography

is used for both confidentiality and integrity. The cryptography support classes in the

Network Operator implement the required ciphers and key generators for the Network

Operator to perform the roles required of it.


For communications with the User, three separate symmetrickeys are used, for

encrypting, signing, and key encrypting respectively. These keys are DES3 keys like

those used for communications with the Location Server. Consequently, support for

DES3 encryption and decryption are also provided by the Network Operator cryptogra-

phy support libraries. Additionally, SHA-1 support is provided for generating hashes

to use in verification of the data. Libraries for dealing withboth DES3 ciphers and

SHA1 message digests are available from the Java API.

In addition to DES3 and SHA-1 support, RSA public key cryptography support is

included for encryption and signing of the ASP packages provided to the user. The Java

API makes allowances for RSA encryption, but it does not include an implementation

due to export and/or license restrictions. Therefore the Bouncy Castle [98] RSA/DSA

implementation was used to extend the cryptography libraries provided by Java. Lastly,

the session keys used for communications between the ASP andthe User are single

DES, therefore support is provided for the generation of DESkeys.

Storage

The Network Operator is required to store information on both users and service

providers. The reference implementation being discussed was implemented using

MySQL for the reasons identified in subsection 7.1.1. The information being stored is:

User • Cryptographic Keys

• Privacy Policies (Profile)

ASP • Public Key

• Privacy Policy

• Service and Connection Details

Using an SQL database as the back end storage mechanism is advantageous to

Network Operators as other user specific data such as billingand account data would

already be contained in some form of relational database structure. As the Network

Operator source code was designed to be modular, Network Operators are free to im-

plement the database handling methods to use whatever DBMS is preferred. Produc-

tion versions may allow pluggable DBMS implementations similar to how the Location

Server handles third party Semantic Providers ( subsection7.1.1). This would make it

easier to change storage mechanisms, and additionally, allow providers to write imple-

mentations without having access to the systems source code, provided the interfaces

were made available.


Privacy Management

In addition to allowing Users to obtain a list of compatible ASPs, the Network Operator

allows Users to manage the profile that is stored in the Network Operator database.

Clients can perform three operations:

• privacyupdate - allows users to update the stored privacy policy for the

nominated service class. This is both encrypted, and SeededSHA-1 verified for

authenticity before accepting.

• privacyrequest - allows users to request the privacy policy stored on the

Network Operator for the nominated service class.

• profilerequest - allows users to obtain a copy of their privacy profile (col-

lection of privacy policies) from the Network Operator.

The reference implementation requires ASP to update their advertised (stored) pri-

vacy policy through out of band, or offline, methods. It wouldbe possible for the

Network Operator to accept privacy policy updates from the ASP as well as the Users

with some additional work.

7.1.3 Clients

User clients are the conduits through which all privacy and location information travel.

This is so that clients have control over their location information at all times, and

make the final decision on the release of location information to the Service Provider.

Privacy Management

Clients rely on the highly trusted Network Operator to only make available Service

Providers that have compatible privacy policies. Clients also trust that the Location

Server is correctly implemented and returns location information with the level of

granularity requested. No trust is placed in the Service Provider however. Even af-

ter a Service Provider is chosen and a connection has been made, clients still have the

power to deny location information from being divulged. Furthermore, if anonymous

UID are being used, the Service Provider has no unique information by which a User

can be identified and tracked.

Maintenance of the privacy profile that is stored at the Network Operator is the re-

sponsibility of the client. Clients do not specifically needto have privacy management


capabilities. However, knowledge of the User’s privacy profile is required for commu-

nication with the Location Server, as the Location Server does not obtain granularity

(privacy) information from the Network Operator. In this case, clients can have privacy

management functionality limited to that required to request privacy information from

the Network Operator.

Required Functionality

Correctly implemented clients will be capable of performing the following operations

as a minimum, against the Network Operator, Location Server, and Service Provider

(ASP).

• Request a List of ASPs for an identified service class from theNetwork Operator

• Make location requests in varying levels of granularity from the Location Server

• Supply location and session information to a Service Provider

• Perform DES3 decryption/encryption

• Perform DES stream encryption/decryption

• Verify Seeded SHA1 signatures

When a request for an ASP list is made, the Client is responsible for verifying the

validity of each of the returned ASP chunks. Users should notbe given the option of

choosing a Service Provider that is contained in a chunk thatdoes not pass the validity

checks. Furthermore, the Client is responsible for ensuring the validity of the location

response from the Location Server before passing that response to the Service Provider.

7.1.4 ASPs

Application Service Providers can be operated by any party if registration with the

Network Operator has occurred. ASPs can provide any number of services and each

service can belong to any number of service classes, however, realistically a service

is likely to only be a member of one service class. An ASP is free to determine the

language, host environment, and requirements of a service provided that the protocols

discussed in section 5.4 are observed.

ASPs can provide any service that is capable of running within the privacy and

location requirements that are provided by the system. The system does not provide


a means of verifying the correct operation of an ASP against the advertised privacy

policy of that ASP.

Privacy Management

Correctly implemented Service Providers are required to provide the Network Operator

with a privacy profile for each service being offered. This privacy profile contains an

upper and lower bound representing:

gran min The best granularity the ASP will use.

gran max The granularity above which the service can no longer be provided.

In addition to providing the policies, to the Network Operator, there is an implicit

expectation, and legal obligation, that Service Providershandle User data and location

data with respect to relevant government legislation and privacy laws. This legal obli-

gation prevents an ASP from falsifying the advertised privacy policy, or breaching the

privacy policy. This is because User choices are based on theadvertised policy, which

takes the form of a contract in which the User places some level of trust.

Furthermore, ASPs should ensure that information that has been made available to

an offered service is not accessible by other services beingoffered by the ASP, or from

any other third party not explicitly authorised by the User.

Support for anonymous UIDs that are generated by the NetworkOperator should

be provided. The protocols make allowances for anonymous UIDs but support for

them has not been provided in the reference implementation of the Network Operator.

Required Functionality

Service Providers (ASPs) have little responsibility, partly because service providers are

not trusted, and operated by parties that are not privilegedwith information regarding

the design, and implementation of system being used. Service Providers only have

three responsibilities:

• DES stream encryption/decryption with the Client

• Verifying signatures

• Providing the Network Operator with a privacy profile and RSAPublic Key


In addition, Service Providers have a logical expectation to perform some form of

service for the user. The nature of that service, and any additional requirements of

the User for using that service except providing location information, is beyond the

purpose of the proposed system.

7.2 Results and Analysis

The development of the system was for a proof of concept. For the actual efficiency

of the system, it is ideal to test the system with an actual carried out on a network

simulator. The lack of tools resulted in the Ad-Hoc analysisof the proposed system.

All four components of the system were individually tested for accurate operation

during the development of each entity respectively. On completion, the components

were tested together under simulated load factors to monitor the delays experienced

in various components of the entities, and in various operations. The goal was to

determine the impact the use of encryption and other security related measures had on

performance, as the provable security model being implemented was the primary goal

of the project. The data collected was recorded in milliseconds.

These loads were used when collecting data when running withcryptography sup-

port enabled. For the no cryptography tests, only 1 client was used (with 1, 5, and

10 ASPs). This was due to the difficulty in data collection as explained in subsec-

tion 7.2.1.

The results and analysis presented the delays experienced by the Client and the

Network Operator. The client perspective shows individualoperation delays, as well

as delays the user would experience.

7.2.1 Collection Technique

There were two mechanisms identified for collecting timing/delay data from Java. One

was by writing interfaces in C that interrogate the JVM directly, and the other by a

simpler, and less accurate way of taking a timestamp before and after an operation

occurs, and determining the difference. As the first mechanism is extremely involved

and complicated, the second approach was used. An example ofthis approach in action

would be:

preTime= newDate().getTime();

requestASPList(timetest, GRANULARITY);

timeTaken= newDate().getTime() − preTime;

7.2. Results and Analysis 117

The Network Operator and Location Server were extended to monitor key opera-

tions and log these to a file for analysis. Additionally, custom Service Providers were

written that required zero user interaction, but caused allnormal operations to take

place (Establishment, Location Request/Result, etc). Furthermore, a custom client

was written that allowed multiple clients to be loaded simultaneously. These Clients

complimented the zero interaction Service Providers. These were used to log results

of the system behaving under various loads.

The testing clients were all configured with similar privacypolicies. This was done

so that the number of ASPs that matched the User’s privacy policy could be controlled

by adjusting the privacy policies of the test Service Providers outside the range of the

test client privacy policies.

Each test was run 6 times, with an average of the last 5 resultsbeing recorded as the

result. The first iteration was disregarded as uncharacteristically large delays existed on

the first iteration. Although the reason for this is unsupported by any documentation,

it would be safe to assume that the first time Java encryption and key libraries are used

some level of seeding needs to occur and this would account for the delay.

Testing was carried out with all encryption and verificationcode enabled. Some

tests were carried out with encryption and verification disabled, however due to the

complexities in maintaining multiple source trees resultsare only available for the sys-

tem with a user load of one. Rewriting both the testing clientand the test service

providers would have taken considerable lengths of time, and would yield only pre-

dictable results.

As specified in the earlier section, ideally the system needsto be tested in a number

of PC’s or in a simulated network. The lack of resources to carry out the testing

of the system in real time environment is one of the key drawbacks. It is assumed

that these drawbacks have affected the ability to analyse the accurate efficiency of the

system. The aim of the impletion is to provide a proof of concept and testing for

the efficiency needs to be more precise and with out inter dependencies between the

various participating entities.

7.2.2 Testing Platform

The tests were carried out using QUT Faculty of IT desktops running the Windows

XP SOE on a Intel P4 2.6Ghz (HyperThreading)processor and 1Gb RAM. All effort

was taken to ensure each machine was a plain image, which was accomplished by

rebooting the machine and ensuring the reimaging process occurred. Furthermore, to


prevent contamination of the results, each service (with the exception of the test Clients

and ASPs) were run on separate PCs. This was needed as the measurement technique

recorded time taken to perform operations, and if multiple servers were on the same

PC this would affect the time taken, as multiple processes would be contending for

processor time, and therefore, increase the time taken. A total of 6 PCs were used in

the following way:

1. Location Server

2. Network Operator

3. Multi-threaded Test Client

4. TestASP 1 to 5

5. TestASP 6 to 10

6. Shared DBMS (MySQL)

Using 1 PC to provide 5 ASPs was necessary as it was not possible to obtain suffi-

cient hardware to run every service individually. This alsoapplies to the DBMS server

as both the Location Server and Network Operator both accessed the same DBMS.

The processing requirements for both the non-interactive ASPs and the DBMS are

quite low, the amount of contamination that was likely to occur was acceptable. Fi-

nally, the Test Client was used to simulate 1, 5, and 10 users on the same host, which

would have caused contention issues that may have contaminated the recorded results.

Additionally, the network connectivity between the hosts used for the testing was

beyond the control of the testing environment, although this is not likely to have caused

significant contamination of the results as the protocols used are relatively lightweight

and have very low bandwidth requirements.

7.2.3 Client Perspective

For Users of the system, the delay experienced at the Client,and in particular, the time

taken to perform specific operations, is going to be of most importance. Therefore, the

following metrics were recorded at the Client:

• Time taken to request a List of ASPs from the Network Operator(Request ASP

List)


• Time taken to establish an encrypted session with an ASP (EstablishASP)

• Time taken to request Location from the Location Server and return to ASP

(ReqLocation)

These operations were performed with the system operating under various loads

with and without encryption. Table 7.1 and Table 7.2 show theaveraged data that was

extracted from the log files made during testing. To establish a baseline of reference,

operations were performed with encryption and with encryption disabled. Due to the

limitations discussed in subsection 7.2.1 the test with encryption disabled was only

performed under a load of 1 User.

Users ASPs RequestASPList EstablishASP RequestLocation

1 1 334.8 509.4 31.05 1 771.88 2906.2 41.84

10 1 1464.32 6237.8 97.18

1 5 1184.0 715.8 31.45 5 4786.2 1392.68 31.96

10 5 9443.12 1918.12 36.28

1 10 2246.6 837.4 28.25 10 9908.84 1035.6 46.32

10 10 19720.42 1527.5 46.54

Table 7.1: Client Delay (in ms), Cryptography Enabled

Users ASPs RequestASPList EstablishASP RequestLocation

1 1 24.6 6.4 18.81 5 59.2 9.2 18.41 10 68.8 6.2 15.6

Table 7.2: Client Delay (in ms), Cryptography Disabled

Using the same testing conditions as used in Figure 7.2 when enabling cryptogra-

phy support produces the results shown in Figure 7.3.

The increase in delay, with just 1 user, is considerable. However, that delay is still

less than half a second, which when combined with low bandwidth network connec-

tivity as experienced in wireless handheld devices, would become insignificant when

compared with the network delays. However, as the user load increases, as can be seen

by the results in Figure 7.4 and Figure 7.5, the delays experienced by the client begin

to rapidly increase beyond values that would be eclipsed by network delays.


Figure 7.2: Client Delay with Encryption Disabled vs Numberof ASPs (1 User)

Figure 7.3: Client Delay with Encryption Enabled vs Number of ASPs (1 User)


Figure 7.4: Client Delay with Encryption Enabled vs Number of ASPs (5 Users)

The results in Figure 7.2 show the delays experienced by a Client performing the

3 standard operations. The metric of note is the time taken toRequest the list of ASPs

(RequestASPList), as the other two operations should take the same amount of time

regardless as they are not dependent upon the number of ASPs available that match a

users privacy policy. It can be seen that this holds true as the values recorded fall within

a margin of 5 milliseconds. This fluctuation of results is likely to have been caused by

the capture method used in subsection 7.2.1. The growth in time taken as the number

of compatible ASPs increases is interesting as a greater delay is experienced between

1 and 5 ASPs than between 5 and 10, this could be attributed to delays in processing

Java ResultSets greater than 1.

By far the greatest cause for delay is the operations required to request a list of

compatible ASPs from the Network Operator. This is expectedhowever when the

amount of cryptographic operations that are needed are known. When a Network Op-

erator provides a Client with a list of compatible ASPs the following cryptographic,

operations occur (multiple operations indicated):

• DES3 Decryption of Client Request

• For each compatible ASP

– DES Key Generation

– DES3 Encryption of DES Key

– RSA Encryption of DES Key


Figure 7.5: Client Delay with Encryption Enabled vs Number of ASPs (10 Users)

– Seeded SHA-1 Hash of Data

– RSA Encryption of Package (Signing)

– RSA Encryption of Signed Package (Encryption)

– DES3 Decryption of DES Key

– Seeded SHA-1 Hash of Data (Verification)

To highlight the demand in resources indicated by the large delays, Figure 7.6

compares the delays experienced by the client in requestingASP lists with the various

load levels tested. subsection 7.2.4 provides a detailed analysis of the delays for each

of these operations as experienced by the Network Operator.

Some explanation needs to be given in regard to the unexpected drop in delay that

is witnessed in Figure 7.4 and Figure 7.5 when establishing an ASP connection. This

occurs due to an overlooked aspect of the testing that was conducted. The reason

this behavior is exhibited, specifically in the change from 1ASP to 5 ASPs is that

when 1 ASP is being used, by 5 and 10 clients, that 1 ASP is beingcontended for by

all clients, and thus displays the worst case scenario for anASP. This is explained by

increasing the number of potential ASPs a client can choose from, therefore decreasing

the number of requests an individual ASP must honour during atest cycle, therefore

reducing the delay experienced by the Client.

Throughout the testing, the delays experienced with the Location Server remained

flat across all loads, with the actual observed difference between the best case and


Figure 7.6: Client Delay Request ASP List vs Number of ASPs

worst case scenarios as being only 66 milliseconds. This is likely to have been the

result of the following:

• the number, and size of requests for the Location Server is not dependent on the

number of ASPs returned to the client;

• the only cryptographic operations required are a DES3 encryption/decryption

and one Seeded SHA-1 hash; and

• most of the processing is off loaded to the SQL server being used.

7.2.4 Network Operator

The Network Operator has the strongest role in the system and, as noted in the previous

section, experiences the greatest delay of the entire system, due to the number of cryp-

tographic operations that need to occur to process client requests. Therefore, to provide

some explanation to the delays observed in the Network Operator, each cryptographic

function was time logged to highlight the operations that cause the most delays.

Table 7.3 shows the Network Operator Delay per Operation (inms), Cryptography

Enabled. Due to the large volume of data that was logged, the data obtained when 10

ASPs is analysed in detail.

Observing the difference between the total time taken to generate the list of ASPs

at the Network Operator (GenerateASPList), and the time taken to Request the list of

ASPs from the Client (RequestASPList) (which includes validation) will show if the


Users ASPs Decrypt Re-quest

GenerateSession Key

EncryptUser Ses-sion Key

EncryptASP Ses-sion Key

GenerateMAC ofASP

EncryptASP Chunk

Sign ASPChunk

GenerateTotal ASPList

1 1 0.0 0.0 3.0 9.2 0.0 15.6 194.0 1053.25 1 78.8 7.48 1.24 80.08 42.56 43.08 239.4 536.32

10 1 126.28 34.36 18.42 133.74 111.14 104.98 333.26 979.9

1 5 0.0 0.0 0.64 3.64 0.0 9.92 194.6 1053.25 5 76.2 51.88 37.13 139.78 102.85 83.75 232.97 4540.64

10 5 138.72 151.14 95.84 329.71 181.6 176.03 367.7 8961.94

1 10 0.0 0.32 0.0 2.8 0.0 8.44 195.96 2109.25 10 85.64 60.36 47.62 162.85 80.5 65.24 255.3 9610.94

10 10 137.4 137.11 137.38 350.92 185.74 173.31 369.49 19205.02

Table 7.3: Network Operator Delay per Operation (in ms), Cryptography Enabled

Users RequestASPList GenerateASPList Difference

1 2246.6 2109.2 137.45 9908.84 9610.64 298.2

10 19720.42 1905.02 515.4

Table 7.4: ASP List Generation Comparison (milliseconds)

delay is with the Network Operator, or in the Client validation routine. Table 7.4

highlights these two delays, along with the difference. Thevalues returned from Re-

questASPList and GenerateASPList are the total time taken.Table 7.5 shows the

average time taken to prepare 1 ASP for a Client under the usual 1, 5, and 10 user load.

7.2.5 Conclusion

The results that were obtained from a running system were as expected and those re-

sults that seemed unusual could be explained rationally. Initial observations suggest

that implementing secure protocols where trust is placed inone host in particular is

computationally intensive for that host. However, it should be noted that these results

were recorded using commodity desktop hardware, running ona platform that is not

optimised, with any algorithm optimisations performed on the servers themselves. Ad-

ditionally, as this is only a prototype implementation, large sections of debugging code

still exist, and the servers have not been written by an experienced programmer. De-

spite all this, it can be reasoned that any implementation ofthese protocols and system

Users Avg Time/ASP

1 207.525 671.87

10 1353.95

Table 7.5: Average Time Taken to Generate an ASP Chunk (10 ASPLoad)


will require considerable resources on the network operator.

The results validate the choice of the framework and the approach taken towards

the design of the secure architecture. The proposed approach provides the user with the

ability to choose suitable service providers along with theability to decide the granu-

larity of location information the user is willing to disclose to service providers. This

approach is suitable for commercial user services but it cannot be used for providing

security services as mentioned in Chapter 4. Security services require tamper resis-

tant location information that needs to be directly forwarded to the service provider.

In Chapter 8 we propose minor modifications to the proposed architecture. We also

demonstrate through a case study the benefits of the proposedarchitecture in securing

critical infrastructure.

Chapter 8

Heterogeneous Location Architecture

for Security Services

The heterogeneous location architecture provides a platform for supporting location

based access control mechanisms in both the authenticationand authorisation pro-

cesses. The use of location based authentication and authorisation has been described

in a number of papers. Looi [65] presented an architecture inwhich location informa-

tion was used to enhance authentication in Internet banking. Wullems [105] presented

an access control mechanism that incorporated location information into the authori-

sation process. In that system, an authenticated user was only permitted to remotely

access resources while their PDA remained within a specifiedarea.

To authenticate a user or authorise a request, based on location information, the

location information needs to be derived securely and its transmission made tamper-

proof. The architecture provides the ability to integrate the location information from

multiple sources. The integrated location information provides the prices location of

the user. This precise location information provides the ability to effectively deter-

mine the location of the user and thus perform efficient location based access control

decisions. The secure protocols also provide the ability tocarry out these operations

securely. This will be extremely useful in protecting critical infrastructures, which

permit the use of wireless technologies in their control systems.

Critical control systems are computer systems that are usedto monitor and control

sensitive processes (e.g. chemical plants) and distribution systems (e.g. electricity dis-

tribution). Traditionally such control systems had been specifically designed for their

127

128 Chapter 8. Heterogeneous Location Architecture for Security Services

particular application using special purpose components and were kept separate from

other information systems [8]. To gain efficiency control systems are using wireless

technologies. These are also being integrated into generalIT networks. Additionally,

there is a move toward the standardisation of the control system architecture e.g. the

adoption of standardised communications protocols withinthe Supervisory Control

and Data Acquisitions (SCADA) architecture. The adoption of standardised commu-

nications protocols with out proper analysis has the potential to introduce new errors

in the system. This increases the vulnerability of the system. In 2000, attacks were

mounted against a sewage pumping station in Queensland, resulting in the release of

very large amounts of raw sewage. This insider attack was also significant as it em-

ployed wireless technology and specifically targeted at taking over the control system.

The current approach to providing network security is basedon the establishment

of a secure perimeter by using firewalls. Such an approach is inherently flawed. Once

these protection measures are breached, an intruder effectively has free access to the

network. To overcome this deficiency, Ganger and Nagle [40, 41] proposed a secu-

rity architecture in which individual network devices wereresponsible for their own

protection, effectively establishing separate security perimeters around each device.

In this chapter, a variation to the heterogeneous location architecture approach is

proposed to secure control systems. A secure context-basedarchitecture based on

these principles of self-defending objects (SDOs) is proposed. The SDO approach is

an extension to the current object oriented programming paradigm such that software

objects which provide security sensitive functionality orhold sensitive information, are

responsible for protecting those resources. The proposed architecture

1. requires limited changes to the existing infrastructure,

2. prevents an attacker from gaining access to the whole system should a breach of

the perimeter defences occur, and

3. through the use of a location based access control mechanism prevents attacks

launched from external mobile wireless devices.

8.1 Background Information

In this section, the reader is introduced to a number of previously unrelated areas of

research which in combination form the basis of the proposedarchitecture.

8.1. Background Information 129

8.1.1 Security Aware Applications and Access Control

A Security Aware Application (SAA) is an application program whose operation is

dependent upon security information. That characteristicis normally reflected by pro-

viding different functionality to different users. To clarify what is meant by the term

security aware application, consider the security requirements of the health care sector.

Patients demand, and legislation requires, that access to medical records should only

be granted on a need to know basis. In a medical system, when access to a patient’s

medical record is requested, whether the access should be granted depends on who is

making the request. Due to the complexity of such access control decisions, a major

component of such an SAA is the access control subsystem.

Access control has two aspects: authentication, the process by which a user pro-

vides proof of their identity, and authorisation, the determination of whether that user

should be given access to a particular resource. Authentication of the user’s identity

may be based on a combination of factors from the following classes: (1) something

that they know, e.g. a password, (2) something that they have, e.g. a swipe card, and

(3) something they are, e.g. a fingerprint or retinal scan. The authorisation decision

is often based on the presentation of a token / credential obtained following authen-

tication, and a set of rules that specify which users are ableto access each protected

resource. These rules are referred to as the application’s security policy. In our med-

ical scenario, once the user has established that they are the doctor currently treating

a particular patient, they would be permitted to both read and append to, the patient’s

medical history. However, somebody who is not authorised touse the system, or an-

other doctor not involved in the treatment of that patient, would be refused access to

the medical record.

Due to the complexity of allocating the large number of rights required by indi-

vidual to perform their duties, a form of access control called role based access con-

trol (RBAC) is being increasingly adopted. The approach reduces the administrative

overhead as rights are assigned to roles and the individual users are associated with

roles. For example, the roledoctor is allocated the access rights needed by a doctor

to perform their duties. The roledoctor at hospital Xwill have those additional rights

allocated that are needed by a doctor working at X, to access the information resources

administered by that hospital. When a new doctor arrives at X, they need only be

associated with the roledoctor at hospital Xto gain all those numerous rights.

A SAA must not only restrict access to its protected resources, it must also main-

tain an audit trail. The audit trail records all attempted accesses to protected resources,


regardless of whether the access was granted or not. Such information is vital for

both verifying that the security policy is being correctly enforced and, when a secu-

rity breach occurs, determining the extent of the breach andwho was responsible.

The information system as a whole also needs to ensure that the information cannot be

viewed or modified by means other than through authorised applications. That require-

ment might be realised using such techniques as encryption (to secure information in

transit across the network) and by hosting the application,its security configuration

information and persistent forms of the information, e.g. databases, on a secure plat-

form.

8.1.2 Self-Defending Objects (SDOs)

The use of the self-defending object (SDO) concept in the construction of SAAs was

described by Holford et al [50, 51]. The SDO concept extends the current object ori-

ented programming paradigm such that software objects which provide security sen-

sitive functionality or hold sensitive information, are responsible for protecting those

resources. This protection has two aspects: the enforcement of that portion of the ap-

plication’s security policy which relate to its protected resources and the generation of

the related audit trail entries.

Within an SDO based application, the right of a user to call each method (function/

procedure) which accesses a protected resource, is checkedbefore the method is ex-

ecuted. To support this access control check, such methods are passed an application

specific credential which is used to validate the user’s right to invoke the method.

The rationale for using SDOs to protect sensitive resourcesis natural. In an ob-

ject oriented program, the relevant object provides the only means of accessing the

resource. That object is therefore the most appropriate point at which to perform ac-

cess control checks and log accesses. This coupling of the single point of access and

the checking of the validity of that access, ensures that theaccess control mechanism

cannot be bypassed. The SDO approach cannot, by itself, guarantee the ultimate the

protection of sensitive resources as it can only control accesses made from within the

application. A protected operating environment, preferably a trusted operating system,

is needed to ensure that the application level protection mechanisms cannot be by-

passed, e.g. the databases and security policy configuration on which the application

relies, must be protected from direct access by hackers.

8.1. Background Information 131

8.1.3 Self Securing Devices

Ganger and Nagle [40, 41] observed that current network security relies heavily on

the establishment of a secure perimeter by using firewalls and the security features

of COTS (commercial off the shelf) operating systems. They concluded that such

an approach is inherently flawed as once these border protection measures have been

breached, an intruder effectively has free access. In accordance with the principle

of defence in depth, they proposed a security architecture in which individual network

devices, including storage devices, network cards, routers and switches, are responsible

for their own protection. Then the secure perimeter protection provided by firewalls,

is supplemented by separate security perimeters around individual network devices.

These enhanced devices, which they call self securing devices, not only protect their

their own resources, they can observe, log, and react to the actions of other nearby

devices. Compromises of one security perimeter will compromise only a small fraction

of the network environment [40]. In related papers, Strunk et al [92, 91]. provides a

description of how a self-securing device, namely a storageserver, was implemented.

Making hardware devices responsible for their own security, provides both a novel

and effective way of increasing the security within critical infrastructures which are

permitted to use wireless technologies.

8.1.4 Critical Control Systems

Critical control systems are computer systems that are usedto monitor and control

sensitive processes (including water treatment, petrochemical and chemical plants) and

distribution systems (e.g. gas and electricity distribution). A number of different types

of control systems are in use including Supervisory Controland Data Acquisitions

(SCADA), Distributed Control Systems (DCS) and Programmable Logic Controllers

(PLC). Various government bodies across the globe have recognised the need to protect

control systems and declared that they constitute criticalinfrastructure that should be

protected [38]. Control systems are vulnerable to a large range of attacks which could

result in:

• disruption to their normal operation by delaying or blocking the flow of the in-

formation through their networks and hence loss of control,

• taking control of PLCs or DCSs, causing them to perform unauthorised opera-

tions. The effect of loss of control includes equipment damage, supply disruption

and significant environmental / financial damage,


• false alarms being received that cause disruption to production or supply of es-

sential services.

External Networks

Firewall

Critical Infrastrcutre

Enterprise Network

Control System

Supervisory Control & Monitoring Unit

Remote/Local Control Remote/Local Control

Engineering Workstation

Laptop computer

Laptop computer

Workstation

Printer Application Server Hub

Server

Human Control Interface

DCS/RTU/PLC DCS/RTU/PLC

Modem PDA Handheld device

Sensor Control systems

Control systems Sensor

Supervisory Control & Monitoring Unit Contains the Servers,workstation and Human conrtol interfaces that collect monitor and log information send by remote/local stations

Remote station Contains the remote terminal unit (RTU), Programmable logic controller(PLC),or distributed control unit(DCS) controller which receives and interepts the signals from the sensor and generates corresponsding control signals to the supervisory control and monitoring unit

Enterprise network: The process where all the business operations are carried out along with correspondence to outside vendous,customers.

Figure 8.1: Control System

Traditionally control systems were designed as dedicated stand-alone systems. Be-

cause each control system was unique, an attack that worked on one system would

be ineffective on other systems. With the use of COTS computing components and

standardised communications protocols, the integration of control systems and the en-

terprise network (and even the Internet) and the adoption ofwireless technology, these

systems are becoming vulnerable to cyber attacks or even cyber-terrorist attacks (see

Figure 8.1). Because only border protection mechanisms (firewalls) are normally used

to protect such networks, an intruder who gains access to thelocal network also has

access to the control systems. The increase in standardisation also means that an attack

successful on one control system may disrupt others.

8.2. Motivation 133

8.2 Motivation

As previously discussed, the control system is a vital component in most critical infras-

tructures and as such, demands a high degree of protection. However control systems

are increasingly being constructed using COTS components and integrated into the

general IT networks. Consequently, the use of (1) standardised IT technologies with

their known vulnerabilities, (2) the adoption of wireless technologies, (3) the lack of

physical access control barriers, and (4) the current reliance on singular border protec-

tion mechanisms, has significantly increased the vulnerability of control systems.

Although they do not occur often, a number of recent events demonstrate that con-

trol systems are vulnerable. In March/April 2000, an attacker mounted 46 attacks on

sewerage pumping station in Queensland, Australia. The subsequent release of very

large amounts of raw sewerage into local waterways caused significant environmen-

tal and financial damage. This attack was also significant in that it involved the use

of wireless technology and specifically aimed at taking control of the control system.

Although the attack was effectively aninsider attack, as the attacker had access to

propriety radios and software, a concerning aspect of the attack was the apparent ease

with which it was carried out [8].

In 1999, a group of hackers with help of an insider, gained control of Gazprom’s gas

network allowing them to control pipeline gas flows for a short time [34]. (Gazprom

is the world’s largest natural gas producer.) Worms and viruses pose a serious threat

to control systems that include standard IT components and communications proto-

cols, even when they are not the intended targets of the attack. In January 2003, the

SQL Slammer Wormpenetrated the Ohio nuclear plant, despite the presence of fire-

walls causing the temporary shutdown of the nuclear plant [77]. The slammer worm

also affected electrical systems in the United States of America. The traffic generated

by the worm swamped the network, blocking SCADA traffic. The worm penetrated

the SCADA system via a remote computer using a VPN connection, bypassing the

network’s firewall protection [72].

These incidents demonstrate vulnerability of a modern, technology-dependent so-

ciety to attacks on the control systems. Should a cyber-terrorist attack be mounted on

a control system, with the aim of maximising the damage or disruption that it causes,

the consequences of the loss of control of critical infrastructures could be devastating.

Such a scenario highlights the need to adequately secure control systems.

An integral part of securing any computer system is the provision of access con-

trol, which limits access to both the system and individual resources, to authorised


entities. One way of strengthening both authentication andauthorisation is to incorpo-

rate contextual information, rather than relying purely onestablishing the identity of

the user. Location information is particularly useful whenwireless technology is being

used. When used, a system might refuse access to an otherwiselegitimate user because

they are not on an approved site, simulating the physical access control mechanisms

afforded by wired systems.

The self-securing device approach also has a role to play in the strengthening

of control network security. However, we believe that the adoption of such special-

purpose hardware runs contrary to the current trend away from the use of dedicated

hardware. Instead, a software means of providing self-securing devices, with SDOs is

considered more appropriate. The SDO concept would providethe underlying design

paradigm for the control system. In addition to the protection of information resources,

SDOs would also be responsible for the control and protection of security significant

devices, transforming the devices into self-defending devices.

SDOs take on a new emphasis in the control of industrial processes, particularly

where the associated messaging systems are based around wireless technologies. Wire-

less transmissions received by a self-defending device might have originated from any

wireless device within range, so the use of authorisation isvital. In accordance with

the SDO approach, such control instructions must necessarily be accompanied by an

appropriate authorisation token. The self-defending device will use the location of

the transmitting device as a factor in determining whether the control instruction is

legitimate and should be executed. The device should also becapable of acting au-

tonomously, in a fail-safe manner, in event of an attack or communications disruption.

As identified in subsection 8.1.2, another important aspectof the protection provided

by SDOs is the generation of an audit trail.

The use of a context aware access control mechanism and SDOs helps to define

a secure architecture, which we believe will be effective insecuring control systems.

An important aspect of the architecture is that it protects control systems with limited

changes to the existing infrastructure and in a scalable manner; while helping to pre-

vent, or minimise, the potential damage and interruption inthe event of an attack. The

multi-layered approach prevents an attacker from gaining access to the whole system

should a breach of the perimeter defences occur, while the use of a location based

access control mechanism prevents attacks launched fromoff sitemobile wireless plat-

forms (provided that the location information is both accurate and cannot be spoofed).

8.3. The Proposed Secure Context-based Architecture 135

8.3 The Proposed Secure Context-based Architecture

In this section, the security architecture and associated communication protocols will

be described. The architecture is an extension of the framework proposed in chapter 4

for secure communication. We extend this architecture and present a case study. The

case study describes the effective application of the architecture to the control system

of a sulphuric acid plant. This is described in section 8.4.

Location based authentication and authorisation has been described in a number

of papers. Looi [65] presented an architecture in which location information was

used to enhance authentication in Internet banking. Wullems et.al [105] presented an

access control mechanism that incorporated location information into the authorisation

process.

The architecture delivers multilayered security, by supplementing the border pro-

tection provided by firewalls and COTS operating systems, with application level, con-

text aware access control measures. A basic assumption of the architecture is that the

system will be implemented using an object oriented programming language and the

design based on the SDO concept. In line with current trends,the SDOs will en-

force role based access control on their protected resources. To counter the continued

adoption of wireless communication within control systems, the architecture includes

location as a crucial factor in the authorisation process. The adoption of the architec-

ture will facilitate the construction of systems with sufficient strength to protect critical

control systems, despite the security ramifications of using wireless technology.

8.3.1 Self-defending Objects And Control Systems

In control systems, the control of all devices and all accessto sensitive information

resources should be restricted to authorised users. Unfortunately, the overhead of per-

forming the authorisation checks needed to provide the additional security adversely

impacts performance. The additional complexity introduced by incorporating contex-

tual information such as location, into security architecture is particularly problematic

as authorisation servers have the potential of becoming system bottlenecks. However,

the inclusion of location information is warranted in orderto combat the increased

vulnerability of the system resulting from the use of wireless technologies. The over-

riding requirement for deterministic real-time performance of the system, and its safety

critical nature, means that the need for complete security must be left unfulfilled. Con-

versely, the execution of control instructions sent by an attacker might have significant


environmental, operational or safety consequences. The possibility of such an event

occurring, particularly when wireless communication is involved, was demonstrated

by the multiple successful attacks on a sewerage pumping station (see section 8.2

orin Barker’s article [8]). To balance these opposing concerns, a risk analysis should

be conducted to determine which hardware and software resources must be protected.

The analysis will identify those objects which should be self-defending. Given the

need to perform authorisation before accessing the identified critical resources, the

use of SDOs will ensure that the required checks will be performed. The audit trail

generated by the SDOs will also be valuable in determining the actions preceding an

incident, whether the cause was accidental or deliberate.

8.3.2 Overview of the Access Control Mechanism

The access control mechanism proposed is similar to standard access control mech-

anisms used elsewhere, other than the inclusion of locationas a factor in the autho-

risation process and the use of SDOs to ensure that the authorisation measures are

consistently applied. The presence of wireless connections makes the direct connec-

tion of an attacker to a control device or subsystem possiblethereby bypassing the

perimeter security measures. From a security viewpoint, itbecomes essential for con-

trol software to defend itself from potential attacks. Partof defence is ensuring that the

user making the request is authorised and any wireless communications (in particular)

originated from an ‘authorised on site’ or from a trusted secure location.

Location should be used as a factor within the authentication process thus ensuring

that the user must be ‘on site’ before being able to gain access to the system. However,

because of the authentication process, a user credential that certifies the identity of

the user, their authenticated role and device identifier being used, is generated. As

one might expect, the details of the user’s location at the time of authentication is not

included. The user’s role is required for role-based authorisation, while their identity

is required to determine their location and for audit trail generation. The device ID is

needed to determine the location of the user’s communication device.

8.3.3 The Authorisation Mechanism

The authorisation mechanism is illustrated in Figure 8.2. The block diagram empha-

sises authorisation decision making mechanism, particularly the access control mecha-

nism. The roles of the various participating entities are the same as the network centric


approach described in chapter 5.

User Application Server

DCSM

Authorisation Serve r

Location server

Network Operator

Access Control Unit Request for location

Response for location

Authorisation request

Authorisation response

Request for service

Response for service

Request for authenication

Authenication response

Figure 8.2: The Authorisation System

User and device location

Many organisations use multiple technologies to determinethe location of the users.

These may include the Global System for Mobile Communications (GSM) mobile

phone of the user, the Global Positioning System (GPS), Wireless Local Area Net-

works (LANs) and Active Badges [100]. Different wireless hand held devices such as

Personal Data Assistant (PDA), laptops are connected to theenterprise network trying

to access files at the supervisory control and monitoring station. If that request is being

mediated by the system, it will result in a call to a method of the SDO, which controls

access to the relevant resource. If more than one kind of technology is used for the

determining or accessing the resource then two different location data sets can be cre-

ated. (1)The general location of the user that is derived from all user devices other than

the device requesting the service and (2) the location of theuser device requesting the

content.

For example, let us consider Alice is working in an organisation determines the

location of its employees by using the mobile phone of the employee, Active Badges

and PDA (Using the Wireless Local Area Networks (LANs)). When Alice requests

for service from the SCADA system from his PDA, the organisation has the ability to

determine the location of the PDA. It can also determine the location of Alice based

on the location of the mobile phone and the Active Badges.

Depending on the nature of service requested by an user, organisations can enhance

the security of the overall system by further verifying if the location of the user and the


user device are identical. These are very useful to prevent unauthorised use of devices

or accessing services from stolen user devices. One of the major limitation of this

approach is the inability of the user to share the device across other users. The system

requires the devices to be used only by the registered users.

Application Server

The application server represents the entity that receivesthe request from the user,

so represents all the software objects of the system. Only selected objects will be

self-defending and will perform authorisation checks before performing the requested

operation.

Access Control Unit (ACU)

The Access Control Unit is responsible for making the accesscontrol decision on be-

half of an SDO. That decision is based on whether that user hasthe ‘right’ to execute

that SDO method and also whether the location of both the userand their communi-

cation device are in the required location. Correspondingly, the access control unit is

divided into two sub-units: the Authorisation Server and the Dynamic Context Service

Manager (DCSM).

Authorisation Server (AS) The authorisation server determines whether the user,

acting in their current role, is permitted to call the SDO method. It enforces that

portion of the access control policy which relates to users and resources, and ignores

the location of the user. If the user is found to have the rightto access the resource, the

DCSM is called to verify that the user request was sent from anacceptable location.

Otherwise, the request is rejected immediately.

Dynamic Context Service Manager (DCSM)The DCSM is responsible for veri-

fying that the user’s request originated from an acceptablelocation, i.e. it is responsible

for enforcing the context component of the access control policy. The DCSM obtains

the location of the user and device from the location server.Depending on the nature

of the request, the granularity of the location required andits recency is likely to vary.

For some method calls, it might be sufficient to know the user is ‘on site’, while for

more sensitive calls the request might need to originate from a particular terminal in

the control room. An important consideration is whether thelocation of the user and

their communicating device coincide. Based on the locationinformation, the DCSM

determines whether the access should be granted.


Location Server (LS)

The Location Server (LS) is responsible for providing the last recorded location of

users and their communicating devices (to the required granularity) and times at which

those readings were made. The LS continually monitors wireless transmissions, per-

sonnel tracking devices, etc. which enables such requests to be satisfied immediately.

As described in chapter 2, the location information is derived from multiple sources to

ensure its accuracy. A collection of Handset based locationdetermination and network

operator based location mechanism is used to determine the location of the user.

Network Operator

The network operator is responsible for maintaining up to date authentication and au-

thorisation (security policy) information.

8.3.4 Authorisation Communication Protocols

In this section, the steps involved in the authorisation process and associated high level

communication protocols will be discussed. The secure protocols designed in chap-

ter 5 can be used for the proposed approach. The following section briefly describes

the process flow to support the proposed architecture. The major steps involved in

providing a service to a user are:

1. the request for service is sent by the user

2. the authorisation request is sent by an SDO

3. the authorisation decision is made by the Access Control Unit

4. if authorised, the SDO performs the service

When presenting the content of messages, the notations presented in Table 8.1 are

used.

Request for Service

The user sends a request to the AS to provide a service. That request might originate

from a device that the organisation provides to users, or potentially, any device, which

has access to the network. The request for service consists of the user’s authorisation

credential and details of the service requested.


Entities

U Client requesting the service (User)AS Application Server (an SDO is assumed)

ACU Access Control UnitAuthSer Authorisation ServerDCSM Dynamic Context Service Manager

LS Location Server

UCred The user’s authorisation credentialUID The user ID (from authorisation credential)DID The communication device ID (from authorisation credential)

SerReq The Request for serviceSerRes The Service result

MethodName The name of the SDO method being envokedGran Granularity of location information required

UserLoc Location of userDeviceLoc Location of deviceUserLoc Time the user location was recorded

DeviceLoc Time the device location was recordedBoolRes A boolean authorisation result

Table 8.1: Protocol Notations

U ASUCred, SerReq−−−−−−−−−−→

Figure 8.3: Request for Service

Authorisation Request

On receiving a service request, an SDO ensures that the user is entitled to make that

method call before satisfying the request. (If a non-SDO receives the request, it will

be satisfied without an authorisation check.) The SDO delegates the authorisation

decision to the ACU, and enforces that decision. The authorisation request sent to the

ACU consists of the user’s authorisation credential and theidentity of method being

invoked by the user.

AS ACUUCred, MethodName−−−−−−−−−−−−−−→

Figure 8.4: Authorisation Request


Making the Authorisation Decision

The request from the SDO is received by the Authorisation Server sub-unit of the ACU.

After checking the validity of the credential, the user’s name and role together with the

device ID are extracted from the authorisation credential and the right of the user to

invoke the requested method on the SDO is verified.

AuthSer DCSM LSUID, DID, MethodName−−−−−−−−−−−−−−−−→

UID, DID, Gran−−−−−−−−−−→

UserLoc, UserLoc, DeviceLoc, DeviceLoc←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

BoolRes←−−−−−

Figure 8.5: Making the Authorisation Decision

If the user does not have the necessary rights, the Authorisation Server responds to

the SDO with an authorisation failure. A successful initialauthorisation check results

in the sending of a request to the DCSM to determine whether the location of the user

and device are acceptable. It should be noted that the user’srole is used for the initial

authorisation, since RBAC is being enforced, while the identity of the user is sent to

the DCSM, as the user’s location is required.

The DCSM is responsible for enforcing the context-based portion of the authori-

sation process. The aim is to ensure that user’s request to access the SDO method

originated from an acceptable location. That checking involves the following steps.

1. Based on the SDO method being invoked, the DCSM determinesthe required

granularity of location information required and then requests the location of the

user and communicating device (to that granularity) from the Location Server.

2. The Location Server returns the most recent location of the user and device, and

the times at which those locations were determined.

3. The DCSM verifies that the user and device locations coincide and that location

is consistent with the access control policy requirements.The result of the access

control check, a Boolean value, is returned to the Authorisation Server.

4. The Authorisation Server returns either the negative result from its original au-

thorisation check or the authorisation decision from the DCSM to the SDO.


AS ACUBoolRes←−−−−−

Figure 8.6: Authorisation Response

SDO Performs the Service

The authorisation decision provided by the ACU determines whether SDO will per-

form the requested service. Whether successful or not, the SDO will log the event. A

critical requirement of the behaviour of the SDO to an authorisation failure is that the

action taken must not cause the system to enter an unsafe state. If required, the SDO

returns the result of performing the service to the user.

U ASSerRes←−−−−

Figure 8.7: Reponse for Service

8.4 An Implementation Scenario

To illustrate how the architecture might be used in practice, its applicability to the

protection of an effluent treatment unit of a sulphuric acid plant will be discussed.

A sulphuric acid plant was chosen because of the commercial importance of sulphuric

acid and the potential for a major disaster should a successful attack be mounted against

the plant. The chemical is highly corrosive and can penetrate deep into the lung cavity

causing respiratory distress in humans and other animals. It is also a source of acid

rain. Consequently, tough legislative requirements applyto the release of sulphuric

acid into the environment.

8.4.1 Analysis of the infrastructure

The control system in the acid plant would adhere to the architecture shown in Fig-

ure 8.1. In the sulphuric acid plant, theRemote/Local Controlswould correspond to

the monitoring and control units for effluent treatment, gascleaning, etc. The efflu-

ent treatment control unit is in turn responsible for the correct operation of numerous

devices including: sensors for monitoring pH, pressure, temperature; gate and safety

valves.

8.4. An Implementation Scenario 143

When deciding which software objects within the control system should be self-

defending, the functionality provided by all components from theSupervisory Control

and Monitoring Unit to individual valve control objects, needs to be subjected to a

risk analysis. Such an analysis would be performed, as part of the standard analysis

process, to determine what operations, users acting in particular roles, should be able

to perform. When using the proposed architecture, there is an additional requirement

to specify the locations from which the user may perform these operations.

Software objects, which perform highly sensitive operations, and so pose a serious

safety, operational or other risk if under unauthorised (and probably external) con-

trol, should be made self-defending. As argued previously,making too many objects

self-defending might overload and undermine the performance of the access control

unit, leading to delays, which might compromise the safe andcritical operation of the

system.

8.4.2 Four Scenarios

Legitimate users of the control system, following authentication, are issued with an

authorisation token which certifies their identities, current role and their communicat-

ing device. When the user requests the service, say open effluent treatment control

valve 1, that token forms part of the request. This valve is a wireless controlled valve,

which releases effluent to the environment. Since it provides a very sensitive service,

it should be protected by an SDO. The access control rules stipulate that the service

is only available to effluent treatment control staff, usingeither a control room work-

station or their company issued handheld device, which mustbe located within the

effluent treatment precinct. The valve 1 SDO on receiving a request uses the token to

verify that the user is permitted to open the value, before the valve is opened. Details

of the authorisation process are provided in subsection 8.3.4. To demonstrate how

the authorisation process used by SDOs helps to safeguard the correct operation of

the plant, attempts made by three users to open valve 1 will beconsidered. The three

individuals are:

1. User Ais an employee who is working in the effluent treatment unit and has the

right to control the flow of effluent. She has been assigned a registered handheld

wireless device A and has been authenticated.

2. User B is also an employee of the plant but belongs to a different operational

unit and so is not permitted to control the flow of effluent. He has been assigned


a registered handheld wireless device B and has been authenticated.

3. User Cis an external entity who is not associated with the plant butis in posses-

sion of user A’s registered wireless device.

We consider the following four scenarios

Scenario 1: User A Attempts to Release Effluent into the Environment

User A sends an open request to the valve SDO which includes A’s authorisation token

(which includes the ID of Device A). An authorisation request is sent to the ACU. The

Authorisation Server determines that User A is permitted toopen the valve, provided

the request was sent from an appropriate location. The DCSM establishes that both

User A and her handheld device are in the effluent treatment precinct, returns a positive

response to the Authorisation Server that in turn, returns the positive response to the

valve SDO. The valve SDO, opens the valve and logs the event. Thus, the normal

operation of the plant is not disrupted. If however, the authorised user was performing

a malicious attack, details of the action, which were recorded by the SDO will facilitate

further investigation.

Scenario 2: External Attack by User C Using a Stolen Registered Wireless Device

Assume that User C has managed to breach the security on User A’s device (which

was stolen while ‘off site’) and thus has obtained a valid authorisation token. He was,

however, unable to breach the physical security surrounding the plant. User C sends

an open request to the valve SDO, which in turn, sends an authorisation request to

the ACU. The request will be authorised by the authorisationserver, so the request is

forwarded to the DCSM. The DCSM requests the location of the Device A and User A

from the Location Server. The DCSM will almost certainly reject the request because

either User A, and certainly Device A are not within the effluent treatment precinct,

or because User A had reported the loss of Device A would no longer be registered.

The SDO will log the event and return the failure reply to UserC. Thus, despite a

powerful base from which to mount the attack, an attack from outside the perimeter

will not succeed. One would assume that either the attemptedaccess to the system

from outside the plant perimeter, or the use of a stolen device, would have triggered an

alarm at the control centre.

8.5. Conclusions 145

Scenario 3: User B Launches an Attack

User B sends an open request to the valve. The valve SDO sends an authorisation

request to the ACU. The authorisation server checks the access rights of User B, and

finds he does not have the right to open the valve and so rejectsthe request. An autho-

risation failure is returned to the valve SDO that sends a rejection response to User B,

and logs the failed request.

Scenario 4: User B has Possession of Device A and Requests theService

The scenario is similar to the previous scenario except thatthis time User B has stolen

User A’s device (on which she has already been authenticated). When User B again

makes the open valve request, the authorisation process will proceed as far as the

DCSM. On this occasion, the attack may or may not be successful. Provided User

B and hence Device A remain within the effluent treatment precinct, User A is also

there and the authorisation token is still valid (has not timed out), this attack will be

successful. It was only successful because a valid authorisation token was presented

and both User A and their device were within the required area. If however, any of

these conditions was not met, the attack will fail. Whether successful or not, the event

will be logged and the appropriate action will be taken by theSDO.

8.5 Conclusions

In this Chapter, we have extended the existing secure heterogeneous location archi-

tecture. The extension has enabled the use of location information to defend critical

infrastructures from internal and external attacks. The use of SDOs to protect in-

dividual components provides multilayered protection that enhances the security of

critical infrastructures by supplementing the existing border protection mechanisms.

The proposed architecture is applicable to SCADA systems and so permits the addi-

tion of security to legacy systems. It should be noted that the proposed architecture

and the case study is targeted at emphasising that the designed heterogeneous location

architecture can be easily extended to security applications. In addition, the proposed

application demonstrates the benefits towards a heterogeneous location networks that

can support’s multiple applications, devices media and platforms.

Chapter 9

Conclusion

The key contribution of this thesis is the design of a secure and privacy assured ar-

chitecture that can explore the effective use of contextualinformation across multiple

devices, domains, access technologies and networks. The field of context aware com-

puting has been rapidly growing during the past three years (2001-2004) and one of

the outcomes of the research is an in-depth understanding ofup to date knowledge in

the field of context aware computing. In the process we have,

• identified drawbacks in existing location determination systems,

• designed secure light weight cryptographic protocols,

• identified the advantage of using a formal mechanisms in secure system design,

• proposed an access control mechanism for securing the flow ofinformation, and

• explored the use of location information to secure criticalinfrastructures.

9.1 Summary of Research

In Chapter 2 a detailed review of existing location based applications, the technologies

and the mechanisms for sensing location was carried out. This review identified the

issues that need to be resolved in the field of context aware computing and emphasised

how to design a secure and privacy assured heterogeneous location architecture.

Chapter 3 analysed the various methodologies for designingsecure systems. A

methodology for designing the secure heterogeneous architecture was decided based

147

148 Chapter 9. Conclusion

on the correctness by construction approach and secure systems approach. The method-

ology aimed at exploring the advantages of various formal mechanism to design a se-

cure system. The chapter also presented a brief review of theformal mechanisms used

in our system development.

Based on the issues identified a detailed requirement analysis of the functional

and security requirements was carried out in Chapter 4. Based on an evolutionary

approach suitable framework for the architecture was chosen. A preliminary analysis

of the latency, trust and security requirements was carriedout. An ideal framework

that suited the requirements was chosen for further development.

Provably secure communication protocols were designed forthe proposed frame-

work in Chapter 5. A novel 3 Party Key Distribution (3PKD) protocol was designed

using the Canetti-Krawczyk approach. The protocols were integrated with the frame-

work designed in Chapter 4. This resulted in a secure architecture that could assure the

security and privacy of the user. The architecture was compared to the requirements

that were documented in Chapter 4 and further enhancements to the architecture were

identified.

In Chapter 6 a formal model was designed for sharing of context information be-

tween co-existing applications. The proposed model provides an access control mecha-

nism to add and remove applications by the application service providers (ASP) which

assures that the privacy of the user is not compromised as a result of sharing the lo-

cation information between co-existing applications. Themechanism was described

using the lattice model and formally represented using Z. The Possum animation tool

was used to explore the functionality of the proposed model.

The prototype implementation of the proposed architecturewas described in Chap-

ter 7. The results of the implementation were also presentedin this section. The section

analysed the overhead caused due to the use of secure communication protocols and

the incorporation of security mechanisms in the proposed architecture.

In Chapter 8, a mechanism to assure security of critical infrastructure using loca-

tion based authentication and authorisation mechanism wasexplored. The mechanism

was based on the use of self-defending objects and location based authentication and

authorisation. A hypothetical chemical plant scenario wasused to illustrate the use of

the proposed mechanism. The proposed architecture is expected to help negate the se-

curity vulnerabilities introduced through the use of general purpose computer systems

and wireless technology to control critical infrastructure.

9.2. Future Work 149

9.2 Future Work

There are a large number of areas that have been left open for future research in the

field of context aware computing and secure system design mechanisms.

9.2.1 Location Based Applications

The designed architecture addressed a number of major concerns that hindered the

growth of the field such as the privacy of the user and securityof communication

medium. The architecture also provides the platform to access services in multi do-

main, multi medium and multi technology. This new flexibility is very useful in the

development of new context aware applications in commercial, social and informa-

tion security environments. Some of the potential applications that can be developed

include automated emergency systems, user behavior based security systems and loca-

tion based dynamic insurance mechanisms.

9.2.2 Location and Information Management

The designed architecture uses the existing location management system. There is a

need for better location management systems that can provide the location information

more precisely to the users. The issue of location negotiation and formation of location

data set from multiple locations needs to be carried out in the future. The need for

tamper resistant location determination mechanism for security applications remains

an important requirement that needs to be addressed.

Though the current architecture uses non-repudiation for assuring the user adheres

to the stated privacy policy, a deniable approach to location information management

can be more effective. This approach needs to be designed as part of the future work.

9.2.3 Privacy Policies and Anonymity

Future research has to look at mechanisms to provide anonymity to the user based on

the user’s preferences and nature of service requested by the user. Though there exist

a lot of commercially available tools for providing these levels of anonymity, research

has to be carried out to select the best approach and tailor the same for a heterogeneous

location network. Also there is a need to document privacy policies that can be used

for negotiation the privacy of the user effectively. The policy management system used

by P3P can be the ideal starting point for this area.

150 Chapter 9. Conclusion

9.2.4 Secure System Design

The heterogeneous location network was designed based on a secure system design

that incorporated a wide range of formal tools. An importantfuture work would be

to document the various formal mechanisms and analyse the benefits and drawbacks

of these formal techniques in each stage of the system design. A modular approach

similar to CK approach can then be devised for design of secure systems. The new

approach can then provide various reusable modules that canbe integrated together to

design secure systems effectively.

Appendix A

Proofs for security protocols

The proof for the security for the 3PKD in AM and the MT authetnicator is provided

in this Appendix. The protocols are presented in chapter 5.

A.1 Proof of security – 3PKD in AM

Theorem 3. Let Π1 be the symmetric encryption scheme andΠ2 be the asymmetric

encryption scheme used in protocol 3PKD. The protocol 3PKD is SK-secure in the

authenticated links model (AM) if the encryption schemesΠ1 andΠ2 are secure under

chosen plaintext attacks.

Proof Since the protocol 3PKD is a key distribution protocol, it iseasy to see that

both partiesU andA are in possession of the same session key upon the completion

of the protocol execution and therefore satisfies the first condition of SK-security in

Definition 1 presented in chapter 3 of Chapter 3.3.1. Note that uncorrupted parties

behave according to the protocol specification. This proof concentrates on proving

that the second condition of the SK-security.

Let Π∗ be the bi-encryption scheme constructed fromΠ1 andΠ2. Let A be an

adversary against the protocol 3PKD. Letǫ be the advantage ofA in distinguishing

between a session key and a random value of the same length. Weshow that ifǫ is

non-negligible, then at least one ofΠ1, Π2 can be broken, thus reaching a contradiction.

For simplicity, message routes are modified such thatA has a direct link withS.

That is, the routes are now:S→ U, S→ A. We stress that this alteration does not

151

152 Appendix A. Proofs for security protocols

affect the security of the protocol, as messages fromS to A can always be forwarded

by U if necessary.

We construct an algorithmX to breakΠ∗. It runsA as a subroutine. Letk∗ ←

K1(κ1) be the symmetric key and(e∗, d∗) ← K2(κ2) be the pair of asymmetric keys

used in 3PKD. Following the definition of Security Notion of Bi-encryption in IND-

CPA, X first computesσ0R← Sn(1κ) andσ1 ∈R {0, 1}

|σ0|. The challenges thatX

receives are a pair of ciphertext(µ∗U

R← Ek∗(σb), µ

∗A

R← Ee∗(σb)) whereb ∈R {0, 1}.

Resources available toX are the public keye∗, access to the bi-encryption oracle

E∗(·) = (Ek∗(·), Ee∗(·)) and the session key generatorSn(·). X then proceeds as fol-

lows:

1. MachineX sets up a virtual scenario for the run of protocol 3PKD and activates

A against the virtual run. The adversaryA has control of the communication

channels and schedule of all operations. The scheduled operations are performed

byX on behalf of all virtual players in the virtual scenario for the run of protocol

3PKD. Virtual players include server, user and service provider. The simulation

takes into consideration of the possession of keys of different parties.

2. At setup stage of the virtual protocol run,X chooses randomly a serverS∗ from

all possible servers(S1, . . . , Sn) in the virtual run of the protocol. SimilarlyX

chooses randomly a userU∗ and a service providerA∗ from a list of imitated

users(U1, . . . , Uu) and service providers(A1, . . . , Aa) respectively. We usen

(resp. u and a) to denote the maximum number ofS (resp. U and A) that

can be invoked in the virtual protocol run. Since multiple sessions are possi-

ble amongst the chosen parties(S∗, U∗, A∗), X picks s∗ ∈R {1, . . . , l}, where

l denotes the maximum number of sessions between the chosen parties, as its

guess on whichA will choose as the test session. That is, the chosen session by

X is (S∗, U∗, A∗, s∗).

3. All long-term symmetric keys and asymmetric key pairs arechosen byX except

for the case ofU∗ andA∗. X providesA with all public keys for all service

providersAi 6= A∗. The input public key toX , e∗, is used as the public key ofA∗.

4. All session establishments are executed byX according to the protocol specifi-

cation except the chosen session. Whenever a sessions 6= s∗ is invoked byA,

X runsSn(1κ) to obtain a session keyσi. If U∗ is not involved in the sessions,

encryptions of the session key can easily be computed because of the complete

A.2. Proof of Security– MT-authenticator 153

knowledge of the long term keys. IfU∗ is involved in the sessions, X accesses

the encryption oracle(C1, C2)R← E∗(σi) and returnsC1 as the encryption ofσi

for U∗. This simulation is perfect fromA’s point of view. If S∗ is activated for

establishing a session betweenU∗ andA∗ at sessions∗,X sendsµ∗U andµ∗

A to U∗

on behalf ofS∗ and sendsµ∗A to A∗ on behalf ofU∗.

5. All exposure against sessions 6= s∗ can be answered byX with its knowledge of

keys. If a session reveal is scheduled against the sessions∗, a corruption against

U∗, A∗ or S∗, or a different test session(Si, Uj, Ak, s) 6= (S∗, U∗, A∗, s∗) is chosen

byA, X aborts the run ofA and outputs a bitb′ ∈R {0, 1} as its guess onb.

6. If A queries the test sessions∗, X returns(µ∗A, µ

∗U) to A. We stress that no

exposure against the test session(S∗, U∗, A∗, s∗) can be performed after the test

key is returned.

7. If A halts and outputs a bitb′, thenX halts and outputs the same bit.

By runningA as a subroutine,X can break the bi-encryption schemeΠ∗ with

overall probability12

+ ǫ

l·n·u·a. This is derived from the probability thatA chooses the

correct test session(l · n · u · a)−1 and the exact probability of guessing correct the bit

b whenA is aborted. The advantageǫ

l·n·u·a is non-negligible.

By Theorem 21, the maximum advantage of the adversary attacking bi-encryption

schemeΠ∗ under CPA is the sum of the advantages of the adversaries attackingΠ1 and

Π2. If Π∗ can be broken under CPA with non-negligible advantage, thenat least one of

Π1, Π2 can be broken with non-negligible advantage. This contradicts our assumptions

in section A.1.

A.2 Proof of Security– MT-authenticator

We now proceed to show that the protocolλTimeSig is a valid MT-authenticator. Assume

that the signature scheme is secure against adaptive chosenmessage attack in the con-

vention of Goldwasser, Micali and Rivest [44] and is thus existentially non-forgeable.

We make the following claim.

1

Theorem 4 ( [9]). If the encryption schemesΠ1 and Π2 are secure under CPA, then the encryptionschemeΠ∗ is secure under CPA. More precisely:

AdvcpaΠ∗(A

cpa,E∗(·)Π∗ ) ≤ Advcpa

Π1(A

cpa,E1(·)Π1

) + AdvcpaΠ2

(Acpa,E2(·)Π2

) (A.1)


Theorem 5. Assume that the signature scheme with message recovery in use is se-

cure under adaptive chosen message attacks and the time of protocol participants is

synchronised. Then protocolλTimeSig emulates protocol MT.

Proof Let U be a UM-adversary that interacts withλTimeSig . We construct an AM-

adversaryA such that the outputs of runningU in the UM and runningA in the AM

are equally distributed except with negligible probability. AdversaryA runsU as a

subroutine on a simulated interaction with a set of parties runningλTimeSig . Note that

adversaryU interacts with some imitated partyA′ in the unauthenticated networks

while adversaryA interacts with some imitated partyA in the authenticated networks.

In the imitated run of the protocol,A first chooses and distributes keys for the

imitated parties according to functionI. When setup is completed, the interaction

runs according to the following rules:

1. WheneverU activates some imitated partyA′ for sending a messagemto imitated

party B′, adversaryA activates partyA in the authenticated network to sendm

to B.

2. When some imitated partyB′ outputs ‘B′ received m fromA′’, adversaryA acti-

vates partyB in the authenticated-links model with incoming message m fromA.

3. WheneverU corrupts a party,A corrupts the same party in the authenticated

network and hands the corresponding information (from the simulated run) toU .

4. Finally,A outputs whateverU outputs.

It is easy to verify that the behaviour ofA is legitimate model except for step two.

In step two, it is possible that partyA is uncorrupted and the message(m, A, B) is not

currently in the set of undelivered messagesM. More precisely, it is the case where

B′ outputs ‘B′ received m from A′’, but eitherA was not activated for sendingm to B,

or B has already had the same output before(m, A, B) expires. This case indicates that

U broke partyA′. We denote this event byB.

If step two can always be carried out such thatB does not occur, then it is clear that

the simulation run byA is perfect and the output ofA andU is equally distributed.

Thus, we need to show that eventB occurs only with negligible probabilityǫ(κ) where

κ is the security parameter.

To prove the negligible probability of occurrence of eventB, we construct a forger

F that breaks the signature scheme with probabilityǫ(κ)/p wherep is the number of

A.2. Proof of Security– MT-authenticator 155

parties. The forgerF runsU on a simulated interaction with a set of parties running

λTimeSig with input a public keypk∗. Access to a signing oracleO(Sigsk∗(·)) is allowed for

modelling adaptive chosen message attacks. Note that the private keysk∗ is not known

byF and thatF runsU in the same way asA runsU . It then proceeds as follows:

1. F chooses and distributes key pairs(pki , ski) wherei ∈ {1, . . . , p} for the imi-

tated parties according to functionI, with the exception that the public key with

a randomly chosen partyP∗ is replaced with the input keypk∗.

2. If U corrupts partyP∗, thenF fails and aborts the simulation.

3. If F is required to sign some valuel on behalf of some imitated partyPi 6= P∗,F

generates the signature using its knowledge of the private keyski. When partyP∗

is required to sign some valuel, F asks its signing oracleO(Sigsk∗(l)) to obtain

a valid signature.

4. If some partyQ outputs ‘Q received m from P∗’, whereP∗ was not activated to

sendm toQ or Q has already output this value before,F is successful in breaking

the signature scheme and outputs the signature in the last incoming message that

Q received.

First note thatU ’s view of the interaction withF is identically distributed toU ’s

view of a real interaction in an unauthenticated network unlessF fails and aborts the

simulation. LetB∗ be the event whereB occurs in the simulated run ofU within F ,

and that the party broken byU is P∗. Note that if eventB∗ occurs,F does not fail. If

F fails, eventB∗ does not happen. Thus the probability of failure in the simulation run

byF is at leastǫ(κ)/p because of the random choice ofP∗.

Assume that eventB∗ occurs. The occurrence of eventB∗ implies that the signature

thatQ received in its last incoming message is a valid signature ofthe value (m,ΥP∗ , Q),

but P∗ never generated this particular signature.

Two cases were identified that might have happened corresponding to eventB∗.

First,P∗ was not activated to sendm to Q. Second,Q has already had the same output

before. In the first case it is clear that ifP∗ was not activated to sendm to Q, P∗ never

signed the message.

If Q outputs the same value twice before the time stamp associated with the first

m has expired, then the signature thatQ received in its last incoming message is valid

and fresh such that it was signed withsk∗ and on input the signatureV returns ‘TRUE’.

However, recall thatQ maintainsL where accepted messages and their respective time


stamps are stored, no messages together with the same time stamp are repeated inL.

It follows thatP∗ only sentm once and thus only signed the signature once where the

time stamp was different to the time stamp in the last signature thatQ received. Recall

again thatP∗ generates a new time stamp with each new message, the time stamp in

the last signature thatQ received was not generated byP∗. ThereforeF (on behalf of

P∗ for signatures) has only asked its signing oracle once. As a result,F never asked

its oracle for the last signature.

Consequently,F has successfully broken the signature scheme.

Remark 4. In fact it is possible thatQ outputs the same value twice or more times

referring to records that are not in the current set of records inL. If the sender sends

the same messagem many times,Q will acceptm provided the time stamp is fresh

and unique, and the signature is valid. Note that time stampsfrom the same sender are

different for different messages. z

Appendix B

The Possum verification script

The following example helps us to have a experience of how Possum can help us in

validation and determination of the functionality of the methodology. The changes at

each state help trace any errors in the process.#possumsessionfile

1 sum: !!PC S!!

file ‘/usr/local/possum/Examples/Spec.sum’

!!P C F!!

Yes

2 sum: !!PC S!!

param currentmodule ASP

!!P C F!!

Yes

First the application is initilised. The following schema shows the init state of the

application.

3 ASP: !!PC S!! init !!P C F!!

[Addedapps’ :={},

AppMaxRights’ :={},

AppMinRights’ :={},

Setapps’ :={},

157

158 Appendix B. The Possum verification script

ASPmaxrights’ :=

(NO, BLOCK, RELAY, REQUEST),

(USER, BLOCK, RELAY, REQUEST),

ASPminrights’ := (NO,{}), (USER,{})]

The first application is set . It can be observed that the ASP minimum and maxi-

mum rights still remain the same as initial state.

4 ASP: !!PC S!!

Set 1/app?,

(USER,RELAY),(NO,RELAY)/ASPminrights?,

(USER,RELAY,REQUEST,BLOCK),

(NO,RELAY,REQUEST,BLOCK)/ASPmaxrights? !!PC F!!

[Addedapps :={}, AppMaxRights :={},

AppMinRights :={}, Setapps :={},

ASPmaxrights := (NO, BLOCK, RELAY, REQUEST),


ASPminrights := (NO,{}), (USER,{}), Addedapps’ :={},

AppMaxRights’ := ((NO, 1), BLOCK, RELAY, REQUEST),

((USER, 1), BLOCK, RELAY, REQUEST),

AppMinRights’ := ((NO, 1), RELAY),

((USER, 1), RELAY), Setapps’ := 1,

ASPmaxrights’ := (NO, BLOCK, RELAY, REQUEST),



The second application is set . The minimum and maximum rights of the ASP still

remain the same as init state.

5 ASP: !!PC S!!

Set 2/app?, (USER,RELAY,REQUEST),

(NO,RELAY,REQUEST)/ASPminrights?,

(USER,RELAY,REQUEST),

(NO,REQUEST,RELAY)/ASPmaxrights?

!!P C F!!

[Addedapps :={},

159

AppMaxRights :=

((NO, 1), BLOCK, RELAY, REQUEST),


AppMinRights := ((NO, 1), RELAY),

((USER, 1), RELAY),

Setapps := 1,

ASPmaxrights :=



ASPminrights := (NO,{}), (USER,{}),

Addedapps’ :={},

AppMaxRights’ :=


((NO, 2), RELAY, REQUEST),


((USER, 2), RELAY, REQUEST),

AppMinRights’ :=

((NO, 1), RELAY), ((NO, 2), RELAY, REQUEST),

((USER, 1), RELAY),((USER, 2), RELAY, REQUEST),

Setapps’ := 1, 2,

ASPmaxrights’ :=




The first application is added. The minimum and maximum rights of the ASP are

set to the applications minimum and maximum rights.

6 ASP: !!PC S!!

Add 1/newapp? !!PC F!!

[Addedapps :={},

AppMaxRights :=






AppMinRights :=



Setapps := 1, 2,

ASPmaxrights :=



ASPminrights :=

(NO, {}), (USER,{}),

Addedapps’ := 1,

AppMaxRights’ :=





AppMinRights’ :=



Setapps’ := 1, 2,

ASPmaxrights’ :=



ASPminrights’ :=

(NO, RELAY), (USER, RELAY)]

The second application is added. The minimum and maximum rights of the ASP

are set based on the specified methodology. We can also observe that conditions still

hold true.

7 ASP: !!PC S!!

Add 2/newapp?!!PC F!!

[Addedapps := 1,

AppMaxRights :=


161




AppMinRights :=

((NO, 1), RELAY),((NO, 2), RELAY, REQUEST),


Setapps := 1, 2,

ASPmaxrights :=



ASPminrights :=

(NO, RELAY), (USER, RELAY),

Addedapps’ := 1, 2,

AppMaxRights’ :=





AppMinRights’ :=

((NO, 1), RELAY),((NO, 2), RELAY, REQUEST),


Setapps’ := 1, 2,

ASPmaxrights’ :=

(NO, RELAY, REQUEST),(USER, RELAY, REQUEST),

ASPminrights’ :=

(NO, RELAY, REQUEST), (USER, RELAY, REQUEST)]

The first application is removed. Since the minimum rights ofthe application must

be equal to the minimum rights of the second application irrespective of removing the

first application. This holds true thus the methodology is true and is validated for re-

moving of applications.

8 ASP: !!PC S!!

Remove 1/oldapp?!!PC F!!

[Addedapps := 1, 2,


AppMaxRights :=





AppMinRights :=



Setapps := 1, 2,

ASPmaxrights :=

(NO, RELAY, REQUEST),(USER, RELAY, REQUEST),

ASPminrights :=

(NO, RELAY, REQUEST), (USER, RELAY, REQUEST),

Addedapps’ := 2,

AppMaxRights’ :=





AppMinRights’ :=



Setapps’ := 1, 2,

ASPmaxrights’ :=

(NO, RELAY, REQUEST),

(USER, RELAY, REQUEST),

ASPminrights’ :=

(NO, RELAY, REQUEST), (USER, RELAY, REQUEST)]

The second application is removed. The minimum and maximum rights of the ASP

are set to the initial condition as there is no application inthe set of added applications.

9 ASP: !!PC S!!

Remove 2/oldapp? !!PC F!!

[Addedapps := 2,

163

AppMaxRights :=





AppMinRights :=



Setapps := 1, 2,

ASPmaxrights :=



ASPminrights :=



Addedapps’ :={},

AppMaxRights’ :=





AppMinRights’ :=



Setapps’ := 1, 2,

ASPmaxrights’ :=



ASPminrights’ :=

(NO, {}), (USER,{})]

Bibliography

[1] 3rd Generation Partnership Project (3GPP).Location Services (LCS) Service de-

scription, Stage1. 3rd Generation Partnership Project (3GPP)- TS22.071, 2003.

[2] M. Addlesee. ORL Active Floor . InIEEE Personal Communications, pages

35–41. IEEE Press, October 1997.

[3] R. Agrawal, J. Kiernan, R. Srikant, and Y. Xu. Server Centric P3P. InW3C

Workshop on the Future of P3P. W3C, November 2002.

[4] P. Amey. Correctness by Construction: Better Can Also BeCheaper. Technical

report, Software Technology Support Center, 2002.

[5] Australian Communication Authority (ACA). Location Location Location.Dis-

cussion Paper, Australian Government, January 2004.

[6] P. Bahl and V.N. Padmanabhan. RADAR : An In-Building RF-Based User Lo-

cation and Tracking System . InIEEE Infocom, pages 775–784, March 2000.

[7] G. Baratoff and S. Blanksteen. Tracking Devices. Technical report, Human In-

terface Technology Laboratory,http://www.hitl.washington.edu/

scivw/EVE/I.D.1.b.TrackingDevices.html, September 2004.

[8] G. Barker. Cyber terrorism a mouse-click away.The AGE Newspaper, July

2002.

[9] O. Baudron, D. Pointcheval, and J. Stern. Extended Notions of Security for

Multicast Public Key Cryptosystems. In27th international Colloquium on Au-

tomata, Languages and Programming, pages 499–511. Springer-Verlag, July

2000.

165

166 BIBLIOGRAPHY

[10] M. Bellare, R. Canetti, and H. Krawczyk. A Modular Approach to the Design

and Analysis of Authentication and Key Exchange Protocols.In 30th Annual

Symposium on the Theory of Computing, pages 412–428. ACM, 1998.

[11] M. Bellare and P. Rogaway. Random Oracles are Practical: A Paradigm for De-

signing Efficient Protocols. InFirst ACM Conference on Computer and Com-

munications Security, pages 62–73. ACM, 1993.

[12] S. Benford, R. Anastasi, M. Flintham, C. Greenhalgh, N.Tandavanitj,

M. Adams, and T. Row-Farr. Coping with Uncertainty in a Location-Based

Game. InPervasive Computing. IEEE Press, July-September 2003.

[13] V. Bharghavan and C.V. Ramamoorthy. Security Issues inMobile Commu-

nications. InSecond International Symposium on Autonomous Decentralized

Systems, 1995.

[14] S. Bjork, J. Falk, R. Hansson, and P. Ljungstrand. Pirates! Using the Physical

World as a Game Board. InConference on Human-Computer Interaction, pages

9–13. International Federation for Information Processing, July 2001.

[15] C. Boyd and P. Kearney. Exploring Fair Exchange Protocols Using Specification

Animation. InInformation Security Workshop, pages 209–223. Springer-Verlag,

2000.

[16] J. Caffery and G. Stber. Overview of Radiolocation in CDMA Cellular Systems.

In Communications Magazine, pages 38 – 45. IEEE Press, April 1998.

[17] R. Canetti and H. Krawczyk. Analysis of Key-Exchange Protocols and Their

Use for Building Secure Channels. InAdvances in Cryptology - Eurocrypt,

pages 453–474. Springer-Verlag, 2001.

[18] R. Canetti and H. Krawczyk. Analysis of Key-Exchange Protocols and Their

Use for Building Secure Channels.Lecture Notes in Computer Science, 2045,

2001.

[19] D. Carney. Location Privacy Protection Act of 2001.Tech Law Journal,

2001. http://www.techlawjournal.com/cong107/privacy/

location/s1164is.asp.

[20] J.R. Chapman. Software Development Methodology. Internet, 1997.http:

//www.hyperthot.com/pmsdm.htm.

BIBLIOGRAPHY 167

[21] G. Chen and D. Kotz. A Survey of Context-Aware Mobile Computing Research.

Technical report, Dept. of Computer Science, Dartmouth College, November

2000.

[22] T. Christ and P. Godwin. A Prison Guard Duress Alarm Location System. InIn-

ternational Carnahan Conference on Security Technology. IEEE Press, October

1993.

[23] D.A. Cooper and K.P. Birman. The Design and Implementation of a Private

Message Service for Mobile Computers.Wireless Networks - Kluwer Academic

Publishers, 1(3):297–309, 1995.

[24] Cospas-Sarsat. Handbook of Regulations on 406 MHz and 121,5 MHz Beacons.

Technical Report C/S S.007, September 2004.

[25] L. Cranor, M. Langheinrich, M. Marchiori, M. Presler-Marshall, and J. Rea-

gle. The Platform for Privacy Preferences 1.0 (P3P1.0) Specification. Technical

report, World Wide Web Consortium, April 2002.

[26] J. Cuellar, J.B. Morris, D. Mulligan, J. Peterson, and J. Polk. Internet-drafts: Ge-

ographic location/privacy (geopriv) requirements. Technical report, Geographic

Location/Privacy (GeoPriv), IETF, March 2003.

[27] D. Hazel and P. Strooper and O. Traynor. Possum: An Animator for the SUM

Specification Language. InFourth Asia-Pacific Software Engineering and In-

ternational Computer Science Conference, page 42. IEEE Press, 1997.

[28] P.H. Dana. Global Positioning System Overview. Internet, May

2000. http://www.colorado.edu/geography/gcraft/notes/

gps/gpsf.html.

[29] P. Davidson. Enhanced 911 Calls Still Far from Wide Coverage.USA TODAY,

October 2002.

[30] D. Delbrouck. Mobiloco Testet Location Based Service ‘Buddy Alert’. ZDNet,

20, January 2003.

[31] A. J. Demers. Research Issues in Ubiquitous Computing.In Thirteenth An-

nual ACM Symposium on Principles of Dstributed Computing, pages 2–8. ACM

Press, 1994.

168 BIBLIOGRAPHY

[32] Y. Deng and J. Wang et.al. An Approach for Modelling and Analysis of Se-

curity System Architectures. InIEEE Transactions on Knowledge and Data

Engineering, pages 1099–1119. IEEE Press, September 2003.

[33] D.E. Denning. A Lattice Model of Secure Information Flow. Communications

of the ACM, 19(5):236–243, 1976.

[34] D.E. Denning. Cyber Terrorism. Testimony Before the Special Oversight Panel

on Terrorism, Committee on Armed Services, U.S. House of Representatives,

May 2000.

[35] S. Duri and et.al. Framework for Security and Privacy inAutomotive Telemat-

ics. In 2nd International Workshop on Mobile Commerce, pages 25–32. ACM

Press, 2002.

[36] R. Enderle. Using Tech To Help Supervise Children.TechNewsWorld, July

2004.

[37] European Telecommunications Standards Institute. GSM 02.60 - LCS Stage-1

Service Description.GSM Technical Specificaton, April 1999.

[38] Dacey F. Critical Infrastructure Protection: Challenges in Securing Control

Systems. Technical report, United States General Accounting Office, October

2003.

[39] A. Finkelstein and J. Dowell. A Comedy of Errors: the London Ambulance

Service Case Study. In8th International Workshop on Software Specification

and Design. IEEE Press, 1996.

[40] G.R. Ganger and D.F. Nagle. Enabling Dynamic Security Management of via

Device-Embedded Security. Technical report, Carnegie Mellon University, De-

cember 2000.

[41] G.R. Ganger and D.F. Nagle. Better Security via SmarterDevices. InWorkshop

on Hot Topics in Operating Systems, pages 100–105. IEEE Press, 2001.

[42] R. Gellens. Wireless Device Configaration (OTASP/OTAPA) via ACAP. Tech-

nical report, RFC:2636, Network Working Group -The Internet Society, 1999.

[43] D.J. Gersuk and J. Burfening. Mapinfo-Factsheet.One Global View, Troy, New

York, 2002.

BIBLIOGRAPHY 169

[44] S. Goldwasser, M. Sipser, and R. Rivest. A Digital Signature Scheme Se-

cure Against Adaptive Chosen-Message Attack.SIAM Journal of Computing,

17(2):281–308, 1988.

[45] S. Graf, O. Haugen, I. Ober, and B. Selic, editors.1st workshop on Specification

and Validation of UML models for Real Time and Embedded Systems. Verimag

Technical Report, 2003.

[46] D. Green and A. DiCaterino. A Survey of System Development Process

Models.http://www.ctg.albany.edu/publications/reports/

survey of sysdev, February 1998.

[47] W.G. Griswold, R. Boyer, S.W. Brown, and T.M. Truong. ActiveCampus - Sus-

taining Educational Communities. Technical report, Department of Computer

Science and Engineering,University of California, San Diego, 2002.

[48] R. Harder. Base64.java 2.0.2. Internet. http://iharder.sourceforge.net/base64/

Last Accessed Thursday 6 May 2004.

[49] J. Hightower and G. Borriello. Location Systems for ubiquitous Computing .

Computer, 34(8):57–66, 2001.

[50] J.W. Holford, W.J. Caelli, and A.W. Rhodes. The Conceptof Self-Defending

Objects in the Development of Security Aware Applications.In 4th Australian

Information Warfare and IT Security Conference, Adelaide, Australia, 2003.

[51] J.W. Holford, W.J. Caelli, and A.W. Rhodes. Using Self-Defending Objects

to Develop Security Aware Applications in Java. In27th Australasian Com-

puter Science Conference, pages 341–349. Australian Computer Society, Jan-

uary 2004.

[52] ISO/IEC JTC. ISO/IEC DIS 11770-3 Information Technology - Security Tech-

niques - Key Management - Part 3: Mechanisms using Asymmetric Techniques.

International Standard, 1996.

[53] J. Juul. The Complete List of Location-based Games.http://www.

jesperjuul.dk/ludologist/index.php?p=109. Last Accessed:

August - 2004 .

170 BIBLIOGRAPHY

[54] J. Kohl and C. Neuman.The Kerberos Network Authentication Service (V5).

RFC 1510, September 1993.http://www.faqs.org/rfcs/rfc1510.

html, accessed on 11th Nov.,2003.

[55] A. Jagoe.Mobile Location Services: The Definitive Guide. Prentice Hall PTR.,

1 edition, December 2002.

[56] X. Jiang and N.Y. Chen et.al. Siren: Context-aware Computing for Firefighting.

In Alois Ferscha, Friedemann Mattern, editor,Pervasive 2004: The Second In-

ternational Conference on Pervasive Computing. Springer-Verlag Heidelberg ,

April 2004.

[57] Justice Department USA. The Privacy Act of 1974. Internet. http://www.

usdoj.gov/foia/privstat.htm Last Accessed: September 26, 2003.

[58] J. Kauffman. Wireless 9-1-1 Geolocation: A New Way to Save Lives Now.

NENA News, 2001.

[59] J. Kempf, L. Ackerman, and T. Miki. Wireless Location Privacy: A

Report on Law and Policy in the USA, the European Union, and Japan.

Technical report, Docomolabs-USA,www.docomolabs-usa.com/pdf/

DCL-TR2003-001.pdf, November 2003.

[60] G. Klyne and C. Newman. Date and Time on the Internet: Timestamps.

RFC 3339,http://www.faqs.org/rfcs/rfc3339.html, accessed

on 19th Nov.,2003, July 2003.

[61] N. Koblitz. Another Look at ’Provable Security’ . Technical report, Department

of Mathematics, University of Washington, 2004.

[62] B. Koelmel. ELBA Project Successfully Fnished. Final press release, April

2004. http://www.e-lba.com/presentations.html, accessed on

7th Feb.,2005.

[63] J. Lin, R. Laddaga, and H. Naito. Personal Location Agent for Communicating

Entities (PLACE). InInternational Symposium on Human Computer Interaction

with Mobile Devices, Pisa, Italy, 2002. Springer-Verlag Heidelberg .

[64] S. Long and R. Kooper et.al. Rapid Prototyping of MobileContext-Aware Ap-

plications: The Cyberguide Case Study. InMobile Computing and Networking,

BIBLIOGRAPHY 171

pages 97–107, 1996. Short paper.http://citeseer.ist.psu.edu/

long96rapid.html.

[65] M. Looi. Enhanced Authentication Services for Internet Systems Using Mobile

Networks. InGlobal Telecommunications Conference, pages 3468 – 3472, San

Antonio, TX USA, 2001. IEEE Press.

[66] M. Lu. Electronic Commerce Over Futhure Generation Mobile Systems. Mas-

ter’s thesis, Information Security Research Centre, February 1999.

[67] B. Ludden, A. Pickford, J. Medland, H. Johnson, F. Brandon, L.E. Axelsson,

K. Viddal-Ervik, B. Dorgelo, E. Boroski, and J. Malenstein.Report on imple-

mentation issues related to access to location informationby emergency services

(E112 ) in the European Union. Technical report, Coordination Group on Access

to Location Information by Emergency Services [CGALIES), January 2002.

[68] M. Fowler and K. Scott.UML Distilled: A Brief Guide to the Standard Object

Modeling Language (2nd Edition). Addison-Wesley Professional; 2nd edition ,

1999.

[69] S. Meyers. Social Policy Issues of Mobile Games. Internet, September

2004. http://stephan.com/MobileSocial.html Last Accessed on

7th Feb.,2005.

[70] MySQL. My SQL Developer Zone. Internet.http://mysql.org/Last

Accessed Thursday 6 May 2004.

[71] N.B. Priyantha and A. Chakraborty and H. Balakrishnan.The Cricket Location-

Support System. In6th Annual ACM International Conference on Mobile Com-

puting and Networking. ACM, August 2000.

[72] North American Electric Reliability Council (NAERC) .SQL Slammer Worm

Lessons Learned for Consideration by the Electricity Sector. Technical report,

North American Electric Reliability Council,http://www.esisac.com/

publicdocs/SQLSlammer2003.pdf Last Accessed on 7th Feb.,2005,

June 2003.

[73] Open Mobile Alliance Location Inter-Operability Forum. OMA location proto-

col specification v3.0. Version 3.0.

172 BIBLIOGRAPHY

[74] R. Orr and G. Abowd. The Smart Floor: A Mechanism for Natural User Identi-

fication. InHuman Factors in Computing Systems, April 2000.

[75] J. Pike. Navigation - Overview. Internet, 2004 March.http://www.

globalsecurity.org/space/systems/nav-overview.htmLast

Accessed on 7th Feb.,2005.

[76] A. Porak. Location Based Advertising (LBA).YellowMap at a Glance,

September 2004.http://www.yellowmap.com/english/default.

aspLast Accessed on 7th Feb.,2005.

[77] K. Poulsen. Slammer Worm Crashed Ohio Nuke Plant Network. Secu-

rity Focus, August 2003. http://www.securityfocus.com/news/

6767Last Accessed on 7th Feb.,2005.

[78] E. Prigge and J. How. Signal Architecture for a Distributed Magnetic Local-

Positioning System. InFirst IEEE International Conference on Sensors, pages

12–14. IEEE Press, June 2002.

[79] R. Moritz and S. Charney. Security Across the Software Development Life

Cycle. Technical report, National Cyber Security Partnership,http://www.

cyberpartnership.org/init-soft.html, April 2004.

[80] J. Ring. Implementation and Analysis of Secure Heterogeneous Location Net-

works. Master’s thesis, Faculty of Information Technology, Queensland Univer-

sity of Technology, July 2004. Honours Dissertation.

[81] P. Rohan. Introduction to Electromagnetic Wave Propagation. Artech House

Publishers , 1991.

[82] R.S. Sandhu. A Lattice Interpretation of the Chinese Wall Policy. In 15th NIST-

NCSC National Computer Security Conference, pages 329–339. United States

Government Printing Office, 1992.http://citeseer.ist.psu.edu/

article/sandhu92lattice.html.

[83] R.S. Sandhu. Lattice-Based Access Control Models. InIEEE Computer,

pages 9–19. IEEE Press, 1993.citeseer.ist.psu.edu/article/

sandhu93latticebased.html.

BIBLIOGRAPHY 173

[84] E. Snekkenes. Concepts for Personal Location Privacy Policies. In3rd ACM

Conference on Electronic Commerce, pages 48–57. ACM Press, 2001.http:

//doi.acm.org/10.1145/501158.501164.

[85] J.M. Spivey. The Z Notation: A Reference Manual. Prentice Hall UK, 2nd

edition, 1992.

[86] J.M. Spivey. Thef UZZ Manual. Internet, 2000.http://spivey.oriel.

ox.ac.uk/∼mike/fuzz/.

[87] W. Stallings. Wireless Communications and Networks. Prentice Hall, 1st edi-

tion, August 2001.

[88] S. Stillman, R. Tanawongsuwan, and I. Essa. A System forTracking and Recog-

nising Multiple People with Multiple Cameras. Technical report, Graphics,

Visualization, and Usability Center, Georgia Institute ofTechnology,http:

//www.gvu.gatech.edu/, 1998.

[89] L.A. Stilp. TDOA - Technology for Locating Narrow Band Cellular Signals.

Mobile Radio Technology (MRT), April 1997.http://mrtmag.com/mag/

radio tdoa technologylocating/Last Accessed on 7th Feb.,2005.

[90] R. Strahan. Location Sensing Technologies. Technicalreport, University

College Dublin (UCD),emc2.ucd.ie/deliverables/e=mc2.2.1.1.

2002.doc, October 2002.

[91] J.D. Strunk and G.R. Goodson et.al. Self-Securing Storage: Protecting Data in

Compromised Systems. In4th Symposium on Operating Systems Design and

Implementation, San Diego, CA., October 2000.

[92] J.D. Strunk and G.R. Goodson et.al. Intrusion Detection, Diagnosis, and Recov-

ery with Self-Securing Storage. Technical report, Carnegie Mellon University,

http://www.pdl.cmu.edu/ftp/Secure/CMU-CS-02-140abs.

html, May 2002.

[93] Sun Microsystems. Java Cryptography Extension. Sun Microsys-

tems, January 2002. http://java.sun.com/j2se/1.4.2/docs/

guide/security/jce/JCERefGuide.htmlLast Accessed Tuesday 4

May 2004.

174 BIBLIOGRAPHY

[94] T. Samuel and Jr. Redwine and N. Davis. Towards more Secure Soft-

ware. http://www.cyberpartnership.org/Software20Pro.

pdf, March 2004.

[95] C. Tanriover. GSM Traffic Monitoring Application.Wireless World Forum,

September 2003.

[96] Technical Committee ISO/IEC JTC 1 .ISO 7498-2:1989 - Open Systems

Interconnection-Basic Reference Model-Part 2: Security Architecture. Inter-

national Organization for Standardization, 2000.

[97] The Cogito Group. The Sum Reference Manual. Technical report, Software

Verification Research Centre, University of Queensland, 1999.

[98] The Legion of the Bouncy Castle. Bouncy Castle. Internet, 2004. http:

//www.bouncycastle.org/Last Accessed Tuesday 11 May 2004.

[99] Y. Wang and X. Jia et.al. An Indoors Wireless Positioning System Based on

Wireless Local Area Network. In6th International Symposium on Satellite Nav-

igation Technology Including Mobile Positioning and Location Services. SAT-

NAV, July 2003.

[100] R. Want and A. Hopper et.al. The Active Badge Location System. ACM

Transactions on Information Systems (TOIS), pages 1046–8188, 1992.http:

//doi.acm.org/10.1145/128756.128759.

[101] R. Want and A. Hopper. Active Badges and Personal Interactive Computing

Objects. In IEEE Transactions on Consumer Electronics, pages 10–20. IEEE

Press, 1992.

[102] WAP and W3C. Report from WAP-W3C Joint Workshop on Mobile Web Pri-

vacy. Technical report, WAP and W3C, 2000.http://www.w3.org/P3P/

mobile-privacy-ws/report.html.

[103] A. Ward. Sensor-driven Computing. PhD thesis, University of Cambridge,

1998.

[104] M. Weiser. The computer for the 21st Century.Scientic American, pages 94–

104, 1991.

BIBLIOGRAPHY 175

[105] C. Wullems, M. Looi, and A. Clark. Enhancing the Security of Internet Ap-

plications Using Location: A New Model for Tamper-Resistant GSM Location.

In International Symposium on Computers and Communication, pages 1251–

1258. IEEE Press, 2003.

[106] M.A. Youssef. Location Determination Papers. Internet, March 2003.http:

//www.cs.umd.edu/∼moustafa/locationpapers.htm.

secure, privacy assured mechanisms for heterogeneous ... · for heterogeneous location network....

Documents