Abstracting application-level security policy for ubiquitous computing

Technical ReportNumber 613

Computer Laboratory

UCAM-CL-TR-613ISSN 1476-2986

Abstracting application-level securitypolicy for ubiquitous computing

David J. Scott

January 2005

15 JJ Thomson AvenueCambridge CB3 0FDUnited Kingdomphone +44 1223 763500

http://www.cl.cam.ac.uk/

c© 2005 David J. Scott

This technical report is based on a dissertation submittedSeptember 2004 by the author for the degree of Doctor ofPhilosophy to the University of Cambridge, RobinsonCollege.

Technical reports published by the University of CambridgeComputer Laboratory are freely available via the Internet:

http://www.cl.cam.ac.uk/TechReports/

ISSN 1476-2986

AbstractIn the future world of Ubiquitous Computing, tiny embedded networked computers will befound in everything from mobile phones to microwave ovens. Thanks to improvements in tech-nology and software engineering, these computers will be capable of running sophisticated newapplications constructed from mobile agents. Inevitably, many of these systems will containapplication-levelvulnerabilities; errors caused by either unanticipatedmobility or interface be-haviour. Unfortunately existing methods for applying security policy – network firewalls – areinadequate to control and protect the hordes of vulnerable mobile devices. As more and morecritical functions are handled by these systems, the potential for disaster is increasing rapidly.

To counter these new threats, this report champions the approach of using new application-level security policy languages in combination to protect vulnerable applications. Policies areabstracted from main application code, facilitating both analysis and future maintenance. Aswell as protecting existing applications, such policy systems can help as part of a security-awaredesign process when building new applications from scratch.

Three new application-level policy languages are contributed each addressing a differentkind of vulnerability. Firstly, the policy language MRPL allows the creation ofMobility Re-striction Policies, based on a unified spatial model which represents both physical location ofobjects as well as virtual location of mobile code. Secondly, the policy language SPDL-2 pro-tects applications against a large number of common errors by allowing the specification ofper-request/response validation and transformation rules. Thirdly, the policy language SWILallows interfaces to be described as automata which may be analysed statically by a model-checker before being checked dynamically in an application-level firewall. When combinedtogether, these three languages provide an effective means for preventing otherwise criticalapplication-level vulnerabilities.

Systems implementing these policy languages have been built; an implementation frame-work is described and encouraging performance results and analysis are presented.

3

Contents

1 Introduction 91.1 Hardware Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111.2 Ubiquitous Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111.3 Terminology: Software Layers, Levels and Protocols . . . . . . . . . . . . . .121.4 Policy Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121.5 Mobile Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131.6 Current Network Firewalls Insufficient . . . . . . . . . . . . . . . . . . . . . .141.7 Abstracting Application-Level Policy . . . . . . . . . . . . . . . . . . . . . .141.8 Motivation for Abstracting Application-Level Policy . . . . . . . . . . . . . .161.9 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161.10 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

2 Technical Background 182.1 Mobile Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

2.1.1 Example: Flight Booking . . . . . . . . . . . . . . . . . . . . . . . . .212.1.2 Example: Secure Database Searching . . . . . . . . . . . . . . . . . .222.1.3 Example: Controlling ATM Networks . . . . . . . . . . . . . . . . . .232.1.4 Example: Location-Oriented Multimedia . . . . . . . . . . . . . . . .23

2.2 Physical Location-Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . .232.2.1 Example: GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242.2.2 Example: Active Bat . . . . . . . . . . . . . . . . . . . . . . . . . . .242.2.3 Example: Radio Received Signal Strength (RSS) . . . . . . . . . . . .242.2.4 In Future Many Devices Will Possess Location Information . . . . . .26

2.3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .272.3.1 Formalism for Interfaces . . . . . . . . . . . . . . . . . . . . . . . . .272.3.2 Interface Proxies and Firewalls . . . . . . . . . . . . . . . . . . . . . .29

2.4 The World Wide Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292.4.1 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .302.4.2 Naming Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . .302.4.3 HyperText Markup Language . . . . . . . . . . . . . . . . . . . . . .352.4.4 Web-Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . .362.4.5 Web-Applications: Handling Application State . . . . . . . . . . . . .362.4.6 Interfaces of Web Applications . . . . . . . . . . . . . . . . . . . . . .37

2.5 Security Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .382.5.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .402.5.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .402.5.3 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4

CONTENTS CONTENTS

2.5.4 Distributed Systems from a Security Perspective . . . . . . . . . . . .412.5.5 As Strong as the Weakest Link . . . . . . . . . . . . . . . . . . . . . .412.5.6 Composability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .422.5.7 Application-Level Security . . . . . . . . . . . . . . . . . . . . . . . .432.5.8 Security, Control and Policy . . . . . . . . . . . . . . . . . . . . . . .44

2.6 Model Checking using PROMELA and SPIN . . . . . . . . . . . . . . . . . . . 442.6.1 PROMELA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.6.2 Simple PROMELA example . . . . . . . . . . . . . . . . . . . . . . . . 472.6.3 Model checking with SPIN . . . . . . . . . . . . . . . . . . . . . . . . 50

2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

3 A Spatial Model 523.1 Modelling the World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

3.1.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .553.1.2 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .553.1.3 Paths and Path Expressions . . . . . . . . . . . . . . . . . . . . . . . .56

3.2 Updating the World Model . . . . . . . . . . . . . . . . . . . . . . . . . . . .573.3 Other Modelling Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . .59

3.3.1 Theoretical Models . . . . . . . . . . . . . . . . . . . . . . . . . . . .603.3.2 UbiComp Middleware . . . . . . . . . . . . . . . . . . . . . . . . . .623.3.3 The Location Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . .633.3.4 SPIRIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .633.3.5 Spatial Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

4 Mobility Restriction Policy Language 664.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

4.1.1 Sentient Spy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .674.1.2 Human Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . .67

4.2 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .674.3 Location-based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . .68

4.3.1 Theprivs function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.3.2 Jailing and Releasing . . . . . . . . . . . . . . . . . . . . . . . . . . .694.3.3 Example: Sound Playing . . . . . . . . . . . . . . . . . . . . . . . . .69

4.4 Mobility Restriction Policies . . . . . . . . . . . . . . . . . . . . . . . . . . .694.4.1 Satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72

4.5 Policy Conflict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .734.6 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .744.7 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77

4.7.1 Traditional Mobile-Agent Systems . . . . . . . . . . . . . . . . . . . .774.7.2 Distributed Programming Languages . . . . . . . . . . . . . . . . . .784.7.3 Middleware-based Approaches . . . . . . . . . . . . . . . . . . . . . .81

4.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81

5

CONTENTS CONTENTS

5 Security Policy Description Language v 2 835.1 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .845.2 Common Security Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . .85

5.2.1 Client-side Modification . . . . . . . . . . . . . . . . . . . . . . . . .855.2.2 SQL Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .865.2.3 Cross-Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . .875.2.4 Forgotten Assumptions: the root cause of vulnerabilities . . . . . . . .88

5.3 Formalising interface assumptions . . . . . . . . . . . . . . . . . . . . . . . .885.3.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

5.4 SPDL-2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .915.4.1 Security Policy Description Language Version 2 . . . . . . . . . . . .91

5.5 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .965.5.1 Designing the Security Policy . . . . . . . . . . . . . . . . . . . . . .97

5.6 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .995.6.1 New Application Frameworks . . . . . . . . . . . . . . . . . . . . . .1005.6.2 Dynamic approaches . . . . . . . . . . . . . . . . . . . . . . . . . . .100

5.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101

6 Stateful Web-application Interface Language 1026.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103

6.1.1 Forceful Browsing Examples . . . . . . . . . . . . . . . . . . . . . . .1036.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106

6.2.1 As Interface Modification . . . . . . . . . . . . . . . . . . . . . . . .1086.3 SWIL Technical Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109

6.3.1 SWIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1096.3.2 Well-formed Programs . . . . . . . . . . . . . . . . . . . . . . . . . .1126.3.3 The SWIL Meta-programming System . . . . . . . . . . . . . . . . .113

6.4 Translation into PROMELA . . . . . . . . . . . . . . . . . . . . . . . . . . . .1176.5 Dynamic Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120

6.5.1 Dynamic Response Transformation . . . . . . . . . . . . . . . . . . .1226.6 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124

6.6.1 Analysis with SPIN . . . . . . . . . . . . . . . . . . . . . . . . . . . .1276.6.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130

6.7 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1316.7.1 Model-based approaches to software development and analysis . . . . .1316.7.2 Describing Interfaces with Automata . . . . . . . . . . . . . . . . . .1336.7.3 Sanctum AppShield . . . . . . . . . . . . . . . . . . . . . . . . . . .1336.7.4 Meta-programming . . . . . . . . . . . . . . . . . . . . . . . . . . . .1346.7.5 User Interface Transformation . . . . . . . . . . . . . . . . . . . . . .1366.7.6 Building web-applications using continuations . . . . . . . . . . . . .138

6.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138

7 Implementation 1397.1 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139

7.1.1 Policy-Enforcing Spatial Middleware . . . . . . . . . . . . . . . . . .1417.1.2 Mobile Agent Servers . . . . . . . . . . . . . . . . . . . . . . . . . .1507.1.3 Mobility Enforcement Policy . . . . . . . . . . . . . . . . . . . . . . .151

6

CONTENTS CONTENTS

7.1.4 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1537.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155

7.2.1 SPECTRE: A Policy-Enforcing Firewall . . . . . . . . . . . . . . . . .1557.2.2 SPDL-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1567.2.3 Tracking Session State . . . . . . . . . . . . . . . . . . . . . . . . . .1587.2.4 SWIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1597.2.5 Raw Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159

7.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163

8 Conclusions and Further Work 1648.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1668.2 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166

A SPDL-2 DTD 183

B Case Study SPDL-2 185

7

Acknowledgements

Firstly I’m very grateful to my supervisor, Alan Mycroft, whose guidance and advice have beeninvaluable throughout my time as a student in Cambridge. Thanks are also due to Andy Hopperwho admitted me as a PhD student in the first place and who allowed me the freedom to pursuemy interests.

Thanks to all my fellow students (in both the Laboratory for Communication Engineeringand the Computer Laboratory) and colleagues (in both AT&T Laboratories Cambridge and IntelResearch Cambridge) who have been so inspiring over the last few years. Particular thanks aredue to Alastair Beresford for all his proof-reading efforts and Richard Sharp for supplyingcoffee and interesting discussion. Thanks are also due to Kieran Mansley, Alastair Tse, AlastairBeresford and Anil Madhavapeddy for all their . . . relaxing. . . late-afternoon games of QuakeIII up in SN17.

Finally, thanks to my family for all their encouragement and support; they’ll be glad thatperhaps now I can finally get myself a proper job!

8

Chapter 1

Introduction

Tiny embedded computers are found in a host of everyday items including wristwatches, alarmclocks, mobile phones, network routers and washing machines. Very few of these devices arenetworked. The situation is changing rapidly; the recent development of integrated on-chipwireless network interfaces will soon drive the cost of networking these embedded computersto almost nothing. Hordes of mobile embedded devices will soon be able to run the samestyle of distributed programs found today on networked PCs. This is the world ofUbiquitousComputing.

Many researchers believe that an environment permeated with powerful, invisible, net-worked computers will be able to support whole new types of useful applications. Howeveras well as great potential for useful applications, there is also great potential for harmful ones.Already figures from CERT (see Figure 1.1) show an alarmingly rapid rise in the number ofcomputer security incidents – typically infections with viruses and trojans – a situation boundto get worse as networked computers proliferate. So-called “zero-day exploits” where mali-cious code to exploit a vulnerability is released before the vendor is made aware of the flaw arebecoming common. Recently “Cabir” [19], the first mobile phone virus, has been observed byanti-virus software firms. Although this particular virus contained no malicious payload, futuremobile viruses could do anything from sending vast numbers of premium-rate text messagesfrom the victim’s phone (incurring the relevant charges, as happened with the ill-fated copyprotection mechanism in the mobile gameMosquitos[109]) to spreading automatically throughthe contact phone numbers stored in the handset. With only a few networked computers perperson (i.e. desktop, laptop, PDA, mobile phone) users can always exercise the ultimate sanc-tion by pulling the plug on an aberrant machine. What sanction is left when there are thousandsof networked computers per person and some of them are safety or mission-critical?

Traditionally networks are secured by surrounding them with firewalls which filter networkpackets depending on their source and destination. In a recent report [127], Gartner analystJohn Pescatore wrote that although firewalls have been effective so far at blunting network-level attacks, the popularity of HTTP tunnelling and Web-Services will push future attacks upto the application-level. In the near future old-style firewalls will likely cease to be effective.Users need to protect and control their applications with new types ofapplication-levelsecuritypolicies.

The thesis of this work is that abstracting application-level security policy (whichwe define to be policy written to govern both themobility andinterface behaviourof systems) is an effective technique for guarding against application-level vulner-abilities which would otherwise plague future ubiquitous computing systems.

9

Chapter 1. Introduction

0

2

4

6

8

10

12

Incid

ents

Rep

orte

d / 1

0000

0

5

10

15

20

25

30

35

40

Vuln

erab

ilitie

s Re

porte

d / 1

00

1995 1996 1997 1998 1999 2000 2001 2002 2003

Year

Incidents

Vulnerabilities

Figure 1.1: CERT/CC Statistics on Reported Incidents and Vulnerabilities obtained fromhttp://www.cert.org/stats/ for the period from 1995–2003.

10

Chapter 1. Introduction 1.1. Hardware Trends

This chapter begins with an outline of relevant hardware trends in Section 1.1 providingthe context for a description of the field of Ubiquitous Computing in Section 1.2. Section 1.3describes some terminology useful for discussing distributed systems while Section 1.4 gives abrief outline of research into policy systems. Section 1.5 describes the trend towards ever greatersoftware mobility which is followed by a discussion in Section 1.6 of how these factors have allled to traditional network firewalls being unable to effectively protect vulnerable applications.Abstracting application-level security policy is described in Section 1.7 and motivated as auseful technique in Section 1.8. Section 1.9 describes the contribution and Section 1.10 thestructure of the rest of this thesis.

1.1 Hardware Trends

The Semiconductor Industry Association [146] predicted that around 1 billion transistors willbe manufactured for every man, woman and child on Earth in the year 2010. These transistorswill likely not be in conventional CPUs; Tennenhouse predicted [158] that the production ofmicrocontrollers – tiny embedded CPUs – will outnumber traditional desktop CPUs by 50 to 1in the year 2000. These microcontrollers are found today in many products including networkrouters, cellphones, alarm clocks, washing machines, vending machines, heating systems, carengines, security systems and many others. These tiny machines are becoming increasinglysophisticated (following Moore’s Law) and some now run Commercial Off-The Shelf (COTS)operating systems like VxWorks [10] or ITRON [4]. Although many of the devices are not cur-rently networked (except network routers) it seems likely that, with the falling cost of wirelessnetworking technologies like Bluetooth [2] and IEEE 802.11 [93] soon these devices will beequipped to communicate with one-another and with the rest of the global Internet. Due to theirsmall size and weight, many of these devices will also be physically mobile, either carried bypeople (in the form of a laptop), under their own power (in the form of a robot) or even driftingon the wind (in the form of a “Smart Dust” [102] particle).

1.2 Ubiquitous Computing

The potential capabilities of a huge network of communicating, mobile, embedded devices aretruly staggering. In August 1999, Neil Gross published an article in Businessweek [78] whichcontained the prediction:

Hundreds of thousands of PCs working in concert have already tackled complexcomputing problems. In the future, some scientists expect spontaneous computernetworks to emerge, forming a “huge digital creature”.

In his seminal article in Scientific American Weiser described [171] a world in which computerscease to be the focus of attention but instead fade into the background, “weaving themselves intothe fabric of everyday life until they are indistinguishable from it”. This vision ofUbiquitousComputingis perhaps the one Licklider imagined [110] in his influential 1960 article titled“Man-Computer Symbiosis”:

The hope is that, in not too many years, human brains and computing machineswill be coupled together very tightly, and that the resulting partnership will think asno human brain has ever thought and process data in a way not approached by theinformation-handling machines we know today.

11

1.3. Terminology: Software Layers, Levels and Protocols Chapter 1. Introduction

Unfortunately there are already signs that trouble is brewing with the first generation of net-worked embedded devices: Arce discusses [15] how it may be possible to remotely compro-mise and seize control of the computer within a Cisco router. Vulnerabilities in core networkelements are bad enough but worse could still be to come: Borriello and Want describe [27] howin the future tiny ingested computers controlled by Web-Services may perform the time-releaseof drugs into the bloodstream. Vulnerabilities in these systems would be devastating.

1.3 Terminology: Software Layers, Levels and ProtocolsMany systems, particularly networked ones, are considered to be constructed inlayers, some-times known aslevels, arranged in a stack. Each layer is a module which uses the interfaces ofthe layer below in order to expose new interfaces to the layer above. Layers at the same levelin different systems communicate usingprotocols. Protocol messages emitted from a particularlayer in one system are routed through lower layers on their way to the same layer in peeredsystems. Layers are intended to be abstract entities; their internal details are hidden and onlyconcrete interfaces are exposed.

The ISO Open Systems Interconnect (OSI) seven layer model is a famous reference de-sign for networked systems1. The seven layers, from highest-level to lowest, are: application,presentation, session, transport, network, datalink, physical. The physical layer considers is-sues such as the voltages required in electrical transmission circuits and the rate at which bitscan be modulated. The datalink layer deals with the organisation of bits transmitted, includingerror-checking and framing. The network layer takes care of message routing across nodes ina network. The transport layer arranges for any necessary data retransmissions in the eventof messages being dropped. The session layer considers grouping messages into higher-levelstructures such as byte streams or request/response messages. Finally the application layer per-forms everything else, i.e. the “real work” of the application. In this thesis we consider theapplication-level software to consist of two aspects: amobility aspect which controls the loca-tion of code and aninterface behaviouraspect which controls how a component interacts withother components.

1.4 Policy SystemsPolicies are widely used throughout computer systems for many different purposes. In gen-eral, a policy system usually consists of a set of high-level rules written in mathematical logicwhich describe the way a system should behave in different circumstances. For example, anaccess control policy [138] would describe how and when users may gain access to particularresources. An example access control policy would be one which states (in some concrete math-ematical form) that only users who have supplied the correct password and are in a particulargroup may access the printer between 9am and 5pm on a tuesday. Access control policies areeitherdiscretionaryor mandatory. A discretionary policy allows users control over who can ac-cess the objects they “own” while a mandatory system is configured by the system administratorand no-one else may change the permissions—not even the user who owns the objects.

Information flowpolicies are rules which constrain how data may move between applica-tions and application components. Denning and Denning [50] designed a compile-time programanalysis phase which checks that information can only legally flow between variables (data mayflow by direct assignment or by indirectly influencing the value of another variable) if the vari-

1ISO defined a concrete set of protocols corresponding to their abstract model. Although these protocols neverbecame popular the model is still used today as a reference to compare other systems.

12

Chapter 1. Introduction 1.5. Mobile Agents

ables belong to certain security classes (e.g. data may flow from a variable of classpublic to avariable of classtop secretbut not the other way around).

Role-based access control(RBAC) [73] introduced the concept of a role which is a associ-ated with a particular position within an organisation and granted a set of access rights. Usersare assigned to roles either statically or dynamically (for example, after supplying supplemen-tary passwords) rather than being granted access rights directly.

XACML[66] is a policy system which has recently been defined by an industrial consortiumto control access to parts of the XML documents. The process of exchanging XML documentsconstitutes the core of the Web-Service protocols and together with XML encryption [94] andXML signatures [18], XACML is a significant part of the Web-Service security model. XACMLis highly flexible; individual users or roles may be given access to read or write documents atarbitrary granularity, down to individual document elements.

The Policy Description Language(PDL) [111] uses a paradigm calledevent-condition-action (ECA) originally developed for active databases. Events (such as a login attempt) arematched against the ECA rules to generate appropriate actions, which could include generatingfurther events. Simple event combinators are provided to allow rules to match combinators orsequences of events.

Network Firewallpolicies are similar to ECA policies where events fire when packets arereceived and the actions include: (i) drop the packet; (ii) reject the packet by sending back anerror; (iii) let the packet pass unmodified; or (iv) transmit the packet with some modification.

1.5 Mobile Agents

As networked computers proliferate there is not only a trend towards greaterphysicalmobil-ity but also greaterlogical mobility. Over time, many different architectures for distributedsoftware have been proposed includingclient-server, remote execution, code on demandandmobile agents. These architectures differ primarily in the amount of code mobility (i.e. logicalmobility) they support. Client-server is the most static — supporting no code movement at all;client and server simply communicate via request and response messages. Remote executionallows a client to send a program to the server while in a “code on demand” system a program isdownloaded from the server to a client. Mobile agent systems sport the most mobility and flex-ibility; agents are autonomous programs which decide for themselves when to move betweenhosts on the network and when to stay in one place and send messages instead.

Mobile Agents are attractive for many reasons [107] including overcoming effects of la-tency, lowering bandwidth requirements, increasing fault-tolerance and maximising use of dis-tributed resources. As time passes each of these aspects is becoming more important. Considerlatency: unlike bandwidth which can be increased through ever more sophisticated transmis-sion schemes, communications latency has a hard lower-limit determined by the speed of lightand the distance between distributed nodes. As machines get faster individual communicationsbecome increasingly expensive in terms of CPU cycles. Sending a whole program (as an agent)is therefore more economical than sending multiple requests serially to a remote server. Forfault-tolerance, agents can replicate themselves and run on several nodes of a network simul-taneously; this ability should be particularly useful as shrinking CMOS feature sizes is leadingto more unreliable chips [55]. At the present time data is being generated in vast quantities byscientists (e.g. from genome sequencing and particle physics experiments) by businesses (e.g.from customer profiling) by governments (e.g. from citizen profiling) and by individuals (e.g.in the form of digital media). In many applications data is generated so quickly that it must be

13

1.6. Current Network Firewalls Insufficient Chapter 1. Introduction

processed by distributed nodes in a system known as a computationalGrid [67]. Autonomousmobile agents are an attractive means of programming these Grid applications [105].

Unfortunately the increased flexibility of mobile agent systems comes with a cost; it is notclear how best to control such a highly mobile, fluid system. There are many open securitychallenges; for example it is not clear how best to protect hosts from malicious agents andagents from malicious hosts (more details may be found in the literature [141, 41]). Howeveras time passes the lure of Mobile Agents will get ever stronger and more difficult to resist.

1.6 Current Network Firewalls Insufficient

A firewall is an entity which imposes policy at the network boundary between systems. Theoriginal design of the Internet was based on theend-to-end[137] principle in which all in-telligence is contained in the hosts while the network itself is dumb. The network consistedentirely of simple packet routing engines corresponding to thenetwork-levelin the jargon ofthe ISO/OSI model described in Section 1.3. This design has no explicit firewalls; each host isresponsible for its own security and may communicate with any other host. Explicit firewallswere introduced later in an attempt to centralise security responsibilities rather than leaving se-curity to individual hosts. Unfortunately this creates tension between two groups of users: thosecharged with security who run the firewalls and those running the actual applications. In such asituation an arms race can easily develop; a firewall blocking a particular protocol provides anincentive to modify the application totunnelthe blocked protocol over some other still permit-ted protocol. It is perhaps no surprise then that Web-Services [75], a new middleware platform,sends all data over HTTP [22]: the same protocol used by the World Wide Web (WWW) andwhich is almost universally permitted. Therefore as far as any application using Web-Servicesis concerned, network firewalls are transparent.

Mobility is also a problem for current network firewalls. If mobile agents (possessing logi-cal mobility) are allowed to migrate across a firewall then they are able to send traffic directlyto local machines without being subject to network security policy imposed by the firewall.Similarly, programs running on physically mobile machines (e.g. on laptops) may also bypassfirewall policy when the machines move. Figure 1.2 shows graphically a representation ofa traditional networked environment in which fixed hosts are connected in small trusted net-works separated by firewalls. Each isolated local network operates as anisland of trustandthe firewalls form naturaltrust boundaries, imposing policy on the traffic flowing between thenetworks. Figure 1.3 shows the same diagram augmented with a multitude of mobile agentsand devices able to move both physically and logically. Clearly network-level firewalls are nolonger sufficient to protect vulnerable applications from mobile attack.

1.7 Abstracting Application-Level Policy

In this thesis the term “application-level policy” is used to refer to policy written to govern themobilityandinterface behaviourof systems. Application-level policy does not deal with lower-level security issues such as the choice of encryption protocol used to prevent eavesdroppingor the nature of the packet filtering rules contained within a network firewall. Application-levelpolicy deals with issues such as (i) where can a program execute; (ii) where can it move to; and(iii) what messages may it safely exchange with other programs.

“Abstracting” policy refers to a general technique for maintaining a single policy specifica-tion separate from an entire application codebase. The policy is kept in one piece to facilitatereasoning and analysis—a task which would be much more difficult if the policy was entwined

14

Chapter 1. Introduction 1.7. Abstracting Application-Level Policy

firewall

host

island of trust

Figure 1.2: Diagram represents traditional distributed computing; fixed hosts are connected insmall trusted networks joined together by firewalls.

firewall

fixed host

island of trust

mobile host

Figure 1.3: The same diagram from Figure 1.2 augmented with a host of mobile devices capableof crossing between islands of trust.

15

1.8. Motivation for Abstracting Application-Level Policy Chapter 1. Introduction

with the main application code.

1.8 Motivation for Abstracting Application-Level PolicyApplication-level policy is required for three reasons. Firstly, the trend towards greater mobilityof both hardware devices and software agents is reducing the effectiveness of current firewallpolicies written at the network or transport-level. Network-level policies necessarily base theirdecisions only on the source or destination addresses of traffic while transport-level policies(like those implemented by the OpenBSD stateful firewall [7]) are able to filter traffic based onTCP-level flow information e.g. the presence or absence of aSYNflag indicating a connectionsetup (more will be said about TCP connection setup later in Section 2.6.2). Secondly, mod-ern middleware platforms like Web-Services are being designed specifically to work aroundnetwork-level firewalls, tunnelling through them by pretending to be normal HTTP traffic2. Fi-nally, more and more vulnerabilities are being found and exploited at the application-level; atrend which is predicted to get worse [127]. Application-level policy, rather than network-levelpolicy is required to protect applications.

Abstractingapplication-level policy affords us a number of advantages. It allows developersto untangle security-related code from a large codebase, facilitating design, analysis and main-tenance. In situations where an application is constructed from separate components (consider ashopping cart component used in a web-application) it may be difficult to modify the individualcomponents since they may be written in different languages or only available in binary form..

Abstracting application-level policy can help mitigate the effects of zero-day exploits. Whena component vendor wishes to release a new version with a critical bug fixed, great care mustbe taken to avoid accidentally creating additional problems—a difficult task when the vendor’scustomers have widely different setups and rely on different features of the component. Thevendor is placed in a very difficult position: release a fix early and possibly introduce moreproblems with some customers or release late and leave all customers vulnerable to attacks forlonger. Abstracting policy offers a third way: customers can write policy, customised for andtested by themselves on their individual configurations, allowing them to protect themselves inthe short-term while they wait for an official fix to come from the vendor.

A downside to the approach of abstracting policy is that it requires extra maintenance; i.e.when the application is modified so too must the policy be modified. However this task need notbe as onerous as it might seem. Policy maintenance could be simplified using automatic toolsupport. For example, a tool could be used to track changes to an application source and remindthe administrator to check particular parts of the policy when the source is changed. The task ofinitially creating policy could also be simplified with a tool which passively monitors “normal”application behaviour and produces a default policy which is permissive enough to allow all thebehaviour it observes. Such policy could then be customised by a human policy designer.

1.9 ContributionThis thesis explores policy languages and mechanisms to govern both themobilityandinterfacebehaviourof software at the application-level. This thesis specifically contributes:

1. the Unified Spatial Model (USM): a spatial model capable of representing simultaneouslythe physical locations of objects such as people and the virtual locations of mobile agents.The USM is the foundation of the Mobility Restriction Policy Language (MRPL) – a

2“The Net interprets censorship as damage and routes around it.” – John Gilmore

16

Chapter 1. Introduction 1.10. Outline

language which allows policies to be written to limit the movements of mobile agentsin an environment augmented with location sensors, like that displayed graphically inFigure 1.3;

2. the language SPDL-2 which allows the expression of application-level interface securitypolicies in which per-request and response validation and transformation rules can bewritten to protect web-applications from many kinds of common security vulnerabilities;and

3. the language SWIL which allows the flow of control across an application interface to bedescribed as a sequence of operations accepted by a finite state automaton. The automatoncan be both analysed statically with a model-checker and dynamically checked with anapplication-level firewall.

Together this model and these policy languages allow abstract application-level policy speci-fications to be written to protect against many kinds of vulnerability. These application-levelpolicy systems have been implemented; implementation details and performance results areprovided.

1.10 OutlineThe rest of this thesis is structured as follows: Chapter 2 provides technical background infor-mation important for understanding the following chapters. The next four chapters are dividedinto two groups of two; the first two chapters focus on themobility while the second two fo-cus on theinterfacesof applications. Chapter 3 begins by describing the Unified Spatial Model(USM) capable of representing both the physical location of computers and the logical locationsof mobile agents in the same framework. This model is used subsequently in Chapter 4 as thebasis of the Mobility Restriction Policy Language (MRPL) in which policies may be writtencapable of limiting the movements of agents in both physical and virtual space.

The following two chapters deal with the interfaces of applications. Chapter 5 introducesthe policy language SPDL-2 (Security Policy Description Language version 2) which allowsthe specification of per-request and response validation and transformation rules, protecting ap-plications from many common forms of security vulnerabilities. Chapter 6 introduces SWIL(Stateful Web Interface Language) which allows the flow of control across an application inter-face to be described as a sequence of inputs accepted by a finite state automaton. SWIL securesan application interface through a combination of up-front model-checking and dynamic policyenforcement.

Chapter 7 describes the implementation of the systems described in Chapters 3 through 6along with some encouraging performance results. Finally Chapter 8 discusses future work andconcludes. Related work and general discussion is provided in the relevant chapters.

17

Chapter 2

Technical Background

This chapter provides detailed technical background information on a number of core conceptsused throughout the rest of this thesis, specifically Mobile Agents (in Section 2.1), LocationSensing (in Section 2.2), Interfaces (in Section 2.3), Web Protocols (in Section 2.4), ComputerSecurity (in Section 2.5) and Model-Checking (in Section 2.6).

Previously Section 1.5 motivated the use of mobile agents as an increasingly useful and eco-nomical way to structure distributed programs. With this in mind, this chapter begins in Sec-tion 2.1 with a detailed description of key Mobile Agent concepts together with some simpleapplication examples. Section 1.1 argued thatphysicalmobility (as well as mobile agent-stylelogical mobility) is set to increase significantly as devices continue to shrink and proliferate.Mechanisms to control this physical mobility will necessarily rely on the ability to sense wheredevices are in physical space. Therefore Section 2.2 describes a number of mechanisms forlocation sensing and provides several political arguments for why these location sensing de-vices will become commonplace. Later work in Chapter 3 builds upon this foundation, creatingthe Unified Spatial Model (USM) capable of representing both the physical locations of ob-jects and the logical locations of agents simultaneously. The model is used in Chapter 4 asthe basis for the Mobility Restriction Policy Language (MRPL) which allows the creation ofmobility restriction policiescapable of limiting the movement of mobile agents throughout anenvironment augmented with location sensors. We observe that, just as early operating systemshad little need for file protections until they became multi-user, mobility policy only becomescritical as systems become more mobile.

In addition to moving between hosts, Mobile Agents are also able to communicate acrosspoints known generically asinterfaces. Section 2.3 describes a simple interface formalism ca-pable of representing a number of common interface operations. The concepts of an interfaceproxyand an interfacefirewall are both introduced. The policy languages SPDL-2 in Chapter 5and SWIL in Chapter 6 are both implemented by an interface firewall system described in Chap-ter 7. While the concept of an interface is generic, real-life systems necessarily will use someconcrete set of protocols. To facilitate a more interesting discussion (and without loss of gener-ality) this thesis makes the simplifying assumption that future distributed, mobile applicationswill opt to use the standard web protocols for communication. These protocols are describedin detail in Section 2.4. The termweb-applicationis introduced to mean any application us-ing the web protocols (HTTP and URIs) for communication and the form of a web-applicationinterface is described using the formalism of Section 2.3. Web interfaces say nothing specificabout security and leave a number of crucial interface assumptions undocumented causing alarge number of application vulnerabilities; these problems are fixed by the policy languagesSPDL-2 in Chapter 5 and SWIL in Chapter 6.

18

Chapter 2. Technical Background 2.1. Mobile Agents

property descriptionreactive responds to external stimuli in the environmentautonomous takes its own decisionsgoal-oriented has a purposecontinuous runs all the timecommunicative communicates with other agents and/or peoplelearning changes its behaviour based on its previous experiencemobile able to migrate between hostsflexible actions are not scriptedcharacter believable “personality” and emotional state

Figure 2.1: Table of properties of mobile agents as proposed by Franklin et al [71].

Section 2.5 describes traditional security principles and outlines several reasons why en-gineering secure systems is difficult in practice. A simple example is used to demonstratehow security is not in general composable and how it is only ever as strong as the weakestpart of a system. Recall the thesis statement from Chapter 1 which talked aboutapplication-levelsecurity vulnerabilities. As briefly described in Section 1.3, software is often constructedin a layered fashion, with system software (e.g. network stacks) layered beneath application-specific code. Application-level vulnerabilities are by definition vulnerabilities present onlyin the application-specific code. Both the mobility restriction policies in Chapter 4 and theinterface policy languages in Chapters 5 and 6 are application-level security mechanisms.

Finally, Section 2.6 describesmodel-checking, a technique for the automatic verification ofcommunicating systems. The syntax of the PROcess MEta LAnguage (PROMELA) is describedand a simple example system is specified. Various properties of the system are mechanicallyverified using the SPIN model checker. PROMELA and SPIN are revisited later in Chapter 6where they are used to verify properties of interface security policies written in SWIL.

2.1 Mobile AgentsThere is no general consensus amongst researchers or practitioners on what exactly constitutesa mobile agent or how an agent is different from a normal software program. Rather thanproviding a concrete definition, Franklin et al [71] propose a number of properties which theybelieve an agent should have. These properties are displayed in the table in Figure 2.1. Someof these properties (specifically character, learning, goal-orientation) are obviously inspired byArtificial Intelligence (AI) research while others (mobility and communicativity) are lower-levelimplementational properties.

This thesis adopts the simple definition:

A Mobile Agent is an autonomous program capable of moving between hosts on anetwork and communicating with other agents.

The term “autonomous” is used to imply that mobile agent programs decide themselves when tomove unlikeprocess migrationsystems (e.g. SPRITE [54]) in which the hosts decide when pro-cesses should move. The diagram in Figure 2.2 shows software running on two hosts labelled“system A” and “system B”, each including a mobile agent server. The software on each host isrepresented as a sequence of layers ranging from lowest-level and least abstract at the bottom tohighest-level and most abstract at the top. Each layer communicates conceptually with the cor-responding layer in the peered system although in practice messages are routed through lower

19

2.1. Mobile Agents Chapter 2. Technical Background

TCP/IP

server

TCP/IP

server

agents agents

datagrams

ethernet ethernet

coax cables

coax cables

ethernetframes

electricalsignals

migratingagents

inter-agentcomms

system A system B

systemlayers

application

presentation

session

transport

network

datalink

physical

ISO/OSI 7 layer model

Figure 2.2: Diagram showing hosts, agent servers, agents and communication channels. Con-ceptually agents communicate directly with other agents but in practice the communications arerouted via lower layers.

layers. In the system depicted the underlying network connecting the two systems is ethernet. Inthe lowest level (corresponding with the ISO OSI physical layer) electrical signals are sent viacoax ethernet cables. The ethernet protocol adds framing and checksumming information andcorresponds to the OSI datalink layer. Both systems are using the internet protocol suite TCP/IPwhich corresponds with the OSI session, transport and network layers combined together1.

Each mobile agent server provides an execution environment (sometimes described as aplace) for the agents running inside. Servers provide all the relevant APIs needed to allowagents to operate and provide any necessary access to local resources. Agents exposeinterfacesthrough which they may communicate with other agents. Two types of message are sent be-tween agent servers: messages sent from one agent to another and messages co-ordinating thetransfer of agents. The message formats are handled by the mobile agent servers which corre-spond to the OSI presentation layer. The agents themselves correspond to the OSI applicationlayer.

The security implications of representing software systems as a set of layers will be dis-cussed later in Section 2.5.4. In this thesis we shall assume that all application-level communi-cation is achieved through the web protocols, described later in Section 2.4.

In addition to communication primitives, mobile agent systems typically support the follow-ing basic but not standardised operations:

create: creates a new agent from scratch

clone: duplicate the current agent (likefork() under Unix)

migrate: move the agent to a new host

recall: forcibly returns an agent to its initial location

terminate: kills a running agent

1TCP provides an error-free flow-controlled byte stream abstraction on top of IP which provides an unreliabledatagram service.

20

Chapter 2. Technical Background 2.1. Mobile Agents

Mobile agent implementations vary in many ways. Firstly, there is no standard mobileagent security mechanism; each mobile agent system provides its own. A second point ofvariation is the choice of implementation language. For interoperability, interpreted bytecode-based systems are common e.g. Java Aglets [106] and interpreted C autonomous objects [25].Other systems define their own languages e.g. Telescript [172] and Obliq [31].

Wojciechowski’s Nomadic Pict [173] is noteworthy in that it is a two-level agent program-ming language; it has a low-level sublanguage which deals with agent migration and location-dependent communication while a high-level language supports only location-independentprimitives. The high-level language is translated into (or implemented in terms of) the low-level language by a mapping known as aninfrastructure. Applications can be recompiled withdifferent infrastructures to explore different migration and communication strategies—an in-frastructure may be thought of as a kind of abstract mobility and communication policy. Laterwork by Unyapoth [163] considered semantics in detail and demonstrated how it was possible toprove the correctness of an infrastructure mapping for an arbitrary high-level source program.

Linked to the choice of implementation language, a third variation is the type of mobilityoffered [87]. Some systems are said to offerfull mobility: the migration of all state including thatwithin the kernel (i.e. open files and network connections). Another variation isstrong mobilityin which a system is able to introspect and migrate running code. The remaining systems offerweak mobility, insisting that agents perform manual shutdown and restart. For example, Javabased systems only offer weak mobility because Java does not allow the introspection of themethod call stack of running code. Even these distinctions are not very discriminating: Bettiniet al describe how strong mobility may be implemented on top of weak mobility with a syntax-level translation [23].

Mobile agent code is handled in several different ways. Some systems transmit code alongwith an agent’s state during migration. Alternative mechanisms include downloading the codeon-demand, perhaps on a class-by-class basis – a common technique if the agent system is basedin Java. A further alternative is to download the code from a third party server.

To give a flavour of how mobile agents may be used, the following four sections describesimple example applications.

2.1.1 Example: Flight Booking

In this example a mobile agent is created by a user who wishes to travel somewhere by air. Theagent is written containing the user’s preferences (e.g. date of journey, class of ticket etc.) andbudget (i.e. how much they are willing to pay). The agent migrates to servers controlled byairlines from where it can efficiently interrogate local flight databases. The agent can migratebetween airline servers to compare prices and find the most appropriate deal for their user. Theprocess is illustrated graphically in Figure 2.3. The user first creates an agent (representedby a circle) which migrates between agent servers (rounded boxes) as indicated by the filledarrows. In the illustration the agent migrates between three different airline agent servers in turn,querying local databases (represented by the unfilled arrows) before returning to the originalagent server.

Provided the agent itself is small compared with the database data, this design requires lessoverall network bandwidth than the traditional client/server design in which the databases are allinterrogated remotely from a fixed location. The main disadvantage is that a malicious airlinesite may disassemble the agent to discover information the user would rather keep secret, for

21

2.1. Mobile Agents Chapter 2. Technical Background

user agent server

airline 1

airline 2

airline 3

DB

DB

DB

commsoverinterface

commsoverinterface

commsoverinterface

Figure 2.3: Use of a mobile agent to query remote databases.

example how much money the user is willing to pay.2 A malicious airline server has otherpotential avenues of attack open to it. It might block the agent’s exit, particularly if it intends tomigrate to a competitor’s servers. Alternatively it might corrupt the agent, modifying any datastored supplied by competitors. To address these problems the user must always assume theworst3and send fresh copies of agents to each airline server and then only analyse the results onthe user’s own trusted computer.

2.1.2 Example: Secure Database Searching

Yannopoulis et al [176] proposed a system called PIVOTS: Private Information Viewing Of-fering Total Safety. The system uses mobile agents to enable sophisticated searches to be per-formed against private data collections while limiting the amount of possible data leakage.

Their running example is a bookstore which contains, but does not want to make freelyavailable, the full-text contents of books. In a situation where the full-textcanbe freely pub-lished a user or a third-party search engine can easily perform arbitrary queries against the text.However, this is not possible in the case where the data is private. In the PIVOTS system, userscan write agents (or have them written by a third-party) which analyse certain properties of thetext. The agents migrate to the bookstore servers from where they can run sophisticated search-ing algorithms against the full-text contents. Crucially, agent communications are limited andan agent can only send back simple responses such as, “you would like this book”. Thereforethey argue that the risk of data leakage is approximately the same as that experienced by a tra-ditional book shop, in which people can wander in and physically thumb through the contents

2Advocates of price discrimination might claim such transparency is a good thing [124].3Later on in Section 2.5 building secure systems is described as “programming Satan’s computer”.

22

Chapter 2. Technical Background 2.2. Physical Location-Sensing

user agent server

bookstore

DBunrestrictedcomms

limitedreturnbandwidth

no furtheragent migration

Figure 2.4: Use of a mobile agent to securely perform full-text searching on private data.

of books on the shelf.The process is illustrated graphically in Figure 2.4. The user creates an agent which migrates

to an agent server running in the bookstore. The agent then enjoys unrestricted communicationwith the back-end database which contains the full-text contents of the books. The agent cannotleave the bookstore server (for it might take private data back with it) but it may send back asimple message, represented by the light, dashed, unfilled arrow.

2.1.3 Example: Controlling ATM Networks

Halls and Rooney [80] describe how mobile agents within a system called the Tube [81] maybe used to control and monitor a network of ATM switches. The agent code and execution stateis transmitted between server processes in the form of continuations in the language Scheme.Agents can query the state contained within network switches, specifically examining the tablesmapping input connection numbers (known as Virtual Channel Identifiers in ATM jargon) andports to output connection numbers and ports. The agents can detect inconsistencies and correctthe tables. The system proposed has two main benefits compared with a traditional centralisedapproach: (i) the distribution ensures the system has no single point of failure; and (ii) theoverall amount of network traffic required is reduced.

2.1.4 Example: Location-Oriented Multimedia

In his thesis, Halls [81] describes how mobile code may be used in a “location-oriented multi-media” system in which video and audio components follow the user as he/she moves aroundthe environment. Applications in the proposed system are able to monitor the physical locationsof users wearing Active Badges [168] and migrate multimedia streams and user interfaces ac-cordingly. Possible applications include: a music playing application which always plays musicphysically near the user; and a video conferencing system which is able to track a user and selectthe most appropriate video camera feed as they walk around. The example of a mobile musicplaying application will be revisited later, in Section 4.6.

2.2 Physical Location-SensingIn addition to possessing logical mobility as exemplified by Mobile Agents, future systems arelikely to also be physically mobile. This section describes how and why such future deviceswill be able to sense their location as they move around the environment,

There exist many devices which can be used to measure physical location information witha variety of different accuracies, latency, levels of reliability and cost. A good taxonomy ofsensor systems has been written by Hightower and Boriello [84]. Sensors differ in the exactphysical characteristic they measure: some compute distance between objects (e.g. a measuring

23

2.2. Physical Location-Sensing Chapter 2. Technical Background

tape), some give a notion of proximity (e.g. an RFID tag), some measure 3D co-ordinates (e.g. aPolyhemus tracker4) while others determine containment of objects (e.g. Active Badges [168]).Some location-sensing techniques arise as a side-effect of other technologies (typically wirelesscommunication systems), for example IEEE 802.11 [93] as used in the RADAR [16] project andGSM Location Based Services (LBS) [79]. Systems designed primarily for location-sensinginclude the Global Positioning System (GPS) [86], Active Bats [169], Ultra Wide Band systemslike PAL650 [65] and Cricket [130].

Examples of location sensing systems are given in the following sections.

2.2.1 Example: GPS

The US Military’s Global Positioning System (GPS) uses a set of low earth orbit satellitesto transmit signals to passive ground receivers. Each receiver must have a clear line of sightto several satellites; therefore the system only works well outdoors, away from trees and tallbuildings. The more satellites in view the more accurate the data can be. A minimum of 3satellites is required for a 2-D position and 4 satellites for a 3-D position.

The GPS satellites transmit their positions (calculated from sophisticated orbit models com-puted by ground stations) simultaneously, using on-board atomic clocks for accurate timing.The signals are transmitted using a chipping code over a large frequency range making the sys-tem very robust to jamming. Receivers correlate the incoming signals with the known chippingsequence to recover the data and calculate the relative times of arrival of each signal. The posi-tions of the satellites and the relative times of arrival are then used to calculate the position ofthe receiver.

Standard inexpensive hand-held GPS units are accurate to 10-20m 95% of the time butdif-ferential GPSwhich calibrates against a receiver at a well-known fixed location can be accurateto 1m.

2.2.2 Example: Active Bat

The Active Bat system comprises a network of ceiling-mounted ultrasound receivers and smallbattery-powered tags called “Bats”. Bats emit ultrasound signals over a small frequency rangewhen triggered over a radio channel. The ceiling-mounted receivers use time of flight measure-ments to estimate the distance between receivers and individual Bats. Since the receivers are inwell-known positions, these distances can be used to multilaterate the absolute positions of thebats. The bats can be located with an accuracy of 3cm 95% of the time at a maximum frequencyof 50Hz.

The diagram in Figure 2.5 shows an Active Bat emitting a narrowband ultrasound pulsedirected at ceiling-mounted receivers. In the scenario shown, the pulse is received by sensorslabelled 1,2,3,4 and 5. Each room has a temperature sensor allowing the system to accuratelycalculate the speed of sound in air. Based on this calculation, the system can then calculatethe distances between the Bat and all five receivers and then use multilateration to compute theabsolute Bat position.

2.2.3 Example: Radio Received Signal Strength (RSS)

Radio communication systems such as IEEE 802.11 [93] (also known as WiFi) and Blue-tooth [2] provide a means to monitor the strength of signals from other network nodes. Thesignal strengths received from several fixed nodes can be fed into a radio propagation model toestimate the position of the mobile receiver. For example, power received from a transmitter

4Polhemus tracker product information available fromhttp://www.polhemus.com/

24

http://www.polhemus.com/

Chapter 2. Technical Background 2.2. Physical Location-Sensing

Ceiling-mounted sensors arranged in a grid

Active Bat

1 2

3 4 5

UltrasoundSignal

Figure 2.5: Diagram showing how an ultrasound signal emitted by an Active Bat is received bymultiple ceiling-mounted receivers.

25

2.2. Physical Location-Sensing Chapter 2. Technical Background

Figure 2.6: Plot showing received signal strength (link quality) of a mobile Bluetooth receiverrelative to a fixed basestation. Picture courtesy of Alastair Tse and Kieran Mansley.

in free space using omnidirectional antennas is well known to be inversely proportional to thesquare of the distance from the receiver.

Indoors the situation is more complicated. Walls, floors, doors, windows and furniture allattenuate signal and cause reflections; the severity of these effects depend on the frequencyof the radio and the exact materials the objects are constructed from. Two objects may lookidentical at visible wavelengths but may have vastly different effects on radio wavelengths.The diagram in Figure 2.6 shows received signal strength from a class 1 Bluetooth device asa function of position (measured with an Active Bat) in the Laboratory for CommunicationEngineering in the University of Cambridge. The signal clearly drops over a range of about10-15m but even samples quite close to the receiver vary unpredictably, probably due to theplacement of furniture and the movements of people5.

WiFi signal strength can be used to infer location outdoors as well as indoors. The PlaceLabproject6 uses a large user-created database mapping WiFi basestation identifiers to latitude andlongitudes. If a mobile receiver spots a known basestation (typically in a densely populatedurban environment) then it can infer its position is within 100m of base station.

2.2.4 In Future Many Devices Will Possess Location Information

In the US the Federal Communications Commission’s Enhanced 911 program [60] mandatedthat mobile phones be locatableby the networkto within 100m 67% of the time and locatableby the deviceto within 300m 95% of the time. The network can locate devices by multilater-ating phone positions given the time of arrival of mobile signals while the devices can locatethemselves by incorporating GPS receivers. It has been suggested that adding GPS to a mobilehandset will cost no more than 10 dollars [164]. Economies of scale and similar pending initia-tives by other governments (such as in the EU) strongly suggest that future mobile phones (andperhaps all future mobile communications devices) will have some built in location-sensingcapability.

Without adding an explicit location system like GPS, any embedded device with a wirelessnetwork interface will automatically be able to use signal strength measurements to infer at leastproximity to other wireless devices. If one of these nearby devices is a GPS-equipped mobile

5Note that organic tissue contains a large percentage of liquid water which readily absorbs 2.4GHz microwaveenergy, an effect exploited by microwave ovens. This effect also means that humans attenuate WiFi and Bluetoothsignals.

6More information can be found athttp://www.placelab.org/

26

http://www.placelab.org/

Chapter 2. Technical Background 2.3. Interfaces

phone then the embedded device will be able to infer its absolute position.For these reasons, this thesis makes the assumption likely to hold in the near future that

location-sensing systems (whether explicit like GPS or implicit like Bluetooth RSS) are foundin most of the networked, embedded devices throughout the environment. This thesis makesthe further two related assumptions that (i) the resolution of the location sensors is sufficient todistinguish between adjacent rooms in a building; and (ii) that user privacy concerns have beenproperly addressed elsewhere (e.g. using Beresford and Stajano’s concept of amix-zone[21]in which a trusted system deliberately mixes location sightings within defined physical areas,obscuring the identities of the people involved).

2.3 Interfaces

An Interface is used to describe how one component (e.g. an agent) may communicate with an-other. Earlier in Section 2.1 Mobile Agents were described as programs which could both moveand communicate, although the mechanism and style of communication was not discussed. Inthis section a simple formalism for Interfaces is presented in the style of Remote ProcedureCalls (RPCs) [121] which is suitable to describe such agent communication.

A useful interface should specify what assumptions the component makes about its envi-ronment (referred to asinput assumptions) as well as what guarantees it is prepared to makeabout its output (referred to asoutput guarantees). These assumptions normally take the formof type specifications for each interface operation. Informally, when the outputs of one inter-face are connected to the inputs of another we require the output guarantee of the first to satisfythe input assumptions of the second. In the case where the input assumptions and output guar-antees only specify types, this corresponds to simple interface typechecking. However inputassumptions and output guarantees can be arbitrarily complicated e.g. they could describe theacceptable order in which functions are called using automata [46]. They also correspond to theuse of preconditions (REQUIRES) and postconditions (ENSURES) in the SRC Extended StaticChecker (ESC) [51].

2.3.1 Formalism for Interfaces

This section describes the simple interface formalism including both a simple syntax and a setof common interface operations.

Interface Syntax

An interfaceI is defined as a set of types (t1 . . . tk) and functions (f1 . . . fn) whose parametershave direction (eitherin or out ), types and names. We allow the pre-defined typesint andstring , custom abstract types and the type constructorslist and× for constructing list and carte-sian product types respectively. Valid interfaces satisfy the constraint that all types visible infunction signatures are either built-in or defined in the interface itself. Each function has a con-junction of atomic formulae representing explicit assumptions and guarantees. Figure 2.7 showsan example interface specification. Note that an interface specification does not say anythingabout theimplementationof that interface; the implementation is considered as a black-box.

The input assumptions of the operationf1 are twofold. Firstly, the input has typeta and thepredicateP (a) holds. Similarly the output guarantees are that the output will have typetb andthe predicateQ(b) holds. Additionally we impose the constraint that all the types mentioned inthe functionsf1 . . . fn must be declared in the interface.

27

2.3. Interfaces Chapter 2. Technical Background

interface I {type t1 = . . .. . .type tk = . . .f1(in ta a, out tb b) assume { P (a) }

guarantee { Q(b) }. . .fn(in tc c, out td d) assume {. . . }

guarantee {. . . }}

Figure 2.7: Example Interface consisting of typest1 . . . tk and functionsf1 . . . fn.

Operation: Hiding

Individual interface types and operations may be hidden so that they are no longer accessibleby callers. For example consider the following interfaceI ′:interface I ′ inherits I {

hide f1

}InterfaceI ′ inherits all the types and functions from interfaceI with the exception of the

operationf1 which becomes hidden. Note that this does not mean the implementation off1

cannot be called; only that interfaceI ′ no longer mentions it. If a client can access interfaceIdirectly thenf1 will be available. Types can also be hidden provided the constraint – that alltypes mentioned in operation signatures are visible – is not violated. Therefore in order to hidea type used by a function it is first necessary to hide that function.

Operation: Extending

In the following example, interfaceI ′ inherits all the types and functions of interfaceI and addsa typet and a functiong. It is assumed thatt andg do not already exist inI.interface I ′ inherits I {

type t = . . .g(in t arg) assume {. . . } guarantee {. . . }

}

Operation: Replacing

Operations and types can be replaced using the same syntax used to add operations and typesin Section 2.3.1. For example:interface I ′ inherits I {

type t = . . .f1(in t arg) assume {. . . } guarantee {. . . }

}In this exampleI ′ inherits from interfaceI adding a new typet and redefining operationf1,

changing its type, assumptions and guarantees. Note that this operation is only valid if no otherfunction is visible which still references the old typet – when a type is replaced all functionswhich reference it must also be replaced.

28

Chapter 2. Technical Background 2.4. The World Wide Web

client server

client proxy server

client firewall server

I

I I

II'

1:

2:

3:

client proxy serverI I'4:

Figure 2.8: Diagram showing four configurations. The first involves a client invoking an inter-faceI on a server. The second case interposes an interface proxy between the client and server,leaving the interface unchanged. The third case uses a firewall rather than a proxy causing theclient to see an interfaceI ′ rather thanI. The fourth case involves an interface firewall used toconvert the interfaceI ′ exposed by anupgradedserver into the original interfaceI expected byan unmodified client.

2.3.2 Interface Proxies and Firewalls

The termproxy is used here to be an entity which intercepts requests for another entity and ifnecessary7 forwards the request back to the original entity. Crucially, a proxy exposes exactlythe same interface as the original entity. The termfirewall, on the other hand, refers to a moregeneric processing entity which is capable of changing the interface of an application.

The diagram in Figure 2.8 shows four cases which are referenced later in the thesis. Thefirst shows a client interacting with a server exposing interfaceI. The second case shows anintermediate proxy between the client and the server. All requests and responses are processedby this entity but crucially from the point of view of the client, the interface is not changed:the client still interacts with the server through interfaceI. In the third case the client interactsthrough a firewall, which changes the interface exposed by the application fromI to I ′; aconfiguration which might represent an upgraded client interacting with a legacy server. In thefourth case the client still uses interfaceI but the server now exposes interfaceI ′; a configurationwhich might represent an upgraded server interacting with a legacy client.

2.4 The World Wide WebThis thesis describes application-level policy languages which address both the mobility andinterface behaviour of ubiquitous computing systems. The description of mobile agents in Sec-tion 2.1 and location sensing systems in Section 2.2 provide all the necessary background forunderstanding the Unified Spatial Model in Chapter 3 and the Mobility Restriction Policy Lan-guage in Chapter 4. The interface behaviour policy systems SPDL-2 and SWIL described inChapters 5 and 6 are based upon the web protocol suite, described in this section. The use of aconcrete set of protocols simplifies the presentation while the specific use of the web protocols

7A caching proxymay be able to respond to the request itself with cached data and avoid contacting the originalserver.

29

2.4. The World Wide Web Chapter 2. Technical Background

permits the use of more compelling commercial examples. However the techniques presentedin this thesis are not limited to apply to only the web-protocols; rather they apply to any similardistributed system.

This section describes the web protocols in fine detail and describes anapproximationofthe interface exposed by a web-based application in terms of the formalism described earlier inSection 2.3. The approximation is only needed to simplify the work presented in later chaptersand does not reduce the power of the policy systems described. Examples in later chapters willassume knowledge of protocols and the interface details described here.

At a minimum all distributed systems must provide three things: (i) a protocol for transmit-ting data between entities; (ii) a method for naming entities and resources; and (iii) a standarddata format. The WWW uses the HyperText Transfer Protocol (HTTP) to transfer typed dataobjects; Uniform Resource Identifiers (URIs or URLs or URNs) to name objects; and the Hy-perText Markup Language (HTML) to describe the the structure and content of hypertext doc-uments. Note that HTTP and URIs may be used to transfer data other than hypertext (such assound or video files) but the following presentation will focus exclusively on HTML — this isbecause HTML documents contain URIs pointing to further data objects while other files (suchas sound, graphics or videos) are simply ‘leaf’ nodes, containing no further links. Each of thesecomponents is described in the following sections.

2.4.1 HTTP

According to RFC 2616 [64], HTTP is an “application-level protocol for a distributed, collabo-rative, hypermedia information system”. HTTP is designed to run over a reliable transport pro-tocol, typically the internet Transmission Control Protocol (TCP/IP). Messages are designed tobe self-describing; properties of the payload data are listed in messageheadersincluding cacha-bility hints and content type indication. HTTP is a very flexible protocol which can be used tointerface with legacy systems such as File Transfer Protocol (FTP) servers and Network NewsTransport Protocol (NNTP) servers, providing users with a common and consistent interfaceacross disparate systems.

As described earlier in Section 1.6 many current firewalls are configured to let HTTPthrough and to block other traffic – a situation that has encouraged application writers delib-erately to encapsulate their protocols within HTTP. IP itself can even be tunnelled over HTTPcreating the possibility of making Virtual Private Networks (VPNs) spanning multiple organi-sations ignoring firewalls (and associated firewall policy).

Protocol Roles

HTTP defines a number of roles, including client, server and proxy. An HTTP client is anyentity which can create a request and send it somewhere. Correspondingly, an HTTP serveris any entity which can receive a request and reply with a response. Clients and servers neednot be distinct entities. For example, HTTP proxies are both clients and servers; they receiverequests from clients by acting as a server and then forward the requests by acting as a client.Like the interface proxies described in Section 2.3.2, HTTP proxies may not change the inter-face exposed by an application, performing only simple caching functions. Entities which canperform interface transformations are also known as firewalls.

2.4.2 Naming Resources

Uniform Resource Identifiers (URIs) are the primary means by which objects on the web arenamed. The general structure of a URI is as follows:

30


scheme : scheme-specific-part

The first part,scheme , names a family of URIs. Example schemes includehttp , ftp andmailto . Thescheme-specific-part is defined by the specification of the scheme. Acommon set of URI schemes share a hierarchical syntax for the scheme-specific part:

// authority path ? query

Theauthority usually refers to a host by DNS name, thepath is an optional ’/’-separatedsequence of names analogous to a filesystem path and thequery is some optional, arbitrarydata relative to the named path. Examples of URIs include

mailto:[email protected]://www.cl.cam.ac.uk/pub/http://www-lce.eng.cam.ac.uk/

The optionalquery part of an HTTP URI contains ‘&’-separatedkey=value pairsknown asquery parameters. The URIhttp://www.example.com/foo?a=b&c=d hastwo such parameters:a=b andc=d . Query parameters are used to pass information toWebApplications, described later in Section 2.4.4. For the rest of this thesis the term URI shall referto the scheme, authority and path of HTTP URIs (e.g. the parthttp://www.example.com/foo ) without the parameters, which will be considered separately.

Many RFCs and technical documents refer to URLs and URNs as well as URIs. Uni-form Resource Locators (URLs) are technically a subset of URIs, specifically those whichidentify an object by the combination of its primary access mechanism and address (e.g.ftp://www.cl.cam.ac.uk/pub ). Uniform Resource Names (URNs) are another sub-set of URIs, specifically those which identify a document by apure namei.e. a name whichhas no visible location information8 (e.g. a telephone number without the area code is a purename9).

Although classifying URIs into URLs and URNs seems appealing, many URIs found on theInternet are neither strictly one nor the other. For example the URI corresponding to an entryin a telephone directory might behttp://directory.org/phone/07771234567 , anidentifier which contains some location information (i.e. access hostdirectory.org viaHTTP) as well as a part which is more like a URN (i.e.07771234567 ). This confusion haspersisted, with the terms URI, URL and URN often used interchangeably. The general termURI shall be used exclusively in this thesis to refer to all names: pure or impure.

Protocol Messages

HTTP messages come in two flavours: requests and responses, depicted graphically in Fig-ure 2.9. Both request and response messages consist of a series of CR-LF terminated stringlines (the header) followed by a blank line and then an arbitrary payload. The first header lineis mandatory and indicates the message type (e.g. whether it is a request or response) while theremaining header lines contain a series of key-value pairs. According to the HTTP RFC [22],some headers are mandatory, some are encouraged while others are entirely optional. An im-plementation will typically ignore unknown headers. The exact encoding used by the payload

8To quote Needham and Mullender [120]: “a pure name just identifies. An impure name guides.”9Note that earlier implementations of the telephone system may have encoded some location information in

telephone numbers to aid call routing; now that it is possible for numbers to be ported between network operatorsthe names are pure.

31

http://www.example.com/foo?a=b&c=d

http://www.example.com/foo


ftp://www.cl.cam.ac.uk/pub

http://directory.org/phone/07771234567

directory.org

07771234567


(blank line)

Payload

Mandatory request lineGET /foobar HTTP/1.1

Method URI pathand query

ProtocolVersion

...Host: 127.0.0.1:8000Cookie: sessionid=1......

...

...

...

...

...

Headers

(blank line)

HTTP/1.1 200 OK

...

...Set-Cookie: sessionid=1......

<!DOCTYPE HTML PUBLIC ...><html>......</html>

ProtocolVersion

StatusCode

Human-readableMessage

Mandatory response line

Headers

Payload (HTML document)

HTTP Request Message

HTTP Response Message

Figure 2.9: HTTP message formats. Both request and responses consist of a number of CR-LFterminated string lines followed by blank line then a payload.

32


is specified in the header (using theContent-Encoding key) and may be anything fromstraight ASCII text to the output of a compression program likegzip .

The mandatory first header line of both requests and responses have one feature in common:they both contain the generating protocol version, albeit at different places in the first line. Thisprotocol version is intended to allow interoperability with future protocol versions. The generalfeatures of requests and responses shall now be described in more detail.

The mandatory first line of a request consists of amethod(roughly speaking a type ofaction to perform) and the path and query from a URI (URIs were described previously inSection 2.4.2). The rest of the URI – the authority – is not in the first line but in theHost:header. Applications are free to either invent their own custom method types or to use one of apre-defined set which includes the following:

GET : indicates the request is a simple data retrieval operation which should not have side-effects on the server.

POST : invokes an action on the server (identified by the URI) with arguments supplied in thepayload.

By convention when a user presses the submit button on a form rendered by a web-browser, thecompleted form values are uploaded to the server by the browser as either query parameters of aGET message or as part of the payload of a POST message. For simplicity this thesis considersthe former – form parameters are uploaded as the URI query parameters – and hence the requestpayload can be ignored.

The mandatory first line of a response message consists of the protocol version togetherwith a status code and a human-readable message. The human-readable message is intended tohelp the user understand the message and is conventionally ignored by non human-controlledweb clients. There are predefined status codes for a number of common scenarios including:(i) request was completed successfully; (ii) the URI was not found on the server; and (iii) theobject identified by the URI has moved to another place. As explained earlier, we assume herethat all response payloads contain only HTML data.

One type of header is especially important and appears in both requests and responses.Originally invented by Netscape Communications Corporation, acookie is a key-value pairsent to a client by a server in aSet-Cookie: response header. By convention a cookie-compatible client will return this data to the server in future request headers. Cookies maybe used for any purpose but common uses include storing user preference information and toassociate together requests from the same client, providing the illusion of session state over theHTTP protocol.

Example Request and Response Messages

This section describes examples of HTTP messages in the context of a simple series of interac-tions between a client and a server. First, imagine the client invokes aGET request targetingURI http://127.0.0.1:8000/first on the server. The headers of the HTTP requestmessage generated are displayed in Figure 2.10. The mandatory first header line indicatesthat the message is aGET request using protocol version 1.1. By concatenating theHost:header and rest of the mandatory first header line we can see the message is targeted at the URIhttp://127.0.0.1:8000/first . TheConnection:keep-alive header is a hintsent from the client that the underlying TCP connection stay open after the current transaction

33

http://127.0.0.1:8000/first

http://127.0.0.1:8000/first

Connection: keep-alive


GET /first HTTP/1.1

Host: 127.0.0.1:8000


User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us)

Accept: */*

Accept-Language: en-us, ja;q=0.62, de-de;q=0.93, de;q=0.90

Figure 2.10: The headers of the first HTTP request message.

HTTP/1.1 200 OK

Date: Tue, 28 Oct 2003 11:57:57 GMT

Server: Apache/2.0.40 (Red Hat Linux)

Set-Cookie: sessionid=1

X-Powered-By: PHP/4.2.2

Transfer-Encoding: chunked

Content-Type: text/html; charset=ISO-8859-1

<html>

<body>

<a href="http://127.0.0.1:8000/second">

click here

</a>

</body>

</html>

Figure 2.11: The headers of an HTTP response message.

completes for efficiency reasons10. TheUser-Agent: line indicates the request was gener-ated by an Apple Macintosh computer running the browser called “Safari” while theAccept:andAccept-Language: headers describe which content types and languages are preferredin the response.

Continuing the example, Figure 2.11 shows the the response sent back by the server. Themandatory first line indicates the server is replying using protocol version 1.1 and the statuscode is 200 with human-readable message “OK”. The rest of the headers indicate the servertype, type of content and content encoding type. TheSet-Cookie: header contains the key-value pairsessionid=1 which the server expects the client to return in subsequent requests.The payload of the response contains an HTML document (HTML is described in more detailbelow in Section 2.4.3) which contains a single link with URIhttp://127.0.0.1:8000/second .

Assuming the payload HTML is rendered by a web-browser and the user clicks the link,the web-browser will produce a second HTTP request like that shown in Figure 2.12. Thesecond request differs from the first request in two respects: (i) the URI query has changed from/first to /second ; and (ii) the second request has theCookie: header which returns thedatasessionid=1 to the server. The server will be able to use this cookie to customise the

10The TCP protocol uses aslow startalgorithm and it is therefore often faster to reuse the same connection onceit has increased its send window size rather than constantly opening and closing new connections.

34

User-Agent:

Accept:

Accept-Language:

http://127.0.0.1:8000/second

http://127.0.0.1:8000/second


GET /second HTTP/1.1

Host: 127.0.0.1:8000


Cookie: sessionid=1

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us)

Accept: */*

Accept-Language: en-us, ja;q=0.62, de-de;q=0.93, de;q=0.90

Figure 2.12: The headers of the second example HTTP request message.

next response to the user.

2.4.3 HyperText Markup Language

The HyperText Markup Language (HTML) is a language for creating structured hypertext doc-uments defined by the W3C [175]. HTML documents are primarily intended to be viewed byhumans using graphical web-browser programs. HTML documents contain content, formattinginformation11 and references to other documents. The language HTML is specified using theStandard Generalised Markup Language12.

An example HTML document may be seen in Figure 2.13. The document is a tree ofele-mentsof the form<name> ... </name> . The text<name> is known as anopening tagand</name> is known as aclosing tag. Elements with no contents can be written in the shortform <name/> . Some elements haveattributeswhich are key-value pairs written as<namekey1=val1 key2=val2> where the elementname has two such pairs: (key1 ,val1 ) and(key2 , val2 ). The example also contains ahyperlink– a reference to another document –written using the syntax<a href="URI">label</a> wherelabel is human-readabletext to be displayed by the web-browser program andURI is the URI to be followed when theuser selects the hyperlink.

Users with graphical web-browsers can interact with servers through HTML forms as wellas hyperlinks. HTML forms allow the user to fill data into text fields, select items from dropdown lists and toggle checkboxes. Special submit buttons allow the form data to be uploaded tothe server using a POST request. In the example of Figure 2.13 there is a single form element.The element has two attributes:target andonSubmit . The URI to which the data will besent is given by thetarget attribute and theonSubmit attribute allows the HTML authorto include some client-side Javascript code which is executed once the user presses the submitbutton but before the data is uploaded to the server. Javascript code is commonly used toprevalidate the contents of a form before incurring the latency of a full network round-trip tothe server. If a form fails the Javascript validation check then the error will be reported to theuser through a pop-up dialog and the HTTP request will be aborted.

Relation to XML

At first glance XML and HTML look very similar. In fact they are different both in terms ofsyntax and in terms of purpose. XML has much simpler syntax than HTML and is thereforemuch easier to parse. Every XML document must have properly nested elements and no tagsmay ever be left out. In contrast, HTML is more flexible and in some circumstances tags may

11Presentation information can also be abstracted usingstyle sheets, not discussed further here.12More information relating HTML and SGML can be found athttp://www.w3.org/TR/REC-html40/

intro/sgmltut.html

35

http://www.w3.org/TR/REC-html40/intro/sgmltut.html

http://www.w3.org/TR/REC-html40/intro/sgmltut.html


<html>

<head>

<title> This is an example page </title>

</head>

<body>

<h1> This is a title </h1>

This is some ordinary text.

<a href="http://www.example.com/">hyperlink</a>

<form target="http://www.example.com/"

onSubmit="...">

<input type="text" name="foo" value="bar"/>

<input type="submit"/>

</form>

</body>

</html>

Figure 2.13: An example HTML document

be left out, their presence being inferred automatically by the parser. Due to the legacy of theWWW and the many web-pages containing invalid HTML, many web-browsers accept invalidHTML without complaints, parsing them using heuristics. XML parsers, by contrast, are muchstricter.

HTML and XML are meant for different purposes. HTML is designed specifically forencoding hypertext documents whereas XML is a generic mechanism for encoding data for anypurpose. Each XML document is associated with a Document Type Definition (DTD) whichdescribes the set of acceptable element names, how the elements may nest and the attributeseach element should have. An XML parser which checks the XML document is valid withrespect to the DTD is known as avalidating parser.

2.4.4 Web-Applications

This thesis uses the following simple definition:

A Web-Application is any application which uses URIs to name remote proceduresand HTTP to transmit requests and responses.

Both web-application clients and servers can take many forms. A client can be anythingfrom a graphical user program to a command-line URI fetching tool. A server can be anythingfrom a web-server running a set of scripts to a graphical program presenting a remote con-trol interface over HTTP. Some servers associate URIs with static HTML pages while othersdynamically generate responses at runtime. Some types of client will parse HTML receivedin responses from the server. Aweb-spideris a type of client which will attempt to traverseall links from a starting page either in search of a particular object or to build up a databaseof reachable pages. Aweb-browseris another type of client which will parse and render theHTML responses on the user’s screen. The web-browser invites the user to fill in forms andclick on links to generate further HTTP requests.

2.4.5 Web-Applications: Handling Application State

HTTP is a stateless protocol. Many applications are inherently stateful and need to create theillusion of a coherent session between the application and the user. The only way to do this is

36


to send session information to the client either as a cookies or as part of an HTML form. Thisclient-side state is then returned to the server (as either a cookie or URI parameter) when thenext URI is invoked. Such client-side state can take three different forms:

1. an opaque identifier referencing server-side state;

2. data cryptographically protected against modification; or

3. plaintext data.

Each of these options has advantages and disadvantages. The first — an opaque identifier— has a security advantage: the client has no way of directly accessing the data pointed toby the identifier since it exists only on the back-end server. However it also has two majordisadvantages. Firstly the machine storing the server-side state becomes a bottleneck; everyrequest involves consulting (and possibly updating) this shared state. This becomes especiallycritical if the site is busy and the state is replicated and must be kept in sync across severalservers. Secondly the server must take responsibility for deleting the state at the right time – atricky operation since a user mightbookmarka session and attempt to return later, only to findthe session state has been deleted.

The second option listed involves sending application state to the client cryptographicallyprotected to guarantee itsintegrity (integrity is explained in detail later in Section 2.5.2). Thisoption has the advantage that it involves storing no state on the server (which otherwise mightlimit how many clients the server can support), except any secret keys necessary to verify theintegrity of the data. The main disadvantage of this method is the state might be large andtherefore take significant time to protect and transmit.

Finally, the third option – keeping the data on the client side in plaintext – has the advantageof simplicity. Indeed many kinds of session state can be stored safely on the client in this waye.g. user preference data. However, this method is totally unsuitable for any data which, ifmodified, could disrupt the workings of the application. More will be said about this problemlater in Chapter 5.

2.4.6 Interfaces of Web Applications

This section shows how an approximation of the interface of a Web Application may be de-scribed using the formalism from Section 2.3. Section 2.4.4 defined a web-application to beany application which uses URIs to name remote procedures and HTTP to transmit requestsand responses. HTTP requests and responses were described in detail in Section 2.4.2.

First consider an HTTP request. The request consists of four parts: (i) a method (i.e. GET,PUT, POST or an application-defined custom method name); (ii) a URI; (iii) the rest of theheaders; and (iv) the payload. Application data can therefore be sent to the server as (i) namesof custom methods; (ii) URI query parameters; (iii) headers; or (iv) within the payloads. In-dividual web-applications can use any arbitrary combination of these. Rather than include allof these separately in our interface description we instead assume that, for simplicity, all ap-plication data is contained solely within the URI query parameters and one particular header –the Cookie: header (described earlier in Section 2.4.2 this header contains an arbitrary keyvalue pair which the server wishes the client to add to its future requests). This assumptiondoes not reduce the power of the policy systems described in later chapters; they could easilybe expanded to consider all these extra possibilities, treating them exactly the same way they do

37

Cookie:

2.5. Security Principles Chapter 2. Technical Background

query parameters and cookies. Cookies shall be represented as key-value pairs using the type

type cookies = (string × string) list

We assume that user supplied data is encoded as part of the URIquery parameters. In theURI http://www.example.com/foo?a=b&c=d the part after the? is the query stringcontaining the two parametersa=b andc=d . Query parameters are key-value pairs which maybe represented by the type:

type parameters = (string × string) list

The remainder of the URI (the non-query part) shall be considered as a simple type:

type uri = string

Therefore an HTTP request has the type

type request = uri × parameters × cookies

An HTTP response message may be broken down into three parts: (i) a status code; (ii) therest of the headers; and (iii) a payload. We shall ignore the status code (implicitly assumingit to be 200 – success) and all the headers except theSet-Cookie: header. For the sakeof simplicity we consider the payload to contain an HTML document which contains a singleHTML form13. A form consists of a URI and a set of named controls, the contents of which areuploaded to the server when the form is submitted. The form may be represented by the type:

type form = uri × parameters

Therefore the response may be represented by the type:

type response = uri × parameters × cookies

Note that, under our assumptions, aresponse is of the same type as arequest .Figure 2.14 shows the interfaceI exposed by a web-application with URIs={U1 . . .Un},

each URI is represented by a function which expects a request and generates a response but oth-erwise makes no assumptions or guarantees. The name of each URI in interfaces shall be com-monly abbreviated using thepathof the URI. For example a URIhttp://www.example.com/view would be represented using a function with nameview .

2.5 Security PrinciplesChapter 1 provided statistics from CERT showing a large year on year increase in reportedsecurity incidents and vulnerabilities. Arguments were presented that traditional approaches tosecurity – specifically network firewalls – are insufficient to deal with new threats arising dueto the increased logical and physical mobility of communicating entities. To better understandthese threats and the solutions proposed in later chapters this section provides some backgroundon the field of computer security.

First of all we attempt to define the word “security” itself. One definition of security takenfrom the Oxford English Dictionary is as follows:

13A link may be considered a primitive type of form consisting of only a single submit button.

38

http://www.example.com/foo?a=b&c=d

http://www.example.com/view


Chapter 2. Technical Background 2.5. Security Principles

interface I {type cookies = stringtype uri = stringtype parameters = (string × string)list



U1(in request req, out response res) assume { }guarantee { }

. . .Un(in request req, out response res) assume { }

guarantee { }}

Figure 2.14: Interface of a web-application with URIs={U1 . . .Un} using the formalism ofSection 2.3.

the condition of being protected from or not exposed to danger; safety.

How might someone or something be exposed to danger? Exposure to danger could arise inone of two ways: (i) through a direct action; or (ii) through inaction. In the first case, the entitywhose action creates a dangerous situation is commonly known as anattacker. In the secondcase there is no explicit attacker; the danger arises through lack of an preventative action. To un-derstand how inaction might be dangerous, consider a nuclear power plant safety system whichreduces the reaction rate by lowering reaction-inhibiting control rods. If the system is preventedfrom responding during an emergency then a reactor meltdown may become inevitable.

The definition of security above suggested that security is synonymous with safety. It isworth noting that in computer science the term “safety” is used in other contexts. A program issaid to be “type-safe” or “memory-safe” if it does not violate any typing rules or perform illegal(i.e. out of bounds) memory accesses. Systems which are “type-safe” or “memory-safe” arefree from certain classes of run-time error. A program which is not type-safe or memory-safemay well exhibit unintended behaviour which could lead to security problems. For examplea program which is not memory-safe might be vulnerable to abuffer overflowattack in whichparts of the program’s code and data are overwritten with data supplied by an attacker effectivelysubverting the process.

A more specific definition ofcomputer securitycomes from Bruce Schneier in the forwardto Ross Anderson’s book on Security Engineering [13]. The definition concentrates on theproperties of an attacker, the entity whose action leads to a dangerous situation:

Security involves making sure things work, not in the presence of random faults,but in the face of an intelligent and malicious adversary trying to ensure that thingsfail in the worst possible way at the worst possible time . . . again and again.

This idea – of constantly fighting against an intelligent and malicious adversary – is famouslydescribed as “Programming Satan’s Computer” by Needham and Anderson [14].

39


Core to computer security are the concepts ofconfidentiality, integrityandavailability (CIA)which refer to keeping data secret, ensuring data remains intact and ensuring systems are re-sponsive. These concepts are described in the following sections: confidentiality is describedin Section 2.5.1, integrity in Section 2.5.2 and availability in Section 2.5.3. We are usuallyconcerned with the security of complete systems rather than separate components. In particularthis thesis is focused on security of mobile communicating systems and so a brief introduc-tion to distributed systems security is given in Section 2.5.4. Engineering secure systems isdifficult. Several reasons are suggested for this including (i) lack of composability (describedin Section 2.5.6); and (ii) the security of a system only being as strong as that of the leastsecure subcomponent (described in Section 2.5.5). This section finishes with a discussion ofApplication-Level Security in Section 2.5.7 and a brief note on the relation between security,control and policy in Section 2.5.8.

2.5.1 Confidentiality

Confidentiality involves limiting the disclosure of data by ensuring that it only becomes knownto authorised users. A common method to ensure confidentiality is toencryptdata known as theplaintextwith a secretkeyknown only to the authorised users to produce encrypted text knownas theciphertext. A good encryption scheme will make it difficult or impossible to recover theoriginal data from the encrypted data without knowledge of the key.

The split between the encryption algorithm and the key is somewhat arbitrary. In his articleon military cryptography [104] Kerckhoff put forward a number of security principles. Themost famous principle (summarised by Claude Shannon as “the enemy knows the system”) isthat one should assume the enemy already knows the workings of the security system (i.e. thealgorithm) and therefore overall security should only depend on the secrecy of thekey. Theusual assumption is that the key is some entirely arbitrary, application instance-specific, secretpiece of data whereas the rest of the system is fixed and well-known.

A very simple example of an encryption algorithm is theVernamcipher also known as theone-time pad. The algorithm requires that the length of the key in bits is the same as the lengthof the plaintext data. The ciphertext output of the algorithm is given by the bitwise exclusive ORof the plaintext and the secret key. The decryption process is also trivial; the bitwise exclusiveOR of the ciphertext and the key yields back the plaintext. This cipher is is noteworthy in that itis one of a small class of ciphers14for which it has been proved mathematically that the plaintextcan only be determined from the ciphertext through knowledge of the key.

Encryption by itself is not always enough to guarantee confidentiality. It is possible toimagine a system in which simply the presence of an encrypted message implicitly conveysinformation about the value of confidential data. In this situation an attacker may never need todiscover the key or break the encryption algorithm in order to attack the system.

2.5.2 Integrity

Integrity refers both to data having sensible values (e.g. a sensible date value would consist of avalid combination of day, month and year fields) and the data not being corrupted. The definitionof the set of sensible data values entirely depends on the application concerned. Data corruptioncan occur either naturally (e.g. as an error on a communication channel) or maliciously (e.g.through the deliberate action of an attacker). Data can be protected from accidental corruptionby appending an error-detection code which has the property that errors in the source data are

14The ciphers vary in the function used to combine the data with the key. In addition to exclusive OR, thegroupwise addition and subtraction ofn bits modulo2n also works.

40


very likely to require a change in the matching detection code. Data received with a non-matching detection code are considered to have been corrupted. So-called hash functions (one-way functions) are often used for this. A commonly-used hash function is MD5 [136].

Malicious data corruption is more difficult to counter. A simple hash like MD5 is insuffi-cient because hash functions are assumed to be public knowledge (see Kerckhoff’s Principle inSection 2.5.1) and easy to compute. An attacker would still be able to corrupt the data providedthey also recomputed the corresponding hash. An alternative is to encrypt the hash value with asecret key to form aMessage Authentication Code(MAC). Only authorised parties possess thekey and can generate and verify matching MACs. It is possible to use a hash function to builda MAC using an algorithm such as HMAC [20].

2.5.3 Availability

Availability refers to ensuring a system can respond to requests in a timely manner (recall theexample of the nuclear plant safety system described earlier). Note that having a system whichfails to respond may be even worse than having no system at all if the users have grown to relyupon it. There are many reasons why a system may fail to respond. An accident or naturaldisaster might disable a system by compromising its power supply. Alternatively, a malicioususer might launch aDenial of Service(DoS) attack, flooding a system with bogus requests andcausing it to become overloaded.

2.5.4 Distributed Systems from a Security Perspective

At the beginning of this chapter a diagram was drawn in Figure 2.2 depicting communicatingmobile agents. The system was drawn in layers, with agents at the highest layer and the phys-ical hardware at the lowest layer. This section revisits this idea with a simple example of adistributed system which is then used as a reference for subsequent security-related discussion.A distributed system by definition consists of multiple components connected by a network.The network providing the interconnect should properly also be considered a component withproperties determined by the network type; for example a trusted local area network has vastlydifferent performance and security characteristics to the untrusted global Internet. Each com-ponent is structured in a number of layers from most abstract at the top to least abstract at thebottom.

Figure 2.15 shows a simple distributed system containing 5 components: 2 endpoints, 1network element and 2 encryption modules (labelled “E”). In this example the endpoints have3 layers labelledapplication , network andphysical representing roughly the appli-cation code, the OS network code and the physical network interface respectively. These layerscorrespond to the ISO OSI layers (first introduced back in Section 1.3) of the same names, therest left out for simplicity. The network element has everything except the application code.The solid arrows represent actual communication; vertically through each stack and horizon-tally across the network. The dashed arrows indicate how layers conceptually communicatewith peer layers in other components, even though their messages are physically routed vialower level layers. In this example the encryption modules are intended to protect the confiden-tiality of the network communications. Both of the encryption modules are configured with thesame secret key:K1.

2.5.5 As Strong as the Weakest Link

The security of a system is only ever as strong as its weakest link. This follows from the as-sumption that a sensible attacker will choose to attack the system where it is weakest i.e. where

41


network

application

physical

network

physical

network

application

physical

endpoint networkelement endpoint

E

K1

E

K1

Figure 2.15: Diagram depicting a distributed system with 3 components: 2 endpoints and 1network element. Each component consists of a number of software layers. Solid arrows in-dicate actual communication between components. Dashed arrows indicate how layers withincomponents conceptually communicate with peer layers in other components.

the attack has the greatest chance of success. A corollary of this is that a system designer mustwork to defendall parts of a system, making them equally hard to attack. An interesting exam-ple of this principle in action is the case of the famous physicist Richard Feynman who noticeda number of secret document safes containing top-secret nuclear information while working atthe Los Alamos research facility. In his book [63] Feynman describes how these safes, althoughthey lookedvery solid and secure were vulnerable to simple lock-picking attacks. A thief re-quired only a small piece of metal to open the lock rather than the sophisticated cutting gearrequired to break through the walls.

Consider the distributed system design from Figure 2.15. An attacker might try to break theencryption algorithm being used by the encryption modules to gain access to the informationbeing transmitted across the network. However, if the cipher is strong and the key handled safelythen this attack is likely to be very difficult. Imagine the distributed system is a web-applicationrunning over HTTPS (i.e. HTTP over SSL). SSL uses strong ciphers and handles session keyssecurely: keys are transmitted protected by public key cryptography, where the public key ofthe server is itself signed by a trusted third party. It is difficult to attack SSL directly. Instead, anattacker may be able to find and exploit a vulnerability in the web-application software (manyexamples of such vulnerabilities are given later in Chapters 5 and 6). Attacking the system at theapplication layer completely avoids the need to break the cipher or guess the SSL session key.More discussion of application-layer security vulnerabilities is presented later in Section 2.5.7.

2.5.6 Composability

Security is not composable. Consider the distributed system displayed in Figure 2.15. Imagine adecision is taken to increase the security of the network-level encryption and so an extra pair ofcrypto modules are purchased and installed in series with the existing modules. A fragment ofthe resulting system is displayed in Figure 2.16. Furthermore, imagine the encryption modulesuse the “one-time pad” cipher first mentioned in Section 2.5.1 in which the plaintext is bitwiseexclusive-ORed with a secret key. Recall that the “one-time pad” cipher is provably completelysecure in the sense that the plaintext cannot be recovered from the ciphertext without knowledgeof the key. Now imagine that, in a configuration error, the keys used by both encryption blocksare the same i.e.K1 = K2. The net effect of both encryption blocks is to exclusive-OR the

42


network

application

physical

network

physical

endpoint networkelement

E

K1

E

K2

Figure 2.16: Diagram depicting part of the system from Figure 2.15 where an extra network-layer encryption module has been added in series with the existing module.

plaintext twice which results in the secret data being output in the clear. Thus, albeit in a rathercontrived example we have managed to take two perfectly secure systems and compose them insuch a way as to form a perfectly insecure system.

2.5.7 Application-Level Security

Earlier in Section 2.5.5 it was argued that the security of a system is only ever as strong as thatof the weakest link. An example was described in which the messages sent on the network wereencrypted but the application running on top (a web-application) had anapplication-levelvul-nerability. Rather than defeat the cryptography, an attacker only had to exploit the application-level vulnerability.

Exact definitions of application-level security vulnerabilities vary. SPI Dynamics re-port [132] define application-level security vulnerabilities as those weaknesses created whenthe constituent components of an application are combined together. In Chapter 1 argumentswere presented that future systems are likely to be constructed out of communicating mobileagents. Therefore for the rest of this thesis the following definition will be used:

An application-level vulnerability is a weaknesses in a system caused by unin-tended component movement or interface communication.

In their report, “Application-Level Firewalls Required”, Gartner [127] describe how currentsecurity measures are targeted at the network-level. They operate by blocking network packetsdestined for vulnerable services. Gartner predict that in the future systems will be attackedprimarily at the application-level; i.e. rather than attack the system hosting the service (wherethe system is protected by a network-firewall and security is the strongest) crackers will insteadattack the service itself.

There is much empirical evidence that current systems are vulnerable to application-levelattack. According to a ZD-NET survey [113] 30-40 percent of all e-commerce sites and accord-ing to Internet Security Systems (ISS) [95] 11 widely-deployed shopping carts are vulnerable tosimple application-level attacks. The fact that so many vulnerabilities are being found in appli-cations should not really be surprising. There are many more different applications in existence

43

2.6. Model Checking using PROMELA and SPIN Chapter 2. Technical Background

than there are operating systems or network stacks. Most web-applications are bespoke piecesof software which deployed on commodity operating systems. Operating systems tend to beheavily studied for security vulnerabilities; for example the OpenBSD Project [6] continuallyperforms security audits of its core operating system code. For the remainder of software whichis not so carefully scrutinised, this thesis advocates the use of application-level policy languagesto protect against many common kinds of vulnerability.

2.5.8 Security, Control and Policy

Control is an important aspect of security. Control can be considered as the ability to respondto a threat or potentially unsafe situation. To control a system is to be able to exercise poweror authority over the system, to check that everything is working properly and to orchestratecorrective action or impose a suitable restraint if necessary. Should a system develop a fault(through either accident or malicious attack) an ability to control the system (e.g. to shut itdown cleanly) may permit a reduction in the amount of harm caused.

2.6 Model Checking using PROMELA and SPIN

Model checking [42] is a technique for the automated verification ofreactive systemswhere areactive system is one which consists of components communicating with each other and theirenvironment, like the layered systems described earlier in Section 2.5.4. In order to modelcheck a system one must first represent it by a suitable model. The models described hereare all finite, however there exist infinite-state model checking algorithms which explore thestate space lazily. The model must be detailed enough to exhibit the interesting behaviour faith-fully while remaining as small as possible. Desirable properties are represented as temporallogic15 formulae and therefore model checking corresponds to checking the truth of the formu-lae with respect to the model. Model checker programs operate by exhaustively searching thestate-space of a model and may never terminate in a reasonable time if the model is too complexand the state-space is too large.

The finite models used in model checking are based on Kripke structures defined as thefour-tuple:

M = (S, S0, R, L)

whereS is a finite set of states,S0 ⊆ S is a finite set of initial states,R ⊆ S × S is atransition relation between states such that∀s ∈ S.∃s′ ∈ S.R(s, s′) andL : S → 2AP isa function mapping every state to a set ofAtomic Propositions(APs) which are true in thosestates. For a formulaf written in temporal logic, model checking corresponds to verifying thatM |= f . Common choices for temporal logics include Computation Tree Logic (CTL) andLinear Temporal Logic (LTL).

2.6.1 PROMELA

PROMELA [89] (PROcess MEta LAnguage) is the language used by the SPIN (Simple PromelaINterpreter) model checker to specify models. In addition to checking LTL properties, SPIN canalso verify that PROMELA models are free of deadlocks, race conditions, assertion violationsand that liveness properties hold (i.e. “good” states happen eventually). The rest of this sectiondescribes the main features of PROMELA needed for the rest of this thesis.

15Temporal logics are modal logics where each distinct universe corresponds to a system state at a particularpoint in time.

44

Chapter 2. Technical Background 2.6. Model Checking using PROMELA and SPIN

Type Size in bits Signed or unsignedbit 1 unsignedbool 1 unsignedbyte 8 unsignedshort 16 signedint 32 signed

Figure 2.17: Table describing basic PROMELA data types.

A PROMELA program consists of a finite number of processes, interconnected by channels.Processes consist of blocks of individual atomic statements; the statements from two processesrunning concurrently are interleaved arbitrarily. Multiple statements can be grouped togetherinto larger blocks using the keywordatomic ; such blocks are guaranteed, if executed, to beexecuted atomically and not interleaved with other statements.

Variable declarations

Variable declarations are scoped and may appear either globally or inside individual processspecifications. Each declared variable has a type drawn from a set including (i) basic types; (ii)structured types; and (iii) channel types. The basic types are:bit , bool , byte , short andint . Details of the basic types may be found in Figure 2.17.

Variables associated with a special type calledmtype are associated with a global set ofsymbolic constants. For example the following PROMELA program fragment:

mtype = { SYN, ACK, FIN }mtype a = SYN;

declares a variablea of typemtype which has been assigned the valueSYN. Structured typesinclude records and arrays. Record types are declared using the keywordtypedef in thefollowing way:

typedef Structure {bool flag;int value;

}

In this example, a new record type namedStructure has been declared with fieldsflagandvalue accessed using the syntaxx.flag andx.value on a variablex . An array typecan be declared using the C-like syntax:

bool flags[N];

whereN is the number of elements in the array.Finally, channel types are represented by the typechan . In the following program fragment:

chan a;

the variablea has been declared as a channel type.

45


Defining and running processes

Processes are declared using the keywordproctype . Processes have a list of formal param-eters and a block of statements. Processes are instantiated through the keywordrun . Thesame process specification may be instantiated several times with different parameters throughrepeated calls torun within specialinit blocks, where theinit block is analogous to themain function in a C program.

Blocking behaviour

Each individual atomic statement contained within a process specification may be either a com-mand or an expression. Each has a notion of “executability”; being said to be either enabledor blocked, depending on the state of the program. Assignments and unconditional branches(using thegoto keyword) are always enabled. Expressions are enabled if they evaluate to truee.g. the expression

x == 1;

blocks until the variablex has the value1. Conditions are written using the syntax:if:: ( stmt0) -> block 0

. . .:: ( stmtn) -> blockn

fiFor each branch0 . . . n, the branch is enabled if the corresponding guard statement

(stmt0 . . . stmtn) is true. If more than one branch is enabled at the same time then one en-abled branch is chosen non-deterministically.

Channel Communication

Channels are declared using syntax like the following:

chan c = [1] of { mtype, bit };

In this example, the channelc is declared as a channel with a buffer length of 1 acceptingmessages which are pairs ofmtype andbit . Channels can be created with any finite bufferlength greater than or equal to zero. A buffer length of zero indicates the channel is synchronous— i.e. a write to the channel blocks until another process simultaneously reads — while a bufferlength of greater than zero indicates the channel is asynchronous.

Sending and receiving are performed using the! and? operators respectively. The follow-ing command:

c!SYN,1;

transmits the pair〈 SYN, 1 〉 on the channelc (recall the channelc was declared above toaccept pairs ofmtype andbit values). If the channel is empty then this command is enabledand will not block. If the channel is full (i.e. in the case of channelc a full channel wouldcontain only one message) then the command is blocked. Note also that if more than onewrite is blocked on a full channel and another process performs a read, one of the blocked writecommands is selected non-deterministically to complete i.e. there is no input queueing or notionof fairness for blocked I/O commands.

Values can be read from the channelc using the following syntax:

46


c?a,b;

The variablesa andb should be of typemtype andbit respectively16. As well as a standardreceive operation, PROMELA supports a non-side-effecting receive operation which behaves likea normal receive but without removing the message from the channel. The following command:

c?<a,b>;

copies the next message in the channel (a pair ofmtype andbit ) into the variablesa andb.Future reads will read the same value.

Assertions

Assertions may be added to PROMELA programs using the syntax:

assert(e);

This assertion causes the program to abort if the expressione evaluates to true in the currentexecution of the program.

2.6.2 Simple PROMELA example

This section demonstrates the capabilities and syntax of PROMELA via a simple example, basedon the Internet protocol TCP. TCP is a peer-to-peer protocol17 for establishing reliable stream-based connections over datagram networks. TCP has many advanced features including errorrecovery, flow and congestion control which will not be modelled here. Instead TCP shallbe modelled as a simple client-server system in which a client connects to a server and thendisconnects, transmitting no data.

Figure 2.18 shows an example PROMELA model of a system comprising two components: aclient and a server. The components are represented by processes started atomically usingrunstatements in theinit block at the bottom of the program text. The processes are connectedby two channels:c to s ands to c for client to server and server to client communicationrespectively. The client proctype transmits aSYNbefore receiving from the channel. If theclient receives aRST(i.e. if the server rejects the connection) then the client jumps to the labeldone and exits. If the client receives a superfluousSYNthen the assertionassert(false) istriggered and the computation aborts. If the client receives anACKthen it transmits aSYNACK,confirming the connection before transmitting aRST.

The server process blocks waiting for a client to attempt a connection by sending aSYNmessage before non-deterministically choosing between two options: (i) rejecting the connec-tion by sending aRST and jumping to the labeldone ; and (ii) accepting the connection bytransmitting anACKbefore receiving aSYNACK, at which point the connection is consideredopen. The server then expects aRST18 from the client, closing the connection.

Figure 2.19 shows two examplemessage sequence chartscorresponding to potential exe-cution paths through the PROMELA program from Figure 2.18. The topmost chart shows theclassic TCP 3-way handshake (SYN, ACK, SYNACK) before the connection is closed by theclient sending the server aRSTmessage. The bottommost chart shows the server rejecting theclient’s connection request by replying to theSYNwith aRST.

16Like C, PROMELA will perform automatic casts of types to other compatible types. This mechanism is ignoredto simplify the presentation.

17Although many people talk about “clients” and “servers” in the context of TCP it itself has no such concept.Connections can be initiated by either party and even initiated simultaneously by both sides.

18Normally a TCP connection is put into a specialclosingstate first using aFIN message but that will not bemodelled here.

47


mtype = { SYN, ACK, SYNACK, RST }

proctype client(chan input; chan output) {output!SYN;if:: input?RST -> goto done; /* refused */:: input?SYN -> assert(false); /* impossible */:: input?ACK -> skip;fi;output!SYNACK;/* established */output!RST;

done:skip;

}

proctype server(chan input; chan output) {input?SYN;if:: true -> { output!RST; goto done }:: true -> output!ACK;fi;input?SYNACK;input?RST;

done:skip;

}

chan c to s = [1] of {mtype }chan s to c = [1] of {mtype }

init {atomic {

run client(s to c, c to s);run server(c to s, s to c);

}}

Figure 2.18: A simple example PROMELA program consisting of two processes:clientandserver interconnected by two channels. The program models a small part of the TCPprotocol.

48


client server

SYN

ACK

SYNACK

RST

Step 1

Step 2

Step 3

Step 4

client sends server aSYNchronise message

server responds with anACKnowledgement

when SYNACK is sent, theconnection is open

a ReSeT message endsthe connection

SYN

RST

Step 1

Step 2

client sends server aSYNchronise message

a ReSeT rejects theconnection

Figure 2.19: Two message sequence charts corresponding to two possible runs of the programin Figure 2.18. [Top] shows a connection created and then shut down; [Bottom] shows a rejectedconnection.

49

2.7. Summary Chapter 2. Technical Background

2.6.3 Model checking with SPIN

Once a valid PROMELA program has been created it is possible to mechanically verify someuseful properties with the model checker SPIN. Three general techniques shall be covered herebut the list is by no means exhaustive. The techniques are:

• detecting invalid end states;

• detecting assertion violations; and

• detecting lack-of-progress cycles.

Invalid End States

An invalid end stateis one in which either (i) all spawned processes have exited leaving unreaddata in a channel; or (ii) the system is deadlocked i.e. all processes are active but blocked.Invalid end states often happen when a message arrives on a channel at an unexpected point; forexample, if the client process in Figure 2.18 were to send anything other than aSYNmessageat the beginning then the server would remain blocked and the system would deadlock.

Assertion Violations

The client process in Figure 2.18 has the commandassert(false) which is triggered ifthe client receives an unexpectedSYNwhen it is expecting either aACKor a RST. SPIN isable to search through every possible execution sequence and verify that this assertion is nevertriggered.

Lack-of-progress Cycles

SPIN can detect livelocks in programs as well as deadlocks and assertion failures. A livelock isdefined to be any infinite loop in the program (i.e. a cycle of states in the state machine) whichdoes not go through a specially markedprogressstate. In SPIN terminology a livelock is knownas a lack-of-progress cycle. A state is marked as a progress state by attaching a label with theprefix progress . In the TCP example from Figure 2.18 the client and server could be mademore realistic by adding a labelstart: at the beginning and agoto start command at theend. The modified processes would be able to loop forever, continually starting up and shuttingdown connections. As well as being a closer approximation to reality, this would likely helpfind bugs where messages from a previous connection prevent a new connection from beingsuccessfully started. However now that the program contains infinite loops, SPIN has no way todistinguish desirable looping (continually starting and stopping connections) from undesirable,buggy loops where (for example) the server enters an infinite loop part-way through establishingone particular connection. To resolve this difficulty we need to change the label at the beginningfrom start: to progress start which signals to SPIN that the only valid infinite loopsmust go through this state and any other loop represents livelock.

2.7 SummaryThis chapter provided background on several topics essential for understanding the followingchapters. Mobile Agents – software programs which can move themselves between hosts on thenetwork – were described in detail. Since future applications are likely to be physically as wellas logically mobile, the ability for a device to sense its location is becoming more important.Several possible location-sensing mechanisms were presented along with several arguments asto why future devices are likely to be equipped with such mechanisms. A simple formalism

50

Chapter 2. Technical Background 2.7. Summary

for describing communication interfaces was presented and web-application were described asa concrete example. Relevant topics within the field of computer security were discussed anda brief introduction to model-checking – a technique for automatically verifying properties ofcommunicating systems – was presented.

51

Chapter 3

A Spatial Model

This thesis argues that abstracting application-level security policy (policy written to governboth themobility and interface behaviourof systems) is an effective technique for guardingagainst application-level vulnerabilities which it was argued, would otherwise plague futureubiquitous computing systems. This chapter and Chapter 4 concern the security issues involv-ing the mobility aspect of systems; Chapters 5 and 6 focus on those involving theinterfacebehaviour.

Two distinct types of mobility have been introduced already. Physical mobility, in whichentities running computer programs move in three-dimensional space was introduced first inSection 1.1. It was argued that physical mobility will inevitably increase as hardware devicesproliferate and become ever smaller. Logical mobility, in which mobile agents running oncomputers move themselves between hosts was introduced first in Section 1.5 and described inmore detail in Section 2.1. Both types of mobility are inherently related; the logical locationoccupied by a running mobile agent must be associated with a particular CPU which itselfis a physical object with a defined physical location at a given point in time. The focus ofthis chapter is to produce a unified representation of space known as the Unified Spatial Model(USM) which allows users and applications to reason about both physical and logical movementwithin the same framework. Users will be able to use this framework to write new kinds ofsecurity policies, explored in more detail in Chapter 4, which combine elements of traditionalsecurity policy (“no entry to unauthorised personnel”) with computer security policy (e.g. “ noaccess to this resource”). Later in Chapter 7sentient mobile applicationsare introduced whichuse this framework tosensetheir environment andreactaccordingly.

This Chapter describes the Unified Spatial Model (USM) capable of representing simulta-neously the disparate worlds of physical spaces (complete with notions of physical location,containment and proximity of objects) andvirtual spaces i.e. those inhabited by mobile agents.The Chapter is structured as follows: Section 3.1 describes the main features of the spatialmodel. Section 3.2 describes how the model reacts to represent changes in the world and Sec-tion 3.3 describes how this model relates to others from the literature.

3.1 Modelling the WorldWe model the world as a tree of nestedentities, analogous toambientsin the Ambient Cal-culus [34]. The Ambient Calculus is described in the related work section at the end of thischapter in Section 3.3.1. We begin our description by defining the following set of terms:

entity name: label used to name entities which may have further entities nested inside. Entitiesform a nesting hierarchy and sequences of entity names describe a route through thehierarchy. Examples of entity names include the names of physical places, computers

52

Chapter 3. A Spatial Model 3.1. Modelling the World

and mobile agents. By convention we useη to range over all entity names and lower-caselettersa, b, c, d, e to range over mobile agent entity names.

entity: description of a spatial location. Entities might consist of nested entities with an en-tity name, sibling entities in parallel, special entityfactoriesor void (i.e. nothing). Notethat, in a similar fashion to the Ambient Calculus, we are not restricted to describing onlyphysical places but can represent any bounded region where activity happens. For exam-ple an office containing people may be described as an entity, as can a virtual machinecontaining mobile code. We use capital lettersX, Y, X ′, Y ′ to range over entities.

path: sequence of entity names describing a route through the entity hierarchy naming a spe-cific entity. Paths are written in the form of a sequence〈η1, . . . , ηn〉 and are describedfurther in Section 3.1.3.

path expressions:regular expression-like facility to efficiently name a set of entities. Pathexpressions are described further in Section 3.1.3.

We divide our entity names intosortseach representing a different kind of object. The sortsprovide a simple well-formedness constraint on the model by restricting how entities may nest.The exact sorts used in any deployed system will depend on the kinds of things being modelled(e.g. an aviation-based system may introduce the sort “aircraft”) but for expository purposes werestrict ourselves to the following:

room: a physical volume of space corresponding to a building, office etc.

person: an autonomous physical entity able to move betweenrooms (a human or a robot)perhaps able to carry other entities

workstation: an immovable physical object which can host computer processes

laptop: a mobile physical object which can host computer processes

context: a virtual (or physical) machine capable of running mobile code

agent: a piece of mobile code

We writee C s to mean entity namee is of sorts. The formulaSortContainable(s1, s2) holdswhen entities of sorts2 may be nested inside entities of sorts1. This formula is defined graph-ically in Figure 3.1. Intuitively, it says that physical objects may nest in the obvious way (e.g.a workstation may nest inside aroom and alaptop may nest within — i.e. be carried by — aperson) and that computers (workstations andlaptops) host virtual machines (contexts) whichin turn hostagentprocesses. Note that agents do not contain any contents themselves; this isan artifact of the prototype implementation described later. A future version could remove thisrestriction.

A state of our world model may be written down with the following syntax (whereη rangesover a set of entity names):

entity ← entity | entity (siblings)entity ← η[entity ] (nesting in a placeη)entity ← 0 (void)entity ← !η[entity ] (entity factory)

model ← η[entity ] (spatial model)

53

3.1. Modelling the World Chapter 3. A Spatial Model

room workstation

person laptop context agent

fixed (infrastructural) sorts

mobile (dynamic) sorts

Figure 3.1: The relationSortContainable.

By convention we consider an entity factory!η[X] (whereη C agent) to be a special kind ofentity which can create other entities, i.e. the factory!η[X] can spawn the entityη[X]. Note thatevery mobile agent which wishes to be created dynamically must be associated with at least oneof these factory entities.

A spatial model (represented bymodel ) consists of an entity name (theroot entity name)plus entity contents. For the spatial modelM = y[X] with namey and contentsX we say thatM is well-sortedif y C room andWS (room,X ) where the predicateWS is defined informallyas follows:

WS (s, 0) ← trueWS (s, X | Y ) ← WS (s, X) ∧WS (s, Y )WS (s, η[X]) ← ∃s′.η C s′ ∧ SortContainable(s, s′) ∧WS (s′, X)WS (s, !η[X]) ← ∃s′.η C s′ ∧ SortContainable(s, s′) ∧WS (s′, X)

In particular note that an entity factory is only well-sorted if the entity it generates would alsobe well-sorted in its place and that all entities can contain an empty entity0. Observe that thesyntax for entities is similar to the subset of the ambient calculus which has no active processesand which describes only the structure of space, like that used in the semistructured data formatdescribed in [33].

As is conventional in mobility theory we next define a congruence relation,≡, under whichentities are equal up to simple rearrangements of parts. In addition to reflexivity, symmetry,transitivity and context (X ≡ Y =⇒ η[X] ≡ η[Y ]) this relation (often referred to as astructural congruence relation) admits the following rules:

X | Y ≡ Y | X (commutativity)X | 0≡ X (zero)X | (Y | Z) ≡ (X | Y ) | Z (associativity)

X ≡ X ′, Y ≡ Y ′

X | Y ≡ X ′ | Y ′ (parallel)

54

Chapter 3. A Spatial Model 3.1. Modelling the World

context

context context context

World

Bob'sOffice

Charlie'sOffice

AlicelaptopPCCharlie

laptop

music player

context

Laptop

Context

Agent

Room

Person

Workstation

secret agent

audio default

! Entity Factory

!music player

factory

default

default

agent

a

a a a

a

a

Figure 3.2: An example world configuration in graphical form.

3.1.1 Example

Consider a simple environment containing people, computers and several mobile agents. Agraphical depiction of the model corresponding to this world at a particular time is displayed asfollows:

World [ Bob’s office [ 0 ]| Charlie’s office [

Charlie [ 0 ]| Alice [ laptop [ default [ agent [ 0]]]]| laptop [ default [ ! music player factory [ 0]]]| PC [ default [ secret agent [ 0]]

| audio [ music player [ 0]]]]

]

There are various things to note about this configuration:

1. Alice is carrying a laptop inside Charlie’s office. This laptop is currently running somemobile agent code. This mobile agent might have arrived in this room by one of twoprocesses: (i) it may have been physically moved by Alice carrying the laptop; or (ii) itmay have migrated itself deliberately after the laptop arrived in the room.

2. The PC in Charlie’s office has been configured with an additionalcontext, calledaudio .

3.1.2 Naming

For simplicity entity names have been presented as short, flat identifiers written in english;names such asAlice , laptop andmusic player . The actual names chosen are likely to

55

3.1. Modelling the World Chapter 3. A Spatial Model

be more complicated in practice. Policy systems like the one described in the following chapterwill likely need some mechanism to refer to individual objects, to either allow or disallow accessto protected resources1. Therefore it is important to be able to create and refer to unique andunforgeable names to prevent the policy system being subverted.

On the other hand allowing non-unique names facilitates policies and conventions whichapply to whole groups of things at once. For example, we may like to write a policy governinga particular class of mobile agent which is straightforward if all instances of the class of mobileagent are represented by the same entity name.

Furthermore it may be useful to represent the same object with multiple entity names collo-cated within the spatial model. For example, a music playing agent written by Alice might havetwo names:Alice’s agent andmusic player representing two useful properties aboutthe agent, specifically that it was written by Alice and is capable of playing music. Policies maythen be written to govern either (i) all of Alice’s agents; or (ii) all music playing agents ratherthan having one policy for each individual agent.

One possible implementation of such a flexible naming scheme would rely on digital sig-natures. Imagine that an agent signed by a particular key is represented by a particular entityname. If the secret part of the key is kept secret then the signature—and hence the name—isunforgeable. If the secret part of the key is made public then anyone can create entities with thatparticular name. A agent may be signed by multiple independent keys, reflected in the modelby multiple collocated entity names.

For simplicity in the rest of this chapter we will continue to use simple english names (likemusic player ) to name entities which are assumed to be unique .

3.1.3 Paths and Path Expressions

We uniquely specify a single entity name by providing a path from the root entity name usingthe nesting relation,↓M . We say thata ↓M b if b is a child ofa in the modelM , i.e.b is containedwithin one level of nesting ofa. Therefore a path from the rootp = 〈η1 . . . ηn〉 selects an entityname ifη1 ↓M η2 ∧ . . . ∧ ηn−1 ↓M ηn. For example, in the diagram in Figure 3.2 a sequence ofentity names uniquely specifying the entitymusic player could be written

〈 World , Charlie’s office , PC,audio , music player 〉

Path expressions, similar to regular expressions, are used to quantify over a set of paths. Wefirst define the↓∗M operator as the reflexive transitive closure of↓M and then write the syntax ofpath expressions as follows:

element ← η (entity name)| {η, η} (disjunction)| ∗ (any)

expression ← element| • • •/ expression| element / expression

1 Consider an agent calledsecret agent which is allowed access to some privileged resource by a policybased on the model presented here. If an attacker could make another agent with the same name then they will beable to access the resource illegally.

56

Chapter 3. A Spatial Model 3.2. Updating the World Model

World

Home

Laptop

Room

Person

Workstation

Office

Bob

Laptop

PC PCEntity with pathWorld/Home/PC

Entities matching path expressionWorld/Office/*

12

Key:

Figure 3.3: Graphical example of entities named by paths and path expressions.

We define thematching setof a path expressionexpression as a set of pathspaths usingthe following rules:

• the trivial path elementη matchesan entity nameη;

• the element{η1, η2} matchesthe entity nameη if η1 = η or η2 = η;

• the element* matchesany entity name;

• an expression of the formelement matches a path〈η〉 if element matchesη;

• an expression of the form•••/ expression matches a path〈η1, . . . , ηk, ηk+1 . . . , ηn〉whereexpression matches〈ηk+1 . . . , ηn〉 for some value ofk; and

• an expression of the formelement / expression matches a path〈η1, η2, . . . , ηn〉 whereelement matchesη1 andexpression matches〈η2 . . . , ηn〉.

Figure 3.3 shows an example spatial model with some entities highlighted. High-lighted group number 1 corresponds to the singleton entity nameWorld/Home/PC whilehighlighted group number 2 corresponds to two names which match the path expressionWorld/Office/* .

Path expressions provide a similar function to that of XPath [174], used for naming elementsof XML documents. They allow us (i) to list concisely names whose paths diverge at a point(using disjunction) e.g.a/ {b, c} matches the same names as those matched bya/b or a/c; (ii )to have paths with dislocations (using/ • • • / ) e.g.a/ • • • / b can match the same entitiesas those matched bya/b as well asa/ c/ d/ b; and (iii ) to quantify over names without directlylisting them e.g.a/* can match the same names asa/ b, a/ c anda/ d.

3.2 Updating the World ModelThe model is updated dynamically to reflect the real-time configuration of the environment byan implementation described in more detail in Chapter 7. The physical world is monitored by

57

3.2. Updating the World Model Chapter 3. A Spatial Model

location sensors, a concept first introduced in Section 2.2. Changes in the physical world –specifically the movements of objects – are then reflected by changes in the model (more detailsof the implementation are forthcoming in Chapter 7). In addition we assume that mobile agentsmay be programmatically created, killed or migrated, constrained only by the installed securitypolicies. We define legal updates to the world by a labelled transition relation,

γ→ over entities.We use labels to represent the side-effects of transitions, in particular the emission (emit(γ))and reception (receive(γ)) of an agent during migration. The absence of a label on a transitionindicates the lack of side-effects. A valid transition must have no labels at the top level – labelsmust always be matched and cancelled by the rule (migrate) described below. For brevity wewrite a↔ b if the transition is reversible i.e. if botha→ b andb→ a are legal transitions. Theimplementation (described in more detail in Section 7) ensures that every event that occurs isrepresented by a legal transition.

Now for agent creation with entitiesX,Y, Z and entity namesa, b, c wherea C person,bC room andcC laptop (i.e.a is of sortperson, b of sortroom andc of sortlaptop) we definethe following rules:

a[X] | b[Y ] ↔ b[a[X] | Y ] (walk in/out)a[X] | c[Y ] ↔ a[c[Y ] | X] (pick up/put down)

In plain terms these rules describe how a person may freely walk into and out of rooms and pickup or drop any portable physical objects (represented by entities of sortlaptop).

For simplicity everything that can happen to a mobile agent (i.e. being created, killed, mi-grated etc.) is considered as a sequence of primitive operations of the following two types: (i)leaving a particular context; (ii ) entering a particular context. For example an agent creationis considered a single event – the new agent entering its initial context, next to the factory thatcreated it. Killing an agent is a single leaving event. An agent migration froma to b is consid-ered a sequence of two events: (i) leaving the source contexta; and (ii ) entering the destinationcontextb directly afterwards.

With a view to defining mobility security policies we assume the existence of a pair of infixpredicates,canenterandcanleavewhich for a given agent with entity named and context withentity namee behave as follows:

d canleave e holds if the policies allowd to leave the contexted canenter e holds if the policies allowd to enter the contexte

Mobility policies may be “plugged-in” to the model simply by defining these predicates.For entity namesd C agent, ande C contextwe write the rule:

e[!d[Y ] | X] → e[d[Y ] |!d[Y ] | X] iff d canentere (agent created)

This rule asserts that agents may be created in those places containing an appropriate agentfactory (represented by!d[Y ]) provided the new agent is allowed to enter the surrounding con-text. Similarly, intensional agent destruction (i.e. agent suicide) is only permitted if the agent isallowed to leave the containing context, as described by this rule:

e[d[Y ] | X] → e[X] iff d canleavee (agent killed)

Agent migration between contexts is handled by the following rules:

e[d[Y ] | X]emit(d[Y ])−→ e[X] iff d canleavee (agent leaves)

e[X]receive(d[Y ])−→ e[d[Y ] | X] iff d canentere (agent enters)

58

Chapter 3. A Spatial Model 3.3. Other Modelling Techniques

Xemit(W )−→ Y Y

receive(W )−→ Z

X → Z(migrate)

Note that the act of migration is a compound operation where the side-effectemit(W ) must bematched by a corresponding side-effectreceive(W ). Therefore migration may only happen ifthe policies allow both the leaving step and the arriving step; it is impossible for the agent toget stuck somewhere in between. It is important to emphasise that only the results of topleveltransitions are visible to applications – applications cannot see any intermediate states of themodel. We get away with this because our work so far has focused on a trusted “intranet”-styleenvironment where complications due to unreliable network communication and partial failureare minimised.

Agent migration could be represented differently if we allowed agents to simply climb theentity hierarchy and then walk down again – the approach taken in the Ambient Calculus. Thiswould allow us to simplify our rules by removing the labels on our transition relation. However,allowing an agent to move anywhere in the hierarchy could lead to violations of the sorting rules(described in Section 3.1). Additionally there is a subtle semantic difference with respect to thesecurity policies: by using the “teleporting” approach described here, only the configurationsat the start (the leaving step) and at the end (the arriving step) are relevant. If the agent wereto have to walk from one place to another then the migration could potentially be blocked bya policy attached to an entity somewhere in the middle. Sometimes this effect is desirable; forexample in the case of a firewall, agents would have to explicitly move through the firewall andbe subject to its policy, rather than teleport past it, avoiding its policy.

To complete our description of how the model can be updated we have the following ruleswhereX ′ andY ′ are entities:

!η[X] → !η[X] | η[X] iff η C6 agent (non-agent entity created)

XW→ Y

η[X]W→ η[Y ]

(nested update)X

W→ Y

X | Z W→ Y | Z(parallel update)

X ′ ≡ X, XW→ Y, Y ≡ Y ′

X ′ W→ Y ′(update≡)

Informally the first rule states that non-agent entities may be created in entity factories (notethat agent entities may only be created if allowed by the security policies, using the rule (agentcreated) described earlier). The other three rules state that transitions may occur anywhere inthe entity nesting hierarchy, in parallel with arbitrary other entities up to structural congruence.Note that the labels on the transitions are preserved but must eventually be cancelled further upthe tree (by the rule (migrate)).

3.3 Other Modelling TechniquesSpatial models have been investigated within several research fields including mobility theory,ubiquitous computing and spatial database theory. Mobility theorists are interested in models ofdistributed computation in order to reason about distributed software in the presence of variablenetwork latency and partial failure. Ubiquitous computing researchers found they needed someform of middleware to bridge the vast semantic gap between (often low-quality) location datareceived from environmental sensors and the (high-quality, high-level) data required by their

59

3.3. Other Modelling Techniques Chapter 3. A Spatial Model

applications. Finally spatial databases have been studied at great length due to their usefulnessin fields as diverse as geography and electrical engineering.

Accordingly related work is divided into three sections: the first deals with recent modelsof distributed computation involving explicit location, the second with ubiquitous computingmiddleware and the third discusses spatial databases. Each section describes the related workand contrasts it to the model presented here.

3.3.1 Theoretical Models

Many mobility models have been proposed in the literature, some of which are described inthis section. We begin with a general overview and then proceeed with detailed descriptions ofparticular models in the following sections.

Theπ-calculus [117] is an early system created to help model distributed, communicatingsystems. Theπ-calculus is aprocesscalculus in which concurrent active processes communi-cate over named synchronous channels. Channel names are treated as first-class data items andcan be transmitted across other channels, providing a simple way to encode mobility. Theπcalculus was the basis for the programming language Pict [129].

Many variants of theπ-calculus have been investigated, including the asynchronousπ-calculus [90] and the distributedπ-calculus [135]. The latter added several new concepts in-cluding migration, site failure, explicitly-located channels and channel names associated withpermissions. The nomadicπ-calculus [163], (on which the language nomadic Pict [173] isbased) separates communication primitives into two types:location-dependentand location-independent. A mapping known as aninfrastructure is used to implement the location-independent primitives in terms of the location-dependent ones.

Amadio et al [12] created a variation of theπ-calculus with located channels and allowedlocation names to be treated as first-class data items and transmitted over channels. The calculuswas used to model the locality and failure behaviour of the distributed programming languageFacile [72].

The Seal calculus [37] is an extension of theπ-calculus with hierarchical locations (knownasseals), mobility and resource access control. Processes can only communicate if they arecollocated in the same seal or are in a parent-child relationship in the seal hierarchy.

The following sections describe a small sample of mobility models and contrasts them tothe approach taken here.

Mobadtl

Semprini et al [61] describe a model called Mobadtl used to design mobile, network-aware ap-plications. They model the world as a flat (not hierarchical) list ofneighbourhoodseach underthe control of aguardian. Mobadtl neighbourhoods are home to agents which can communi-cate with other agents and migrate to other neighbourhoods. All communication and migrationbetween neighbourhoods must be routed through guardians and guardians are not necessarily di-rectly connected to each other by point-to-point links but rather form a directed graph of nodes.Remote communication or migration may then be vetoed by any guardian on the path fromsender to receiver through the guardian network. Guardians are the primary means to imposecommunication and mobility policy on the system. The diagram within Figure 3.4 graphicallydepicts neighbourhoods, agents, guardians and a communication between two agents in differ-ent neighbourhoods.

The Mobadtl system is specified formally using the Mark toolkit [62] written on top of thetheorem proving system Isabelle [126]. It supports designing applications by refinement starting

60


neighbourhood neighbourhood

guardian guardian

networkagent

agent

Figure 3.4: The main components of the Mobadtlmodel. The large circles are neighbourhoods,the small white circles are agents, the small black circles are guardians. The arrow shows acommunication path between a sender agent in one neighbourhood and a receiver in another.

with a specification of generic components (agents and guardians) together with aco-ordinationtheory. The co-ordination theory contains a set of assertions written in the spatio-temporal logic∆DSTL(x) [118] which talk about the possible states of the distributed system without requiringa global clock. A typical formula might be:

m p LT n q ∧ m r (3.1)

which says that a propertyp holding in componentm causes propertiesq andr to hold in futurestates of componentsn andm respectively. Each refinement step aims to reduce the complex-ity of the co-ordination theory by distributing aspects of it across the individual components.The eventual aim is to finish with the co-ordination theory containing only those assumptionsthat can be guaranteed by the underlying network stack and middleware e.g. that messages aredelivered reliably and in the original order.

There are a number of differences between Mobadtl and the model described in this thesis.Firstly the Mobadtl model uses a flat list of environments (called neighbourhoods) whereas themodel described in this chapter uses a tree of nested entities inspired by the Ambient Calculus.Secondly the Mobadtl system is inherently generic whereas the system proposed here is targetedtowards environments which have pervasive location sensing systems (i.e. modernUbiCompenvironments). Thirdly Mobadtl aims to formally develop applications through careful refine-ment steps whereas this thesis proposes the abstraction of security policies (both for mobilityand communication properties) from the source code ofexistingapplications.

The Ambient Calculus

The Ambient Calculus [34] is a calculus for describing the movement of processes and devicesthrough and withinadministrative domainswhere an administrative domain may be consideredthe granularity at which policy is applied. The concept of an administrative domain correspondsto the termcontext horizonused by Shirky [150] to describe the boundary between “local”and “remote” in the world of Web-Services. It is no coincidence that work on Ambients wasinspired initially by observations of the World Wide Web; Cardelli and Gordon claim [36] thatthe primary problem with web-programming is neither mobility nor communication (for both

61


have realisable technological solutions) but rather in specifying and enforcing suitable policy ascomputations leave one domain and enter another.

In the Ambient Calculus an ambient is defined to be aboundedplace where computationhappens. Examples of possible ambients include web-pages, processes, address ranges of mem-ory and computers, bounded by their physical cases and connectors. In the model, ambients maybe nested within other ambients, possess names which can be used for access control (as part ofcapabilities), contain active threads or processes and may be migrated wholesale (i.e. includingcontents) to other locations. A simple example of an ambient could be written

n[in m.P | Q] | m[R] (3.2)

wheren, m are the names of ambients, brackets are used to denote nesting and| denotes parallelcomposition of ambients. The sub-expressionin m.P means “execute an action associated withcapabilityin m and then perform P”; in this case the capabilityin m denotes the capability tocause the enclosing ambient to enter sibling ambientm. Therefore this ambient expression canreduce to

m[n[P | Q] | R] (3.3)

The model proposed in this chapter is heavily inspired by but is a more restricted anddomain-specific version of the Ambient model. Entities, like ambients may be nested. Capabil-ities in the ambient calculus include permission to enter, leave andopenan ambient; enter andleave capabilities are similar to thecanenterandcanleavepredicates in the model presentedhere. The main difference stems from a different underlying philosophy: the ambient calculusis intended to be powerful enough to encode arbitrary computation while the model presentedhere is intended only to represent configurations of the world for the purposes of writing anddynamically checking policy.

Join Calculus

The join-calculus [68] is an asynchronous variant of theπ calculus [117] aiming to be im-plementable in a distributed programming environment. The distributed join-calculus[69] is afurther variation which adds the notions of named locations, migratable agents and partial fail-ure (the presence or absence of which they describe as the “litmus test” for models of distributedcomputation).

The distributed join-calculus models agents as locations and allows locations to be nestedinside other locations forming a tree. Migration is modelled by atomically moving a location(complete with contents) wholesale to another site. The notion of a location in the distributedjoin-calculus therefore has much in common with the notion of an ambient in the ambientcalculus and therefore also with the entities in the model presented here.

As with the ambient calculus, the main difference is one of motivation: the distributed join-calculus is intended to represent the core of a distributed programming language whereas thefocus here is to model configurations of the world for the purposes of writing and dynamicallychecking policy.

3.3.2 UbiComp Middleware

Traditional middleware aims to abstract away low-level details of network communication (e.g.choice of underlying protocol or naming of endpoints) from applications in order to make thetask of writing distributed applications simpler. Yau et al suggest [177] that UbiComp middle-ware aims to exploit usercontextto foster dynamic integration between resource-poor devices

62


and a resource-rich infrastructure in a way transparent to the application and hence make thetask of writing generic ubiquitous computing applications easier. Context is a nebulous concept,reflected in the commonly-used definition from Dey and Abowd [52]:

any information which can be used to characterise the situation of an entity

Dey and Abowd propose four primary types of context: (i) identity (of the interacting entities);(ii) location (in space); (iii) activity (i.e. actions being performed by entities); and (iv) time.Two of these types – identity and time – predate the study of UbiComp and hence are the mostwell understood. Activity inference is hard problem; Hull et al report [92] that even inferringsimple activity information from a mix of low-level sensor readings is difficult to make robust.Perhaps unsurprisingly a lot of effort in the UbiComp community has therefore been focusedon monitoring and processing location i.e. spatial context.

3.3.3 The Location Stack

The Location Stack [85] is a “layered software engineering model for location-aware appli-cations”, similar in spirit to the OSI reference model for networking. The stack aims to takeadvantage of commercially available location systems and integrate research in sensor fusionallowing applications to receive combined sensor input which is more accurate or has greatercoverage than any one sensor system can provide by itself. The system includes standard no-tions of measurement (e.g. distances between objects, frames of reference), standard algorithmsfor positional estimation (e.g. multilateration) and standard query types (e.g. containment andproximity). The system aims to preserve estimates of uncertainty as measurements are pro-cessed and to provide some kind of activity inference.

3.3.4 SPIRIT

The SPIRIT [11] system is a typical example of aspatial indexing systemdeveloped origi-nally at AT&T Laboratories Cambridge. Primitives in the SPIRIT model are spatial containers(three-dimensional volumes of space) represented as polyhedra which may be mobile or fixedstatically to the environment. The world is represented as a quad tree-like structure allowingthe system to efficiently compute dynamic intersections between containers. Users register in-terest in these container intersection events (e.g. partial overlap) and receive notifications whenevents of interest occur. The SPIRIT system receives events mainly from Active Badges [168](personal IR transmitters) and Active-Bats [170] (radio-triggered ultrasound-emitting tags) andevents are emitted by callbacks in the CORBA [123] middleware system.

At a higher-level, the SPIRIT system contains a sophisticated object database which knowsabout many different types of physical object. Desks, chairs, walls, computers, telephones,monitors, windows and doors are all represented in the SPIRIT model. A typical SPIRIT clientis the classic “active map” program which displays a top-down view of an office complete withthe positions and orientations of people and equipment, updated in real time. Figure 3.5 showsan active bat on the left and a screenshot of the “active map” program on the right. Note that themap is showing a zoomed-in view of an office in the Laboratory for Communication engineeringwhere 3 people are present, represented by usernames ofkjm25 , jpw20 andja316 . Desks,computer terminals and telephones are also visible.

Relevance to this work

There are a number of differences between the model exposed by middleware like SPIRIT andthe Location Stack and that proposed in this chapter. The differences arise due a difference

63


Figure 3.5: On the left: an example active bat. On the right: a screenshot of the “active map”program.

in focus; both the SPIRIT model and Location Stack are intended to represent the physicalconfiguration of the world as accurately as possible. In contrast the model presented here isintended to be an abstraction of reality where it is not necessary for the model to only representobjects with physical presence; virtual objects like mobile agents are easily incorporated, alongside physical objects.

Both SPIRIT and the Location Stack are sophisticated systems. In SPIRIT sets of objectsmay partially overlap with each other while the location Stack associates notions of uncertaintywith its measurements. These sophisticated features complicate the process of reasoning aboutthe models. In contrast the model presented here has been kept deliberately simple — support-ing only simple nesting — to aid reasoning and analysis.

Both the Location Stack and SPIRIT model the world at a single level of granularity whereasthe model presented here can represent some parts of the model in high-detail while using morecoarse-grained representations for the rest. Coarse-grained representations have the advantagethat they change at a slower rate than fine-grained representations and hence increase applicationscalability, by allowing a single server to support more clients. In this respect, the modelpresented here is similar in intent to recent work by Katsiri and Mycroft [103] which proposedbuilding a two-layer logical representation where the lower layer contains accurate physicalinformation and the higher layer maintains logical inferences using rules registered by clientapplications. The hope is that the higher level inferences will be more coarse-grained and hencechange less often than the low level data, permitting the system to scale. The system proposedby Katsiri and Mycroft is intended to bridge the semantic gap between low-level sensor readingsand the high-level knowledge required by applications whereas the model presented here isdeliberately intended to be as simple as possible in order to act as a base for reasoning andwriting security policies.

64

Chapter 3. A Spatial Model 3.4. Summary

3.3.5 Spatial Databases

According to Shekhar et al [147] a Spatial Database Management System (SDBMS) aims tomanage effectively and efficiently any data related to space. Such systems have been stud-ied for over 20 years and have found extensive uses in many disciplines including geography(Geographical Information Systems), urban planning, astronomy, biology (mapping living or-ganisms), pharmaceutical research and electrical engineering (e.g. VLSI and CAD).

Spatial databases primarily differ on the kinds of data they store. Some arefield-basedandstore information such as rainfall or temperature as a function of spatial position. Others areobject-basedand divide up spaces into discrete entities with notions of boundaries betweenobjects. The latter database type is evidently the most closely related to the entity-based worldmodel presented here.

Spatial databases support numerous query types; for example the OGIS system [125] addsobject intersection tests, distance calculations, convex hull calculations and calculations of spa-tial unions, intersections and differences to SQL. Like the SPIRIT system described earlier inSection 3.3.4, spatial databases employ sophisticated spatial indexing methods in order to pro-cess queries efficiently. Many datastructures are used for spatial indexing, including BSP-trees,R-Trees and Quad-trees [139] (as used in SPIRIT). Spatial databases are designed to be flexibleand generic, suitable for many types of applications. The model presented here is intended onlyto allow simple reasoning about spatial security policies and does not aim for such wide ap-plication. However by defining a suitable interface, a spatial database fed with accurate sensorinformation could be used as a back-end for the model presented here.

3.4 SummaryThis chapter described a spatial model which provides a unified representation of space, capableof representing both the physical and logical movement of people, things and mobile agents.The model allows users to write new kinds of security policies which combine elements oftraditional security policy (“no entry to unauthorised personnel”) with computer security policy(e.g. “ no access to this resource”). The model itself if policy-agnostic; policies may be plugged-in by defining the predicatescanenterandcanleave. A sophisticatedmobility restriction policyis described in Chapter 4.

As well as providing hooks for implementing security policies, applications may also usethe model to monitor the environment in which they exist. A special type of application knownas asentient mobile applicationwill be described later in Chapter 7 which uses this frameworkto sensetheir environment andreact accordingly. Implementation details for both the spatialmodel and sentient applications are described later in Chapter 7.

65

Chapter 4

Mobility Restriction Policy Language

This chapter builds upon the spatial model described in Chapter 3 to definemobility restric-tion policiesgoverning the permitted movements of mobile agents in an environment equippedwith physical location sensors (of the kind introduced in Section 2.2). Together with Chapter 3this chapter contributes an application-level policy system governing themobility of applica-tions. The following two chapters contribute application-level policy mechanisms governingthe interfacesof applications. Chapter 7 describes the implementation of the system describedhere.

The structure of this chapter is as follows: Section 4.1 outlines why mobility restrictionpolicies are necessary and describes a number of scenarios in which mobility restriction poli-cies would shield applications from attack. Section 4.2 outlines the threat model associatedwith this chapter. Section 4.3 describes how physical location is already used to grant peopleaccess to resources and how this technique can be extended seamlessly to mobile agents. Sec-tion 4.4 describes the language for writing policies consisting of assertions about the state ofthe spatial model and a corrective action executed upon assertion violation. Assertions can beviolated either through thephysical movementof a computational host or themigration of anagent. It is recognised that, in a realistic environment, policies may be written by different peo-ple, with different motivations and for different purposes. Accordingly Section 4.5 describesa metapolicy for resolving conflicts between different users within a typical office scenario.Finally Section 4.7 describes security mechanisms found in other mobile agent systems andcontrasts these with the system proposed here.

4.1 Motivation

The policies described in this chapter are motivated by three key trends and observations.Firstly, as first explained in Section 1.1, improvements in device miniaturisation and cost areleading to the proliferation of tiny, powerful embedded computers which can be found in every-thing from digital watches to fridge freezers.

Secondly, computers are becoming increasinglyphysically mobile. Current users haveportable computers: laptops, PDAs and mobile phones which are mobile only by virtue ofbeingdeliberatelycarried by people. As devices become smaller one can imagine tiny com-puters which areaccidentallycarried by other entities (e.g. “smart dust” [102] – tiny sensorparticles carried by the wind). Fully autonomous mobile computer devices known as robots arealready commonplace today in factories and are likely to become more common as technologyimproves.

Mobile Agents were motivated initially in Section 1.5 as a sensible and economical way tostructure distributed programs and then described in detail in Section 2.1. Mobile Agents are

66

Chapter 4. Mobility Restriction Policy Language 4.2. Threat Model

said to possesslogical mobility. Agents can programmatically move themselves (“migrate”)independently of hosting computers.

Finally, modern ubiquitous computing environments equipped with location sensors (of thekind described in Section 2.2) are capable of hosting new kinds of malicious applications not en-countered before. The following subsections describe two possible new malicious applicationswhich highlight the need for new policy mechanisms.

4.1.1 Sentient Spy

A Sentientapplication is one which can perceive its environment and react accordingly [91].The Sentient Spy application is defined to be one which perceives the current physical locationof a target person and reacts by migrating to a computer nearby. It then activates the micro-phone on the computer, attempting to record any conversations which it then transmits overthe network back to its controller. As the target person moves so the spy application moves tofollow. Note that is it not sufficient to secure the physical workstations near potential targets toprotect against this attack. Another user carrying a PDA could become the unwitting host of thesentient spy application by walking into the same room as the target and allowing it to migrateonto the PDA.

4.1.2 Human Denial of Service

A Denial of Service attack is one which prevents legitimate users from being able to interactwith a particular service. Denial of Service attacks are commonplace on the Internet where itis possible to block access to particular networks or machines by flooding them with unwantedtraffic, drowning out legitimate traffic. A Human Denial of Service attack is created by using anumber of mobile agents which constantly monitor the physical location of a target user. Theagents attempt to migrate to computers near the target user and deliberately allocate resources toprevent1 the user from gaining access to them. For example an agent could use Bluetooth [2] in-terfaces to prevent the user from being able to use local IEEE802.11 networks [93] or could playlots of audio noise at high volume to prevent the user being able to talk to other people. Notethat such an attack relies on the computers within the environment being configured to allowthe free movement of agents. The earlier database searching example described in Section 2.1.2relied on being able to prevent all agents from leaving their current execution environment;this may be considered as a simple mobility restriction policy. In this chapter we expand uponthis idea, allowing the expression of more sophisticated mobility restriction policies suitable forpreventing unwanted agent migrations in an environment permeated with hosts, agents, peopleand location sensors.

4.2 Threat ModelThis section summarises the threat model behind the mobility restriction policies described inthis chapter. The model is based within a single organisation or company. The people within theorganisation are associated with physical resources: specifically offices and computers (laptops,desktops, PDAs) etc. and are associated with computational resources in the form of mobileagents. We make the assumptions that

• the hardware, operating system and support libraries on all the computers are trusted;

1While a Bluetooth interface is scanning for other nodes enough interference is generated to prevent anyIEEE802.11 nodes from successfully receiving any data. Therefore continuous scanning would cause a denialof service.

67

4.3. Location-based Access Control Chapter 4. Mobility Restriction Policy Language

• an organisation-wide location system exists which is accurate and responsive and whichgenerates unforgeable location sighting events;

• all mobile hardware and personnel are tracked by the location system; and

• all mobile code runs in a Virtual Machine or sandbox under the control of the OS andsystem libraries (i.e. the code cannot “break free” from system control).

We do not consider interface communication here, only mobility.The threats addressed happen when:

1. a mobile agent is physically carried into a different room and gains access to the physicalspace without any access control check e.g. such code can then access the “shared audiochannel” in the room by playing music or recording sound;

2. a user physically moves (presumably after passing an access control check by possessing akey for a physical lock) into the same room as a computer on which an agent is running—the agent now has access to the physical space near the user; and

3. a mobile agent explicitly migrates to a new host physically near a particular user.

All three cases are symptoms of the divide between two worlds: the physical world of peopleunder the control of locks and keys; and the ethereal world of agents with their traditional accesscontrol systems. The aim of the mobility restriction policy language is to bridge this divide andprevent threats like those listed above.

4.3 Location-based Access ControlIn normal life humans are already familiar with access to resources being governed by phys-ical location, a form oflocation-based access control. For example many physical securityarrangements work by creating a guarded perimeter which only authorised people may cross.Once through the perimeter (and presumably after satisfying a security check), access to re-sources is granted automatically without subsequent checks. This work allows this principleto be extended seamlessly from the physical world of people to the ethereal world of mobileagents.

In order to exploit this principle, the spatial model of Chapter 3 is extended with two extrafacilities: (i) the notion of sets ofprivilegesassociated with individual entities and inherited byentities nested within; and (ii) the notions of an entity being “jailed” and “released”. Each ofthese will be described in the following two sub-sections.

4.3.1 The privs function

Privileges are defined through a partial function,privs : entity name → privilege set , whichis only defined on names associated withcontext entities and gives the set of privileges whichare granted automatically to anyagentnested inside. Upon movement away from thecontext(either through intentional movement or through eviction) the privileges are revoked.Note that,in contrast to capability-based systems, it is not possible for an agent to delegate access rightsto anyone else. Examples of privileges include “canplaysound” and “canrecordsound” corre-sponding to the ability to play and record audio respectively. Through creating appropriate newcontexts in the spatial model and assigning appropriate privileges we gain the ability to controlaccess to arbitrary resources. Note that we consider all agents to have permission to execute atall times; even the most deprived agent can therefore use this ability to request to migrate to acontextwhich is associated with more access.

68

Chapter 4. Mobility Restriction Policy Language 4.4. Mobility Restriction Policies

context

PC

music_player

sound context default

privs = sound

default

{ can_play_sound }

{ }{

a

Figure 4.1: Diagram showing a PC with twocontextentities, one conferring the canplaysoundprivilege on a music playing agent nested inside.

4.3.2 Jailing and Releasing

The act of jailing an agent is considered as a migration into a special context calledjail andreleasing is a migration out again. The specialjail contexts are created dynamically whenneeded and associated with no privileges i.e.privs(jail) = {}. Note that although agents injail contexts lose all their privileges (by virtue of leaving the context where the privileges weregranted) they are still able to execute and in particular may request to be released again. Theacts of jailing and releasing are represented by the following two extra spatial model updaterules in addition to those defined in Section 3.2 and a single extra structural congruence rule:

e[d[Y ] | X] → e[jail [d[Y ]] | X] iff d canleavee (jailed)e[jail [d[Y ]] | X] → e[d[Y ] | X] iff d canentere (released)

e[jail [X] | jail [Y ]] ≡ e[jail [X | Y ]]

Note that, to be jailed, an agent must be allowed by the security policies to leave its currentcontext. There is no guarantee the agent will ever be released again; release may only occur ifthe agent has permission to reenter the original context. The extra structural congruence ruleasserts that multiple entities with namejail in the same place may be freely combined into asingle suchjail entity.

4.3.3 Example: Sound Playing

The diagram in Figure 4.1 depicts a fragment of a spatial model configuration. There is a PCentity containing two sub-entities, one of which is associated with the privilege canplaysoundvia theprivs function. Note that if the agent were to migrate to the other context, it wouldlose this privilege. Later we will see how it can be forced to migrate by the application ofmobility restriction policy. The diagram in Figure 4.2 shows the same agent being jailed andthen released again.

4.4 Mobility Restriction PoliciesA mobility restriction policy is defined as a 4-tuple

〈location, formula, times , onfail〉

69

4.4. Mobility Restriction Policies Chapter 4. Mobility Restriction Policy Language

context

PC

music_player

sound context default context

PC

music_player

sound context default

contextjail

jailing

releasing

privs =

sound

jail

default

{ can_play_sound }

{ }

{ }{

a

a

Figure 4.2: Diagram showing the agent from the example in Figure 4.1 may be jailed andreleased.

where location is a path expression (see Section 3.1.3) designating a set of specific entitieswhere the assertion given byformula should hold. If, with respect to the time period describedby times, the assertion becomes violated (e.g. by the physical movement of an object) then thesystem will attempt to execute the command described in the fieldonfail .

It is worth noting that policy is intended to be used in one of two ways: either (i) an agentwhich is attempting to migrate to another host has its movement prevented; or (ii) a physicalmovement (such as a person carrying a laptop from one room into another) results in the viola-tion of a policy which is “patched up” by the execution of theonfail action. Theonfail actionmay be thought of as a last-ditch attempt to fix an unpreventable and undesirable situation.2

Later in Section 4.5 it is described how policies may be written (probably by different users)which conflict with each other in certain situations. Some mechanism is required which resolvesthese conflicts and decides which policies should be enforced at the expense of which other poli-cies. Of course this implies that not all policies can actually be enforced in practice. Althoughoutside the scope of this thesis, an automatic tool could be created to analyse policies and checkfor nonsensical policies and also potential conflicts before they happen. For example, it is possi-ble to write policies which make untrue assertions about the physical world (e.g. a policy couldinsist that a certain office does not exist when it actually does). Knowing a little about how theworld model behaves (e.g. that rooms never move) a tool would be able to detect some nonsen-sical policies up-front. A tool could also search through possible configurations of the world forsituations which cause policies to be in conflict (just as a model checker enumerates the statespace of a model searching for assertion violation). Potential problems could be flagged up andusers could then revise their policies accordingly.

The policy fieldtimes can contain one of two possible types of values:Always(∆t) andSometime(from, to, ∆t) (wherefrom,to and∆t are all in seconds and∆t > 0). In both casesthe parameter∆t specifies how much “reaction” time the system has before the policyonfailaction is executed. The valueAlways(∆t) indicates that the assertionformula should hold forall time during which the system is running. The valueSometime(from, to, ∆t) states that

2One may imagine a system in which physical movements too may be prevented through automatic control ofdoor locks. However consider that, due to Health and Safety regulations, in the event of a fire (alarm) the doorcontrols would have to be disabled, enabling policy violations.

70

Chapter 4. Mobility Restriction Policy Language 4.4. Mobility Restriction Policies

formula should hold3 at some point in the time interval between the timesfrom andto. Notethat we do not rely on having global time synchronisation and allow individual agents to operateon their own local clocks. Therefore agents (particularly those conserving battery power) needto be given some time (represented by the∆t) to respond to policy violations.

To understand the necessity of having the “reaction” time,∆t, first consider a hypotheticalscenario in which an agent is running on a battery-powered PDA with intermittent wirelessnetwork access (perhaps the PDA deliberately runs the network in a low-power mode or theradio coverage is relatively poor). Imagine that a policy exists which insists that for all time(i.e. theonfail field is set toAlways(∆t) for some∆t > 0) the agent currently running on thePDA is not within a particular room. Furthermore consider that the database of installed policiesis running on a mains-powered high-performance server elsewhere in the building andnot onthe PDA. Imagine that a user carries the PDA into the room in which the agent is forbidden. Itis possible that the new location of the PDA will be sensed by the environment during a periodwhen the PDA’s network interface is inactive. Therefore the policy will be violated without thesoftware on the PDA realising. Assuming that the agent running on the PDA wishes to complywith the policy in the first place, then it is polite to grant it a (hopefully short) grace period inwhich to comply before theonfail action is activated. This grace period is represented by the∆t.

The policy fieldonfail specifies an action to take should the policy be violated. The actioncan be of the following types:

• Log(message) causes a message to be written to a log;

• Kill(pathexpr) asks the system to terminate agents identified by the path expressionpathexpr ;

• Jail(pathexpr) requests agents named bypathexpr be jailed; and

• Create(path) requests the agent factory named bypath create an agent.

For both theKill andJail values we adopt the convention that if the path expression has amissing initial element (i.e. it starts with/ • • • / ) we automatically prepend the full path tothe specific entity the formula is currently being applied to. For example if the policylocationfield is a/* and the policy is violated at〈a, b〉 then theonfail expressionKill / c is expandedto Kill a/ b/ c i.e. a request to terminateonly the entity named by〈a, b, c〉 and not any otherelement (e.g.〈a, d, c〉). This ability to refer to previously matched data in a pattern is also foundin other systems using regular expressions, e.g. Perl [167].

The policy field formula contains an expression written in a simple spatial modal logicsimilar to the Ambient Logic [35]. The core syntax is as follows, whereη ranges over entity

3This is similar to the concept ofobligation in traditional Role-Based Access Control (RBAC) systems i.e. itstates that someoneshouldperform some action during some time interval.

71

4.4. Mobility Restriction Policies Chapter 4. Mobility Restriction Policy Language

names:formula ← T (true)

| ¬formula (negation)| formula ∨ formula (disjunction)| 0 (void)| η[formula] (named entity)| !η (named agent factory)| formula | formula (composition)| ♦formula (somewhere modality)

For convenience the following additional syntax is defined in terms of the core:

F ≡ ¬T (false)a ∧ b ≡ ¬(¬a ∨ ¬b) (conjunction)

�a ≡ ¬♦¬a (everywhere modality)

These constructs may be familiar to those versed in modal logics, but their meaning issummarised in the following section.

4.4.1 Satisfaction

We say that an entityE satisfies the logical formulaf (i.e. the formulaf holds atE) by writingE |= f . Intuitively, we may think of a formulaf asmatchingan entityE if e |= f . The relation,|= is defined informally as follows:

• E |= T for any entitye

• E |= ¬f if E |= f does not hold

• E |= f ∨ g if eitherE |= f or E |= g

• E |= 0 if E ≡ 0 i.e. e is “nothing”

• E |=!η if E ≡!η

• E |= η[f ] if E ≡ n[M ] andη = n andM |= f

• E |= f | g if E ≡ N |M , N |= f andM |= g

• E |= ♦f if ∃e′.e ↓∗ e′, E ′ ≡ e′[Y ] andE ′ |= f

So the formulaT matches any entity (which may itself be a parallel composition of entities)and the formula0 only matches “nothing” (or “void”) i.e. the absence of anything. The formulaf | g matchesE if e can be written as the composition of two expressionsN andM (rememberthe equivalence relation≡) such thatf matchesN andg matchesM . The formula♦f matchesE if there is an entityE ′ somewhere in the tree rooted atE whereE ′ matchesf .

72

Chapter 4. Mobility Restriction Policy Language 4.5. Policy Conflict

4.5 Policy ConflictIf we allow individual users to write their own security policies then we must also provide amechanism to resolve policy conflicts when they arise. Conflicts between rules in our systemare similar to those found in Active Databases [45]. Many mechanisms have been proposed,ranging from simple numeric priority schemes to more complex algorithms comparing rulesbased on their generality [96] (e.g. the more general rule holds except when the less generaldoes not or the other way round). There is no single best strategy that works perfectly in allcircumstances. Therefore the scheme presented here is not claimed to be perfect, but ratheras an example of the kind of scheme possible in a system like this. Some implications (notall of which are desirable) of the scheme presented here are outlined in the examples in thefollowing section. Our main goal is to make the system be intuitive enough for ordinary usersto understand. Security policies in our system are based on a spatial modal logic therefore wealso use a spatial mechanism for arbitrating between conflicting policies.

Recall that we model the state of the world as a nested tree of entities (see Section 3.1). Weobserve that within a real life enterprise people too are often arranged into a hierarchy, with theboss at the top, managers in the middle and normal employees at the leaf nodes. In such anorganisation, a manager would be able to set a policy which would override those of subordi-nates but which could itself be overridden by the boss. These two hierarchies, one describingthe world and one describing the people, can be linked together by associating entities with aset of people (“owners” or “administrators”) via a function

owners : entity name → person set

such that for an entity nameη we haveowners(η) = {person1, . . . , personk} whereperson1...k

are the direct “owners” ofη. In a typical configuration, the boss would “own” the root en-tity while normal employees would “own” their individual offices. Our scheme for arbitratingbetween conflicting policies may be informally described as:

For a proposed change to entity nameη, policies instituted by a useru′′ ∈owners(η′′) override those policies instituted by a useru′ ∈ owners(η′) whereη′′ ↓∗ η′ andη′ ↓∗ η as long asη′′ 6= η′ andu′′ 6= u′.

Recall from Section 3.2 that the installed security policies may be represented by a pair ofpredicates,canleaveandcanenterwhich, given an agent and a context hold precisely when anagent is allowed to leave or enter the context respectively. Both of these predicates are computedin the following way: For a proposed change in the configuration at context namedc (e.g. anentity wishes to leavec) we first compute the set of users who “own” any of the entity nameson the path〈η1, . . . , ηn〉 from the “root” entity nameη1 which designatesc

users =n⋃

k=1

owners(〈η1, . . . , ηk〉)

Each useru ∈ users is allocated a single vote on the proposed change. Note that this effectivelymeans that although users may write policies about entity names they do not “own” these poli-cies will be easily overridden by other users whodo “own” these entity names. A useru votesfor the proposed change if the number of their policies which are in violation decreases or thenumber remains the same but the agent requesting the migration is owned by them, votes against

73

4.6. Example Chapter 4. Mobility Restriction Policy Language

context

context context context

World

Bob'sOffice

Charlie'sOffice

AlicelaptopPCCharlie

laptop

music player

context

Laptop

Context

Agent

Room

Person

Workstation

secret agent

audio default

! Entity Factory

!music player

factory

default

default

agent

a

a a a

a

a

Figure 4.3: An example world configuration in graphical form.

if the number in violation increases and abstains otherwise. We define a functionvote(user) asfollows:

vote(user) =

−1 if user votes against the proposal0 if user abstains+1 if user votes for the proposal

We then compute the value of

overall vote =n∑

i=1

∑o∈owners(〈η1,...,ηi〉)

prio(i)vote(o)

where〈η1, . . . , ηi〉 refers to theith entity name on the pathp = 〈η1, . . . , ηn〉 and the functionprio(i) gives the priority of owners of this entity name. One possible priority function is givenby prio(i) = x−i wherex is a tunable vote weighting factor. The parameterx determines howmany people who “own” an entity nameηn are needed in order to equal the vote of a singleperson who “owns” a “more important” entity nameηn−1. If x > max i (|owners(ηi)|) thenit is impossible for the owner of a more important entity name to be overridden by a group ofpeople who own a less important entity name. The system will allow the proposed change ifoverall vote ≥ 0 and veto it otherwise.

4.6 ExampleIn this section we demonstrate the kinds of policies which are expressible in our system bymeans of a series of examples set in a typical shared workplace environment. A snapshot ofthe world configuration is presented in Figure 4.3. The top-level entity is namedWorld andcontains child entitiesBob’s office andCharlie’s office representing the officesof users named Bob and Charlie respectively. We assume that ordinary employees by default

74

Chapter 4. Mobility Restriction Policy Language 4.6. Example

“own” the entities corresponding to their offices and for the sake of an interesting example wefurther assume that Bob is the boss and also “owns” the top-level entity,World .

A user, called Alice, deploys a “follow-me” music playing mobile agent which follows heraround, playing music where she goes. She is worried about the agent failing to follow her whenshe moves between rooms and so writes the following policy to cause the system to monitor theagent:

〈 location = World ,formula = ♦(Alice[T] | ♦music player [T] | T),times = Always(10 seconds),onfail = Log 〉

(4.1)

“for all time, I am in theWorld and an agent calledmusic player should bein the same space as me. If this is not true for more than 10 seconds, log the error”

The generous 10 second reaction time affords the agent an opportunity to notice Alice hasmoved (by receiving an event from a networked location server), stop playing music, recordhow much of the current track it has already played, find a new machine to migrate to and tomigrate itself to its new home. If the reaction time period is shortened then the probabilityincreases that a log entry is created even when the agent is working properly but fails to reactin time. Note that the agent may fail to react for many reasons, including: the task scheduler onthe hosting device may neglect to give the agent any CPU time; the network may temporarilyfail, delaying the arrival of the location sighting event; or perhaps Alice moves into a room inwhich the agent simply cannot find a suitable host to run on.

Remember thatE |= f | g holds wheneverf andg match the two children ofE and thatTmatches anything, including0, the absence of anything. In the formula above the thirdT meansthat the formula will hold irrespective of whatever else is in the same space as Alice.

The consequences of this policy are summarised as follows:

1. When themusic player attempts to migrate, the system prevents the agent fromleav-ing the same room as the user. Recall from the beginning of Section 4.4 that the system isassumed to be able to block agent migration requests which are judged to violate policies..Note it does not directly force the agent to move properly (these are mobilityrestrictionpolicies), it just stops it from moving inappropriately.

2. Upon observing Alice move to a new room the system generates a new entry in the sys-tem log if it has not followed her within 10 seconds. The log entry may help Alice indebugging her errant agent.

3. If the agent is running on a portable device which is picked up by someone else andmoved to another room (recall that physical movements cannot be blocked unlike agentmigration requests and therefore must be “patched up” afterwards using theonfail action)then a new entry will be generated in the system log if the agent has not migrated to amachine in the same room as Alice within 10 seconds.

4. If Alice moves to a room which already has amusic player agent the system will notcomplain even if Alice’s agent fails to follow her. Recall the earlier discussion about nam-ing in Section 3.1.2; therefore it is important that only one agent calledmusic playerexists at a time.

75

4.6. Example Chapter 4. Mobility Restriction Policy Language

Consider a second user, Bob, who is Alice and Charlie’s boss. Bob prefers peace and quietwhere he works. To prevent wandering music playing agents disturbing him he writes a rule:

〈 location = World/* ,formula = �¬Bob[T] ∨ (♦Bob[T] ∧�¬audio [¬0]) ,times = Always(3 seconds),onfail = Jail / • • • /audio/* 〉

(4.2)

“if ever I’m in an office with a music playing agent, jail the agent if it has not leftwithin 3 seconds”

The policy location field World/* causes the rule to be applied to all children of theentity namedWorld , i.e. in the diagram in Section 3.2 this corresponds to all the offices,〈World , Bob’s office 〉 and〈World , Charlie’s office 〉. The same formula is ap-plied individually to each of these entities. The formula�¬Bob[T] holds if the entityBob isnowhere inside the office; the formula♦Bob[T] holds if the entityBob is somewhereinsidethe office and the formula�¬audio [¬0] holds if there is not a non-emptyaudio contextanywhere within the office. Taken together, the wholeformula may be read as

Either Bob is not inside the office concerned (in which case there is no violation)or he is inside the office but there is no sound playing.

If the policy is violated in the office namedx then the onfail action is expanded toJail World/ x / • • • /audio/* causing audio playing agents inside officex to be jailed.

The consequences of this policy are summarised as follows:

1. If a music player agent attempts to migrate inside the same office as Bob the requestwill be denied, assuming that his policy is not overridden by anyone more senior in thecompany.

2. If a music player agent running on a laptop or PDA is physically moved inside hisoffice by someone else, that agent will be jailed.

Now consider what will happen when Alice enters Bob’s office. Clearly the two policies 4.1and 4.2 now conflict. Alice’s mobile agent will attempt to migrate inside Bob’s office so thesystem will apply the conflict resolution rules described in Section 4.5. Assuming the systemknows that Bob “owns” the entity namedWorld (since he is the boss) his policy will overridethose belonging to Alice and the migration request will be blocked.

Imagine a third user, Charlie, with more malicious intent. This user attempts to lure haplessagents into his domain and then trap them there forever. He decides to target Alice’s musicplaying agent and writes the following:

〈 location = World/Charlie’s office ,formula = ♦(music player [T]),times = Always(3 seconds),onfail = Log 〉

(4.3)

“for all time themusic player agent should remain inside my office.”

76

Chapter 4. Mobility Restriction Policy Language 4.7. Related Work

Consider what happens when Alice is enticed into Charlie’s office for a coffee and biscuit. Ini-tially Alice’s music player ’s request to migrate into Charlie’s office is accepted since itdoes not violate any policy (in fact it causes rule 4.3 to no longer be in violation – an improve-ment!) When Alice leaves the office the music player attempts to follow her. Charlie’s andAlice’s rules are now in direct conflict; Alice’s rule is violated if the agent stays and Charlie’srule is violated if the agent goes. Note that both rules have an entirely passiveonfail action.Unfortunately for Alice since Charlie “owns” his office his policies take priority and thereforethe agent’s request to leave is denied. What can Alice do? The only solution for Alice inthis situation is to appeal to a higher authority – in this case Bob – someone whose policies areranked higher than Charlie’s. Bob may write a policy to evict Alice’s agent, overriding Charlie’swishes.

4.7 Related Work

Many people have developed mobile-agent frameworks which included support for somekind of mobility security policies. Dag Johansen, one of the developers of the influentialTACOMA [101] system recently wrote in a 10-year retrospective [99] that

more than 100 mobile agent systems have been built, where the majority, to bemodest, hardly provides any incremental contribution to the community as a whole.

Many of the systems Johansen referred to were developed independently, by different teamsand using different languages and tools. However they all implemented more-or-less the samefunctionality. Johansen claims that the lack of a satisfactory solution to mobile-agent securityproblems together with a general lack of akiller-appand not the lack of support for a particularlanguage or system prevented the large-scale deployment of mobile agent systems.

Rather than describe 100 near-identical mobile agent systems it suffices to mention only afew classified into the following groups: (i) traditional mobile-agent systems as described byJohansen; (ii) proposals for distributed programming languages; and (iii) middleware systemssupporting object migration. Each of these groups shall now be described and their support forsecurity policies contrasted with the mobility restriction policies presented here.

4.7.1 Traditional Mobile-Agent Systems

Traditional mobile-agent systems is the name used here for those systems which aim to creategeneric mobile-agent middleware for writing agents in existing languages. They have manyfeatures in common. They focus mainly on mechanism: how to transmit agents between sites(running on different platforms); how to protect sites from aberrant agents; and how to specifysecurity policies to guard accesses to local resources. These systems are differentiated throughmany subtle features. One such feature is the type of mobility offered [87] (first mentioned inSection 2.1). Some systems are said to offerfull mobility: the migration of all state includingthat within the kernel. Another variation isstrong mobilityin which a system is able to introspectand migrate running code. The remaining systems offerweak mobility, insisting that agentsperform manual shutdown and restart. Even these distinctions are not very discriminating;Bettini et al describe how strong mobility may be implemented on top of weak mobility with asyntactic translation [23].

Two example systems shall be described, one academic system (TACOMA) and one indus-trial system (Aglets).

77

4.7. Related Work Chapter 4. Mobility Restriction Policy Language

TACOMA

The TACOMA [101] (Tromsø And COrnell Moving Agents) project had several major revisionsover a 10 year period, the features of each version are summarised in a summary paper [100].The most recent version allowed agents to be written in a variety of programming languages andsupported communication over TCP. TACOMA provided weak mobility; agents were chargedwith handling their own serialisation rather than relying on runtime support for freezing runningcode (which would prevent agents being written in many languages e.g. Java). Agent statewas handled through “briefcases” which could be left permanently on one site or transmittedbetween sites. Briefcases contained nested “folders” containing application data.

Special “firewall agents” are used to enforce application-specific security policy on arrivingagents. Depending on the security policy in force, arriving agents might find themselves exe-cuting in a private location (like a sandbox) where they cannot communicate with other agents(in TACOMA agents must be in the same location in order to communicate). In the system de-scribed here, a sandbox would correspond to a location with restricted privileges (via theprivsfunction) and a mobility policy which prevented any agents contained inside from migrating outof the sandbox.

Several aspects of TACOMA are shared with this work. The TACOMA project imaginedmobile agents running on PDAs [97] and mobile phones [98], equivalent to the portablelaptopentities used in the USM described here. The hierarchical data stored in TACOMA briefcasesand transported between sites could be represented by creating a new sort of entity (“data”) andallowing agents to have these entities nested inside. The TACOMA framework differed fromthe system described here in three significant ways. Firstly, TACOMA considered only mobileagents and agent servers; it had no access to physical sensor information and therefore made noattempt to support a unified representation of both physical objects and mobile agents like thatdescribed in Chapter 3. Secondly, TACOMA did not directly associate locations with accessto specific resources instead preferring to restrict access to resources depending on whether amobile agent has been signed. TACOMA has no equivalent to theprivs function described inSection 4.3. Thirdly, TACOMA firewall agents would impose mobility policy by preventingcertain agents from migrating to specific locations. The mobility restriction policies describedin Section 4.4 also copes with unrestrictedphysicalmovement by triggering a corrective actionaftera policy has been violated.

Aglets

Aglets [106] (a portmanteau word derived from “agent” and “applet”) is a Java-based APIfor building mobile agents released by IBM. The Aglet system has much in common withTACOMA with the major difference that it is based entirely upon Java. Security policies in theAglet system are based upon the Java-2 security model [74] in which code is selectively trustedor not depending on its origin and/or the presence of recognised signatures. This signature-based scheme is totally different to that proposed here; it does not associate virtual locationswith privileges nor does it attempt to handle physical movement as well as agent migration,a feature essential to cope with the expected hordes of networked mobile devices outlined inChapter 1.

4.7.2 Distributed Programming Languages

The termdistributed programming languageis used here for projects which aim to create al-together new languages suitable for developing distributed (often agent-based) systems. The

78

Chapter 4. Mobility Restriction Policy Language 4.7. Related Work

following sections describe three such systems and describes both how they approach securityand how the approaches taken differ from the system proposed here.

Telescript

The Telescript system [157] is an object-oriented programming language designed to supporta remote programming model offeringstrong mobility. Security in the system is addressed bythe use of safe language features such as the lack of pointers, types , automatic memory man-agement, built-in authentication mechanisms and a system of capabilities known as “permits”.Telescript has the concept of “regions” each of which can have their own security policy just ascontext entities here are associated with sets of privilege. Both Telescript and the system de-scribed here allow policy to be written to prevent agents migrating to particular places. Howeverunlike the system presented here, telescript does not directly support policies written in termsof spaces and does not support physical regions – all regions in telescript are entirely virtual.

Obliq

Obliq [32] is a dynamically-typed language built on top of Modula-3 Network Objects at DECSRC. It aimed to exploit the existing Modula-3 middleware facilities including remote objectnaming, invocation and garbage collection. Obliq introduced distributed lexical scoping: it al-lows procedures to be sent to remote sites complete with free variables which remain bound totheir original definition sites. Issues involving security were delegated to the underlying net-work objects middleware. The middleware supports security through (i) callee authentication;(ii) access control lists for individual objects; and (iii) non-forgeability of references to securenetwork objects. This very traditional approach to security is completely different from andorthogonal to that proposed here. Chapter 1 argued that the environment will be filled withphysically and logically mobile programs necessitating mechanisms to limit the mobility ofsoftware, hence the mobility restriction policy presented in this chapter. Agents will still needto be able to authenticate each other and control access to their internal state and so a systemlike that used by Obliq and secure network objects may run in parallel with the system proposedhere.

JoCAML

Conchon et al produced a mobile-agent system for Objective-Caml based on the Join Calcu-lus [43] (the Join Calculus was described earlier in Section 3.3.1). Furthermore, on top of Jo-CAML Fournet created a proof-of-concept implementation [70] of the Ambient Calculus. TheAmbient Calculus was described in detail in the previous chapter in Section 3.3.1. JoCAMLand the Ambient Calculus encoding are powerful tools for creating distributed systems.

Facile

Facile [72] is a high-level, higher-order programming language based on Standard ML [116]with the addition of a model of concurrent processes based on Milner’s CCS [115]. Facile hasthe concept of a node – effectively a virtual processor – on which processes may execute. Indi-vidual processes communicate and synchronise using typed channels; any value may be trans-mitted, including user-defined types, channel names and functions. In addition to possessing arobust implementation, Facile (the first release of which was known as “Facile Antigua” [160])has been studied extensively from a theoretical standpoint. As a programming language, Faciledoes not include built-in support for security policies; however it could be used to create animplementation of a system like that presented here.

79

4.7. Related Work Chapter 4. Mobility Restriction Policy Language

Distributed π

First mentioned in Section 3.3.1, the Distributedπ calculus (Dπ) incorporates notions of remoteexecution, migration and site failure into theπ calculus. Channels in Dπ are explicitly located;using a channel requires knowledge of both the name of the channel and name of the location.All names (for both channels and locations) have permissions detailing what can be done withthe name. Defined permissions include:

snd : to send data along a channel

rcv : to receive data from a channel

run : to run a thread at a location

newc : to create new channels at a location

subl : to place sublocations at a location

mig : to move a location complete with all threads and sublocations

halt : to kill a location, stopping all threads from running

When names are communicated, certain permissions are communicated too. A type systemis employed to ensure that well-typed terms only use received names in a manner consistentwith the permissions received along with the name. Dπ and the system proposed here haveone obvious feature in common: both systems represent locations as trees. However unlikeDπ in which all locations are under the control of the programmer, in the system presentedhere some locations correspond with mobile physical objects and are simply observed, notcontrolled. A major difference between the two systems is that Dπ programs are type-checkedat compile-time whereas MRPL policies are enforced dynamically at run-time against agentswhose program code may not be available to the system for any up-front analysis.

KLAIM

KLAIM (A Kernel Language for Agents, Interaction and Mobility) [49] is a mobile-agent for-malism based upon Linda. KLAIM supports multiplelocatedtuple spaces and operators forbuilding processes. A KLAIM program (also called anet) consists of a collection ofnodes;each of which has a process component and a tuple space component. In KLAIM terminology,the concrete name of a node is asiteand alocality is the symbolic name of a node. Localities areconsidered first-class data and can be dynamically created and communicated over the network.Programs may be written using the X-KLAIM [24] tools and compiled into Java for execution.Programs are written in terms of localities and are independent of the actual physical distribu-tion of nodes. The net primitives address distribution and co-ordination issues, including thevisibility of localities and the mappings of localities onto sites.

KLAIM uses a simple type system to statically enforce security properties [122]. Type-checking is a two phase process; the first phase deduces process intentions (e.g. read, write,intention to migrate etc.) with respect to the various localities they may interact with; thesecond phase checks whether each process actually has the necessary rights (granted by theadministrator) to perform the intended operations.

KLAIM has some similarities to the system proposed here. Both KLAIM and the MRPLattempt to control access to localised resources and to prevent some process migrations (in

80

Chapter 4. Mobility Restriction Policy Language 4.8. Summary

KLAIM a migration would be blocked if the process had insufficient access to the intendedmigration target whereas here migrations would be blocked if found to violate MRPL policies).However KLAIM and the system proposed here have a number of philosophical differences.The KLAIM system analyses a fixed network of sites up-front in a compile-time type-checkingphase whereas we take a more dynamic approach, enforcing policies at run-time. Rather thanonly consider networks of sites, MRPL policies are written also in terms of physical spaces andcan react to the physical movements of people and computers.

4.7.3 Middleware-based Approaches

This section provides an example of a piece of middleware which supportsobjectmigration.Object migration systems allow the state of an object to be moved from one host to anotherand typically have some request redirect mechanism whereby requests sent to the old objectlocation get transparently rerouted to the new location. From the point of view of other objectsinteracting with the migrating object, nothing has happened save a slight pause as the objectmoved. Object migration systems can be used to implement mobile agents systems supportingweak mobility; i.e. those which require agents to assist in their own shutdown and restart post-move.

LocALE

The LocALE [47] (Location-Aware Lifecycle Environment) framework provides aCORBA [123]-based mechanism to control the life-cycle (i.e. creation and destruction) andlocation of software objects residing on a network. LocALE defines the notion of aLocationDomain– a group of machines physically located in the same place. This aspect of the LocALEsystem could be represented easily in the spatial model presented in Chapter 3; a Location Do-main would correspond to a set ofworkstation entities with a common parent entity.

The LocALE project addressed two primary concerns: (i) providing the underlying(CORBA-based) mechanism for causing objects to move seamlessly from one object serverto another; and (ii) using a vision-based environmental sensing system (called TRIP [48]) totrigger objects to change location. The LocALE system made the simplifying assumption thateverything operates within the same trust domain and hence no specific support for securitywas required. The system could use whatever CORBA security systems are available on thehosts (such as transport-level encryption via SSL) in much the same way as Obliq could usethe underlying feature-set of the secure network object system. This thesis makes the differentassumption (outlined in Chapter 1) that many mobile programs will not be trusted – or equiva-lently contain errors which cause them to act in an untrustworthy fashion – and hence we requiremechanisms like the mobility restriction policies described in this chapter to remain in control.

4.8 SummaryThis chapter used the spatial model introduced in Chapter 3 as the basis for creatingmobilityrestriction policieswhich allow the movements of mobile agents to be controlled in an environ-ment augmented with physical location sensors. The spatial model was extended to associateentities with access to resources (via the functionprivs defined in Section 4.3) allowing thesame policies to be used to govern both movement and resource access. Policies are intended tobe written by individual users with potentially conflicting goals. A metapolicy system to resolvepolicy conflicts was presented in Section 4.5 and was demonstrated by means of a hypotheticalexample in Section 4.6.

This thesis argues that application-level security policies governing the mobility and inter-

81

4.8. Summary Chapter 4. Mobility Restriction Policy Language

face behaviour of applications are an effective technique to prevent vulnerabilities which wouldotherwise plague future ubiquitous computing systems. Potential threats enabled by physicaland logical mobility were outlined in Section 4.1 and the mobility restriction policy languagewas argued by means of a series of examples to be an effective mechanism to prevent this classof attacks. A prototype implementation of the system described here has been created and de-scribed in Chapter 7. This chapter concludes the study of the mobility aspect; the following twochapters focus on theinterface behaviourof applications.

82

Chapter 5

Security Policy Description Language v 2

This thesis introduces new application-level security policy systems to govern both themobilityand interfacesof applications. Chapter 3 and Chapter 4 discussed the mobility aspect; thischapter and Chapter 6 focus on the interface aspect.

Many contemporary web-applications possess application-level security vulnerabilities. Ac-cording to a ZD-NET survey [113] 30-40 percent of all e-commerce sites and according toInternet Security Systems (ISS) [95] 11 widely-deployed shopping carts are vulnerable to sim-ple application-level attacks. These vulnerabilities may be classified into a small number ofcategories, including client-side modification, SQL attacks, Cross-Site Scripting (XSS) andForceful Browsing attacks. Each type of vulnerability stems from an undocumented interfaceassumption; an assumption that a malicious user can violate often to great effect and which thisthesis addresses in a systematic manner.

Unfortunately, although each vulnerability is simple in nature it is nevertheless difficult to fixall the errors scattered across a large codebase. A realistic application is likely to be constructedof multiple components, each written by different people in different languages. Additionaldifficulties arise when components have been bought and are only available in binary form,preventing any analysis of the sourcecode.

This chapter introduces a language called SPDL-2 which allows security policy to be createdto protect an entire web-application interface. SPDL-2 allows the specification of per-requestand response validation and transformation rules which can protect applications from all of thevulnerabilities listed above with the exception of Forceful Browsing, the subject of the follow-ing chapter. SPDL-2 policies are kept separate from the main application codebase and can beenforced against applications even without access to the original sourcecode and irrespective ofprogramming language(s) used. Using SPDL-2 application integrators and installers can proac-tively fix bugs in third-party components without waiting for the original vendors to produce afix1.

The structure of this Chapter is as follows: Section 5.1 describes the threat model usedby Chapters 5 and 6. Section 5.2 describes the common security vulnerabilities addressedby SPDL-2: namely Client-side Modification, SQL Attacks and XSS. It is argued that thesevulnerabilities are evidence of the existence offorgotten assumptionswithin the apparentlysimple interfaces exposed by these applications. Using the interface framework described inSection 2.3 the general-form of interface modification required to fix these problems is de-scribed in Section 5.3. The language SPDL-2 is introduced in Section 5.4 and the capabilities

1Vendors have to produce fixes that work on all installations without needlessly breaking functionality. It isoften easier to fix the bug locally because (i) some functionality may be unused and breaking it does not matter;and (ii) the application with the fix can be tested readily.

83

5.1. Threat Model Chapter 5. Security Policy Description Language v 2

Internet

Application-levelFirewall

Application Server

Network-levelFirewall

Third-partyComponent

CustomComponent

UntrustedClients

Policy Policy

ComponentVendors

Application Integrators System Administrators Network Operators Users

Figure 5.1: Block diagram showing the structure of a hypothetical system highlighting the usersresponsible for each component. Arrows indicate interface communication.

are demonstrated through a case study in Section 5.5. Section 5.6 finishes with a discussion ofalternative security mechanisms.

5.1 Threat ModelThis section summarises the threat model behind the interface security policies described hereand in the following chapter. We begin by classifying and describing the people involved in theproduction, maintenance and use of an e-commerce system on the Internet:

component vendorswho sell black-box components (e.g. an e-commerce shopping cart);

application integrators who create sites by connecting components together with custom ap-plication logic;

system administrators who configure and run machines in a corporate environment;

network operators who run the public network; and

users who access the application over HTTP.

We assume that the application integrators and system administrators work for the samecompany—the company who wish to run the application—and are therefore fully trusted. Thecomponent vendors are assumed to be semi-trusted third-parties who—although they cannotguarantee to write perfectly secure software—nevertheless do not deliberately introduce trojansinto their products. The network operators and users are completely untrusted and it is assumedthat they are prepared to act maliciously to gain any advantage by exploiting vulnerabilities inthe application. The diagram in Figure 5.1 shows the structure of the system and highlightswhich group of users is responsible for each part. Note that we do not consider mobility inthis description; we only consider interface behaviour. Note further that in the diagram, re-sponsibility for the application-level policies has been split between the application integratorsand the system integrators to reflect the fact that the policies are of interest to both groups: thesystem adminstrators who have traditionally been responsible for security and the applicationintegrators whose application the policies are written specifically for.

84

Chapter 5. Security Policy Description Language v 2 5.2. Common Security Vulnerabilities

We assume that transport-level security (e.g. SSL) is used to protect communications be-tween the users and the servers and therefore that the network operators are not able to eaves-drop on traffic. We do not consider Denial-of-Service attacks where legitimate users are blockedfrom accessing the servers by floods of bogus network traffic. We assume the system admin-istrators stay on top of the relevant OS and server software patches and manage their networkfirewall rules so that the server machines may not be exploited directly. We do not considerthe security of the users’ machines to be important; the worst case scenario is that an attackertakes over computers belonging to other people and acts on their behalf. We do not distinguishattacks coming this way from attacks coming directly from the attackers’ own machines2. Weassume that physical attacks are not possible because the servers are locked away. Thereforethe remaining threats are due to:

• vulnerabilities in the third-party components; and

• vulnerabilities in the custom logic glueing the components together.

We assume that these application-level vulnerabilities can be used to subvert the application andleave it under the complete control of an attacker, even if all else in the system is secure. Thetwo policy languages, SPDL-2 and SWIL described in this and the following chapter aim toaddress these remaining interface vulnerabilities. Note that policy enforcement is always doneon the application-level firewall on the server-side. Some additional policy enforcement maybe done on the client-side too—to save the cost of a round-trip to the server—but in all cases,policy is always checked on the server sideas well.

5.2 Common Security VulnerabilitiesThis section contains a set of example web-application security vulnerabilities found in manyapplications today. This set is not exhaustive; for a more exhaustive list the reader is referredto the Open Web-Application Security Project (OWASP) “top 10” vulnerabilities list [9]. Theexamples presented here are intended to provide a flavour of the problem and motivate thesubsequent discussion.

5.2.1 Client-side Modification

Section 2.4.5 described the need to store application state on the client-side to provide theillusion of a coherent session over the inherently stateless protocol HTTP. Application statecan either be stored as a cookie or within a component on an HTML form. HTML formscontain several types of stateful components including textboxes, list selections, checkboxes,press buttons and even specialhiddenelements, designed specifically for storing client-side stateinvisibly. All of these may be changed. Many online e-commerce applications are vulnerable toso-called “hidden price field”’ attacks [113] where users are able to modify the prices of goodsstored in hidden fields on the client-side.

In addition to client-side state some applications use client-sidecodewritten in the languageJavascript. Such code is commonly used to prevalidate user input by checking all the input fieldshave appropriate values before sending the data to the server; useful to avoid unnecessary andslow round-trips to the server. However, it is unsafe to rely on this code catching errors asit can also be changed by a malicious user, neutralising whichever checks it performs. Anyapplication which does rely on client-side code may be vulnerable to attack.

2Of course the difference between these two cases is in the potential forcatchingthose responsible; an attackerusing someone else’s machine is presumably much harder to catch than an attacker using their own machine.

85

5.2. Common Security Vulnerabilities Chapter 5. Security Policy Description Language v 2

Defence

Client-side Modification attacks happen when application-developers mistakenly assume thatcode and data on the client side will not be modified. These attacks can be defended against bycarefully checking all data (even hidden data) on the server-side; the server should never relyon the honesty of the client.

5.2.2 SQL Attacks

SQL Attacks are sometimes known as “metacharacter attacks” or “quoting attacks”. Web-applications often include database components. For example, in an e-commerce applicationa database would be used to store the shop catalogue, inventory and a list of customer orders.Database interfaces are often written in terms of Structured Query Language (SQL) statementswhich are dynamically interpreted by the database engine. Applications construct these SQLqueries, transmit them to the database which responds with a table of records which match thequery. In a web-application the queries often involve data obtained from the user, for examplethe password supplied by the user to log into their account. Consider an application whichcontains code like the following:

$query ="SELECT * FROM users WHERE username=’"+$username+"’"+

" AND password=’"+$password+"’;";

where the variables$username and$password are bound to the user’s username and pass-word as entered on a login HTML form. Imagine a malicious user types their username as

Administrator’; \#

and leaves their password blank. After minor textual reformatting the SQL query constructedby the system will be

SELECT * FROM users WHERE username=’Administrator’;# ’ AND password = ’’;

In SQL the character# indicates the following data up to the end of line is a comment. Thereforethis SQL query is equivalent to

SELECT * FROM users WHERE username=’Administrator’;

which will successfully retrieve the system administrator’s user account from the database,without checking the password.

Defence

SQL attacks happen when developers fail to safely incorporate user data with SQL queries.They can be defended against by carefully separating all SQL metacharacters (" , ’ etc.) fromuser input through careful escaping or changes to the database interface (e.g. using precompiledSQL statements rather than relying on dynamic interpretation).

86

Chapter 5. Security Policy Description Language v 2 5.2. Common Security Vulnerabilities

5.2.3 Cross-Site Scripting

Section 5.2.1 described how client-side Javascript code is often used to enhance applicationsby pre-validating form input thus avoiding a costly round-trip to the server to catch simple typeerrors. The Javascript security model is based upon thesame origin policy. This policy statesthat Javascript code from a particular site can only access private state belonging to the samesite. The intention is to prevent Javascript written by a malicious user from stealing anotherapplication’s session state.

The web was intended to be an interactive medium which encourages everyone to publishtheir own information. This is exemplified by the proliferation of bulletin-board applicationswhich invite users to post messages in various discussion threads. Unfortunately if a malicioususer is able to publish a message containing Javascript code then when a normal user viewsthe message the malicious Javascript will appear to have come from the bulletin-board site andthe same origin policy will allow the Javascript to access the session state of the bulletin-boardapplication.

The termsession hijackingrefers to a technique for impersonating another user by stealingtheir session information somehow. As discussed in Section 2.4.5, such session data is oftenstored on the client-side due to the stateless nature of HTTP.3

Once Javascript code can access the session information it can be trivially sent to an attacker,for example by fetching a URI with the secret information as a query parameter. This subversionof the same-origin policy is known as Cross-Site Scripting (XSS).

Note that XSS attacks can be used in conjunction with client-side modification attacks:consider an application which requires users to register before being granted access by enteringpersonal details such as their full name and address. A typical HTML form for this purposewould contain separate HTML text boxes for forenames, surnames, title and address. Manysites impose length restrictions on fields like the title field; after all, most titles are quite shorte.g. Mr. Mrs. Rev. Dr. Prof. etc. It seems superficially unlikely that much malicious Javascriptcode would physically fit in such a short field. Correspondingly a web-application designermight decide not to bother filtering that particular field. However, if the length restriction is onlyimposed on the client-side then it will be possible to modify the form, remove the restriction anduse the changed form to upload a much larger than expected title field, containing the maliciouscode. If successful, anyone who views the malicious user’s title on screen may also accidentally(and transparently) execute the malicious Javascript.

Defence

XSS attacks result from improper filtering of input data. Avoiding XSS attacks involves care-fully filtering every piece of data submitted by a user removing all suspect code and HTMLtags which might be displayed by the application.4 The application server must remove all datareceived from a clientA which, if sent to another clientB, would be interpreted by clientB’sbrowser as something other than “normal” content.

3Some websites tie sessions to IP addresses, avoiding the need to store any additional client-side state (notethe IP address is another form of client-side state). Unfortunately the use of web-proxies, Network Address Trans-lation (NAT) and load-balancers render this technique almost useless in practice. Additionally, IP addresses (andtherefore sessions) can be forged.

4A difficult task because the server must filter everything the client may interpret as a script. Many differentbrowsers exist, each of which has its own set of bugs and undocumented features.

87

5.3. Formalising interface assumptions Chapter 5. Security Policy Description Language v 2

5.2.4 Forgotten Assumptions: the root cause of vulnerabilities

The vulnerabilities described here are all caused by application developers making unwarrantedassumptions about client behaviour. Within a single organisation it may be safe to assumethat clients always behave in a predicable way but on the Internet where clients and serversnormally run within different organisations a secure server should never trust a client or makeany assumptions about its behaviour.

The assumptions made by developers in the above vulnerabilities fall into three groups:

1. query parameters (as entered on forms) are transmitted as text but often represent higher-level types (e.g. a credit card numbers) which need to be checked;

2. freeform textual data is often assumed to be free of special metacharacters (like# inSQL);

3. data stored on the client-side (as cookies or hidden form fields) is modifiable.

A client-side modification attack (Section 5.2.1) is possible when developers either forget tocheck the types of form parameters (item 1) or forget that data on the client-side is modified,even if it has been marked as hidden (item 3). SQL attacks (Section 5.2.2) and XSS attacks(Section 5.2.3) occur when developers forget that users can enter special characters (item 2) –fragments of SQL or Javascript – which cause code to be executed either on the back-end serveror third-party clients.

5.3 Formalising interface assumptionsPreviously in Section 2.4.6 an interface exposed by a web-application was described consistingof a set of functions of the form:

URI (in request req, out response res) assume { }guarantee { }

This interface is very generic, insisting only that clients send valid HTTP requests (representedby the argument of typerequest) and guaranteeing only that the application will generate validHTTP responses (represented by the typeresponse). The existence of the vulnerabilities de-scribed in Section 5.2 is evidence that many real applications have more complicated interfaceswith additional and unchecked assumptions about client behaviour.

In this Section we make web-application interface assumptions explicit by creating a newinterface which acts as an interface firewall, checking the assumptions before up-calling to theoriginal interface. We define the following predicates:

Typecheck(u, req) holds iff the parameters and cookies within requestreq are valid with respectto the SPDL-2 policy associated with URIu

Statecheck(u, req) holds iff all MAC-protected client-side state within requestreq mentionedin the SPDL-2 policy associated with URIu is intact

Escaped(u, req) holds iff all metacharacter escaping has been performed on the requestreq asspecified by the SPDL-2 policy associated with URIu

Protected(u, res) holds iff the client-side state mentioned in the SPDL-2 policy associatedwith URI u and stored within the HTML form in the responseres has been protected bya MAC.

88

Chapter 5. Security Policy Description Language v 2 5.3. Formalising interface assumptions

interface I {type cookies = stringtype uri = stringtype parameters = (string × string)list



U1(in request req, out response res)assume { Typecheck(U1, req),

Statecheck(U1, req),Escaped(U1, req)}

guarantee {Protected(U1, res)}. . .Un(in request req, out response res)

assume { Typecheck(Un, req),Statecheck(Un, req),Escaped(Un, req)}

guarantee {Protected(Un, res)}}

Figure 5.2: A web-application firewall interface with URIs={U1 . . .Un} using the formalismof Section 2.3.

The generic interface for a web-application was displayed in Figure 2.14. The new interfacewith additional assumptions and guarantees is displayed in Figure 5.2. Each of the assumptions(Typecheck(U1, req), Statecheck(U1, req), Escaped(U1, req) corresponds to an explicit checkmade by the application-level firewall. If any of the assumptions do not hold (i.e. the corre-sponding check fails) then the request is blocked and the application is protected. Similarly, theguarantee made about the response (Protected(U1, res)) corresponds to a transformation ap-plied to the response – annotating client-side state with MACs – before returning to the caller.

5.3.1 Example

Consider part of an e-commerce application consisting of 2 URIs whose paths5 areviewdetails and commit . The URI viewdetails displays details of a transaction,prompting the user for confirmation while the URIcommit finalises the transaction by debitingthe user’s credit card and storing the order in a back-end database. The raw generic interfacewould have the following form:

interface Application{viewdetails(in request req, out response res)commit(in request req, out response res)

}

Imagine the application stores all session data on the client-side as hidden form fields. The formreturned byviewdetails will look something like the following:

5A URI http://www.example.com/view has pathview .

89

viewdetails

commit

viewdetails

commit

viewdetails


5.3. Formalising interface assumptions Chapter 5. Security Policy Description Language v 2

<form target="commit"><input type="hidden" name="productID" value="1234"/><input type="hidden" name="price" value="19.99"/>...<input type="submit">Submit order</input>

</form>

The formtarget field indicates that the values contained within the form should be sent to theURI commit when the user presses the submit button. Notice the two hidden text fields; onestores the integer ID of the product being purchased and the other stores the price as a floatingpoint number.

The application is potentially vulnerable in the following ways:

• it may not check the types of theproductID andprice fields, leading to undefinedbehaviour in the event the user changes the types of these values; and

• theprice field (representing the price of an item in a shopping cart) is left on the client-side and may be modified by a user keen to get an unauthorised discount.

We may protect the application by creating an interface firewall with an interface like that shownin Figure 5.2 and producing suitable definitions for the predicates:

• Typecheck(commit, req),

• Statecheck(commit, req),

• Escaped(commit, req) and

• Protected(viewdetails, res).

The predicateProtected(viewdetails, res) should guarantee the hidden field data returnedby theviewdetails URI is protected by a MAC. TheTypecheck(commit, req) predicateshould guarantee the types of the parameters:productID is an integer andprice is a floatingpoint number.Statecheck(commit, req) verifies the client-side state protected by a MAC (i.e.by theProtected(viewdetails, res) predicate) is still intact. This example does not containan SQL Attack (Section 5.2.2) or XSS (Section 5.2.3) vulnerability and so we require

∀req .Escaped(commit, req) = T

MACs allow servers to verify that state stored on the client-side (in the form of hiddenfields) is returned unmodified. A well-written server would be expected to store well-typeddata in such MAC-protected fields; returning to the previous example, one can see that theproductID field was an integer while theprice field was a floating-point number. However,it is possible to imagine a buggy server which accidentally generates badly-typed hidden formdata. Such badly-typed data might lead to an application-level error when the data is returnedunmodified to the server. Therefore it is still useful to typecheck all data, even though some isMAC-protected and cannot be modified by malicious users. Typechecking therefore serves twopurposes: (i) it prevents users entering badly-typed data into form fields; and (ii) it prevents abuggy application from sending itself badly-typed data through hidden form fields.

The next section describes the language SPDL-2 – Security Policy Description Languageversion 2 – which is used to define concretely the request/response validation constraints andtransformations represented by the predicates mentioned above.

90

commit

viewdetails

Chapter 5. Security Policy Description Language v 2 5.4. SPDL-2 Overview

5.4 SPDL-2 OverviewThe language SPDL-2 (Security Policy Description Language version 2) allows the spec-ification of both per-URI validation constraints and data transformation rules. The firstversion of SPDL was presented at the Eleventh International World Wide Web conference(WWW2002) [144] and had several deficiencies which have been addressed by the design ofversion 2. In particular SPDL-2

• allows policies to be defined hierarchically, factoring out common elements and leadingto more readable specifications;

• allows fine-grained control over expensive HTML-modification operations specificallythe use of Javascript (see Section 5.4.1) and MAC insertion (see Section 5.4.1); and

• uses the same language for both validation and transformation (see Section 5.3 expres-sions for consistency.

SPDL-2 descriptions may be written by hand or with the aid of automatic tools. Once written,policies can be compiled into executable code and dynamically loaded into an application-levelfirewall which sits between the Internet and the back-end web-server. The following sectionsdescribe the SPDL-2 language in detail.

5.4.1 Security Policy Description Language Version 2

At the top level, an SPDL-2 specification is an XML document (XML and HTML were brieflycompared in Section 2.4.3). The full DTD for SPDL-2 may be found in Appendix A. The doc-ument consists of a single<site> element which in turn contains a collection of<policy>elements. Each<policy> element contains a group of related<uri> and<cookie> ele-ments and optionally<parameter> and further nested<policy> elements.

For each<uri> element a number of<parameter> elements are declared. The attributesof a<parameter> element with attributename = p place constraints on data passed via URIparameterp:

• The maxlength andminlength attributes specify maximum and minimum lengthconstraints.

• Settingrequired to “Y” specifies thatp must always contain a (non-zero length) value;

• SettingMACto “Y” specifies that the value ofp must be accompanied by a Message Au-thentication Code (MAC) [143] generated by the server. This provides assurance of dataintegrity; i.e. the user is prevented from changing the value of the parameter to arbitraryvalues .

• The type attribute specifies the data-type ofp (currently eitherint , float , bool orstring ).

Themethod attribute determines whether the specified constraints apply top passed as a GET-parameter (i.e. a URI argument) or a POST-parameter (i.e. returned from a form).

For example, consider the following policy fragment:

91

5.4. SPDL-2 Overview Chapter 5. Security Policy Description Language v 2

e ← x (variables)| c (constants)| f(e1, . . . , ek) (function calls)| getparam .c (value of GET parameters)| postparam .c (value of POST parameters)| this (value of this field)| e1 〈op〉 e2 (binary infix operators)| if e1 then e2 else e3 (conditionals)| let d . . . d in e end (local declarations)

d ← val x : t = e (immutable bindings)| fun f(x1 : t, . . . , xk : t) : t = e (function definitions)

t ← int | float | string | bool (types)

Figure 5.3: The Abstract Syntax of the Validation Language.

<policy name="example" description="..."><uri prefix="http://www.example.com/foo">

<parameter name="p1" maxlength="4"type="int" required="Y"MAC="N" />

<parameter name="p2" method="POST"maxlength="3" type="string" />

</uri></policy>

This example specifies constraints on parameters passed to URIs with prefix “http://www.example.com/foo ”. The first<parameter> element defines constraints to be applied toa parameter namedp1 passed by either GET or POST; the second<parameter> elementdefines constraints to be applied to a POST parameter namedp2 . A larger example of a policydefinition can be found in the case study of Section 5.5. The case study explicitly demonstrateshow policies can be nested within each other in order to abstract common parameters (e.g.Session IDs etc.) from a group of related URIs.

The attributes of the<parameter> element are intended to cover the majority of valida-tion constraints required in practice. However one can imagine some circumstances in whichmore flexible constraints are required; this is the purpose of the<validation> element.Within <validation> elementsvalidation expressionsmay be written in a general purposevalidation language. SPDL-2 uses a simple, call-by-value, applicative language which is essen-tially a simply-typed subset of Standard ML [116] to express validation expressions. Note thatthe exact details of the language are not important and a commercial version of the system maychoose to replace ML with a more mainstream industrial language, like Java.

The abstract syntax of the validation language is displayed in Figure 5.3. All well-formedexpressions have typebool ; this restriction is enforced by a compile-time type-checking phasein which all badly typed expressions are rejected. If the expression evaluates at run-time totrue then this signifies that the parameter contains valid data. Invalid data should cause thevalidation expression to evaluate tofalse. Validation expressions are executed in an environment

92




in which all HTTP GET parameters namedx may be referenced asgetparam.x , HTTP POSTparameters namedx aspostparam.x and the value of the enclosing parameter is referred toby the special namethis .

The SPDL-2 system contains a simple standard library of convenience functions including:

• Arithmetic operators+, - , * and / which can be applied to both integers and floatingpoint values. String concatenation is represented by the infix operator++.

• Relational operatorslt , gt , le andge can be applied to integers, floating point numbersand strings (under the standard lexicographic ordering).

• The functionString.length(s) returns the length in characters of strings .

• The functionString.format(s,regexp) returns true iffs matches the form spec-ified by regular expression,regexp .

• The functionString.mid(s,l,r) returns the substring ofs which starts at characterl and finishes at characterr inclusively. (Characters ofs are numbered from 1).

• Functions are provided to convert between different types. For example,String.fromInt(i) returns the string representation of integeri .

• Functionisdefined(p) takes a parameter (e.g.getparam.p or postparam.p )and returns a boolean indicating whetherp is defined (i.e. has been passed to the URI inthe HTTP request). Using an undefined parameter as an argument to any other functionor operator leads to a dynamically generated error message.

Transformation rules for parameters and cookies are written in the same language as valida-tion expressions but are often much simpler. The standard library contains a number of functionscovering some of the common cases. For example, if it was necessary to remove all spaces froma parameterp and then SQL-escape the result the specification would look something like:

<transformation>let fun filter(s: string, char: string):string =

let val first:string = String.mid(s, 1, 1)val rest:string = String.mid(s, 2,

String.length(s) - 1)in if (fst = char) then filter(rest, char)

else first ++ (filter(rest, char))end

in Transform.SQL( filter( this, " " ) )end

</transformation>

The standard library contains the following functions:

• The functionTransform.EscapeSingle(s) returns a copy of the strings whereall single quotes have been replaced with their HTML character encoding.

93

String.fromInt(i)

String.fromInt(i)

5.4. SPDL-2 Overview Chapter 5. Security Policy Description Language v 2

• The functionTransform.EscapeDouble(s) returns a copy of the strings whereall double quotes have been replaced with their HTML character encoding.

• The functionTransform.HTML(s) returns a full HTML-encoding of strings whereevery meta-character has been replaced by an HTML character encoding.

• The functionTransform.HTMLpartial(s) returns a copy of the strings where allmeta-characters have been replaced by character encodings (likeTransform.HTML )with the exception of those associated with a small number of allowed tags (includingsimple style tags,<b>, <u>, <i> and anchors of the form<a href="..."> ...</a> ).

• The functionTransform.SQL(s) returns a copy of the strings where all SQL meta-characters such as ‘; ’ are escaped.

HTML-encoding is a particularly important transformation since inadvertently forgettingto HTML-encode user-input leads directly to XSS vulnerabilities, described earlier in Sec-tion 5.2.3. In recognition of the importance of this transformation, the convention is thatallparameters are HTML-encoded unless explicitly specified otherwise in the security policy. Toturn off HTML-encoding one must set thehtmlencode attribute of thetransformationelement toN. For example one may write:

<transformation htmlencode="N" /transformation>

The DTD in Appendix A specifies that policies within an SPDL-2 document consist of aseries of<uri> and<cookie> elements.<uri> elements have already been discussed indetail; in a similar fashion,<cookie> elements allow designers to place validation constraintson cookies returned from clients’ machines. Earlier in Section 2.4.2 the assumption was madethat cookies are global across entire applications i.e. all cookies are returned to the applicationin every request. This allows MACs to be generated for all state together.

Client-side Form Validation

Whenever requested by the policy (through the policy attributejavascript="Y" ), the fire-wall inserts Javascript code to perform client-side validation checks. (Recall that the insertion ofJavascript is only intended to enhance usability – data is always rechecked by server-side codeto avoid the kind of Client-side Modification attacks described in Section 5.2.1). The insertedcode checks most of the SPDL-2 constraints: types, lengths and all custom constraints writtenin the validation language. The resulting program is inserted into theonSubmit attribute of a<form> tag (described earlier in Section 2.4.3) unless such an attribute is already present – inwhich case an error is generated.

Message Authentication Codes

Recall that SPDL-2 policies allow URI parameters to be marked indicating that they must onlyreceive data which is accompanied by aMessage Authentication Code(MAC) [143] to ensurethe integrity of state stored on the client-side. This corresponds to the predicateProtecteddescribed in Section 5.3.

The implementation (discussed further in Chapter 7) uses the HMAC [20] algorithm togenerate MACs by securely combining the protected data with a secret key and a timestamp.In this way an attacker is unable to generate new MACs without first finding out the secret key.

94

Transform.HTML


A major danger still facing this system is avoidingreplay attacks[154] where clients replaymessages already annotated with MACs in unexpected contexts. Two steps are taken to avoidsuch attacks:

1. A time-stamp is included in the MAC to guarantee messagefreshness.

2. Rather than generating separate MACs for each individual protected field, a single MACis generated for all protected client-side state bundled together. This protects the integrityof the whole message, protecting against cut-and-splice attacks (in which MAC-annotatedfields are swapped into other messages).

Despite these preventative measures, the responsibility for ensuring that replay attacks are notdamaging ultimately rests with the security policy designer. For example, in the case study ofSection 5.5 a MAC is generated forboth theproductID and Price fields. Although userscan replay such messages this results in multiple purchases of the same product for thecorrectprice. The intention is that the MAC prevents thePrice andproductID being modifiedindependently.

SPDL-2 requires that HTML pages fetched from URIs that are contained in a single<policy> block may only contain links to MAC-protected URIs6 which are found in the same<policy> block (or in a nested<policy> block). By forcing the application’s URIs to bepartitioned in this way an important performance optimisation is facilitated which is discussedlater in Chapter 7.

Server-side State

The previous section described how client-side state may be protected using a MAC generatedfrom a secret key and a timestamp. The secret key used is a piece of state stored on the server-side (strictly-speaking the state is stored within the interface-transforming firewall, rather thanthe application process itself). One may wonder whetherall state should be stored in this way,rather than transmitted to the client at all.

The primary difference between the state represented by the secret key and the state storedin the hidden form fields is that the secret key is considered to be a constant shared across alot of independent user sessions, whereas the state found in hidden form fields is applicationand session-specific. Consider the example described earlier in Section 5.3.1 which had twohidden fields:price andproductID representing the price of a good and a database keyrespectively. If two users are purchasing different goods from the application at the same timethen they will have differentprice andproductID fields in their respective requests but,crucially, the MACs will be generated with thesamesecret key.

A single shared secret key for MACs allows us to build a scalable implementation. A clusterof interface-transforming firewalls can be used, all pre-configured with the same key. Since thekey is shared it will not matter that logically related interactions (e.g. those pertaining to thesame session) could be handled by different firewall nodes. By contrast, if all application state(like theprice andproductID ) were stored within the firewalls then this state would haveto be shared dynamically between the firewall nodes. Accessing the state would be a bottleneck,inhibiting the scalability of the system.

The timestamp stored within the MAC is intended to guarantee messagefreshnessand tolimit the scope for replay attacks. The timestamp can be implemented in one of two differentways. It may be used to contain

6A MAC-protected URI has at least one<parameter> with its MACattribute set to ‘Y’.

95

5.5. Case Study Chapter 5. Security Policy Description Language v 2

e-commerce application

static HTML pages

dynamic pages

3rd-party component

in-house PHP component

Policy enforced dynamically by Application-Level Firewall

No policy enforcementnecessary

Figure 5.4: High-level structure of a simple e-Commerce web-site.

1. the exact time the MAC was generated (assuming clocks are synchronised across thefirewalls); or

2. a message sequence number.

The former approach allows the firewalls to reject replayed requests that are more than a certainnumber of seconds old. This obviously does not prevent all replays but it has the advantage ofscalability—no extra state is required in the firewalls. The second approach allows firewalls toreject all duplicate responses, completely preventing all replays but at the cost of requiring extrastate in the firewalls. The implementation of the system described in Chapter 7 uses the former,stateless approach. It must be emphasised therefore that the primary function of the MACs is toprevent hidden fields changing separately (e.g. allowing a differentproductID for the sameprice ) and not to prevent all replays.

5.5 Case Study

To illustrate the methodology presented in this Chapter a hypothetical e-commerce system isconsidered. The hypothetical application is first partitioned into groups of URIs (see Figure5.4) corresponding to:

96

Chapter 5. Security Policy Description Language v 2 5.5. Case Study

• static HTML pagesincluding “welcome” pages, an “about” page and all static multimediacontent (e.g. images, videos, music);

• a group ofdynamic pagesfurther subdivided into

– an off-the-shelf 3rd party shopping cart component capable of credit card transac-tions;

– an in-house PHP component.

To make a more realistic example let us assume that:

• both the in-house components and the 3rd party component are configured to set a cookie,sessionKey , to monitor user movement through the site for marketing research pur-poses;

• the off-the-shelf shopping cart component is supplied in a binary-only form and thereforecannot be modified.

Let us further assume that the site in question is vulnerable in the following ways:

1. The in-house PHP code (used to view an online shopping catalogue) has missing inputvalidation code and can be used to execute arbitrary SQL against the back-end databaseusing the attack described in Section 5.2.2.

2. ThesessionKey cookie is predictable since it is created using a time-seeded randomnumber generator; clients can spoof other active sessions by modifying the value of thecookie in their browser.

3. Javascript can be embedded in thesurname field of the shopping cart login page which,when viewed on the company’s intranet, leads to XSS vulnerabilities.

4. The Client-side Modification attack (described earlier in Section 5.2.1) can be used toreduce the price of items in the shopping cart component.

5.5.1 Designing the Security Policy

The static pages can be described simply with a single<policy> block containing a straight-forward list of URIs; no processing is required for these pages.7 The dynamic pages, on theother hand, necessitate a more complex policy description. In the example application describedabove, the dynamic pages may be subdivided into two sets of pages: those corresponding to the3rd party component and the in-house PHP code. Each of these sets should be mapped onto itsown<policy> block and then if either component is upgraded the policy changes required arelimited to a single block.<policy> blocks may be nested and inner blocks inherit the param-eter and cookie specifications from outer blocks. Since thesessionKey cookie is commonto all the dynamic pages it is desirable to nest the policy specifications for the dynamic pageswithin a parent<policy> block which declares this shared cookie. The resulting SPDL-2XML document has the following high-level structure:

7Note that these pages will also silently ignore thesessionKey cookie.

97

5.5. Case Study Chapter 5. Security Policy Description Language v 2

<site name="e-Commerce website" ...><policy name="Static pages" javascript="N">

<uri prefix="About.html" /><uri prefix="Contact.html" />...

</policy><policy name="Dynamic pages" ...>

<cookie name="sessionKey" MAC="Y" maxlength="16"type="int"/>

<policy name="dynamic enforcement"><policy name="3rd party component">

<uri prefix="CreditCard.asp" />...

</policy><policy name="in-house PHP">

<uri prefix="ViewShoppingCart.asp" />...

</policy></policy><policy name="static enforcement">

<uri prefix="Login.asp" /><uri prefix="Buy.asp" />...

</policy></policy

</site>

All that remains is to fill in the individual<uri> elements by writing the appropriate vali-dation and transformation code. To see how this is done, consider the final step in the purchasingprocess in the shopping cart, a continuation of the example first used in Section 5.3.1. Imaginethat users are sent an HTML form requesting their surname, credit-card number and its expirydate. The price and product-ID are stored in hidden form fields on the form. For example, whenpurchasing a product withproductID = 1234, the form sent to the client might be as follows:

<form method="POST" target="commit">

<input type="hidden" name="productID" value="1234"><input type="hidden" name="price" value="19.11">

<input type="text" name="surname"><input type="text" name="CCnumber"><input type="text" name="expires">

<input type="submit">Submit order</input></form>

98

Chapter 5. Security Policy Description Language v 2 5.6. Related Work

Once purchases have been made, an order record is entered into the company’s back-enddatabase which can be subsequently viewed on their local intranet.

The SPDL-2 fragment corresponding to the form’s target URI (commit ) is presented inAppendix B. Each of the parameters shown in the form above are declared and a numberof validation and transformation rules specified. A typical validation element looks like thefollowing:

<parameter name="productID" method="POST"maxlength="10" minlength="1"required="Y" type="int" />

This fragment indicates that the fieldproductID should be between 1 and 10 characters long,should always be present and should be a valid integer. Most of the rest of the SPDL-2 specifi-cation is self-explanatory although a few points are worth noting. Firstly the<validation>element for theprice field simply states that negative prices are not allowed. Secondly themore complicated validation expression for theCCnumber field is an implementation of theLuhn-formula commonly used as a simple validation check for credit-card numbers. Thirdlythe validation expression for theexpires field ensures that it is of the formmm/yyand alsochecks that the month is in the range 1–12.

Through repeating this process for all<uri> elements all of the system’s vulnerabilities(described above) may be fixed without modifying any of the application code:

1. The form- and cookie-manipulation attacks can no longer be used since theprice andproductID fields along with thesessionKey cookie can all be protected by havingtheirMACattributes set to “Y”.

2. Thesurname field can be HTML-encoded, preventing XSS attacks.

3. SQL attacks are prevented by applying the transformation,SQLEncode (see Section5.4.1), to escape quotes in all relevant fields.

If specified in the SPDL-2 specification (by settingjavascript="Y" ), Javascript codewill be inserted to check validation rules on the client-side. In this example Javascript is gen-erated to ensure that credit-card numbers satisfy the Luhn-formula, that expiry dates are of theform mm/yy, that thesurname field contains a non-zero-length value etc. Note that if extravalidation constraints are required, they can simply be added once to the policy specification.Using conventional tools and techniques, the addition of extra validation constraints may requirethem to be coded multiple times (once in Javascript for client-side validation and certainly atleast once in the web application’s source code).

5.6 Related Work

Related work is divided into two categories. The first category comprises proposals for newmethods for developing web-applications from scratch which attempt to abstract away manyof the difficulties of traditional web-programming. The second category comprises tools foranalysing and protectingexistingapplications. SPDL-2 falls into the second category.

99

commit

5.6. Related Work Chapter 5. Security Policy Description Language v 2

5.6.1 New Application Frameworks

Graunke et al

Graunke et al [77] describe a model of web interactions in which each application consists of aset of URIs, each of which is a function which takes a request and produces a result containing asingle form. This is the same model of web interactions presented earlier in Chapter 2. Graunkeuse this model to propose a type system for a new web-scripting language in which each formis associated with a record type and the server prevents the execution of any program whichmight generate a form which violates this typing. Their focus is on preventing run-time errorscaused by programming errors, not on preventing run-time errors caused by malicious usersmodifying otherwise-correct forms. As a side-effect of their different focus they also purposelyignore issues arising from the use of client-side storage, which is an important part of the systemproposed here.

BigWig

The <bigwig> project [1] consists of domain-specific languages and tools for the develop-ment of web services. A part of the<bigwig> project,PowerForms[28], allows constraints(expressed as regular expressions) to be attached to form fields. A compiler generates bothclient-side Javascript and code for server-side checks.

There are several key differences between<bigwig> and the system proposed here. Firstly<bigwig> is intended for the development of new web-applications whereas the system hereis able to retrospectively attach security policy to existing applications.<bigwig> lacks ageneral-purpose validation language using instead a system of regular expressions. Validationconstraints in<bigwig> and SPDL-2 can both be compiled to Javascript for client-side execu-tion but<bigwig> only supports server-side validation when the application itself is written in<bigwig> . SPDL-2 policies can be applied no matter what language the application is writtenin.

WASH/CGI

WASH/CGI [159] is a system for building web-applications entirely in Haskell. It is structuredinto sub-languageseach handling a different aspect of application development. The documentsub-language handles creating valid XHTML documents, the session sub-language provides asession abstraction, the widget sub-language allows forms to be typed (in a similar manner toGraunke at al [77]) and the persistence sub-language handles server-side and client-side storage.WASH/CGI therefore provides all the facilities needed to develop sophisticated applicationsand has no obvious security problems itself. However creating secure distributed applicationis still difficult (as argued in Chapter 2). It is still possible to compose together individuallysecure components to produce an application with vulnerabilities. For example it would still bepossible to use WASH/CGI to produce an application which uses client-side state insecurely,like in the earlier e-commerce example of Section 5.3.1. Systems like SPDL-2 are thereforestill useful even when such advanced tools are used to construct systems.

5.6.2 Dynamic approaches

Sanctum AppShield

Sanctum Inc. produce a product called AppShield [140] which, like the system described here,protects a system by interposing an interface firewall. However, despite this apparent similarity,there are significant differences between the two systems: we take theprogrammatic approach

100

Chapter 5. Security Policy Description Language v 2 5.7. Summary

of specifying a security policy explicitly; in contrast AppShield has no policy description lan-guage or compiler and attempts to infer a security policy dynamically. Whilst this allows App-Shield to be installed quickly, it limits the tasks it can perform. In particular, since there is nopolicy description language for describing validation or transformation rules, AppShield knowsvery little about what constitutes valid parameter values in HTTP-requests and can only per-form simple checks on data returned from clients. AppShield is intended as a plug-and-playtool which provides a limited degree of protection forexisting websites with application-levelsecurity problems. In contrast, we envisage our approach as also being useful in the designprocess of new applications i.e. when components are being composed together to make newsystems.

WebScarab

WebScarab is a freely available Java-based application penetration-testing framework. It iscomplementary to the system described here: where SPDL-2 is intended to define the behaviourof an interface firewall toprotectan application, WebScarab is intended to locate the errors in anapplication so they can be fixed. It contains an HTTP proxy, web-spider and a set of predefinedapplication security tests. WebScarab is not intended to be fully-automatic (the developers say,“There is no shiny red button in WebScarab”) but rather as a base on top of which developerscan write application-specific tests. WebScarab is used for off-line analysis, not as a permanentapplication-protecting firewall like AppShield.

5.7 SummaryThis chapter introduced SPDL-2, a language for writing expressive security policies govern-ing web-application interfaces. SPDL-2 allows the specification of per-request and responsevalidation constraints and transformation rules which protect web-applications from client-sidemodification attacks, SQL attacks and cross-site scripting (XSS) attacks. As justified by theextended case study, policies written in SPDL-2 are effective even when an application is con-structed from multiple components, written in different languages and when components areonly available in binary form. Implementation details are presented later in Chapter 7.

One attack, “forceful browsing” was mentioned briefly at the start of this chapter but notelaborated. This attack and its prevention are the subject of the following chapter.

101

Chapter 6

Stateful Web-application Interface Language

This chapter is the second and final chapter dealing withinterfacesof applications. The previouschapter introduced the policy language SPDL-2 which allows stateless per-request and responsevalidation and transformation rules to be specified for web-applications. SPDL-2 policies areable to protect applications from several common forms of application-level vulnerabilities,including client-side modification, SQL attacks and XSS. Mentioned briefly in the previouschapter,forceful browsingattacks involve submitting legitimate, well-typed1 requests to an ap-plication in an unexpected order, causing the application state to become invalid. This chapterdescribes this class of attack in detail and presents a new policy language called the StatefulWeb-application Interface Language (SWIL) designed specifically to thwart this kind of attack.

At the most basic level, SWIL describes the acceptable order of operation invocations asthat accepted by a deterministic finite state automaton. SWIL is designed to be both easilytranslatable into PROMELA – the input language of the SPIN model-checker – as well as directlyexecutable by an application-level firewall. Using SPIN, policies in SWIL are readily analysedbefore being installed, enabling policy designers to verify the system is free from importantclasses of error like deadlocks, livelocks and assertion violations.

Built on top of SWIL, the SWIL Meta-programming System (SMS) provides a high-levelmechanism to automatically generate low-level SWIL programs. SMS consists of an embeddingof SWIL in Objective-Caml (O’Caml)2 [108] together with a library of useful functions whichgenerate common application control sequences.

SWIL programs can do more than simply block erroneous HTTP requests; they can also beused to guide the actions of an HTML-based user interface transcoder. The transcoder is capableof removing all HTML elements (i.e. links and forms) whose normal use3 would always violatethe installed security policy. Finally, to demonstrate the complete SWIL-based system, a seriesof examples involving a hypothetical e-commerce site are presented and discussed.

The structure of this Chapter is as follows: Section 6.1 begins with a detailed discussion offorceful browsing attacks leading into an overview of the SWIL system contained in Section 6.2.Technical details of both SWIL and SMS are described in Section 6.3, followed by a descriptionof the translation into PROMELA in Section 6.4 and the dynamic user interface transformationprocedure in Section 6.5. The system is demonstrated by means of an extended example inSection 6.6. Related work is found in Section 6.7 while section 6.8 concludes this chapter.

1The requests are well-typed in the sense that they pass SPDL-2 parameter validation checks.2Standard ML (on which SPDL-2 validation expressions are based) and O’Caml are very similar, differing in

minor syntax and library support.3Normal use is discussed later but specifically excludes activities such as modifying application HTML in a

text editor and generating custom HTTP requests.

102

Chapter 6. Stateful Web-application Interface Language 6.1. Motivation

6.1 MotivationEarlier in Section 2.4.6 the interface for a web-application was described as a collection ofURIs, each of which is represented as a function which takes a single input of typerequest(representing HTTP requests) and returns a single output of typeresponse (representing HTTPresponses):


No other assumptions (represented by the keywordassume) or guarantees (represented by thekeywordguarantee ) were documented in the default web interface description. Chapter 5described how many assumptions about what constitutes valid input values typically remainundocumented in real applications. These assumptions often manifest themselves in the formof application-level vulnerabilities which an attacker can exploit. The policy language SPDL-2 was designed to allow the specification of stateless per-request and response validation andtransformation rules and when enforced by a special application-level firewall (described laterin Chapter 7) is able to prevent many of these common attacks.

SPDL-2 only deals with argument (parameter) validation. In the description in Chapter 5nothing was said about the acceptable order of execution of the interface functions; rather it wasassumed that a user could invoke the operations in an arbitrary order with arbitrary parameters,provided they satisfied the validation constraints.

Unfortunately some application designersdo make assumptions about the acceptable orderof function invocation. When a user invokes a function from the interface, the response typicallycontains an HTML document comprising links and forms pointing to further interface functions.Usersnormally click on these links to continue their session with the application. It is easyto forget that users can manually type in URIs at any time, open new windows or click ontheir browser’s “back” button, potentially confusing the application4. Many current statefulapplications attempt to detect when the client and the server get out of synchronisation andreturn an error message. However, as is the case with the other vulnerabilities discussed inChapter 5 it is difficult to ensure this potential error case is handled properly everywhere insidea large application. An attacker need only find one vulnerability in the application to mount aforceful-browsingattack.

6.1.1 Forceful Browsing Examples

Imagine a hypothetical e-commerce website which has a three stage checkout procedure, dis-played diagrammatically in Figure 6.1. The first stage (labelled “Step 1”) displays the contentsof the user’s shopping cart and offers the user the chance to make a purchase. The next stage(“Step 2”) asks the user to enter credit card details while the last stage (“Step 3”) asks for a de-livery address. The normal path through the application (from “Step 1” to “Step 2” to “Step 3”)is illustrated with the solid arrows. The web-site designer intends that goods are only dispatchedonce both payment and delivery details are confirmed.

Imagine a scenario where a user manages to guess the URI pointing to the delivery addresspage. Such a user will be able to request the delivery address page without having filled in thecredit card details first. This alternate path through the application (from “Step 1” to “Step 3”

4It should be noted that a fully stateless application – one in which all application state is stored on the client-side – is less likely to be confused than an application which possesses mutable server-side state which cannot berolled back to a previous configuration. It should also be recognised that not every application can be stateless e.g.a flight booking application will need to commit a transaction to a database at some point.

103

6.1. Motivation Chapter 6. Stateful Web-application Interface Language

CCNumber:

Expires:

DeliveryAddress

Shopping Basket Contents:

Buy

Next

Confirm

1. ...2. ...

Step 1

Step 2

Step 3

Displays shopping basketand offers user the chance to make a purchase

Prompts user for creditcard details

Prompts user for theirdelivery address

Figure 6.1: A hypothetical e-commerce website with a three stage checkout procedure. Eachstep has a form which points to the following step. The intended path through the procedure isdisplayed using the solid arrows. An alternate path, which may constitute a forceful browsingattack is displayed using a dashed arrow.

bypassing “Step 2”) is illustrated in Figure 6.1 by the dashed arrow. If the application has beenwritten securely then the unexpected request (“Step 3”) will be rejected and the user forced togo back and enter their payment details. However, if the application developer has assumed thatthe only way to reach the delivery address page (“Step 3”) is by pressing the button on the creditcard page (“Step 2”) and the code contains no explicit check then the application is vulnerable toa forceful-browsing attack. In this example the forceful-browsing attack may allow a malicioususer to receive goods without paying for them.

It is worth noting that forceful browsing attacks are not always malicious. Many web-applications use client-side Javascript code to open new web-browser windows, a particularlycommon technique in the travel industry. Consider a hypothetical travel booking applicationwhich opens a new window displaying flight details every time a user performs a databasesearch. Furthermore imagine the application designer intends that each search result is eitheraccepted (by clicking on a “buy” button) or discarded (by closing the window) before any further

104

Chapter 6. Stateful Web-application Interface Language 6.1. Motivation

Search Criteria

Search

Search Criteria

Search

Search Criteria

Search

Confirm Flight

Confirm

Flight Details 1

Buy

Flight Details 2

Buy

Flight Details 1

Buy

Step 1 Step 2 Step 3 Step 4

time

Figure 6.2: A sequence of interactions with a hypothetical travel-booking web-application.Time runs horizontally left to right. At each point in time a number of windows are open,displayed vertically.

searches are made. A possible sequence of events is shown diagrammatically in Figure 6.2,with time running horizontally from left to right. At the first stage (“Step 1”) the user enterssome search criteria and presses the button marked “search”. The second stage (“Step 2”) a newwindow has been opened containing the details of a flight (labelled “Flight Details 1”) alongsidethe original application window. Rather than discarding this window or accepting the flight, theuser returns to the original application window and enters different search criteria. The resultsof the second query appear in another new window (labelled “Flight Details 2”) at the third stage(“Step 3”). Imagine the user prefers the first result to the second and so discards the window“Flight Details 2” and presses the button marked “Buy” on the window “Flight Details 1”. Atthe final stage (“Step 4”) the user has to confirm the transaction and pay for the flight. Thequestion is: which flight has the application booked? From the point of view of the user the firstflight has been booked. However if the application contained server-side state relating to thecurrent search results then it might misinterpret the request and accidentally book the secondflight. In effect, the application has suffered a forceful browsing attack simply because a userhas clicked onlegitimatelinks (i.e. those provided by an application) in an unexpected order –no guessing of URIs or other dubious behaviour was required on the user’s part.

105

6.2. Overview Chapter 6. Stateful Web-application Interface Language

Defence

Forceful-browsing attacks occur when developers forget that users can invoke interface func-tions at any time, with any arguments (provided they satisfy whatever parameter validationscheme is in force). They are a direct consequence of the mismatch between the stateful natureof many applications and the statelessness of the HTTP protocol, a problem exacerbated by thethe flexibility of web-browsers (specifically the ability to open new windows, use bookmarksand type URIs at will). The attacks can be prevented by ensuring that the requests receivedfrom the user are consistent with the internal state of the application. In the three stage check-out procedure example above, the application should reject requests for the delivery addressstage (“Step 3”) without first receiving the payment details (“Step 2”). In the travel-bookingexample, the application shouldeither reject requests which correspond to stale search resultsi.e. once the window “Flight Details 2” is opened, all requests related to the window “FlightDetails 1” should be rejectedor it should use enough client-side state (protected as necessarywith MACs as in Chapter 5) to book the flight the user actually chose.

6.2 OverviewThis chapter introduces a form of web-application security policy based on Alfaro and Hen-zinger’s Interface Automata [46] which allows developers to define the acceptable order of URIinvocations as that accepted by a deterministic finite state automaton. A simple language calledStateful Web-application Interface Language (SWIL) for defining such automata is presentedand the language is embedded in O’Caml — a variant of ML. The embedding facilitatesmeta-programming; high-level ML programs can be written which generate complete low-level SWILprograms. To demonstrate the usefulness of this technique, a small library of functions has beencreated each of which represents a common application control sequence. The functions in thelibrary can be easily composed together to generate sophisticated SWIL programs.

SWIL has special-purpose features intended for web-applications interacting over HTTP:specifically an HTTP request type and manipulation functions. The language has been de-signed to be easy to translate directly into PROMELA, the language accepted by the SPIN model-checker as well as simple to execute dynamically on an application-level firewall.

A high-level overview of the system is presented graphically in Figure 6.3. After gener-ation using the O’Caml embedding, SWIL policy is compiled first to PROMELA for off-lineanalysis with the SPIN model checker. PROMELA is used to verify a number of useful proper-ties including: (i) the error state (encountered when an unexpected HTTP request is received)is unrecoverable; (ii) the automaton does not suffer from livelock or deadlock; and (iii) keysteps (such as authentication) cannot be bypassed by forging a URI. Once the policy has beenanalysed in sufficient detail and the relevant properties verified it is compiled into an O’Camlprogram for dynamic execution on an application-level firewall, alongside any desired SPDL-2policies.

Policies can be designed at different levels of granularity and installed in parallel. Sucha compound policy ensures that only HTTP requests accepted byall policy automata will beallowed through to the application. Policies can be activated and deactivated at run-time inresponse to external demands. Finally, policies executed by the application-level firewall arenot only passive monitors of application behaviour but take a more active role. A strength ofthe design presented here is that policies may be used to dynamically transform the appearanceof graphical user interfaces expressed in HTML, removing interface elements (links and forms)whose use correspond to transitions inevitably leading to future error states.

106

Chapter 6. Stateful Web-application Interface Language 6.2. Overview

InternetX

Application-levelFirewall

(Chapter 7)UnmodifiedWeb Server

Possibly MaliciousClients

SWIL policy

/* One #define for each used string constant: */

#define stage_3 0#define stage_2 1#define stage_1 2#define logout 3#define checkout 4#define menu 5#define browse_3 6#define browse_2 7#define browse_1 8#define preform_auth 9#define show_login_page 10

/* Useful proctype to select a URI at random */chan rchan = [0] of {byte};proctype random(){ do :: true -> atomic {printf("MSC: stage_3\n"); rchan!stage_3;} :: true -> atomic {printf("MSC: stage_2\n"); rchan!stage_2;} :: true -> atomic {printf("MSC: stage_1\n"); rchan!stage_1;} :: true -> atomic {printf("MSC: logout\n"); rchan!logout;} :: true -> atomic {printf("MSC: checkout\n"); rchan!checkout;} :: true -> atomic {printf("MSC: menu\n"); rchan!menu;} :: true -> atomic {printf("MSC: browse_3\n"); rchan!browse_3;} :: true -> atomic {printf("MSC: browse_2\n"); rchan!browse_2;} :: true -> atomic {printf("MSC: browse_1\n"); rchan!browse_1;} :: true -> atomic {printf("MSC: preform_auth\n"); rchan!preform_auth;} :: true -> atomic {printf("MSC: show_login_page\n"); rchan!show_login_page;} od}

SPDL-2 policy(Chapter 5)




SWIL metaprogram(Chapter 6)




O'Camlinterpreter

PROMELAprogram




SWILcompiler Verification

Result

SPINmodelchecker

If verification failed, edit original SWIL metaprogram

SWILinterpreter

SPDL-2compiler

OnlineInterfaceFirewalling

OfflinePolicy Creationand Analysis

Figure 6.3: Overview of the system outlined in Chapters 5, 6 and 7. Note that the bottom partof the diagram describes offline policy creation and maintenance while the upper part shows themain application datapath.

107

6.2. Overview Chapter 6. Stateful Web-application Interface Language

6.2.1 As Interface Modification

Recall that the interface exposed by a web-application was described in Section 2.4.6 as a setof functions of the form:


This interface is very generic, insisting only that clients send valid HTTP requests and guaran-teeing only that the application will generate valid HTTP responses. Section 5.3 described howa number of common attacks resulted from hidden assumptions not documented in the inter-face and how the attacks could be prevented by programming a suitable interface firewall. Thissection shows how the forgotten assumption behind forceful browsing attacks – that users caninvoke interface operations at any time – can be expressed using the same interface formalism.

Valid sequences of interface invocations are represented by a policy based on a finite stateautomaton. Transitions between states of the automaton are triggered by HTTP requests; thelack of a valid transition from a state indicates an error condition. Input HTTP requests arerepresented as elements drawn from a finite alphabetΣ using anabstraction functionof typerequest → Σ. The exact form of the alphabet and the abstraction function are policy-specific.More will be said about this later in Section 6.5.

Note that the input of the automaton is taken entirely from HTTP requests, ignoring HTTPresponses. The reason for this is convenience; it is much easier to parse HTTP requests andextract useful information (e.g. the target URI, query parameters and cookies) than it is to parseand extract useful content from the HTML payload contained within the HTTP responses. How-ever, it is possible to imagine a more complicated system which possesses a series of templatesor XPath queries which are matched against the HTML payload data and the results of whichare fed into the automaton, but for the sake of simplicity the remainder of this presentation willignore this possibility.

A policy is represented by an automaton(Q, q0, A, T ) whereQ is a set of states,q0 ∈ Q is aspecial initial state,A : request → Σ is the abstraction function andT : Q×Σ→ Q is a partialfunction which returns the next state given the current state and the abstract representation of arequest. For each combination of state and possible input there is either no successor state orone single successor state.

The policy can be imposed by an interface firewall in the style of Section 5.3 by first defininga number of types, functions and prolog-style predicates. First of all we require a mechanismto associate HTTP requests originating from the same session. There are several concrete tech-niques used in practice to achieve this but we represent the process abstractly by a functiongetsession : request → N which maps individual HTTP requests onto sessions representedby natural numbers. Several possible methods to track user sessions were described earlier inSection 2.4.5 and a concrete implementation will be discussed later in Chapter 7. Each ac-tive session is associated with a mutable state value stored on the firewall which is updatedas valid transitions occur. This updating is treated as a special side-effect of the predicateUpdateState(s , q ′) which updates the state value of sessions to valueq′.

Note that the sessions and their associated policy automata are maintained on the firewalland not directly accessible by the user or their browser. A user only possesses an unforgeablereference to a session which is obtained when they first access the application and which isstored in a cookie. Users cannot clone their sessions, since the session state is not stored ontheir computer. They can copy the session reference by sharing their cookie with others with

108

Chapter 6. Stateful Web-application Interface Language 6.3. SWIL Technical Details

the effect that multiple browsers would interact with the same session at the same time. Notethat this requirement to store per-session state is a major point of difference with the SPDL-2system described in the previous chapter. In practice sessions are likely to be timed out afterperiods of inactivity and their state garbage-collected with the effect that subsequent requestsfrom the same user will cause a fresh session to be created. More will be said about sessionmanagement later in Section 7.2.3.

The full list of predicates used in the interface firewall definition are summarised below:

SessionID(req , s) holds iff s is a valid session corresponding to the HTTP request objectreqi.e.s = getsession(req)

CurrentState(s, q) holds iff q is the current automaton state corresponding to the sessionnamed bys

Abstract(req , σ) holds iff σ = A req i.e.σ ∈ Σ is the abstract representation of the requestreq

Valid(q, σ) holds iff (q, σ) ∈ dom(T ) i.e. a valid transition exists in the transition function5

NextState(q, σ, q′) holds iff q′ = T (q, σ) i.e. q′ is the new state of the automaton

UpdateState(s, q′) holds always with the side-effect that the state of the automaton state cor-responding to sessions is updated toq′.

Figure 6.4 shows the general form of a firewall interface with URIs{ U1, . . . , Un } usingthe predicates defined above, necessary to protect applications from forceful browsing attacks.Two points are worth noting about the specification:

1. the identifiersq, q,′ , σ are bound locally in eachassume block; and

2. to avoid concurrency issues, eachassume block is evaluated in isolation, to prevent twonear-simultaneous requests reading the same initial state valueq.

6.3 SWIL Technical DetailsThis section describes SWIL policies in detail. This section assumes knowledge of PROMELA

and SPIN, first described back in Section 2.6. Section 6.3.1 describes the core language syntaxand is followed by Section 6.3.2 which introduces the notion of a well-formedprogram fragmentandprogram. Since SWIL is a low-level language, Section 6.3.3 introduces the high-level SWILMeta-programming System (SMS) based on an O’Caml embedding which greatly eases theproduction of SWIL policies. SMS comes complete with a library of common control sequenceabstractions which may be easily combined together to create complex SWIL programs.

6.3.1 SWIL

The abstract syntax of the language SWIL is shown in Figure 6.5. The language is derivedfrom PROMELA as used in the SPIN model checker with a few simple adjustments including (i)the removal of features in PROMELA allowing the expression of non-determinism; and (ii) theaddition of built-in primitives for handling HTTP request messages.

The main syntactic categories are commandsc and side-effect free expressionse. A programp consists of a set of global variable declarationsd, a set of labelled command blocksb and an

5The automaton is deterministic as indicated by the fact thatNextState is a function.

109

6.3. SWIL Technical Details Chapter 6. Stateful Web-application Interface Language

interface I {type request = . . .type response = . . .

U1(in request req, out response res)assume {

CurrentState(getsession(req), q),Abstract(req, σ),Valid(q, σ),NextState(q, σ, q′),UpdateState(getsession(req), q′)

}guarantee {}

. . .Un(in request req, out response res)

assume {CurrentState(getsession(req), q),Abstract(req, σ),Valid(q, σ),NextState(q, σ, q′),UpdateState(getsession(req), q′)

}guarantee {}

}

Figure 6.4: A web-application firewall interface with a URIs{ U1, . . . , Un } written using theformalism of Section 2.3. The identifiersq, q′, σ are considered to be bound locally in eachassume block.

110


initial command. All variables are initialised with a constant literal (either an integer, string,boolean or a special null request) and further assignments are restricted to values of the sametype. The infix binary operators+, - , * and / are defined on integers6, and and or onbooleans and the equality operator= is defined on all built-in types: integers, strings, booleansand requests.

The special commandx := NextRequest() assigns to the variablex the next re-quest sent by the user, directly corresponding to reading from a synchronous channel inPROMELA. The commandx := PeekRequest() is similar except it does notconsumetherequest; subsequent calls toPeekRequest() or NextRequest() will receive the samedata again. These two commands are similar to PROMELA commandsc?x andc?<x> de-scribed in Section 2.6.1. Request objects are also treated specially in SWIL. They can be as-signed to other variables and introspected with the specialGetField function. The expressionGetField( var , "x") wherevar is an identifier containing data of typerequest and"x" isa constant string returns the field namedx from var . By convention we say that every requestobject has a field calleduri which is the URI of the request. We also say that a request pa-rameter calledy can be accessed byGetField( var , "param.y") . Note that strings areconstant and immutable and can only be compared against other strings. In the translation intoPROMELA described later in Section 6.4, each unique string (including field names) is translatedinto a unique integer.

The commandx := native f( e1, . . . , ek) assigns to variablex the result of callingnative functionf with arguments given by expressionse1, . . . , ek. The implementation of thefunctionf must be written in every language targeted by the system; e.g. if targeting PROMELA

then the implementation will be written as a PROMELA proctype and if targeting O’Camlthen the implementation will be written as an O’Caml function. Typically a function imple-mented in PROMELA would employ non-determinism and be much simpler than the determin-istic O’Caml equivalent. Theproctype in PROMELA would likely be an abstraction of thecorresponding code written in O’Caml.

To understand the usefulness of this mechanism, consider a web-application which requiresusers to authenticate before accessing the rest of the application. Checking the username andpassword could be performed by a call to a native function taking two strings, representing theusername and password, and returning a boolean value, true if the credentials are valid and falseotherwise. In a PROMELA model we may represent this by a non-deterministic choice: eitherthe credentials match or they do not. In O’Caml we represent this as a deterministic concretefunction which looks up the username and password in the accounts database.

The rest of the commands are: (i) assignments of the formx := e which assign the re-sult of evaluating expressione to variablex ; (ii) sequencing with ‘; ’; (iii) conditionals withif then else ; (iv) skip which does nothing; (v)error which jumps to a built-in errorstate; and (vi)goto which jumps to another labelled block. The special error state jumped toby theerror command is equivalent to jumping to the following program fragment:

error_state:skip;goto error_state;

Note that no further requests are read (viaPeekRequest() or NextRequest() ), prevent-

6Note that should a divide-by-zero error occur, the program behaves as if theerror command has beenexecuted.

111


const ← integer | string | boolean | null (constant literals)

e ← x (variables)| const (constants)| not (e) (logical negation)| e1 〈op〉 e2 (binary infix operators)| GetField (x, string) (request field access)

c ← x := e (assignment)| x := NextRequest() (next)| x := PeekRequest() (peek)| x := native string(e1, . . . , ek) (native)| c1 ; c2 (sequencing)| if e then c1 else c2 (conditionals)| error (error)| skip (skip)| goto label (goto)

b ← label : c (block)

d ← val x = e (variable declaration)

p ← let d1 . . . dn and b1 . . . bn in c (program)

Figure 6.5: The Abstract Syntax of the Language SWIL.

ing the application from processing any further HTTP requests. There is no way to recover fromthis state except deleting the current automaton state and restarting from the beginning.

6.3.2 Well-formed Programs

Before describing a well-formed program we first introduce the concept of a well-formedpro-gram fragmentwhere a program fragment is defined to be a pair of variable declarations andblocks:

type fragment = d list × b list

A program fragment is said to be well-formed if the following constraints are met:

1. each variable is defined at most once;

2. each label is defined at most once;

3. every variable is associated with a single static type: one of integer, string, boolean orrequest;

4. every variable of type request (initialised tonull ) must be assigned to by aNextRequest() or PeekRequest() before aGetField in every possible exe-cution path within every block; and

112


5. every call to a native functionf must have the same number of arguments, same argumenttypes and same result type.

A program consisting of a program fragment and a command is said to be well-formed if thefragment is well-formed and also:

1. each variable is defined exactly once;

2. each label is defined exactly once; and

3. each label referenced by agoto is defined.

Rather than use a set of well-formedness rules, an alternative approach would be to employ atype system to achieve the same effect. A type system could be created which would allow pro-gram fragments to be combined together if their associated typing environments are compatible(e.g. enforcing the constraint that each variable has at most one definition).

6.3.3 The SWIL Meta-programming System

SWIL is a simple low-level language which does not directly support sophisticated mechanismsfor code-reuse. However rather than always writing programs entirely by hand it is possible tocombine together existing fragments of SWIL programs using a meta-program in a higher-levelprogramming language. This technique allows common interface patterns to be abstracted andeasily shared across applications. To achieve this goal, the SWIL Meta-programming Systemconsists of an embedding of the language SWIL in O’Caml allowing program fragments to begenerated and composed together to create complex SWIL programs. SWIL syntax is availableas a set of recursive disjoint union types and there are typeslabel , fragment and programcorresponding to label names, well-formed fragments and programs respectively.

The utility of this mechanism is demonstrated by way of examples. The rest of this sectiondescribes two functions which can be used to generate SWIL program fragments. Each functionis intended to capture the essence of (or ‘abstract out’) a common pattern of interaction with aweb-application.

The first function, calledsequence , has the following O’Caml signature:

sequence : uri list → label → label → fragment

The function abstracts a sequential interaction pattern in which a list of URIs ({U1 . . . Un})represented by the first parameter of typeuri list must be visited essentially in order (i.e.U1

beforeU2. . . ) but with limited support for backtracking. An example of the scheme is depictedgraphically in Figure 6.6. In the figure time runs horizontally and 4 application URIs labelledURI1, URI2, URI3, URI4 are represented vertically. As time progresses, the user browsesbetween the URIs in the sequence URI1, URI2, URI1, URI3, URI4, URI2, URI3, URI1, URI4represented by the arrows.

The code generated by thesequence function enforces the following rule: If the user hasvisited at some point during the current run of the sequence the URIUk wherek < n thenrevisiting any URI within the rangeU1 . . . Uk is permitted. However any attempt to visitUk+1

before a visit toUk will be blocked. To understand how this kind of interaction sequence mightbe useful, consider the e-commerce payment example first described in Section 6.1.1. Theuser has to fill in several pages of information (including payment and shipping details) beforebeing able to complete a purchase. The security policy created by thesequence function

113


URI1

URI2

URI3

URI4

time

Figure 6.6: Graphical depiction of a browsing pattern allowed by the program fragment gen-erated by the O’Camlsequence function. Four application URIs are represented vertically,time runs horizontally and the arrows indicate a path taken through the application by a user.

will prevent the user from skipping the payment stage and going straight for the dispatch ofgoods, preventing a possible forceful browsing attack. However the policy generated by thesequence function still allows the user to backtrack (through either links explicitly includedon the pages, entering URIs by hand, recalling bookmarks or using the browser back button)between already-visited pages in the payment procedure, useful to correct mistakes. The policyalso blocks any attempt to fetch a URI not mentioned in theuri list as this would also beambiguous i.e. should the application cancel the transaction or simply postpone it?

The two parameters of typelabel represent the entry and exit labels respectively. The se-quence is activated by an explicitgoto to the entry label and the fragment finishes by jumpingto the exit label when the final URI is successfully called. When composing together programfragments in the policy creation system, the system verifies that the resulting program is well-formed (i.e. the labels match up correctly etc.) using the rules described above in Section 6.3.2.

In SMS evaluating the expression

sequence [ "one"; "two"; "three" ] "entry" "exit"

generates a program fragment like the following, where the two variablestmp and req arefresh:

entry:tmp := 0;goto loop;

loop:req := ReadNext;if (GetField (req, "uri") = "one"){

tmp := 1;goto loop;

} else { skip };

114


tmp=3tmp=2tmp=1tmp=0

one

one

two

onetwo

three

error

elseelse else

"entry" "exit"

Figure 6.7: Automaton representing program fragmentsequence [ "one"; "two";"three"] "entry" "exit" . States are represented by circles and labelled arrows in-dicate state transitions where the label is the name of the consumed URI. Arrows without labelsindicate a transition which consumes no URI. Two conventions are used to preserve determin-ism. Firstly we insist that all the labelled arrows from each individual state must have distinctlabels and secondly we insist that if the source state has arrows with labels, these transitions arefollowed in preference before any unlabelled arrow transition.

if (GetField (req, "uri") = "two"){if (tmp < 1) { error } else { skip };tmp := 2;goto loop;

} else { skip };

if (GetField (req, "uri") = "three"){if (tmp < 2) { error } else { skip };tmp := 3;goto exit;

} else { skip };error

The implementation uses the integer counter variabletmp to store the highest URI index visitedso far. The labelentry marks the entrypoint to the fragment and the fragment is left either bytheerror command or a jump to the labelexit . Attempts to access forbidden URIs invokethe error command. The diagram in Figure 6.7 displays graphically an automaton whichcorresponds to this program fragment. Each state (represented by a circle) is associated with aparticular value of the variabletmp . State transitions (represented by the directed edges) arelabelled with the URI expected. The special labelelse signifies a transition that occurs whena URI appears which is not associated with any other edge. In every state (except the finalstate where the sequence is exiting) there is anelse label pointing to a special error state (inthe program fragment this corresponds with the commanderror ). Once inside the error statethere is no transition out again7.

7A user-friendly system might opt instead to allow the user to backtrack out of the error state.

115


onetwo

"entry" "exit"

Figure 6.8: Automaton representing program fragmentbrowse [ "one"; "two"]"entry" "exit" .

The second O’Caml function, calledbrowse , has the same signature assequence i.e.

browse : uri list → label → label → fragment

This function represents a free-form browsing pattern in which the user is allowed to visitany URI from the list specified in the first parameter. Like thesequence example, the twoarguments of typelabel specify entry and exit labels respectively. Control passes to the exit labelif the user fetches any URI not in the set specified by the first argument of typeuri list . Thefinal URI is handled specially; rather than being consumed by the generated program fragment(as all URIs discussed so far have been) it is deliberately left unconsumed, available for thefollowing program fragment.

The program fragment generated by evaluating the following expression in O’Caml:

browse [ "one"; "two" ] "entry" "exit"

looks like the following, where the variablereq is fresh:

entry:req := PeekRequest();if (GetField (req, "uri") = "one"){

req := ReadNext();goto entry;

} else { skip };if (GetField (req, "uri") = "two"){

req := ReadNext();goto entry;

} else { skip };goto exit;

It operates by first peeking to see if the next request has a URI of eitherone or two . If ithas, the request is discarded by callingReadNext() . Otherwise the request is left and controlpasses to the labelexit . The associated (and very simple) automaton is displayed graphicallyin the diagram within Figure 6.8. It has only a single state and all labelled edges (correspondingto the URIs within the URI list) point back to this single state.

116

one

two

Chapter 6. Stateful Web-application Interface Language 6.4. Translation into PROMELA

machine

user

fnf1

input output

f_n_outputf_1_output

f_1_input f_n_input

Figure 6.9: General structure of the translation of an automaton into PROMELA. Circles rep-resent PROMELA proctypes while labelled arrows represent channels: the arrow indicatesdirection while the label gives the channel name.

6.4 Translation into PROMELA

This section describes how a SWIL policy may be translated into PROMELA for analysis by theSPIN model checker. An introduction to PROMELA and SPIN was given earlier in Section 2.6.1and knowledge of both shall be assumed throughout this section.

Recall that a PROMELA model consists of a finite number of processes (defined throughthe proctype keyword) connected together by simply-typed channels with optional buffer-ing. Each process body may be thought of as a set of labelled blocks with control-flow han-dled using thegoto keyword. The features and syntax of SWIL are intentionally similar toPROMELA with only a few specific differences notably (i) SWIL policies are deterministicwhereas PROMELA models may be non-deterministic; and (ii) models described here havesupport for HTTP request types and native functions, examples of the use of which will bedescribed later in Section 6.6.

After translation into PROMELA the general structure of the automaton produced is depictedgraphically in Figure 6.9. Each PROMELA proctype (process) is represented by a circle.Circles are connected by labelled arrows: the arrow gives the channel name and the arrow-headindicates the direction of flow of data; i.e. it points from sender to receiver. The bulk of thecode (i.e. all the labelled blocks) is contained within theproctype namedmachine . Theuser is represented by an emptyproctype labelleduser with two channels: one for sendingrequests to the application and the other for receiving a boolean result:true indicating therequest was accepted by the policy andfalse indicating the program has entered an error state.Each native function called by the automaton becomes an emptyproctype , labelledf1 . . . fn

in the diagram. Each of these native functions must be implemented, perhaps by a processwhich reads its inputs, ignores them and non-deterministically generates a random output. Theexact implementation depends on the nature of the analysis being performed, an example isprovided later in Section 6.6.1.

The mechanical translation into PROMELA requires two passes. The first pass computes thefollowing:

1. the types of all variables used in the program

2. the set of all request fields accessed by calls toGetField

allfields = {field 1, . . . , field k}

117

6.4. Translation into PROMELA Chapter 6. Stateful Web-application Interface Language

3. prototypes for all native functions (f1 . . . fn)

allnatives = { f1(a11 : t11, . . . , a1q1 : t1q1) : t1qreturn ,. . . ,fn(an1 : tn1, . . . , anqn : tnqn) : tnqreturn }

4. a unique integer for each string used in the program

hash : string → integer

Since PROMELA is conventionally fed through the C pre-processor a#define is created foreach string e.g. the string “foo” may be represented by the following:

#define FOO 0

The request fields are computed because PROMELA HTTP requests areflattenedinto individualvariables, one for each field. PROMELA does not support a string type; the functionhash mapsconstant strings onto simple integers (in the above example “foo” was mapped onto 0).

The second phase performs the actual translation via the set of recursive functions:T [[−]],D[[−]], E [[−]],O[[−]], C[[−]],X [[−]],P [[−]] over types, declarations, expressions, operators,commands, native functions and programs respectively. The first five of these are displayed inFigure 6.10.

The first functionT [[−]] translates simple (i.e. not HTTP request) types (Figure 6.10). Sim-ple PROMELA types were first described in Section 2.6.1. As previously noted, HTTP mes-sages are translated into PROMELA by flattening them into individual fields. The first transla-tion pass computed the complete set of HTTP request fields accessed throughout the program:allfields = {field 1, . . . , field k}. This information is used by the translation of variable decla-rations through the functionD[[−]] (Figure 6.10). Note that each field is assumed to have typestring and defaults to the translation of the constant string “”. Also note that a request calledx with a field calledf is transformed intox f ; and it is assumed that variablex f does notalready exist. Violations of this rule must cause a translation error. Expressions are translatedstraightforwardly into PROMELA via the functionE [[−]] (Figure 6.10) where the functionO[[−]]converts binary operators. Commands are translated via the functionC[[−]].

Notice in particular how variables of type request are decomposed into a set of variables,one for each individual possible field access. This affects both the assignment, next and peekrules. In theNextRequest rule the individual fields are read from a channel labelledinput(displayed graphically in Figure 6.9) which is a unit-length buffered channel. The processes rep-resenting the user (user ) and the policy (machine ) are kept in lock-step using synchronouscommunication over theoutput channel. Calling a native function requires two operations: amarshalling step where the arguments are evaluated and sent over a request channel (for func-tion f namedf input ) and secondly a boolean result is read from a result channel (namedf -output ). Theerror command is implemented by jumping to a special block callederrordescribed later.

Labelled blocks are translated trivially via the functionB[[−]]:

B[[label: c]] → label: C[[c]]

118

Chapter 6. Stateful Web-application Interface Language 6.4. Translation into PROMELA

T [[integer ]] → byteT [[string ]] → byteT [[boolean]] → bool

D[[val x = e : request ]] → T [[string ]] x field 1 = E [[“”]];. . .T [[string ]] x field k = E [[“”]];

D[[val x = e : t]] → T [[t]] x = E [[e]]

E [[x]] → xE [[string x]] → hash(x)E [[not(e)]] → ! (E [[e]])E [[e1 op e2]] → (E [[e1]] O[[op]] E [[e2]])E [[GetField (x, string y)]] → x y

O[[and ]] → && O[[or ]] → ||O[[+]] → + O[[−]] → −O[[<]] → < O[[>]] → >O[[=]] → ==

C[[x := y : request ]] → x field 1 := y field 1; ...C[[x := e]] → x = E [[e]]C[[x := NextRequest() ]] → input?x field 1, ..., x field kC[[x := PeekRequest() ]] → input?<x field 1, ..., x field k>C[[x := native f(e1, . . . , en)]] → f input! E [[e1]], ..., E [[en]];

f output?xC[[c1; c2]] → C[[c1]]; C[[c2]]C[[if e then c1 else c2]] → if

:: ( E [[e]]) -> {C[[c1]]}:: else -> {C[[c2]]}fi

C[[error ]] → goto errorC[[skip ]] → skipC[[goto label ]] → goto label

Figure 6.10: The PROMELA translation functionsT [[−]],D[[−]], E [[−]],O[[−]], C[[−]].

119

6.5. Dynamic Execution Chapter 6. Stateful Web-application Interface Language

Every native function is translated into a skeletonproctype via the functionX [[−]]:

X [[native f(a1, . . . , an)]]→proctype f(chan input; chan output) {loop:

input?arg 1, ..., arg n;...output!true;goto loop;

}

This skeleton does nothing except unmarshal its input arguments and return the single resulttrue . When analysing a realistic system it is expected that this skeleton will be replaced withsomething more useful; an example of this will be described later in Section 6.6.1.

Finally the functionP [[−]] completes the translation and is displayed in Figure 6.11. Thisfinal translation mostly adds necessary boilerplate: the definition of the globalerror label, alltheproctype and channel definitions and finally theatomic block which instantiates eachproctype with the appropriate channels. Theinit block is a PROMELA idiom similar to themain function in the C programming language.

At this point a syntactically correct PROMELA model is available, albeit one which exhibitsno interesting behaviour whatsoever; if executed themachine proctype would block on thefirst attempt to read a request from theuser proctype . To make the system more useful thefollowing steps must now be performed:

1. theuser proctype should be completed with a model of user behaviour to analyse;

2. each native functionproctype should be filled in with some logic specific to the appli-cation domain;

3. properties of interest should be devised and then analysed with SPIN.

In many cases the model of the user will be completely non-deterministic i.e. the user can doanything. This allows us to check properties of the form “this can never happen, nomatter whatthe user does”. Other models of the user can be written in order to check that “this is stillpossible if the user acts sensibly” i.e. the policy has not needlessly broken the application.

6.5 Dynamic ExecutionSWIL programs are designed to be easy to translate into PROMELA for off-line analysis and easyto be interpreted by an O’Caml program running on an application-level firewall. The O’Camltranslation is broadly similar to the PROMELA one; each (deterministic) PROMELA proctypesimply becomes an O’CamlThread communicating viaEvent channels (O’Caml’sThreadandEvent handling is based on Reppy’s Concurrent-ML [133]). Since all non-determinism inSWIL programs must be contained within native function calls, only these need to be writtenmanually in O’Caml. We make the additional restriction that the O’Caml implementations ofthe native functions are purely functional (i.e. free of side-effects). Purely functional nativefunctions allow speculative execution by cloning the state and then feeding the automaton addi-tional inputs to see how it behaves, without worrying about unintended side-effects. More willbe said about this in the next section.

120

Chapter 6. Stateful Web-application Interface Language 6.5. Dynamic Execution

P[[let d1, . . . , dn and b1, . . . , bm in c]]→D[[d1]]; . . . ; D[[dn]];proctype user(chan output) {

do :: true -> skip; od}proctype machine(chan input;

chan f 1 input; chan f 1 output;...chan f n input; chan f n output) {

T [[string ]]scratch field 1, ... scratch field k;C[[c]]

error:output!false;input?scratch field 1, ... , scratch field k;goto error;B[[b1]]... B[[bn]]

}X [[f1(a11 : t11, . . . , a1q1 : t1q1) : t1qreturn ]]...X [[fn(an1 : tn1, . . . , anqn : tnan) : tnqreturn ]]chan input = [1] of {T [[string ]], ..., T [[string ]]};chan f 1 input = [0] of {T [[t11]], ..., T [[t1q1 ]]};chan f 1 output = [0] of {T [[t1qreturn ]]};...chan f n input = [0] of {T [[tn1]], ..., T [[tnqn ]]};chan f n output = [0] of {T [[tnqreturn ]]};

init {atomic {

run f 1(f 1 input, f 1 output);...run f n(f n input, f n output);run user(input);run machine(input,

f 1 input, f 1 output,...,f n input, f n output);

}}

Figure 6.11: The definition of the functionP [[−]].

121

6.5. Dynamic Execution Chapter 6. Stateful Web-application Interface Language

Program state is represented by the simple type

type state = (id , id expr) Hashtbl .t

whereid is the type of identifiers,id expr the type of expressions andHashtbl .t is a hashtabletype constructor.

As with the PROMELA translation, user behaviour (proctype user in PROMELA) andall native functions need to be defined by hand. The thread running the user code looks like thefollowing:

let rec user_thread () =let request = read_from_user () inlet request’ = make_request_object request inEvent.sync(Event.send output request’);match (Event.sync (Event.receive input)) with| OK -> begin

send_to_webserver request;let response = read_from_webserver()insend_to_user (transform response);user_thread();

end| Error -> raise Error_Exception

The functionread from user reads a raw HTTP request from the user and converts theresult into a special request object – containing only those fields accessed by calls toGetField– before sending it on the channeloutput connected to the main program thread. This stepcorresponds directly to using the abstraction function mentioned back in Section 6.2.1.

The result (read from channelinput ) is eitherOKif the request was accepted orErrorif the program entered the error state. If an error occurs an exception is thrown which haltsthe program. Otherwise, the request is forwarded to the back-end webserver viasend -to webserver . The response is read back throughread from webserver and filteredthrough a special functiontransform (described in the following section) before being sentto the user viasend to user .

6.5.1 Dynamic Response Transformation

Recall how an interaction between a user and a web-application consists of a series of HTTPrequests and HTTP responses, requests containing parameters and responses containing HTMLdocuments. Although the user can generate any HTTP request at any time (e.g. by recallinga bookmark or simply entering a URI by hand) the HTML within the response contains hintsfor further HTTP requests as links and forms. There is an unwritten contract between theapplication and the user which states that the user is allowed to invoke any of these operations;otherwise, why would they be present? Unfortunately if a SWIL policy is being imposed by afirewall then it is possible for the application to generate links and forms whose use would berejected by the firewall.

In the generated O’Caml code described above in Section 6.5, the special functiontransform parses HTTP response messages containing HTML and filters all those formsand links which, if clicked on, would definitely be rejected by the installed security policy.

122

Chapter 6. Stateful Web-application Interface Language 6.5. Dynamic Execution

The result is that the user sees a restricted view of the application, where links and forms aredeleted if selecting them would certainly fail. As a side-effect, this makes SWIL policies usefulfor more than simply enforcing security properties; for example, parts of web-sites may be se-lectively disabled in a user-friendly manner by installing simple policies which block requestscorresponding to those parts of the site.

A very simple conservative analysis can be used to determine whether a particular link orform should be removed, using the information known when the page is generated (i.e. beforeany extra information is filled in by the user). Links and forms were first described back inSection 2.4.6. In both cases they may be represented by a type

type link = form = uri × parameters

where

type parameters = (string × string) list

The primary difference between links and forms is the origin and purpose of theparameters.In the case of a link the parameters are all contained within the HTML and not displayed at allwhen the page is rendered. In normal operation (i.e. assuming the user is not examining theHTML in a text editor) the only opportunity the user gets to see the parameters is when the userclicks on the link. When a link is clicked, a web-browser typically copies the link to the URIbar8 as the new page is loaded. Like links, forms contain some parameters which are invisibleand not intended to be edited (the “hidden” form elements) but they also contain parameterswhich the user is supposed to modify, through text input controls. Therefore when a page isbeing transformed by the application-level firewall each link and form may be considered to bean instance of type

uri × (string × (string option))list

where the parameters are key-value pairs, the keys are of typestring while the values are oftypestring option where the valueNone indicates the user is supposed to fill this value in andthe valueSome x indicates the value is known already.

The analysis is performed by duplicating the current state of the firewall and speculativelyexecuting the program as if the request had been sent as-is by the user. The speculation abortsimmediately if aGetField command attempts to access any part of the request which isunknown (i.e. aNone) value. Therefore the result of the speculation can be any one of threepossibilities: (i) the request was accepted; (ii) the request was rejected; or (iii) insufficientinformation is known to decide between (i) and (ii). In the case of both (i) and (iii) the link orform is left intact; only if the request was definitely rejected is the link or form deleted from thepage.

It should be noted that removing links or forms using this technique might lead to userconfusion if some of the remaining text or images on the page refer to the deleted elements. Ifthis happens then either the technique should not be used or a more application-specific userinterface transform – which also removes these remaining problematic elements – should beapplied instead.

8Some web-browsers allow the URI bar to be hidden from view using Javascript code. Sometimes web-browsers are embedded into other applications as components without the URI bar. For simplicity we ignorethese cases.

123

6.6. Example Chapter 6. Stateful Web-application Interface Language

authentication

menu

checkoutbrowse

auth_l:

menu_l:

brwse_l: chkout_l:

Module URIsauthentication show login

do authlogout

menu menucheckout checkout

checkout {1,2,3 }browse browse

browse {1,2,3 }

Figure 6.12: General structure of the e-commerce application described in Section 6.6. [Left]:the application consists of 4 modules displayed along with entrypoint labels. [Right]: table liststhe URIs which logically belong in each module.

6.6 ExampleIn this section a simple e-commerce application is described and a fine-grained SWIL policyis built which represents the acceptable order of URI invocations within the application. Theapplication has the following characteristics:

1. users are required to login at the very beginning;

2. once authenticated, users are presented with a menu of further options;

3. users can choose to browse around the site adding items to their shopping cart; and

4. when finished shopping, there is a 3-step checkout scheme, similar to that mentioned backin Section 6.1.1.

The general structure of the application is described in Figure 6.12. The leftmost part of thefigure shows how the application may be divided into four logical modules, labelled “authenti-cation”, “menu”, “browse” and “checkout”. Each module will correspond to a SWIL programfragment with entrypoint labelsauth l , menu l , brwse l andchkout l respectively. Therightmost part of the figure contains a table which lists the URIs contained within each module.The syntaxcheckout {1,2,3 } is used as a compact way of representing the three stringscheckout1 , checkout2 andcheckout3 . Note that, as explained in Section 2.4 URIs areof the formscheme://authority/path?query ; for brevity single words are used forURIs in the examples.

The first application module, authentication, involves three URIs:show login , do -auth and logout . For the user to log into the application, the first two of these URIs arerequired: the first to return an HTML login page to the user and the second to process the user-supplied username and password. This procedure can be modelled with a SWIL fragment likethe following:

auth_l:x := ReadNext;if (GetField(x, "uri") <> "show_login")

then { error } else { skip };x := ReadNext;

124

scheme://authority/path?query

Chapter 6. Stateful Web-application Interface Language 6.6. Example

if (GetField(x, "uri") <> "do_auth")then { error } else { skip };

t := native("check_authentication",GetField(x, "param.username"),GetField(x, "param.password"));

if (t) { goto menu_l; } else { error }

This program fragment expects two requests in order with URIsshow login anddo authrespectively. The first corresponds to the user fetching the page with the login window whilethe second is fetched when the user enters their username and password and presses the loginbutton. The second request assumes the existence of parametersusername andpasswordwhich are sent to the native functioncheck authentication . If this native function re-turns false then the application enters the error state, otherwise it jumps to the labelmenu l ,representing the menu module.

The menu module is very simple. It presents a list of options to the user and can be modelledwith the following short program fragment:

menu:x := ReadNext; uri := GetField(x, "uri");if (uri = "menu") then { skip } else { error };

x := ReadNext; uri := GetField(x, "uri");if (uri = "logout") then { goto auth_l }

else { skip };if (uri = "checkout") then { goto checkout_l }

else { skip };if ( (uri = "browse1") or

(uri = "browse2") or(uri = "browse3") ) then { goto brwse_l }

else { skip };error

The user is first expected to request themenu URI which displays the menu HTML itself.Afterwards if the user fetches the URIlogout then control jumps to the labelauth l , theauthentication module. If the user fetches the URIcheckout then control jumps to the labelcheckout l in the checkout module. The last option is to browse the product catalogue; ifthe user requests any of the URIsbrowse 1, browse 2 or browse 3 then control jumps tothe labelbrowse l in the browse module.

The browse module, corresponding to labelbrwse l is easily handled using thebrowseSWIL generating function described earlier in Section 6.3.3. Unlike the specific example dis-played graphically in Figure 6.8, this application allows the user to browse around pages namedby URIsbrowse_1 , browse_2 andbrowse_3 . In the meta-programming system the ex-pression:

browse [ "browse_1"; "browse_2"; "browse_3" ]"brwse_l" "menu_l"

generates a program fragment with entrypointbrwse l which allows the user to move betweenthe URIsbrowse 1, browse 2, browse 3 at random. When the user requests a differentURI, control jumps to the labelmenu l defined above.

125

browse_1

browse_2

browse_3


show_login

do_auth

browse{1,2,3}

menu

checkout

checkout1

checkout2

checkout3menu

logout

checkout2

checkout1

checkout1

browse{1,2,3}

1. authentication

2. checkout

3. menu4. browse

Figure 6.13: Graphical depiction of the automaton described in Section 6.6. Each state isrepresented by a circle. The start state is marked by a double circle. The state with the crossrepresents the call to the native functioncheck authentication . For clarity the error stateis not represented on the diagram.

The final module of the application is the checkout module which can be handled by theprogram fragment generated by evaluating the following expression in the meta-programmingsystem:

sequence [ "checkout_1"; "checkout_2"; "checkout_3" ]"checkout_l" "menu_l"

This expression evaluates to a program fragment which has a similar form to the example inFigure 6.7, with different URIs and label names. A detailed diagram of the resulting automatoncan be seen in Figure 6.13. The states in the diagram (represented by circles) are dividedinto 4 groups corresponding to the 4 modules of the system. The start state is highlightedwith a double circle. Each transition is signified by a labelled edge, the label being the URIexpected. The state marked with the cross represents the call to the native functioncheck_authentication . Not shown on the diagram is the error state which the machine jumps to ifit receives an unexpected URI or if thecheck_authentication function returnsfalse .

126

check_authentication




6.6.1 Analysis with SPIN

The translation of the SWIL program into PROMELA results in a skeleton; leaving the processescheck authentication anduser undefined. The functioncheck authenticationrepresents the process for determining whether a particular username and password is validwhile user represents the behaviour of a user interacting with the system. This section de-scribes how interesting properties of the automaton can be mechanically verified using the SPIN

model checker by implementing theseproctypes and writing some auxiliary code.Recall how the PROMELA translation in Section 6.4 flattened requests into a set of variables,

one for each distinct request field access via calls toGetField . In the following sectionsrequests are therefore triples ofusername , password anduri . Each of these is a string inSWIL mapped onto byte constants in PROMELA (T [[string ]] → byte). Although URIs withinthe program become unique integers, a series of#define s are created allowing the use ofsymbolic names throughout the examples in this section.

For convenience, a specialproctype and channel are introduced using the following code:

chan rchan = [0] of {byte};proctype random(){

do:: true -> rchan!menu;:: true -> rchan!logout;...od;

}

This process runs forever in a loop, non-deterministically selecting a URI (represented by sym-bolic namesmenu, logout , . . . ) and sending it on the channelrchan . This can then be usedas the basis for a general model of a user, capable of invoking interface functions at random.

1. Error state is non-recoverable and absence of livelock

This section describes how to simultaneously verify two desirable properties: the inability torecover from the error state and the absence of livelock. Entering the error state is intendedto be a non-recoverable operation that happens when the user sends a request not anticipatedby the policy. The error indicates a mismatch between the user’s model of the applicationand the policy designer’s model of the application. For safety it is important that the usersession is not continued. Livelock occurs in the shopping application example if the automatonenters an infinite loop ignoring all requests sent by the user. The consequences of livelock aresevere: from the point of view of the user the application would appear to halt while in fact theautomaton would waste all available CPU-cycles on the application-level firewall.

To check for livelock with SPIN it is first necessary to mark a set of program states asprogressstates where infinite loops are only allowed if they go through at least one of these spe-cial states. Figure 6.6.1 shows PROMELA code representing a non-deterministic user processin which the first state in the main loop of theuser proctype is marked as a progress state.Note that the variableuri holds a single byte value representing a constant string in the originalSWIL program (recall that in SWIL all strings are static and constant). Thisproctype loopsforever sending random URIs (read from the channelrchan ) on its output channel. The user-name and password are left as0 and subsequently ignored by thecheck authenticationproctype described below. The variableresult keeps track of whether themachine has

127

username

password

uri


proctype user(chan input; chan output){bool result = true;byte uri;

progress_loop:if:: result -> input?result;:: else -> input?false;fi;rchan?uri;output!0, 0, uri;goto progress_loop;

}

Figure 6.14: A PROMELA representation of a user which loops forever reading random URIsand writing them to the output channel. The main loop is marked as aprogressstate indicatingthat infinite loops are only allowed if they pass through this state.

entered an error state. If it has then all future results (read from theinput channel) are ex-pected to befalse , since it should not be possible to recover from the error state. If themachine is able to recover from an error state then this process will be able to halt in anin-valid end-state(in SPIN terminology) i.e. one blocked attempting to read afalse value fromthe input channel when it contains atrue value. Invalid end-states were first described inSection 2.6.3.

Thecheck authentication proctype is written as follows:

proctype check_authentication(chan input; chan output){byte username, password;

loop:input?username,password;if:: true -> output!true;:: true -> output!false;fi;goto loop;

}

This proctype loops forever reading usernames and passwords, ignoring them and non-deterministically choosing whether the authentication succeeded or failed.

Once theseproctype s have been defined the two properties can be verified by SPIN by

1. checking for the absence of invalid end-states which confirms the special SWIL errorstate is non-recoverable (i.e. nomatter what actions the user takes and whether or not theyever properly authenticate); and

2. checking for the absence of non-progress cycles (non-progress cycles were first describedin Section 2.6.3) which confirms the policy never gets stuck in a loop, ignoring user input.

128


2. Authentication cannot be bypassed

It is useful to verify that users must properly authenticate (i.e. have a valid username and pass-word) before being able to use the application. Put another way we desire that users who do notproperly authenticate cannot do anything other than attempt to log in.

The first step is to write thecheck_authentication proctype as follows:

proctype check_authentication(chan input; chan output){do:: input?username,password -> { output!false; }od;

}

This process reads in a username and password and always outputs the valuefalse , as if theusername and password are always wrong. The second step is to write theuser proctypeto represent possible user behaviour. Theuser proctype may be written as follows, whereSHOWLOGIN, DOAUTH, CHECKOUT, CHECKOUT2, CHECKOUT3correspond to the strings“show login”, “do auth”, “checkout”, “checkout2”, “checkout3” mapped to unique integersusing#defines by the PROMELA translation described earlier in Section 6.4:

bool failure = false;proctype user(chan output; chan input){

bool scratch;input?scratch;do:: true -> output!0,0, SHOW_LOGIN; input?scratch;:: true -> output!0,0, DO_AUTH; input?scratch;...:: true -> output!0,0, CHECKOUT; input?false;:: true -> output!0,0, CHECKOUT2; input?false;:: true -> output!0,0, CHECKOUT3; input?false;od;

}

The two0 parameters represent the username and password which are totally ignored by thecheck_authentication process. The input channel returns a boolean value:true if therequest is valid andfalse otherwise. Note how thisproctype uses non-determinism tomodel every possible sequence of URIs sent to the application. The two URIsSHOW_LOGIN,DO_AUTHare the only ones thatmay succeed, since neither requires authentication. Notehowever that if the user has already caused the system to enter an error state then they shouldfail. For the rest of the URIs, we require theyalwaysreturnfalse . If any of these URIs everreturnedtrue it would indicate the user managed to access the application without properlyauthenticating first.

The property we set out to prove can now be verified by mechanically checking the resultingprogram has no invalid end-states.

3. Checkout must be completed once begun

Once a user has added items to the shopping cart they may begin the checkout sequence, arrang-ing payment and delivery details before finally confirming the transaction. The SWIL program

129



SHOW_LOGIN

DO_AUTH


described in Section 6.6 aimed to ensure this sequence could not be interrupted i.e. the usershould be prevented from leaving the sequence partly completed.

To verify this, the user is represented by the same code used in Section 6.6.1, in Figure 6.6.1.The code non-deterministically chooses URIs (from therchan channel) and fires them at theautomaton, keeping track of whether the system has entered the error state.

Theproctype machine needs to be modified, with the following snippet of code addedat the beginning of the checkout procedure:

assert(!in_checkout);in_checkout = true;

At the end of the checkout routine the following snippet is added:

assert(in_checkout);in_checkout = false;

Finally, the variablein checkout is declared at the beginning of the program:

bool in_checkout = false;

The desired property – that the checkout sequence is non-interruptible once begun – can nowbe verified by asking SPIN to check the assertions always hold. Note we are partially dependingon the structure of the application to justify this claim. If the user leaves the sequence part of theway through then we rely on the fact that the user will always be able to return to the menu andrestart the sequence. Therefore if the sequence is interruptible SPIN will be able to find an errortrace where the user enters the sequence again, after interrupting it the first time, triggering theassertion failure.

6.6.2 Scalability

This section discusses the applicability of the techniques described in this Chapter to larger e-commerce websites. For expository purposes the example application described in this Chapterwas kept small and simple and used only 12 distinct URIs; a realistic commercial site is likelyto use many more.

In the example described here, users were required to log on before being able to access anypart of the site (apart from the login screen). A realistic commercial site is likely to allow usersquite a lot of freedom to browse the site before being forced to log in. Not only is this moreconvenient for the user but it also allows third-party search engines to index the site freely.Rather than forcing users to log on when it becomes strictly necessary (e.g. when about tomake a purchase), commercial sites oftenencourageusers to log on earlier in order to receivepersonalised recommendations. A realistic policy has to cope with all of these eventualities.Since the authentication step can happen (almost) at any time, the effect is to multiply up thenumber of states in the final machine. However, the effect of this on the policy document itselfis mitigated using the metaprogramming system– the authentication steps can be wrapped up ina function in a similar way to the example functionsbrowse andsequence .

As already indicated, a realistic e-commerce site is likely to be much larger than the toyexample described here. Much of this size difference is likely to stem from the size of theproduct catalogue: the in the example here there were only three product URIs. However theeffect of this expansion can be mitigated by grouping all the product URIs together and treating

130

Chapter 6. Stateful Web-application Interface Language 6.7. Related Work

them as a single automaton input. This avoids having to maintain a manual list of all theproducts in the policy specification and reduces the number of states in the policy automaton.

A realistic site is likely to have a set of sub-applications dealing with issues such as (i)managing account details; (ii) creating a wish-list; and (iii) writing reviews of products. It isenvisaged that each of these could be represented by small a automaton in a similar manner tothe “checkout” procedure in the example of this Chapter.

In summary, a realistic site will certainly require a larger, more complicated policy specifi-cation than that presented here. However, provided that chunks of the application’s URI-spacecan be grouped together (e.g. an entire product catalogue) and provided that good use is madeof the metaprogramming system, it should still be possible to have a reasonably concise policycovering a large application.9

6.7 Related Work

Our work directly exploits five strands of research; the main novelty is in their combination. Thestrands are: (i) model-based approaches to software development and analysis; (ii) describinginterfaces using automata; (iii) enforcing security policies dynamically on web-applications;(iv) meta-programming techniques; and (v) dynamic user interface transformation. Each ofthese will be discussed in the following sections. Additionally, Graunke et al [76] proposed asystem for automatically restructuring programs for the web; this will also be discussed.

6.7.1 Model-based approaches to software development and analysis

A model is a finite abstraction which is intended to capture some of the essential properties ofa system. Described earlier in Section 2.6, model-checking [42] – the process of automaticallyverifying properties of such a model – is gaining in popularity as a software verification method.However, creating a useful model of a software system is a difficult task. Software systemsoften have large numbers of states and an abstraction must be carefully chosen to minimise theresulting number of states in the model (in the worst case the number of states is proportional tothe time taken to verify) while still remaining faithful enough to be able to verify the propertiesof interest.

Producing models from software

There have been many attempts to automatically translate source languages into models, a pro-cess known asmodel-extraction. Systems have been built for languages including Java [83],Ada [56] and C [88]. Compiler techniques such as partial evaluation and program slicing arecommonly used to reduce the complexity of the models created by removing aspects of theapplication behaviour unrelated to the property of interest.

Systems vary by how much the user is involved in the model extraction and checking pro-cess. Two systems shall be described: Bandera and SLAM. Bandera [44] is a generic softwaremodel-checking tool for Java code. Bandera contains an abstraction library which the usermust use to select appropriate abstractions for individual program variables. For example aJavaVector object (a dynamic array) may be modelled by various lengths of finite buffer.The simpler the model chosen the faster the model-checking process will be. However, if themodel-checker fails to verify the desired property it might be necessary to refine the modelusing some longer length buffers at the cost of a slower model-checking process.

9One may argue that, if the resulting policy is too big, then the application is fundamentally too complexanyway.

131

6.7. Related Work Chapter 6. Stateful Web-application Interface Language

In contrast to Bandera which attempts to verify whole Java programs, the SLAM [17] projectat Microsoft aims to mechanically check that library interfaces are correctly used by C pro-grams. SLAM operates by first translating a C program and a library-related safety propertyinto a finite-state C program with the same control-flow but only boolean variables, related tothe property being checked. The program has a special error state which corresponds to a vi-olation of the safety property (like that triggered by the SWIL commanderror ). Once theabstract program has been created, a model-checker determines if the error state can be reachedthrough any possible path through the program. If an error path is found it is related back to theoriginal C code. Symbolic computation and a theorem prover are used to determine whetherthis path corresponds to an actual error (i.e. a bug) or whether the path is an artifact of the ab-straction process. If the latter than the model is refined and SLAM is executed again. Thereforeusing SLAM is an iterative process which continues until one of three things happen (i) theautomatic refinement step fails (requiring user input); (ii) an actual error is discovered; or (iii)the code is pronounced safe, with respect to the specified safety property.

Producing software from models

Rather than starting with complicated software and attempting to extract a suitable model fromit, some researchers have approached the problem from the other direction and attempted totranslate models into implementations. Early work in this area includes a system [112] whichallows PROMELA specifications to be transformed directly into a C program, with the addi-tion of a scheduler, random number generator (to handle non-determinism), timeout and I/Omechanisms.

Model-Carrying Code

Model-Carrying Code [145] (MCC), inspired by earlier work on Proof-Carrying Code(PCC) [119] is a proposal where the code producer pairs the implementation (in binary form)with a high-level model of its “security-relevant” behaviour. The code consumer can staticallycheck (at install-time) the model against its security requirements (perhaps through model-checking) and then execute the code while dynamically checking it against the model in themanner of Schneider et al [142].

A similar approach was taken by Madhavapeddy et al [114] who proposed a special-purposepolicy language called Stateful Syscall Policy Language (SSPL) which described a high-levelmodel of the acceptable system calls made by a Unix process. Models written in SSPL couldbe analysed statically and were enforced dynamically through Unix system call monitoring andinterception.

Relevance to this work

SWIL policies are abstract models written in a language similar to PROMELA, the input lan-guage of the SPIN model checker. There are a few key differences between PROMELA andSWIL notably that SWIL has built-in types and functions for processing HTTP requests andSWIL programs are essentially deterministic, with all non-determinism pushed into calls to na-tive functions. SWIL is designed to be a half-way house between a modelling language likePROMELA used to create abstract, non-deterministic models and an implementation languagelike O’Caml which is used to create concrete, deterministic code. No attempt is made here togenerate SWIL code automatically; rather we take the view that manually specifying the pol-icy is both useful for documentation and often inevitable, especially when the source code toapplications is not available.

132


The system proposed here is closest in spirit to Model-Carrying Code: SWIL policies model“security-relevant” behaviour insofar as they relate to forceful-browsing attacks. Policies arestatically analysed before ultimately being dynamically enforced. The primary difference is thecontext of use; MCC is intended to bridge a gap of understanding between distrusting code pro-ducers and consumers who may have conflicting goals. In contrast, the goals of web-applicationcode producers and SWIL policy writers are assumed to be the same; neither wishes an appli-cation to be vulnerable to forceful-browsing attacks.

6.7.2 Describing Interfaces with Automata

Alfero and Henzinger propose describing interfaces as automata [46] in order to capture thetemporal behaviour of interfaces. They use automata both to specify theinput assumptionsand theoutput guaranteesof an interface. They define interface compatibility optimistically:interfaces are said to be compatible if there is a possible environment in which they can worksuccessfully together.

In a similar theme to Interface Automata, typestate checking [152] is

a compile time program analysis technique which enhances program reliability bydetecting type-correct applications of operations which are non-sensical in theircurrent context

A typestate analysis associates each program object with an automaton which describes theorder in which operations can be invoked. The state of the automaton is thecontextmentionedin the quote above. For example a file object supporting operationsopen, read andclosemightbe described using the regular expression

open read? close

i.e. the file must be opened first before it may be read and it must be closed eventually. Typestateanalysis can be used to check a variety of interface rules, from security properties to detectingwhen data structures can be successfully freed as an alternative to garbage collection.

Interface Automata and typestate checking have much in common with this work. How-ever there are several major differences. Firstly, interface automata and typestate checking arecompile-time procedures which aim to check the compatibility of software modules statically.In contrast, although SWIL policies may be generated and analysed statically they are nonethe-less intended to be enforced at run-time against an unmodified application. Unlike the otherapproaches SWIL policies are not checked against the application source-code and so may beapplied even when source-code is not present. Additionally multiple SWIL policies may bein force at any one time, each running in parallel. Finally, SWIL policies are not simply pas-sive monitors of application behaviour but can be used to dynamically transform interfaces, byremoving links and forms associated with future error states in the SWIL model.

6.7.3 Sanctum AppShield

Sanctum AppShield was first mentioned in Section 5.6.2 and its ability to protect web-formparameters was discussed. AppShield is also claimed to protect applications from forceful-browsing attacks, through a component called aDynamic Policy Recognition Enginewhichmonitors live HTTP traffic and infers a policy dynamically. While it has a low installation over-head and does not require expert users to write a policy, a purely dynamic approach like this isinherently much less powerful than the manually specified approach specified here. Without an

133


up-front policy specification, the system must either be taught, by example, which sequencesof requests are valid or it must be conservative and dynamically track all links and forms gen-erated by the application across every session10. The former approach (training the system)suffers from problems if the examples presented to the system do not cover all valid applicationbehaviour. The latter approach (tracking all generated forms) may betoo permissive and allowattacks like the travel-booking example of Section 6.1.1.

The systems presented in this thesis all support policy abstraction: the ability to keep a con-crete security policy document separate from main application code. Two of the advantages ofhaving a concrete abstract policy are (i) the policy is a valuable form of interface documentation(and can be viewed as an interface transformation); and (ii) the policy can be analysed staticallyenabling the verification of important properties. These benefits are not conferred by an auto-matic, hidden-policy, Sanctum-like solution. In essence the system presented here combinesstatic and dynamic checking in a novel way.

6.7.4 Meta-programming

The SWIL Meta-programming System used an O’Caml embedding of SWIL to generate andcombine SWIL program fragments into more complicated SWIL programs. Although notthe main focus of this chapter, this section describes a number of other approaches to meta-programming and compares them to the SWIL Meta-programming System.

A traditional programming language is said to have twostages: compile-time and run-time.Multi-stage programming [155] (also known as generative programming or meta-programming)adds extra stages. At a minimum a multi-stage system would have: generation-time, compile-time and run-time where the code run at generation-time creates further code which is subse-quently compiled at compile-time.

Multi-stage systems are surprisingly common. Systems tend to vary in two aspects: firstlythey vary in how they manipulate generated code (some using strings while others may usesyntax trees) and they vary in how many guarantees they are prepared to make about the gener-ated code (i.e. whether it definitely typechecks). The parser generatoryacc generates C codeby bashing together strings containing fragments of syntax. There is no guarantee that outputgenerated in this way will successfully parse. Described in this chapter, SMS produces SWILcode by bashing together trees of concrete syntax (known asprogram fragments). Althoughguaranteed to parse, output generated in this way may fail to typecheck or may fail the well-formed program tests, resulting in an O’Caml exception being thrown. Recent research intometa-programming has resulted in systems like Meta-ML (described below) which can guar-antee that well-typed generator programs generate well-typed output programs11. A couple ofinteresting meta-programming systems are described in the following few sections.

Meta-ML/ MetaOCaml

Based on the ML language family, Meta-ML [156] and now MetaOCaml [3] allow programsto have an arbitrary number of stages. Meta-ML adds extra syntax for staged computations:<e > is a staged computation which will evaluate the expressione in the next stage. Bracketsmay be nested:< < e > > indicates an expression will be evaluated in the next stage butone. Staged computations have types which indicate both their result (when finally evaluated)and their context. A staged computation can be immediately evaluated using the operatorrun

10Consider that a user may bookmark a URI in one session and recall the bookmark from a second session.11A difficult property when variable bindings can be generated, possibly shadowing existing bindings of different

type.

134


which behaves like a type-safeeval operator. As mentioned in the previous section above,Meta-ML and MetaOCaml both perform static type checking guaranteeing that code will not begenerated which contains a type error.

If the SWIL Meta-programming System were implemented in MetaOCaml then we coulduse Taha’s observation [155] that a staged interpreter is a program translator. The SWIL inter-preter combined with a generated SWIL AST could be used to directly generate native O’Camlcode in a type-safe manner.

C++

C++ [153] created by Bjarne Stroustroup is an extension of C with accidental [166] supportfor meta-programming usingtemplates. Templates were intended for generic programming;creating classes and functions parameterised over types. For example a class which implementsa linked list might be written

template<class T>class List {

T *head;List<T> *rest;...

}

where theT is a type variable. A linked list of integers would have typeList<int> .However as well as providing type parameters to templates C++ allows templates to accept

integer value parameters. A template may be defined recursively as follows:

template<int X>class c {

static const int result = X * c< X-1 >...

}

When the program is compiled, the compiler will expand the nested templates completely (pos-sibly with a maximum recursion depth). C++ is therefore a three-stage programming languagewhere template evaluation generates code which is compiled and then executed.

Meta-programming using templates has been exploited by several projects. The MTL li-brary [151] uses templates to generate fixed-size kernels for linear algebra routines while theBlitz++ library [165] generates specialised algorithms, unrolling loops where possible for fastvector and matrix computation.

FreshML/ Fresh O’Caml

Although not strictly meta-programming languages, FreshML [148] and Fresh O’Caml [149]are derivatives of the ML family with extra facilities for matching and generating syntax. Orig-inally ML (which stands for Meta-Language) was intended for manipulating logic expressionsand accordingly supports sophisticated pattern matching and datatypes useful for this purpose.However when performing operations over syntax trees it is often difficult to handle variablebinding properly. Syntax trees should be treated as equivalent if they differ only in the namesof bound variables. Furthermore care must be taken when generating new names to managefreshnesscorrectly i.e. to respect the naming and scoping rules of the language and not acciden-tally confuse names that should be distinct. FreshML and Fresh O’Caml are specially designed

135


to make syntax manipulation tasks easy and safe. It would be promising to try implementingfuture versions of the SWIL meta-programming system using these tools.

6.7.5 User Interface Transformation

Dynamically changing (or transforming) interfaces has been studied in several different con-texts. Firstly, many applications deal with and must be able to display dynamically-generateddata. Therefore interfaces must transform themselves at run-time to cope with this generateddata. Secondly, in the highly mobile world of UbiComp, applications may be called upon toadapt and run on devices ranging from large wall-sized displays to small PDAs. Thirdly someapplication transformations are motivated by security. Each type of transformation is describedin the following sections.

Pre-programming transformations

User interfaces typically comprise a static part known at application-design time and a dynamicpart which depends on data only available at run-time. Traditional user interface builders (e.g.Cardelli’s direct manipulation interface builder [30]) focus on the static part. As part of theinfluential MASTERMIND project, Castells et al [38] propose a declarative language whichuses constraints to specify how the application should respond to dynamically changing data.

Rather than using a traditional user interface builder program, an alternative is to generatethe whole interface from scratch. For example one approach, taken by Engelson et al [58], isto automatically generate interfaces from the datastructures used by applications; for examplea structure might become a table and a string value might correspond to a text box. This hasthe advantage that if the code is updated (perhaps by dynamically loading a module) then theinterface can change to match.

Transformations for UbiComp

Ubiquitous Computing applications pose a difficult challenge for user interface designers. Pierand Landay [128] outline how future applications will be expected to be highly mobile andable to cope with a wide range of display sizes, from wall-sized displays down to small PDAdevices. They propose the idea of alocation-independent interface: an abstract entity whichmay take multiple physical forms; anything from a stylus-based interface on one device to avoice recognition system on another.

One attempt at making a location-independent interface was made by Todd and Glinertwho proposed a system called POLYGLOT [161]. In POLYGLOT interfaces written in an ab-stract form (similar to HTML form controls) are rendered on specific devices bypresenterobjects connected using a CORBA [123] middleware to the back-end applications. Presentersare device-specific; they choose the style of the interface and can render it using whatever fa-cilities are present on the device. Presenters can be connected and disconnect at will; multiplepresenters can control the same application simultaneously.

Perhaps due to the popularity of the devices, adapting interfaces to work on PDAs hasbeen studied in detail. One approach is to transcode images contained within web-pages, e.g.by reducing the quality and size of JPEGs with a custom web-server [39, 82]. AlternativelyHTML pages themselves may be parsed and summarised such that they better bit onto PDAscreens [29].

136


Transformations for Security

Some interfaces adapt their appearance in response to security requirements. When untrustedJava applets spawn top-level windows they are specially marked to warn the user that they arenot local applications. The Trusted Computing Group initiative [162]12places each applicationinto one of two groups: a low-security group and a high-security group. The high-securityapplications are trusted to access resources like encryption keys used to secure digital content.High-security applications needing to ask the user for sensitive details (e.g. passwords) areable to establish atrusted pathto the screen and keyboard. The aim is to prevent low-securityapplications from being able to fool the user by forging convincing-looking password dialogsor simply record key-presses. Whereas Java applets are marked with words like “untrusted”to warn the user, a TPCA high-security application will be marked with some special markingknown only to the user to provide some reassurance that the application is genuine. Effectivelythe marking would be a shared secret between the application and the user.

User Interface transformations are common on existing web-sites. Some bulletin-boardstransform the appearance of links, specially marking those which are written by users. Thisprevents users unknowingly clicking on links of the form:

<a href="http://malicious.com/">http://good.com/</a>

which causes the texthttp://good.com/ to be displayed on the page but when the link isclicked the actual URI fetched ishttp://malicious.com/ . When combined with client-side Javascript code capable of hiding the real URI bar (containing the give-away URIhttp://www.malicious.com/ ) and HTML designs which mimic the appearance of the browser,a user might be tricked into thinking that the page loaded fromhttp://www.malicious.com/ really ishttp://good.com/ .

Finally, it is important that any security-related interface transformations are never reliedupon in isolation. A user of a program with a visible security marking will inevitably grow totrust that feature, increasing the potential for disaster should that feature be subverted. A casein point is the typical web-browser “padlock” icon displayed on the screen when the browser isusing HTTPS i.e. HTTP over SSL. The padlock is intended to convey the fact to the user that thesite can be trusted; that its identity was confirmed and all communication is encrypted. Howeverthe SSL specification [53] allows ciphers to be renegotiated at any time and the NULL cipher isalways supported13. It is possible for an HTTPS server to request the NULL encryption cipherat any point — with the result that the data is not protected but the padlock icon is displayed.

Comparison with other UI transformation schemes

The dynamic response transformation described in Section 6.5.1 exists in a different niche tomost of the interface transformations presented in this section. It is not intended to be exclu-sively used as part of the application design process; rather it is intended both to be used to helpdesign new applications as well as to be externally imposed to fix pre-existing applications.

The transformation system proposed in this chapter is built on top of HTML transforma-tions, similar to those needed to make web-applications usable on small screen devices likePDAs. However, rather than removeunnecessaryfeatures (which do not fit on screen) we re-moveillegal features which would lead to a security policy violation.

12Also known as “Trusted computing”, “trustworthy computing”, “safer computing”, “TPCA”, “Palladium” andeven “treacherous computing” depending on who you talk to.

13It is needed at the beginning before another cipher has been negotiated.

137

http://good.com/

http://malicious.com/

http://www.malicious.com/




http://good.com/

6.8. Summary Chapter 6. Stateful Web-application Interface Language

The security related transformations are similar in spirit to the transformation scheme pro-posed in this chapter. However there are a number of key differences: (i) the system describedhere abstracts policy from the application code rather than entangling the two together; (ii) thetransformation system does not need to be foolproof – even if a bad link is selected the requestwill still be blocked by the application-level firewall; and (iii) the policy here is dynamic andmay be adjusted according to demand (e.g. it is possible to disable temporarily a part of anapplication while maintenance is being performed on it14).

6.7.6 Building web-applications using continuations

Several people have suggested making use of continuations to structure web programs [76, 131].For example, Graunke et al [76] propose a system where, whenever an application wishes tointeract with a user it stores its current execution context as a continuation—encrypted andprotected with a MAC (to prevent tampering)—on the client-side in a form. Users are freeto save the continuation-carrying forms to disk and revisit them at any arbitrary time in thefuture. Users can effectivelybacktrackto any interaction point as if they were running thewhole application within atimetravel debugger[26]. In the system proposed by Graunke et aleven application mutable state is stored on the client-side within cookies.

Such a scheme works well provided applications are fundamentally free of server-side side-effects; i.e. they must not rely on any mutable state on the server. Once some server state hasbeen introduced (e.g. in the form of an e-commerce transaction log) then the user needs to beprevented from backtracking to a point before the state was last updated, otherwise they mightsee a stale view of the application and become confused. The strength of the work presentedin this chapter is that nomatter which languages – recall a web-application might consist ofmultiple components written in different languages – are used to create the actual application,control over backtracking can be implemented using a SWIL policy and server-state can beprotected.

6.8 SummaryThis chapter presented SWIL, a language intended to protect applications fromforceful-browsingattacks. SWIL specifies the acceptable order of web-application interface functioninvocations as that accepted by a deterministic finite state automaton. A translation from SWILinto PROMELA was presented allowing SWIL policies to be analysed statically by the SPIN

model-checker before being dynamically interpreted by an application-level firewall. More im-plementation details are forthcoming in the following chapter.

To facilitate creating complex SWIL policies, an embedding of SWIL into O’Caml wascreated, called the SWIL Meta-programming System. This system allows the generation, ma-nipulation and combination of SWILprogram fragmentsforming complete SWIL programs.

As well as simply blocking requests in violation of the installed policy, the system proposedhere is able to perform dynamic interfacetransformation. Links and forms contained withinapplication HTML responses may be analysed and those which are determined to inevitablylead to a future policy error state are removed.

Finally, to demonstrate the utility of the system described in this chapter, an extended casestudy was presented based on a hypothetical e-commerce web-site. Suitable policy to protectthe application was created and a number of useful properties statically checked with SPIN.

14Although a realistic system would likely need some mechanism for telling userswhy the interface elementsare disabled and for how long the restriction might last.

138

Chapter 7

Implementation

This chapter describes the implementation of the application-level policy systems described inthis thesis. The policies described here fall into two categories: policies governing applica-tion mobility and applicationinterfaces. Chapter 3 and Chapter 4 described the Unified SpatialModel (USM) and the Mobility Restriction Policy Language respectively. Chapter 5 and Chap-ter 6 described SPDL-2 and SWIL, two policy languages for securing vulnerable applicationinterfaces. Mirroring this split, this chapter is also divided into two parts: Section 7.1 addressesmobility and Section 7.2 addresses interface policies. This chapter also includes details of anew policy mechanism known asmobility enforcement policies. These policies are written assimple Java classes and embody a particular movement strategy (e.g. “the agent should alwaysrun in the same room as person X”). Object instances of the classes are associated with indi-vidualsentient mobile applications– applications which automatically sense their environmentand react accordingly. Like the other policy systems described in this thesis, these new policiesare abstract specifications which may be placed in a library and shared between multiple clients.

7.1 Mobility

Earlier Chapter 3 described a spatial model capable of simultaneously representing the loca-tions of physical entities such as people and virtual entities such as mobile agents. The modelwas used as the basis for a new kind of policy: the mobility restriction policies described inChapter 4.

This section describes a Java-based implementation framework comprising of (i) a spatialmiddleware system maintaining a world model in the style of Chapter 3; (ii) client and server-side support for implementing the security policies of Chapter 4; and (iii) a new kind of mobileagent policy known asmobility enforcement policyused tocausean agent to move in responseto external stimuli. The structure of the framework is depicted graphically in Figure 7.1.

The implementation is described in two parts. First, Section 7.1.1 begins the descrip-tion of the spatial middleware system known as the WOrld Reaction and Modelling Service(WORMS). The model supports a plug-in architecture. Plug-in modules are used to connect themiddleware to external location systems and to help implement mobility restriction policies.The middleware is designed to be location-system agnostic; adding support for a new location-system simply involves writing a new plug-in module. As well as passively monitoring the stateof the world, the middleware is capable of taking action to programmatically create, destroyand move certain kinds of entities. This facility is used by a mobility policy plug-in to enforcethe mobility restriction policies of Chapter 4.

Section 7.1.2 continues the discussion with a description of the software running inside themobile agent servers. This code is divided into three parts, drawn separately on the diagram in

139

7.1. Mobility Chapter 7. Implementation

World Model

React

ModelSPIRITplugin

React

ModelAgletplugin

location sightingsof tracked physicalobjects

WOrld Reaction and Modelling Service

PolicyDB

Policy Plugin

Mobile Agent Server

Manager

MobilityPolicy

UntrustedAgentCode

(WORMS)

Figure 7.1: The structure of the system designed to implement mobility security policies. Notein particular the react interface of the SPIRIT plugin is greyed out (i.e. disabled); this is ex-plained later in the text.

Figure 7.1:

1. aManagermodule which communicates directly with the WORMS Aglet plug-in;

2. aMobility Policymodule which implements the new mobility enforcement policies; and

3. Untrusted Agent Codecomprising the rest of the agent code written by the user.

Recall from Chapter 4 that the mobility restriction policies were designed to influence the move-ments of mobile agents by either (i) blocking migration requests; or (ii) taking corrective action(e.g. killing or jailing an agent) afterwards if the policy violation cannot be avoided (i.e. itwas caused by physical movement). TheManagermodule is responsible for co-ordinating theclient-side part of both of these functions. It actively filters migration requests, checking for po-tential policy violations and also responds to commands (e.g. jail, kill) received from the Agletplugin.

The policies of Chapter 4 were intended torestrict the movements of agents; nothing wassaid about how tocauseagents to move in the first place. It was assumed that mobile agentswould contain code to decide when to migrate and would call the appropriate migration APIs.This chapter introduces a new kind of policy known as anmobility enforcement policywhichdescribes using the Unified Spatial Modelwhenan agent should move andwherean agentshould move to. An application using these policies is factored into two parts: (i) a mobilitypolicy object; and (ii) the rest of the code, which would contain no mobility-related behaviour.

Mobility enforcement policies areproactivepolicies and may be considered as the dual ofthereactivemobility restriction polices described previously. Enforcement policies are written

140

Chapter 7. Implementation 7.1. Mobility

abstractly as Java classes and each mobile agent is associated with a concrete object instance.Structuring applications in this way ensures that mobility behaviour is kept separate from themain agent code, allowing patterns of behaviour to be packaged into code libraries facilitatingthe sharing of mobility policies between applications.

The rest of this section is structured as follows: Section 7.1.1 describes the WORMS systemin more detail together with information about several plug-in modules. Section 7.1.2 describesthe code running in the mobile agent servers followed by a description of the mobility en-forcement policies in Section 7.1.3. A number of issues arose during the development of thisprototype system, these are discussed in Section 7.1.4.

7.1.1 Policy-Enforcing Spatial Middleware

This section describes the implementation of a spatial middleware system called the WOrldModelling and Reaction Service (WORMS) which implements the spatial model of Chapter 3.The Java-based WORMS system bridges the gap between real-life sensor and reaction systemsand spatially-aware mobile agents. The service constitutes a core and a set of plug-in modules.The core maintains the world model, making sure the entities in the model are well-sorted.Clients can register themselves to receive update events whenever parts of the world-modelchange i.e. events are generated whenever entities are created, destroyed or moved.

Plugins exist for two purposes: (i) to connect the WORMS system to individual locationsystems; and (ii) to impose policy on the system. The system uses a publish/subscribe mecha-nism; policy modules register themselves with the core, receiving events whenever any updatesto the world model happen. The policy modules continually monitor for any policy violations.If any breach is observed then they take the appropriate corrective action (e.g. in the policiesdescribed in Chapter 4 this might involve killing, creating or jailing an agent).

Location plugins expose two interfaces: a passivemodellinginterface and an activereactioninterface. The modelling interface is used by modules which monitor the outside world (the“real-world”) and feed updates into the world model. The reaction interface is used to effectchanges in the outside world being modelled. For example, it is through the reaction interfacethat mobile agents may be frozen or destroyed.

As mentioned above, the Service is not specialised to one particular location system butrather is designed to be location-technology agnostic. Each particular location technology isassociated with a plugin module which implements either or both of the interfaces (modellingand reaction). Currently the system has two such plugins: aSPIRITplugin and anAgletplugin.

SPIRIT Plugin

The SPIRIT [11] system first mentioned in Section 3.3.4 is a piece of location-monitoring mid-dleware developed originally at AT&T Laboratories Cambridge. Its primary function is to take astream of raw location events received from a network of ceiling-mounted sensors and combinethese with a spatial database to produce and disseminate high-level location events concerningpeople and objects within the lab. Objects to be tracked are equipped with Active-Bat [169]devices — radio-triggered ultrasound-emitting location tags described earlier in Section 2.2.2.The clients of the system are location-aware applications, for example the “active map” pro-gram which displays a top-down view of an office complete with the positions and orientationsof people and equipment, updated in real time. Figure 7.2 shows an active bat on the left and ascreenshot of the “active map” program on the right. Note that the map is showing a zoomed-inview of an office in the Laboratory for Communication engineering where 3 people are present,represented by usernames ofkjm25 , jpw20 and ja316 . Desks, computer terminals and

141


Figure 7.2: On the left: an example active bat. On the right: a screenshot of the “active map”program.

phones are also visible.SPIRIT is aspatial indexing system. Primitives in SPIRIT are spatial regions (shaped vol-

umes of space) which are allowed to move freely with respect to one-another. SPIRIT generatesevents whenever a region overlaps, ceases to overlap, contains another or ceases to contain an-other region. The functionality of the SPIRIT system is best explained by means of an example.The “desktop teleporting” [134] application is a commonly-used program which automaticallymoves a user’s desktop to the terminal nearest their current physical location. The teleportingapplication exploits SPIRIT in the following way: every computer monitor is associated witha region of space placed in front. Roughly speaking, the region of space corresponds to thespace from which the monitor would normally be used. Therefore a smaller monitor would beassociated with a smaller region than a bigger monitor. Similarly, users are associated with avolume of space representing the region in which an object has to be located for them to interacteffectively with it. When a person turns to face a monitor the two regions overlap, generating anevent which causes the teleport application to display the user’s desktop on the screen. Whenthe user moves away, another SPIRIT event is generated which removes the teleported desktop.

The SPIRIT plugin1provides a mapping between the spatial regions understood by SPIRITand specific entities in the entity hierarchy. An example of such a mapping is shown in Figure7.3. The bottom half of the figure shows the output of the active map application monitoring tworooms — “Room 9” and “Room 10”. The SPIRIT plugin has associated these rooms, two people(useridkjm25 andacr31 ) and a pair of workstations with entities inside the Service. Oncethe mapping is established, the plugin listens for high-level containment events from SPIRIT(such as “userkjm25 has left Room 9”) and makes the corresponding changes in the world

1The low-level interface between the native SPIRIT C++ libraries and Java was written by Alastair Beresfordusing the Java Native Interface (JNI) facility. This small piece of code generates a continuous stream of locationevents which are filtered and processed by the rest of the plugin code.

142


model. Note in the earlier diagram in Figure 7.1 how the “React” part of the SPIRIT plugin wasgreyed out. This is because SPIRIT is an entirely passive system; it is not possible to commandSPIRIT to physically move objects around. It is possible to imagine a modified SPIRIT systemwhich can influence its environment. This might be used, for example, to command robots tomove around the building.

Aglet Plugin

The Aglet system – a Java-based mobile agent system from IBM – was first described in Sec-tion 4.7.1. Aglets (calledagentsin the terminology of Section 2.1) execute in a “context” –represented by an instance of the classAgletContext (called locationsin the terminologyof Section 2.1). A single computer can run multiple Aglet VMs (calledmobile agent serversinthe terminology of Section 2.1), each associated with a unique TCP port number. Each AgletVM can contain multiple contexts. Individual Aglet contexts are named globally by URIs ofthe formatp://host:port/context where the URI schemeatp indicates the “AgletTransport Protocol”. Aglets exploit the conventional Java event model: events are generatedwhen agents are created, destroyed or move between contexts. Interested parties can registerthemselves (as eventlisteners) with the Aglet system and receive callbacks when the events aregenerated.

Like the SPIRIT plugin described above, the Aglet plugin is responsible for maintaining amapping from hostnames, context names and Aglet names to entities in the world model. Sucha mapping for a fragment of a world model is displayed in Figure 7.4. The diagram depictsa path of entities from the root to an agent called “music player”. The first two entities inthe path (“World” and “Charlie’s Office”) represent physical objects and are therefore ignoredby the Aglet plugin. The remaining four entities have some meaning in the Aglet universe:the “laptop” entity is a piece of hardware with a hostname (”laptop”); the context “main-123”corresponds to an Aglet process with process ID (PID) 123; the context “context” correspondsto anAgletContext within the java VM called “context” while the entity “music player”corresponds to a running Aglet called “music player”.

Unlike the SPIRIT plugin described earlier, the Aglet plugin supports thereact interface,to control the runtime behaviour of agents. Ideally it would be possible to completely control(migrate, jail or kill) untrusted agents running in the system without their consent. However,in the prototype described here there are a number of limitations inherited from Java whichmake this impossible. Therefore in the current implementation, the Aglet plugin sends controlmessages to the individual agents and trusts them to respond correctly to the control messages.More details and discussion of the limitations inherent to the design of the prototype system arepresented later in Section 7.1.4.

Mobility Restriction Policy Plugin

Recall the mobility restriction policies introduced in Chapter 4 which consisted of 4-tuples:

〈location, formula, times , onfail〉

where location is a path expression (see Section 3.1.3) designating a set of specific entitieswhere the assertion given byformula should hold. If, with respect to the time period describedby times, the assertion becomes violated (e.g. by the physical movement of an object) then thesystem will attempt to execute the command described in the fieldonfail .

In any realistic system, policies written by different users are likely to come into conflictwith each other. Section 4.5 outlined one possible conflict resolution strategy in which each

143

atp://host:port/context


Upper Floor

Room 9 Room 10

User:acr31

User:kjm25

Figure 7.3: An example of the mapping between SPIRIT objects as displayed by the programsmap (bottom) and entities in the WORMS world model (top).

144


context

World

Charlie'sOffice

laptop

music player

context

a

context

main-123

Physical Hardwarenamed "laptop"

Aglet process (Java VM)with PID 123

AgletContext called "context"within VM

Aglet called "music player"

Entity in the Unified Modelling System Realisation in the Aglet plugin

N/A

N/A

Figure 7.4: Diagram showing how entities along a path in the world model are realised by theAglet plugin.

145


entity is associated with anowner, who has a say in the outcome of anyonfail action (e.g. thekilling or jailing of an agent) involving that entity.

Therefore the mobility restriction policy plugin must maintain a database of users, entities,active policies and keep track of which user owns each entity. The plugin performs two func-tions: (i) it receives migration requests from deployed mobile agents and either confirms orrejects the requests; and (ii) it observes other movement (e.g. physical movements) and deter-mines when a policy violation has occurred and what corrective action should be taken (if any).These two functions are now explained with an example.

Example

Consider a simple office environment containing two people: Alice and Bob, both of whomhave one office and one PC each. An example world model is displayed graphically in the upperpart of Figure 7.5. The world model is similar to the example originally used in Section 4.3.Note that dashed boxes and arrows are used to indicate the owners of each entity. There arethree owners in the diagram: Alice, Bob and a user called “The Boss” who is not physicallypresent in the model. In the example there are two policies installed in the WORMS system,one belonging to Alice and one to Bob. Alice’s policy is as follows:

〈 location = World ,formula = �¬music player [T] | (♦(Alice[T]

| ♦music player [T] | T)),times = Always(10 seconds),onfail = Kill World// • • • //music player 〉

(7.1)

“for all time, either themusic player is absent (not running) or it is running ina place next to me. If this remains false for 10 seconds, kill themusic player(wherever it is)”

Note that in the upper part of Figure 7.5 the formula in the policy is holding because Aliceand her agent are both within her office. The second active policy written by Bob is the same asthat given back in Chapter 4 i.e.:

〈 location = World/* ,formula = �¬Bob[T] ∨ (♦Bob[T] ∧�¬audio [¬0]) ,times = Always(3 seconds),onfail = Jail / • • • /audio/* 〉

(7.2)

“if ever I’m in an office with a music playing agent, jail the agent if it has not leftwithin 3 seconds”

Note that in the upper part of Figure 7.5 the formula in the policy is holding because Aliceand her agent are in one office and Bob is in another.

Now, consider what happens when Alice walks into Bob’s office. First of all the locationsystem senses Alice’s new location and sends this information to all registered applications,including the WORMS service. The WORMS service updates the authoritative copy of theworld model resulting in the configuration displayed in the lower part of Figure 7.5. Note thatAlice’s policy is now being violated but Bob’s is not. Since the WORMS service itself acts asa location system, it sends location update events to all registered clients: specifically all the

146


World

Alice'sOffice

PC PC

Bob'sOffice

Bob

context

audio

context

audio

music player

a

Alice BobAlice

The Boss

1

World

Alice'sOffice

PC PC

Bob'sOffice

Bob

context

audio

context

audio

music player

a

BobAlice

The Boss

2

Alice

1.2.3.4.5.

Alice walks into Bob's OfficeSPIRIT location system senses her new positionLocation update event received by WORMS serverSpatial Model in WORMS server updatedSpatial Model update events propagated to allregistered Mobile Agent Servers

Status of Policies:

User Status

Alice OK

Bob OK

Status of Policies:

User Status

Alice VIOLATED

Bob OK

Figure 7.5: [1]: initial state of the WORMS system; the dashed arrows and dashed boxesindicate the owners of each entity. The table on the right indicates that two users’ policies areboth satisfied. [2]: the state of the WORMS system after Alice has been sensed moving intoBob’s Office. Note her music playing agent has not moved and her policy is now being Violated.

147


registered mobile agent servers running on all the PCs. Observe that Alice’s policy had atimesfield containingAlways(10 seconds); this indicates that Alice’s agent has 10 seconds to takean action which fixes the policy violation before theonfail clause is executed. The WORMSsystem sets an internal timer for 10 seconds and waits for the agent to respond, if it can.

There are now several possibilities, including:

1. Alice walks back into her office, her policy is nolonger in violation and the timer iscancelled;

2. the music playing agent quits (or crashes), it is removed from the model, the policy isnolonger in violation and the timer is cancelled; or

3. the music playing agent attempts to migrate to a PC in Bob’s office.

The last case is particularly interesting and worth considering in detail. Figure 7.6 shows thesequence of events starting with the initial message from the location system to the WORMSservice triggered when Alice switches room. We have already considered up to the time markedwith the asterisk, just after the WORMS service has set a timer and sent an update message toall the registered clients. We assume that the music player is a “follow-me” music player andtherefore it decides to follow Alice by migrating into Bob’s office. It sends a request to theWORMS system asking for permission to migrate there. The centralised WORMS systemconsiders all agent migration requests. The WORMS system computes that, should it allow theagent to move, it would satisfy Alice’s policy but place Bob’s in violation and therefore it mustapply the conflict resolution policy to decide which policy should take priority.2

The default conflict resolution strategy was outlined back in Section 4.5. Each user is con-sidered to “vote”3 on a proposed change to the world model. A user is said to either befor thechange,againstagainst the change or said toabstainin the following circumstances:

for: either the change results in fewer of the users policies being violatedor it results in nochange to the number of the users policies being violated and the request happens tocome from an agent they own;

against: if the change results in more of the users policies being violated; and

abstain: if the change results in no change to the number of the users policies being violatedand the request comes from an agent they do not own.

A migration is considered to consist of two phases: the first when the agent leaves its old contextand the second when it arrives at its new context. The request is only allowed if both phasesare allowed. For the case of Alice’s music player attempting to migrate into Bob’s office, eachphase will be considered separately.

Consider the first phase of the migration; i.e. when Alice’s agent leaves Bob’s office. Alice’ssingle policy is violated if the agent stays where it is and holds if the agent disappears; thereforeAlice votes for the change. Consider Bob: his policy is not violated before or after this changeand since the agent does not belong to him he abstains. Since there is one vote for and oneabstention there is no need to deliberate any further and the change is accepted.

2The conflict resolution is needed because Bob’s policy would be violated by the proposed move. If Bob’spolicy was agnostic then the conflict resolution would not be needed.

3Of course no actual user polling takes place, just an examination of their policies

148


WORMS system

World Model Update:Alice moves to Bob's Office

Event from Location System:Alice moves to Bob's Office

Alice's policy violated:onfail timer set

Music Player requestsmigrate to Bob's Office

Request considered;Bob's policy takes precedencedue to conflict resolution

Migration requestrejected

10seconds

time

Alice's policyonfail timer triggered

Alice's policy onfail actionconsidered; both policies accept;no need for conflict resolution

Kill agent request

Agent terminated

Location systemmusic player

*

Figure 7.6: Chart showing the sequence of events which happen when Alice walks into Bob’soffice and remains there. Time runs vertically downwards. There are three components in-volved, from left-to-right: the music playing agent running on a PC in Alice’s office; theWORMS system running on a centralised server; and the location system running on a cen-tralised server.

149


Consider the second phase of the migration; i.e. when Alice’s agent arrives in Bob’s office.Alice’s single policy holds if the agent is absent and holds if the agent is in Bob’s office; there-fore since the number of policies in violation is unchanged she votes for the change, becausethe request comes from her agent. Bob’s policy, however, is not violated before the changeand would be violated afterwards; therefore he votes against the change. For this phase of themigration there is one vote for (from Alice) and one vote against (from Bob) and therefore wemust consider the owners of the relevant spaces.

Recall that the conflict resolution strategy adds weights to votes depending on the ownersof the space where the proposed change will occur. Since the proposed change is Alice’s agentarriving on Bob’s PC the WORMS system examines who owns the entities on the path betweenthe root and Bob’s PC’saudio context. There are two relevant owners: “The Boss” who ownsthe root entity and Bob who owns his office and the equipment inside. Since “The Boss” has notentered any policies into the system he is ignored. Bob, of course, votes against the migration.Alice’s votes are ignored because she does not own any of the relevant entities. Therefore theconflict resolution system decides that Bob’s wishes take precedence and the migration requestis to be blocked.

Returning to the chart in Figure 7.6, a message is sent back to the agent from the WORMSsystem telling it that its migration request has been rejected. At this point we assume the agentcontinues to monitor Alice’s location and if she moves somewhere else it will attempt anothermigration. Assuming Alice stays where she is, a short time later the 10 second timer expiresand theonfail action is triggered and the WORMS system considers executing the commandto kill the music player agent. Recall that a kill consists of only one phase: removing the entityfrom the model. The WORMS system evaluates this change in the same way as the previousmigration proposal and concludes that it will be accepted—this is due to the fact that Alice’spolicy will cease to be in violation and Bob’s policy holds regardless. Therefore the WORMSsystem issues a command to kill the music player entity. This request is translated by the Agletplugin into a request to the mobile agent server on Alice’s PC to terminate the music playingaglet. The last step in the chart of Figure 7.6 shows this message being received and the resultingagent termination.

7.1.2 Mobile Agent Servers

This section describes the code running inside the client-side mobile agent servers. In thediagram of Figure 7.1 three modules were displayed: (i) theManager; (ii) the Mobility Policy;and (iii) theUntrusted Agent Code. Each of these shall be described in turn.

TheManagermodule talks directly to the Aglet plugin. On startup its first task is to registerentities in the model which correspond with instances ofAgletContext in the local virtualmachine. Whenever an agent wishes to migrate, the Manager sends the request to the Agletplugin. The installed policy in the middleware service is queried to determine whether therequest should be accepted or not. The Aglet plugin can also send requests to the Manager,telling it to destroy or jail an agent in response to a policy violation (recall that policy violationscan result from unrestrained physical movement).

The policies in Chapter 4 are mobilityrestriction policies designed to limit the physicalmovements of mobile agents. TheMobility Policy in Figure 7.1 refers to another kind of policy:themobility enforcement policy. These policies are written directly as Java classes and a numberof example policies are described in the following section.

The rest of the code is labelledUntrusted Agent Codein Figure 7.1 and comprises the

150


application-specific part of the mobile agent code. This code is standard Java Aglet code exceptit has access to additional APIs (notably the Manager module) and is unable to use the standardAglet migration commands directly; all migration requests must be filtered through the Managerfirst.

7.1.3 Mobility Enforcement Policy

The mobility enforcement policiesare the dual of the mobilityrestriction policies outlined inChapter 4. The enforcement policies decidewhenan agent should move andwherethe agentshould move to. The policies are represented as Java classes using a few simple APIs as exhib-ited by the following pseudo-code fragment:

public class SimplePolicyimplements EntityChangeListener{

...public SimplePolicy(WORMS spatial_model,

Manager manager,Entity me) {

spatial_model.addCallback(this);...

}public entityDeparted(who, where){ ... }public entityArrived(who, where){ ... }...

}

where spatial model represents a reference to the WORMS system andthe addCallback method registers the SimplePolicy instance as anEntityChangeListener . When the world model changes, the system invokes theentityDeparted andentityArrived methods when entities leave a place and arrive ata new place respectively. Note these correspond to the two primitive events described earlierin Section 3.2. Note also that although this API causes the agent to receiveall change eventsin the model an API could be added to request only events within a particular subtree of themodel to enhance scalability.

Since the policies are abstract, a library of common patterns can be created to encouragecode sharing between applications. The following two sections provide examples of how suchcommon mobility policies might look.

Example: The Follow-Me Policy

The “Follow-Me” policy instructs the application to physically follow a particular user around.Whenever the user leaves a room, the application stops running. Whenever the user enters anew room, the application migrates to a host in the new room and continues where it left off.This mobility policy is useful in a number of contexts, for example

• migrating a user’s desktop to a terminal near their current physical location (recall theteleporting example in Section 7.1.1) to ensure that user applications are always easilyaccessible; and

• ensuring that a music playing program is always playing music that the user can physi-cally hear, by migrating to a computer in the same room.

151


Java-like pseudocode for the Follow-Me policy may be written as follows:

public class FollowMe{...public FollowMe(WORMS spatial_model,

Manager manager,Entity me) {

spatial_model.addCallback(this);...

}

Entity findNearbyComputer(Entity x){// returns an entity near "x"// capable of running the// application

}

public entityDeparted(who, where){if (who.equals(me)){

manager.stop();}

}public entityArrived(who, where){

if (who.equals(me)){Entity x=findNearbyComputer(where);manager.migrate(x);

}}

}

In the constructor theFollowMe object registers itself with the WORMS. When entitieschange location in the spatial model the two callback methodsentityDeparted andentityArrived are executed on the policy object. Note that in the Follow-Me policy onlyevents relating to the user being tracked are relevant and all other events are silently ignored.When the tracked user leaves his/her current room, theentityDeparted method calls themanager.stop() method which requests that the application stop executing. When thetracked user enters another room, theentityArrived method attempts to migrate the appli-cation to a new computer, located inside the user’s new room.

Example: The When-No-one’s-Here Policy

This policy is useful for running long-term non-interactive tasks on otherwise idle computers.Whenever a user enters a room with one of these applications, the application is paused toprevent any possible degradation of the quality of service to the user. Only when the last personleaves the room is it safe for all such background tasks to be restarted.

Java-like pseudocode for this policy may be written as follows:

public class WhenNooneHere{...

152


public WhenNooneHere(WORMS spatial_model,Manager manager,Entity where) {

spatial_model.addCallback(this);...}

int countPeopleHere() {// return number of people in// same room as me

}

public entityDeparted(who, where){if ( (manager.amStopped()) &&

(countPeopleHere() == 0) )manager.start();

}public entityArrived(who, where){

if ( (manager.amRunning()) &&(countPeopleHere() > 0) )

manager.stop();}

}

The utility functioncountPeopleHere returns the number of people in the same room asthe application. TheentityDeparted andentityArrived methods use this informationto decide whether or not to let the application execute.

7.1.4 Issues

In the prototype system described in this section there are several outstanding issues whichshould to be addressed before the system is widely deployed. The first issue concerns the sizeof the trusted computing base(TCB). In computer security terminology, the TCB is definedto be the set of hardware and software components which enforce the security policy. In thisimplementation, the TCB comprises

1. the location system;

2. the servers running both the WORMS middleware system and the mobile agent servers;

3. the network connecting the hardware components together;

4. the code running in the WORMS middleware system;

5. the Java virtual machine; and

6. the Manager module in the mobile agent servers.

Some of these dependencies are hard to avoid; for example it is difficult not to rely on the phys-ical security of server machines and difficult not to rely on the software (Java VM, WORMS

153


middleware, Aglet libraries and the Manager module) being written in a secure fashion, free ofapplication-level vulnerabilities. However, the two remaining dependencies, namely the loca-tion system and the network, are particularly problematic.

The design of the Active Bat system, described earlier in Section 2.2.2, was focused onachieving maximum performance in terms of location accuracy and update latency in a shared,trusted environment. In particular it was not designed for high integrity and availability in thesecurity sense (integrity and availability were first discussed in Sections 2.5.2 and 2.5.3 respec-tively) and there are a number of possible attacks. A simple method to prevent an object beingtracked (assuming the Active Bat is physically attached to the object) is to cover the ultrasoundemitters on the top of the bat, preventing any signal getting through. Another possible attackrelies on the fact that the ultrasound signals are narrowband – it is possible to prevent any sight-ings in a room by flooding the room with ultrasound continuously4. Neither the radio channelnor the ultrasound channel use any kind of integrity checking and therefore it is possible for amore sophisticated attacker to forge false sightings, completely manipulating the system. Theseproblems can only be solved properly by redesigning the location system with measures toensure integrity and availability. A move to wide-band (e.g. spread spectrum) signals wouldincrease the difficulty of jamming the signals and cryptography could be used to guarantee theintegrity of messages.

As well as relying on the Active Bat, the network connecting the components together isalso part of the TCB. In the prototype system, the network is a shared ethernet network. Thecomponents can use standard cryptography to guarantee the secrecy and authenticity of mes-sages but, due to the properties of the underlying ethernet network. the system cannot guaranteethe messages are ever delivered. In the same way an attacker can prevent Active Bat sightingsby flooding the ultrasound channel with noise, an attacker can prevent messages being deliv-ered by flooding the network with data. There are two approaches which would ameliorate thesituation. The first approach is to redesign the network so that it can make some reliabilityguarantees – a form of Quality of Service (QoS). Alternatively the set of policies allowed inthe system could be changed. Rather than assuming that the movements of entities which leadto a policy violation are observed, we could instead assume that we needproof that the policyhas not been violated, otherwise corrective action is taken. Such proof could take the formof a message generated and signed by the location system saying “entity X was seen in entityY at time T”. The absence of any such guarantee within a certain time period could result incorrective action being taken, such as the termination of an active agent. Applications could beconstructed in a robust fashion so that loosing an agent does not unduly affect the task beingperformed. In such a scenario, unnecessarily killing agents might be an acceptable solution.

There are a number of additional issues stemming from the choice of implementation lan-guage: Java. Java has the following (mis-)features:

• the inability to introspect the call stack of a running thread;

• the inability to kill (sometimes known ascancel) a running thread; and

• the security model for governing access to resources.

The first feature – the inability to introspect the call stack of a running thread – leads Java toonly support weak mobility (see Section 2.1). All agents must supportstop() andstart()

4Jangling keys or using a hoover are both proven techniques for jamming Active Bat ultrasound signals.

154

Chapter 7. Implementation 7.2. Interfaces

methods which provoke them to voluntarily serialise and deserialise their own execution state.It is not possible to freeze another thread and read its method call stack. The second feature– the inability to cancel a running thread – is a deliberate limitation to prevent threads beingterminated while still holding locked resources, which would then become permanently locked.The consequence is that agents must respond to commands to shut themselves down and anaberrant agent cannot be forcibly killed, without restarting the virtual machine. The last featureconcerns the standard Java security model for controlling access to resources. Java APIs grantpermissions to resources by withholding or transmitting references to otherwise hidden objects.Once a reference is given it cannot be taken back or cancelled. If a music playing agent is frozenand the system wishes to prevent the agent from playing sound, there are two implementationalpossibilities. Either the agent should voluntarily give up the reference to the sound playingobject or the system should interpose a proxy object which checks access permissions for everycall. Both options have drawbacks; the first relies on cooperative agents while the second altersthe semantics of APIs by adding extra failure modes (e.g. the command to play a sound mightfail during theplay() call but after the sound device is opened successfully).

7.2 InterfacesThe previous section dealt with enforcingmobility policies on applications while this sectionfocuses on imposing policy on applicationinterfaces. The policies are implemented by meansof a web-based firewall called SPECTRE, the design of which is described in Section 7.2.1.SPECTRE is a sophisticated and modular firewall which allows policy modules for SPDL-2(described in Section 7.2.2) and SWIL (described in Section 7.2.4) to be loaded dynamically.Although the implementation of SPECTRE is a research prototype, encouraging performanceresults are provided which demonstrate that the approach described here is feasible.

The rest of this section is structured as follows: Section 7.2.1 describes the structure ofSPECTRE followed by details of the SPDL-2 implementation in Section 7.2.2. SPDL-2 poli-cies are stateless whereas SWIL policies are inherently stateful and require state tracking. Sec-tion 7.2.3 describes how SPECTRE can be used to track sessions and Section 7.2.4 describesthe implementation of SWIL policies. Finally, some results and discussion are presented inSection 7.2.5.

7.2.1 SPECTRE: A Policy-Enforcing Firewall

SPECTRE is an application-level firewall used to enforce interface policies dynamically.SPECTRE is written in O’Caml on top of a custom HTTP processing library. It receives HTTPrequests intended for the back-end application server and parses the headers, including parame-ters and cookies. Once the request has been parsed, the firewall reads the URI and decides whichmodule the request should be directed to. In the diagram of Figure 7.7, requests are initiallydirected towards both modulem1and modulem3 in turn. Each module may choose one of thefollowing three actions: (i) accept the request for processing; (ii) reject the message as invalid;or (iii) opt not to process the request. A rejection from a module terminates the processing ofthe request. If the request is accepted for further processing then it may be modified beforebeing passed on to further modules. For example, in Figure 7.7, if modulem1accepts a requestit may be modified before being passed on to modulem2. A module may opt not to process arequest e.g. in Figure 7.7 the modulem3may opt not to process a request in which case it willbe offered to modulem1. If no module accepts the request then the request is rejected, even ifno module explicitly rejected it.

The firewall is intended to befailsafe– if a request is not explicitly accepted with an installed

155

7.2. Interfaces Chapter 7. Implementation

client server

firewall

m1 m2

m3

Figure 7.7: Structure of the SPECTRE Policy-Enforcing Firewall with three modules loaded:m1, m2andm3.

policy module then it will be rejected (i.e. the firewall operates adefault-denybase policy).By forbidding all URIs that do not match those explicitly in the installed policies the firewallprevents an attacker from using obscure, non-standard URI encoding techniques to circumventthe protection (thus avoiding attacks of the kind recently used on Cisco’s Intrusion DetectionSystem [57]).

Once requests have been successfully processed by all relevant modules the request is for-warded to the back-end application server. HTTP response messages received are again filteredthrough the policy modules which perform any necessary transformations before the responseis finally returned to the original user.

7.2.2 SPDL-2

TheSPDL-2 Compilertakes an SPDL-2 specification (as described in Section 5.4.1) and com-piles it into a policy module for execution on the firewall. Validation rules and constraints arecompiled into both O’Caml for dynamic execution and Javascript which can be embedded intoforms and executed on clients. Generating client-side form validation Javascript code is not al-ways desirable – many applications already have their own, custom Javascript for this purpose– and therefore Javascript generation can be turned off on a<policy> -wide basis (by settingthe javascript attribute of the<policy> tag to ‘N’). The SPDL-2 DTD may be found inAppendix A.

The policy module operates as follows: Once a valid URI has been detected in the HTTP-Request, the module examines the names of all parameters and cookies present. If unexpecteddata is present, or expected data is absent then the error is logged, the request is blocked and amessage returned to the user indicating the request was rejected. The next step is the checkingof parameter type and length constraints. Assuming those tests pass, any required messageauthentication code is verified and the validation and transformation code is applied.

Transformations should betotal functions on strings. A badly-written transformation whichgenerates an exception will cause the request to be aborted and an error message to be returnedto the client. Additionally, observe that if the policy document requires the insertion of client-side Javascript or if the policy indicates that it might contain a link to a MAC-protected URIthen the firewall must process the HTTP response returned from the web-server. The HTML isparsed and rewritten in order for the appropriate validation code (pre-generated by the policycompiler) to be added to forms (see Section 7.2.2). Message authentication codes are also

156


inserted to protect form fields and URI-parameters from malicious client-side tampering (seeSection 7.2.2).

Client-side Form Validation

Whenever requested by the policy document, the module inserts Javascript code to performclient-side validation checks. (Recall that the insertion of Javascript is only intended to enhanceusability – data is always rechecked by server-side code to avoid the kind of Form Modificationattacks described in Section 5.2.1). The inserted code checks most of the SPDL-2 constraints:types, lengths and all custom constraints written in the validation language. The resulting pro-gram is inserted into theonSubmit attribute of a<form> tag unless such an attribute isalready present – any already present validation code is considered to take priority over thegenerated code.

Message Authentication Codes

Recall that SPDL-2 policies allow URI parameters to be marked indicating that they must onlyreceive data which is accompanied by aMessage Authentication Code(MAC) [143] generatedby the firewall. As HTML is sent to the client, the firewall annotates the appropriate parts withMACs; these MACs are checked when the form data is submitted. This mechanism is used toprevent the Form Modification attacks described in Section 5.2.1.

The implementation uses the HMAC [20] algorithm to generate MACs by securely com-bining the protected data with a secret key and a timestamp. In this way an attacker is unableto generate new MACs without first finding out the secret key. A major danger still facing thissystem is avoidingreplay attacks[154] where clients replay messages already annotated withMACs in unexpected contexts. Two steps are taken to avoid such attacks:

1. A time-stamp is included in the MAC to guarantee messagefreshness.

2. Rather than generating separate MACs for each individual protected field, a single MACis generated for all protected client-side state bundled together. This protects the integrityof the whole message, protecting against cut-and-splice attacks (in which MAC-annotatedfields are swapped into other messages).

Both steps are SPDL-2 mechanisms which require storing no session state in the application-level firewall. However these mechanisms are not foolproof. For example, in the case studyoriginally presented in Section 5.5 a MAC is generated forboth theproductID andPricefields. Although users can replay such messages this results in multiple purchases of thesame product for thecorrect price. The intention is that the MAC prevents thePrice andproductID being modified independently.

In this example the problem of multiple identical purchases can be partially rectified byusing a SWIL policy in addition to a SPDL-2 one. Such a policy could take many differentforms. At one extreme, a very simple SWIL policy could prevent the user submitting twoconsecutive requests to the same sensitive URI by accident. A more complicated policy coulduse a native function call to check the request against a database containing previous requests, toprevent duplicates. Note this second case may require large amounts of storage space; howeverapplications like the hypothetical e-commerce application would probably already store therequired information anyway (e.g. in a transaction log).

SPDL-2 requires that HTML pages fetched from URIs that are contained in a single

157


<policy> block may only contain links to MAC-protected URIs5 which are found in thesame<policy> block (or in a nested<policy> block). By forcing the application’s URIsto be partitioned in this way an important performance optimisation is facilitated which is dis-cussed in Section 7.2.5 as well as encouraging the policy designer to structure their policy forease of future maintenance.

7.2.3 Tracking Session State

The SPDL-2 policies described in Section 7.2.2 may be consideredstateless policiesbecausethey can always be implemented by a stateless firewall. In contrast, SWIL policies which de-scribe the acceptable order of URI invocations have an implicit notion of state and thereforecannot be implemented by a stateless firewall6. This section describes a firewall module whichprovides the necessary state handling.

Since HTTP is itself a stateless protocol, it is necessary to manually create a session on topof the HTTP protocol using one of the techniques discussed in Section 2.4.5. Once a sessionis established, state associated with the policy can be associated with it. When processingrequests and responses, the session information can be retrieved from the HTTP messages andany associated state (stored within the firewall) can be modified.

The session state tracking module creates a session over HTTP using client-side state viaspecially-named cookies. The module does not impose any policy of its own in the sense thatit never rejectsany requests or responses; it onlytransformsresponses by adding the specialsession tracking cookies. Note that the session established by the session tracking module iscompletely orthogonal to any sessions established by the application itself. Each such sessionwould use a different cookie name.

The session tracking module operates in the following way. Upon receiving a request thesession tracking module examines all cookies within the HTTP message. If the specially-namedsession tracking cookie is absent (indicating the need for a new session) then a new sessionidentifier is created and the cookie added to the request. This modified request is then passedto other policy modules which can use the session cookie to store state associated with thesession. When the session tracking module receives the response back from the application(possibly after being transformed by other policy modules) the session cookie is added again tothe response. This scheme relies on the user to have cookies enabled in their browser; if a userdoes not have cookies enabled then every request will cause a new session to start.

Session lifetimes

Sessions are not eternal; the maximum lifetime of an idle session is a configurable parameter ofthe tracking module. The time of the last request is stored with every session and those olderthan the maximum lifetime are culled. If a user attempts to restart a deleted session then anew session is created for them and they must restart their interaction with the application fromthe beginning. This is a similar tactic used by many web-applications and by other systemssuch as NAT routers. The exact choice of maximum lifetime value depends on the nature ofthe application and reflects a trade-off between convenience and security. A long lifetime isconvenient for a user who can return to the application after a lengthy period of absence whilea short lifetime guards against a user forgetting to logout, leaving a terminal and allowing amalicious user to continue their session.

5A MAC-protected URI has at least one<parameter> with its MACattribute set to ‘Y’.6Unless the policy was so simple it only had a single state, in which case it could be implemented on a stateless

firewall.

158


Auditing

Tracking user sessions in an application-level firewall allows the firewall to performauditingin which it records each user’s interactions with the application. The audit log can be usedto answer the question, “how did the user get here” by displaying the user’s path through theapplication. This is especially important since a user will likely not be able to simply bookmarktheir current place in the application and expect it to work indefinitely; once their session timesout they will have to re-enter the application from the beginning.

Many web-applications already individually contain code to display “breadcrumbs” – visualhints of the path taken by the user through the application. This function may be offloaded tothe application-level firewall and the code shared across multiple applications. Auditing is alsovery useful in the case of error conditions. A user can be told how they managed to trigger theerror so that hopefully they will not repeat their mistake again.

7.2.4 SWIL

The SWIL language, described in Chapter 6 allows the acceptable order of URI invocations tobe defined as a sequence accepted by a deterministic finite state automaton. The implementationconsists of a firewall policy module stub which communicates with a SWIL interpreter runningin a separate O’Caml thread. The diagram in Figure 7.8 shows a typical configuration of thefirewall. Notice that the session tracking module must be on the data-path before the SWILinterpreter since the SWIL interpreter relies on having access to user session state informa-tion. The SWIL policy module is connected to the interpreter thread by a pair of synchronousO’Caml channels represented by arrows and external functions (mapped to O’Caml functions)are represented by a set of square boxes. More details of the SWIL interpreter functionalitywere given back in Section 6.5.

On receiving a request the policy module creates a SWIL request object: a record consistingof every field mentioned by a call toGetField in the SWIL program. This data is sent via thesynchronous channel to the interpreter thread which responds by sending back a boolean valueon the output channel: true if the request was accepted and false if the machine has entered theerror state.

If the module has been configured to perform dynamic response transformation (describedin Section 6.5.1) then, on receiving a response message the module parses the HTML docu-ment to extract all the links and forms. These are then communicated to the interpreter threadwhich decides if any should be deleted or greyed out. The HTML is then rewritten with all theoffending links and forms modified.

7.2.5 Raw Performance

In this section basic performance results of the prototype SPECTRE system are presented fo-cusing mainly on measurements of latency and throughput.

Figure 7.9 shows the worst-case latency of the firewall prototype and compares it to thelatency of other common types of HTTP processing. The results were measured by fetchingthe homepage of the Laboratory for Communication Engineering (University of Cambridge)7

augmented with the web-form described in the case-study of Section 5.5. The leftmost barshows the latency added by a Squid [8] proxy cache when fetching a statically compiled versionof the page; the middle bar shows the added latency of dynamically generating the page usingPHP and a MySQL [5] back-end; the rightmost bar shows the latency of using the firewall to

7http://www-lce.eng.cam.ac.uk/

159


interpreterthread

fn

f1

input output

firewall

state trackingmodule

Figure 7.8: A configuration of the application-level firewall with two modules arranged in apipeline. The first module is the state tracking module from Section 7.2.3 while the second isthe SWIL module from Section 7.2.4.

HTTP-proxy

Dynamic Generation

Security Gateway

0

10

20

30

Add

ition

al L

aten

cy P

er-r

eque

st (

ms)

Figure 7.9: A comparison of the latency of the system with latencies incurred in commontypes of HTTP processing. Note the third bar has been subdivided into two parts; the lowerbar represents latency due to message buffering while the upper bar represents latency due toparsing and rewriting HTML.

160


Request Validation and Transformation

Response HTML parsingResponse HTML rewriting

Figure 7.10: A breakdown showing the relative cost of HTTP processing stages within theapplication-level firewall.

1 2 3 4 5 6 7 8

Number of client machines

0

1

2

3

4

5

6

Tot

al T

hrou

ghpu

t (M

bits

per

sec

)

Figure 7.11: Total throughput of a single firewall as the number of concurrently connectedclients varies.

enforce the security policy found in Appendix B. The final bar is divided into two sections:the (lower) solid black section represents the latency due to buffering the HTTP messages; the(upper) striped section shows the latency due to parsing the HTTP messages and annotatingthe HTML with MACs. Figure 7.10 shows the relative cost of processing HTTP requests andHTTP responses in the case of the example web-form. Note that the total processing time isdominated by the HTML parsing stage.

The latency of the system appears large compared with the latencies incurred in proxycaching and dynamic page generation. To some extent this is due to the fact that the naıveimplementation is a proof-of-concept prototype which is completely unoptimised, based uponan inefficient non-pipelined HTTP 1.0 library. However, it is recognised that the complexity ofthe application-level tasks performed by the firewall will necessarily incur more latency than thelower level manipulation performed by proxies such as Squid. Future potential optimisationsinclude (i) using a specialised HTML parser to concentrate only on relevant parts of HTMLsyntax (currently a general HTML parser is used which performs a great deal of unnecessarywork); (ii ) reducing latency by streaming the HTTP messages and processing them on-the-flywhenever possible; (iii ) writing speed critical parts of the firewall directly in C or implementingin hardware.

161


1 2 3 4 5 6 7 8 9 10

Number of client machines

0

5

10

15

20

25

30

Tot

al T

hrou

ghpu

t (M

bits

per

sec

)

Figure 7.12: Total throughput of a cluster of firewalls as the number of concurrently connectedclients varies.

Figure 7.11 shows how the total throughput of a single firewall varies as the number of con-currently connected clients increases. Each client is running a single threaded application con-tinuously requesting the test URI. The machines are all connected on a fast 100Mbit/s switchednetwork and the measurements were taken running the firewall on a dual Intel P-III 500 MHzduring an off-peak time when the network was idle. The throughput quickly reaches a max-imum value as the CPUs become saturated. Note that it took 3 clients to saturate 2 CPUsprobably because of lack of support for persistent connections in the HTTP library used. Again,it is claimed that optimising the code for performance and running the filter on a higher specmachine would yield a significantly higher maximum throughput.

In the case of policies like SPDL-2 which are inherently stateless one may increase through-put linearly simply by deploying multiple replicas and using a load balancing scheme8 to dis-tribute work between them (see Figure 7.12). (Note that stateful systems do not scale linearlyin this way since, ultimately, the centralised state becomes a bottleneck across the cluster.)

The measurements presented areworst casein the sense that the test policy and the testHTML were both complicated and required extensive processing within the firewall. BothSPDL-2 and SWIL have features which are particularly expensive. SPDL-2 has a number of ex-pensive features like MAC annotation and insertion of client-side Javascript. In the first versionof SPDL [144] turning on the MAC facility foranyURI would have necessitated processing theHTML output of everypage. By requiring that URIs within a single<policy> block do notreference MAC-protected URIs outside that block (see Section 5.4.1), the new system allowsthe developer to specify the set of application URIs which make use of MAC-protected client-side state and, critically,those which do not. URIs with no MAC or Javascript requirements canbe processed much more efficiently by the firewall as the HTTP response from the web-servercan be streamed to the client directly: it does not have to be parsed or re-written. Given thatprocessing the HTTP response is by far the dominant performance cost incurred by the firewall(see Figure 7.10) significant speedups are achieved.

Similarly SWIL policies comprise both an expensive part: response transformation (seeSection 6.5.1) and a cheap part: request filtering. Only the request filtering is necessary forsecurity; the response transformation exists solely to improve the user interface. Therefore if

8This assumes that load balancing can be achieved cheaply, e.g. by round-robin DNS.

162

Chapter 7. Implementation 7.3. Summary

performance is a problem the expensive response transformation can be disabled.Furthermore, it is believed that many HTML pages are simpler than the contrived example

and have fewer security constraints (i.e. shorter pages without form parameters), leading tobetteraverage caseperformance. For example consider that many of the HTTP messages wouldcontain graphics and hence would not require any processing at all. A performance-optimisedfirewall could examine the content-type header of HTTP responses, using streaming instead ofbuffering if no HTML processing is required.

In summary, the performance figures presented in this section relate to an unoptimised pro-totype under worst-case conditions. The system is designed to be scalable and optimisable andtherefore the techniques represented are claimed to be applicable in practice.

7.3 SummaryThis chapter described the implementations of the two important types of policy described inthis thesis: mobility policy and interface policy. Mobility policy consisted of both restrictionpolicy and enforcement policy, limiting and directing the movements of agents within an en-vironment permeated with location-sensors. The mobility policy system comprised two mainelements: (i) a new form of spatial middleware designed to be independent of the underlyingchoice of location-system and policy type; and (ii) client-side support code based upon the JavaAglet mobile agent system. The system was implemented and a number of issues discussed.

The interface policies were implemented through a modular application-level firewall calledSPECTRE. SPECTRE supports both stateless policies like SPDL-2 policies as well as statefulpolicies such as SWIL policies. SPECTRE was written in O’Caml on top of a custom HTTPprocessing library. The SPECTRE system was implemented and a number of encouragingperformance results were presented.

163

Chapter 8

Conclusions and Further Work

Chapter 1 stated that:

The thesis of this work is that abstracting application-level security policy (whichwe defined to be policy written to govern both themobilityandinterface behaviourof systems) is an effective technique for guarding against application-level vulner-abilities which would otherwise plague future ubiquitous computing systems.

It is time to critically evaluate this statement. We proceed by breaking down this thesisstatement into two sub-claims:

1. Abstracting application-level security policy is an effective technique for guarding againstapplication-level vulnerabilities; and

2. The application-level vulnerabilities referred to in (1) above would otherwise plague fu-ture ubiquitous computing systems.

We begin by addressing claim number 1: that the policy systems presented in this thesis are an“effective technique for guarding against application-level vulnerabilities”. Each of the policysystems presented in this thesis in Chapters 4 through 6 were presented along with realisticexamples, many of which are based on actual vulnerabilities found “in the wild” and reported inthe IT press. As each policy language was presented it was demonstrated exactly how it could beused to prevent particular vulnerabilities. Details of a prototype implementation complete withencouraging performance results was presented in Chapter 7. Since the technique of abstractingapplication-level policy was shown to be workable both in theory and in practice we claim thetechnique iseffectiveand that sub-claim 1 holds.

Furthermore we argue thatabstractingsecurity policy is a important concept in itself. Keep-ing policy specifications separate from implementation code allows the policies to be easilyanalysed (c.f. the use of SPIN in Section 6) and also serve as valuable de-facto documentation.In many cases software is built from a mixture of “off the shelf” and custom components, someonly available in binary form. It may not be possible or feasible in such systems to modify thesource code directly; in these cases abstracting security policy is the only option.

Sub-claim number 2 above claims that the application-level vulnerabilities addressed byChapters 5 through 6 would otherwise “plague future ubiquitous computing systems”. Thisclaim is justified in two further sub-claims:

1. Future ubiquitous computing systems will be constructed from large numbers of physi-cally and logically mobile processes (agents) which will make existing protection mech-anisms – network and transport-level firewalls which together form theMaginot LineofInternet security – completely redundant.

164

Chapter 8. Conclusions and Further Work

2. The application-level vulnerabilities addressed by the policy languages presented in thisthesis will be present in future systems irrespective of the exact choice of underlyingprotocols.

Consider the first claim that existing protection mechanisms will become redundant. Thisclaim is justified with arguments from Chapter 1, specifically that

• code will become more mobile as the gulf between processing speed of individual nodesand latency of inter-node communication widens;

• more devices will be physically mobile as manufacturing processes improve and embed-ded devices become networked;

• higher-level protocols (like Web Services) tunnel over other protocols, enabling them topenetrate network-level firewalls;

• the bulk of code in a system – and hence the majority of bugs – is at the application-level.

Section 1.6 argued that current firewalls are inadequate because (i) increasing mobility andprotocol tunnelling allows code to bypass the points at which the firewall rules are applied; and(ii) increasingly vulnerabilities will be discovered and exploited at the application-level, wherenetwork and transport-level firewalls have no effect.

Consider the second claim that the application-level vulnerabilities addressed by policy lan-guages described in this thesis are independent of the exact choice of underlying protocol. Thisclaim shall now be justified separately for the mobility and interface policy languages.

The mobility policy language in Chapter 4 was implemented on top of Java Aglets but onlyrelied upon two features which are present in all existing mobile agent systems. The first fea-ture is the ability to have multiple named locations co-existing on the same host, either as partof the same agent server or by running multiple servers on different ports. The second featureis the ability to interpose a policy checking module between mobile agents and their runningenvironment. We claim that these abilities are core features that will be present in all futuremobile agent systems. The enforcement mechanism described in Chapter 7 was built in acentralised fashion: one server machine maintained the authoritative model of the world andthe database of policies. This server, which is a client of the SPIRIT location service which isalso centralised, was used to authorise all agent migration requests and to take corrective actionagainst agents which were in violation of policies. This centralised security policy enforcementservice is similar to existing access control mechanisms such as NIS under Unix and ActiveDirectory under Windows. None of these systems are designed to be used over the open In-ternet but rather within individual organisations or companies. Further work would be neededto investigate ways of sensibly distributing the enforcement mechanism if operation over theInternet was required.

The interface policy languages SPDL-2 in Chapter 5 and SWIL in Chapter 6 are both lan-guages designed to protect vulnerable web-applications i.e. applications running over HTTP.However, the vulnerabilities they serve to protect against – specifically validating requests withrespect to type specifications and temporal automata – are general concepts which apply to anyRPC-based distributed system. Although the concrete details of the protocols may change (e.g.to Web-Services, XML-RPC or even CORBA), provided the same types of applications are inuse, the vulnerabilities will remain and languages like SPDL-2 and SWIL will still be useful.

165

8.1. Contributions Chapter 8. Conclusions and Further Work

To justify this claim, we now describe the applicability of these techniques first to CORBA andthen to Web-Services.

CORBA [123] allows application interfaces to be specified in an Interface Definition Lan-guage (IDL) which is then compiled into client and server code. CORBA IDL has many built-intypes includingint , string , bool andfloat . It also has support for record types, arraysand disjoint union types. CORBA has the concept of a requestContext which is similar tothe HTTP concept of a cookie. CORBA’s built-in types negate the need for the simpler SPDL-2typechecking. However it lacks anything as sophisticated as the arbitrary validation and trans-formation expressions of SPDL-2 and has no support for any kind of stateful interface checking.Support for a variant of SPDL-2 and SWIL could be added to a CORBA IDL compiler and usedto generate “proxy classes” to enforce these policies dynamically.

“Web-Services” is the name given to a suite of protocols based around exchanging XMLdocuments. The Web Service Description Language (WSDL) [40] allows the specification ofapplication interfaces in a similar fashion to CORBA IDL. The XML documents exchanged aretyped (e.g. by XML-Schemas [59]) and, like in the case of CORBA, this typing subsumes thesimpler SPDL-2 typechecking. However, also like CORBA, there are no arbitrary validation ortransformation expressions and there is no support for any kind of stateful interface checking—therefore SPDL-2 and SWIL are still useful to applications written in a Web-Services world.

8.1 ContributionsIn summary this thesis provided the following contributions:

1. the Unified Spatial Model (USM): a spatial model capable of representing simultaneouslythe physical locations of objects such as people and the virtual locations of mobile agents.The USM is the foundation of the Mobility Restriction Policy Language (MRPL) – alanguage which allows policies to be written to limit the movements of mobile agents inan environment augmented with location sensors;

2. the language SPDL-2 which allows the expression of application-level interface securitypolicies in which per-request and response validation and transformation rules can bewritten to protect web-applications from many kinds of common security vulnerabilities;and

3. the language SWIL which allows the flow of control across an application interface to bedescribed as a sequence of operations accepted by a finite state automaton. The automatoncan be both analysed statically with a model-checker and dynamically checked with anapplication-level firewall.

Together this model and these policy languages allow abstract application-level policy specifica-tions to be written to protect against many important kinds of vulnerability. These application-level policy systems have been implemented; implementation details and performance resultswere provided.

8.2 Further WorkThe systems presented in this thesis were intended to investigate ways of imposing policy toprotect vulnerable future ubiquitous computer systems. Simple prototypes were constructedand analysed. In the real world things are more complex and much more effort would need to

166

Chapter 8. Conclusions and Further Work 8.2. Further Work

be expended to make the systems robust enough to deploy. Unfortunately this would requireconsiderably more implementation time than is available during a PhD.

However there are a number of opportunities for future research based on this thesis:

• Using a location system as part of a security mechanism places a lot of emphasis on thereliability and integrity of the location system itself. It would be interesting to considerwhat could be done to make such a system more dependable, perhaps by creating a wholenew location system or by changing the types of policy which can be expressed (e.g. ratherthan saying “delete the data on this device if the device is locatedoutsidethe building”we might say “delete the data on this device if we have not been seeninsidethe buildingfor 10 minutes”).

• Spatial models like that described in Chapter 3 could be used to model non-physicalentities like network configurations (e.g. a secure network might be a separate entity froman insecure network) as well as more physical entities (e.g. the model could include doorlocks and other physical access controls).

• Although we argue that maintaining separate security policy specifications is a goodthing, it would nevertheless be useful to have a means of generating automatically atleast part of a policy for an application. Perhaps the simpler part of an SPDL-2 policycould be generated leaving the more complicated part to human policy designers.

• The prototype implementation described in Chapter 7 had encouraging performance char-acteristics. However we recognise that some applications demand extremely high perfor-mance. A major overhead of the current mechanism is the need to parse HTTP messagesand HTML responses. These overheads could be eliminated if the policy could be auto-matically “woven” (in the sense of Aspect-Oriented Programming) into the applicationsource code using an automatic tool. The resulting program would have the security codeinserted where the HTTP and HTML messages are first generated, obviating the need toparse the messages later.

• The mobility restriction policies make use of a central server with an authoritative modelof the world. It would be useful to investigate to what extent this can be distributed andcombined with a distributed location-sensing system.

167

Bibliography

[1] The<bigwig> project.http://www.brics.dk/bigwig/ . (Ref: p. 100.)

[2] The Bluetooth Specification version 1.1.http://www.bluetooth.com/ . (Ref: p. 11,24, 67.)

[3] The Meta-O’Caml project.http://www.metaocaml.org/ . (Ref: p. 134.)

[4] µitron4.0 specification version 4.00.00. http://www.ertl.jp/ITRON/SPEC/

mitron4-e.html . ITRON Committee, TRON Association. Edited by Hiroaki Takada.(Ref: p. 11.)

[5] MySQL database server. http://www.mysql.com/ . (Ref: p. 159.)

[6] The OpenBSD project.http://www.openbsd.org/ . (Ref: p. 44.)

[7] PF: The OpenBSD Packet Filter.http://www.openbsd.org/faq/pf/ . (Ref: p. 16.)

[8] Squid web proxy cache.http://www.squid-cache.org/ . (Ref: p. 159.)

[9] The Open Web Application Security Project Top Ten.http://www.owasp.org/ . (Ref:p. 85.)

[10] VxworksR©. http://www.windriver.com/ . Wind River Systems. (Ref: p. 11.)

[11] N. Adly, P. Steggles, and A. Harter. SPIRIT: a Resource Database for Mobile Users.In Proceedings of ACM CHI’97 Workshop on Ubiquitous Computing, Atlanta, Georgia,March 1997.http://citeseer.ist.psu.edu/adly97spirit.html . (Ref: p. 63,141.)

[12] Roberto M. Amadio and Sanjiva Prasad. Localities and failures (extended ab-stract). In FSTTCS, pages 205–216, 1994.http://citeseer.ist.psu.edu/

amadio95localities.html . (Ref: p. 60.)

[13] Ross J. Anderson.Security Engineering. John Wiley & Sons Inc, April 2001.http:

//www.cl.cam.ac.uk/˜rja14/book.html . (Ref: p. 39.)

[14] Ross J. Anderson and Roger M. Needham. Programming Satan’s Computer.ComputerScience Today - Recent Trends and Developments, 1000:426–440.http://citeseer.

ist.psu.edu/22376.html . (Ref: p. 39.)

[15] Ivan Arce. The rise of the gadgets.IEEE Security and Privacy, 1(5):78–81, September2003. http://csdl.computer.org/comp/mags/sp/2003/05/j5078abs.htm .(Ref: p. 11.)

168

http://www.brics.dk/bigwig/

http://www.bluetooth.com/

http://www.metaocaml.org/

http://www.ertl.jp/ITRON/SPEC/mitron4-e.html

http://www.ertl.jp/ITRON/SPEC/mitron4-e.html

http://www.mysql.com/

http://www.openbsd.org/

http://www.openbsd.org/faq/pf/

http://www.squid-cache.org/

http://www.owasp.org/

http://www.windriver.com/

http://citeseer.ist.psu.edu/adly97spirit.html

http://citeseer.ist.psu.edu/amadio95localities.html

http://citeseer.ist.psu.edu/amadio95localities.html

http://www.cl.cam.ac.uk/~rja14/book.html

http://www.cl.cam.ac.uk/~rja14/book.html

http://citeseer.ist.psu.edu/22376.html


http://csdl.computer.org/comp/mags/sp/2003/05/j5078abs.htm

BIBLIOGRAPHY BIBLIOGRAPHY

[16] P. Bahl, A. Balachandran, and V. Padmanabhan. Enhancements to the RADAR User Lo-cation and Tracking System. Technical Report MSR-TR-2000-12, Microsoft Research,February 2000.http://citeseer.ist.psu.edu/291324.html . (Ref: p. 24.)

[17] Thomas Ball and Sriram K. Rajamani. Automatically validating temporal safety prop-erties of interfaces. InProceedings of the 8th international SPIN workshop on Modelchecking of software, pages 103–122. Springer-Verlag New York, Inc., 2001.http:

//citeseer.ist.psu.edu/ball01automatically.html . (Ref: p. 132.)

[18] Mark Bartel, John Boyer, Barb Fox, Brian LaMacchia, and Ed Simon.Xml-signature syntax and processing. http://www.w3.org/TR/2002/

REC-xmldsig-core-20020212/ . W3C Recommendation. 12 February 2002.(Ref: p. 13.)

[19] BBC News. First mobile phone virus created.http://news.bbc.co.uk/1/hi/

technology/3809855.stm . (Ref: p. 9.)

[20] M. Bellare, R. Canetti, and H. Krawczyk. Keying hash functions for message authentica-tion. In Advances of Cryptology – Crypto ’96 Proceedings, volume 1109 of LNCS.Springer-Verlag, 1996. http://citeseer.ist.psu.edu/bellare96keying.

html . (Ref: p. 41, 94, 157.)

[21] Alastair R. Beresford and Frank Stajano. Location privacy in pervasive computing.IEEEPervasive Computing, 2(1):46–55, 2003. http://dx.doi.org/10.1109/MPRV.

2003.1186725 . (Ref: p. 27.)

[22] T. Berners-Lee, R. Fielding, and H. Frystyk. RFC 1945: Hypertext Transfer Protocol— HTTP/1.0, May 1996.ftp://ftp.internic.net/rfc/rfc1945.txt,ftp://

ftp.math.utah.edu/pub/rfc/rfc1945.txt . Status: INFORMATIONAL. (Ref:p. 14, 31.)

[23] Lorenzo Bettini and Rocco De Nicola. Translating strong mobility into weakmobility. In Proceedings of the 5th International Conference on MobileAgents, pages 182–197. Springer-Verlag, 2002.http://citeseer.ist.psu.edu/

bettini01translating.html . (Ref: p. 21, 77.)

[24] Lorenzo Bettini, Rocco De Nicola, Rosario Pugliese, and Gian Luigi Ferrari. Interactivemobile agents in x-klaim. InProceedings of the 7th Workshop on Enabling Technologies,pages 110–117. IEEE Computer Society, 1998.http://citeseer.ist.psu.edu/

bettini98interactive.html . (Ref: p. 80.)

[25] Lubomir F. Bic, Munehiro Fukuda, and Michael B. Dillencourt. Distributed computingusing autonomous objects.IEEE Computer, 29(8):55–61, August 1996.http://dx.

doi.org/10.1109/2.532046 . (Ref: p. 21.)

[26] Simon P. Booth and Simon B. Jones. Walk backwards to happiness - debugging bytime travel. In Automated and Algorithmic Debugging, pages 171–183, 1997.http:

//citeseer.ist.psu.edu/booth97walk.html . (Ref: p. 138.)

169


http://citeseer.ist.psu.edu/ball01automatically.html

http://citeseer.ist.psu.edu/ball01automatically.html

http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

http://news.bbc.co.uk/1/hi/technology/3809855.stm

http://news.bbc.co.uk/1/hi/technology/3809855.stm

http://citeseer.ist.psu.edu/bellare96keying.html

http://citeseer.ist.psu.edu/bellare96keying.html

http://dx.doi.org/10.1109/MPRV.2003.1186725

http://dx.doi.org/10.1109/MPRV.2003.1186725

ftp://ftp.internic.net/rfc/rfc1945.txt, ftp://ftp.math.utah.edu/pub/rfc/rfc1945.txt


http://citeseer.ist.psu.edu/bettini01translating.html

http://citeseer.ist.psu.edu/bettini01translating.html

http://citeseer.ist.psu.edu/bettini98interactive.html

http://citeseer.ist.psu.edu/bettini98interactive.html

http://dx.doi.org/10.1109/2.532046

http://dx.doi.org/10.1109/2.532046

http://citeseer.ist.psu.edu/booth97walk.html

http://citeseer.ist.psu.edu/booth97walk.html


[27] Gaetano Borriello and Roy Want. Embedded computation meets the world wide web.Communications of the ACM, 43(5):59–66, 2000.http://doi.acm.org/10.1145/

332833.332839 . (Ref: p. 12.)

[28] Claus Brabrand, Anders Moller, Mikkel Ricky, and Michael I. Schwartzbach. Power-forms: Declarative client-side form field validation.World Wide Web, 3(4):205–214,2000.http://dx.doi.org/10.1023/A:1018772405468 . (Ref: p. 100.)

[29] Orkut Buyukkokten, Hector Garcia-Molina, and Andreas Paepcke. Seeing the whole inparts: Text summarization for web browsing on handheld devices.Tenth InternationalWorld Wide Web Conference, 5 2001. http://doi.acm.org/10.1145/371920.

372178 . (Ref: p. 136.)

[30] Luca Cardelli. Building user interfaces by direct manipulation. InProceedings of the 1stannual ACM SIGGRAPH symposium on User Interface Software, pages 152–166. ACMPress, 1988.http://doi.acm.org/10.1145/62402.62428 . (Ref: p. 136.)

[31] Luca Cardelli. Obliq: A language with distributed scope. Technical Report SRC-RR-122, Digital Equipment Corporation, June 1994.http://www.hpl.hp.com/

techreports/Compaq-DEC/SRC-RR-122.html . (Ref: p. 21.)

[32] Luca Cardelli. A language with distributed scope. InConference Record of POPL’95: 22nd Annual ACM SIGPLAN-SIGACT Symposium on Principles of Program-ming Languages, San Francisco, Calif., pages 286–297, New York, NY, 1995.http:

//citeseer.ist.psu.edu/cardelli95language.html . (Ref: p. 79.)

[33] Luca Cardelli. Semistructured computation. InRevised Papers from the7th International Workshop on Database Programming Languages, pages 1–16. Springer-Verlag, 2000. http://research.microsoft.com/Users/luca/

Papers/SemistructuredComputation.A4.pdf . (Ref: p. 54.)

[34] Luca Cardelli and Andrew D. Gordon. Mobile Ambients. In M. Nivat, editor,Proceed-ings of Foundations of Software Science and Computation Structures (FoSSaCS), volume1378, pages 140–155. Springer-Verlag, Berlin, Germany, 1998.http://citeseer.

ist.psu.edu/cardelli98mobile.html . (Ref: p. 52, 61.)

[35] Luca Cardelli and Andrew D. Gordon. Anytime, anywhere: modal logics for mobileambients. InProceedings of the 27th ACM SIGPLAN-SIGACT symposium on Principlesof programming languages, pages 365–377. ACM Press, 2000.http://doi.acm.

org/10.1145/325694.325742 . (Ref: p. 71.)

[36] Luca Cardelli and Andrew D. Gordon. Mobile ambients.Theoretical ComputerScience, 240(1):177–213, 2000.http://dx.doi.org/10.1016/S0304-3975(99)

00231-5 . (Ref: p. 61.)

[37] G. Castagna and J. Vitek. Seal: A framework for secure mobile computations. InH. Bal, B. Belkhouche, and L. Cardelli, editors,Internet Programming Languages,number 1686 in Lecture Notes in Computer Science, pages 47–77. Springer, 1999.http://citeseer.ist.psu.edu/vitek99seal.html . (Ref: p. 60.)

170

http://doi.acm.org/10.1145/332833.332839

http://doi.acm.org/10.1145/332833.332839

http://dx.doi.org/10.1023/A:1018772405468

http://doi.acm.org/10.1145/371920.372178

http://doi.acm.org/10.1145/371920.372178

http://doi.acm.org/10.1145/62402.62428

http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-122.html


http://citeseer.ist.psu.edu/cardelli95language.html

http://citeseer.ist.psu.edu/cardelli95language.html

http://research.microsoft.com/Users/luca/Papers/Semistructured Computation.A4.pdf

http://research.microsoft.com/Users/luca/Papers/Semistructured Computation.A4.pdf

http://citeseer.ist.psu.edu/cardelli98mobile.html

http://citeseer.ist.psu.edu/cardelli98mobile.html

http://doi.acm.org/10.1145/325694.325742

http://doi.acm.org/10.1145/325694.325742

http://dx.doi.org/10.1016/S0304-3975(99)00231-5

http://dx.doi.org/10.1016/S0304-3975(99)00231-5

http://citeseer.ist.psu.edu/vitek99seal.html


[38] Pablo Castells, Pedro Szekely, and Ewald Salcher. Declarative models of presentation.In Proceedings of the 2nd international conference on Intelligent user interfaces, pages137–144. ACM Press, 1997.http://doi.acm.org/10.1145/238218.238315 .(Ref: p. 136.)

[39] Surendar Chandra, Carla Schlatter Ellis, and Amin Vahdat. Differentiated multimediaweb services using quality aware transcoding. InINFOCOM - Nineteenth Annual JointConference Of The IEEE Computer And Communications Societies, Tel Aviv, Israel,2000.citeseer.nj.nec.com/chandra00differentiated.html . (Ref: p. 136.)

[40] Erik Christensen, Francisco Curbera, Greg Meredith, and Sanjiva Weerawarana. WebServices Description Language (WSDL) 1.1.http://www.w3.org/TR/2001/

NOTE-wsdl-20010315 . W3C Note. 15 March 2001. (Ref: p. 166.)

[41] Joris Claessens, Bart Preneel, and Joos Vandewalle. (How) can mobile agents do secureelectronic transactions on untrusted hosts? A survey of the security issues and the currentsolutions. ACM Transactions on Internet Technology, 3(1):28–48, 2003.http://doi.

acm.org/10.1145/643477.643479 . (Ref: p. 14.)

[42] E.M. Clarke, O. Grumberg, and D. Peled.Model Checking. Cambridge, MA: MITPress, 1999.http://mitpress.mit.edu/catalog/item/default.asp?ttype=

2&tid=3730 . (Ref: p. 44, 131.)

[43] Sylvain Conchon and Fabrice Le Fessant. Jocaml: Mobile Agents for Objective-Caml.In First International Symposium on Agent Systems and Applications (ASA’99)/ThirdInternational Symposium on Mobile Agents (MA’99), Palm Springs, CA, USA, 1999.http://citeseer.ist.psu.edu/conchon99jocaml.html . (Ref: p. 79.)

[44] James C. Corbett, Matthew B. Dwyer, John Hatcliff, and Roby. Bandera: a source-levelinterface for model checking java programs. InProceedings of the 22nd internationalconference on Software engineering, pages 762–765. ACM Press, 2000.http://doi.

acm.org/10.1145/337180.337625 . (Ref: p. 131.)

[45] Umeshwar Dayal, Eric N. Hanson, and Jennifer Widom. Active database systems. InModern Database Systems, pages 434–456. 1995.http://citeseer.ist.psu.edu/

dayal94active.html . (Ref: p. 73.)

[46] Luca de Alfaro and Thomas A. Henzinger. Interface automata. InProceedings of the 8thEuropean software engineering conference held jointly with 9th ACM SIGSOFT interna-tional symposium on Foundations of software engineering, pages 109–120. ACM Press,2001.http://doi.acm.org/10.1145/503209.503226 . (Ref: p. 27, 106, 133.)

[47] Diego Lopez de Ipina and Sai-Lai Lo. LocALE: a Location-Aware Lifecycle Environ-ment for Ubiquitous Computing. In15th International Conference on Information Net-working (ICOIN’01), 1 2001.http://www-lce.eng.cam.ac.uk/publications/

files/tr.2001.9.pdf . (Ref: p. 81.)

[48] Diego Lpez de Ipia and Sai Lai Lo. Sentient Computing for Everyone. InThird IFIPWG 6.1 International Working Conference on Distributed Applications and Interopera-ble Systems (DAIS’2001), pages 41–54, 09 2001.http://citeseer.ist.psu.edu/

513263.html . (Ref: p. 81.)

171

http://doi.acm.org/10.1145/238218.238315

citeseer.nj.nec.com/chandra00differentiated.html

http://www.w3.org/TR/2001/NOTE-wsdl-20010315

http://www.w3.org/TR/2001/NOTE-wsdl-20010315

http://doi.acm.org/10.1145/643477.643479

http://doi.acm.org/10.1145/643477.643479

http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=3730


http://citeseer.ist.psu.edu/conchon99jocaml.html

http://doi.acm.org/10.1145/337180.337625

http://doi.acm.org/10.1145/337180.337625

http://citeseer.ist.psu.edu/dayal94active.html

http://citeseer.ist.psu.edu/dayal94active.html

http://doi.acm.org/10.1145/503209.503226

http://www-lce.eng.cam.ac.uk/publications/files/tr.2001.9.pdf





[49] Rocco de Nicola, Gian Luigi Ferrari, and Rosario Pugliese. Klaim: A kernel languagefor agents interaction and mobility. IEEE Trans. Softw. Eng., 24(5):315–330, 1998.http://dx.doi.org/10.1109/32.685256 . (Ref: p. 80.)

[50] Dorothy E. Denning and Peter J. Denning. Certification of programs for secure in-formation flow. Communications of the ACM, 20(7):504–513, July 1977.http:

//doi.acm.org/10.1145/359636.359712 . (Ref: p. 12.)

[51] David L. Detlefs, K. Rustan M. Leino, Greg Nelson, and James B. Saxe. Extended staticchecking. Technical Report 159, Compaq SRC, December 1998.http://www.hpl.

hp.com/techreports/Compaq-DEC/SRC-RR-159.html . (Ref: p. 27.)

[52] Anind K. Dey and Gregory D.Abowd. Towards a better understanding of context andcontext-awareness. InProceedings of the CHI 2000 Workshop on ”The What, Who,Where, When, Why and How of Context-Awareness”, 2000.http://www.cc.gatech.

edu/fce/ctk/pubs/HUC99-panel.pdf . (Ref: p. 63.)

[53] T. Dierks and C. Allen. RFC 2246: The TLS protocol version 1, January1999. ftp://ftp.internic.net/rfc/rfc2246.txt,ftp://ftp.math.utah.

edu/pub/rfc/rfc2246.txt . Status: PROPOSED STANDARD. (Ref: p. 137.)

[54] Fred Douglis and John K. Ousterhout. Transparent process migration: Design alterna-tives and the sprite implementation.Software - Practice and Experience, 21(8):757–785,1991.http://citeseer.ist.psu.edu/douglis91transparent.html . (Ref: p.19.)

[55] Tudor Dumitras, Sam Kerner, and Radu Marculescu. Towards on-chip fault-tolerantcommunication. InProc. Asia & South Pacific Design Automation Conf. (ASP-DAC),January 2003.http://www.gigascale.org/pubs/410.html . (Ref: p. 13.)

[56] Matthew B. Dwyer and Corina S. Pasareanu. Filter-based model checking of par-tial systems. In Proceedings of the 6th ACM SIGSOFT international symposiumon Foundations of software engineering, pages 189–202. ACM Press, 1998.http:

//doi.acm.org/10.1145/288195.288307 . (Ref: p. 131.)

[57] eEye Digital Security. %u-encoding IDS bypass vulnerability.http://www.eeye.

com/html/Research/Advisories/AD20010705.html . Advisory AD20010705.(Ref: p. 156.)

[58] Vadim Engelson, Dag Fritzson, and Peter Fritzson. Automatic generationof user interfaces from data structure specifications and object-oriented applica-tion models. In P. Cointe, editor, Proceedings ECOOP ’96, pages 114–141, Linz, Austria, 1996. Springer-Verlag. http://citeseer.ist.psu.edu/

engelson96automatic.html . (Ref: p. 136.)

[59] David C. Fallside and Priscilla Walmsley. XML Schema Part 0: Primer Secnd Edition,October 2004.http://www.w3c.org/TR/2004/REC-xmlschema-0-20041028/ .W3C Recommendation. (Ref: p. 166.)

172

http://dx.doi.org/10.1109/32.685256

http://doi.acm.org/10.1145/359636.359712

http://doi.acm.org/10.1145/359636.359712



http://www.cc.gatech.edu/fce/ctk/pubs/HUC99-panel.pdf

http://www.cc.gatech.edu/fce/ctk/pubs/HUC99-panel.pdf



http://citeseer.ist.psu.edu/douglis91transparent.html

http://www.gigascale.org/pubs/410.html

http://doi.acm.org/10.1145/288195.288307

http://doi.acm.org/10.1145/288195.288307

http://www.eeye.com/html/Research/Advisories/AD20010705.html

http://www.eeye.com/html/Research/Advisories/AD20010705.html

http://citeseer.ist.psu.edu/engelson96automatic.html

http://citeseer.ist.psu.edu/engelson96automatic.html

http://www.w3c.org/TR/2004/REC-xmlschema-0-20041028/


[60] Federal Communications Commission. Enhanced 911.http://www.fcc.gov/911/

enhanced/ . (Ref: p. 26.)

[61] G. Ferrari, C. Montangero, L. Semini, and S. Semprini. The Mobadtl model and methodto design network aware applications. Technical Report TR-03-08, University of Pisa,Computer Science Dept, June 2003.ftp://ftp.di.unipi.it/pub/techreports/

TR-03-08.ps.Z . (Ref: p. 60.)

[62] Gianluigi Ferrari, C. Montangero, L. Semini, and S. Semprini. Mark, a reasoning kit formobility. Automated Software Eng., 9(2):137–150, 2002.http://dx.doi.org/10.

1023/A:1014530313153 . (Ref: p. 60.)

[63] Richard Phillips Feynman. ”Surely you’re joking, Mr. Feynman!”: Adventuresof a curious character (Reprint Edition). W. W. Norton and Company, April1997. http://www.amazon.com/exec/obidos/tg/detail/-/0393316041/

102-8071009-6672113?v=glance . (Ref: p. 42.)

[64] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, andT. Berners-Lee. RFC 2616: Hypertext Transfer Protocol — HTTP/1.1, June1999. ftp://ftp.internic.net/rfc/rfc2616.txt,ftp://ftp.math.utah.

edu/pub/rfc/rfc2616.txt . Status: DRAFT STANDARD. (Ref: p. 30.)

[65] R.J. Fontana, E. Richley, and J. Barney. Commercialization of an ultra wideband preci-sion asset location system. InIEEE Conference on Ultra Wideband Systems and Tech-nologies, November 2003.http://ieeexplore.ieee.org/xpl/abs_free.jsp?

arNumber=1267866 . (Ref: p. 24.)

[66] OASIS (Organization for the Advancement of Structured Information Standards). Xacmllanguage proposal, January 2002.http://www.oasis-open.org/committees/

xacml . version 0.8. (Ref: p. 13.)

[67] Ian T. Foster. The anatomy of the grid: Enabling scalable virtual organizations.In Proceedings of the 7th International Euro-Par Conference Manchester on ParallelProcessing, pages 1–4. Springer-Verlag, 2001.http://citeseer.ist.psu.edu/

foster01anatomy.html . (Ref: p. 13.)

[68] Cedric Fournet and Georges Gonthier. The reflexive chemical abstract machine andthe join-calculus. In Proceedings of the 23rd ACM Symposium on Principles of Pro-gramming Languages (POPL’96), Jan 1996.http://research.microsoft.com/

˜fournet/papers/reflexive-cham-join-calculus.ps . (Ref: p. 62.)

[69] Cedric Fournet, Georges Gonthier, Jean-Jacques Levy, Luc Maranget, and Didier Remy.A calculus of mobile agents. InProceedings of the 7th International Conference onConcurrency Theory (CONCUR’96), pages 406–421. Springer-Verlag, 1996.http://

citeseer.ist.psu.edu/fournet96calculus.html . (Ref: p. 62.)

[70] Cedric Fournet, Jean-Jacques Levy, and Alan Schmitt. An Asynchronous, DistributedImplementation of Mobile Ambients. InIFIP TCS, pages 348–364, 2000.http://

citeseer.ist.psu.edu/319659.html . (Ref: p. 79.)

173

http://www.fcc.gov/911/enhanced/

http://www.fcc.gov/911/enhanced/

ftp://ftp.di.unipi.it/pub/techreports/TR-03-08.ps.Z

ftp://ftp.di.unipi.it/pub/techreports/TR-03-08.ps.Z

http://dx.doi.org/10.1023/A:1014530313153

http://dx.doi.org/10.1023/A:1014530313153

http://www.amazon.com/exec/obidos/tg/detail/-/0393316041/102-8071009-6672113?v=glance




http://ieeexplore.ieee.org/xpl/abs_free.jsp?arNumber=1267866

http://ieeexplore.ieee.org/xpl/abs_free.jsp?arNumber=1267866

http://www.oasis-open.org/committees/xacml

http://www.oasis-open.org/committees/xacml

http://citeseer.ist.psu.edu/foster01anatomy.html

http://citeseer.ist.psu.edu/foster01anatomy.html

http://research.microsoft.com/~fournet/papers/reflexive-cham-join-calculus.ps

http://research.microsoft.com/~fournet/papers/reflexive-cham-join-calculus.ps

http://citeseer.ist.psu.edu/fournet96calculus.html

http://citeseer.ist.psu.edu/fournet96calculus.html




[71] Stan Franklin and Art Graesser. Is it an agent, or just a program?: A taxonomy forautonomous agents. In Jorg P. Muller, Michael Wooldridge, and Nicholas R. Jennings,editors, Intelligent Agents III, Agent Theories, Architectures, and Languages, ECAI ’96Workshop (ATAL), Budapest, Hungary, August 12-13, 1996, Proceedings, volume 1193of Lecture Notes in Computer Science, pages 21–35. Springer-Verlag, 1997.http:

//citeseer.ist.psu.edu/franklin96is.html . (Ref: p. 19.)

[72] Alessandro Giacalone, Prateek Mishra, and Sanjiva Prasad. Facile: a symmetric integra-tion of concurrent and functional programming.Int. J. Parallel Program., 18(2):121–160, 1990.http://portal.acm.org/citation.cfm?id=78098 . (Ref: p. 60, 79.)

[73] Virgil D. Gligor. Characteristics of role-based access control. InACM Workshop on Role-Based Access Control, 1995. http://doi.acm.org/10.1145/270152.270169 .(Ref: p. 13.)

[74] L. Gong, M. Mueller, H. Prafullchandra, and R. Schemers. Going Beyond the Sandbox:An Overview of the New Security Architecture in the Java Development Kit 1.2. InUSENIX Symposium on Internet Technologies and Systems, pages 103–112, Monterey,CA, 1997.http://citeseer.ist.psu.edu/410667.html . (Ref: p. 78.)

[75] K. Gottschalk, S. Graham, H. Kreger, and J. Snell. Introduction to web services ar-chitecture. IBM Systems Journal, 41(2), 2002.http://www.research.ibm.com/

journal/sj/412/gottschalk.pdf . (Ref: p. 14.)

[76] Paul Graunke, Robert Bruce Finder, Shriram Krishnamurthi, and Matthias Felleisen. Au-tomatically restructuring programs for the web. 2001.http://citeseer.ist.psu.

edu/626882.html . (Ref: p. 131, 138.)

[77] Paul T. Graunke, Robert Bruce Findler, Shriram Krishnamurthi, and Matthias Felleisen.Modeling web interactions. In Pierpaolo Degano, editor,Proceeedings of ESOP 2003,volume 2618 of Lecture Notes in Computer Science, pages 238–252. Springer Ver-lag, April 2003.http://www.ccs.neu.edu/scheme/pubs/esop2003-gfkf.pdf .(Ref: p. 100.)

[78] Neil Gross. The earth will don an electronic skin.http://www.businessweek.com/

1999/99_35/b3644024.htm . BusinessWeek, Aug. 30, 1999. (Ref: p. 11.)

[79] GSM Association. SE.23 Permanent Reference Document on Location BasedServices.http://www.gsmworld.com/technology/applications/location.

shtml . (Ref: p. 24.)

[80] David A. Halls and Sean G. Rooney. Controlling the Tempest: Adaptive man-agement in advanced ATM control architectures.IEEE Journal on Selected Ar-eas in Communications, 16(3):414–423, 1998.http://citeseer.ist.psu.edu/

halls98controlling.html . (Ref: p. 23.)

[81] David Alan Halls. Applying Mobile Code to Distributed Systems. PhD thesis, Universityof Cambridge, 1997.http://citeseer.ist.psu.edu/halls97applying.html .(Ref: p. 23.)

174

http://citeseer.ist.psu.edu/franklin96is.html

http://citeseer.ist.psu.edu/franklin96is.html

http://portal.acm.org/citation.cfm?id=78098

http://doi.acm.org/10.1145/270152.270169


http://www.research.ibm.com/journal/sj/412/gottschalk.pdf

http://www.research.ibm.com/journal/sj/412/gottschalk.pdf



http://www.ccs.neu.edu/scheme/pubs/esop2003-gfkf.pdf

http://www.businessweek.com/1999/99_35/b3644024.htm

http://www.businessweek.com/1999/99_35/b3644024.htm

http://www.gsmworld.com/technology/applications/location.shtml

http://www.gsmworld.com/technology/applications/location.shtml

http://citeseer.ist.psu.edu/halls98controlling.html

http://citeseer.ist.psu.edu/halls98controlling.html

http://citeseer.ist.psu.edu/halls97applying.html


[82] Richard Han, Pravin Bhagwat, Richard LaMaire, Todd Mummert, Veronique Perret, andJim Rubas. Dynamic adaptation in an image transcoding proxy for mobile WWW brows-ing. IEEE Personal Communication, 5(6):8–17, 1998.http://ieeexplore.ieee.

org/iel4/98/15881/00736473.pdf . (Ref: p. 136.)

[83] K. Havelund and T. Pressburger. Model checking java programs using java pathfinder.International Journal on Software Tools for Technology Transfer, STTT, 2(4), April 2000.http://citeseer.ist.psu.edu/havelund98model.html . (Ref: p. 131.)

[84] Jeffrey Hightower and Gaetano Borriello. A survey and taxonomy of location sens-ing systems for ubiquitous computing. UW CSE 01-08-03, University of Washing-ton, Department of Computer Science and Engineering, Seattle, WA, August 2001.http://citeseer.ist.psu.edu/hightower01survey.html . (Ref: p. 23.)

[85] Jeffrey Hightower, Barry Brumitt, and Gaetano Borriello. The location stack: A layeredmodel for location in ubiquitous computing. InProceedings of the 4th IEEE Workshopon Mobile Computing Systems & Applications (WMCSA 2002), pages 22–28, Callicoon,NY, June 2002. IEEE Computer Society Press.http://csdl.computer.org/comp/

proceedings/wmcsa/2002/1647/00/16470022abs.htm . (Ref: p. 63.)

[86] Bernhard Hofmann-Wellenhof, Herbert Lichtenegger, and James Collins.GlobalPositioning System: Theory and Practice. Springer-Verlag, 5th edition, March2001. http://www.amazon.com/exec/obidos/tg/detail/-/3211828397/

102-8071009-6672113?v=glance . (Ref: p. 24.)

[87] Matthew Hohlfeld and Bennet Yee. How to migrate agents, Aug 1998.http:

//citeseer.ist.psu.edu/hohlfeld98how.html . (Ref: p. 21, 77.)

[88] G. J. Holzmann and M. H. Smith. An automated verification method for distributedsystems software based on model extraction.IEEE Trans. Softw. Eng., 28(4):364–377,2002.http://dx.doi.org/10.1109/TSE.2002.995426 . (Ref: p. 131.)

[89] Gerard J. Holzmann.The SPIN Model Checker : Primer and Reference Manual title.Pearson Educational, September 2003.http://www.awprofessional.com/title/

0321228626 . (Ref: p. 44.)

[90] Kohei Honda and Mario Tokoro. An object calculus for asynchronous communication.Lecture Notes in Computer Science, 512:133–147, 1991.http://citeseer.ist.

psu.edu/honda91object.html . (Ref: p. 60.)

[91] Andy Hopper. 1999 Sentient Computing.Phil. Trans. R. Soc. Lond., 358(1):2349–2358,2000. http://www-lce.eng.cam.ac.uk/publications/files/tr.1999.12.

pdf . (Ref: p. 67.)

[92] Richard Hull, Philip Neaves, and James Bedford-Roberts. Towards situated computing.In Proceedings of the 1st IEEE International Symposium on Wearable Computers, page146. IEEE Computer Society, 1997.http://computer.org/conferen/proceed/

8192/pdf/81920146.pdf . (Ref: p. 63.)

175

http://ieeexplore.ieee.org/iel4/98/15881/00736473.pdf

http://ieeexplore.ieee.org/iel4/98/15881/00736473.pdf

http://citeseer.ist.psu.edu/havelund98model.html

http://citeseer.ist.psu.edu/hightower01survey.html

http://csdl.computer.org/comp/proceedings/wmcsa/2002/1647/00/16470022abs.htm

http://csdl.computer.org/comp/proceedings/wmcsa/2002/1647/00/16470022abs.htm



http://citeseer.ist.psu.edu/hohlfeld98how.html

http://citeseer.ist.psu.edu/hohlfeld98how.html

http://dx.doi.org/10.1109/TSE.2002.995426

http://www.awprofessional.com/title/0321228626

http://www.awprofessional.com/title/0321228626

http://citeseer.ist.psu.edu/honda91object.html

http://citeseer.ist.psu.edu/honda91object.html



http://computer.org/conferen/proceed/8192/pdf/81920146.pdf

http://computer.org/conferen/proceed/8192/pdf/81920146.pdf


[93] IEEE. Telecommunications and Information Exchange Between Systems - Local andMetropolitan Area Network - Part 11: Wireless LAN Medium Access Control and Physi-cal Layer Specifications. 1999. (Ref: p. 11, 24, 67.)

[94] Takeshi Imamura, Blair Dillaway, and Ed Simon. Xml encryption syntax and process-ing. http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/ . W3C Rec-ommendation. 10 December 2002. (Ref: p. 13.)

[95] Internet Security Systems (ISS). Form tampering vulnerabilities in several web-basedshopping cart applications.http://xforce.iss.net/alerts/advise42.php . ISSalert. (Ref: p. 43, 83.)

[96] Yannis E. Ioannidis and Timos K. Sellis. Conflict resolution of rules assigning values tovirtual attributes. InProceedings of the 1989 ACM SIGMOD international conference onManagement of data, 1989. http://doi.acm.org/10.1145/67544.66945 . (Ref:p. 73.)

[97] Kjetil Jacobsen and Dag Johansen. Mobile Software on Mobile Hardware – Experienceswith TACOMA on PDAs. Technical report, Department of Computer Science, Universityof Tromsø, Norway, 12 1997.http://www.cs.uit.no/forskning/rapporter/

Reports/9732.html . (Ref: p. 78.)

[98] Kjetil Jacobsen and Dag Johansen. Ubiquitous Devices United: Enabling DistributedComputing Through Mobile Code. InProceedings of the Symposium on Applied Com-puting (ACM SAC’99), February 1999.http://doi.acm.org/10.1145/298151.

298395 . (Ref: p. 78.)

[99] Dag Johansen. Mobile agents: Right concept wrong approach. InMobileData Management. Proceedings of the 5th IEEE International Conference on Mo-bile Data Management (MDM 2004), pages 300–301. IEEE Computer Society,2004. http://csdl.computer.org/comp/proceedings/mdm/2004/2070/00/

20700300abs.htm . (Ref: p. 77.)

[100] Dag Johansen, K. J. Lauvset, Robbert van Renesse, Fred B. Schneider, Nils P. Sudmann,and Kjetil Jacobsen. A TACOMA retrospective.Softw. Pract. Exper., 32(6):605–619,2002.http://dx.doi.org/10.1002/spe.451 . (Ref: p. 78.)

[101] Dag Johansen, Robbert van Renesse, and Fred B Schneider. An Introduction to theTACOMA Distributed System Version 1.0. Technical Report 95-23, Department of Com-puter Science, University of Tromsø, Norway, 6 1995.http://citeseer.ist.psu.

edu/johansen95introduction.html . (Ref: p. 77, 78.)

[102] J. M. Kahn, R. H. Katz, and K. S. J. Pister. Next century challenges: Mobile net-working for ”smart dust”. In International Conference on Mobile Computing andNetworking (MOBICOM), pages 271–278, 1999.http://citeseer.ist.psu.edu/

kahn99next.html . (Ref: p. 11, 66.)

[103] Eleftheria Katsiri and Alan Mycroft. Knowledge representation and scalable abstractreasoning for sentient computing using first-order logic. InChallenges and Novel Appli-cations for Automated Reasoning Workshop, Miami, July 2003.http://www.uclic.

ucl.ac.uk/usr/jgow/nads03/katsiri.pdf . (Ref: p. 64.)

176

http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/

http://xforce.iss.net/alerts/advise42.php

http://doi.acm.org/10.1145/67544.66945

http://www.cs.uit.no/forskning/rapporter/Reports/9732.html

http://www.cs.uit.no/forskning/rapporter/Reports/9732.html

http://doi.acm.org/10.1145/298151.298395

http://doi.acm.org/10.1145/298151.298395

http://csdl.computer.org/comp/proceedings/mdm/2004/2070/00/20700300abs.htm

http://csdl.computer.org/comp/proceedings/mdm/2004/2070/00/20700300abs.htm

http://dx.doi.org/10.1002/spe.451

http://citeseer.ist.psu.edu/johansen95introduction.html

http://citeseer.ist.psu.edu/johansen95introduction.html

http://citeseer.ist.psu.edu/kahn99next.html

http://citeseer.ist.psu.edu/kahn99next.html

http://www.uclic.ucl.ac.uk/usr/jgow/nads03/katsiri.pdf

http://www.uclic.ucl.ac.uk/usr/jgow/nads03/katsiri.pdf


[104] A. Kerckhoffs. La cryptographie militaire. pages 5–38, Jan 1883.http://www.cl.

cam.ac.uk/users/fapp2/kerckhoffs/ . (Ref: p. 40.)

[105] Hairong Kuang, Lubomir F. Bic, and Michael B. Dillencourt. Iterative grid-basedcomputing using mobile agents. In Tarek S. Abdelrahman, editor,Proceedingsof the 2002 Intternational Conference on Parallel Processing, pages 109–117, LosAlamitos, Calif., August 2002. The International Association for Computers and Com-munications (IACC), IEEE Computer Society.http://citeseer.ist.psu.edu/

kuang02iterative.html . (Ref: p. 13.)

[106] Danny B. Lange and Mitsuru Oshima.Programming and Deploying Java Mobile Agentswith Aglets. Addison Wesley, 1998.http://www.awprofessional.com/titles/

0-201-32582-9/ . (Ref: p. 21, 78.)

[107] Danny B. Lange and Mitsuru Oshima. Seven good reasons for mobile agents.Commu-nications of the ACM, 42(3):88–89, March 1999.http://doi.acm.org/10.1145/

295685.298136 . (Ref: p. 13.)

[108] Xavier Leroy. The Objective Caml System Release 3.0. INRIA, Rocquencourt, France,2000. http://pauillac.inria.fr/caml/ocaml/htmlman/index.html . (Ref:p. 102.)

[109] John Leyden. Mosquitos smartphone ’trojan’ there by design, Aug 2004.http://www.

theregister.co.uk/2004/08/11/mosquitos_malware_myth/ . (Ref: p. 9.)

[110] J.C.R. Licklider. Man-computer symbiosis.IRE Transactions on Human Factors inElectronics, HFE-1:4–11, March 1960.http://medg.lcs.mit.edu/people/psz/

Licklider.html . (Ref: p. 11.)

[111] Jorge Lobo, Randeep Bhatia, and Shamim A. Naqvi. A policy description lan-guage. In AAAI/IAAI, pages 291–298, 1999.http://citeseer.ist.psu.edu/

lobo99policy.html . (Ref: p. 13.)

[112] Siegfied Loeffler and Ahmen Serhouchni. Creating implementations from PROMELAmodels. In Proceedings of the SPIN96 DIMACS Workshop, pages 72–80.http://

citeseer.ist.psu.edu/168908.html . (Ref: p. 132.)

[113] Laura Lorek. New e-rip-off maneuver: Swapping price tags.http://www.zdnet.

com/intweek/stories/news/0,4164,2692337,00.html . ZD-Net. 5th March,2001. (Ref: p. 43, 83, 85.)

[114] A. Madhavapeddy, A. Mycroft, D. Scott, and R. Sharp. The case for abstracting se-curity policies. In Proceedings of the 2003 International Conference on Securityand Management (SAM’03). http://www.cl.cam.ac.uk/Research/SRG/netos/

papers/2003-sam-secpol.pdf . (Ref: p. 132.)

[115] R. Milner. A Calculus of Communicating Systems. Springer-Verlag New York, Inc.,1982.http://portal.acm.org/citation.cfm?id=539036 . (Ref: p. 79.)

177

http://www.cl.cam.ac.uk/users/fapp2/kerckhoffs/

http://www.cl.cam.ac.uk/users/fapp2/kerckhoffs/

http://citeseer.ist.psu.edu/kuang02iterative.html

http://citeseer.ist.psu.edu/kuang02iterative.html

http://www.awprofessional.com/titles/0-201-32582-9/

http://www.awprofessional.com/titles/0-201-32582-9/

http://doi.acm.org/10.1145/295685.298136

http://doi.acm.org/10.1145/295685.298136

http://pauillac.inria.fr/caml/ocaml/htmlman/index.html

http://www.theregister.co.uk/2004/08/11/mosquitos_malware_myth/

http://www.theregister.co.uk/2004/08/11/mosquitos_malware_myth/

http://medg.lcs.mit.edu/people/psz/Licklider.html

http://medg.lcs.mit.edu/people/psz/Licklider.html

http://citeseer.ist.psu.edu/lobo99policy.html

http://citeseer.ist.psu.edu/lobo99policy.html



http://www.zdnet.com/intweek/stories/news/0,4164,2692337,00.html

http://www.zdnet.com/intweek/stories/news/0,4164,2692337,00.html

http://www.cl.cam.ac.uk/Research/SRG/netos/papers/2003-sam-secpol.pdf

http://www.cl.cam.ac.uk/Research/SRG/netos/papers/2003-sam-secpol.pdf



[116] R. Milner, M. Tofte, R. Harper, and D. MacQueen.The Definition of Standard ML (Re-vised). MIT Press, 1997.http://mitpress.mit.edu/catalog/item/default.

asp?ttype=2&tid=3874 . (Ref: p. 79, 92.)

[117] Robin Milner. Communicating and Mobile Systems: Theπ Calculus. Cambridge Uni-versity Press, May 1999.http://portal.acm.org/citation.cfm?id=329902 .(Ref: p. 60, 62.)

[118] Carlo Montangero and Laura Semini. Distributed states logic. InProceed-ings of the Ninth International Symposium on Temporal Representation and Reason-ing (TIME’02), July 2002. http://doi.ieeecomputersociety.org/10.1109/

TIME.2002.1027474 . (Ref: p. 61.)

[119] George C. Necula. Proof-carrying code. InProceedings of the 24th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Langauges (POPL ’97), pages 106–119, Paris, January 1997.http://citeseer.ist.psu.edu/50371.html . (Ref: p.132.)

[120] Roger M. Needham and Sape J. Mullender. Names.http://wwwhome.cs.utwente.

nl/˜sape/gos/chap12.pdf . (Ref: p. 31.)

[121] Bruce Jay Nelson. Remote Procedure Call. PhD thesis, Carnegie-Mellon University,1981. Published as CMU technical report CMU-CS-81-119. (Ref: p. 27.)

[122] Rocco De Nicola, Gian Luigi Ferrari, and Rosario Pugliese. Programming access control:The klaim experience. InProceedings of the 11th International Conference on Con-currency Theory, pages 48–65. Springer-Verlag, 2000.http://portal.acm.org/

citation.cfm?id=701626 . (Ref: p. 80.)

[123] Object Management Group. Common Object Request Broker Architecture(CORBA/IIOP), 1995.http://www.corba.org/ . (Ref: p. 63, 81, 136, 166.)

[124] A. M. Odlyzko. Privacy, economics, and price discrimination on the internet. InICEC2003: Fifth International Conference on Electronic Commerce, pages 355–366.ACM. http://citeseer.ist.psu.edu/675573.html . (Ref: p. 22.)

[125] Open GIS Consortium, Inc. OpenGIS Simple Features Specification for SQL version1.1, 1998.http://www.opengis.org/docs/99-049.pdf . (Ref: p. 65.)

[126] L. Paulson and T. Nipkow. Isabelle.http://www.cl.cam.ac.uk/Research/HVG/

Isabelle . (Ref: p. 60.)

[127] John Pescatore. Web services: Application-level firewalls required.http://www4.

gartner.com/DisplayDocument?id=353429 . Gartner, Inc. Report. 7th March,2002. (Ref: p. 9, 16, 43.)

[128] K. Pier and J. Landay. Issues for location-independent interfaces. Technical ReportISTL92-4, Xerox Palo Alto Research Center, December 1992.http://citeseer.

ist.psu.edu/pier92issues.html . (Ref: p. 136.)

178




http://doi.ieeecomputersociety.org/10.1109/TIME.2002.1027474

http://doi.ieeecomputersociety.org/10.1109/TIME.2002.1027474


http://wwwhome.cs.utwente.nl/~sape/gos/chap12.pdf

http://wwwhome.cs.utwente.nl/~sape/gos/chap12.pdf



http://www.corba.org/


http://www.opengis.org/docs/99-049.pdf

http://www.cl.cam.ac.uk/Research/HVG/Isabelle

http://www.cl.cam.ac.uk/Research/HVG/Isabelle

http://www4.gartner.com/DisplayDocument?id=353429

http://www4.gartner.com/DisplayDocument?id=353429

http://citeseer.ist.psu.edu/pier92issues.html

http://citeseer.ist.psu.edu/pier92issues.html


[129] Benjamin C. Pierce and David N. Turner. Pict: A programming language based on thepi-calculus. In G. Plotkin, C. Stirling, and M. Tofte, editors,Proof, Language andInteraction: Essays in Honour of Robin Milner. MIT Press, 2000.http://citeseer.

ist.psu.edu/article/pierce97pict.html . (Ref: p. 60.)

[130] Nissanka B. Priyantha, Anit Chakraborty, and Hari Balakrishnan. The cricket location-support system. InProceedings of the 6th annual international conference on Mobilecomputing and networking, pages 32–43. ACM Press, 2000.http://doi.acm.org/

10.1145/345910.345917 . (Ref: p. 24.)

[131] Christian Queinnec. The influence of browsers on evaluators or, continuations to programweb servers. InInternational Conference on Functional Programming, pages 23–33,2000. http://citeseer.ist.psu.edu/queinnec00influence.html . (Ref: p.138.)

[132] Jim Reavis. Layer seven: The future of vulnerabilities.http://www.spidynamics.

com/ . SPI Dynamics White Paper. (Ref: p. 43.)

[133] J. H. Reppy. Concurrent Programming with Events—The Concurrent ML Manual.AT&T Bell Lab., version 0.9.8 edition, Feb 1993. (Ref: p. 120.)

[134] Tristan Richardson. Teleporting: Mobile X sessions.The X Resource, 13(1):133–140, 1995. http://citeseer.ist.psu.edu/richardson95teleporting.

html . (Ref: p. 142.)

[135] James Riely and Matthew Hennessy. A typed language for distributed mobile processes(extended abstract). InProceedings of the 25th ACM SIGPLAN-SIGACT symposiumon Principles of programming languages, pages 378–390. ACM Press, 1998.http:

//doi.acm.org/10.1145/268946.268978 . (Ref: p. 60.)

[136] R. Rivest. RFC 1321: The MD5 message-digest algorithm, April 1992.ftp://ftp.internic.net/rfc/rfc1321.txt,ftp://ftp.math.utah.edu/

pub/rfc/rfc1321.txt . Status: INFORMATIONAL. (Ref: p. 41.)

[137] J.H. Saltzer, D.P. Reed, and D.D. Clark. End-to-end arguments in system design.ACMTransactions in Computer Systems, 2(4):277–288, November 1984.http://doi.acm.

org/10.1145/357401.357402 . (Ref: p. 14.)

[138] Pierangela Samarati and Sabrina De Capitani di Vimercati. Access control: Poli-cies, models, and mechanisms. InFOSAD, volume 2171 of Lecture Notes in Com-puter Science, pages 137–196. Springer, 2001.http://link.springer.de/link/

service/series/0558/bibs/2171/21710137.htm . (Ref: p. 12.)

[139] Hanan Samet. The quadtree and related hierarchical data structures.ACM Comput. Surv.,16(2):187–260, 1984.http://doi.acm.org/10.1145/356924.356930 . (Ref: p.65.)

[140] Sanctum Inc. AppShieldTM white paper. http://www.sanctuminc.com/ . March2001. (Ref: p. 100.)

179

http://citeseer.ist.psu.edu/article/pierce97pict.html

http://citeseer.ist.psu.edu/article/pierce97pict.html

http://doi.acm.org/10.1145/345910.345917

http://doi.acm.org/10.1145/345910.345917

http://citeseer.ist.psu.edu/queinnec00influence.html

http://www.spidynamics.com/

http://www.spidynamics.com/

http://citeseer.ist.psu.edu/richardson95teleporting.html

http://citeseer.ist.psu.edu/richardson95teleporting.html

http://doi.acm.org/10.1145/268946.268978

http://doi.acm.org/10.1145/268946.268978



http://doi.acm.org/10.1145/357401.357402

http://doi.acm.org/10.1145/357401.357402

http://link.springer.de/link/service/series/0558/bibs/2171/21710137.htm

http://link.springer.de/link/service/series/0558/bibs/2171/21710137.htm

http://doi.acm.org/10.1145/356924.356930

http://www.sanctuminc.com/


[141] K. Schelderup and J. Olnes. Mobile agent security - issues and directions. InProceedingsof the 6th International Conference on Intelligence and Services in Networks, pages 155–167. Springer-Verlag, 1999. (Ref: p. 14.)

[142] Fred B. Schneider. Enforceable security policies.ACM Trans. Inf. Syst. Secur., 3(1):30–50, 2000.http://doi.acm.org/10.1145/353323.353382 . (Ref: p. 132.)

[143] Bruce Schneier. Applied cryptography: protocols, algorithms, and sourcecode in C.John Wiley & Sons, New York, 1994.http://www.schneier.com/book-applied.

html . (Ref: p. 91, 94, 157.)

[144] David Scott and Richard Sharp. Abstracting Application-Level Web Security. InTheEleventh International World Wide Web Conference Proceedings, pages 396–407, May2002.http://www2002.org/CDROM/refereed/48/ . (Ref: p. 91, 162.)

[145] R. Sekar, V.N. Venkatakrishnan, Samik Basu, Sandeep Bhatkar, and Daniel C. DuVarney.Model carrying code: A practical approach for safe execution of untrusted applications.In 19th ACM Symposium on Operating Systems Principles (SOSP), 2003. http://

doi.acm.org/10.1145/945445.945448 . (Ref: p. 132.)

[146] Semiconductor Industry Association (SIA).http://www.sia-online.org/pre_

facts.cfm . Industry Facts and Figures Page. (Ref: p. 11.)

[147] S. Shekhar, S. Chawla, S. Ravada, A. Fetterer, X. Lio, and C.T. Liu. Spatial databases:Accomplishments and research needs.IEEE Transactions on Knowledge and Data En-gineering, 11(1):45–55, Jan/Feb 1999.http://dx.doi.org/10.1109/69.755614 .(Ref: p. 65.)

[148] M. R. Shinwell, A. M. Pitts, and M. J. Gabbay. FreshML: Programming with bindersmade simple. InEighth ACM SIGPLAN International Conference on Functional Pro-gramming (ICFP 2003), Uppsala, Sweden, pages 263–274. ACM Press, Aug 2003.http://doi.acm.org/10.1145/944746.944729 . (Ref: p. 135.)

[149] Mark R. Shinwell and Andrew M. Pitts. Fresh objective caml user manual, Sept 2003.http://www.freshml.org/foc/docs/foc-manual.pdf . (Ref: p. 135.)

[150] Clay Shirky. Web services and context horizons.IEEE Computer, 35(9), September2002.http://dx.doi.org/10.1109/MC.2002.1033037 . (Ref: p. 61.)

[151] Jeremy G. Slek and Andrew Lumsdaine. The matrix template library: A generic pro-gramming approach to high performance numerical linear algebra. In Denis Caromel,R. R. Oldehoeft, and Marydell Tholburn, editors,ISCOPE, volume 1505 of LectureNotes in Computer Science. Springer-Verlag, dec 1998.http://citeseer.ist.psu.

edu/161165.html . (Ref: p. 135.)

[152] Robert E. Strom and Daniel M. Yellin. Extending typestate checking using conditionalliveness analysis.IEEE Transactions on Software Engineering (TSE), 19(1):478–485,Jan 1993.http://dx.doi.org/10.1109/32.232013 . (Ref: p. 133.)

180

http://doi.acm.org/10.1145/353323.353382

http://www.schneier.com/book-applied.html

http://www.schneier.com/book-applied.html

http://www2002.org/CDROM/refereed/48/

http://doi.acm.org/10.1145/945445.945448

http://doi.acm.org/10.1145/945445.945448

http://www.sia-online.org/pre_facts.cfm

http://www.sia-online.org/pre_facts.cfm

http://dx.doi.org/10.1109/69.755614

http://doi.acm.org/10.1145/944746.944729

http://www.freshml.org/foc/docs/foc-manual.pdf

http://dx.doi.org/10.1109/MC.2002.1033037



http://dx.doi.org/10.1109/32.232013


[153] Bjarne Stroustrup. The C++ Programming Language. Addison-Wesley Pub Co, 3rdedition. http://www.amazon.com/exec/obidos/tg/detail/-/0201889544/

102-8071009-6672113?v=glance . (Ref: p. 135.)

[154] Paul Syverson. A taxonomy of replay attacks. InComputer Security Foundations Work-shop VII. IEEE Computer Society Press, 1994.http://citeseer.ist.psu.edu/

syverson94taxonomy.html . (Ref: p. 95, 157.)

[155] W. Taha. A gentle introduction to multi-stage programming. In Christian Lengauer, DonBatory, Charles Consel, and Martin Odersky, editors,Domain-Specific Program Genera-tion, volume 3016 ofLecture Notes in Computer Science. Springer-Verlag, 2004.http:

//www.cs.rice.edu/˜taha/publications/journal/dspg04a.pdf . (Ref: p.134, 135.)

[156] Walid Taha and Tim Sheard. Multi-stage programming with explicit annotations. InPro-ceedings of the 1997 ACM SIGPLAN symposium on Partial evaluation and semantics-based program manipulation, pages 203–217. ACM Press, 1997.http://doi.acm.

org/10.1145/258993.259019 . (Ref: p. 134.)

[157] J. Tardo and L. Valente. Mobile agent security and Telescript. InIEEE CompCon’96, pages 58–63, 1996.http://citeseer.ist.psu.edu/tardo96mobile.html .(Ref: p. 79.)

[158] David Tennenhouse. Proactive computing.Communications of the ACM, 43(5):43–50,2000.http://doi.acm.org/10.1145/332833.332837 . (Ref: p. 11.)

[159] Peter Thiemann. An embedded domain-specific language for type-safe server-side web-scripting, May 2003.http://www.informatik.uni-freiburg.de/˜thiemann/

papers/wash-cgi.ps.gz . Accepted for publication in ACM Transactions on InternetTechnology. (Ref: p. 100.)

[160] Bent Thomsen. Facile antigua release, july 1994.http://compilers.iecc.com/

comparch/article/94-07-092 . Posted to USENET incomp.compilers . (Ref:p. 79.)

[161] Lindsay Todd and Ephraim P. Glinert. Polyglot: An architecture and prototype fordistributed multi-interface computing.http://www.rpi.edu/˜toddr/Archives/

1997/a01g-pgmi/ . (Ref: p. 136.)

[162] Trusted Computing Group. TPM specification version 1.2.https://www.

trustedcomputinggroup.org/home . (Ref: p. 137.)

[163] Asis Unyapoth. Nomadic π-Calculi: Expressing and Verifying Communica-tion Infrastructure for Mobile Computation. PhD thesis, University of CambridgeComputer Laboratory, March 2001.http://www.cl.cam.ac.uk/TechReports/

UCAM-CL-TR-514.html . (Ref: p. 21, 60.)

[164] Frank van Diggelen and Charles Abraham. Indoor GPS: The No-Chip Chal-lenge. http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?

id=3053 . (Ref: p. 26.)

181



http://citeseer.ist.psu.edu/syverson94taxonomy.html

http://citeseer.ist.psu.edu/syverson94taxonomy.html

http://www.cs.rice.edu/~taha/publications/journal/dspg04a.pdf

http://www.cs.rice.edu/~taha/publications/journal/dspg04a.pdf

http://doi.acm.org/10.1145/258993.259019

http://doi.acm.org/10.1145/258993.259019

http://citeseer.ist.psu.edu/tardo96mobile.html

http://doi.acm.org/10.1145/332833.332837

http://www.informatik.uni-freiburg.de/~thiemann/papers/wash-cgi.ps.gz

http://www.informatik.uni-freiburg.de/~thiemann/papers/wash-cgi.ps.gz

http://compilers.iecc.com/comparch/article/94-07-092

http://compilers.iecc.com/comparch/article/94-07-092

comp.compilers

http://www.rpi.edu/~toddr/Archives/1997/a01g-pgmi/

http://www.rpi.edu/~toddr/Archives/1997/a01g-pgmi/

https://www.trustedcomputinggroup.org/home

https://www.trustedcomputinggroup.org/home

http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-514.html


http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=3053

http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=3053


[165] Todd L. Veldhuizen. Arrays in Blitz++. In Denis Caromel, R. R. Oldehoeft, and MarydellTholburn, editors, ISCOPE, volume 1505, pages 223–230. Springer-Verlag, dec 1998.http://portal.acm.org/citation.cfm?id=709708 . (Ref: p. 135.)

[166] Todd L. Veldhuizen. C++ templates as partial evaluation. InProceedings of PartialEvaluation and Semantics-Based Program Manipulation (PEPM’99), jan 1999.http:

//citeseer.ist.psu.edu/veldhuizen99templates.html . (Ref: p. 135.)

[167] Larry Wall and Randal L. Schwartz.Programming Perl. O’Reilly & Associates, Inc.,Sebastopol, CA, 1992.http://www.oreilly.com/catalog/pperl3/ . (Ref: p.71.)

[168] Roy Want, Andy Hopper, Veronica Falcao, and Jon Gibbons. The active badge locationsystem. Technical Report 92.1, ORL, 24a Trumpington Street, Cambridge CB2 1QA,1992. http://citeseer.ist.psu.edu/want92active.html . (Ref: p. 23, 24,63.)

[169] A. Ward. Sensor-driven Computing. PhD thesis, University of Cambridge, August 1998.http://citeseer.ist.psu.edu/ward99sensordriven.html . (Ref: p. 24, 141.)

[170] A. Ward, A. Jones, and A. Hopper. A New Location Technique for the Active Office.IEEE Personal Communications, 4(5):42–47, October 1997.http://citeseer.ist.

psu.edu/ward97new.html . (Ref: p. 63.)

[171] Mark Weiser. The Computer for the 21st Century.Scientific American, 9 1991.http:

//www.ubiq.com/hypertext/weiser/SciAmDraft3.html . (Ref: p. 11.)

[172] J. E. White. Telescript technology: The foundation for the electronic marketplace. Tech-nical report, General Magic, Inc., 2465 Latham Street, Mountain View, CA 94040, 1994.(Ref: p. 21.)

[173] Pawel Tomasz Wojciechowski.Nomadic Pict: Language and Infrastructure Design forMobile Computation. PhD thesis, University of Cambridge Computer Laboratory, March2000.http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-492.html . (Ref:p. 21, 60.)

[174] World-Wide Web Consortium. XML Path Language (XPath) Specification, November1999.http://www.w3.org/TR/xpath/ . (Ref: p. 57.)

[175] World-Wide Web Consortium. Hypertext markup language activity statement, October2003.http://www.w3.org/MarkUp/Activity . (Ref: p. 35.)

[176] Angelos Yannopoulos, Yiannis Stavroulas, and Theodora A. Varvarigou. Moving e-commerce with pivots: Private information viewing offering total safety.IEEE Trans-actions on Knowledge and Data Engineering, 16(6):641–652, June 2004.http:

//csdl.computer.org/comp/trans/tk/2004/06/k0641abs.htm . (Ref: p. 22.)

[177] S. S. Yau and F. Karim. A context-sensitive middleware-based approach to dynamicallyintegrating mobile devices into computational infrastructures.Parallel and DistributedComputing, 64(2):301–317, Feb 2004. (Ref: p. 62.)

182


http://citeseer.ist.psu.edu/veldhuizen99templates.html

http://citeseer.ist.psu.edu/veldhuizen99templates.html

http://www.oreilly.com/catalog/pperl3/

http://citeseer.ist.psu.edu/want92active.html

http://citeseer.ist.psu.edu/ward99sensordriven.html

http://citeseer.ist.psu.edu/ward97new.html

http://citeseer.ist.psu.edu/ward97new.html

http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html

http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html


http://www.w3.org/TR/xpath/

http://www.w3.org/MarkUp/Activity

http://csdl.computer.org/comp/trans/tk/2004/06/k0641abs.htm

http://csdl.computer.org/comp/trans/tk/2004/06/k0641abs.htm

Appendix A

SPDL-2 DTD

<!ELEMENT site (policy*)><!ATTLIST site name CDATA #REQUIRED><!ATTLIST site policy_author_name CDATA #REQUIRED><!ATTLIST site policy_author_email CDATA #REQUIRED><!ATTLIST site description CDATA "unspecified"><!ATTLIST site base_uri CDATA #REQUIRED>

<!ELEMENT policy (parameter*, uri*, cookie*, policy*)><!ATTLIST policy name CDATA #REQUIRED><!ATTLIST policy description CDATA "unspecified"><!ATTLIST policy javascript (Y | N) "N">

<!ELEMENT parameter (validation*, transformation*)><!ATTLIST parameter method (GET | POST |

GETandPOST)"GETandPOST">

<!ATTLIST parameter name CDATA #REQUIRED><!ATTLIST parameter maxlength CDATA #REQUIRED><!ATTLIST parameter minlength CDATA "0"><!ATTLIST parameter required (Y | N) "N"><!ATTLIST parameter MAC (Y | N) "Y"><!ATTLIST parameter type (int

| float| bool| string) #REQUIRED>

<!ELEMENT cookie (validation*, transformation*)><!ATTLIST cookie name CDATA #REQUIRED><!ATTLIST cookie maxlength CDATA #REQUIRED><!ATTLIST cookie minlength CDATA "0"><!ATTLIST cookie required (Y | N) "N"><!ATTLIST cookie MAC (Y | N) "Y"><!ATTLIST cookie type (int

| float

183

Chapter A. SPDL-2 DTD

| bool| string) #REQUIRED>

<!ELEMENT uri (parameter*)><!ATTLIST uri prefix CDATA #REQUIRED>

<!ELEMENT transformation (#PCDATA)><!ATTLIST transformation htmlencode (Y | N) "Y">

<!ELEMENT validation (#PCDATA)>

184

Appendix B

Case Study SPDL-2

...<policy ...>

<uri prefix="Buy.asp"description="Do CreditCard transaction"javascript="Y">

<parameter name="price" method="POST" maxlength="10"minlength="1" required="Y" type="float" >

<validation> this gt 0.0 </validation></parameter>

<parameter name="productID" method="POST"maxlength="10" minlength="1"required="Y" type="int" />

<parameter name="surname" method="POST"maxlength="30" minlength="2"required="Y" MAC="N" type="string">

<transformation>Transform.EscapeSingle

(Transform.EscapeDouble(this))</transformation>

</parameter>

<parameter name="CCnumber" method="POST"maxlength="16" minlength="16"MAC="N" required="Y" type="int">

<validation>let

fun first(s:string):string =String.mid(s,1,1)

fun rest(s:string):string =String.mid(s,2,String.length(s)-1)

fun double(s:string,a:bool):string =if s="" then ""

185

Chapter B. Case Study SPDL-2

else(if a then first(s)

else String.fromInt(Int.fromString(first(s))*2))

++ (double (rest (s), not a))

fun sum(s:string):int =if s="" then 0

else (Int.fromString (first(s)))+ (sum (rest(s)))

in sum(double(this,false)) % 10 = 0end

</validation></parameter>

<parameter name="expires" method="POST"maxlength="5" minlength="5"MAC="N" required="Y" type="string">

<validation> String.format(this,"\d\d/\d\d") andInt.fromString(mid(s,1,2))<=12 andInt.fromString(mid(s,1,2))> 0

</validation></parameter>

</uri></policy>

186

Documents

Abstracting application-level security policy for ubiquitous computing