The University of Southern Mississippi The Aquila Digital Community
Dissertations
Summer 8-2007 API-S CALCULUS: FORMAL MODELING FOR SECURE MOBILE INTELLIGENT AGENT SYSTEMS Jean Francois Gourd University of Southern Mississippi
Follow this and additional works at: https://aquila.usm.edu/dissertations Part of the Applied Mathematics Commons, and the Computer Sciences Commons
Recommended Citation Gourd, Jean Francois, "API-S CALCULUS: FORMAL MODELING FOR SECURE MOBILE INTELLIGENT AGENT SYSTEMS" (2007). Dissertations. 1264. https://aquila.usm.edu/dissertations/1264
This Dissertation is brought to you for free and open access by The Aquila Digital Community. It has been accepted for inclusion in Dissertations by an authorized administrator of The Aquila Digital Community. For more information, please contact [email protected]. The University of Southern Mississippi
API-S CALCULUS: FORMAL MODELING FOR SECURE MOBILE INTELLIGENT AGENT SYSTEMS
by
Jean Gourd
A Dissertation Submitted to the Graduate Studies Office of The University of Southern Mississippi in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy
Approved:
August 2007
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Copyright by
J e a n G o u r d
2007
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The University of Southern Mississippi
API-S CALCULUS: FORMAL MODELING FOR SECURE MOBILE INTELLIGENT AGENT SYSTEMS
by
Jean Gourd
Abstract of a Dissertation Submitted to the Graduate Studies Office of The University of Southern Mississippi in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy
August 2007
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ABSTRACT
API S CALCULUS: FORMAL MODELING FOR SECURE MOBILE INTELLIGENT AGENT SYSTEMS
by Jean Gourd
August 2007
Mobile code has, for some time, been an intriguing area of research. Unfortunately, it has not propagated much to real-world applications primarily due to serious security con
cerns associated with processes that possess the capability to move across administrative domains (e.g. mobile intelligent agents). In order to ensure the future success and safety of mobile code, it is imperative that comprehensive mechanisms be developed that permit thorough modeling and analysis of such systems.
The use of formal methods to give software meaningful function and performance guarantees is becoming more widespread as the staggering cost of software bugs increases.
Using formal methods provides opportunities to experiment with complex systems in order to ultimately prove their functionality, thus offering some sort of validity guarantee. API Calculus stands out in a sea of similar modeling tools as particularly adept at modeling
mobile agents and multi-agent systems (MAS). We propose to extend the API Calculus to include the capability to model the security of mobile agents (and agent hosts). We introduce the API-S Calculus as an extension to the API Calculus. In this calcu
lus, we introduce several new and unique constructs that provide mechanisms to formally model cryptographic protocols and various security techniques unique to the mobile intel ligent agent paradigm. We introduce Q-terms and ^-processes which allow the detailed analysis of various cryptographic protocols. Moreover, we provide a way to more accu rately model realistic distributed computational systems by introducing the milieu listener, a form of agent broadcast. We extend the concepts of milieu, knowledge unit, and term as defined in the API Calculus in order to impart our calculus with the added flexibility to provide the mechanisms necessary to model and analyze the security of interacting mobile
ii
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. iii
agents, particularly with respect to MAS. Furthermore, these extensions will support ac
curate modeling of the security of mobile intelligent agents while distinguishing between groups of cooperating agents, thus providing the tools necessary to model a common secu rity model for a group of mobile agents working together to perform some computational
task.
The need to formally model a MAS initially motivated the development of the API-S
Calculus. This multi-agent fuzzy logic framework-termed DDI (Defense Data Integration)- ultimately provides a fused input to an external inclusive decision support system. The framework utilizes mobile intelligent agents to collect, sort, filter, and fuse heterogeneous data for inclusion in the fuzzy logic engine. The unique security requirements of DDI provided the primary motivation for the design of the API-S Calculus. The lack of a for mal modeling tool that can capably model MAS and the intrinsic security characteristics
of such systems furthermore motivated the development of the API-S Calculus. We ul
timately show how the calculus can be used to accurately model the DDI framework as well as numerous cryptographic protocols and security techniques relevant to the mobile
intelligent agent paradigm.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. T o M y D a z z l in g W if e
iv
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ACKNOWLEDGMENTS
I wish to thank several people who have provided me an innumerable amount of as sistance in my endeavor to push through this phase of my life. First, I wish to thank Dr. Dia Ali for his incredible support. Truly, he has helped me in countless ways and I am indebted; Dr. Adel Ali whose keen racquetball skills ultimately led to a graduate educa tion; my doctoral committee whose talented members endlessly provided guidance in this exciting process; the 251 crew (you know who you are) whose members have provided me with a wonderful, challenging, and perpetually amusing work environment. Finally, I wish to thank my marvelous wife who, with her unending love and support, is the singular reason I have been able to achieve this.
v
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. TABLE OF CONTENTS
ABSTRACT...... ii
DEDICATION...... iv
ACKNOWLEDGEMENTS...... v
LIST OF ILLUSTRATIONS...... viii
LIST OF T A B L E S...... ix
1 INTRODUCTION...... 1 1.1 Mobility and the Future 1 1.2 Intelligent Agents 3 1.3 Mobile Agents 4 1.4 Security Issues 6 1.5 Modeling 7 1.6 Motivation 9 1.7 Overview of the Thesis 11 1.8 Contributions of the Thesis 12 1.9 Thesis Structure 14
2 MOBILE AGENT SECURITY...... 15 2.1 General Security Assumptions 15 2.2 Unique Mobile Agent Characteristics 17 2.3 Multi Agent Systems 18 2.4 Security Issues 19 2.5 Protecting the Host 21 2.6 Protecting the Agent 24 2.7 Summary 30
3 MOBILE AGENT MODELING TO OLS ...... 31 3.1 Petri Nets 31 3.2 7t-Calculus 37 3.3 Ambient Calculus 43 3.4 SPI Calculus 50 3.5 API Calculus 54 3.6 Other Modeling Methods 60 3.7 Summary 60
vi
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4 THE API-S CALCULUS ...... 63 4.1 Syntax 64 4.2 Broadcasting 74 4.3 Abbreviations 76 4.4 Structural Congruence 78 4.5 Reduction 80 4.6 Discussion 84
5 ILLUSTRATIONS OF THE CAPABILITIES OF A P I-S...... 86 5.1 Simple Examples 86 5.2 Examples with Knowledge Units 88 5.3 Examples with Milieus 90 5.4 Other Examples 94 5.5 Examples Exhibiting Characteristics of Security 97 5.6 Discussion 104
6 THE PRELIMINARY FORMAL MODEL FOR D D I...... 106 6.1 Preliminary Definition of Formal Components 106 6.2 Preliminary Formal Model 109
7 CONCLUSIONS AND FUTURE W O R K ...... 115 7.1 Conclusive Remarks 115 7.2 Future Directions 116 7.3 Discussion 120
BIBLIOGRAPHY...... 122
vii
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. LIST OF ILLUSTRATIONS
Figure
1.1 Multi-Agent Fuzzy Logic Framework ...... 10
3.1 Graph representation of a Petri n e t ...... 32 3.2 A marked Petri n e t ...... 32 3.3 The Petri net resulting from the firing of transition t\ ...... 33 3.4 The Petri net resulting from the firing of transition ?3 ...... 33 3.5 The Petri net modeling a simple producer-consumer scenario ...... 35 3.6 The Petri net modeling the equation x = (a + b)/(a — b) ...... 35 3.7 The ambient resulting from the process n[in m.P \ Q] \ m [R \...... 47 3.8 Structure of the Channel Establishment Example ...... 52 3.9 Example of Interaction Between Processes Within M ilie u s ...... 59
5.1 Passing Links: The Client-Server-Printer Example ...... 87 5.2 Passing Links with Restriction ...... 87 5.3 Passing a Knowledge U n i t ...... 89 5.4 Passing a Knowledge Unit (Scope E xtrusion) ...... 91 5.5 Data Gathering Agent (Agent Migration) ...... 91 5.6 Communicating Through the Milieu Boundary via Broadcast ...... 92 5.7 Milieu Association W orkaround ...... 94 5.8 An Encapsulated A gent ...... 97 5.9 Encapsulated Agent M igration ...... 97 5.10 Partial Result Authentication Codes E x am p le ...... 100
6.1 Multi-Agent Fuzzy Logic Fram ew ork ...... 109 6.2 DDI Agent Initial Configuration ...... I l l 6.3 Local View after Spawning Four D G A s ...... 112 6.4 Local View after DGAs M igrate ...... 112
7.1 The Sealed Milieu: Malicious Outsider Example ...... 120 7.2 The Sealed Milieu: Trojan Horse Example ...... 120
viii
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. LIST OF TABLES
Table
3.1 7t-Calculus Syntax ...... 39 3.2 The Definition of Structural Congruence ...... 42 3.3 The Primitives of the Ambient C alcu lu s...... 45 3.4 Free Name Equivalences in the Ambient Calculus ...... 46 3.5 The Definition of Structural Congruence ...... 48 3.6 The Syntax of SPI Calculus ...... 51 3.7 The Syntax of API Calculus ...... 55 3.8 Structural Congruence and Equational Reasoning in the API Calculus .... 57
4.2 Axioms of Structural Congruence and Rules of Equational Reasoning in the API-S C alcu lu s ...... 80 4.3 Reduction Rules in the API-S Calculus ...... 81
6.1 Heterogeneous Agent Identifier ...... 107
ix
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 1
INTRODUCTION
1.1 Mobility and the Future
Over the past decade, the Internet has grown tremendously; almost one-sixth of the world’s population [18,72] has been and/or regularly uses the Internet to, for example, browse the
WWW (World Wide Web), check e-mail, or to conduct their daily business. It is now commonplace to observe people browsing the Web at coffee shops and other public places throughout the world. Moreover online gaming networks have grown exponentially over the past several years. It is also not uncommon to see cellular phones and PDAs (Personal
Digital Assistant) developed with standard Internet accessibility. Currently, there is an immense push to migrate from a wired perspective to a wireless one. The traditional method of connecting to a network via cables is now being replaced
with wireless network cards and routers, thus allowing users an untethered connection to the Internet. Mobile computing is becoming more prevalent; wireless networks are pop ping up everywhere. This is particularly true in academia [68], where the latest advances
in technology are generally widely accepted and are often developed. The plethora of wireless networks is easily noticed by simply powering up a laptop and permitting the
wireless network adapter to detect networks within range. Mobile code is becoming more popular of late. For example, consider the growing use of laptops, cellular phones, Bluetooth technology, and the use of the Java language to propel applications to a mobile level [41]. Clearly associated security (secrecy and integrity risks), validation, and verification concerns must be addressed [100] primarily due to the fact that programming is getting more complicated. Many new electronic devices are now going wireless and including some sort of Inter net connectivity. For example, users can check their e-mail on a cellular phone and even
a PDA. Browsing the WWW can be easily done on a cellular phone, although it can often be cumbersome due to the minuscule size of the device. Even portable audio devices, such
1
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 1. INTRODUCTION 2
as the iPod, are going wireless in the future [44]. Worried mothers can check in on their young children staying at day care by simply pointing their Internet browser to the appro
priate location, and curious vacationers can periodically poll their home security system to ensure that the security of their home has not been breached.
Notwithstanding the popularity of a wireless world, it is sane to presume that many wireless subscribers will want some level of productivity even while offline. For example, complex (and comprehensive) WWW searches may take some time; it may not be advan tageous to stay online and wait for a search to complete. In this case it may be better to
submit the search query and disconnect the device until it is more convenient, at which time the results may be waiting for the user. Furthermore, wireless outages will inevitably
occur. Mobile elements are typically resource poor and unreliable, often utilizing low-
bandwidth wireless links [102]. Therefore, search algorithms and wireless protocols must account for such problems. Ongoing processes working on behalf of users must not simply
terminate as a result of breaches in connectivity. Typically, mobility encompasses two separate aspects: In mobile computing [67], com puting is done on mobile devices (e.g. browsing the WWW on a laptop via a wireless Inter net connection). On the other hand, mobile computation [67] embraces the idea of moving the computations themselves (e.g. employing the use of mobile agents which migrate to
separate hosts in order to gather, filter, and fuse data). With the ever-increasing number of electronic devices implementing wireless proto
cols, security is a critical issue. Frequently the security of the communication link-this
is often just the security of the communicated message-between the user and some other
entity is extremely important. Thus, the capabilities of secure communication and transac tions are paramount. Messages intended for a particular recipient must not be intercepted by-or at least not be readable to-an unauthorized source.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 1. INTRODUCTION 3
1.2 Intelligent Agents
The intelligent agent was bom as a means to provide a solution to the dilemma of au tonomously performing tasks for users. Strictly speaking, an agent is some sort of object
that performs a task on behalf of a user. More specifically, Wooldridge and Jennings in [119] give the intelligent agent several unique characteristics:
• Autonomy. An agent is capable of performing tasks without requiring user interven tion; furthermore, an agent may implement mobility aspects and be able to move from one location to another (see section 1.3 for a description of mobile agents). Note that move, migrate, hop, and transit are used interchangeably in this text.
• Social ability. An agent is capable of communicating with other agents and/or other
entities; it may adapt its behavior accordingly based on the communication activities it performs.
• Reactivity. An agent can react to changes in the environment or in events that occur
within that environment.
• Pro-activeness. An agent can not only react to changes and events but can addition
ally induce changes and initiate patterns of behavior when necessary.
Intrinsic to the agent is the concept of an agency. Essentially, it is nothing more than a
storehouse for agents and is generally software-based. The agency may accept a group
of agents by providing an interface that supports a set of tasks; for example, querying a relational database on the network. Often, agencies are utilized as a means to provide safe and secure inter-agent communication. Note that agency, host, platform, and peer are used interchangeably in this text. With respect to an agent, the concept of intelligence is one which many in the disci pline of Computer Science opine. In the field of AI (Artificial Intelligence), it generally
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 1. INTRODUCTION 4
means that an agent exhibits characteristics similar to humans, such as intention and mo
tivation [119], for example. Concepts central to AI such as fuzzy logic, expert systems, and artificial neural networks have been used to implement the intelligence of an agent. It is important to note, however, that this intelligence is not a strict intelligence; that is to say, it is not human intelligence but rather computational intelligence [81]. An intelligent agent can be given a set of rules to follow, some of which may actually be to learn from experience. In turn, as the agent performs more tasks, it can become better at performing
them. Recently, intelligent agents have been used to aid in gathering data on the WWW. The following is a typical scenario: User u sitting on machine M wishes to obtain a set S of images pertaining to, say, the internals of a computer. The user’s query Q is sent to a
high-level intelligent agent Ao which then tasks lower-level agents Ai,A2 , ... ,An on the basis of the information they are familiar with. In this multi-agent environment, it is the
responsibility of some agents to become very familiar with a very specific data type such
as JPEG (Joint Photographic Experts Group) images. There are, in turn, more general or abstract agents that are responsible for a generic image type (which perhaps includes JPEG and GIF (Graphic Interchange Format) images). Ultimately, it is the job of the high-level intelligent agent Ao to present the user with the results of a specific WWW query which may include several images of differing image types. Rahimi and Carver in [85] expose a
similar design.
1.3 Mobile Agents
The distinguishing factor between an agent and a mobile agent lies in the fact that mobile agents possess the capability to migrate from one peer to another autonomously. Typically,
the migration process is performed as follows [98] (with respect to the agent):
• Suspension of execution. The mobile agent’s chain of execution is suspended at the onset of some predetermined event.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 1. INTRODUCTION 5
• Identification of current state. For later continuation, the agent’s current state is saved.
• Serialization. The agent is internally converted to an array of bytes for transit.
• Encoding. The byte array is encoded (and perhaps compressed) to some common format used in the communication process.
• Transfer to a remote host (subsequent to host authentication). The encoded agent is transferred, via the network, to the host.
With respect to the agency, the process is slightly different:
• Authentication of the communication. The host authenticates the communication
(the previous host’s request to transfer the agent).
• Decoding. The incoming data are decoded back to an array of bytes.
• Deserialization. The byte array is deserialized to the object form of the agent.
• Instantiation. The object is then instantiated into the mobile agent.
• Restoration of previous state. The agent’s state is set to the previously saved state in order to properly resume execution on this host.
• Continuation of execution. The agent now resumes execution, its current state guid
ing its flow of control.
Clearly, this introduces numerous security concerns both for the agent and the agency. Unfortunately, mobile agents are not yet widely used and/or accepted. A reason for this is perhaps because they are not very well thoroughly defined; this is primarily due to a severe lack of clarity with respect to the security of mobile agents. Given that, in many cases, it
is the task of mobile agents to gather data and information as it moves from peer to peer, it is critical in many cases to protect this data. Furthermore, the integrity of the mobile
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 1. INTRODUCTION 6
agent must be guarded during its life cycle. Such very important issues have not been fully addressed. Defining the security of a mobile agent will allow them to be modeled and analyzed more thoroughly, perhaps widening their acceptance and use. A major issue in the gathering of data and information lies in the heterogeneity of the data that resides on distributed relational databases, file servers, and so on. The process
of gathering this data and ultimately fusing them for presentation to the end user, some expert system, or dedicated framework becomes quite a task. In support of and answer to
this issue, we have proposed a multi-agent fuzzy logic framework to provide a fused input to an external inclusive decision support system which we elaborate on in section 1.6.
1.4 Security Issues
Utilizing autonomous intelligent agents to perform tasks without user intervention merits hefty security protocols. Generally speaking, security threats become increasingly signif icant in the presence of mobile code (e.g. mobile agents). Particular to mobile agents is their intrinsic vulnerability once situated on a host. Typically, the mobile agent must give
access to its code, potentially its state, and at times its data. This poses a difficult problem for mobile agent designers. Perhaps, for example, the owner of a mobile agent does not wish to release its code to an agency (i.e. it is of a proprietary nature). Numerous methods
have been proposed in answer to this problem (see sections 2.5.1 and 2.6.1), although none
are comprehensive, and none propose a complete security strategy. Mobile code violates all typical security assumptions (for a thorough review of these
assumptions, see section 2.1)-to the point that even single-user systems require hefty se curity in the presence of mobile code. Characteristics specific to mobile agents (see sec tion 2.2) further present security risks and thus motivates the continuous work done with respect to their security. The ongoing push toward MAS (multi-agent systems) further complicates security issues, particularly with respect to concurrent distributed systems. In general, security issues, with respect to mobile agents lie in three classes [55]:
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 1. INTRODUCTION 1
• Security of the agent. An agent may be compromised by a malicious agency; further more, an agent may be operating in an unfriendly environment, thus be vulnerable.
Typically, mobile agents can be adversely affected by malicious hosts and other ma
licious agents.
• Security of the agency. An agency may be compromised by malicious agents or
some other entity altogether. It is typical to involve the underlying operating system and/or supporting software (e.g. firewalls) in the security of the host.
• Security of the communication channel. Agent-agency communication is performed via communication channels that are at risk of being compromised. Often, sensitive
data are transferred using these channels.
It is thus necessary to consider several cases; First, the agency must be protected from
malicious agents and other malicious entities which may target it. Second, agents must
themselves be protected from several potential types of attackers. Malicious agencies may
attempt to compromise agents in a number of ways (e.g. denial of service, eavesdropping on collected data, etc), and other malicious agents may attempt to convert an otherwise trustworthy agent and force it to do its bidding. Third, the data that the agent carries
in its briefcase must also be protected. Quite often, the data are of a proprietary nature (particularly in secure networks) and must not be compromised. There are, of course many issues to deal with within the aforementioned classes. A more thorough review of
security issues is done in chapter 2.
1.5 Modeling
MAS are becoming more and more popular particularly in the field of artificial intelli gence. Mobile agents are being utilized to perform many useful tasks, of which the gath
ering of heterogeneous data is only a small portion. Often, it is desirable to model the framework prior to realizing its existence in order to prove important attributes of the sys
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 1. INTRODUCTION 8
tem such as robustness and scalability. Furthermore, we often wish for a formal tool that can be used to model the system so that we can perform comprehensive qualitative and
quantitative analyses in order to prove the system. These formal modeling tools allow us to reason about complex systems formally and help us to answer very important questions; for example:
• How will the system react to malicious agents or hosts?
• Does the system perform as intended?
• Does it perform acceptably?
• How does it quantitatively compare to other technologies?
The use of formal methods to provide some guarantees that a system or software appli
cation performs as intended is growing. The cost of software bugs could reach $60 billion a year, according to the National Institute of Standards and Technology [118]. Providing
performance guarantees and verifying system correctness (e.g. absence of runtime errors,
data consistency, accuracy, and information flow) greatly enhances the reliability of these realized systems [118]. Moreover, using formal methods to investigate models of these systems provides a useful way to cogitate about their complexity. Modeling systems which exhibit aspects of mobility introduces a level of complex ity due to the inherent dynamic topology of the environment [58]. Typically the models are complex because so many variables are involved. Often, modeling such systems is in
tractable and cannot be entirely solved using computers; therefore, they tend to be modeled
at higher levels of abstraction [46]. In any case, the use of modeling tools allows us to rea son about such complex systems and models formally, often in a mathematical manner [9]. Furthermore, there is often a need to formally model the movement of processes across administrative domains (which tends to introduce additional security concerns) [39]. There are a large number of tools well fitted to model concurrent and mobile systems;
however, they generally fall into two categories: visual modeling tools (e.g. Petri nets)
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 1. INTRODUCTION 9
offer a pictorial view of the system which is quite often nice. Textual modeling tools (e.g. rt-Calculus) provide a mathematically linear method of modeling the system which is defined very explicitly and possesses sound mathematical properties. Current examples include the formal modeling of MAS in the 7t-Calculus, primarily focusing on the commu nication aspects [88, 89]. Web service transactions [120]-which are often complex-and
trust within distributed systems [45] are also modeled using 7t-Calculus.
Ultimately, there are numerous methods that can be used to perform such tasks. For example, extended Petri Nets [7] and process algebras such as Tt-Calculus [63,64] and API Calculus [84] have been used to model concurrent and massively concurrent processes
such as a MAS. A detailed review of concurrent process modeling is done in chapter 3.
1.6 Motivation
Remaining on the cutting edge of mobile agent technology quite often results in the design
of a plethora of new and interesting ideas relating to the subject. In most cases, we find ourselves hard-pressed to prove the functionality and correctness of these new systemic proposals. It is a typical software engineering problem; we often proceed directly from a
diagram of the system to test coding key components simply to observe their functional
ity. Repeating this process many times, we often wish for a formal tool that can be used
to model the system so that we can perform comprehensive qualitative and quantitative analyses in order to prove the system. Notwithstanding the seemingly constant outpouring of ideas on the topic of the mobile agent paradigm, the motivation for this work primarily originated from a US ASMDC (U.S. Army Space and Missile Defense Command) grant for the design and implementation of a multi-agent fuzzy logic framework to provide a fused input to an external inclusive decision support system (see Figure 1.1). This framework-casually termed DDI (Defense Data Integration)-provides mechanisms to gather heterogeneous data-utilizing intelligent mobile agents-which is fed to a reconfigurable fuzzy logic engine. In turn, the resulting
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 1. INTRODUCTION 1 0
output is presented to the user directly via some sort of GUI (Graphical User Interface)
or to a high-level decision support system. The intelligent mobile agents (MA in the
figure) are utilized to collect, sort, filter, and fuse the heterogeneous data-via information gathering agencies (IGA in the figure) and a static information gatherer agent-for inclusion in the fuzzy logic engine.
GUI
Fuzzy Broker Module
Information Information Storage Gatherer Facility
IGAIGA IGAIGA
MA) (MA MA MA) MA (MA) MA
Figure 1.1: Multi-Agent Fuzzy Logic Framework
The data gathering capabilities of the system motivate the use of mobile intelligent
agents. Moreover, the nature of the data (e.g. their heterogeneity) further propels the use of a hierarchical multi-agent system. The data sources and data gathered are a security
issue, in that secrecy must be wholly maintained at all times; we typically deal with highly sensitive data that must, under no circumstance, be accessed by unauthorized sources. As more research is being carried out in the design and implementation of this frame work and in mobile agent security aspects in general, the importance of realizing a formal model for DDI becomes quite clear. Such a formal model can be used to address the
security, validation, verification, and performance of the system. The calculus used to model such a system should indeed be capable of representing its individual components, including those responsible for data gathering (detection and evaluation of data sources,
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 1. INTRODUCTION 11
collection and validation of data, and ultimate fusion of the data). Naturally, the intrin sic mobility aspects of the system must be capably modeled. Perhaps more importantly, however, the calculus must provide adequate capabilities to formally model the system’s
necessary security characteristics. The need for such a calculus motivates the research of current modeling calculi (see chapter 3). Ultimately, this led to the development and intro duction of an extension to the API Calculus [84] which introduces the ability to capably
model key security techniques and protocols relevant to mobile agent systems. The new
calculus is named the API-S Calculus (hereby referred to as API-S) and is introduced in chapter 4.
1.7 Overview of the Thesis
The goal of this research is to extend the API Calculus to include the capability to model the security of mobile intelligent agents and agencies, thus providing a means to fully
analyze this aspect of the mobile agent paradigm (including MAS). Maintaining the con
ducive concepts of milieu and knowledge unit, the aim is to extend the calculus, thereby
imparting it with the ability to formally model various security aspects of mobile agent systems. API Calculus stands out in a sea of similar modeling tools as particularly adept at modeling mobile agents and MAS. Others have proposed methods and techniques that model security for more general artefacts (e.g. modeling cryptographic protocols such as public key cryptography [3,4] and others [43, 78]); yet no comprehensive work has been
done regarding mobile agents and security in particular.
In order to fully model the security of mobile agents and the agencies that support them, the following component relationships [50] will be considered:
• Agent-to-Agency. This includes security issues such as authorization and permission to request resources and services, masquerading as a trustworthy agent, denial of service, flooding the host, and repudiation. See section 2.5 for a comprehensive
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 1. INTRODUCTION 1 2
review of these issues.
• Agency-to-Agent. This includes security issues such as masquerading as a trustwor thy agency, incorrect execution of code (including re-execution), complete denial of
execution, denial of service, situatedness, and eavesdropping. See section 2.6.1 for a comprehensive review of these issues.
• Agent-to-Agent. This includes security issues such as masquerading as another trust
worthy agent, denial of service, situatedness, eavesdropping, and unauthorized ac
cess. See section 2.6.1 for a comprehensive review of these issues.
Protecting the data a mobile agent carries from host to host is fundamental to ensuring robustness and soundness of the system. In support of this, we consider the establishment
of mechanisms in the calculus that model the security of the data itself.
1.8 Contributions of the Thesis
The primary focus of this thesis is the introduction of API-S, a new formal modeling
calculus specifically directed at capably modeling mobile intelligent agent based systems- including their security features. By extending the API Calculus to include formalisms that provide support for modeling these security aspects, API-S not only addresses the migration, intelligence, and natural grouping characteristics of agent-based systems, but furthermore considers the intrinsic security considerations of such systems. API-S pro
vides the necessary mechanisms to permit the modeling and analysis of the security of
agent-based systems. The work outlined in this thesis will provide a contribution to the body of work which currently exists in the domains of the mobile agent paradigm, mobile code security, and agent-based analytical modeling tools. We summarize our contribution as follows:
• Development of API-S, a formal modeling tool specifically designed to model the security, migratory, and natural grouping characteristics of mobile intelligent agent
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER I. INTRODUCTION 13
based systems. This includes the introduction of several core concepts:
- Q.-term. Introduces the constructs necessary to accurately model a wide variety of cryptographic protocols and security techniques related to the mobile agent paradigm.
- O-process. Provides support for a wide variety of cryptographic protocols, thus permitting secure analytical and conditional constructs in the calculus.
- Milieu listener. Introduces an entirely new capability to the calculus by pro viding a way to cross the milieu boundary via an abstract milieu environment channel, thus allowing secure communication between processes that do not
share the same milieu.
Furthermore, API-S is unique in that:
- It provides the mechanisms to fully model and analyze the security of inter acting mobile agents, particularly with respect to MAS. Securing the commu
nication channels provides a way to exchange knowledge unit facts or rules securely, for example.
- It distinguishes between groups of cooperating agents (utilizing the concept of milieu), thus providing the tools necessary to model a common security model
for a group of mobile agents working together to perform some computational task.
- It is abstract and flexible in that it can support the modeling of numerous cryp tographic protocols, including more canonical security constructs (e.g. authen tication, verification, and identification).
• Design and implementation of a multi-agent fuzzy logic framework (DDI) that pro
vides a fused, coherent input to an external inclusive decision support system.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Presentation of a preliminary formal model for the DDI framework using the newly introduced API-S Calculus.
1.9 Thesis Structure
This thesis is organized as follows: we present a review of the security issues relevant to mobile agent systems in chapter 2. We begin with a brief introduction and subsequently discuss the uniqueness that mobile code presents to systems. We continue by detailing the
unique mobile agent characteristics that intrinsically demand higher security measures. We then discuss MAS and the security issues they bring to light. We conclude with a
comprehensive discussion of security issues pertinent to mobile agents, the data they carry, and agencies, and a variety of techniques that have been proposed to address these security
issues.
In chapter 3, we discuss modeling in general and relate it specifically to the mobile agent paradigm. We present a review of general concurrent process modeling tools such as Petri nets and the 7t-Calculus, and further discuss calculi specific to mobile agent sys
tems and security. We address any shortcomings, thus identifying several reasons for the introduction of API-S. Chapter 4 formally introduces API-S. Several illustrative examples are provided in chapter 5 to support the material introduced and to address the security issues identified in chapter 2. Furthermore, we provide illustrative examples that show how we can model a number of the security techniques reviewed. In chapter 6, we introduce the preliminary formal model for DDI and show how it can be modeled in API-S. We complete the thesis by concluding and providing a set of items and issues appropriated for future work in chapter 7.
14
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 2
MOBILE AGENT SECURITY
Although the concept of mobile agents has been around for over a decade and has con tinuously been developed and refined within that time, the security of mobile agents has traditionally been ill-defined. The reasons are plentiful; however, we can generalize the
difficulty by observing that, once situated at some agency, the mobile agent must give ac
cess to its code, potentially its state, and at times its data; therefore, the mobile agent is
indeed vulnerable. This poses a difficult problem for mobile agent designers. Perhaps, for example, the owner of a mobile agent does not wish to release its code to an agency (i.e.
it is of a proprietary nature). Numerous methods have been proposed in answer to this problem (see sections 2.5.1 and 2.6.1), although none are comprehensive and propose a
complete security strategy.
2.1 General Security Assumptions
The issue of security threats regarding networked environments (e.g. LAN and WAN) and
communications in general has been discussed extensively [26, 27]. In fact, many of the security protocols that are currently implemented are strictly based on the following set of assumptions [27]:
• Identity assumption. In this assumption, we can identify the person who wishes to perform some action. With this information, we can determine whether to allow the action to take place. Identities are typically verified via the use of usernames and
passwords (e.g. on Linux and Windows operating systems). Frequently, computer programs perform tasks on behalf of an individual.
• Trojans are rare. All programs are generally identifiable and are from trusted sources. Clearly, mobile agents as generally defined are in direct violation of this. This as sumption may indeed be questioned of late due to the enormous amount of Trojan horses and worms lurking around today on the Internet.
15
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 2. MOBILE AGENT SECURITY 16
• Origin of attacks. The prototypical hacker is used to model security. Security threats come from attackers running programs with malicious intent; therefore security measures should authenticate the user and make sure that programs run by this user
can only do those things that the user is allowed to do.
• Programs stay put. In general, programs rarely cross the administrative boundary.
When they do it is intentional. A program runs on one OS (Operating System), and security is provided by the OS. Computer programs do not move from one system
to another, unless users intentionally transmit them.
Mobile code violates all of the aforementioned assumptions; therefore even single user systems require security. Furthermore, the OS may not provide adequate security as gener ally assumed. There are, of course, standard procedures that can be taken in order to min imize harm to mobile agents. For example, limiting the agent to a set of trusted agencies
(i.e. mobile agents can only move to trusted hosts) [15, 16, 27, 28, 49, 50]. Understand
ably, this is often not a realistic assumption; the realm of moving to a number of untrusted hosts is much more probable for a real-world implementation of mobile agents. An often
utilized example illustrates this: Suppose an individual wishes to travel from Atlanta, GA to Tokyo, Japan for a conference. The person wishes to stay for three days and requires a two-night stay at a decent hotel near the conference location with airport shuttle service. The user may send a mobile agent-complete with the user’s requests and preferences-to search for the best airfares, hotel rates, and so on. Unquestionably, the agent will be re
quired to travel to untrusted hosts. In such a simple case, it may not be critically important to protect the agent’s code given that its task is solely to search for the best deal; however, consider the situation that an agent is given permission to purchase the least expensive ticket it finds with the appropriate specifications. This transaction introduces several prob lems. First, the agent must be protected so as not to allow a malicious host to tamper with its execution. Modifying the agent so that it purchases the most expensive ticket,
for example, would be detrimental to the user. Second, the agent must be protected from
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 2. MOBILE AGENT SECURITY 17
having the user’s itinerary modified. Imagine the case when the mobile agent is minimally
modified by a malicious host in such a way that the flight number is altered. There are several assumptions that can be made with respect to mobile agent migra
tion [28]. First, we must consider the case in which agents are deployed over standard computer networks. Second, and obviously, agents should be protected while in transit. Third, inter-agent communication must be protected in addition to agent-agency commu nication. Additionally, the communication between users and agents must be safe. Finally,
communication channels should be cryptographically secure.
2.2 Unique Mobile Agent Characteristics
Mobile agents possess unique characteristics which pose security risks and thus motivates
the continuous work done with respect to their security [14]:
• Situatedness. An agent can receive sensory input from its environment.
• Autonomy. An agent can act without user intervention.
• Flexibility. An agent possesses the following characteristics:
- Responsive. An agent perceives its environment and responds accordingly.
- Pro-active. An agent exhibits opportunistic, goal-driven behavior.
- Social. An agent interacts with other agents, humans, and other entities.
• Rationality. An agent will not act in a manner that prevents it from achieving its goal.
• Veracity. An agent will not knowingly communicate false information.
• Benevolence. And agent cannot have conflicting goals that either force it to transmit
false information or do something that can cause its goals to be impeded.
• Mobility. An agent can move across networks.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 2. MOBILE AGENT SECURITY 18
It is also important to note that mobile agents can indeed possess some sort of repu
tation and may, in time, be trusted to some extent [27]; these attributes are more likely earned. With such a plethora of unique characteristics, mobile agents offer a greater op portunity for abuse and misuse, broadening the scale of threats significantly [49]. More
over, mobile agents are extremely flexible and can be used for a wide range of tasks.
For example, they have successfully be used to gather information (e.g. database access) [30,33,92], to make purchases on behalf of users and organizations [107], to support Inter net (primarily WWW) searches [52, 76, 85], and in numerous other wireless applications
[102, 110].
2.3 Multi Agent Systems
In some cases, multi-agent systems (MAS) have been introduced to allow for broader
scope and increased scalability [51, 53, 82, 85, 8 8 , 89, 107]. A particularly interesting implementation appears in [85]. Briefly, wrapper agents surround themselves around a single data type (e.g. JPEG) and support extraction, filtering, and other unique charac teristics well-fitted for the data type. Information agents are then responsible for a larger body of data (e.g. images in general) and provide a higher level of abstraction. In this framework, a user may request some data (e.g. images representing a particular topic). An information agent receives this request and forwards it to a subset of appropriate informa
tion agents which rely on a series of wrapper agents for the underlying images. Ultimately,
a selection of appropriate images are returned to the user. MAS possess several interesting characteristics [14]:
• Each agent cannot solve the problem unaided. The system relies on multiple agents, some of which may indeed be static, in order to perform a user-defined task.
• There is no global system control. No one platform or entity controls the flow of information or instructions. Agents work on their own, autonomously, carrying out
individual instructions.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 2. MOBILE AGENT SECURITY 19
• Data are decentralized and generally heterogeneous. Agents gather data that are
distributed across networks. Often, the data must be filtered and converted to some common format in order to be fused into an outcome result, analysis, or assessment.
• Computation is asynchronous. Multiple agents carry out tasks simultaneously. Hosts may accept (and execute) numerous agents simultaneously.
MAS are likewise vulnerable to similar security issues, but in addition seem to allevi ate some of the security threats due to the natural encapsulation of the individual mobile agents. In one example [28], a master static agent is utilized which does not move but rather collaborates with other mobile agents, each of which have no concept of the com
plete task as defined by the user. The supporting mobile agents deliver important informa tion, and the master agent ultimately makes some decision with the combination of these data.
2.4 Security Issues
Several assumptions must be made in order to properly address the security issues relevant to the mobile agent paradigm: The mobile agent’s home platform is completely trusted.
Additionally, the home platform and other equally trusted platforms are implemented se curely (i.e. there are no flaws) and behave non-maliciously [49]. Certificates utilize public key cryptography, and revocation lists are managed through a public key infrastructure
[50]. It is important to note, however, that security does indeed come at a cost; additional
computational and communication resources are required [14]. Although there are numerous security issues threatening mobile agents and agencies, we can generally categorize them as follows:
• Threats to the agency
• Threats to the agent
• Threats to the communication channel (e.g. during agent data communication)
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 2. MOBILE AGENT SECURITY 20
Malicious hosts and other entities pose unique threats to the mobile agent directly. For
example, a mobile agent can have its previously collected data erased or its route changed. It may be unexpectedly terminated or its commitment function (e.g. making a purchase)
may be executed at an inopportune time. In general, threats to security fall into three main
classes [50]:
• Disclosure of information
• Denial of service
• Corruption of information
Security threats with respect to communication in general can be further classified as
follows:
• Confidentiality [50]. Agent-agency communication must not be accessible to unau thorized parties. Moreover, any private data stored on the host or in the possession
of an agent must be protected. Agents may choose to communicate through proxies
to keep their location confidential. Furthermore, the contents of any host log must
remain confidential if such logs are maintained.
• Anonymity [50]. An agent may wish to be anonymous in order to have some sort of privacy; therefore, the host must keep the agent’s identification private but should nonetheless be capable of formally validating the agent. This implies that anonymity must be reversible.
• Data integrity [14,28,49,50]. Communicated information must not be manipulated by unauthorized entities without being detected. Agents must additionally protect themselves from unauthorized modification of their code, state, and data. Agents take measures to detect compromise by malicious hosts or other agents.
• Accountability [50]. Agents and hosts must be held accountable for their actions. Agents must be identified, authenticated, and audited.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 2. MOBILE AGENT SECURITY 21
• Authentication of origin [14]. Communication should originate from the purported source. Hosts and agents must implement measures to accurately certify communi cation sources.
• Availability [14, 50]. Communication should reach its intended destination in a
timely manner. The host must ensure the availability of both data and services to agents. The host must be able to handle multiple simultaneous requests for services.
The host (and agent) must take precautions against DOS (Denial of Service) attacks.
• Non-repudiation [14, 28, 50]. The original source of a message, task, or event must
be held responsible for its action(s).
2.5 Protecting the Host
Hosts (or agencies) provide the environment that allows a mobile agent to execute based
on its current state. Threats to the host are generally the cause of intentionally malicious agents, improperly programmed agents, or other malicious entities. Clearly, it may often be imperative to ensure that agent-agency communication is encrypted [50]; moreover, that each agent which travels to an agency be digitally signed and encrypted by the previous host so that it can be verified [28]. Note that cryptography can do nothing about what the agent might do when it is executed on the host [55]; this is a primary motivation for the protection of the host. In general, hosts must prepare for the following key security issues:
• Authorization/Permission [14, 115]. The agent must have the necessary rights to
perform some action. Note that remote access to a platform must also be protected (implying protection from some other or outside entity).
• Masquerading [14, 50]. An unauthorized agent must not be able to claim the iden
tity of another agent. Furthermore, an agent must not be able to masquerade as another agent on another platform and request services and resources which it is not authorized to use.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 2. MOBILE AGENT SECURITY 22
• Denial of service [14, 50]. An agent must not be permitted to consume excessive amounts of a host’s resources. Additionally, a host can also be affected by traditional DOS attacks through underlying OS and communication protocols; this must be
taken into account.
• Flooding [27] (including replication floods). Copy and replay [49], where an agent
may be copied and replayed (e.g. a buy order), must not be permitted.
• Repudiation [14, 28, 50]. An agent participating in a transaction must not later claim that it never took place. A method to overcome this threat involves the use of auditing wherein hosts can support strong evidence of transactions [50].
2.5.1 Agency Methods and Techniques
There are several methods and techniques that an agency may employ in order to reduce the security threats a mobile agent may exploit. The following list categorizes the agency process once a mobile agent has moved to a host and identifies several techniques a host
may employ during each part of the process:
• Agent identification [14, 115]. An agent must be identified by the host by some
mechanism, preferably utilizing cryptographic methods. For example, the host may request the agent’s serial number or username and password. Support for reversible
anonymity [14, 50] may be provided.
• Agent authentication (and delegation) [15,16,14,26,27,28,50,49,55,98,99,115]. The agent must originate from a trusted source. Access and execution rights must be
implemented; the host must accurately allocate its services and resources, limiting
and controlling an agent’s access to its resources. Agents typically act on behalf of a user and/or organization. They must be authenticated using cryptographic meth ods. A technique involves digitally signing the agent’s code [14, 50], wherein the
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 2. MOBILE AGENT SECURITY 23
digital signature of the code confirms the authenticity of the agent, its origin, and its
integrity.
• Agent verification [14, 28, 55]. One method of verifying an agent once it arrives at
an agency is to implement proof-carrying code. Here, an agent must formally prove that it conforms to a security policy (i.e. the code is safe to execute). The agent’s
author must formally prove that the agent’s code is safe by digitally signing the agent’s executable code. Another method involves ownership verification [98] im plemented in such a way that cryptography is used to certify the origin of the agent and to provide guarantees that the agent was not tampered with in transit. Agent path histories can be used to track where an agent has been by maintaining an authenti-
catable record of the prior hosts visited by an agent. State appraisal is used to detect
if an agent has been tampered with. The author of an agent produces an appraisal function which is signed and verified by the host upon the agent’s instantiation.
• Agent execution [14, 27, 28, 50, 55]. Agents must be prevented from executing a DOS attack on the host. The use of secure languages (i.e. software-based fault isolation) provides for safe execution of an agent’s code. Languages which run on virtual machines (e.g. Java [38]) within their own virtual address space provide more robust security for the host. Using interpreted languages allows for unsafe
agents to be executed safely. Unsafe code can be made safe or denied execution via safe code interpretation. The technique of sandboxing agents may be achieved by isolation and the limiting of privileges by effectuating appropriate permissions. Protection from other agents can be accomplished by utilizing this technique which isolates agents from one another on a host. Security-relevant events occurring at the platform can be audited in order to later determine the presence of a malicious agent.
If payment for services is required, the agent must be able (and willing) to pay for these services.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 2. MOBILE AGENT SECURITY 24
2.6 Protecting the Agent
Mobile agents possess the unique ability to transit to agencies. It is obvious that a ma licious agency may indeed compromise an otherwise honest agent. Furthermore, other malicious mobile agents may pose security threats. Since agents can communicate with one another, a malicious agent may attempt to compromise a legitimate one. For these reasons, protecting the agent is significantly more difficult than protecting the host. Ad ditionally, the host needs a fair amount of access to the agent code and state in order
to support execution, thus posing additional security risks. Indeed, it may be simpler to
render potential attacks useless than to prevent them; for example, simply detecting such attacks and managing them accordingly. Preventing agents from being affected may not be possible, but it may be detectable [28, 50]. Avoiding the problem may initially appear interesting and ideal. For example, the exclusive use of trusted nodes [14, 50] resolves the issue quite directly by limiting mobile agents to a set of authenticated hosts. An agent’s home platform is generally trusted and inter-agent communication can be managed by specifying that it can only occur while
situated on an authenticated host. The use of trusted hardware [14, 27, 28] such as smart cards appears to be a sound solution; however, it may be too costly in most cases.
2.6.1 Agent Security Issues, Methods, and Techniques
Mobile agents are plagued by a variety of security threats, most of which stem from mali
cious hosts and some of which may be caused by other malicious agents. The following list
attempts to classify the mobile agent process by providing several approaches to thwarting security threats:
• Execution integrity
- Masquerading [14, 50]. An unauthorized agent claims the identity of another agent or, more plausibly, a host masquerades as a trusted host; for example, if
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 2. MOBILE AGENT SECURITY 25
the malicious host returns false system call values. Approaches include the use
of secure hardware [14,27,28], mutual trust [27,50], time-limited black boxes [14,27, 50] which protect the agent for a limited amount of time (useful in the case that confidentiality is temporarily required), contractual agreements [14] in which the host guarantees not to be malicious, and execution tracing [14,
50] wherein logs are kept of an agent’s execution and detecting unauthorized
modification of an agent is accomplished through recording its behavior during
its execution on each host. The use of partial result authentication codes [14, 50] which protects the authenticity of an agent’s state and execution result(s)
provides another approach. In this method, the state of the agent and the result provided by the agency or some system call is processed with a key (one of many) which is then thrown away before the agent migrates to another host. Undetachable signatures [14] can be used to limit the amount of damage that can be done to an agent. In this technique, constraints are encoded into a
signature key. If the constraints are not met, a valid digital signature is not
produced, thus preventing the message from being signed. In mutual itinerary recording [50], a cooperating peer maintains the agent’s path (i.e. its prior host, current host, next host, etc). Itinerary recording with replication and voting
[50] is a method in which multiple agents are sent to perform the same task. When received back at the home platform, each agent is checked for malicious events. Voting then takes place, and if a majority of the agents have succeeded in performing the task, then the agents can perform the next task.
- Incorrect execution of code (including re-execution) [14]. An agent must be protected from incorrect execution of its code. If, for example, and agent ex ecutes a buy order for a number of stocks, that transaction must not be re
executed.
- Denial of execution [14]. An agent must not be completely denied execution
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 2. MOBILE AGENT SECURITY 26
on a host unless the host deems it necessary for security reasons. Furthermore, if, for example, the agent does not possess the necessary rights to request a particular service or host resource, it must be denied the request; in this case,
a partial denial of execution.
- Denial of Service [50]. Rapidly receiving sent messages by another agent
(spamming) or a malicious host ignoring a request for resources thus caus ing delays (e.g. placing a stock trade). The case of a host altogether ignoring the agent is another possibility. Livelock, wherein the host gives the agent too many tasks so that it cannot complete its given (original) task, can likewise occur.
• Execution privacy
- Situatedness [14]. An agent must keep track of its state, data, and host itinerary.
The protection of critical information (where to go next, what to collect, etc) which typically includes code, state, and data is imperative. The unmonitored
observation of code, state, and data must be prevented as well as, and per haps more importantly, its manipulation and/or alteration (e.g. manipulating the agent’s route) or altering any messages to be sent to the next host (e.g. changing a sell order to a buy order). Several techniques include partial result encapsulation [50] wherein the results of an agent’s actions on a host are en
capsulated and verified at a later time. Partial result authentication codes [50] reduce the work a compromised agent must redo. In this method, results are authenticated with a throw-away key before moving to next host. If the agent is affected, then all results prior to the malicious host are still valid, hence there is no need to redo them.
- Eavesdropping [14, 50], An agent is secretly monitored (including code in structions which may need to be kept private). Techniques to surmount this in-
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 2. MOBILE AGENT SECURITY 27
elude environmental key generation wherein the agent carries encrypted code and/or data. The key is generated by environment variables so that it can only
be decrypted within that same environment-when a predefined environmental
condition is met-thus supporting the view that a successful decryption implies transit to a safe host. This ensures that an agent has access to some prede
termined assurance of validity in the information source. In general, this is difficult to do primarily because the environmental variables must themselves
be protected [28]. Computing with encrypted functions offers another tech nique to help reduce agent compromise. Here, an encrypted agent function is executed on the host. For example, if (normally) the agent must execute a
function /( ) on a host, it can instead be given a program P(E(f)) which imple
ments £ (/), an encrypted version of /(). Successively, this permits the agent to execute code that the host cannot see (e.g. proprietary code). Obfuscated code prevents the host from gaining a complete understanding of the agent’s code. Time-limited blackboxes (which expire) can also be implemented.
• Autonomy [14]. An agent must be protected during transit. Typically, the transit or moving process is performed as follows [98]: The agent’s execution is suspended
and its current state is identified. It is then serialized, encoded, and transferred to a remote host. Once the host has authenticated the communication, it decodes and deserializes the mobile agent, instantiates it, restores its state and resumes its
execution. Clearly, this introduces numerous security concerns. Eavesdropping on
the agent-agency communication or manipulation of the communicated message (the serialized agent) must be prevented. The solution is to utilize cryptography, thereby encrypting the agent, message, and/or the communication channel.
Recently, Artail and Kahale, in [ 6 ], have proposed a new method of implementing agencies. Utilizing web services as the agency stand-in, they suggest a message passing paradigm for the migration of mobile agents from one host to another. Mo-
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 2. MOBILE AGENT SECURITY 28
bile agents are, as described earlier, serialized and transmitted to the host. What is
interesting in this specific case is that the agents are literally passed as messages in the SOAP envelope. Any data the agent is carrying are included as an attachment
to the message. Utilizing web services in this manner adds a new perspective on the mobile agent paradigm. Much work has been done in the area of web service
security [10,11,12,13,42], and several others have suggested a synthesis of mobile agents and web services in different capacities [48].
Unauthorized access (by other malicious agents) poses an additional security threat.
For example, a malicious agent may attempt to buffer overflow another agent or reset it to some other state. Moreover, it may even alter its data and/or code in order to turn it into a malicious agent. There several additional methods and techniques in the literature which aim to help foil would-be attackers. For example, agents that go back home after each hop are less likely to be compromised [50]. Voting between multiple replicated agents sent to numerous different hosts [28, 50] may aid in detecting malicious hosts. Cooperating
agents [14] possess the unique characteristic that no single agent can be compromised to reveal the complete information or task. The use of a master agent [28], wherein several agents move and negotiate but a transaction can only be completed by the master agent,
offers some protection. The master agent may reside on the home host which is inherently trusted. Additionally, users can entrust agents with limited capabilities [28] (e.g. small amounts of money to purchase items or services), or the agent can be signed with a tem porary proxy certificate which expires in a short time [28]. In this case, one hopes that the
agent will have performed its required transaction before the certificate is broken. Clearly, this is advantageous for tasks which, once completed, need not be surreptitious anymore. Indeed, so many partial solutions exist, but unfortunately none offer a comprehensive se curity strategy.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 2. MOBILE AGENT SECURITY 29
2.6.2 Protecting the Data
Quite often, a mobile agent must gather some sort of data. Intuitively, the protection of
this data is frequently critical. Claessens categorizes the protection of data as follows [28]:
• Data confidentiality. Only the originator of the agent can extract the information. This is usually performed when the agent arrives at its destination (which is typically its home platform). The host may digitally sign the data and, additionally, encrypt them with the agent owner’s public key in order to ensure the confidentiality of the
data.
• Non-repudiability. Hosts cannot repudiate the information.
• Forward privacy. The identities of previous hosts are not disclosed to the current host or to any other agent.
• Forward integrity. No gathered information can later be modified. In situations
where small amounts of data are collected by the agent, this succeeds. If a portion of the agent’s task is to filter data-involving previously collected data-forward integrity poses problems.
• Publicly verifiable integrity. Anyone can verify the chain of information. For pub licly available information, any host, agent, or user can verify and validate the data
collected by an agent.
• Insertion resilience. No data can be added to the agent’s briefcase unless this is explicitly allowed by both the agent and the agency.
• Truncation resilience. Only the data compromised by a malicious host or entity can
be removed from the agent’s briefcase (additionally, see [60]).
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2.7 Summary
In this chapter, a comprehensive review of the security of the mobile agent paradigm has been presented. The characteristics of mobile agents introduce unique problems and pose
additional security issues. MAS introduces a paradigm which largely increases the scale of security threats. Typically, security can be categorized as protecting the host, protecting the agent, and protecting the method of communication (e.g. the communication channel).
Protecting the agent appears to be much more difficult than protecting the host because
the host must have access to the agent’s code and state. Numerous security issues coupled with techniques and methods to overcome them have been proposed in the literature. Ad ditionally, the data an agent carries must often remain confidential; its integrity must not be compromised. Quite often, mobile agents are utilized to gather, filter, and rank data; therefore, they must be protected in order to ensure that only the agent’s owner properly
receives the data.
30
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 3 MOBILE AGENT MODELING TOOLS
In this chapter, several modeling tools will be discussed, including Petri nets and its deriva
tives and extensions (e.g. dynamic Petri nets and CO-OPN/2), 7 t-Calculus and several of
its extensions, ambient calculus, SPI Calculus (a secure extension of the 7t-Calculus), API
Calculus (a mobile agent extension of the Tt-Calculus), and several other modeling calculi
(e.g. SMA Calculus, SPC Calculus, Join Calculus, and other process algebras). We tie in the motivation for this thesis-the DDI framework-and note the shortcomings of each tool with respect to modeling the framework. Unique characteristics are identified which clearly allow separate components of DDI to be adequately modeled, thus providing some direction of tool choice. Furthermore, the unique features of mobile agents and MAS are always considered when evaluating each modeling tool.
3.1 Petri Nets
Petri nets offer a pictorial view of the system. They are generally used to model systems which exhibit inherent parallel, asynchronous, and concurrent characteristics. In this sec tion, an informal introduction to Petri nets is presented. Various Petri net extensions are
further discussed. For a formal and thorough review of Petri nets, the reader is referred to
[70].
Overview
Petri nets are pictorially represented as a bipartite graph comprising of two main com
ponents. Figure 3.1 illustrates a typical Petri net. Nodes are comprised of places (the circles in the figure) and transitions (the bars in the figure) which are connected by di rected arcs. These arcs may denote direction from a place to a transition or vice versa. An arc that goes out of a node i and into a node j (the configuration of these nodes (i.e. which is a place and which is a transition) is unimportant at the moment) denotes that i is an input to j and that j is an output of i [79]. Transitions have an input place and an output place.
31
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 32
Figure 3.1 : Graph representation of a Petri net
t1
Figure 3.2: A marked Petri net
The dynamic properties of a Petri net can be modeled with the use of movable tokens which represent amarking (state), thus yielding a marked Petri net as shown in Figure 3.2. A marked Petri net is said to have an initial marking. A place may have any number of tokens. Several rules must be followed with respect to moving the tokens around [79]:
• Tokens are moved by the firing of transitions.
• A transition must be enabled in order to fire.
• A transition is enabled if all of its input places contains a token.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 33
t,1
Figure 3.3: The Petri net resulting from the firing of transition t\
Figure 3.4: The Petri net resulting from the firing of transition
• The firing process removes a token from each of a transition’s input places and puts a token in each of a transition’s output places. This occurs atomically.
Multiple transitions may be enabled simultaneously, any one of which can fire. Note that it is not mandatory that an enabled transition fire. Moreover, firing is nondetermin- istic, thus Petri nets are well suited for modeling the concurrent behavior of distributed systems. In the original definition, only one token could be removed from and added to a place during the firing of a transition. Weighted Petri nets have since been defined which
generalize the original and allow multiple tokens to be removed from and added to a place.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 3 4
Typically, arcs are labeled with the appropriate weight; unlabeled arcs imply a weight of 1. In Figure 3.2, only transition t\ is enabled because it has a token in all of its input places (place p\). Transition tj is not enabled because it does not have a token in one of
its input places (place pi). When transition t\ fires, the marking changes (the token in p\ is removed, and a token is placed in pi) to the Petri net shown in Figure 3.3. Note that
transition tj is now enabled because all of its input places have a token (places p^.pi).
Once transition U fires, the Petri net transitions to that of Figure 3.4.
Formal Definition
A Petri net is defined as a 5-tuple (P,T,A,Mq,W), where
• P = (pi,p2 ,..., Pm) is a set of places.
• T = (t\, t2 , ..., tn) is a set of transitions.
• A C (P x T) (J (T x P) is a set of arcs wherein no arc may connect two places or two transitions.
• Mo : P —> N is an initial marking.
• W : A —► N+ is a set of arc weights, which assigns to each arc a 6E A some n specifying the number of tokens a transition consumes from a place or puts in a place when it fires. The marking of a Petri net can be stated as a vector, M, where the first value in the vector represents the number of tokens in place p \, the second value represents the number of tokens in place p2 , and so on. For example, the marking of the Petri net in Figure 3.2 can be stated as M = (1,0,0,1,0). Thestate space of a Petri net is the set of all possible markings. The reachability tree of a Petri net is the set of all states that the net can enter into by any possible firing of a transition. Often, Petri nets suffer from what is referred to as the state space explosion problem; there are too many markings that the net can take on, Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 35 t.1 Figure 3.5: The Petri net modeling a simple producer-consumer scenario a X = addcopy divide \a-b) a+b copy .subtract a-b ifa—b— 0 * is undefined Figure 3.6: The Petri net modeling the equation x = (a + b)/(a —b) thus rendering it difficult to analyze. Several techniques (e.g. in [23]) have been proposed related to this problem. Petri nets can be used to model quite a large number of things from the elementary to the most complicated. For example, a traditional producer-consumer problem is modeled in Figure 3.5, and the equation x=(a + b)/(a — b) is modeled in Figure 3.6. Clearly, these are very simple examples to model. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 36 Extensions to the Petri Net Removing the single token limitation was one of the first extensions to the simple Petri net. Generalized Petri nets allow the removal of more than one token from an input place and the addition of more than one token to an output place upon the firing of a transition. Mobile Petri nets [87] are a generalized form of Petri nets and are comprised of Mobile nets and Dynamic nets. Mobile nets support the passing of a reference to a process along a communication channel. Communication channels are modeled as places in the net and mobility is implemented by the moving of colored tokens (tokens with values). Dynamic nets provide the capability to instantiate a new net during the firing of a transition for true dynamic support. Mobility, in this case, can be viewed as the process of creating a copy at the new location and terminating execution at the current location [ 1 0 0 ]. Communicative and Cooperative nets [100] provide mechanisms that allow nets to communicate with each other. Effectively, communicative nets provide the capability to model communication via message passing, and cooperative nets model communication via the client-server paradigm. In communicative nets, a subset of places is reserved for data that are scheduled to be sent to another net. Transitions are relatively more involved, personifying data function calls similar to a producer-consumer, message sending, and object creation. Cooperative nets substitute message sending transitions for service request and retrieve transitions. CO-OPN/2 (Concurrent Object-Oriented Petri nets) [87,100] allow the modeler to deal with interacting object-oriented systems, including many traditional facets of the object- oriented model (e.g. inheritance, abstraction, polymorphism, etc). Many object (algebraic) nets interact with each other. Summary Mobile Petri nets provide mechanisms similar to Tt-Calculus that allow mobile agents and agencies to be modeled. Mobility is accomplished via the message passing of ref Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 3 7 erences [100], just as in rc-Calculus wherein mobility is accomplished via the message passing of channels of communication. While Petri nets and 7t-Calculus are fairly equiva lent with respect to modeling mobility, rc-Calculus is much more flexible in that it is well suited for the composition of processes [ 1 0 0 ] and lends itself well to analysis via com puters. Moreover, although mobile nets support tokens with values, modeling multiple instances of a process is problematic; accounting is generally left to the user [1]. There are additional limitations regarding mobile nets. For example, some synchronization pat terns seem difficult to model. Events which generate nonlocal effects are difficult to model given that the firing of a transition is always local to the net. The nondeterministic man ner in which transitions are fired introduces considerable complexity; therefore, the firing of transitions is considered to be instantaneous which is not particularly realistic [79]. Petri nets are unfortunately not well designed for representing mobile intelligent agents and multi-agent systems. For example, the natural grouping behavior of agents and their associated intelligence is not easily modeled, often resulting in a very confusing model. 3.2 7t-Calculus 7 t-Calculus is a process algebra which has its roots in CCS (Calculus of Communicating Systems) [77], which was originally developed in the late 1970’s. In fact, it is an exten sion of CCS that supports mobility. In general, process algebras define variables which denote arbitrary channels and processes (operators); operators describe relations between processes and channels [67]. The tt-Calculus models the changing connectivity of inter active systems, focusing on the interaction between processes. It provides primitives for describing and analyzing distributed systems which focus on process migration between peers, process interaction via dynamic channels, and private channel communication. Ex ample applications include languages that support distributed programming with process mobility and description and analysis of authentication protocols. What follows is an informal introduction to the 7 t-Calculus. For a more thorough Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 3 8 review, the reader is referred to work presented by Milner et. al [63, 64] and Parrow [77]. Overview According to Wing [117], a process is an abstraction of an independent thread of con trol. A channel is an abstraction of the communication link between two processes. Pro cesses interact with each other by sending and receiving messages over channels. What es sentially separates 7 t-Calculus from other modeling methods is the ability to pass channels as data along other channels; this allows the expression of process mobility which allows expression of changes in process structure. Therefore, 7i-Calculus is a natural choice for describing concurrent processes that communicate through message passing. However, it is not good at describing abstract data types or states with rich or complex data structures. Preliminary Definitions [67, 77, 117] 7t-Calculus consists of a set of prefixes and process expressions. The basic building block is the set of infinite names 3Sf which vary over a,b,...,z. These names function as communication channels, variables, values, and process identifiers (varying over A). The prefixes are as follows: a (x) output the message x is sent along the channel a a{x) input the channel a can receive input and bind it to x x silent nothing observable happens In general, a denotes an arbitrary action prefix (input, output, or silent). Agents (or processes), varying over P, Q,..., are defined in Table 3.1. Agents can be of the following form: 1 . 0 , the nil process (empty process) which does nothing. 2. a (x) .P, an output prefix', the process sends a message x over the channel a and then Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 39 Table 3.1: 7 t-Calculus Syntax Prefixes a a(x) Output a(x) Input X Silent Processes P ::= 0 Nil a.P Prefix P + P Sum P | P Parallel i f x — y then P Match i f x y then P Mismatch (vx)P Restriction A(yi,y2 ,...,yn) Identifier Definitions A(x l,X2 ,...,Xtt) =P (where i^fi j => Xi ^ xf) proceeds as P. 3. a(x).P, an input prefix; the process waits on channel a to receive a message that is then bound to jc and then proceeds as P. 4. x.P, thesilent prefix', nothing observable happens (i.e. the process can proceed as P by doing nothing). 5. P + Q, a sum; non-determinism (i.e. the process can represent either P or Q). 6 . P | Q, a parallel composition; processes P and Q run concurrently. 7. i f x = y then P, a match; if x and y are the same name, the process will behave as P. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 40 8 . i f * y^y then P, a mismatch; if x and y are not the same name, the process will behave asP. 9. (vx)P, a restriction', the variable x is bound to P (i.e. it is local and cannot be immediately used for communication between P and its environment). 10. A(y\ ,y2 ,. .. ,yn), an identifier; n is the arity of A and every identifier has a definition A(xi,X2 ,...,xn) — P, whereXi are pairwise distinct. Match and mismatch constructs are the only valid tests within the calculus; they can only compare names for equality. They can be combined (including by using sum), for example: i f x = y th e nP+ i f x ^ y then Q behaves asP if x = y or Q if x ^ y is true. Note that this example can be abbreviated (thus simplified) by the following: i f x = y then P e lse Q Furthermore, the following shortcuts are often employed for the match and mismatch operators: i f x = y then P = [x = y}P # i f x 7 ^ y then P = [x^ y]P The input prefix a(x).P binds x in P; however, the output prefix a {x) .P does not. Input and output prefixes have a subject a and an object x, where the object isfree in the output prefix and bound in the input prefix. Bound names in P are defined as bn(P) and free names in P are defined as fn(P). Substitutions are maps for names. For example, the substitution that maps y to x is written as x/y. In general, x\ ,X2 ,... ,xn/y\,y2 ,...,yn for pairwise distinct y* maps each y;- Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 41 to Xi. a is used to range over all substitutions, and sometimes x can be used to represent a sequence of names of unimportant length. Structural Congruence [67, 77] Two processes are structurally congruent if they are identical in structure. For example, P | Q is equal to Q \ P. Essentially, the calculus is not orthogonal; there are many ways to represent the same thing. Therefore, a structural congruence is defined in Table 3.2 which resolves these similarities and ensures that equivalences are resolved. Note that the axioms for parallel composition also apply for sum. Moreover, unfolding ties an identifier to its definition (i.e. they are the same so long as their respective parameters are). Also note that (yx){P | Q) is not equivalent to (vx)P \ (vx)Q. In the former, P and Q can interact using x (it is shared) while in the latter, the same occurrences are local to each process. Reduction via Simple Examples [67, 77] We write P —► P' if P can perform a computation step and become P'. The reduc tion relation —> (often written as A ) is defined as the least relation closed under a set of reduction rules. For example: a{x) .c (x) \a(b) —>c{b) | 0 and in general: a(x).P | a(b) .Q P{b/x} \ Q 3.2.1 The Polyadic%- Calculus The polyadic 7 t-Calculus allows the communication of more than one name (e.g. tuples of names, sorts, functions, and data structures) during a single action [67, 77]. For example: d{b\,b2,... ,bn) .P \ a(xi,x2,... ,xn).Q which can be encoded in the monadic 7t-Calculus as follows: (vw)o(w) .w (b\) .w (b 2 ) ■ ■ ■ ■ .w(bn).P | a(w).w(x\).w(x2 ).--- .w(xn).Q Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 42 Table 3.2 : The Definition of Structural Congruence Alpha conversion P — Q Axioms for parallel composition P 1 Q = Q\P (P\Q)\R = P\(Q\R) P |0 = P Unfolding A(J0 = P{y/x} i f A(x) =P Scope extension (vx) 0 = 0 = («)(/>ie ) P | (vx)Q i f jc i f n (P) (vx)(P +Q) = P+(vx)Q i f x i f n(P) (v;t)if u — v then P = i f u = v then (vx)P i f x ^ u and x ^ v (vx)if thenP = i f then (vx)P if xy-u and x ^ v (vx)(vy)P = (vy)(vx)P In general: a(x).P | a(y) .Q ^ P{y/x} | Q The mobility represented by the polyadic Tt-Calculus implies a reference passing, wherein processes do not actually move; instead, the communication configuration changes [ 1 0 0 ]. 3.2.2 The Higher-Order 7t-Calculus (H07t) The idea behind higher-order 7 t-Calculus is that it can additionally support the sending of processes or agents through channels [77]. Mobility is indeed a true mobility where processes (agents) can be sent through channels, move, and change their configuration [100]. Although the term agents is used generally in the calculus, it may in reality be Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 43 appropriate to consider the agent in the AI sense-that is as an intelligent agent [ 8 8 ]. A higher-order output prefix is given by: a(P).Q which implies that the agentQ sends agent P along the channel a and then behaves as Q. The input prefix is given by: a(X).Q which implies that the agentQ receives an agent along channel a and binds it to X then proceeds as Q. For example: a(bu.O ).b(x ) | a(X).(X | cv) b(x ) \bu\cv In this case, the first process sends bu.O along channel a. The second process receives it, binds it to X, and executes it in parallel with cv. Higher-Order 7t-Calculus introduces the concept of an agent variable (varied over X). The formal definition is given as: a(X).P\a(Q).R^P{Q/X}\R Summary In this section, we have presented the 7 t-Calculus and several enhancements. Clearly, for the purpose of modeling mobile agents and multi-agent systems, only HOtc offers any support as it allows the communication of agents via channels. Nevertheless, H07t does not allow us to formally model the natural grouping behavior or intelligence of mobile intelligent agents. Furthermore, it provides no constructs for modeling security techniques or cryptographic protocols. 3.3 Ambient Calculus Ambient calculus introduces the concept of ambient in order to model the movement of one location of activity inside another. An ambient is a fundamental primitive in the calcu Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 44 lus and is simply a bounded place where computations can occur-it is the key to represent ing mobility in the calculus. Ambient calculus groups processes into multiple, disjoint, distributed ambients (as opposed to 7t-Calculus), enables interaction by shared position, and implements access control by using capabilities derived from ambient names [39]; se curity in the ambient calculus is implied by the view that crossing boundaries is guarded. The mobility represented in the calculus is general in that it allows mobility of processes, channel names, and entire environments [ 1 0 0 ]; the crossing of boundaries implies mo bility. Boundaries surrounding ambients permit the definition of separate locations, thus inferring some sort of abstract knowledge of the distance between locations. Inter-agent communication occurs within a common boundary. What follows is a cursory introduction to the ambient calculus. For a more thorough review, the reader is referred to work done by Cardelli and Gordon in [20,21,22, 39]. Ambients In general, communication within an ambient is local to that ambient, is anonymous, and is asynchronous. Ambients have names which strictly controls access (entry, exit, communication). They can be nested within other ambients to produce computational en vironments within computation environments. Moreover, ambients can be moved entirely through channels defined in the calculus. Boundaries surrounding ambients rigorously control what is inside and outside the ambient. Examples of ambients include a web page (bounded by a file) and a laptop (bounded by its case) [22]. Each ambient has, within it, agents which perform computations. Furthermore, they, in some sense, control the ambi ent; for example, they can instruct it to move. Mobility and Communication The primitives of the calculus are given in Table 3.3. Free name equivalences are given in Table 3.4: Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS Table 3.3: The Primitives of the Ambient Calculus Processes P,Q ::= (vn)P Restriction 0 Inactivity p 1Q Composition \p Replication M[P] Ambient M.P Action (x).P Input action (M) Asynchronous output action Capabilities M ::= x Variable n Name in M Entry (can enter into M) out M Exit (can exit out of M) open M Open (can open M) e Null M.M' Path There are several syntactic conventions in the ambient calculus: (vn)P | Q -> ((vn)P)\Q '■P\Q -» {\P)\Q M.P | Q (M.P) | <2 and several abbreviations: (vni,vn2,...,vnm)P = (vni)(vn2).--(vnw)P «[] 4 n[0] M = M.O Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 46 Table 3.4: Free Name Equivalences in the Ambient Calculus fn((vn)P) A fn(P) - {n} MO) A 0 A MP 1Q) fn(P)Ufn(Q) A fn(\P) MP) A M m [p ]) {M }U fn(P) A_ MM.P) fn(M) Ufn(P) A fn((x).P) MP) M m _A fn(M) fn(x) A 0 fn(n) A {n} A fn(in n) in) A_ fniput n ) in) A fn(open n) w A_ / » ( e ) 0 A_ fn(M) Ufn(M') The restriction operator (vn)P creates a new unique name n within a scope P. This name can then be used to name ambients and to operate on ambients by name. Reduction, as in the 7t-Calculus, allows transparent restriction; for example: P —> Q =>- (vn)P —>■ (vn)Q The process 0 does nothing. An ambient n[P] possesses name n with process P running inside of it. It is implied that P is actively running and that P can be made of more than one concurrent process. Since ambients can be nested within each other, it is entirely possible to have, for example n[P \ m[Q]]. The process M.P executes an action regulated by the capability M then continues as the process P. Note that P is not running until the action is executed. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 47 The entry capability in m.P instructs the ambient surrounding in m.P to enter a sibling ambient named m. The reduction rule is: n[in m.P \ Q] | m[R] —► m[n[P \ Q] | /?] or pictorially as shown in Figure 3.7. m m inm.P\Q R Figure 3.7: The ambient resulting from the process n[in m.P \ Q] | m[R] Conversely, the exit capability out m.P instructs the ambient surrounding out m.P to exit its parent ambient m. The reduction rule is: m[n[out m.P | Q] | /?] —>•n[P \ Q] | m[R] The open capability open m.P removes the boundary surrounding ambient m. The reduc tion rule is: open m.P | m[Q] —> P \ Q Ambient I/O is possible via input and asynchronous output actions [22]. An output action releases a capability into the surrounding ambient. Conversely, an input action re quires a capability from the surrounding ambient which it binds to a variable. For example: (x).P| (M) —* P{x <— M} whereP{x <— M} implies the substitution of the capability M for each free occurrence of the variable je in the process P. Structural Congruence [22] Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 48 Table 3.5: The Definition of Structural Congruence p = p Reflection P = Q ^ Q = P Symmetry P = Q,Q = R^ P = R Transition P = Q^> (vn)P = (vn)Q Restriction P = Q=^P\R = Q\R Parallelism P = Q ^ \P = \Q Replication P = Q^n[P]=n[Q] Ambience P = Q=^ M.P = M.Q Action P\Q = Q\P Parallel commutativity (P\Q)\R = P\(Q\R) Parallel associativity \P = P\\P Parallel replication (vn)(vm)P = (vm)(vn)P Restriction restriction (vn)(P | Q) = P | (vn)Q if n (£ fn(P) Parallel restriction (vn)(m[P]) = m[(vn)P] iln^m Ambient restriction P\Q = P Zero parallel (yn) 0 = 0 Zero restriction !0 = 0 Zero replication Table 3.5 shows the structural congruence of the ambient calculus which helps us to resolve expressions of the same meaning in the calculus. A Mobile Agent Example In the following example, a mobile agent wishes to leave its home and later return. The home host must, however, authenticate the mobile agent before it can resume execution: Home[(vn)(open n \ Agent[out home.in home.n[out Agent .open Agent .P]])\ Initially, it may not be clear exactly what is happening. Essentially, a shared secret Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 49 n within the safe location Home is distributed over the network (carried by Agent)', the authentication is based on this shared secret [22]. The following is the behavior of the computation: Types In order to ensure the arity of the messages that are input or output on a channel, types were introduced in the ambient calculus (similar to sorts in the 7t-Calculus). Types are essentially based on the idea of partitioning ambients in defined groups in order to track communication and mobility properties [20,21]. Home[(vn)(open n \ Agent[out home.in home.n[out Agent .open Agent .P]])} = (yn)Home[open n \ Agent[out home.in home.n[out Agent.open Agent.P]]] —► (yn)(Home[open n] \ Agent [in home.n[out Agent.open Agent.P]]) —>■ (yn)Home[open n \ Agent[n[out Agent.open Agent.P}]] —» (yn)Home[open n \ n[open Agent.P\ \ Agent[ ]] —> (vn)Home[0 | open Agent.P \ Agent[ ]] —> (yn)Home[0 | P | 0] = Home[P\ Extensions A variant of ambients called boxed ambients was proposed by Bugliesi et. al in [17], wherein theopen capability is dropped and several new primitives are introduced to man age communication between ambients (across boundaries). The view is that this will pre vent the code of untrusted agents to mingle freely within trusted ambients. Furthermore, the concept of read/write access is difficult to model using traditional ambients. Summary There are several limitations to the ambient calculus. First, it is difficult to model the concept of a mobile agent briefcase (of data) using traditional ambient calculus; however, interface ambients have been proposed as a potential solution to this [103]. Second, the inherent synchronous nature of the in, out, and open capabilities poses some problems Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 50 with respect to using the calculus as the core programming language for mobile and dis tributed computing systems. Although the ambient calculus does provide some rudimen tary form of authentication with respect to entering an ambient, it provides no constructs for modeling cryptographic protocols or many of the techniques proposed in chapter 2 for maintaining the security of mobile agents and agencies. Moreover, there are no constructs provided in the calculus to model the intelligence of an intelligent agent. 3.4 SPI Calculus The SPI calculus extends the 7t-Calculus by adding cryptographic primitives in order to provide support for modeling cryptographic protocols [3] (e.g. authentication). Further more, it facilitates the study of cryptographic protocols in a high level of detail. 7t-Calculus does not include primitives for encryption and decryption (e.g. the concept of secret keys); therefore, the SPI calculus was proposed in order to support the expression of crypto graphic operations that typically serve as the foundation for security in distributed systems. Subsequently, the SPI calculus allows for finer analysis of such security protocols. In SPI Calculus, scoping plays an integral part in preventing an attacker from intruding on some communication. For example, it guarantees that an attacker cannot access a channel that it does not have authority to access. Thus, scoping forms the basis of security. Furthermore, the calculus supports contextual equivalence for the specification of security properties; modeling an attacker explicitly is thus unnecessary [43]. With 7t-Calculus’ strong scoping rules (e.g. scope extrusion), this natural extension fits quite well into the 7i-Calculus family. The SPI Calculus provides mechanisms to not only clarify what messages are sent, but additionally elucidates how messages are generated and checked [4]. The syntax is described in Table 3.6. In 7t-Calculus, names are the only terms. The SPI Calculus adds constructs for pairing and numbers as well as a clear distinction between variables and names. Reduction, free Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 51 Table 3.6 : The Syntax of SPI Calculus Terms L,M,N ::= n Name (M,N) Pair 0 Zero suc(M) Successor X Variable Processes P,Q,R ::= M(N).P Output M(x).P Input P 1Q Composition (vn)P Restriction \P Replication [M is N]P Match 0 Nil let (jc,y)— M in P Pair splitting case M o f 0 :P suc(x): Q Integer case and bound names, replacement, and the input and output prefixes are used as in the 7t- Calculus. The match operator (e.g. [x is y]P) is very similar to the shorthand [x — y]P in the Tt-Calculus. Two new process forms have been added: • let (x,y) = M in P, pair splitting ; behaves as P{NL/xy} if term M is pair (N,L). • case M o f 0 :P suc(x): Q, integer case ; behaves asP if term M is 0 or as Q{N/x} if M is suc(N). Consider the example illustrated in Figure 3.8. Given a server S and two principals A and 5; initially, a channel exists from A to S and from S to B. Note that no channel Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 52 AS SB Figure 3.8: Structure of the Channel Establishment Example initially exists from A to B. The scenario is simple: A must send a message to S passing the newly created channel from A to B. Through S, the channel from A to B is transmitted to B. Ultimately, A may send some message M using the newly created channel (that is now known to B) from A to B. The protocol in the calculus is as follows: A(M) 4 (v C ab )CT s (C ab }-C ^ (M ) S = CAS(x).C^(x) B 4 C5BW.x(y).F(y) Inst(M) 4 (v C as )(v CSb)(A(M) \S\B) whereA(M ) represents principal A with message M, F(y) is some sort of function that B applies to y once it receives the message, and Inst(M ) is an instance of the protocol. Abadi and Gordon in [3] introduce a specification for representing authenticity; the protocol can be rewritten as follows: A(M) 4 (v CAb)C as {C ab } -Cab {M) S = CAs (x).C sb (x) Bspec = CSB(x).x(y).F(M) Instspec{M) 4 (v C as )(v C sb)(A(M) \ S | Bspec(M)) whereBspec is a special version of B that knows the message M sent by A; it is essentially an intrinsic reduction. Similarly, Instspec is just a special version of Inst which realizes the instance of the specification of the protocol. Shared-Key Cryptography [3] Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 53 The power of SPI Calculus becomes clear when we attempt to model a simple shared- key cryptographic protocol, which amounts to nothing more than adding several clauses to the calculus: Terms L,M,N ::= ... (as originally defined) {M}^ Shared-key encryption Processes P,Q ::= ... (as originally defined) case L o f {x}jyin P Shared-key decryption where the term{M }^ represents the cyphertext obtained by encrypting the term M under the keyN using shared-key cryptography (e.g. DES) and the process case L o f {x}^ in P attempts to decrypt the term L with the keyN. If successful, the process will behave as P{M/x}. A simple example. In this case, consider two principals A and B that share a keyKab and a channel C ab (which is not necessarily secure); A wishes to send a message encrypted with the keyK ab (using shared-key cryptography) to B: A(M) 4 Cab {{M} kAb) B = C ab (x) •case x o f { y } ^in F (y) Inst(M) 4 (vKab )(A(M) | B) whereF(y) is a function that is applied to the message M when B receives it. The protocol can be rewritten under the following specification: A(M) A CTb {{M}Ka,) Bspec = CAB{x).case x o f {y}*-ABin F(M) Instspec(M ) 4 (vKab )(A(M) \ Bspec(M)) Summary SPI Calculus, although somewhat more difficult to use than, say 7t-Calculus, compen sates with its formal precision. Clearly, numerous security protocols (public key cryptog raphy, for example) may be modeled using the SPI Calculus. Although well suited for Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 54 modeling security particularly with respect to cryptographic protocols, the SPI Calculus is a direct extension of the 71-Calculus. As such, it offers no constructs well suited for the modeling of the natural grouping and migration behavior of agents in MAS or the associated intelligence of mobile agents. 3.5 API Calculus API Calculus [84,86] attempts to extend the 7t-Calculus in order to more accurately model intelligent mobile agents by directly addressing their characteristics of intelligence, natu ral grouping, and migration. Its goal is to be used to successfully model key issues with respect to mobile agent-based systems such as security, validation, verification, and per formance. As an extension, it introduces three new concepts to the 7t-Calculus: • Term: Consists of a name, a rule or fact, or a function; a name can be a variable or a channel. • Knowledge unit: Consists of a knowledge base and a set of facts. • Milieu: Embodies a family of processes (agents). The formal API Calculus syntax is shown in Table 3.7. Tuples of terms are sup ported in the calculus; for example, u and T may be used to abbreviate ui,U2,...,un and 7j, 7 2 ,... , Tn respectively. Sorts are likewise supported, as in the 7i-Calculus, which par tition a potentially infinite set of terms. R : s implies that the termR belongs to the sub ject sort s. A sorting function S f maps each subject sort to an object sort; for example, s i—► (?) £ S f implies thatS f assigns the object sort (?) to s. The action prefix a and sum mation behave as in the original calculus definition. The conditional is one of strict rather than syntactic equivalence. Knowledge name restriction indicates that a knowledge unit is local to a process (there may be more than one knowledge unit local to a process). The constant D is nothing more than a function whose parameters can be processes or other functions. Knowledge unit summation implies that more than one knowledge unit reacts to Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 55 Table 3.7: The Syntax of API Calculus Terms R,T x,y,z,..- Name a,b,c,... Fact or rule Function Processes P 0 No action a.P Action prefix P1 +P2 Summation [T = R]Pl :P2 Conditional vxP Restriction (Kl)P Knowledge name restriction !P Replication D ( l ) Constant Knowledge Units K ::= 0 Empty unit r Single rule Kx +K2 Summation of units Milieus M ::= 0 Empty milieu M[0\ Milieu M[0\ | O2] Parallel milieu M\ +M 2 Summation p.Mi Action prefix a fact simultaneously, essentially impersonating a single knowledge unit. M[0\ is a milieu in which process or milieu 0 exists. Similarly, M[0\ \ O2 ] is a milieu in which milieus or processes 0 \ and O2 are working in parallel. Milieu summation implies the merging of Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 56 two or more milieus. The milieu action prefix (3 can be one of three actions: • join m.M instructs milieu M to join milieu m then acts like M in m. • leave m.M instructs milieu M to leave milieu m then acts like M. • open.M removes the boundary surrounding milieu M\ all processes and milieus orig inally inside M continue to compute and operate freely with no further interaction withM. API Calculus supports the following actions: • x is an internal action. • x(Z) is an input prefix. A tuple of processes or terms is received over channel x and bound to L. • xL is an output prefix. A tuple of processes or terms L is sent over channel x. • (K).P implies that the tupleK is local to P. • Ki (a) (R) is a knowledge unit call where the knowledge unit Ki is passed a list of facts a. The result of the call is placed in R. • x(K)/ \ .P is an input prefix. A tuple of knowledge units is received over channel x and bound to K. The process then behaves asP. • xK is an output prefix. A tuple of knowledge units K is sent over channel x. • Ki(a) is a prefix that adds tuple a to the facts fist of Ki if it is a fact or to the rule list of K{ if it is a rule. • Kta is a prefix that drops a from the facts list of Ki if it is a fact or from the rule list of K if it is a rule. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 57 Table 3.8: Structural Congruence and Equational Reasoning in the API Calculus Structural Congruence [T = T]x.P = x.P Match 0\ + (0 2 + O3 ) = (0\ + O2 ) + O3 Summation associativity 0\ + 0 2 = 0 2 4- Ox Summation commutativity O i+O = 0 i Summation identity Ox | (O2 | O3 ) = (Ox | O2 ) | O3 Composition associativity 0 + 0 = 0 Same process Ox \ 0 2 = 0 2 \ Ox Composition commutativity 0 |O = O Composition identity v TxvT2P = v T2v TxP Restriction III 0 0 Restriction identity vT(Px | P2) = Px | vTP2, if T i ft(Px) Restriction composition \P = P\\P Replication Equational Reasoning 0 = 0 Reflexivity Ox ~ O2 +• 0 2 = Ox Symmetry Ox = O2 A O2 = O3 =+ Ox = O3 Transitivity P = Q^C[P]=C{Q\ Generality The reduction operator —> also applies to the API Calculus. For example: xL\.P\ \x(L2 ).P2 ^ P i \ P 2 {Li/L2} Structural congruence and equational reasoning in the API Calculus are illustrated in Table 3.8. Congruence is critical to the calculus and is intertwined with the concept of context. A context introduces the capability to transform a process into another process [84]. A context is obtained when the hole [.] replaces an occurrence of 0 in a process structure; it can subsequently be filled by a process. Given a context C and a process P, Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 58 C[P] implies that [.] will be replaced by P in a process. For example, given the following process and context expression: vz([.] | z(u).yu.0),C[P\ =C[zb.O] we can perform the substitution as follows: vz(zb .0 | z{u).yu. 0) Examples Passing processes as messages can be illustrated quite simply in the calculus. Consider the following process: vx(xPl.Q\x(X).(X\P2)) which can be stated as a process wishing to receive process Pi and subsequently executing it in parallel with process Pi. A reduction would produce the following: < q i m i ?i)) Suppose a process P is inside milieu M\ and that both M\ and process Q are inside milieu Mi. Process P wishes to send a rule a to process Q (which adds a to its knowledge unit K)\ Figure 3.9 illustrates a pictorial representation of this. The computation would take place as follows: M2 [Q\Ml [leave M] ./>]] -*• M2 [Q\Ml [0]\P] - Mi[Q\P\Mi[0]} -* M 2 [x(b).Q\xa.P\Mi[0}] - M2 [Q{a/b}\P\Mi[0]} -* Mi[K(a).Q | P | Mi[0]] Note that process P had to leave milieu M\ in order to communicate with process Q. Due to the notion of boundaries surrounding milieus, processes wishing to communicate Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 59 i Figure 3.9: Example of Interaction Between Processes Within Milieus must be within the same milieu (which may mean some sort of temporary relocation). We could, for example, instruct the process P to move back within milieu M\ in the initial expression via: M2 [x(b).Q | Mi [leave M\ Jca.join M\ .P]] which would result in the desired outcome; the reduction would be: m 2[Q\m 1[p]\ Perhaps a more complete initial expression resulting in the same reduction would be: M2 [x(b).Q{a/b}.K(a).Q \ M\[leaveM\.xa.joinM\.P]\ Summary It is clear that the API Calculus is indeed well suited for modeling and analyzing mo bile agents, including MAS. The concepts of milieu, knowledge unit, and term combined empower the calculus with an accumulation of useful tools with which to analyze poten tially complex MAS. Rahimi in [86] illustrates the power of the API Calculus by modeling a geospatial conflation MAS similar to one proposed in [85]. What is missing from the calculus, however, is the ability to accurately model the security of mobile agents. More over, the inability to communicate through the milieu boundary does not present the tools Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 60 necessary to capably model the communication in a real-world distributed computing sce nario. 3.6 Other Modeling Methods In this section, several other modeling methods will be briefly identified. There are a wide variety of calculi-such as SMA Calculus, SPC Calculus, Join Calculus, etc-which attempt to model the complexity of MAS (or mobile agents in general). The Distributed Join Calculus represents mobile agents by locations. In this sense, agents may contain sub-agents; this is very much like ambients in the ambient calculus and milieus in the API Calculus. The syntax of the join calculus is pseudocode-like which lends itself quite well to the elaboration of a model. Alas, the calculus provides no way to model the intelligence of intelligent agents, the natural grouping characteristics of mobile agents, or the security often required in MAS. The SMA Calculus is based on the Seal Calculus and infers an implied security by restriction (as in the ambient calculus). Included are primitive constructs for the modeling and analysis of cryptographic protocols. There is, however, no way to model the natural grouping and migratory characteristics of mobile agents or the intelligence of intelligent agents. A rudimentary introduction of process knowledge (i.e. agent intelligence) is intro duced in the SPC Calculus, although it does not compare to the API Calculus. In this simplification of the SPI Calculus, there is no way to model groups of agents (i.e. their collective behavior), the intelligence of an intelligent agent, or many of the security tech niques reviewed in chapter 2. 3.7 Summary In this chapter, several practical modeling methods were discussed. Petri nets and numer ous extensions (e.g. CO-OPN/2) provide a user-friendly pictorial view of a concurrent Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 3. MOBILE AGENT MODELING TOOLS 61 system and further provide capabilities that allow the modeled system to be analyzed. Tt-Calculus offers a linear mathematical method of modeling and analyzing complex con current systems with strong scoping rules. Channels of communication can be passed along, thus providing the support for mobility. Ambient calculus introduces the concept of ambients (bounded places) wherein computations can occur. Access is controlled by the strong use of ambient names. The modeling of cooperating systems (e.g. MAS) seems to fit well within the context of ambient calculus. SPI Calculus is an extension of the Tt- Calculus which introduces several new primitives in order to provide support for modeling some of the security aspects of distributed systems (e.g. authentication). The flexibility and power of SPI Calculus allows for numerous cryptographic protocols to be modeled by simply adding clauses to the calculus. API Calculus is, too, a 7t-Calculus extension with the intent of strictly modeling mobile agents and MAS. The concepts introduced in the calculus (i.e. milieu, knowledge unit, and term) allow for a powerful means to model distributed cooperating systems. Notwithstanding the modeling method of choice, mobile code is becoming increas ingly employed in many ways, thus motivating the formal analysis of systems which im plement these concepts. It is worth mentioning that the verification of a system plays a rather important role when considering the analysis of the system. Certainly, process calculi can be used to model a system and to determine whether it behaves as intended. Often, however, we wish to perform a more formal analysis and verify the system according to a set of behavioral constraints. Typically, this is accomplished by comparing the equality of the system’s formal description with that of the initial specification. The basis for this is provided by the notion of bisimulation as defined by Milner in [63,64]. A bisimulation is a binary relation 93 that is symmetric, such that if P93<2 and P ^ P' then there exists aQ' such thatP'iRQ 1 and Q ^ Q' where a is a process action. More Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. formally, we write: m Q A P ^ P '^ 3 Q ' (p'VKQ! A Q ^ of} Put differently, any transition from P must be simulated by a transition from Q such thatP' and Q' remain in the simulation. The relation 91 is a bisimulation if whenever two process terms P and Q exist such that(P. Q) C 91. This concept provides a method to deduce the behavioral equivalence of two processes defined in the calculus. Often we wish to more practically compare two processes; hence, several refinements to bisimulation exist. If we restrict a-transitions to input and output actions (e.g. x(y) and xy), for example, then weak bisimulation exists. This is particularly useful when we wish to evaluate the behavioral equivalence of two systems. 62 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 4 THE API-S CALCULUS In this chapter, we syntactically and semantically define the API-S Calculus (referred to as API-S in the remainder of the text) and offer numerous illustrative examples to further exemplify the calculus. API-S extends the API Calculus [84] by integrating primitives and constructs necessary to capably model several security aspects of the mobile agent paradigm. The calculus forms a foundation on which additional constructs can be built, thus offering the necessary tools to extend the breadth of the types of systems the calculus can model. API-S further expands upon the concepts of term, milieu, and processes-as defined in the API Calculus-in order to facilitate the modeling of numerous security techniques and protocols. We consider both the security of the agent and of the agency. API-S provides mechanisms to completely secure actions involving the knowledge unit as defined in the API Calculus. Note that the knowledge unit definition has not been changed but rather expanded upon in order to maintain its powerful functionality in mod eling the intelligence of an intelligent agent. As in API Calculus, agents possess the ability to add or drop facts from their fact list and to alter the knowledge base by adding or remov ing specific rules to their rule base. An agent may possess one or more knowledge unit, and support for sending such units to or receiving them from other agents is inherently provided, albeit in a secure fashion. The notion of term as defined in the API Calculus is maintained such that it does not drop the concepts of name, knowledge unit (rules and/or facts), or function. It is further extended to include an fl-term (crypto-term), which provides primitives for such attributes as a pair, a successor, and several other constructs (e.g. hashing and digital signatures) necessary to properly model a wide variety of cryptographic protocols. We discuss this in sections 4.1.1 and 4.1.3. The semantic abstraction that provides a powerful way to model families of agents, the milieu, is indeed inherited from the API Calculus, and its definition is only slightly 63 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 64 expanded upon in order to more capably model the security of the agency. In this way, we can, for example, model a group of agents working cooperatively on a similar task or even a group of agents residing on the same agency involved in secure communication. Furthermore, we provide a method to securely model process communication through the milieu boundary, something that is sorely lacking in the API Calculus. 4.1 Syntax The following constitutes the basic definition for the elements of API-S. It is important to note that much of the element definitions have been inherited from the API Calculus in order to preserve its conciliatory characteristics. 4.1.1 Term Definition 4.1.1. Term R, T x,y,z,... name | a,b,c,... fact or rule | f(x,y,z,...) function | R^jT0, fl-term A name may be a channel or a variable name. A fact or a rule can be added to a knowl edge base, sent to a different process, or received from a different process. A function may have I parameters; / ranges over the functions of <0, and one matches the arity of / . Variables u,v,w are used to range over names, facts, and rules. The abbreviations u and f are used in place of tuples u\,U2,...,ui and Ti,T2,...,T[ respectively. Terms are partitioned into a collection of subject sorts, each of which contains an infinite number of terms. We write if?: s to mean that term R belongs to subject sort s. As in the API Calculus, this notation is extended to tuples component-wise. Object sorts, ranged over by S, are simply sequences over subject sorts; for example, (si,S2 , • • •, si) or just ( 5 ). A sorting is a function Sf mapping each subject sort to an object sort. We write 51—>■ (?) G Sf if Sf assigns the object sort (.?) to s. In this case, we say that Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 65 (?) appears in Sf. By assigning the object sort ( 5 1 ,5 2 ) to the object sort s, the object part of any term in s is forced to be a pair whose first component is a term of s\ and whose second component is a term of S2 [95]. An Q-term compartmentizes cryptographic primitives for use in modeling an array of cryptographic protocols and techniques. They are further defined in section 4.1.3. 4.1.2 Process Definition 4.1.2. Process 0 no action a.P action prefix P1 +P2 summation process [T = R]P1 :P2 conditional process vxP name restriction (K>)P knowledge unit restriction IP replication D ( l ) constant M((P))N listener pQ. fl-process Processes are denoted by P,P i,P2 ,..., Pn and Q,Qi,Q2 , ■ ■ ■ ,Qn- The no action process is denoted by 0 and performs internal computation. The prefix a is called the action prefix. The expression a.P performs the action a and then behaves as P. The summation process Pi +P2 behaves as either Pi or P2 . Terms are identified by T and R. The process [T = P]Pi : P2 is then a conditional process wherein the equality of T and R is not a strict syntactic identity. When P 2 = 0, we abbreviate the conditional process to [T = P]Pi. The expression vxP makes a new private name x local to P then behaves as P. The knowledge unit restriction (Kj) P makes a new private knowledge unit Ki local to P. The replication Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 66 process IP implies (P | P | .. .); for example, Pi | P 2 consists of two processes P\ and P 2 acting in parallel and perhaps independently. Process synchronization (i.e. of an output action of Pi at some output port x with an input action of P 2 at x) is possible resulting in a silent (x) action. The constant D, where L indicates a tuple of processes or terms, is a function whose parameters can be processes or other functions. Formally, D is defined as D = (T^jP, where f is any tuple of terms. For example, consider xL to be an output prefix that sends a term or process L on channel x and x (L) to be an input prefix that receives a term or a process L from channel x. Now consider the expression xP.Q \ x(X) X. Once the interaction between the two processes has occurred, the resulting process is then Q \ P. This may be interpreted as a process x (X) X waiting for X to be sent along channel x, thus defining its subsequent behavior. In this case, the process P is sent along channel x in the expression xP\ the process x{X)X then simply behaves as P once the interaction has taken place. If x : s > (si, S2 ), then for x(f^j .P and xf.P to respect the sorting function Sf, then f — T\,T2 for some T\ : si and Ti : S2 - Furthermore, we require that in a matching [T = P], the terms T and R belong to the same sort. We also assign an object sort to agents: processes take the sort (), whereas if D = ( j^ P and T : s, then D and P take on the sort ( s). The requirement on D (r ^ is such thats now exists for instance R : s and D : (?) [95]. In M ((P)) N, process P is associated with (i.e. listening to) milieus M and N. This allows a process to be part of more than one communication group. Process P may receive messages broadcast by processes within M and N and may broadcast messages to any processes within M and N. Milieus are defined in section 4.1.6. Similar to the 12-term, we introduce the 12-process in order to allow us to formally rea son about cryptographic processes. Defined in section 4.1.4,12-processes provide support for a wide variety of cryptographic protocols, thus permitting secure analytical constructs in the calculus. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 67 4.1.3 Q-term An Q-term U further extends term as defined in section 4.1.1 by integrating primitives for cryptographic support. Definition 4.1.3. H-term 0 zero (M,N) pair sue (M) successor H(M) hashing m K shared-key encryption m u public-key encryption M i t private-key signature K+ public key part K~ private key part Constructs for pairing and numbers, ( M,N), 0, and sue (M ), are added for convenience in modeling numerous cryptographic protocols. The successor term sue (M) implies M + 1. For example, sue (0) = 1, sue (sue (0)) = 2. H (M ) represents the hashing of some message M (which can be a key, for example). Furthermore, we assume that H is a one-way function (i.e. it cannot be inverted) and that it is free of collisions. We write {M}K to represent the encryption of a message M with a key K using a shared-key cryptographic system (e.g. DES [29]). Public key encryption (e.g. RSA [56]) is modeled as {[M]}k, which illustrates some message M encrypted under some key K. Often, we wish to encrypt using some public key and typically write {[M]}K+ to denote this behavior. Accordingly, if K represents a key pair, thenK + corresponds to its public part and K~ corresponds to its private part. We write [{Mjj/f to denote a message M that is digitally signed with key K. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 68 4.1.4 Q-process To support the formal modeling of conditional processes regarding authoritative crypto graphic protocols, the £2-process is introduced. The digital signature of terms, processes, and agents is capably modeled in API-S, in addition to common cryptographic schemes. Definition 4.1.4. Q-process Pa ::= let (x,y) = M in P pair splitting | case M o f 0 : P, sue (x): Q integer case | case L o f {x}^ in P shared-key decryption | case L o f {[jc]}^ in P public-key decryption | case L o f [{x}];v in P signature check In let (x,y) = M in P, the variablesx and y are bound in P. It behaves as P {NL/xy} if M is the pair N,L( ). In case M o f 0:P, sue (x): Q, the variablex is bound in Q. It behaves as P if M is 0 or as Q {N/x} if M is sue (N ). The variable x is bound in P in all three of the following processes: • case L o f {x}^ in P attempts to decrypt L with the key N. If L is a cyphertext of the form {M}N, then the process behaves asP{M/x}. • case L o f {[x]}/y in P attempts to decrypt L with the key N. If L is a cyphertext of the form {[M]}n, then the process behaves asP{M/x}. If A is a private key K~, then x is bound to M such that {[M]}^+ is L, if such anM exists. • case L o f [{x}]/y in P attempts to decrypt L with the key N. If L is a cyphertext of the form [{Mjj/v, then the process behaves as P{M/x). If A is a public key K+, then x is bound to M such that is L, if such anM exists. We should note, quite importantly, that several assumptions about cryptography are made as pointed out in [3]: • The only way to decrypt an encrypted message is to know the appropriate key. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 69 • An encrypted message does not reveal the key that was used to encrypt it. • The decryption algorithm used can always detect whether a message was encrypted with the expected key (i.e. there is adequate redundancy in the message). 4.1.5 Knowledge Unit A knowledge unit Kj e Ki,K2 ,...,K n consists of a knowledge base (which is comprised of rules) and a set of facts. A knowledge unit reacts to new facts added to its fact list. Kl denotes the set of knowledge units belonging to process P\. Definition 4.1.5. Knowledge Unit K ::= 0 empty unit | r rule | K1 +K2 summation of knowledge units The empty knowledge unit-one with no rules or facts-is denoted by 0. A knowledge unit may consist of a single rule. The summation K\ + Ki indicates that both knowledge units K\ and K2 react to a fact simultaneously, essentially behaving as a single knowledge unit. 4.1.6 Milieu A milieu is a bounded place (also called an environment) in which processes reside and computations take place. Although milieus are very much similar to ambients in the am bient calculus (see [21] and [39]), Rahimi takes great care to differentiate the two: milieus are not a basic unit of a system; rather, they represent an environment in which processes can join together to form a new computational unit [84]. Furthermore, the existence of separate locations is represented by a topology of boundaries. A milieu is surrounded by a border that must be traversed in order to join or leave it. We will show that communication can indeed occur through the milieu boundary via an unnamed environment channel of sorts (via the listener process defined in section 4.1.2). Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 70 An entire milieu can move, taking with it its entire contents (i.e. all the processes and other milieus within it). Milieus are well-suited to address the characteristics of the natural grouping and security of the system. Definition 4.1.6. Milieu M ::= 0 empty milieu | p.M action prefix | M[0] ownership I M[0\ | O2] parallel | M 1 +M 2 summation of milieus An empty milieu is denoted as 0. The variables 0 \ , O2 , ■ ■ •, On are used to range over processes and milieus. M[0\ is a milieu in which process or milieu 0 exists. A milieu may consist of other milieus or processes behaving in parallel; for example, M [0\ \ O2}. The expression M\ 4- M2 indicates that milieu M is generated by the merging of milieus Mi and M 2 . The prefix p is an action prefix. The expression p.M performs the action P and then behaves as M. M[0\ exhibits a tree structure induced by processes and the nesting of milieu brackets (e.g. M[Pi | ... | Pp | M i[...] | ... | Mq [...]]). In API-S (as in API Calculus), process mobility is represented as the crossing of milieu boundaries. Contrary to API Calculus, however, interaction between processes can indeed cross the milieu boundary. 4.1.7 Actions API-S inherits the traditional send and receive actions as defined in the 7t-Calculus. Fur thermore, knowledge unit and milieu actions are inherited from the API Calculus. As such, terms and processes may be present within actions. Knowledge unit actions include the receiving and sending of knowledge units and the adding and dropping of facts and rules. Milieu actions include the ability to join or leave a milieu, and the ability to open a milieu boundary. The process action prefix is denoted by a; the milieu action prefix is denoted by p. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 71 Definition 4.1.7. Actions Let A be the set of all a-actions in the calculus: • x is a silent, internal action. • x (jLj is an input prefix where x is the input port or channel of a process which con tains it and L is a tuple of processes or terms. The process x (l^ j .P inputs an arbitrary number of terms or processes L on the channel x and then behaves as P |L i / Z |. All free occurrences of the names L in P are bound by the input action prefix x in P. • xL is an output prefix where x is the output port or channel of a process which contains it and L is a tuple of processes or terms. The process xL.P outputs an arbitrary number of terms or processes L on channel x and then behaves as P. P makes the tuple of knowledge unit names K local to P. Ki {a} (jtj is a knowledge unit call. The expression Ki (a) .P calls the knowl edge unit Ki, passing a list of facts a. The result of this call is placed in R. All free occurrences of R in P are bound by the prefix Ki (a) (jtj in P. x .P is an input prefix where K is a knowledge unit that is received from a process via channel x. The expression x (K\) .P receives a knowledge unit K\ on channel jc and then behaves as P. • xK is an output prefix where K is a knowledge unit that is sent by a process via channel v. The expression xK\ .P sends a knowledge unit K\ on channel x and then behaves as P. • Ki {a) adds the tuple a to the fact list of Ki (if a is a tuple of facts) or to the rule base of Ki (if a is a tuple of rules). The expression Ki (a) .P adds a to the fact fist or rule base of Ki depending on the definition of a (whether it is a rule or a fact). Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 72 • Kja drops the tuple a from the fact list of Ki (if a is a tuple of facts) or from the rule base of Ki (if a is a tuple of rules). The expression Kia.P drops a from the fact list or rule base of Ki depending on the definition of a (whether it is a rule or a fact). • join m.P allows process P to join milieu m and then behave as P inside of m. • leave m.P allows process P to leave milieu m and then behave as P outside of m. • is a broadcast output prefix such that the tuple of processes or terms L is broad cast to the surrounding milieu. Any processes within the milieu in which L was broadcast may receive it (see the next item). There is no notion of a channel; one may think of the milieu as an environment channel, and processes defined to be listeners of-or associated with-a milieu can listen or send messages on this chan nel. If there is more than one process listening, one is chosen in a non-deterministic manner; naturally, the diffusion can be implemented in such a way that if there are several processes listening, then all of them receive the message. • ^L^j is a broadcast input prefix such that the tuple of processes or terms L is received upon the condition that P is within the milieu that initially broadcast L or that P is listening to the milieu. All free occurrences of the names L in P are bound by the input listening prefix in P. Let B be the set of all (3-actions in the calculus: • join m.M indicates the case that milieu M joins milieu m and then behaves as M inside of m. • leave m.M indicates that milieuM leaves milieu m and then behaves asM outside of m. • openM indicates that the boundary surrounding milieu M is dissolved; M ceases to exist. Any processes or other milieus that were inside of M behave as if they do not belong to M. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 7 3 Definition 4.1.8 . Binding Consider the expressions xT.P and x{T) .P. In each case, T (ranging over terms) is binding with the scope of P. An occurrence of a term within a process is bound if it is-or lies within the scope of-a binding occurrence of the term. An occurrence of a name within a process is free if it is not bound. We write ft (P) for the set of terms that have a free occurrence in P. For example, ft ((zy.O + wT.O) | xu.O) = {z,y,w,r,x, w} and ft (vx ((x (z) .zy.O + vvv.O) | vm x u .O )) = {y, w, v} The free terms of a process limit its capabilities. Consider a process P and a term R. In order for P to send or receive R, to send via R, or to receive via R, it must be that R e ft (P). Therefore, a name must occur free in two processes if such a name can be used for communication between the processes. Of course, one process must provide a sending capability; the other must provide a receiving capability. 4.1.8 Substitution and Convertibility A substitution is a function from names to names. We write {x/y} for the substitution that maps y to x. We can reword this in the following manner: we wish to substitute the name y present in some process P with the namex. In general, {xi ,X 2 ,.. . ,xn/y\,>’2 , • • • ,yw} (where theyi are pairwise distinct) maps each y,- to Xf. We use a to range over substitutions. For a process P, the process of applying a substitution a replaces each term x by c (x). In order to avoid the unintended capture of variables, we implement alpha-conversion whenever needed. For example, the result of (y (z) .zx.O) {z/x} is y (w) .vvz.O for some name w 7 ^ z, and the result of ( a (x). (yb)xb.cy.0) {xb/yc} is a (z). (vd)zd.bx.O for some name z 7 ^ x and d ^ b . For convertibility, alpha-conversion is defined as follows: • If the name w does not occur in the process P, then P{w/z} is the process obtained by replacing each free occurrence of z in P by w. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 74 • In process P, the replacement of x(T) .Q by (x(R) .Q) {R/T} is a change of bound terms where, in each case,R does not occur in Q. • Processes P and Q are convertible (i.e. P = Q) if Q can be obtained from P by a finite number of changes of bound names. For example: (y (w) .wv.O) {z/x} = y (w) .wz.0 (lvzvz .0 |y(w ).0 ){v/v,v/y} = !vz vz.O | v (w) .0 (yy (y (z) -^-0 IVW yw.w (v) .vv.O)) {y/z, uz/yv} = vu (u (y) .yx.O | vw uw.w (z) .vz.O) 4.2 Broadcasting We make use of the listener process as defined in Definition 4.1.2, combined with the broadcast prefixes (l ^ and (l^j as defined in Definition 4.1.7, so that we enable commu nication across the milieu boundary. We may, for example, associate a process with several milieus without the limitation that it be inside those milieus; this enables the process to broadcast messages to processes within its associated milieus. Indeed it may also listen to broadcasted messages originating from the same milieus; for example: Ml [P\Q\{(R))M2[S} Note that R is executing in parallel (i.e. concurrently with Mi, M2 , P, Q, and S): ((/?)) possesses an implied j R |. In this case, process R is listening to (associated with) milieus M\ and M 2 . Process P may broadcast a message x that process R can receive; and vice versa; for example: Mi[W./>|e]«M-R» m2[s] It is clear, in this case, that process R will receive message x as broadcasted by process P. The following, however, is ambiguous: M,[«.P|e]((W.«)>M2[fe>.S] Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 75 Which message is process R receiving? Indeed it may very well be x as broadcasted by process P; however, since broadcasts are chosen in a nondeterministic manner, R may receive z from S instead. In order to remove this ambiguity, we allow associated processes (those listening to milieus and outside of them) to specify the environment channel when broadcasting or receiving a message; this is very similar to the standard input and output prefix syntax. For clarity, we use the milieu name as the channel name. For example: Mi [<*> .P | Q] {{Mi (yi) .M2 (y2) .R))M2[{z) .S\ Now it is clear that process R will first receive x from P; it will subsequently receive z from S. We may, of course, omit the specification of the milieu if the model can capably tolerate it (i.e. we do not care if all of the processes within listening milieus can receive broadcasts). Technically, thisenvironment channel does not directly imply the true notion of a chan nel. It is simply a way to associate a process (or agent) to several milieus (or groups), thereby allowing it to be a part of several communication groups simultaneously. This behavior is more true to the real-world distributed systems we implement. Reconfigurable systems (and MAS) can be better modeled if we capably support such dynamics. 4.2.1 Triggers A trigger provides a way to communicate with a process without requiring a message parameter. We may think of this as a way to alert a process. For example, the expression xy sends y over channel x. Triggers remove the requirement of the message y. Triggers are implemented over named channels, but do not require a tuple of processes or terms to send or bind to the received input. We often see triggers being utilized in an executor process which is typically defined as follows: exec = x (y) .y The process exec accepts a process y via channel x and subsequently activates y, thus triggering the process. If, for example, a process P wishes to alert process Q to begin Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 76 some internal computation F (), we may model this as: x.P | x.F () .Q where processes P and Q share a communication link x. Essentially, P flicks a switch of sorts and triggers Q to begin F (). We often see triggers activating channels on which other processes are listening. 4.3 Abbreviations Quite often, we wish to reduce the size of the expressions we write in API-S. Typically, we apply syntactic sugar which is simply a way of allowing us to abbreviate certain ex pressions: • Sometimes, no message is communicated over a channel. To model this, we intro duce a special name £ which is never bound; we may then write: x.P in place of x£.P and x.P in place of x (y) .P, y ft (P) • We will often omit the no action process 0 as it is redundant. For example, we generally write: xy in place of xy.O • Often, we wish to allow input names to dynamically determine the course of com putation and write: * (v). ([v = yi]Pi + [v = y2\P2 +...) where the y; are distinct. Assuming that v ^ ft (Pi), we reduce this to: x: [yi =>Pi,y2 =>Pi,.-.] Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 11 • We often abbreviate the successor term sue (x) to its integer value: sue (0) =>■ 1 sue (sue (0)) =>• 2 • We define some composite prefixes: xy\yi---yn => xyi.xy2 ---xyn jc(yi)Cv2 )--.(yn) => -«Cvi)-*Cyz) join M\M i...Mn join M\ .join M i... join Mn leave M\M 2 ... Mn =f” leave M\ .leave M i ... leave Mn • If a process must leave a milieu simply to communicate with another process (and then reenters the milieu): Lxa.j.P => leave M\.xa.join M\ .P Of course, the same applies to the reverse condition that a process must join a milieu in order to communicate with another process (and subsequently leaves the milieu): j.x (a).l.P => join M\ .x (a) .leave M\ .P If a process needs to leave an arbitrary n milieus in order to communicate with another process, then: ln.xa.jn.P => leave M\ .leave Mi... leave Mn.xa.join Mn.join Mn- \ ... join Mi .P • We utilize pair splitting when receiving a pair of terms or processes and when de crypting: x(yi,yi)'P =* x(y).let (yi,y2)= y in P case L o f {yi,3^2}^ in p =► case L of {y }N in let (yi,yi) = y in P We generalize pair sphtting in the following manner: Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 78 ( j l ^ r - J n ) =► ((^l,y2, • • • ,y«-l) ,Jn) let (yuy2,... ,yn) = N in P => let (y,yn) = N in let (yi,y2,...,yn-i) = y in P • If a listener process is associated with a single milieu, we write: M[]((P in place of M[} ((F)) Ml[}((P\M2[] in place of Mx[] ((F)) | M2[] 4.4 Structural Congruence Quite often, we wish to transform a process to a new process; one may think of this as a way to dynamically decide what a process should be within some expression. Definition 4.4.1. Context A context introduces the capability to transform a process into another process. It is obtained when the hole [.] replaces an occurrence of 0 in an expression given by the grammar for a process as defined in Definition 4.1.2; it can subsequently be filled by a process. Given a context C and a process F, we write C[P] for the process obtained by replacing the hole in C by F. Note that the replacement is literal so that the terms free in F may be bound in C[P\. For example, take the expression vz([.] \lz(u) .yu.O) and the context Co[!z&.0]. In this case, replacing the hole with the context yields the expression vz(\zb. 0 |!z(w) .yu.O). Definition 4.4.2. n-hole Context For n > 1, an n-hole context is obtained when n occurrences of 0 in an expression are replaced by the holes [.] i, [.]2 , ..., [.]«. IfC is an n-hole context, then we write C[Fi ,P2 ,...,P n\ for the process obtained by replacing [.],• in C by F, for each i. Definition 4.4.3. Context Congruence An equivalence relation S on processes is a congruence if (F, Q) e S => (C[P\,C[Q\) ES for every context C. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 79 The syntax of the API-S often alludes to things similar in nature. Take, for example, the following set of expressions: x(m\) .xm\ and x (m2 ) .xm2 Both intuitively convey the same thing, in that one process inputs some term or process along a channel and another outputs some term or process along a channel. This is a simple synchronization of processes. The ambiguity of the messages mi and m 2 does not matter; both expressions exhibit the same behavior. Take another example: P | Q and Q \ P Again, both exhibit the same behavior: the parallel composition of processes P and Q. In order to identify the processes and expressions which intuitively exhibit the same behavior and thus represent the same thing, we introduce a structural congruence. Definition 4.4.4. Structural Congruence The structural congruence = is defined as the congruence on processes that satisfies the laws outlined in Table 4.2. Note that if processes P and Q are variants of the alpha- conversion, then P = Q. Furthermore, if P = Q can be inferred from the structural axioms and equational reasoning rules, then P and Q are structurally congruent. Take the following example [96]: P = vx(x (z) .za.O | (xy.x | xb.0)) By applying the axioms of associativity and commutativity of composition coupled with the identity of t, we obtain that: P = P\ — vx(((xy.0 + 0) | (x(z).za.0 + 0)) \xb.0) It should be noted that in the transformation from P to Pi, two potential interactors have been brought together. We may write, equally, that: P = P2 = vx (((xb.0 + 0) | (x(z) -za.O + 0)) | xy.O) implying a change of potential interactors. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 80 Table 4.2: Axioms of Structural Congruence and Rules of Equational Reasoning in the API-S Calculus Structural Congruence [T = T]x.P = x.P Match P+(Q + R) = (P + Q)+R Summation associativity P + Q = Q + P Summation commutativity P + 0 = P Summation identity P\(Q\R) = (P\Q)\R Composition associativity P + P = P Same process P\Q = Q\P Composition commutativity P\0 = P Composition identity vTi\T2P = vT2vTiP Restriction vTO = 0 Restriction identity vT (Pi | P2) =P\ \ vTP2, if T £ ft (P^ Restriction composition IP = P\ \P Replication Equational Reasoning P = P Reflexivity P = Q=>Q = P Symmetry P = Q/\Q = R^ P = R Transitivity P = Q^C[P]=C[Q\ Generality 4.5 Reduction Definition 4.5.1. Reduction The reduction relation —► is defined on processes and milieus according to the rules outlined in Table 4.3. It merely provides a mechanism whereby some process P can evolve to P' as a result of some interaction (an action within P). Reduction is inferred directly from the syntax and is defined by a family of inference rules [77]. We begin by stating the Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 81 communication axiom: (■■■+xLl.P1) | (■■■+x(L2).P2 )^ P i\P 2 {Li/L2} (4.1) Table 4.3: Reduction Rules in the API-S Calculus TAU: x.P + Q ^ P REACT: ( * ( ? ) •P + P') | (xR.QLQ!^ -^p{p/f} | Q p ^ p i P ^ P ' PAR: — —----- —— RES: P \Q ^ P '\Q ' (vx) P —> (vx) P/ P-+P' P ^ P ' RES-K: —— -----——- MIL (K) P -> (K) P' ‘ M[P\ -+ M[P'] STRUCT: g The process prior to the reduction consists of two main parallel processes: a sending process and a receiving process. The term or process Li is sent along channel x and Li is received via channel x. The axiom expresses that P has a reduction arising from an interaction between its components via channel or port x. As a result of this reduction, L\ is passed from the first process to the second and is substituted for the placeholder Li in P2 ; the two prefixes are consumed. A second axiom is used in defining reduction: T.P -*■ P (4.2) where the x prefix expresses an internal action whose origin is not necessarily explicit. For closed processes, the following reductions hold: Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 82 let (x,y) = (M,N) inP -*■ P{MN/xy} case 0 o f 0: P, sue (x) : Q —> P case sue (M) o f 0:P, sue (x) : Q —> P {M/x} case {M}N o f {x}N in P —> P{M/x] case {[M]}N+ o f {[jc]}^- in P —> P{M/x} case o f [{-*;}]ah- in P —>• P{M/x} We now introduce the structural rule: p = p' p ^ O 0 = 0 ' STRUCT: ~ (4-3) which is read as follows: from P = P' and P —► Q and Q = (?, infer P' —>■ Qf Note that the structural rule can be rewritten as follows to mean the same thing: P = Q,P-+P\P' = Q' STRUCT: Q ^Q ' The inference rules for reduction are defined as follows: P-*Pf PAR: n— (4.4) P \Q ^P '\Q P -> P ' RES: —r— —r— 7 (4.5) (v jc ) P —> ( v j c ) P ' In the parallel inference rule (PAR), we assert that if the component P of the process P \ Q has a reduction, then P \ Q has a reduction, the effect of which is just the effect on P. The component Q is unaffected by the action within P. The restriction inference rule (RES) simply expresses that a restriction in some term does not inhibit reduction in a process. The API Calculus introduces a new inference rule which directly addresses knowledge unit restriction. API-S naturally inherits it as well: Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 8 3 (K)Pp Z[ k )P' (46) The two axioms defined in Equations 4.1 and 4.2, the structural rule defined in Equa tion 4.3, and the inference rules defined in Equations 4.4,4.5, and 4.6 collectively define reduction. For an example, consider the following expression: xy.O | vy (x (z) .0 {y/z}) We may reduce this expression using the reduction rules and structural congruence as follows: xy.O | vy(x{z).Q{y/z\) = xy.O | vy' (x (z) Q {y1 /z}) Alpha-conversion = vy' (xy.O | x (z) .0 {y'/z}) Restriction composition -> vy' (0 | 0{y'/y}) REACT = vy' (0 {y'/y}) Composition identity In another example, the expression: v x ( ( x ( m ) .Qi + y (v) .02) I xa.0 ) | (yb.Ri +XC.R 2 ) may also be reduced using the reduction rules. First, we isolate a part of the expression: (x(w) .0i +y(v) .0 2 ) | xa.0 and note that it matches the left side of the REACT rule. We now have that: (x (m) .0i + y (v) .0 2 ) | xfl.O —> 0 i | 0 REACT (x (u) .0i + y (v) .0 2 ) | xa.O —> 0 i STRUCT vx((x(u).Qi + y (v ).0 2 ) |xfl.O) —>vx(0i) RES and can now reduce the complete expression as follows (via the PAR rule): vx((x(«) .0i +y (v) .0 2 ) | xa.O) | (yb.Ri +XC.R 2) —>■ v x(0i) | (yb.R\ +XC.R 2 ) Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 4. THE API-S CALCULUS 84 4.6 Discussion In extending the API Calculus, API-S has introduced several new concepts: • Terms have been extended by introducing a collection of Q-terms which include constructs necessary to accurately model several security techniques and protocols related to the mobile agent paradigm. Support for cryptographic algorithms (e.g. shared-key and public-key) is provided to aid in modeling secure communication. The ability to model other cryptographic necessities (e.g. hashing) has also been included. • Processes have been broadened to support the additional terms introduced. In fi- processes, decryption constructs are present including the capability to formally model digital signatures. The listener (milieu association) process introduces an en tirely new capability to the calculus. It provides a way to cross the milieu boundary via an abstract milieu environment channel, thus allowing communication between processes that do not share the same milieu. Furthermore, processes themselves may be transferred via this environment channel, providing an additional method of en tering a milieu and implementing process migration. This is illustrated in chapter 5. • New process prefix actions (a) have been introduced to support the additional con structs providing security modeling capabilities. Several new broadcast actions now allow communication and migration through the milieu boundary. • Triggers have been uniquely implemented so as to further enhance agent migration, including the new alternate method of joining and leaving milieus via milieu listen ers. This is illustrated in chapter 5. API-S provides methods that permit the calculus to capably model numerous security as pects relating to the mobile agent paradigm. We fully realize that it is extremely compli cated to model every possible security technique that has been proposed (see chapter 2 ) to Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. secure both the agent and the agency (whether in full or in part); however, we believe that API-S provides a solid foundation on which to build upon. 85 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 5 ILLUSTRATIONS OF THE CAPABILITIES OF API-S In this chapter, our aim is to illustrate the flexibility of API-S. In doing so, we will pri marily offer examples that address the security aspects of the calculus. In order to more fully illustrate the power of the calculus (e.g. the natural grouping ability that milieus of fer), however, we will furthermore illustrate several other simpler examples which offer a view at some of the core components of the calculus. For more examples relating to the non-security aspects of the calculus, the reader is referred to [84]. 5.1 Simple Examples Example 5.1.1. Passing Links: The Client-Server-Printer Example Server S shares a link x with printer P; client C also shares a link y with the server.C wishes to send a document d to P for printing. In this example, we illustrate the passing of the communication link x from S to C so that the client can use this link to send its document. The act of printing the document is modeled by the function F (), an internal function in P. We define the system illustrated in Figure 5.1 as: S = yx.S' P = x(d').F(d').P' C = y (xf) .x'd.C' The behavior is then: yx.S' | x (d') .F (d') .P' \ y (V) .x'd.C' -> S' \x (d1) .F {d!) .P' | (x'd.C') {x/x'} -> S'\{F(d').P'){d/d'}\C' S'\P'\C' Note that the communication links x and y are indeed global (i.e. not private to any par ticular process). If, for example, we restrict x to processes S and P initially, we obtain a much different result (as illustrated in Figure 5.2). Indeed the behavior is very similar: 86 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 87 ► Figure 5.1: Passing Links: The Client-Server-Printer Example v jc (yx.S' | jc ( -► v jc (S' | x (d') ,F (d') .P' | (x'd.C') {* //} ) -► vx (S' I (F (d')..P') {d/d'} I C') -»• v jc(S' | P' | C') > Figure 5.2: Passing Links with Restriction When communication link x is passed from S to C, its scope extrudes and is extended. It would be an entirely different scenario if, for example, client C possessed a public channel x initially. In this case, we rename the passed channel such that, again, its scope is extruded, and maintain the name of the client’s public channel x. Example 5.1.2. An Intermediary There are times when it is convenient to make use of an intermediary process whose sole responsibility it is to transfer terms or processes. Here we model a very simple case, wherein process P wishes to send a message m to process R and subsequently receive a response r. An intermediary process Q (sharing a link jc to P and a link y to R) is used to transfer m and r. We may define the system very simply: Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 88 P — xmjc(r,).Pf Q = x(m').ym'.y(r').xr'.Q' R = y (m!) .yr.R' The behavior is then: xm.x (r1) .P' | x (m') .ym'.y (/) .xr' .Q11 y (m!) .yr.R' —> x (/) .P' | (ym'.y (V) .xr1 .Q') {m/m'} | y (mr) ,yr.R' -* x (/) .P' | y (/) .x/.Q' | yr.R' x{rJ).P'\{xr,.Q'){r/r1}\R' -»• P'\Q'\R' 5.2 Examples with Knowledge Units Often, we wish to model the secret exchange (or just simple transmission) of a complete knowledge unit or perhaps even a simple fact or rule between agents. The following ex amples illustrate the use of knowledge units coupled with simple cryptographic protocols. Example 5.2.1. Passing a Knowledge Unit Using Shared-key Cryptography Consider two agents A\ and A2 ; they share a linkx. Agent A\ possesses a knowledge unit K\ \ agent A 2 possesses a knowledge unit K2 . Agent A 1 wishes to hand off its knowl edge unit K] to agent A 2 using a private key S they both share. This example (illustrated in Figure 5.3) can be simply modeled in the calculus as follows: A\ = x iK ^ sA } A2 = x (K) .case K o f {y}5in A'2 The behavior is then: x{K] }s .A\ | x(K) .case K o f {y}5inA'2 -► A\ | (case K o f {y}5 in A'2) {K\/K} - Aj \A'2{K\/y} The result is such that agent A2 now possesses knowledge units K\ and K2 . Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 89 x Figure 5.3 : Passing a Knowledge Unit One may wish agent A\ to simply pass a copy of its knowledge unit K\ to A2 , thus maintaining ownership of K\. In this case, we must alter the definitions of A\ and A 2 appropriately: AX = vKx(x{Kx}s.A'x) A2 = x(K) .case K of {y}5in A2 Utilizing the restriction, the behavior now becomes (as expected): vK\ (x {K\ }s .Aj) | x (K) .case K of {y}5in A'2 = vKi (x {K\ }s .A', | x(K) .case K of {y} 5 in A2) \Kx {A\ | (case K of {y}sin A'2) {K\/K}) -> vK\(A[ \A'2{K\/y}) Example 5.2.2. Transferring a Rule Using Public-key Cryptography In this case, agent A\ (with knowledge unit Kx) wishes to send a fact a to agent A 2 (with knowledge unit Kf) and then drop it from its fact list. A\ will encrypt a with A2 ’s public key S+ and send it to A 2 over channel x. A2 will decrypt a with its private key S~ and subsequently add a to its fact list: A} = xQa§s+-Kia.A[ A2 — x (b) .case b of {[c]}^- in K2 (c) A 2 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 90 The behavior is then: jc{[a]}S4 .K\a.A\ \ x(b) .case b o f {[c]}s - in Ki (c) A 2 —> K\a.A\ | (case b o f {[c]}5 - in Ki (c) A 2) {a/b} —> K\a.A'x | {K2 {c) A'2 ){a/c} -> A\ | A 2 Example 5.2.3. Scope Extrusion For this example, we refer back to Example 5.2.1. In this case, however, agents A\ and A 2 both have similarly named knowledge units K. A\ still wishes to send its knowledge unit K (encrypted with shared key S) to agent A 2. We define this small system as: Aj = x{^}s .A' A2 = vK(x(K').caseK'of{y}s inA'2) The behavior is then (as illustrated in Figure 5.4): x {K}s .A\ | vK (x (K') .case K' o f {>}s in A2) -V A' I vATi ((case K' o f {y}5 inA'2) {Ki/K} {K/K'}) AWvK^iKly}) We may consider scope extrusion as a way of resolving variable collisions. In this specific case, the knowledge unit K belonging to agent A 2 was renamed in order to allow the inclusion of the knowledge unit K received from A 1 via channel x. 5.3 Examples with Milieus Milieus present a unique way to model the natural grouping often seen in MAS. Intrin sically, they offer some rudimentary aspects of security (e.g. authorization), particularly when combined with the typing and naming rules of the calculus. Furthermore, they are very well-suited to model the agency which forms an integral part of the mobile agent paradigm. Example 5.3.1. Data Gathering Agent Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 91 x Figure 5.4 : Passing a Knowledge Unit (Scope Extrusion) We wish to illustrate that API-S can capably model a real-world example, albeit a fairly simple one. In this scenario (see Figure 5.5), there exists two agencies M\ and M 2 (modeled as milieus), one data gathering mobile agent A, and one database D (a process). A, initially at its home agency M\, will migrate to M 2 , query D with a request for data q, receive a data response r from D, and return home. A simple way to implement this scenario in the calculus is as follows: M, Figure 5.5: Data Gathering Agent (Agent Migration) Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 92 Mi = [A] M2 = [D] A = leave M\ .join M2.xq.x (/) .leave M2.join M\ A' D = x(q').xr.iy The behavior of the system: Mi [leave Mi .join M2 .xq.x (/) .leave M2 .join M\ .A'] \ M2 [x (qr).xr.D'] —> Mi [ ] | M2 pcq.x ( /) .leave M2 .join Mi A ' | x (q1) .xr.D'] —> M\[]\M2[x (/) .leave M2.join Mi .A' \ (xr.D1) {q/q'}] Mi [ ] | M2[(leave M2.join M\.A') {r/r1} \ D'] Ml[A'}\M2[D'} Example 5.3.2. Communicating Through the Milieu Boundary via Broadcast By combining cryptographic primitives with the listener (as defined in Definition 4.1.2), we show that it is possible to communicate through the milieu boundary quite securely. In this example, we wish to model the system as illustrated in Figure 5.6. In API-S, we define the system as follows: Figure 5.6: Communicating Through the Milieu Boundary via Broadcast Mo = [Mi ((R)) M2\ Mi = [P\Q] m2 = [s' | r] Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 93 In this scenario, agent P would like to send a fact a to agent S. A key k known to all agents is used to encrypt and decrypt a. To accomplish this, we will use agent R as an intermediary. We define the scenario as follows: P = H ah)*' R = (b).(b).R' S = (c) .case c of {d}k in K (d) .S' The behavior is then: M0[Mi [({a}*).P' | Q] {{(b). (b).R'))M2[(c) .case c of {d}k in K(d) .S' | T]] -> M0[Mi [P' | Q] ((({b) .R') {a/b}))M2[(c) .case c of {d}k in K(d) .S' | T]] -»■ M0 [Mi [P' | Q] ((/?')>M2 [(case c of {d}k in K (d) .S') {a/c} \ T}] - M0[Mi[P' | Q\ {(.R'))M2[(K(d) .S') {a/d} \ T}} - MQ[MX[P'\Q\((R'))M2[S'\T]] Naturally, a process may only be associated with milieus at its own level (i.e. only those that it can directly join) or one that directly surrounds it. We can simulate the association of unassociable milieus, however, by placing a series of processes as intermediaries in such a way that association is ultimately derived. For example, in Figure 5.7, process P is associated with milieus M\,M2, and M 3 . If association with milieu M 4 is desired, we simply introduce a process Q in M 3 and associate it with M 4 ; Q is now the intermediary between any process directly in M 4 and any process directly in M i. Similarly, if association with milieu Mo is desired, we introduce a process R outside of Mi and associate it with both Mo and M\; R is now the intermediary between any process directly in Mo and any process directly in M i. Alas, the syntax does not make it easy to directly model the association of a process to more than three milieus (two by association and one by join). Implementing the workaround described above allows an unlimited number of milieu associations by utilizing a series of strategically placed intermediaries. We should note that there may indeed be more than one process or agent associated with the same milieu(s); for example, the following is a valid expression in the calculus: Ml[P\Q]((R\S))M2[T] (5.1) Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 94 i Figure 5.7: Milieu Association Workaround In such a case, the exchange of the factsa and b between agents P and T in Equation 5.1 could be modeled in the following manner: Mi[(a).(b) .K(b) .P' | Q\ ((Mi (a).M2 (b).M 1 (b) .M2(a) .R'\ S))M2 [(b). (a) .K(a).T'\ Mi [(ft) .K (b) .P' | Q] ((M2 (b ) .Mi (b) .M2 (a) ./?' | S)) M2[(b ) . (a) .K (a) .T'] Mi [(b) .K (b) .P' | Q\ ((Mi (b) .M2 (a) ./?' | S)) M2 [(a) .K (a) .T'\ Mi [^T(fc) .P' | Q] ((M2 (a)./?' | S))M2[(a) X (a) T'] -> Ml [AT (ft) .P' I Q] ((& I S))M2 [K(a) .T'\ - Mi[P' I <2]((P' I S))M2 [T'\ One must take into consideration the order of broadcasts and receives so as to prevent deadlock. In this example, we use agent R to control the flow. 5.4 Other Examples Example 5.4.1. Passing Processes (Agents) We wish to model the following scenario: static agent P wishes to send an encrypted Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 95 version of agent Q over channel x to agent R. Q will be encrypted with a newly generated private (secret) key S which will be sent along with Q over x. In order to conceal this key, agent P will encrypt it with agent R’s public key K+. Upon communication, agent R will first decrypt the transmitted key with its private key K~ and subsequently use it to decrypt the agent Q. Q then runs, in this case modeled by its internal function F (). Agents P and Q ultimately cease to exist; agent R ultimately behaves as R'. The system is described as: p = vs(x({e}s,{[sD*+).o) Q = F () .0 R = x (Aenc, Senc) .case Senc o f ifl case Aenc o f {Adec} in (A^ec \ R ) Of course, K is in the scope of agents P and R. Note that the agent R is often called an executor, in that it accepts a process via a channel and executes it. A simple executor is modeled by x (y) .y, wherein the process y is received over channel x and then executed. Technically, we can think of A^ec as the trigger of agent Q whichR has been called upon to run. We shall initially abbreviate the expression case Aenc o f {^dec}sdec l'w {^dec IR') in agent R as Z for space; the system evolves as follows: vK(yS(x({2}^ , {[5]}^'+) -0) | x(Aenc,Senc) .case Senc o f in Z) -> vK (vS (0) || (case Senc o f {[ = R1 Interestingly, this example may be used to model a simple mobile agent implemen tation over web service enabled agencies (see [6]). Such agencies are wrapped by web services and expose a move method which accepts the migrating agent as a parameter. In the example above, the agent is encrypted and an encrypted key is further passed in the parameter list. A simple way to model the resuming of mobile agent execution on such an Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 96 agency could be implemented by adding the term run P to the calculus which runs agent P ’s internal function (typically named run). Thus, such a process may indeed look like: R = x(Aenc,Senc) .case Senc o f{[•S'dec]}in caseAenc o f {Adec} ^ (funAdec \ R ) Typically, we would model process R within a milieu since such a construct is well suited to model the agency. In this sense, R is the interface (the web service) to the agency. Process migration in this way does not necessitate the use of join or leave actions because channels may be used to transmit processes; thus, they can be used to transmit agents. Coupled with milieu association, we can technically allow the migration of some agent (from one milieu to another) via the milieu environment channels. Furthermore, we can certainly model secure migration if we encrypt the agent prior to moving and decrypt it once it has been received by a specified process in the target milieu. For example, if we define a system as follows: Mi = [P\Q] Mi = m P = (Q) - ? 1 Q = m 2.f ().q! R = Ml (GO .Ml (GO Ah-R' S = (Q')-S' We can now model a form of agent migration as follows: Ml [(G) .P' I M2.F () .Q'] ((Ml (GO .Mi (GO M i.R '))M 2[(Q') .S'] - Mi [P'] (((Mi (GO M 2.R') {Q/Q'}))Mi[(Q!) .S'] -+ Mi [P'] ((M2 -R'»Mi [5' | M i.F () .Q'] - Mi[P']«/JO)M2[S'|F().G/] -> M i[P1] ({R'))Mi[S'\Q'] This is very similar to the system described in Figure 5.6; however, in this case we are actually modeling mobile agent migration via the milieu environment channels. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 97 5.5 Examples Exhibiting Characteristics of Security We will now take a look at several examples that illustrate the modeling of some of the security techniques mentioned in chapter 2. In some cases-particularly when dealing with the internals of a mobile agent (i.e. code, state, data)-it is much more illustrative to model an agent as shown in Figure 5.8. In this way, we can model such techniques that directly involve agent code, state, and data. These agent characteristics are then modeled as pro cesses within a milieu; the milieu identifies the agent’s boundary. We may think of this as the agent’s body which encapsulates its internal organs. code Figure 5.8: An Encapsulated Agent code state data code/ data, Figure 5.9: Encapsulated Agent Migration Given some milieu M-which represents an arbitrary agency-and an agent A, we would Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 98 then model A’s mobility as a milieu join; for example, join M A as illustrated in Figure 5.9. The process Mtest in milieu M is one that is used to model a generic verifier. Many of the security techniques require some sort of verification of an agent’s code, state, etc. Indeed, we can simply model the agent’s code, for example, as an encrypted variable that can be decrypted and verified by the agency. In this way, it suffices to express this as the expression xc.P | x (c') .Q in order to achieve a similar result. We choose the latter method in the following examples. Example 5.5.1. Agent Identification and Authentication As it is quite important to identify, verify, and authenticate an agent upon its migration to an agency, we must be able to accurately model this in API-S. An agent may be iden tified via a biometric identifier or simply a named identifier (e.g. an agent name) and a password. As discussed earlier, Example 5.4.1 illustrates a simple form of this. We would, of course, additionally integrate a form of cryptography which would assure identifica tion and authentication of the agent. We modify this example and redefine the system as follows: Mi = [P | Q] M2 = [S] P = <{[<2]}^+) G = m 2 .f().q' R = Ml (Q,).M2(Q,)M .R > S = (GO .case Q' of §Q !'^k - in {S' | GO We can now model agent Q’s migration coupled with identification and authentication by the agency (modeled as milieu M2) via public key encryption: Ml [<{le]k+) P' I M2.F () .<21 « M j (<20 .m2 (GO M 2.R'))M2[S\ - M l [Pi « (M 2 (GO M 2.R') {G/G/}»M 2[(G0 .case G' of iQ"]}K- in (S' \ Q')} - M l [Pi ((M~2.R’))M2[S' {G/G'} {G/G"} I M2.F () .G1 -> M i[P'] ((R'))M2[S' | F () .G l -► M i [Pi ((R'))M2[S' | G l Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 99 Example 5.5.2. Proof Carrying Code (see section 2.5.1) Proof carrying code mandates that an agent must formally prove that it conforms to a security policy; thus, the conclusion is that the agent’s code is safe to execute. The agent’s code is digitally signed by its author and subsequently verified upon migration to a host. For this example, we define the system as follows: M = [A | (c) .case c o f [{cdec^K+ in 0] A — (l{acode]\K- ) -A' We now model verification of the agent’s code as follows: M[{[{aC0de]\K-) -A' I (c) -case c o f {{cdec'lK+ in 0] -»• M[A’\ (case c o f [{cdec]\K+ in 0) {acode/c}\ -► M[A'] Note that a successful decryption (i.e. signature verification) of the agent’s code implies agent authentication. The agency is then free to continue (in this case the agency does nothing as implied by the process 0). Example 5.5.3. State Appraisal and Path Histories (see section 2.5.1) In the case of state appraisal, the agent possesses an appraisal function that is signed by its author. Upon migration, the host verifies the appraisal function. Similarly, path histories utilizes an agent itinerary which represents a record of where it has been prior to the current migration. This itinerary is signed by the agent and verified by the host. Both cases are analogous and can be modeled as in proof carrying code; the difference being the characteristic bound to the variable communicated over a channel. In state appraisal, the appraisal function is transmitted; in path histories, the agent itinerary is communicated. We define the system as in Example 5.5.2 with the exception that the item being communicated over the milieu environment channel is dependent upon the technique being modeled; this is simply a generalization of the previous example: M = [A | (a!) .case d o f [{adec]\K+ in x] a = a w k - M ' Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 100 We now model verification as follows: M [(WlK-) A ' I («0 -case a' ° f [{adec}]K+ in A —> M[A' | (case a! o f [{a^ec}]^+ in x) {a/a'}} -> M[A'|x{a/arfec}] -* M[A'] where x represents some internal action required for further processing of the appraisal function or agent itinerary. Example 5.5.4. Partial Result Authentication Codes In section 2.6.1. we discussed a technique that mobile agents can implement in order to maintain data integrity and minimize loss of data if the agent is compromised. Partial result authentication codes is a technique whereby the state and data of the agent are encrypted with a key (of many) which is subsequently thrown away. Upon migrating to another host, the previously gathered data is protected by encryption. If the agent is compromised somewhere on its path, this can be detected upon its return to the home agency. All data prior to the compromise remains valid; therefore, we minimize the loss of data. home data check/ Figure 5.10: Partial Result Authentication Codes Example In this simple example as illustrated in Figure 5.10, we model a mobile agent Agather with states, initially at its home agency Hhome• It will travel to a single host Hdata> submit a query q to relational database Rdb for data d, encrypt this data using a throw-away key k, and return home. A static agent A c/^ will check Agathef^ data for integrity. We formally define the system as follows: Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 101 S — {so, si, • •., sn } set of agent states L = {ko,k\,..., &n} set of keys and initially: Hfiome = \A gat her \ Acheck\ Hdata = [Rdb] The formal model begins with A gather migrating from H hom e to H data- Hhome [leave Hhofne-join Hdatagat her I ^check] Once at the host, the agent gathers the data, encrypting it with the keyk: Hdata[xq-x({d'}k) .x I * (q') .xd.R!db] where x represents the agent throwing away key k, an internal action. The agent then migrates back home: H d a ta [leave Hdata-jo™ Hhome I ^dbl Once back at its home agency, the agent sends its data to A check- H h ome [xd .0 \x(d /) -xA'check] where x represents the checking of the data for compromise, an internal action. Example 5.5.5. Execution Tracing, Mutual Itinerary Recording, and Partial Result Encap sulation (see section 2 .6 .1 ) We can model this selection of techniques very similar to partial result authentication codes. In each case, we must perform some sort of verification of information at the home platform. Execution tracing records an agent’s execution at each host which is then verified upon return to the home agency. In mutual itinerary recording (with replication and voting), the agent’s path is maintained as it migrates from host to host; this is then verified at the home platform. Multiple agents are sent to perform the same task; if a majority of the agents Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 1 0 2 have successfully completed the task, the agents can perform the next task. In partial result encapsulation, the agent’s execution results are saved for verification upon return to the home platform. In each of these security techniques, a verification of specific characteristics c stored by the agent A can be modeled as follows (upon returning to the home platform H): H[{c)A'\(c').l] where x represents the silent internal action of verification. Example 5.5.6. Environmental Key Generation (see section 2.6.1) This technique requires an environment-specific key to be created that is used to en crypt the agent’s code and/or data. Successful decryption occurs only at a host where a set of predefined environmental conditions are met. In modeling such a technique, initial key generation is necessary. In this example, we model this first, then show very simply how a single agent migrates to a host. We define the initial key generation as follows and abbreviate leave as I and join as j: H = [A] M = [P] A = I H .j M.x (e1) .xi M .j H .xA' P = xe.P' Agent A migrates to host M and receives environment-specific information e from some process P (which represents an interface to the host). The first internal x action implies key generation utilizing the received environment information. The second x represents the internal action of encrypting the agent’s code or data with the generated key. Subsequent agent migration and transmission of code for verification could be modeled as follows: vk (/ H .j M.x {code}k A' \M[x (c) .case c o f {cdec}k x]) Example 5.5.7. Computing with Encrypted Functions Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 1 0 3 Typically, much of the burden of modeling a system lies on the modeler; correctly defining the system directly affects how it will be modeled in the calculus. Undoubtedly, there are many ways that a particular technique can be modeled. In some cases, it is ob vious which definition of a system will allow it to be more easily and accurately modeled; in other cases, it is not so obvious. Computing with encrypted functions can be modeled in a similar way to state ap praisals, path histories, and proof carrying code. In every case, the agent must provide the host with some sort of information (encrypted code, itinerary, etc) that must be verified before allowing the agent to proceed. In the case of encrypted functions, we are simply providing a program p that implements an encrypted version ce of the agent code c. We can model this as follows: M [x(p,ce).A '\x(p ',c'e).x] This particular technique may benefit from modeling the agent more abstractly as in Fig ure 5.8. Example 5.5.8. Returning Home and Cooperating Agents Several other techniques exist which are fairly simple to model. For example, agents returning home after each hop are less likely to be compromised [50]. For an agent A at home agency H, this can be modeled as follows (note that we abbreviate leave M and join M as / m and j m respectively): H [I H .j Mi .x.l Mi .j H.x.l H .j M2 .X.l M2.j H.X.A'] \Mi[]\M2[) Where x represents some internal actions the agent performs at each agency and upon returning home after each hop. The use of cooperating agents [14] with a master agent [28] can be modeled very simply. We define the system as follows: Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 5. ILLUSTRATIONS OF THE CAPABILITIES OF API-S 1 0 4 A I /U I A 2 H = simaster \ ^gather I gather M i = [] M2 = [] A m aster = (4 )/c(4 ).t Agather1 = l H.j M \.(q\). (d\).x.l M \.j H. (d\) Agather2 lH.jM2 .(q 2 ).{d 2 ).%.lMx.jH .(d2) The two independent data gathering agents submit queries upon migrating to separate data hosts. Upon returning home, this data is provided to the master agent which subsequently performs filtering, ranking, and other sensitive actions that the designer wishes to keep secret. The master agent remains at home, an inherently trusted platform. With respect to modeling security of the data, we can simply use the defined crypto graphic primitives to do this. For example, an agent A may transmit a request r for data over some channel x. A resource process R receives this query and sends data d to the agent. The data are encrypted: xr.x (d1) .case d' o f {ddec}K *n ^ Ix (r') 5.6 Discussion Clearly, API-S offers powerful constructs to model a variety of MAS. In particular, sys tems exhibiting unique security characteristics and involving numerous security techniques as earlier presented can be easily modeled in API-S. In general, we think that most of the proposed security techniques relevant to MAS can be capably modeled. Indeed, API-S does possess several shortcomings that must be discussed. The intro duced broadcasting capability via the milieu listener does not provide a direct point-to- point communication path to a specific process. Any process listening in on the milieu environment channel may receive a broadcasted message. This does not represent the nat ural communication mechanisms in real-world distributed systems. Furthermore, a pro cess may only listen to a limited number of milieus. The API-S syntax for milieu listener Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. limits this to three. Again, this is not indicative of real, implemented distributed systems. These are limitations to the calculus and addressing them is left for future work. 105 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 6 THE PRELIMINARY FORMAL MODEL FOR DDI In this chapter, we introduce the preliminary formal model for the DDI framework as introduced in section 1.6. The formal components are first defined; subsequently, the formal model is specified. As previously mentioned, the desire to more completely formally model the DDI framework (i.e. including the mobility, natural grouping, intelligence, and security as pects of the framework) motivated the design of API-S. Using the calculus, we can now more accurately define DDI and thus quantitatively analyze it using bisimulation as earlier defined. 6.1 Preliminary Definition of Formal Components It is not generally necessary to formally define the components of a model with respect to its analysis; however, it can prove useful particularly when combined with the formal model in order to more specifically describe the details of the system’s behavior. Definition 6.1.1. Environment The environment consists of agents and resources. E = {A, R} Definition 6.1.2. Agent A set of heterogeneous intelligent agents exists: A = {Ai,A2 ,...,A„} where A,- = {IuSi,KuCi} Each agent is defined by an identifier (/;), a state (Si), knowledge (Ki), and a set of capabilities (Q). The agent identifier 7; is a tuple: 106 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 6. THE PRELIMINARY FORMAL MODEL FOR DDI 107 Table 6.1: Heterogeneous Agent Identifier Intelligent Agent /? /“ Information Gatherer 0 0 Information Gathering Agent 0 1 Data Gathering Agent 1 0 which represents a binary mapping of the agent’s type as described in Table 6.1. An agent’s state is represented by: sf = {s?,sj,...,s7} whereby we can infer an agent’s position. Each agent A; may transition into one of n states. The intelligence of an agent (i.e. its knowledge) is represented by a triple: Ki = {KUhDi,Bi} It is comprised of a knowledge unit ( KUi), a set of data objects (D,), and a buffer (Bj) which represents a temporary place for data processing (e.g. the processing of a rule or fact for ultimate inclusion in the knowledge unit). The data object set an agent may possess is defined as: Di = {D^,D},...,Df} Each agent may possess m data objects. An agent possesses numerous capabilities which allow it to perform tasks (e.g. gather ing data): f /~*R f^M f*L /~*P /"<* 1 W j '-'i ? 5 5 ? W j r where Cf represents a sending capability, Cf a receiving capability, Cf a migration ca pability, Cf a learning capability, Cf a processing capability, and C* an agent-specific capability (i.e. a capability that is not shared among all types of agents). Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 6. THE PRELIMINARY FORMAL MODEL FOR DDI 1 0 8 • Sending Capability; Aj <— Cf(S{,Di). The function depends on the state Si of an agent Aj and sends one of its data objects D" to agent Aj. • Receiving Capability; A; <— Cf ( c ^ • The function depends on the sending capabil ity of an agent Ay. Agent A; receives a data object from agent Ay. • Migration Capability; Si <— Cf1 (Si,KUi). The function depends on the state Si and knowledge unit KUi of an agent A* and sets its next state. • Learning Capability; KUi <— Cf (Si,KUi,Di). The function depends on the state Si and the knowledge unit KUi of an agent Aj. Via the learning capability, the agent can, for example, update its knowledge base with some data object D\. • Processing Capability; Di Cf (Si,KUi,Di,Bi). The function depends on the state Si of an agent Aj. The function processes the contents of the buffer Bi and updates the set of data objects A utilizing its knowledge base KUi. • Agent-Specific Capabilities; these functions represent capabilities specific to each type of agent. For example, an Information Gathering Agent can spawn numerous Data Gathering Agents. We can define this function as Ay <— C* (Si,KUi,Di). The function depends on the state S; of an agent A j. Utilizing its knowledge unit KUi and set of data objects Di, the agent can spawn a new agent Ay. Definition 6.1.3. Resources The set of resources in the environment is defined as follows: R — {R\,Ri,... ,Rn} where a tuple further defines each resource: I?j = { * f , i ? f } representing a resource’s connectivity characteristics R f and metadata information R f. At this time, resources may be relational databases, geospatial shapefiles, and other textual sources of data such as RSS feeds, flat ASCII files, etc. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 6. THE PRELIMINARY FORMAL MODEL FOR DDI 109 6.2 Preliminary Formal Model We are particularly interested in modeling the characteristics of DDI that incorporate the use of mobile intelligent agents. As such, we restrict our formal model to the hierarchical tree-like structure inferred from the framework diagram (see Figure 6.1) with the Informa tion Gatherer at the root. We wish to model the following scenario: GUI Fuzzy Broker Module Information Information Storage Gatherer Facility IGAIGAIGA IGA MA MA MA MA MA MA MA Figure 6.1 : Multi-Agent Fuzzy Logic Framework • The Information Gatherer (IG) is tasked by the Broker • The Information Gatherer tasks the Information Gathering Agents (IGA) • The Information Gathering Agents spawn numerous Data Gathering Agents (DGA). For this task, several actions take place: - Knowledge units are distributed to each DGA - DGAs are tasked to gather data • Data is gathered. For this task, several actions take place: - The DGAs migrate Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 6. THE PRELIMINARY FORMAL MODEL FOR DDI 110 - The DGAs securely interface with resources - The DGAs extrapolate, filter, and rank data • The DGAs return home • Data is securely transferred and fused. For this task, several actions take place: - The DGAs securely hand-off data to the IGAs - Data are integrated - The IGAs transfer the integrated data to the IG - Data are fused • Fused data are stored in the Information Storage Facility (ISF) for later processing by the Fuzzy Module (FM) 6.2.1 Formal Model Definitions We begin with the resources. In the general case, they are all databases physically residing at separate locations. We therefore model them as disjoint processes, each within its own milieu. There can be up to n resources, Ri ,Ri, ...,R n, but for exemplary purposes we limit this to four resources. We define the resources: R = • • • ,Rn} The repositories at the onset: Md 1 m I Mdl [R2] I Md3 [J?3] I Md4 [R4\ The Broker, Information Gatherer, Information Gathering Agents (of which we cur rently only have one), and the Information Storage Facility are defined as follows: • Broker: Pf, • Information Gatherer: Pis Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 6. THE PRELIMINARY FORMAL MODEL FOR DDI 111 • Information Gathering agent: P iga • Information Storage Facility: P is f The agents at onset (as illustrated in Figure 6.2): Mig [Mb [Pb\ ((Pig)) Miga [Piga] I P isf] Note that the IG is modeled as a listener which fits very well within the context of the DDI framework. 6.2.2 Formal Model of the Scenario iga Figure 6.2: DDI Agent Initial Configuration Step 1: The IG is tasked by the Broker and, in turn, tasks the IGA: Mig [Mb \(T) A ] {{(T'). {T') .P,s))MiSa [(T") .P,sJ I Pis/] Step 2: The IGA spawns numerous DGAs: M ig a [}X -Piga |!x .P jgi] The partial view of the model within the proximity of the DGAs is now as illustrated in Figure 6.3. Again, we limit the number of DGAs to four. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 6. THE PRELIMINARY FORMAL MODEL FOR DDI 112 Step 3: Knowledge units are distributed to each DGA, and the DGAs are tasked to gather data: Miga \x\K\X2K2 • • .XnKn.Piga | Xi (K) .P | X2 (K) .Pdg2 | ... | Xn (K) ■Pdgn\ dg2 Figure 6.3: Local View after Spawning Four DGAs Step 4: The DGAs migrate, one to each remote data resource: Miga [Piga I leave Miga. join Mdi ■P dg 1 I • • • I leave Miga.join Mdn.Pdgn\ * M d\ [Pdg1 I ^ l ] I • • • I M (jn \Pdgn | R n \ | M ig a [Piga] The local view is now as illustrated in Figure 6.4. M M dgl dg4 Figure 6.4: Local View after DGAs Migrate Step 5: The DGAs securely interface with resources (providing a query and receiving a resultset) and extrapolate, filter, and rank the data received. Each query and subsequent data resultset is encrypted with a secret key s known only to the DGA and the resource it is communicating with: Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 6. THE PRELIMINARY FORMAL MODEL FOR DDI 1 1 3 Mdi [x{q}s-x(r')-case{r'}sPdgi \ x(4).case{4}sx{r}sIl\] | ...... | Mdn ^c{q}s.x{rJ).case{rJ}sPdgn \x(q,).case{q'}sx{r}s.Rn] -*■ Mrfl [x.Prfgl I J?i] I .. . I Mdn [%.Pdgn | J?„] * Mdl [Pdgl I ^l] I • • • I Mdn [Pdgn | Rn] Note that x represents the internal action of extrapolating, filtering, and ranking the data. Also note that several abbreviations are conveniently used for brevity: case{y}sP instead of case L o f {y}s in P case{[y]}k-P instead of case L o f {[y]}*- in P Step6 : The DGAs migrate back to their home host: Mdi [leaveMdi.joinMiga. ?dgl | R\] | ... | Mdn [leaveMdn.joinMiga.Pdgn \ Rn] * Miga [Riga | Pdgi | • • • | Pdgn\ \ Md\ [/?i] | ... | Mdn [/?n] Step 7: The DGAs securely transfer their data to the IGA using the IGA’s public key k+, which subsequently integrates it. Each DGA then ceases to exist (dies): M iga [^1 {[^1 ]}k+ | ••• | Xn {[<^n]}k+ .0 | X \ (d^ ) .. ,X n { d f) -Piga] -* Miga [casei[d\ ]}*- ... casej[d'n]}k- .x.Piga) Note that the x action in this case represents the IGA’s internal action of integrating the data. Step8 : The integrated data is securely transferred to the IG via a secret key s, which subsequently fuses it (in the case of multiple IGAs) and securely transfers it to the ISF: (O’) .case {D'}sz.p!s))M,ga [({D},> 4 J Note that the x action here represents the IG’s internal action of fusing the data. All that remains is to store the fused data in the ISF which can simply be modeled as follows: Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 6.2.3 Discussion In this chapter, using API-S quite naturally produced a formal model for the DDI frame work. By using the milieu listener and cryptographic primitives introduced in API-S, we have shown how simple it is to model a complex MAS such as the DDI framework. Modeling such a system in H07t-Calculus, for example, would not allow us to model the security requirements of the system or the natural grouping abilities and the intel ligence of mobile intelligent agents. The API Calculus would coerce us to remove the security requirements of the system, and the SPI Calculus would not adequately model the natural grouping or intelligence characteristics of mobile intelligent agents. API-S allows us to model such a MAS more completely. As it is geared toward mod eling MAS, it can model the natural grouping abilities and migratory characteristics of mobile agents and the intelligence of intelligent agents. Moreover, API-S is well suited to model and analyze numerous security techniques relevant to the mobile agent paradigm and cryptographic protocols. 114 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 7 CONCLUSIONS AND FUTURE WORK In this work, we have introduced the API-S Calculus, an extension of the 7 t-Calculus and direct extension of the API Calculus. Utilizing the powerful syntax of the 7 t-Calculus and the introduced concepts of milieu, knowledge unit, and term in the API Calculus, API-S includes the capability to model various security aspects of mobile intelligent agents (and agent hosts). We now have the means to fully analyze this aspect of the mobile agent paradigm (including MAS). API-S not only addresses the migration, intelligence, and nat ural grouping characteristics of agent-based systems, but furthermore covers the intrinsic security considerations of such systems. API-S provides the necessary mechanisms to permit the modeling and analysis of the security of agent-based systems. 7.1 Conclusive Remarks API-S introduces several new and unique constructs that provide mechanisms to formally model cryptographic protocols and various security techniques unique to the mobile intel ligent agent paradigm. The concepts of £l-term and Ql-process allow the detailed analysis of various cryptographic protocols. Moreover, realistic distributed computational systems are more accurately modeled due to the introduction of the milieu listener, a form of agent broadcast. By extending the concepts of milieu, knowledge unit, and term as defined in the API Calculus, API-S is imparted with the added flexibility to provide the mechanisms nec essary to model and analyze the security of interacting mobile agents, particularly with respect to MAS. Furthermore, we have shown that these extensions will support accurate modeling of the security of mobile intelligent agents while distinguishing between groups of cooperating agents, thus providing the tools necessary to model a common security model for a group of mobile agents working together to perform some computational task. The need to formally model DDI, a MAS discussed in chapter 6 , initially motivated the development of the API-S Calculus. This multi-agent fuzzy logic framework could not be 115 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 7. CONCLUSIONS AND FUTURE WORK 1 1 6 fully modeled utilizing the plethora of other modeling tools, some of which are discussed in chapter 3. The need to prove important attributes of the system such as robustness and scalability necessitated the use of a modeling tool. The need for the representation of individual components within the DDI framework (e.g. fusion of data) and the specific nature of the data and data source requirements of DDI further propelled the development of API-S. In addition, API-S was successfully used to develop a preliminary model of the DDI framework as shown in chapter 6 . The ongoing push toward MAS complicates security issues, particularly with respect to concurrent distributed systems. In designing API-S, three classes of security were con sidered: • Security of the agent. As shown in chapter 5, API-S can capably model such pro posed techniques as partial result authentication codes, computing with encrypted functions, execution tracing, mutual itinerary recording, partial result encapsulation, environmental key generation, and cooperating agents. The introduction of the f2- term, the ^-process, and the milieu listener all cooperatively play a part in providing this capability. • Security of the agency. API-S has demonstrated its capability to accurately model agent identification and authentication and other security techniques such as proof carrying code, state appraisal, and path histories. • Security of the communication channel. Utilizing the cryptographic primitives in troduced in the calculus, API-S can fully model and be used to analyze common cryptographic protocols often used to secure communication over channels in real- world distributed systems. 7.2 Future Directions There are three main areas delegated for future research: Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 7. CONCLUSIONS AND FUTURE WORK 117 • Extending API-S by integrating constructs that permit the modeling of new mobile agent and MAS security techniques as they are proposed. • The design and implementation of a tool to computationally verify expression syn tax, automatically reduce expressions, and evaluate a specified model; this would essentially be an analytical modeling framework for API-S coded models. • Introducing useful syntactical conventions in API-S that would enhance the breadth of systems it can accurately model. The current flexibility of API-S allows for a wide variety of security techniques to be modeled; however, as new research is done in the field, the need for specific methods to model such techniques may be necessary. The concepts of milieu and term as inherited from the API Calculus, and the concepts of Q-Term, Q-Process, and milieu listener as introduced in API-S, provide the calculus with the capability to support the modeling of additional (and possibly new) security techniques. The details of such mechanisms have not been discussed in this work. Furthermore, the design and implementation of a software tool or framework for the verification and reduction of API-S expressions would indeed be an important area for future research. Certainly, this framework would require the design of a compiler and a mechanism for the evaluation and reduction of a model coded in API-S. This evalu ation would assess security, validation, and verification concerns and would produce a quantitative analysis of the performance of a specified model using bisimulation theory as discussed in chapter 3. There are numerous areas for future research with respect to the introduction of useful syntactic principles and conventions that further refine the calculus, thus imparting it with the benefit of capably modeling a more diverse set of systems. For example, the capability to broadcast a message through the milieu boundary via the milieu listener is indeed a formidable characteristic of the calculus; however, there is no mechanism to direct the Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 7. CONCLUSIONS AND FUTURE WORK 118 message to a particular process. Such a feature could be implemented by specifying the target process in the expression as follows: In this case, the process R wishes to target a broadcast message to the process P that is located within milieu M\ . Certainly, the calculus would support the specification of the environment channel as defined in API-S: We may alternatively write this as follows: Mi [(y) -P] {{M\ (x ) .R Combining this with the cryptographic primitives introduced in API-S, we may write: Mi [(y) .case y o f {ydec]K in p ] {{Mi (M at) r More research must be done in this area to ensure that this enhancement can indeed work as supposed. The introduction of a conditional milieu join would directly address the authentication of an agent as it migrates to a host. Certainly, the concept of an executor as discussed in section 4.2.1 and as illustrated in Example 5.4.1 indirectly addresses this issue; however, a more direct approach motivates research in this area. As is currently defined in API-S, a milieu join (modeling agent migration) is expressed as follows: join Mi .P The joining of milieu Mi conditionally -based upon some condition that must be met (e.g. a valid password)-may be modeled as follows: join Mi ({p}K) .P Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 7. CONCLUSIONS AND FUTURE WORK 119 Here, a password p encrypted with a shared key K is necessary to successfully join the milieu M\. We may further expand upon this and bind some response to the milieu join (i.e. whether the join is successful or not) by the expression: join Mi ({p}^) (y) .P where a response is then bound to y in the process P. Again, further research and investi gation must be done in order to validify this enhancement. Often, we wish to model some alternate case with respect to decryption (i.e. upon unsuccessful decryption of some term or process). In API-S, this would be useful in the case construct when modeling the decryption or signature verification of a message. Take, for example, the following API-S expression: case m o f {y}^ in P If the term (or process) m is successfully decrypted (as y with the keyK), the process then behaves asP. There currently exists no construct to define an alternate case. We could extend the calculus to provide this functionality by appending to the case construct as follows: case m o f {y}^ in P others Q Where the process behaves asP if the term or process m is successfully decrypted or as Q if not. The introduction of a sealed milieu may impart the calculus with security refinements. The sealed milieu is defined as one that drops the open capability (i.e. its boundary may not be dissolved). The advantages of such a property are clear when considering the following examples: Example 12.1. The Malicious Outsider Consider the model snapshot illustrated in Figure 7.1. In this case, a malicious process (or agent) lies outside of the milieu, while a legitimate agent lies inside. The malicious Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 7. CONCLUSIONS AND FUTURE WORK 120 o d : Figure 7.1: The Sealed Milieu: Malicious Outsider Example process releases a worm in the environment. If the milieu boundary is dissolved, the legitimate agent then becomes exposed to the worm and is susceptible to any harm it may present. Given that the malicious agent cannot join the milieu without the necessary permissions, a sealed milieu would then prevent this nasty occurrence. Example 7.2.2. The Trojan Horse If several malicious agents exist within some milieu (perhaps denoting a group of ma licious agents) and that milieu joins a legitimate milieu as illustrated in Figure 7.2, then the dissolution of the milieu enclosing the malicious agents would result in a similar set of circumstances as depicted in the previous example. Again, this is a rather unpleasant result, and the introduction of a sealed milieu would preclude this. Figure 7.2: The Sealed Milieu: Trojan Horse Example 7.3 Discussion The work outlined in this thesis provides a contribution to the body of work which cur- rently exists in the domains of the mobile agent paradigm, mobile code security, and Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CHAPTER 7. CONCLUSIONS AND FUTURE WORK 121 agent-based analytical modeling tools. API-S is unique in that it provides the mecha nisms to fully model and analyze the security of interacting mobile agents, particularly with respect to MAS; for example, securing the communication channel provides a way to privately exchange knowledge unit facts or rules. Furthermore, API-S distinguishes be tween groups of cooperating agents (utilizing the concept of milieu), thus providing the tools necessary to model a common security model for a group of mobile agents working together to perform some computational task. The calculus is abstract and flexible in that it can support the modeling of numerous cryptographic protocols, including more canonical security constructs (e.g. authentication, verification, and identification). Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. BIBLIOGRAPHY [1] W. M. P. Aalst. Pi calculus versus petri nets: Let us eat humble pie rather than further inflate the pi hype, unpublished, 2003. [2] M. Abadi and C. Foumet. Just fast keying in the pi calculus. In Programming Languages and Systems: 13th European Symposium on Programming (ESOP’04), pages 340-354, London, UK, March 2004. Springer-Verlag. [3] M. Abadi and A. D. Gordon. A calculus for cryptographic protocols: The spi calculus. In Fourth ACM Conference on Computer and Communications Security, pages 36—47. ACM Press, 1997. [4] M. Abadi and A. D. Gordon. Reasoning about cryptographic protocols in the spi calculus. In CONCUR ’97: Proceedings of the 8th International Conference on Concurrency Theory, pages 59-73, London, UK, 1997. Springer-Verlag. [5] P. Agrawal and D. Famolari. Mobile computing in next generation wireless networks. In D1ALM ’99: Proceedings of the 3rd international workshop on Discrete algorithms and methods for mobile computing and communications, pages 32-39, New York, NY, USA, 1999. ACM Press. [6] H. Artail and E. Kahale. Maws: a platform-independent framework for mobile agents using web services. Journal of Parallel and Distributed Computing, 66(3):428-443, 2006. [7] T. Basten. In Terms of Nets: System Design with Petri Nets and Process Algebra. PhD thesis, Eindhoven University of Technology, Eindhoven, The Netherlands, December 1998. [8] S. Berkovits, J. D. Guttman, and V. Swarup. Authentication for mobile agents. In Mobile Agents and Security, pages 114-136, London, UK, 1998. Springer-Verlag. [9] E. Best, R. R. Devillers, and M. Koutny. Petri nets, process algebras and concurrent pro gramming languages. In Lectures on Petri Nets II: Applications, Advances in Petri Nets, the volumes are based on the Advanced Course on Petri Nets, pages 1-84, London, UK, 1998. Springer-Verlag. [10] K. Bhargavan, R. Corin, C. Foumet, and A. D. Gordon. Secure sessions for web services. In SWS ’04: Proceedings of the 2004 Workshop on Secure Web Services, pages 56-66, New York, NY, USA, 2004. ACM Press. [11] K. Bhargavan, C. Foumet, and A. Gordon. Verified reference implementations of ws- security protocols. In 3rd International Workshop on Web Services and Formal Methods (WS-FM2006), pages 88-106, 2006. [12] K. Bhargavan, C. Foumet, and A. D. Gordon. A semantics for web services authentication. In POPL ’04: Proceedings of the 31st ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 198-209, New York, NY, USA, 2004. ACM Press. 122 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. BIBLIOGRAPHY 1 2 3 [13] K. Bhargavan, C. Foumet, A. D. Gordon, and R. Pucella. Tulafale: A security tool for web services. In Proceedings of the International Symposium on Formal Methods for Compo nents and Objects (FMCO’03), pages 197-222, 2004. [14] N. Borselius. Mobile agent security. Electronics & Communication Engineering Journal, 14(5):211-218, October 2002. [15] N. Borselius, N. Hur, M. Kaprynski, and C. J. Mitchell. A security architecture for agent- based mobile systems. In Proceedings - 3G2002, Third International Conference on Mobile Communications Technologies, pages 312-318, London, UK, 2002. IEEE Computer Soci ety. [16] N. Borselius, C. J. Mitchell, and A. Wilson. On mobile agent based transactions in moder ately hostile environments. In Proceedings of the IFIP TC11 WG11.4 First Annual Working Conference on Network Security, pages 173-186, Deventer, The Netherlands, 2001. Kluwer, B.V. [17] M. Bugliesi, G. Castagna, and S. Crafa. Access control for mobile agents: The calculus of boxed ambients. ACM Transactions on Programming Language Systems, 26(1):57-124, 2004. [18] US Census Bureau. Us and world population clocks. Internet Web site, November 2006. http://www.census.gov. [19] A. Burkle, B. Essendorfer, A. Hertel, W. Muller, and M. Wieser. A test suite for the eval uation of mobile agent platform security. In I AT ’06: Proceedings of the IEEE/WIC/ACM International Conference on Intelligent Agent Technology (IAT 2006 Main Conference Pro ceedings) (IAT’06), pages 752-756, Washington, DC, USA, 2006. IEEE Computer Society. [20] L. Cardelli, G. Ghelli, and A. D. Gordon. Mobility types for mobile ambients. In ICAL ’99: Proceedings of the 26th International Colloquium on Automata, Languages and Program ming, pages 230-239, London, UK, 1999. Springer-Verlag. [21] L. Cardelli, G. Ghelli, and A. D. Gordon. Types for the ambient calculus. Information Compututation, 177(2): 160-194, 2002. [22] L. Cardelli and A. D. Gordon. Mobile ambients. In Foundations of Software Science and Computation Structures: First International Conference, FOSSACS ’98. Springer-Verlag, Berlin Germany, 1998. [23] S. Caselli, G. Conte, and P. Marenzoni. A distributed algorithm for gspn reachability graph generation. Journal of Parallel Distributed Computing, 61(l):79-95, 2001. [24] G. Castagna, J. Vitek, and F. Z. Nardelli. The seal calculus. Information and Computation, 201(1): 1-54, 2005. [25] G. Castagna, J. Vitek, and F. Zappa Nardelli. The seal calculus. Information and Computa tion, 201(1): 1-54, 2005. [26] D. Chess, C. Harrison, and A. Kershenbaum. Mobile agents: Are they a good idea? Tech nical Report RC 19887, IBM Research Division, Yorktown Heights, New York, 1994. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. BIBLIOGRAPHY 1 2 4 [27] D. M. Chess. Security issues in mobile code systems. In Mobile Agents and Security, pages 1-14, London, UK, 1998. Springer-Verlag. [28] J. Claessens, B. Preneel, and J. Vandewalle. (how) can mobile agents do secure electronic transactions on untrusted hosts? a survey of the security issues and the current solutions. ACM Transactions on Internet Technology, 3(1): 1533—5399, 2003. [29] D. Coppersmith. The data encryption standard (des) and its strength against attacks. IBM Journal of Research and Develpoment, 38(3):243-250, 1994. [30] S. Das, K. Shuster, C. Wu, and I. Levit. Mobile agents for distributed and heterogeneous information retrieval. Information Retrieval, 8(3):383—416, 2005. [31] K. S. Decker and K. Sycara. Intelligent adaptive information agents. Journal of Intelligent Information Systems, 9(3):239-260, 1997. [32] J. Desel and G. Juhas. What is a petri net? In Unifying Petri Nets, Advances in Petri Nets, pages 1-25, London, UK, 2001. Springer-Verlag. [33] T. Eliassi-Rad and J. Shavlik. A system for building intelligent agents that learn to re trieve and extract information. User Modeling and User-Adapted Interaction, 13(1-2): 35- 88, 2003. [34] C. Ene and T. Muntean. A broadcast-based calculus for communicating systems. In IPDPS ’01: Proceedings of the 15th International Parallel & Distributed Processing Symposium, pages 149-158, Washington, DC, USA, 2001. IEEE Computer Society. [35] E. A. Feigenbaum. Some challenges and grand challenges for computational intelligence. Journal of the ACM, 50(l):32-40, 2003. [36] C. Foumet and G. Gonthier. The join calculus: A language for distributed mobile pro gramming. In Applied Semantics, International Summer School, APPSEM 2000, Caminha, Portugal, September 9-15, 2000, Advanced Lectures, pages 268-332, London, UK, 2002. Springer-Verlag. [37] C. Foumet, G. Gonthier, J-J. Levy, L. Maranget, and D. Remy. A calculus of mobile agents. In CONCUR ’96: Proceedings of the 7th International Conference on Concurrency Theory, pages 406^421, London, UK, 1996. Springer-Verlag. [38] J. S. Fritzinger and M. Mueller. Java security. Sun Microsystems, Inc. [39] A. D. Gordon. Part iii: The ambient calculus. Presented at the International Summer School on Foundations of Security Analysis and Design (FOSAD 2000) in Bertinoro, September 2000 . [40] A. D. Gordon. A calculus for cryptographic protocols: Lecture notes, 2001. Microsoft Research. [41] A. D. Gordon and A. Jeffrey. Secrecy despite compromise: types, cryptography, and the pi-calculus. Lecture Notes in Computer Science, pages 186-201, 2005. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. BIBLIOGRAPHY 125 [42] A. D. Gordon and R. Pucella. Validating a web service security abstraction by typing. In XMLSEC ’02: Proceedings of the 2002 ACM workshop on XML security, pages 18-29, New York, NY, USA, 2002. ACM Press. [43] Y. Gu and Y. Fu. A simple process calculus for the analysis of security protocols. In PDCAT ’05: Proceedings of the Sixth International Conference on Parallel and Distributed Computing Applications and Technologies, pages 110-114, Washington, DC, USA, 2005. IEEE Computer Society. [44] C. Haddad. A wireless ipod can torpedo the pirates. BusinessWeek online, September 2003. http://www.businessweek.com. [45] M. Hepburn and D. Wright. Trust in the pi-calculus. In PPDP ’01: Proceedings of the 3rd ACM SIGPLAN International Conference on Principles and Practice of Declarative Programming, pages 103-114, New York, NY, USA, 2001. ACM Press. Florence, Italy. [46] L. O. Hertzberger. The importance of modeling for computational science. In J. Gerbrandy, M. Marx, M. de Rijke, and Y. Venema, editors, JFAK. Essays Dedicated to Johan van Ben- them on the Occasion of his 50th Birthday. Amsterdam University Press, 1999. [47] F. Hohl. Time limited blackbox security: Protecting mobile agents from malicious hosts. In Mobile Agents and Security, pages 92-113, London, UK, 1998. Springer-Verlag. [48] F. Ishikawa, N. Yoshioka, Y. Tahara, and S. Honiden. Toward synthesis of web services and mobile agents. In AAMAS’2004 Workshop on Web Services and Agent-based Engineering (WSABE2004), pages 48-55, July 2004. [49] W. Jansen. Countermeasures for mobile agent security. Computer Communications, Special Issue on Advances in Research and Application of Network Security, November 2000. [50] W. Jansen and T. Karygiannis. Nist special publication 800-19 - mobile agent security. Technical report, National Institute of Standards and Technology, 2000. [51] N. R. Jennings, K. Sycara, and M. Wooldridge. A roadmap of agent research and develop ment. Autonomous Agents and Multi-Agent Systems, 1(1):7—38,1998. [52] L. Kagal, F. Perich, H. Chen, S. Tolia, Y. Zou, T. Finin, A. Joshi, Y. Peng, R. S. Cost, and C. Nicholas. Agents making sense of the semantic web. In First GSFC/JPL Workshop on Radical Agent Concepts (WRAC), NASA Goddard Space Flight Center, MD, January 2002. [53] S. M. Koriem. Development, analysis and evaluation of performance models for mobile multi-agent networks. Computing Journal, 49(6):685-709, 2006. [54] P. Kotzanikolaou, M. Burmester, and V. Chrissikopoulos. Secure transactions with mobile agents in hostile environments. In ACISP ’00: Proceedings of the 5th Australasian Con ference on Information Security and Privacy, pages 289-297, London, UK, 2000. Springer- Verlag. [55] Y. Kun, G. Xin, and L. Dayou. Security in mobile agent system: problems and approaches. SIGOPS Operating Systems Review, 34(l):21-28, 2000. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. BIBLIOGRAPHY 1 2 6 [56] RSA Laboratories. Pkcs#l v2.1: Rsa cryptography, standard draft 2, January 2001. [57] D. B. Lange and M. Oshima. Seven good reasons for mobile agents. Communications of the ACM, 42(3): 88-89, 1999. [58] E. F. A. Lima, R D. L. Machado, F R. Sampaio, and J. C. A. Figueiredo. An approach to modelling and applying mobile agent design patterns. SIGSOFT Software Engineering Notes, 29(3): 1-8, 2004. [59] C. Lin, V. Varadharajan, Y. Wang, and Y. Pruthi. Trust enhanced security for mobile agents. In CEC ’05: Proceedings of the Seventh IEEE International Conference on E-Commerce Technology (CEC’05), pages 231-238, Washington, DC, USA, 2005. IEEE Computer Soci ety. [60] S. Loureiro, R. Molva, and A. Pannetrat. Secure data collection with updates. Electronic Commerce Research, 1(1-2):119—130, 2001. [61] M. Luck, P. McBumey, and C. Preist. A manifesto for agent technology: Towards next generation computing. Autonomous Agents and Multi-Agent Systems, 9(3):203-252, 2004. [62] R. Milner. The polyadic pi-calculus: A tutorial. In F. L. Bauer, W. Brauer, and H. Schwicht- enberg, editors, Logic and Algebra of Specification, pages 203-246. Springer-Verlag, 1993. [63] R. Milner, J. Parrow, and D. Walker. A calculus of mobile processes, part i. Information and Computation, 100(1): 1^10, 1992. [64] R. Milner, J. Parrow, and D. Walker. A calculus of mobile processes, part ii. Information and Computation, 100(l):41-77, 1992. [65] D. Milojicic, M. Breugst, I. Busse, J. Campbell, S. Covaci, B. Friedman, K. Kosaka, D. Lange, K. Ono, M. Oshima, C. Tham, S. Virdhagriswaran, and J. White. Masif, the omg mobile agent system interoperability facility. Personal and Ubiquitous Computing, 2(2): 117-129, June 1998. [66] Horizon Systems Laboratory Mitsubishi Electric ITA. Mobile agent computing. A White Paper. [67] A. Moen. Introduction to pi-calculus. Presented at a seminar in Computer Science at the University of Oslo, March 2003. [68] L. Moody and G. Schmidt. Going wireless: the emergence of wireless networks in educa tion. Journal of Computing Sciences in Colleges, 19(4): 151—158, 2004. [69] V. Moraru, T. Muntean, and E. Gutuleac. Towards a model for broadcasting secure mobile processes. In ISPDC ’06: Proceedings of the Proceedings of The Fifth International Sympo sium on Parallel and Distributed Computing, pages 168-172, Washington, DC, USA, 2006. IEEE Computer Society. [70] T. Murata. Petri nets: Properties, analysis and applications. In Proceedings of the IEEE, pages 541-580,1989. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. BIBLIOGRAPHY 1 2 7 [71] G. C. Necula and P. Lee. Safe, untrusted agents using proof-carrying code. In Mobile Agents and Security, pages 61-91, London, UK, 1998. Springer-Verlag. [72] J. Nielsen. One billion internet users. Internet Web site, December 2005. [73] P. D. O’Brien and R. C. Nicol. Fipa towards a standard for software agents. BT Technology Journal, 16(3):51—59,1998. [74] J. Page, A. Zaslavsky, and M. Indrawan. A buddy model of security for mobile agent com munities operating in pervasive scenarios. In ACSW Frontiers ’04: Proceedings of the sec ond workshop on Australasian information security, Data Mining and Web Intelligence, and Software Internationalisation, pages 17-25, Darlinghurst, Australia, Australia, 2004. Aus tralian Computer Society, Inc. [75] L. Palen, M. Salzman, and E. Youngs. Going wireless: behavior & practice of new mo bile phone users. In CSCW ’00: Proceedings of the 2000 ACM conference on Computer supported cooperative work, pages 201-210, New York, NY, USA, 2000. ACM Press. [76] S. Papastavrou, G. Samaras, and E. Pitoura. Mobile agents for www distributed database ac cess. In ICDE ’99: Proceedings of the 15th International Conference on Data Engineering, pages 228-237, Washington, DC, USA, 1999. IEEE Computer Society. [77] J. Parrow. An introduction to the pi-calculus. In J. Bergstra, A. Ponse, and S. Smolka, editors, Handbook of Process Algebra, pages 479-543. Elsevier, 2001. [78] R. Peng, K. He, and X. Zhong. Sma calculus: A secure mobile agent calculus. In CIT ’04: Proceedings of the The Fourth International Conference on Computer and Informa tion Technology (CIT’04), pages 516-521, Washington, DC, USA, 2004. IEEE Computer Society. [79] J. L. Peterson. Petri nets. ACM Computing Surveys, 9(3):223-252, 1977. [80] G. P. Picco. Mobile agents: An introduction. Journal of Microprocessors and Microsystems, 25(2):65-74, April 2001. [81] D. Poole, A. Mackworth, and R. Goebel. Computational intelligence: a logical approach. Oxford University Press, Oxford, UK, 1997. [82] A. Pridgen and C. Julien. A secure modular mobile agent system. In SELMAS ’06: Proceed ings of the 2006 international workshop on Software engineering for large-scale multi-agent systems, pages 67-74, New York, NY, USA, 2006. ACM Pess. [83] F. Puhlmann and M. Weske. Using the pi-calculus for formalizing workflow patterns. In Proceedings of the 3rd International Conference on Business Process Management (BPM 2005), pages 153-168, 2005. [84] S. Rahimi. API-Calculus for Intelligent-Agent Formal Modeling and its Application in Dis tributed Geospatial Data Conflation. PhD thesis, The University of Southern Mississippi, Hattiesburg, MS, USA, May 2002. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. BIBLIOGRAPHY 1 2 8 [85] S. Rahimi and N. F. Carver. A multi-agent architecture for distributed domain-specific in formation integration. In HICSS ’05: Proceedings of the 38th Annual Hawaii International Conference on System Sciences (HICSS’05) - Track 4, page 113.2, Washington, DC, USA, 2005. IEEE Computer Society. [86] S. Rahimi, M. Cobb, D. Ali, and F. Petry. A Modeling Tool for Intelligent-Agent Based Sys tems: Api-Calculus, volume Soft Computing Agents: A New Perspective for Dynamic Sys tems of The International Series Frontiers in Artificial Intelligence and Application, chap ter 7, pages 165-186. IOS Press, 2002. [87] O. F. Rana. Performance management of mobile agent systems. In AGENTS ’00: Proceed ings of the fourth international conference on Autonomous agents, pages 148-155, New York, NY, USA, 2000. ACM Press. [88] T. Rorie, J. Burge, and A. C. Esterline. Formal modeling of multi-agent systems: An appli cation of the pi-calculus. In M. Jamshidi, D. Kaufman, and N. Vadiee, editors, Proceedings of ACE-PJJRSUE STUDENT CONFERENCE, Advances in Research and Education in Sci ence, Mathematics and Engineering, April 1999. Albuquerque, NM. [89] T. Rorie and A. C. Esterline. Formal modeling of multi-agent systems using the pi -calculus and epistemic logic. In NASA-URC98, Huntsville, AL, 1998. [90] V. Roth. On the robustness of some cryptographic protocols for mobile agent protection. In MA ’01: Proceedings of the 5th International Conference on Mobile Agents, pages 1-14, London, UK, 2002. Springer-Verlag. [91] S. J. Russell and P. Norvig. Artificial intelligence: a modem approach. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1995. [92] G. Samaras, M. D. Dikaiakos, C. Spyrou, and A. Liverdos. Mobile agent platforms for web databases: A qualitative and quantitative assessment. In ASAMA ’99: Proceedings of the First International Symposium on Agent Systems and Applications Third International Sym posium on Mobile Agents, page 50, Washington, DC, USA, 1999. IEEE Computer Society. [93] T. Sander and C. F. Tschudin. Protecting mobile agents against malicious hosts. In Mobile Agents and Security, pages 44-60, London, UK, 1998. Springer-Verlag. [94] T. Sander and C. F. Tschudin. Towards mobile cryptography. In Proceedings of the IEEE Symposium on Security and Privacy, pages 215-224,1998. [95] D. Sangiorgi. From pi-calculus to higher-order pi-calculus - and back. In TAPSOFT ’93: Proceedings of the International Joint Conference CAAP/FASE on Theory and Practice of Software Development, pages 151-166, London, UK, 1993. Springer-Verlag. [96] D. Sangiorgi and D. Walker. Pl-Calculus: A Theory of Mobile Processes. Cambridge University Press, New York, NY, USA, 2001. [97] I. Scagnetto and M. Miculan. Ambient calculus and its logic in the calculus of inductive constructions. In F. Pfenning, editor, Proceedings of the Workshop on Logical Frameworks and Meta-languages. Elsevier, 2002. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. BIBLIOGRAPHY 129 [98] M. Schoeman and E. Cloete. Architectural components for the efficient design of mobile agent systems. In SAICSIT ’03: Proceedings of the 2003 annual research conference of the South African institute of computer scientists and information technologists on Enablement through technology, pages 48-58, Republic of South Africa, 2003. South African Institute for Computer Scientists and Information Technologists. [99] M. A. Schoeman. Architectural guidelines for mobile agent systems. Technical Report TR-UNISA-2003-02, School of Computing, University of South Africa, 2003. [100] G. D. M. Serugendo, M. Muhugusa, and C. F. Tschudin. A survey of theories for mobile agents. Worldwide Web, 1(3): 139-153,1998. [101] I. Sobrado. Evaluation of two security schemes for mobile agents. SIGCOMM Computer Communication Review, 31(2 supplement):2-19, 2001. [102] C. Spyrou, G. Samaras, E. Pitoura, and P. Evripidou. Mobile agents for wireless computing: the convergence of wireless computational models with mobile-agent technologies. Mob. Netw. Appl, 9(5):517-528, 2004. [103] P. Staski and A. Zaslavsky. Expressing dynamics of mobile agent systems using ambient calculus. In DEXA ’98: Proceedings of the 9th International Workshop on Database and Expert Systems Applications, pages 434-439, Washington, DC, USA, 1998. IEEE Computer Society. [104] Y. Tahara, A. Ohsuga, and S. Honiden. Mobile agent security with the ipeditor development tool and the mobile unity language. In AGENTS ’01: Proceedings of the fifth international conference on Autonomous agents, pages 656-662, New York, NY, USA, 2001. ACM Press. [105] C. Talcott and P. Lincoln. Towards a semantic framework for secure agents: Extended abstract. In High Confidence Software and Sytems (HCSS 2003), 2003. [106] H. K. Tan and L. Moreau. Certificates for mobile code security. In SAC ’02: Proceedings of the 2002 ACM symposium on Applied computing, pages 76-81, New York, NY, USA, 2002. ACM Press. [107] R. Tatikunta, S. Rahimi, P. Shrestha, and J. Bjursel. Tragent: A multi-agent system for stock exchange. In IEEE/WIC/ACM International Conference on Web Intelligence and Intelligent Agent Technology (W1-IAT2006 Workshops)(WI-IATW’06), pages 505-509, 2006. [108] A. R. Tripathi, T. Ahmed, and N. M. Kamik. Experiences and future challenges in mobile agent programming. Microprocessors and Microsystems, 25(2): 121-129, April 2001. [109] A. M. Turing. Computing machinery and intelligence. Mind, 49:433^460,1950. [110] R. Tynan, D. Marsh, D. O’Kane, and G. M. P. O’Hare. Intelligent agents for wireless sensor networks. In AAMAS ’05: Proceedings of the fourth international gt conference on Autonomous agents and multiagent systems, pages 1179-1180, New York, NY, USA, 2005. ACM Press. [111] V. Varadharajan. Security enhanced mobile agents. In CCS ’00: Proceedings of the 7th ACM conference on Computer and communications security, pages 200-209, New York, NY, USA, 2000. ACM Press. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. BIBLIOGRAPHY 1 3 0 [112] G. Vigna. Cryptographic traces for mobile agents. In Mobile Agents and Security, pages 137-153, London, UK, 1998. Springer-Verlag. [113] J. Vitek and G. Castagna. Seal: A framework for secure mobile computations. ICCL’98: Workshop on Internet Programming Languages, pages 47-77, 1999. [114] J.-L. Vivas and M. Dam. From higher-order pi-calculus to pi-calculus in the presence of static operators. In CONCUR ’98: Proceedings of the 9th International Conference on Concurrency Theory, pages 115-130, London, UK, 1998. Springer-Verlag. [115] S. T. Vuong and P. Fu. A security architecture and design for mobile intelligent agent sys tems. SIGAPP Applied Computing Review, 9(3):21-30, 2001. [116] J. White. Mobile agents white paper. General Magic, 1994. [117] J. M. Wing. Faq on pi-calculus. Microsoft Internal Memo, December 2002. [118] J. Woodcock. First steps in the verified software grand challenge. Computer, 39(10):57-64, 2006. [119] M. Wooldridge and N. R. Jennings. Intelligent agents: Theory and practice. Knowledge Engineering Review, 10(2): 115-152, 1995. [120] H. Wu and F. Wong. A study of web services transactions based on real-time pi calculus. In Proceedings of the Second International Conference on Semantics, Knowledge, and Grid (SKG’06), pages 90-90, November 2006. [121] S. Zhong and Y. R. Yang. Verifiable distributed oblivious transfer and mobile agent security. Mobile Networks and Applications, 11(2):201-210, 2006. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.