|UFDC Home||myUFDC Home | Help|
This item has the following downloads:
A COMPUTATION PARADIGM FOR MULTIPLE MOBILE AGENT SYSTEMS
OGUZ KAAN ONBILGER
A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY
UNIVERSITY OF FLORIDA
Oguz Kaan Onbilger
my unborn son Alpkan
I would like to express my gratitude to my advisor, Dr. Randy Chow, for his
guidance and support, which made this study possible and for sharing his wisdom with
me. I also would like to thank my co-advisor, Dr. Richard Newman, for fruitful
suggestions, and sharing his intelligence and experience. I thank both of my advisors for
patiently listening to my presentations during the weekly group meetings and providing
I also would like to thank my committee members, Dr. Jih-Kwon Peir, Dr.
Abdelsalam Helal and Dr. Suleyman Tufekci, for their efforts and brainstorming to make
it clear what I was trying to do and their helpful comments and suggestions. Special
thanks go to Dr. Shigang Chen for providing the network simulation software he
developed and his collaboration and discussions. Thanks go again to Dr. Randy Chow for
encouraging this collaboration.
Very special thanks go to my parents for their continual emotional support from
thousands of miles away.
Finally, I express my gratitude to my beloved wife, Derya, for her constant love,
encouragement, patience, and support through difficult times. Without her, this study
would never have been completed.
TABLE OF CONTENTS
A C K N O W L E D G M E N T S ................................................................................................. iv
LIST OF TABLES ........................................................ ........... ........... .. viii
LIST OF FIGURES ......... ......................... ...... ........ ............ ix
ABSTRACT .............. .................. .......... .............. xi
1 INTRODUCTION ................................................................. ..... ....
2 BACKGROUND .................................. ...... .... ..................
2.1 Softw are Agents and M ulti-Agent System s ........................................ ................7
2.2 The M obile C ode C oncept........................................................... ............... 9
2.3 The M obile Agent Paradigm ...................................................... ..................11
2.3.1 Applications of M obile Agents ................ .................. ....................13
2.3.2 M obile A gent System s ........................................ .......... ............... 15
2.3.3 W hat M obile Agents Offer .............................. ..................................... 19
2.3.4 Drawbacks of the Mobile Agent Paradigm ..............................................22
2.4 Security Problem of Mobile Agents ........................................... ...............23
2.4.1 M alicious A gents Problem ......................... .... .... ............... .... 25
126.96.36.199 General protection mechanisms against possibly malicious mobile
code ............... .......... ....... ........................... ...... ....... 25
188.8.131.52 Specific protection mechanisms against possibly malicious agents 27
2.4.2 M alicious H osts Problem ........................................ ....................... 29
3 MULTIPLE COOPERATING MOBILE AGENTS ...............................................35
3 .1 In tro du ctio n .................. ................................................ ................ 3 5
3.2 R equirem ents and Objectives ........................................ .......................... 37
3 .3 D efin ition s ................................................................4 0
3.4 M mission M models .................... .............. ....... ....... .. ..... .. ...... ... .......... 4 1
3.5 Multi-agent Systems (MAS) vs. Multiple Mobile Agent Systems (MMAS).......44
3.6 Proposed Architecture for M M ASs ........................... ....................45
3.7 E xam ple M issions............. .......................................................... ...... .... ..... 48
3.8 R elated W ork ............................................................... 52
4 REMOTE DIGITAL SIGNING WITH MOBILE AGENTS................................54
4.1 Introduction ...................................... ............................................ .. 54
4.2 Electronic Commerce and Mobile Agents............... .............. ...................54
4.3 M obile Commerce and M obile Agents...................................... ............... 55
4.4 Mobile Agent Security in Mobile Commerce ............................................... 55
4 .5 O b je ctiv e s ....................................................... ................ 5 7
4.6 Background .................................... ................................ .........58
4.7 M multiple C ryptography ................................................ ............................. 61
4.8 Key Splitting and Signature Generation...................... ..................63
4.8.1 Using the Multiplicative Property of RSA.................. ..................64
4.8.2 Using the Additive Property of RSA.......................... ................. 65
4.8.3 Using El Gamal Public Key Cryptosystem .............................................66
184.108.40.206 Signing in sequence with El Gamal signature scheme...................67
220.127.116.11 Signing in parallel with El Gamal signature scheme .....................69
18.104.22.168 Transition from El Gamal cryptosystem to digital signature
algorithm ..... .................. .... .. ...................... 70
4.9 The Overall System for Remote Digital Signing............................................71
4.10 Using Limited-liability Keys and Public Key Certificates.............................74
4.11 Practical Issues of Remote Digital Signing ................... ................... ........... 78
4.11.1 Probabilistic Signature Scheme and its Impact on Practice ...................79
4.11.2 Performance Considerations and the Big Picture................................80
5 A NETWORK POSITIONING ARCHITECTURE FOR MOBILE AGENTS......... 84
5 .1 In tro d u ctio n ................................................... .............. ................ 8 4
5.2 R elated W ork ................................................................................ .. ................. 85
5.3 T PN P A approach .......... .............................................. .............. .......... ....... 88
5.3.1 T he A lgorithm .......................... ...................... ............ .. ........... 90
5.3 .2 Starting the Sy stem ......................................................................... .. .... 95
5.3.3 Scalability Issues ....................................... ...... ............ ............. 96
5.3.4 Security C onsiderations.................................... ......................... ........... 97
5.4 Experim ental Evaluation ............................................. ............................. 97
5.4.1 Sim ulation Environm ent....................................... .......................... 98
5.4.2 Sim ulation P aram eters.................................................................... ..... 99
5.4.3 Sim ulation Strategy ............................................................................. 99
5.4.4 Sim ulation R results and A nalysis.............................................................100
5.5 C conclusion ............................................................... ... ... ......... 104
6 QUANTITATIVE ANALYSIS OF MULTIPLE MOBILE AGENT SYSTEMS... 106
6.1 Introduction .............................. ... .................. ........ ................. 106
6.2 Network-awareness in Mobile Agent Computing ......................... ...........107
6.3 The Traveling Salesperson Problem .................................... .........................108
6.4 Application of TPNP and TSP to Classical MA Model .............. .................111
6.4.1 The D ata Structure...................... .... ............................... ..111
6.4.2 The Heuristics .................. ..................................... ... ........ 112
6.5 Experim mental Evaluation ...................................................... ...... ............... 113
6.5.1 Simulation Environment and Parameters .............................................. 113
6.5.2 Sim ulation Strategy ........................................................ ............... 114
6.5.3 R results and A nalysis....................................................... .................. 114
6.6 Context-awareness in MA Computing .................................... ............... 120
6.7 Multiple Cooperating Mobile Agents Model ............................................. 122
6.7.1 Trust M odel ...................... .................. ... .... .. ....... .. ....... 122
6.7.2 Perform ance M odel ....................................... ...... .................... 124
6.8 Application of TPNP to Multiple Cooperating MAs .............. .... ...............126
6.8.1 Problem Form alization ................................... ............................. ....... 128
6.8.2 H euristics for M A TAP ........................................ ......... ............... 131
6.8.3 Experim ental Evaluation ....................................................................... 132
22.214.171.124 Sim ulation param eters................................................................ 132
126.96.36.199 Sim ulation strategy...................................... ........ ............... 133
188.8.131.52 R results and analysis ............................................ ............... 133
6.9 R elated W ork ............................................................................... 140
6.10 Conclusion and Future Work................ ...................... .... ........... 142
7 SUMMARY AND FUTURE DIRECTIONS.......................................... .....144
R E F E R E N C E S ....................................... ........................................................... .. 14 7
BIOGRAPHICAL SKETCH ............... ............ ................................ ............... 156
LIST OF TABLES
3-1. Comparison of MAS and MMAS................................................................ 44
6-1. Application of NN heuristic with TPNP ............ .......................................... 118
6-2. Application of RA heuristic with TPNP.............................................................118
6-3. Application of FRP heuristic with TPNP ...........................................................118
6-4 Sim u nation p aram eters ................................................................... ..................... 133
LIST OF FIGURES
2-1. M obile agent execution m odel .............................................................................12
2-2. M obile agent execution platform .......................................................... .... ............ 16
3-1. M obile client/server m odel ............................ ............... ..... .... ............ ............... 42
3-2. Multiple mobile agents model with two mobile agents........................... ...........43
3-3. Multiple mobile agent system architecture...... ....................... ...........46
4-1. A snapshot of a mission using multiple mobile agents ...........................................67
4-2. Protocol for sequential signing with multi-agent model ........................................72
4-3. Protocol for parallel signing with multi-agent model ...........................................73
4-4. Lim ited-liability key protocol......................................................... ............... 77
5-1. Global netw ork positioning m odel (GN P)....................................... .....................86
5-2. Local network positioning model (TPNP) ..................................................88
5-3 D iscov ery alg orith m ........................................................................ .....................9 1
5-4 Selection algorithm ............ .............................................................. ....... ............ 92
5-5. D instance m easurem ent protocol.......................................... ............................ 93
5-6. A average relative error .......................................................................... 101
5-7. A average local relative error ......................................................................... ... ... 102
5-8. A average outliers relative error...................................................................... .. .... 102
5-9. Distribution of average relative error to path latencies ................... ............... 103
6-1. Performance of 2-Opted TSP heuristics across the problem size ..........................15
6-2. Performance of 2-Opted TSP heuristics across the number of TPNP dimensions... 116
6-3. Illustration of M A TA P .................................. ................ ..................................... 127
6-4. Mission communication time across problem size............................135
6-5. Mission communication time across security level category ................................136
6-6. Mission communication time across random selection distribution over security
lev e ls ...................... .. .. ......... .. .. .................................................. 1 3 7
6-7. Effect of transmission rates on mission communication time..............................138
6-8. Heuristic performance with the available SA hosts in the network .......................139
6-9. Heuristic performance with the number of clusters .................................................140
Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy
A COMPUTATION PARADIGM FOR MULTIPLE MOBILE AGENT SYSTEMS
Oguz Kaan Onbilger
Chair: Randy Chow
Cochair: Richard Newman
Major Department: Computer and Information Science and Engineering
Mobile agent (MA) systems have been proposed as a potentially useful computing
paradigm for distributed applications. An MA is an autonomous computing entity, which
migrates from one host to another carrying its code/data/state information, to accomplish
a task on behalf of its owner. The concept is attractive since mobility of the agent brings
execution closer to the remote resources resulting in a great reduction of communication
overhead, and the autonomy property of the agent relieves the attention of the initiating
owner, rendering more concurrency for the applications.
The primary hindrance that prevents MA systems from wider acceptance is the
concern of MA security. Protection of agents from malicious hosts is considered a
difficult problem. Our goals are to prove that sufficient degree of agent security can be
achieved to make MA systems a reality, and to propose prototype architecture for secure
multiple MA systems.
Our approach relies on the assumption that security can be enhanced through the
use of multiple collaborating MAs. We conjecture that security can be strengthened
through protection as a whole meaning that attacks to some of the agents cannot corrupt
the entire group of agents performing collaboratively on a common task. One of the
problems tackled in this research is the requirement of the ability to compute / i/h secrets
in public domain. Our research focuses on a special case of this problem, i.e., remote
digital signing with multiple agents. Multiple collaborating MAs are a natural extension
(with mobility) of the research on multi-agent systems in artificial intelligence.
Central to the design of mobile systems is the ability to track the locations of
migrating agents. In our proposed multiple MA system, agents need contextual
information based on location to optimize their traveling itineraries. We propose a
general coordinate-based peer-to-peer network-positioning scheme for the system. The
design of such a location service opens up many new and interesting variations of the
classical traveling salesperson problem. The location service is used in a simulation tool
for analyzing the performance and communication overhead of the MA-based network.
The concept of software agents is a natural extension of the notion of processes in
traditional operating systems. In the context of distributed systems, software agents are
autonomous processes deployed at various sites to perform some specific functions or
tasks. When collaborations among these agents are needed, they form a Multiple Agent
System (MAS) to achieve a common goal. The design issues on MASs generally fall into
two complementary research areas, distributed systems and artificial intelligence. The
distributed systems research community is concerned with the system supports for the
agent technologies such as synchronization and communication of interacting agents,
while in the AI community, the focus is more on the intelligence and decision support of
the cooperating agents. This research adds another dimension, mobility, to the multiple
agent systems we term, Multiple Mobile Agent Systems (MMAS). In such a MMAS,
mobile agents exhibit strong mobility in that they need and are allowed to dynamically
migrate from host to host carrying with them their code/data/state information to
accomplish their missions.
The concept of code migration or mobile code is not new. Most Internet users have
experienced its impacts in both positive and negative ways. On the positive side, we have
enjoyed downloaded programs such as Java applets in web browsers for all kinds of
operations ranging from banking transactions to animating cartoon characters. This
aspect of mobile code technology helps to realize the important goals of transparency and
efficiency in distributed systems. On the negative side, we have seen numerous malicious
uses of the technology in the forms of viruses and worms that disrupt our daily computer
operations. Similarly, Java servlets, which are the server counterpart of applets, have
become commonplace for many Internet applications. Like applets, their code migration
is static, meaning that codes are uploaded to servers, run there and cease their existence.
The emerging mobile agent technology takes the applet and servlet concepts one step
further to allow dynamic and continuous migration of the agent processes autonomously.
Mobile agents have been proposed and used in some limited application domains
such as e-commerce, information retrieval, network management, software distribution,
distance education, and even as a security mechanism for intrusion detection. It has been
argued that using mobile agents as a programming paradigm is a perfect fit for distributed
systems since the autonomous characteristics and mobility of agents facilitate naturally
the implementation of asynchronous and dynamic interaction of concurrent execution in
distributed applications. More precisely, the mobility of agents brings execution closer to
the remote resources resulting in great reduction of communication overhead, and the
autonomy property of agents relieves the attention of the initiating agent owners
rendering more concurrency for the applications. However, the concept has received
much skepticism until the current millennium, out of concern that interoperability and
security might not be justified if agents are to roam freely in an open and large-scale
network. This research addresses the security issue of mobile agents. In particular, it
claims that utilizing multiple collaborating mobile agents can actually enhance the
security of the applications.
There are two separate categories of threats in mobile agent security, malicious
agents and malicious hosts. Protection of hosts against malicious agents is well
understood and has been implemented at least in some degree in most systems. Common
solution approaches to the problem are host hardening and agent containment such as the
built-in security mechanisms for byte-code execution in Java language and virtual
machine. The protection of mobile agents against malicious hosts, however, is less
intuitive. First, the assumption that a user would send its agent processes to untrustworthy
hosts is less conventional. Second, the secrecy and integrity of the agents and the need to
execute the code in public might conflict with each other at times. Total agent protection
is considered unsolvable without special hardware by some researchers. The main
difficulty comes not only from agent mobility but also autonomy. Especially, their ability
to migrate from one host to another poses vulnerabilities, which could easily be exploited
by the very host platforms they execute on. This dissertation focuses on the problem of
protecting mobile agents against malicious hosts.
There are threats to mobile agents which lead to very simple attacks that could be
devised: denial-of-service and replay attacks. A host platform which receives an agent
may simply not execute the agent at its own discretion, which leads to denial of service.
Similarly, a host platform can reuse the agent by using the credentials delegated to it by
its owner (i.e., user) to masquerade the original host and user, which leads to replay
attacks. These two types of attacks are not properly addressed by the known or proposed
mechanisms. A complete description of attacks possible against mobile agents and a
background information about proposed solutions and their classification are given in
We have identified several requirements for a solution for the malicious hosts
problem. These are summarized as follows:
1. A solution proposed to protect hosts from possibly malicious hosts should not
jeopardize the protection of hosts from agents,
2. The second important requirement is that solutions should not limit the potential
benefits of mobile agents,
3. It is vital to address easier attacks against mobile agents, which are denial-of-
service and replay,
4. The concept of the network trusted computing base needs to be extended to be
applications and case specific.
Details of these requirements are provided in Chapter 3.
The theme of this dissertation is to address the protection of mobile agents from
possibly malicious behavior of host platforms by keeping in mind the requirements
pointed out above. The proposed technique is based on an autonomous group of multiple
agents designed to accomplish a single well-defined task, which in turn relies on the
concept of information dispersal for security. Information dispersal is not a new concept.
Both cryptographic and non-cryptographic means of protection via the technique have
been proposed and implemented. Cryptographic mechanisms are mostly related with key
sharing and threshold cryptography. Non-cryptographic means are directly applied on
data to be protected. For example, sensitive information is split up and distributed to
several hosts connected with a computer network. Penetration to one or some of the hosts
would not reveal the information, and intrusion to several hosts is considered more
difficult than intrusion into a single host. Similarly, sensitive information carried by
mobile agents (this may also include the code) can be split up and given to multiple
agents. Therefore a successful attack against the group of agents is more difficult than
attacking a single agent. Agents in the group should be located on different hosts, and
furthermore on different administrative domains. Agents in the group should
communicate and cooperate to accomplish the task given. Therefore, tampering with one
of the agents could be detected by the others in the group.
The feasibility of the described approach however does not only depend on
information dispersal. To apply the concept into dynamic mobile agents, we first need to
figure out how to position multiple mobile agents, specifically how to find the hosts to
locate the agents in a feasible manner. This opens up very interesting research issues
including making mobile agent systems aware of the underlying network topology. While
we are focusing on one specific application of information dispersal in Chapter 3, our
focus in Chapter 4 is on the network positioning models to be able to apply information
dispersal into multiple mobile agents in an open internetwork environment.
This dissertation is organized as follows.
In Chapter 2, we provide a brief description about software agents and multi-agent
systems, mobile code concept and its applications, mobile agents, their benefits and
drawbacks. Then we provide background information about mobile agent security from
both perspectives described above and proposed solutions and their categories in more
In Chapter 3, we explain the concept of group of multiple cooperating agents for
security. We provide models applicable to this concept and our proposed model. We
define the mission concept and model and distinguish this concept from the multi-agent
systems. The proposed multiple mobile agent system architecture is also introduced.
Chapter 3 is the foundation for the rest of this dissertation.
In Chapter 4, we address the remote digital signing problem of mobile agents. For
the mobile agent paradigm to be widely accepted and used, one must demonstrate that
mobile agents are capable of performing computations that are possible with the
client/server model. Digitally signing a contract is one such computation in e-commerce
applications that needs to be performed by mobile agents. We demonstrate that it is
feasible to perform this computation with multiple cooperating agents using the
information dispersal for security concept, as presented in Chapter 3.
In Chapter 5, we examine the network distance measurement approaches and
propose a general, highly scalable coordinate-based peer-to-peer network-positioning
scheme, one that fits better to the requirements of the mobile agent systems. By using a
simulation tool, we analyze and demonstrate the achieved accuracy of the approach.
In Chapter 6, we apply the network positioning system proposed in Chapter 5
together with traveling salesperson problem heuristics to traditional mobile agent
computing and multiple mobile agent systems. We are looking for the answers to the
questions about whether we can alleviate the performance problem of multiple mobile
agent systems and if we can do it efficiently without canceling out the performance
benefit achieved. This chapter also deals with network- and context-awareness in mobile
Finally, Chapter 7 summarizes our work and provides future research directions.
Mobile agent paradigm has two descendants: software agents and mobile code.
Mobile agents are software agents with the added feature of mobility. On the other hand
what makes them mobile is the general concept of mobile code. So, mobile agents
combine these two unrelated concepts, and become a unique technology in distributed
systems. In this chapter we provide a brief outline of software agents in general and then
have a look at the mobile code concept and its applications. The rest of the chapter is
dedicated to mobile agents, their applications, systems, standards, pros and cons. A
detailed survey of the security problem of this technology and the proposed solutions
ends the chapter.
2.1 Software Agents and Multi-Agent Systems
Software agents are an active research area in Artificial Intelligence (AI) and
distributed computing systems. In this section we use the term "software agent" to refer
to software entities that are subject to research in these two fields, in general. So,
autonomous agents, intelligent agents, interface agents, virtual agents, information
agents, and mobile agents are all software agents.
The difficulty with the definition of an agent in the AI community is to distinguish
a software agent from a software program (Franklin & Gaesser, 1997). Bradshaw (1997,
pp. 7) cites the definition given by Shoham (1997), with the hope that it might be
acceptable to most researchers: "A software entity which functions continuously and
autonomously in a particular environment, often inhabited by other agents and
processes." Murch and Johnson (1998, pp. 16) provide a survey of definitions and as a
result they conclude that "agents are, by consensus, autonomous, goal seeking, persistent,
reasoning, productive, and communicative." So, it seems like characterization of agents
makes more sense than giving an exact definition. Bradshaw (1997, pp. 8) shares the
same point and as the result of his own survey concludes that "consistent with the
requirements of a particular problem, each agent might possess to a greater or lesser
degree attributes like the ones: reactivity, autonomy, collaborative behavior,
communication ability, inferential capability, temporal continuity, personality, adaptivity,
From the distributed computing systems perspective, however, our focus is on
mobile agents, which is a specialization of generic software agents with the added ability
of mobility. The details on mobile agents are given in Section 2.3.
A precise description of multi-agent systems is given by d'Invemo and Luck (2001,
Multi-agent systems are typically distributed systems in which several distinct
components, each of which is an independent problem-solving agent come together
to form some coherent whole. There is generally no pre-established architecture or
configuration incorporating the agents, and the interactions between them are not
pre-defined, as is usually the case with traditional processes in concurrent
programs. More importantly, there is no global system goal, the agents being
heterogeneous with their own goals and capabilities. In consequence, agents in a
multi-agent system need to coordinate their activities and cooperate with each
other, in order to avoid duplication of effort, to avoid unwittingly hindering other
agents in achieving goals, and to exploit other agents' capabilities.
What is not clearly specified in the above description is that owner or users of the
agents participating in a multi-agent system may be different parties.
It is necessary to distinguish the multi-agent systems and the multiple-agent model
we use in our research for better understanding. This distinction is made clear in Chapter
3 where we define multiple cooperating agents concept.
2.2 The Mobile Code Concept
The mobile code concept may be best understood by examining the applications. In
the following we provide brief descriptions of mobile code applications.
In traditional distributed computing systems, applications are built on the
client/server paradigm. Usually, the client process sends a request to the server process
over the network. The server processes the request and returns the result to the client. The
communication between the clients and servers are handled through message passing or
Remote Procedure Calls (RPC). This is a synchronous process in the sense that clients
usually block after sending the request until the reply arrives or a certain timeout is
observed. Although asynchronous RPC changes the classical synchronous
communication nature of the client/server model, the request/reply scheme remains the
same. The mobile code concept however makes a paradigm shift in distributed
In contrast to the request/reply scheme, in mobile code systems, not only the data
but also the code to be executed is exchanged between the applications. Remote
evaluation has been first proposed by Stamos and Gifford (1990). In this scheme, code to
be executed is sent to the remote machine. The result of execution is sent back as data
As is true for other resources, processor cycles can also be shared in distributed
systems. The mechanism necessary for sharing such a static component requires code
migration in the form of processes, which is known as process migration. The first
objective of process migration in distributed systems is to redistribute load and improving
performance by migrating processes from node to node. The secondary objective is to
achieve location and performance transparencies by distributed process scheduling
(Chow & Johnson, 1997).
Perhaps the most well-known mobile code mechanism that is widely used today is
Java applets. An applet is a Java object that is associated with a web page. When the page
is requested by a client browser, applet is downloaded into the client machine along with
the web page and executed in the Java Virtual Machine installed on the same machine.
Applets are static in the sense that they cannot move anywhere other than the client
machine, Moreover, their communication to the outside world is restricted to the
originating server machine due to security concerns.
The server counterpart of applets is an object known as a servlet in Java. So,
servlets are uploaded from the client to the server to make the server functionality
customized according to the specific requirements of the client. Code migration,
therefore, follows the opposite path of an applet. Servlets are widely used today by the
web servers, which are implemented in Java. However, servlets in use today are created
and used by the server host, mostly due to the security concerns. Therefore, the capability
of code migration, which was explained above, is not used. Java applets and servlets are
said to be examples of code-on-demand paradigm (Lange & Oshima, 1998).
Active networks are an active research area employing the mobile code concept
(Hartman et al., 1996; Tennenhouse et al., 1997; Tennenhouse & Wetherall, 1996). The
area has its roots in the SOFTNET project, which is a multihop packet radio network
developed in the 1980s (Zander & Forchheimer, 1988). In active networks, specialized
packets, which are called capsules (Tennenhouse & Wetherall, 1996), carry not only data
but also code. The code is injected into the nodes along the route of the capsule.
Subsequent packets which are related to the original capsule trigger the execution of the
code previously stored in the nodes. The result is that the routers of the network and
therefore the network itself are programmed by its users. Immediate advantages of the
described scheme are that customized computation for individual applications can be
carried out inside the network and new network protocols can be installed on the routers
2.3 The Mobile Agent Paradigm
Mobile agents (MAs) are an approach to distributed computing employing the
mobile code concept. MAs are autonomous entities, which are composed of code, data
and state information. They visit hosts (e.g., servers) possibly using an itinerary, perform
some execution on those hosts using their codes and migrate with their state information
from host to host. As in the case with stationary agents, they act on behalf of their owners
(e.g., senders). They are autonomous in the sense that they have all the knowledge needed
to perform the assigned task on behalf of their owners. The traditional mobile agent
execution model is illustrated in Figure 2-1. The mobile agent is launched from the
originating platform by the owner. It visits the hosts to accomplish its task and return to
The most important difference between the MA paradigm and the other mobile
code systems is the strong mobility of MAs. None of the mobile code systems and
mechanisms except the process migration mentioned in the previous section has the
strong mobility feature. This means that the execution state of the transmitted mobile
code is not carried. Therefore, the code (e.g., program, procedure or method) starts
execution from the beginning and terminates at a certain point. In the case of mobile
agents, execution stops but not terminates and resumes at the next platform, where the
mobile agent migrates.
Host I Agent Agent Host
Host Agent \ I Agent Host
Agent Owner's Host
Figure 2-1. Mobile agent execution model
Migrating processes are not allowed to choose where and when to migrate in
contrast to mobile agents. While processes are migrated to balance the load transparently,
mobile agents autonomously migrate to hosts where the information or services are of
interest. Another difference between the two is that processes in general can migrate
among homogeneous environments whereas mobile agents are designed to run on the
middleware, which makes them platform (machine and operating system) independent.
Active network architecture is mainly proposed for network level tasks, although
application level customization is also possible. Mobile agents, in contrast, are mostly to
be used at the application level. While the target hosts are the network routers in the
former, target of mobile agents can be any host. One last distinguishing feature is that
mobile agents have execution state, whereas an active capsule has no such state.
However, active networks and mobile agent systems are not mutually exclusive. Active
network architectures and models, which employ mobile agents, have been proposed
(Breugst & Magedanz, 1998; Busse et al., 1999).
2.3.1 Applications of Mobile Agents
Mobile agents have been proposed to be useful in a wide range of applications. We
classify these applications in the following and give a brief insight about the application
E-commerce, m-commerce. Among many application areas of MAs, e-commerce
draws the most attention from both academic and industrial researchers (Busch et al.,
1998; Marques et al., 1999; Klusch, 1999; Roth, 2000; Sandholm, 2000). This is mostly
due to the fact that, MAs and in general agent systems have the capability of representing
users (i.e., customers) in the electronic marketplaces. Agents can effectively profile user
preferences, act on behalf their owners, participate in e-auctions, watch stock prices,
search for commodities and find the best offer from competing vendors, purchase goods
by paying and committing to transactions, communicate and cooperate with other agents
of relevant goals.
Network management. Code mobility in the form of mobile agents has been
proposed by many researchers as a promising technology in network management. Some
examples are Baldi, & Picco, 1998, Papavassiliou et al. 2002, and Meer et al., 2000.
Baldi and Picco (1998) model network management activities using client/server model,
remote evaluation and mobile agents and summarize advantages of using mobile code in
network applications as semantic compression of information, a higher abstraction level
to the network manager and autonomy of management agents.
Information retrieval. The information retrieval problem is getting more difficult
everyday on the Internet due to the amount of information available to the users. Mobile
agents can search, filter and retrieve vast amount of information locally. Therefore
information retrieval has become one of the most important and popular application areas
of the mobile agent paradigm. Brewington et al. (1999) provides a qualitative and
quantitative analysis of the use of mobile agents in information retrieval applications.
Johansen (1998) discusses pros and cons of mobile agents in different application areas
and provides quantitative analysis of real applications. One of these applications is
StormCast where several servers receive weather data from meteorological censors.
Users in turn, by sending their mobile agents can learn about the weather conditions in
their area, and even set alarm conditions which are watched by their agents. Agents react
by notifying the their users when the condition is occurred.
Software distribution. Mobile agents are capable of customizing server side
functionality by moving the client specific code to the server and this capability is one of
most important benefits of the mobile agent paradigm. This concept therefore can even be
used to deliver software for permanent use of server and client computers. Using this
push model, subscribed code consumers may enjoy immediate software installation and
updates. In fact, active networks are a good example of using mobile code in the form of
specialized packets to install new protocols to the network routers, on-the-fly. An
example of software update application using mobile agents is given by Bettini et al.
Other application areas. Other example specific application areas are
distant/remote education (Jamwal & Iyer, 2003), and vehicular traffic management
(Schill et al., 1998). Mobile agents have also been proposed as alternatives to provide
security in distributed systems. An example is intrusion detection systems, which utilize
mobile agents (Jansen et al., 2000).
2.3.2 Mobile Agent Systems
Informally a mobile agent system is a middleware where mobile agents live. This
middleware typically sits on top of a runtime environment. The runtime environment is
responsible for running the mobile agents and in some cases also for the execution of the
mobile agent system itself as in the case of Java systems. The instances of these
middleware systems, which run on hosts are known as places (Lange & Oshima, 1998) or
platforms. We prefer the term "platform". So, the mobile agents are created, executed and
terminated in these platforms. When we say that mobile agents migrate between hosts,
what we actually mean is that they migrate between the platforms, running on different
hosts connected through a network. The mobile agent systems are responsible for all the
operations of mobile agents. Creation, migration, communication with other systems and
agents, cloning, security and termination are all handled by the underlying platform.
Figure 2-2 illustrates the mobile agent system concept and relationships with the
other components of a host, which employs a mobile agent platform. The runtime
environment is typically a high-level language interpreter or Java virtual machine, since
vast majority of mobile agent systems today are built using the Java programming
language. Java has been the common ground for mobile agent systems, mostly due its
standard, object-orientedness, support of mechanisms such as serialization and reflection,
support of distributed objects as in RMI, and inherent security features. However,
because different mobile agent systems themselves and mobile agents are implemented in
the same programming language and executed by the same standard Java virtual machine
does not mean that these systems would be interoperable. More details on interoperability
problem are given in Section 2.3.4.
Mobile Agent Platform
T JVM T
Figure 2-2. Mobile agent execution platform
Today, there are more than fifty mobile agent systems. It is difficult to keep track
of all the mobile agent systems exist today around the world. Some of the earlier ones
ceased to exist as they become unsuccessful in the market or some of them have been
experimental research systems. However, many new projects have been started to
develop new systems which usually to overcome the deficiencies of the existing or
Kiniry and Zimmerman (1997) provide a survey of both commercial and research
based Java mobile agent systems. Brewington et al. (1999) classify the systems as
multiple language, Java based or others which are written mostly in script languages, and
compare the systems. Lange and Oshima (1998) give a brief description of popular
mobile agent systems. Karnik (1998) classify mobile agent system according to several
criteria including the security features provided by these systems. We classify the mobile
agent systems as in the following.
Programming language used. Most of the latest mobile agent systems are
developed in Java. Hence, mobile agents themselves are implemented in the same
language. Earliest systems however have been written in scripting languages or
interpreted bytecodes in other high level languages.
Migration state carried by the agents. There are two different approaches for
mobile agent migration. Within the first one control state of the mobile agent is captured
and send to the target machine. The execution resumes in the target where it left off in the
source machine. Within the second approach, the execution state of the mobile agent is
not sent to the target machine. The programmer is responsible for the agent state and the
execution state resume in the target host by referring to an entry point. The second
approach makes it simpler to develop the underlying system but it may be a burden to the
application programmer to capture the current state of the agents. But this is not really a
problem because migration decision is made solely by the mobile agent itself by
executing an instruction such as go. Since, migration is not forced by the underlying
system, entry points can be easily specified using the data portion of the agent rather than
the control state which includes the execution stack. This approach is taken by many of
the Java based systems for interoperability since Java does not support inspection of the
execution state of the objects due to security concerns. The former approach requires
modifications to the JVM to capture the state and hence mobile agent systems and mobile
agents developed using these systems can not run on standard JVMs.
Multi-threading of mobile agent systems and mobile agents. Many Java mobile
agent systems run the agents as a separate thread of the main process of the mobile agent
platform. Others run agents in isolated processes and some of the systems use a
combination of the two approaches. Ara is an example of the former approach whereas
D'Agents is for the latter.
Communication primitives. Different mobile agent systems use different
communication primitives among mobile agents. Some uses message passing, or RMI.
Some systems require the agents to be present at the same platform, some other provide
remote communications between sites. As examples, Aglets support sending and
receiving messages in the form of objects, Ajanta supports RMI using proxies and
D'Agents use message passing.
Security provided. This is perhaps the most important classification from our
point of view. Unfortunately, vast majority of the mobile agent system have been
developed without any security consideration at all. This is perhaps due to the fact that
these systems are not intended for large scale, open systems or networks such as the
Internet. In a company network or intranet, security may not be that important for mobile
agent systems. Kamik (1998) makes the distinction among mobile agent systems in three
categories: secure communication, server resource protection and agent protection.
Secure communication is about whether the agent migration is protected using encryption
and authentication. Server resource protection is usually associated with authorization of
agents and access control mechanisms such as ACLs. Agent protection is related with the
malicious hosts problem. Agents must be protected against any possible hostile behavior
of hosts where they are executed. This is an open research area, which is the subject of
this dissertation and only a limited number of agent systems support mechanisms within
2.3.3 What Mobile Agents Offer
Lange and Oshima (1998) point out that mobile agents: 1. reduce the network load,
2. overcome network latency, 3. encapsulate protocols, 4. execute asynchronously and
autonomously, 5. adapt dynamically, 6. are naturally heterogeneous, and 7. are robust and
fault-tolerant. Gray et al. (1996) examines the benefits of mobile agents from the mobile
computing perspective. They point out the capability of mobile agents which provides a
powerful alternative for partially connected computing through mobile computers (i.e.,
laptops, personal digital assistants, etc.) and home computers, which have intermittent
connections to the fixed networks. They also highlight how mobile agents simplifies the
development, testing and deployment of distributed applications, and how it is possible to
employ a scalable, peer-to-peer architecture for distributed applications instead of the
rigid client/server model.
Chess et al. (1995b) in their classical paper in the area collect fourteen claims,
which have been given as the advantages of mobile agents over existing client/server
paradigm (i.e., message passing, RPC, etc.) and they examine each claim in detail. They
conclude that none of the claimed application areas could be uniquely addressed by the
mobile agent paradigm (one exception might be the real-time applications which could be
impaired with the network latencies between hosts that run client and server components
of such a distributed application, especially in wide-area networks). For every application
area, they could find an alternative that may well be addresses by the existing
technologies. However, as the final conclusion they point out that mobile agent
technology is unique in the sense that there is no alternative technology that could
address all of the application areas and benefits together that can be offered easily by the
Johansen (1998) shares their experiences of implementing and using mobile agents
in real world applications using the Tacoma mobile agent system and also provides
quantitative analysis of the performance aspects of mobile agents. He concludes that 1.
agents are a convenient way to install client software at remote hosts, 2. their most
successful application would be to build extensible servers, 3. the asynchronous nature of
agents is important, 4. agents are shown to be a very convenient structuring technique for
the distributed applications.
We briefly summarize the benefits, which are offered by the mobile agent paradigm
Mobile computing point of view. Mobile devices have limited battery life, and
their intermittent connection to the wireline networks have low bandwidth, and high
latency. Mobile agents overcome all these problems. They can be launched from mobile
devices in a brief connection to the fixed network. Returning results to the users requires
only another brief connection. During the computation the device can be disconnected
from the network, and can even be turned off.
Networking point of view. Mobile agents are capable of searching, analyzing and
filtering huge amounts of information available on the servers across the Internet. As a
result they can only return the most relevant information to their interested users. This
saves network bandwidth when compared to the existing client/server model of
computing where all the analysis and filtering are performed in the client side which
requires transferring all irrelevant information along with the most relevant parts.
Service point of view. Services offered by servers can be customized according to
the user requirements, on-the-fly. Servers can offer basic primitives to use their services.
Using these simple primitives, mobile agents can be programmed to reach the services
and information offered by the servers in a customized way. The alternative used today is
to provide service packages, which are offered to clients. Offering a new service requires
a long implementation and deployment process. Therefore, users have to choose from
these offered service packages. Mobile agents make the deployment process immediate.
Application development point of view. Even it is not a real problem
theoretically, client/server based application development poses the problem of a design
issue of at which component the client or server, the services should be implemented.
Mobile agents overcome this problem easily. Client side functionally can easily be
moved to the server. Mobile agents, in general, simplifies the implementation, testing and
deployment of distributed applications (Brewington et al., 1999; Johansen, 1998).
Interestingly enough, they can even be used to develop and deploy prototype distributed
applications (Chess et al., 1995a).
Application user point of view. Not only mobile agents, but in general software
agents have the capability of representing their users and user preferences, which is an
important benefit especially in electronic commerce and mobile commerce applications.
Distributed system point of view. Most distributed applications fit naturally to the
mobile agent model (Brewington et al., 1999), mostly because of the mobility of the
agents. This is the aggregate advantage and hence becomes the unique property of mobile
As a conclusion we believe that mobile agents possess an enormous potential in
building feature distributed systems, once their drawbacks are addressed convincingly, as
explained in the following sections.
2.3.4 Drawbacks of the Mobile Agent Paradigm
Two major open problems, which prevent mobile agent paradigm from being a
widespread, actively used technology today, are security and interoperability. The
security problem of mobile agents is addressed in the next section. Here, we provide brief
information about the interoperability problem.
As mentioned in Section 2.3.2 mobile agents require their own mobile agent
platforms to be executed. For example, an Aglet cannot be executed in an Ajanta
platform even though these two mobile agent platforms and agents themselves were
implemented in Java and all they need is a standard Java virtual machine. Interoperability
has several aspects such as capability of communication between the different systems
via message passing or RPC, capability of running mobile agents from different systems,
or communication between agents from different systems.
Recently, Brazier et al. (2002) proposed generative migration of mobile agents
among heterogeneous platforms. This approach is based on agent factories and blueprints
of agents. Blueprints, which could be describe with a high-level specification language,
describe the agent functionality. Agents' state is described by a language such as XML.
Agents' blueprints along with their state are migrated between host platforms where
agent factories exist. The job of the agent factory is to transform the blueprint and the
state into an executable form using libraries designed for this purpose and for the target
environment, which exists on the same host. Although the approach seems to be
promising, it raises several questions. First one is the security issue. While it is already
difficult to protect agents from malicious hosts, this approach makes it worse. For
example, the approach renders the agent protection schemes completely useless which are
based on obfuscation methods. The other concern is performance overhead introduced
with the approach to transform agents back and forth.
Another approach is to let agents migrate only between their own platforms. If and
when they need information available on some host, which does not employ the same
platform that the agent needs, the agent migrates to the nearest host to the target one, with
a platform needed for the agent. Then, assuming standard client/server interfaces are
employed between the hosts, agent becomes a client and communicate with the target
host using a request/reply scheme. This scenario is equivalent to the one with a target
host, which does not support any mobile agent platform as in (Theilmann & Rothermel,
2000). The major problem with this approach is related with performance, which is to
find the nearest available hosts to the target host. This issue is a subject of this
dissertation. Moreover, making mobile agents dependant on the client/server model limits
their capability to customize server functionality.
2.4 Security Problem of Mobile Agents
In contrast to many other technologies in distributed systems, mobile agent
technology will not be accepted and widely deployed before the security problem is
solved. Other technologies have been widely deployed before their security requirements
have been understood and mechanisms have been implemented and used.
There are two types of security threats introduced by mobile code systems. One
comes from potential malicious agents and the other from malicious hosts. The malicious
agents problem is rather old and many protection mechanisms have already been
proposed and implemented because of the fact that some kind of protection mechanisms
are common in mobile agent systems and other mobile code systems. On the other hand,
the malicious hosts problem is more difficult and considered unsolvable without
dedicated hardware. The problem is relatively new since the computation in the form of
mobile agents has never been defined to take place in a remote environment that could
possibly be malicious. We are concerned with the latter problem in this dissertation:
protecting the MAs from malicious hosts.
Chess (1998) identifies the assumptions made on the security of computing systems
in four categories: identity assumption, origin of programs, origin of attacks, immobility
of programs. These assumptions state that programs and their users can be easily
identified; programs are obtained from easily identifiable and trusted sources. Significant
security threats come from attackers running programs with a clear intent in a restricted
environment. Programs rarely cross administrative boundaries and only in controlled
ways, programs run entirely on one machine on a specific operating system and operating
system is responsible for the security. Unfortunately, these assumptions do not hold for
mobile agents and in general, mobile code systems. Therefore new security mechanisms
are necessary especially in the mobile agents case.
The protection of hosts from potential malicious agents and the protection of agents
against potentially malicious hosts are not mutually exclusive. There are two reasons for
this. First one is that, in general, solutions proposed for the former problem implies also
the protection of hosts. This is due to the fact that, a successful attack against a mobile
agent in a given platform may threaten the subsequent platforms, which the MA visits.
For example a brainwashed shopping agent may request for hundred airline tickets
instead of the correct value of two. Similarly, an agent responsible for software updates
may introduce Trojan horses to the subsequent hosts it visits, if a former platform could
fabricate this code inside the software patches carried by the agent. The second reason is
that some protection mechanisms, namely obfuscation techniques may render host
security useless, since the intent of the agent might not be easily checked or verified by
the platforms, which are to execute the agents.
2.4.1 Malicious Agents Problem
Hosts, which are to accept and execute MAs must be protected against possibly
malicious MAs. A malicious agent may access sensitive information on the host, which is
not authorized to do. Moreover, MAs may alter, fabricate or delete data or files, and may
inject malicious behavior in the form of Trojan horses.
We have a brief look at mechanisms to protect hosts from two perspectives. The
first one is the general mechanisms, which apply to almost all mobile code systems hence
to MAs. The second category is specific to MA security, which necessary due to strong
mobility and multiple execution platforms that a given MA may need to migrate and run.
184.108.40.206 General protection mechanisms against possibly malicious mobile code
Sandboxes and playgrounds. Sandbox is a restricted execution environment
where all the foreign code (i.e., downloaded from another machine) is to be executed. In
Java, the Java Virtual Machine executes foreign code in a sandbox, which is
complemented by a security manager, which checks the instructions of the code to verify
if they adheres to the security policies (Oaks, 1999). For example, foreign code has
restricted access to the file system, main memory and other assets of the computer
system. Moreover, in the case of Java applets for example, their communication to the
outside world is also restricted to the host from where they are downloaded. Since the
code inside the sandbox needs to be interpreted in order to be checked, code
interpretation is regarded as a part of the sandbox (Tanenbaum & Van Steen, 2002).
However, in general, there exist code interpreter systems that do not employ the sandbox
concept. Therefore, we consider this mechanism as a separate one in the following.
Malkhi and Reiter (2000) extended the sandbox mechanism into playgrounds.
Basically, the functionality is the same, however, playgrounds are to be placed in
physically isolated machines. Foreign code is downloaded and executed only in these
machines. The local programs can access the migrated code and data through traditional
mechanisms. However, foreign code cannot access to the other computers and local
assets in them.
Interpreting code. Code interpretation is an important concept in mobile code
systems for interoperability of heterogeneous systems. The code, which is not compiled
directly into the machine instructions but instead compiled into some intermediate code
(i.e., bytecodes in Java) can be run by standard middleware systems on top of the
underlying specific operating systems. The best known example is the standard Java
Virtual Machine, which can run almost on any operating system exist today.
A nice side effect of code interpretation is the ability to easily check the code
before execution during runtime. Therefore, each instruction can be inspected to figure
out whether there is any access violation or any behavior, which does not conform to the
security policies defined.
Code signing. It is important in mobile code systems to authenticate the source of
the code, which is migrated or downloaded. Digital signatures (through public key
cryptography) can effectively be used for this purpose. The code is signed by the
manufacturer (i.e., programmer) and/or the owner (i.e., user of a MA) by using their
private keys. The receiver uses the corresponding public key to authenticate the source of
the code. If the source is considered to be trusted then the foreign code can be assumed
safe and executed. Even in theory this works well, in practice it is difficult to assess the
trustedness of the source and the level of trust that could be associated with the source.
220.127.116.11 Specific protection mechanisms against possibly malicious agents
Here, we provide an overview of the mechanisms proposed for the host protection
against malicious agents. These mechanisms, mostly try to circumvent the issues arise
from the nature of strong mobility of MAs which is a direct result and necessity of
visiting multiple host platforms to accomplish a task.
Path histories. The idea of path histories (Chess et al., 1995a; Ordille, 1996) is to
record and carry authentication information of previously visited hosts, with an MA.
Each host platform digitally signs and inserts its own identity and the next platform to the
history using digital signatures. Meanwhile, every host, which receives an agent checks
the validity of the signatures and decides by looking at the previous hosts, whether it
would be safe to accept and execute the MA. If, for example, any of the identities of the
previous hosts is considered to be untrusted, the MA is discarded. The drawback of the
approach is that the payload of the MA increases at the every platform visited, and it is
required to check the whole path of digital signatures carried by the agent.
State appraisal. The state appraisal mechanism is to detect, to a certain extent,
whether the current state of a MA, when arrived to a new site, is not harmfully altered.
The agent code producer and the user of the agent provide appraisal functions for the
state of the agent. This function is carried by the agent along with its code and state.
When an agent arrives a new host, it must decide what specific privileges it will need at
the host. The state appraisal function is used to compute a set of privileges to request as a
function of the current agent state. In turn, the authorization mechanism employed by the
agent platform determines which privileges requested by the agent it is willing to grant
and whether the agent is in a safe state (e.g., no harmful modifications have been made)
(Farmer et al., 1996). The authors indicate however that, it may not always be possible to
detect a deceptive state from a correct one.
Proof carrying code. This is a technique, which is used by the hosts to verify that
foreign code provided by an untrusted party adheres to a predefined set of rules, which is
known as safety policy. This policy is formed by the hosts to guarantee that the
downloaded or migrated foreign code, if complies with the policy, will be safe to execute.
Two components are used with the technique: a formal proof and a proof validator. The
code producer creates a formal safety proof, which expresses the fact that the code will
behave according to the safety policy. The code consumer host uses the proof validator,
to check whether the proof is valid and therefore the code is safe to execute (Lee &
Necula, 1997). The authors indicate that there are four necessary components for the
technique: 1. a formal specification language used to express the safety policy, 2. a
formal semantics of the language used by the untrusted code, 3. a language used to
express the proofs, and 4. an algorithm to validate the proofs. Although the approach is
theoretically sound, there might be practical difficulties in implementing and using the
approach including a standard formalism for establishing the safety policy, automated
assistance for generation of proofs, and techniques to limit the potentially large size of
proofs (Jansen, 2001). In addition, the technique is tied to the hardware and operating
environment, which is in conflict with the interoperability requirements of MA systems.
2.4.2 Malicious Hosts Problem
As we have pointed out above, protecting mobile agents from possibly malicious
hosts in open environments is one of the most difficult security problems in distributed
systems. This problem has even considered unsolvable without dedicated hardware. The
obvious reason for this is that an agent in under complete control of the host it is to run
on. Hohl (1998a) identified the specific threats to mobile agents:
* Spying out and/or manipulating code,
* Spying out and/or manipulating data,
* Spying out and/or manipulating control flow,
* Incorrect execution of code,
* Masquerading as a host,
* Denial of execution,
* Spying out and manipulation of interaction with other agents,
* Returning wrong results to system calls issued by an agent.
Hohl (1998b) also provided a set of requirements for an attack model against
mobile agents. He uses the Random Access Stored Program (RASP) machines to show
that the components of the execution process of an agent program can be accessed by an
attack program and this program can be executed by another machine (in the abstract
sense) to control the execution of the agent program.
There are several approaches proposed in the literature. Different classifications of
these approaches can be given. For example, some approaches are aimed only to detect
certain attacks whereas others try to prevent them. While some of the approaches are
more general, majority of the proposed solutions target specific threats. Although we do
not give a precise taxonomy, a classification and a brief description of the proposed
solutions are presented below.
Organizational or social trust. Most of the MA systems ignore security by the
assumption of organizational or social trust. For example, an individual user may have
trust to a reputable well-known company. Therefore he/she may not expect any hostile
behavior from the company that operates the MA system, against his/her agent. But this
cannot be applied to a virtually unknown company, and such an e-commerce MA system
may not be fair to businesses that have not yet established a public trust. On the other
hand, social trust does not apply to a business-to-business e-commerce system based on
MAs. For example two competing companies could not assume the same trust to one
another as in the individual user case, even if these were reputable companies. This
potential aspect of lack of trust could severely limit the use of MAs in an open e-
commerce environment. However, we believe that together with other technical security
mechanisms, this aspect will be helpful in providing better security for MAs.
Solutions based on obfuscation. Blackbox security is an obfuscation scheme,
which does not rely on cryptography. It defines the problem as to make an agent's code
and data be messed up so that cannot be read or modified at any time (Hohl, 1998a).
Because there is no known solution to the problem, the "at any time" requirement is
relaxed to "for some known time interval." The idea is to scramble code and data of an
agent so that they do not reveal the function of the code. The interesting aspect of this
proposal is that it does not rely on cryptography. There are some issues to be solved by
the approach such as necessity of synchronized clocks to be able to realize time
limitation. Code obfuscation is a well-known method and there are many examples
especially for Java. However, there are also tools to defeat known obfuscation methods
and this is an arms race as indicated in (Dyer, 1997).
Another approach for mobile agent protection relies on cipherprogram concept
(Sander & Tschudin, 1998). It is claimed that mobile agents do not have to rely on
cleartext data, program or messages. This, in turn, relies on computing with encrypted
functions and computing with encrypted data. Encrypted functions work as follows.
Suppose Alice has an algorithm to compute a functionfon data item x. Bob has the
computation power and would like to computeffor Alice. However Alice does not want
Bob to know anything about Iffcan be encrypted in a way that another function E(f)
can be computed by a program namely P(E()), then Alice sends this program to Bob,
after execution Bob sends the result back to Alice. Alice, in turn decrypt the result to
Although it is not claimed to be a general solution to agent protection and the
computation is limited to certain functions (e.g., polynomials), this approach is a good
example for a software-based solution based on cryptography. However, recently Barak
et al. (2001) have shown that this approach is not likely to succeed.
Tracing data state and execution. Partial Result Authentication Code (PRAC) has
been proposed by Yee (1999). The goal is the technique is to ensure forward integrity
using cryptographic checksums formed using symmetric cryptography similar to
Message Authentication Codes (MAC). Forward integrity means that results of the
previously visited hosts should not be able to be forged by a malicious host subsequently
visited. The technique requires maintaining or generating keys for every host visited, with
the assumption that the hosts will destroy the keys after the computation is complete.
This raises concerns especially if the agent needs to revisits a previous host. PRACs are
aimed to provide integrity rather than confidentiality. Karjoth et al. (1998) improved the
technique using digital signatures to create a chain of results obtained from the hosts
Young and Yung (1997) proposed the sliding encryption technique to deal with the
small size data usually obtained from hosts by mobile agents when compared to the size
of the encryption keys and resulting ciphertext. The technique is to ensure confidentiality
with public key cryptography accumulating the encrypted data in each platform visited.
Another approach is called cryptographic traces (Vigna, 1998), which aims at
detecting any kind of tampering with a mobile agent. It relies on code execution
verification using traces based on cryptography. This technique requires each host visited
by a mobile agent to create a trace of the execution of agent. This trace is both maintained
in the host and forwarded to the other hosts subsequently visited by the agent. The major
concern is the size of the trace, which needs to be carried with the agents. This is another
unauthorized modification detection technique.
Hardware-based solutions. Hardware support is recognized as the only tractable
solution since no single software solution proposed so far addresses every possible attack.
One example is the Tamper-proof Environment (Wilhelm et al., 1998), which is a regular
computer with some specialized OS, manufactured only by authorized well-known
parties. Sites that offer services to mobile agents purchase these computers and advertise
this. In turn agents execute only in these isolated places by interacting with the hosts on
those sites by well-defined secure interfaces. However it might still possible to devise
some attacks and the solution does not seem feasible because of its special requirements.
A similar approach has also been taken by Yee using secure coprocessors (Yee, 1999).
Environmental key generation. Environmental Key Generation approach
(Riordan & Schneier, 1998) relies on some interesting observation that agents can find
some keys whose protection is crucial only after they are on the host on which they will
execute. A key can be sent to an environment such as a news list or a mailbox. The idea
is to not carry the keys but to know how to find them. After agents find their keys in this
manner they can do their jobs with some protection. An interesting example is given as a
search agent that needs to search remote databases without revealing what it looks for.
The solution is nothing more than using a cryptographic hash function that is applied to
the items in the database and checking the results against the already hashed value carried
with the agent. Because it is still vulnerable to denial-of-service attacks by changing the
value carried by agent this approach should be used together with some other solution to
prevent the kind of attacks mentioned.
Multiple (cooperating) agents. The idea of using more than a single agent for
fault-tolerance and security has also been studied by some authors. However this
approach has not been attracted deserved attention. Since the theme of this dissertation is
in this category, we provide related previous work in Chapter 3 in more detail.
Other approaches. Another approach protects the computation of agents by
relying on trusted third parties (Corradi et al., 1999): some sites that offer a trusted
environment for mobile agents to perform secure operations. Agents need to visit such a
site after computing in some untrusted host. Another example (Marques et al., 1999)
assumes a "neutral trusted" host for e-commerce applications. But it is not clear in these
proposals, why and how untrusted hosts guarantee to send the agents to so-called trusted
servers to compute with secrets.
Meadows (1997) proposed the detecting objects idea, which is originally proposed
for database integrity against unauthorized modification. In this scheme, some dummy
objects are inserted into the mobile agents. For example, a shopping agent can be
provided by some dummy offers as if they were coming from legitimate merchants. By
carefully selecting these objects, the owner platform can check the agent whether these
dummy objects have been tampered with. If there is no modification to these dummy
objects, then with some degree of confidence it can be said that there have been no
modifications to the other parts of the agents. However, this scheme is highly application
specific. We extended the idea to detection objects and code (Onbilger et al., 2001). In
this scheme, some dummy code fragments can be inserted into the agent code together
with dummy objects. Depending on the degree of protection desired, dense of injection
can vary for different applications. Since, it is intractable to distinguish dummy code
fragments from the original ones, execution results of the dummy code can be checked
against previously recorded results and it can be detected whether the code is executed
correctly. By combining the technique with multiple cooperating agents, detection can be
made immediate, without requiring the agent to return to the originating platform.
General discussion and survey papers for mobile agent security are given by
Tschudin (1999), Jansen (2001), Claessens et al. (2003), and Oppliger (1999). Some
flaws in the security protocols, which have been proposed before and summarized above
are identified by Roth (2001).
MULTIPLE COOPERATING MOBILE AGENTS
Information Dispersal is a technique used for fault- and intrusion-tolerance of
information. The study in this area consists of three phases. In the first phase, Shamir
(1979) showed how to construct a robust key management scheme for cryptographic
systems. In this scheme, a secret S is divided into n pieces in such a way that S can easily
be constructed from any of the k pieces, but the knowledge of k-1 or fewer pieces reveals
no information about the secret S. This is called a (k, n) threshold scheme. The
remarkable aspect of the scheme is that k-1 pieces give no information about S, so it is
applicable to relatively small data such as secrets. However, this scheme is not space
efficient, consequently it is not suitable for large data such as a file. Rabin (1989) showed
how to disperse a file into pieces and to use a subset of pieces to reconstruct the file later,
in a space efficient manner. In this scheme, a file F of length L is divided into k pieces
each of length L/m. The file can be reconstructed from any m pieces. The sum of the
lengths of pieces is L(k/m). Because k/m can be chosen to be close to 1, the scheme is
The second phase includes the techniques of Fragmented Data Processing (FDP)
(Fray & Fabre, 1991) and Fragmentation-Redundancy-Scattering (FRS) (Fabre et al.,
1994). The common goal in this phase, in addition to the concept of information dispersal
for security in the first phase, is the processing of sensitive information. FDP is designed
to employ parallel processing techniques to process fragmented and scattered pieces of
data. Sensitive information (both code and data) is fragmented into pieces in the trusted
part of a distributed system and the pieces are located on hosts in the untrusted part of the
system. The code fragments are constructed using a pre-processor and compiler so that
when collaboratively applied by the hosts on the corresponding pieces, the result
becomes exactly the same with the result of the original code applied to the original data.
Similarly, the goal of the FRS is to employ several hosts to provide fault-tolerance
of the systems and intrusion-tolerance against deliberate faults. The fragmentation
process may consist of several iterations. At each iteration, application objects, which
consist of both code and data are decomposed into more elementary objects if there is
still identifiable confidential information exists. Redundancy is achieved by either
applying techniques such as checkpointing and synchronization or relying on detection
mechanisms and voting protocols implemented over underlying multicast communication
system. Scattering phase consists of assigning the fragmented and redundant elementary
objects to the hosts in the system. The goal is to assign the elementary objects in such a
way that the objects that are assigned to the same host would not reveal any confidential
We consider our work as part of the third phase in this field. There are however
important differences between the third phase and the former ones. FRS and FDP utilize
a distributed static infrastructure to provide tolerance. In our case the target environment
is already distributed and extremely dynamic. The assumption with those techniques that
there are fixed available hosts in a close environment does not hold for the MA problem.
FRS merely relies on a spatial technique (replication) but we need to consider both spatial
and temporal solutions for efficiency. Also, in addition to Shamir and Rabin's work we
also need mechanisms not only to distribute the secrets but also to be able to compute
with them again in a distributed fashion. These differences inevitably add new challenges
to the known problems and solutions.
3.2 Requirements and Objectives
There are mainly four requirements to meet in providing security to mobile agents
as mentioned in Chapter 1. The first one is that a solution proposed to protect hosts from
possibly malicious hosts should not jeopardize the protection of hosts from agents. Some
proposed solutions such as obfuscation mechanisms might not be feasible since they may
cause hosts to be vulnerable to attacks by hostile mobile agents. The second important
requirement is that solutions should not limit the potential benefits of mobile agents,
which are otherwise observed and enjoyed. While security is an important requirement
for the mobile agent technology to be accepted and widely used, it should not sacrifice
the benefits we gain from using them. One such property that is usually ignored by the
proposed solutions is the autonomy of mobile agents. Since it is one of the distinguished
features of them, sacrificing autonomy would severely limit the their applicability to the
wide range of possible applications. For example, an MA may be required to
communicate with its owner's host to perform some security sensitive operations. This
violates the autonomy property of the agents, which constitute the basis of disconnected
operation, which is a highly desirable mode of functioning in m-commerce. Another
example is to allow mobile agents to execute only on trusted hosts and then limit the use
of mobile agents into the client/server model to access the untrusted hosts. While this
model provides security it sacrifice the benefit of customizing the computations on
servers, which is another important feature of mobile agents. The third one is related to
one of the fundamental principles of security: when there are easier ways of defeating a
system, an attacker would not try to penetrate to the system through well-protected
components. So, it is vital to address easier attacks against mobile agents, which are
denial-of-service and replay. The last requirement is extending the network trusted
computing base concept. This concept has been proposed as a solution without giving
clues about how they could be realized. Simply assigning some dedicated hosts for this
purpose does not seem practical. At least, these hosts could be single points of failure and
targets of attacks. Moreover, locations of these hosts should also be considered.
Under the requirements given above, the goal is to make individual MAs
"meaningless" when they are treated as a single entity as much as possible since there is a
trade-off between openness and security. This makes them resistant against malicious
behavior of the hosts where they execute. A given task is split up into two or more MAs.
These MAs are located in different hosts and migrate when necessary. They exchange
information and partial results of execution at certain synchronization points. So, the
approach presented here is based on information (data and code) dispersal supported by
known cryptographic techniques.
In a mobile agent system there are three general security objectives:
1. Data confidentiality,
2. Correct code execution and data integrity,
3. Code confidentiality.
Data confidentiality is the easiest-to-achieve goal in our approach especially if the
data needs to be kept confidential from certain hosts that possibly could gain advantage
from knowing it. It is possible to place sensitive information (i.e., credit card) in an agent
encrypted with a nonce and place the nonce in a cooperating agent. Other more complex
means are also possible.
Data integrity can be achieved through the idea of detection objects, which has
been proposed by Meadows (1997) to detect possible modifications to MA data. Correct
code execution along with data integrity can be provided by extending the detection
objects idea and introducing detection code. Predetermined but random code fragments
are injected into the original code of the agent (possibly by also introducing dummy
data). These code fragments can be produced by a tool and the modified program can be
guaranteed to give the exact same result as the original when executed. At certain
synchronization points, agents exchange the results of the modified program together
with the results of the original program. Since the dummy code results have to be fixed,
another agent can easily check them against the precalculated values. Together with
realizing time limitations and dense injection (i.e., one line of dummy code for every
original line) it can be guaranteed that the original code was executed correctly.
Although a human can detect which portions of code are dummy by analyzing the
code, it is an undecidable problem for machines especially if data flow analysis is
prevented by mixing the data flow from the original code to the dummy code (e.g.,
y=y*x; z=y; z=z/x; y=z; y and z are dummy, x is not). Since the concern here is instant
correct execution of code and time for that execution can be limited to a few seconds, an
analysis by an human is prohibited. The approach presented is equivalent to randomized
state information that could be maintained and exchanged among agents.
Code confidentiality is the most difficult of these problems. The difficulty of the
problem comes from the fact that it is not possible to limit the time for analysis; therefore
human analysis attacks are possible. Due to the difficulty of the problem, one might
restrict the confidentiality of code into certain decision functions (e.g., a shopping agent's
purchase decision) and apply the code injection technique to those functions before
splitting. In addition to arbitrary code generated by a tool randomly, other mechanisms
can be applied. For example, code can be generated which consists of similar statements
to the original code. Also, code libraries can be used to provide code that implements
some relevant or irrelevant function to the original function.
The three goals above are the generalization of broad range of diverse security
requirements of the MAs. There are certain situations where combinations of the three
goals above overlap. One such requirement in a mobile e-commerce environment is
computing with secrets in an untrusted environment. Any such secret (e.g., a private key)
cannot be revealed to any third party since the information here is more sensitive. For
example, people reveal their credit card information to buy lunch but not their social
security number (even if asked). So, it is crucial to have the ability not only to keep
certain data secret but also to compute with that data. Digital contract signing (Sander &
Tschudin, 1998) is such an example and Chapter 4 demonstrates how to do this
computation remotely by a group of agents without divulging secrets or inventing new
The problem of protecting MAs against malicious hosts comes from the fact that
they are, by definition, autonomous. Since this aspect of MAs is the most important
among others and actually it is what make them special, it would not be a good idea to
give it up for the sake of making them secure. But if we define "autonomy" not for a
single MA but a group of communicating and cooperating MAs, which rely only on each
other to perform a single task to achieve a goal, we will be able to reach autonomous
secure MA groups.
Definition. Autonomous MMAs. A group of mobile agents is said to be autonomous
if they together have the knowledge necessary to perform a single task, and they
communicate and cooperate to perform that well-defined task.
What follows is the definition of the mission concept.
Definition. Mission (traditional single mobile agent case). A mission consists of a
mobile agent, a set of hosts to be visited, execution of the agent's code on these hosts and
the set of migrations of the agent between any pair of these hosts.
Definition. Mission (multiple mobile agents case). A mission consists of an
autonomous group of mobile agents, a set of hosts to be visited, execution of the agents'
code on these hosts, a set of migrations of the agents between any pair of these hosts and
communication among the agents.
The term mission is the counterpart of the term session in client/server computing.
A mission can represent any session that carries out a computation such as a database
search, a network management activity or an e-commerce task, etc., using MAs.
3.4 Mission Models
Single mobile agent model. This basic model is illustrated in Figure 2-1 in
Chapter 2. The mission must be accomplished by visiting several hosts, which requires
process migration from host to host. The agent computes (e.g., is being executed) in these
hosts and returns home at the end of a successful mission in this case. Note that the
illustration in Figure 2-1 is a simplified generic case of a mission. It may not be necessary
for a mobile agent to return home and a same host might be visited multiple times in the
Mobile client/server model. Depending on the mission given, one or more of the
following reasons might prevent placing an agent on a service provider host:
* The server may not have a mobile agent platform,
* The mobile agent platform supported might be a different one,
* The host may not be trusted or may not provide any measure to appraise trust on.
Therefore in this model the mobile agent is located on a host, which provides the
necessary environment and is close to the target host. The model is illustrated in Figure 3-
Host IAgent [Agent Host
Agent Owner's Host
Figure 3-1. Mobile client/server model
This model is not suitable for applications where it is necessary to customize
certain server functionality. If the model is used for security purposes, it will not meet the
second requirement mentioned in Chapter 1.
Multiple mobile agents model. The multi-agent paradigm fits well with the
concept of protection of an application as a whole. It is more difficult to compromise a
task if the task is split into multiple collaborating agents. In the context of data secrecy,
this is also referred to as information dispersal for security.
The multi-agent model does not differ from the classical agent model in terms of
the definition of the mission. The difference is due to the definition of the autonomy
property of MAs. So, in the new model, MAs are autonomous as a group but not as an
individual entity. The group of agents carries out a single task by communicating and
Figure 3-2 illustrates the model. In the model, we call one of the agents the master
agent (Alice in the figure), who actually visits the set of hosts that are necessary to
complete the mission. This set of hosts is called the itinerary of the mission. The itinerary
may or may not specify the order of the hosts to be visited. The other agents are called
support agents (Bob in the figure), who visit only the hosts outside of the itinerary of the
master agent. Note that, the model that we describe here is the most generic multi-agent
1 Alice -- I Alice
Agent Owner's Host
S3. ti ob
I *.....* communication G l-
Agent Owner s Host
Figure 3-2. Multiple mobile agents model with two mobile agents
Variations of the model admit more than one master agent, or alternatively, a peer-
to-peer architecture can be employed. In the figure, Alice and Bob, migrate according to
their itineraries and communicate with each other.
As it is clear, the migration of an agent or agents in a group is more complicated in
this model and requires support from an underlying system that is aware of the
underlying network topology. This issue is addressed in Chapters 5 and 6.
3.5 Multi-agent Systems (MAS) vs. Multiple Mobile Agent Systems (MMAS)
In Chapter 2, we have defined multi-agent systems and said that multiple mobile
agent systems differ from those. Following table highlights the differences between the
Table 3-1. Comparison of MAS and MMAS
Property Multi-agent Systems Mbile Agent
Interactions Not pre-defined Pre-defined
Global system goal Not exist Exist
Autonomy w.r.t. goal Yes No
Single owner No Yes
Main goal Easy, efficient, intelligent Combine MAS and MA
and distributed problem Paradigm
solving MA Protection
However, it should be noted that the above properties of multiple cooperating
agents are internal to their group. There is nothing to prevent a group of multiple
cooperating agents from participating in any multi-agent system. So, from a broader point
of view multiple cooperating agents can perfectly become a part of any multi-agent
3.6 Proposed Architecture for MMASs
In this Section we present the proposed system architecture of MMASs. We will
explain the architecture by providing the step-by-step workflow of the system as
illustrated in Figure 3-3.
On the host side we show the components/modules of an MMAS. Note that, the
Mission Planer, Mission Optimizer, Security, and the Context components can be
interpreted and implemented as part of the MMAS. However, we show them as separate
components in the figure for the sake of clarity.
On the network side the double-line boxes represent systems rather than modules.
These systems, except the Directory (a.k.a. Yellow Pages) system are distributed systems.
The network positioning system is a peer-to-peer distributed system, which provides
relative positions of the participating hosts via coordinates in a geometric system. The
proposed architecture for this system is given in Chapter 5. The DNS is the Domain
Name System. The anticipated role of the DNS will be clear in Chapter 5. The Directory
system can be either a centralized or a distributed system. Although it is not addressed in
this dissertation, we believe that it needs to be a distributed system. The primary
responsibility of this system is to maintain and provide the information about the hosts,
which employ a MA System and the services provided. The workflow and the
responsibilities of the components in the architecture are given below.
-- --- 0 ------I------ -
Directory [= Network Positioning t N
Figure 3-3. Multiple mobile agent system architecture
Step 1: The Application receives the information from the user through the User
Interface. Two example applications are provided in the next Section.
Step 2: The Application presents the information to the Multiple Mobile Agent
Steps 3 & 4: The MMAS gives the related information to the Security module.
This module is responsible for determining the security level required for this instance of
the Application and deciding the number of agents and the necessary communication
among them. The module returns this information to the MMAS. Note that, apart from
the workflow presented, the MMAS and the Security modules can interact to create the
group of mobile agents necessary for the mission by observing the necessary dispersal of
information, code and data, at the later steps in the workflow.
Step 5: MMAS presents the information provided by the Application and the
Security module to the Mission Planner. This module is responsible for planning the
mission by coordinating the other support modules.
Steps 6 & 7: The Planner module first asks the Context module for information
about where and how this particular instance of the application could take place as a
mission. The context module in turn communicates with the Directory service to obtain
contextual and network/topology information.
Steps 8 & 9: The mission planner receives the contextual information.
Steps 10 & 11: The planner then asks the Mission Optimizer to compute the best
possible itineraries for each agent by taking into account their interactions during the
mission, in terms of the total execution time of the mission.
Step 12: The planner presents the optimized mission information to the MMAS.
Step 13: MMAS using all the information provided by the modules creates the
mobile agents to accomplish the mission and passes the agents to the MA System. Any
existing MA System can be used here, however one might expect some modifications on
the existing system for integration/interoperation of the MMAS and the MA System.
Steps 14 & 15: The MA System, just as in the single mobile agent applications
send out the agents to the network. Mobile agents) return to the MA System with the
Steps 16, 17 & 18: The result of the mission is presented to the user.
Following chapters of this dissertation deals with the research issues of Security,
Mission Optimizer and Context components as well as the Network Positioning System.
More precisely, Chapter 4 is related with the Security component. Chapter 6 addresses
the issues with the Mission Optimizer component and also makes it clear how context-
awareness is an important concept in MMASs and their security. Some issues with the
Context component and a proposed architecture for a network positioning system are
given in Chapter 5.
Due to the lack of the Directory component, which is out of scope of this study, we
assume its existence, however we make no assumptions about the use of contextual
concepts. The TPNP system (Chapter 5) is capable of providing this information as a
peer-to-peer system. A directory system will only need to cooperate with the TPNP to
obtain contextual (including location) information.
3.7 Example Missions
In this Section we present two real-world examples of multiple mobile agent
applications based on the system architecture given in the previous Section.
Example 1. sayingg Agent. The shopping agent is a classical example of mobile
agent applications in e-commerce (See Chapter 2). The job of the agent or the group of
agents is to visit on-line merchants of the product of interest, negotiate and finally
purchase the product by making the payment. We assume that the user would like to
The user presents the details of preferences for this purchase (e.g., a dozen red
roses, under $10, with a gift card) to the shopping agent applications using the user-
interface provided by this application. The user either indicates the security requirements
specific for this mission or the application uses a preference file to use default or existing
set of requirements for this kind of missions. The application passes this information to
the MMAS possibly in XML format. MMAS consults the Security module to determine
the mechanisms needed to apply to be able to meet the security requirements of the user.
For example, the purchase may require a digital signature to be generated and presented
to the merchant, which is the subject of Chapter 4. We assume that the Security module
decides to use a master/support model with two agents; Alice and Bob from Section 3.4.
MMAS passes all the information about the mission to the Mission Planner.
The planner needs first the context information, which consists of the potential
merchant hosts to be visited by Alice, the set of hosts of which a subset would form
Bob's itinerary, their trustworthiness and locations. This is the job of the Context module
in the architecture and this module contacts the Directory system for this purpose. The
directory system executes a query given the input as the transaction of purchasing flowers
from potential merchants. The result of the query appears to be a list of merchant hosts on
the Internet. This part is exactly the same as of the classical single mobile agent
applications. The directory service will also provide additional information about these
hosts. This information needs to be the level of security provided by these hosts, the hosts
that Bob will be visiting, the level of security provided by these support hosts and
location information of all the hosts. The network positioning system, TPNP is capable of
providing all these information, which is the subject of Chapter 5.
The directory system returns the information about merchants and potential support
hosts to the Context module. The mission planner at this point has two issues to consider,
which are to find best possible itinerary for Alice to visit merchants and the selection a
subset of hosts returned by the Context module for Bob. The mission planner may consult
the user for choice of possible merchants or may use a file to determine the preferred
merchants. The planner then consult the Mission Optimizer module to provide the order
of hosts to be visited to make the mission as short as possible. In addition, the mission
optimizer is responsible for choosing the closest support agent hosts to a subset of
merchant hosts. The result of this selection is the itinerary of Bob including the order of
hosts. This is the subject of Chapter 6. When the mission planner returns its decisions, the
MMAS is ready to create the agents for the flower mission and then pass them to the MA
system to be forwarded to the network.
Example 2. Software Distribution. Our second example is from a relatively new
application area of mobile agent technology. The scenario is as follows. A software
vendor has a product running on their customer sites around the world. The company
continuously improves its products and provides updated versions to the customers. They
also need to provide their customers with software patches for newly found security flaws
in their products.
The company figures out that mobile agent technology is a viable alternative for
this problem, that is using a push model with mobile agents is rather powerful than the
pull model in client-server computing. They also know that security is still a drawback of
mobile agent technology. But they also are aware that a group of cooperating multiple
agents provide the level of security they need. So, they develop a multiple mobile agent
system following the architecture presented in the previous section and ship the MA
execution environment part of this product to their customer sites along with their
When a new security patch is ready to be installed for a recently discovered flaw in
their application software, they launch agents to the Internet to update their customer
systems. They organize their software in well-designed small modules so that when they
need to update some module, their agents will only carry that small module as the
We will not repeat the whole process for this application but we will provide only
the differences from the previous example. In software distribution, the number of sites to
be visited are expected to be much larger than the e-commerce applications. So, several
agents or group of agents may need to be deployed according to their locations. Since the
customers are well known by the company, the directory system's main responsibility of
providing host information is not useful. However, context and network information is
still quite important.
This application may use the master/support agent model as well as the peer-to-
peer model. The former may be preferred for small number of customer sites. The latter
is more suitable when the number of sites is large. In this case, agents need to act both as
a master agent to do the primary job of software distribution and checking the integrity of
peers for security. The alternative is to use the former model with multiple master agents,
and make the support agent responsible for checking all of them.
We assume that the security component decides to use a master/support agent
model with two agents, Alice and Bob. The software module to be installed is split up by
the MMAS with the help from security and mission optimizer components. Security
component makes sure that the payload of either agent would not reveal essential
information about the module. Mission optimizer's responsibility is to balance the load of
agents so that the cost of the mission will be minimized in terms of agent migration and
Both Alice and Bob have the credentials to check the integrity of the payload of
each other. On every host Alice visits, she contacts Bob and sends the payload integrity
check to Bob. Bob verifies the code as well as the identification of host on which Alice is
running. If all checks are successful, Bob sends Alice the part of patch he is carrying.
Alice after checking the Bob's information installs the new module in the customer
system and migrates to the new site in her itinerary. Bob, if necessary also migrates to the
next host in his itinerary. Neither agent in this application needs to return home after the
3.8 Related Work
Multiple agents have first been used by Minsky et al. (1996) for fault-tolerant
distributed computing with MAs. The proposed scheme is deploying clones of an MA to
identical servers at each stage of the computation and then comparing the results. In this
scheme MAs do not communicate or cooperate. The assumptions that the identical
servers would be available and that they would be under different administration
domains, so that they would behave independently, are not realistic.
Yee (1999) proposed a fault-tolerant approach, where replicated agents are sent to
the same set of hosts to figure out airfare prices for a flight ticket purchase. Agents
traverse the hosts in the reverse order and at the end the minimum prices they come up
with are checked. In the one malicious server case it is possible to find out the actual best
price. This is one of the earliest proposals using multiple mobile agents which is
application and case specific.
Ng (2000) used multiple agents for security purposes. In this scheme, again the
agents do not cooperate; instead the task is split into multiple agents so that any agent
alone would not reveal any useful information. In contrast to the multiple agent model we
use, agents in this scheme visits the same hosts, therefore they need to be completely
anonymous to be able to defeat attacks.
Cooperating multiple agents have been first used by Roth (1998). It is shown that
two cooperating agents, under certain assumptions, can verify the path each agent takes
and whether the migration patterns adhere to the itinerary of the agents.
REMOTE DIGITAL SIGNING WITH MOBILE AGENTS
Although the MA paradigm opens many interesting applications, to validate it as an
alternative to traditional client/server computing, one must address its security issues. In
particular, it should demonstrate the ability to compute with secrets in remote public
domains. A good example of the need for this is digitally signing a contract for m-
commerce (and in general e-commerce) applications with MAs as shown by Sander and
Tschudin (1998). We call this problem remote digital signing. In this chapter, a multi-
agent architecture is used and a solution to this problem is presented. The techniques we
explore and analyze are based on information dispersal in distributed system security
terms as well as multisignatures and secret splitting in cryptographic terms. The idea is to
devise a secure way of sharing secret keys among members of a multi-agent group and
signing with shares.
4.2 Electronic Commerce and Mobile Agents
Among many application areas of MAs (such as information retrieval, e-commerce,
network management, network/site security, distance education, and software
distribution) e-commerce draws the most attention from both academic and industrial
researchers, for example see Busch et al. (1998) and Klusch (1999). This is mostly due to
the fact that, MAs and in general agent systems have the capability of representing users
(i.e., customers) in the cyberspace. Agents can effectively profile user preferences, act on
behalf their owners, participate in e-auctions, watch stock prices, search for commodities
and find the best offer from competing vendors, purchase goods by paying and
committing to transactions, communicate and cooperate with other agents of relevant
goals. Although it is now agreed that MAs are not a new enabling technology, they offer
many technical capabilities together (i.e., all-in-one) over the traditional client/server
computing (Chess et al. 1995a; Chess et al. 1995b; Lange & Oshima 1998). Mobile
commerce (m-commerce), which is a rapidly growing field in e-commerce, is especially a
suitable application area of MAs.
4.3 Mobile Commerce and Mobile Agents
Mobility of agents brings unique advantages to m-commerce. Mobile devices such
as PDAs and laptop computers have limited battery life, intermittent and low-bandwidth
connections to the fixed network. Traditional client/server computing which was
originally designed for and very well fit into the fixed wireline networks is not suitable
for m-commerce due to these limitations. MA paradigm enables disconnected operation
(Chess et al., 1995a; Gray et al., 1996), where a brief connection to the fixed network
from a mobile device through the wireless network is sufficient to launch an MA (or
MAs) to engage in a mobile commerce activity. For example, a laptop owner, which has
a wireless connection to the Internet, through a cell phone, may launch an agent to search
for the best offer for an airline ticket and make a purchase. While the agent working
towards the goal of purchase, the owner can (or may be forced to) disconnect from the
network. When the MA accomplishes the goal, it takes another brief connection to
receive the agent with the results.
4.4 Mobile Agent Security in Mobile Commerce
There are two aspects of the security issues in MA technology which are known as
the malicious agents problem and the malicious hosts problem. In the former case, the
hosts that are to accept and execute the agents should be protected against any possible
hostile behavior of agents. There are known mechanisms such as sandboxes proposed and
implemented. The latter case is considered to be much more challenging due to the
remote nature of the platforms where the MAs are to be run. Since these platforms are
owned and operated by other parties, it is difficult to establish trust. Classical security
mechanisms designed for distributed systems, including the cryptographic ones come
short for threats against the MAs due to the assumptions, which do not hold for MAs
(Chess, 1998). So, protection mechanisms are needed to make MAs safe in possibly
E-commerce is the most security demanding application of the MA paradigm. This
is not different for m-commerce, which is a special case of the broader topic of e-
commerce. In fact, it can be argued that if all the security requirements of e-commerce
applications are met, then the general MA security problem is solved altogether. The
shopping agent application where a MA is deployed to find the best possible price for
some good such as an airline ticket, flowers or CDs, and make a purchase, has become
the classical problem for discussing the requirements of MA security and proposing
solutions to certain aspects of the requirements (see for example, Berkowitz et al. (1998),
Hohl (1998), and (Yee 1999)). Hohl (1998) provides an extensive list of attacks using a
shopping agent application example that could be launched against an agent.
The focus of this chapter is the remote digital signing problem for shopping agents.
In any trade, principals engaged in the activity need to authenticate each other. A
merchant would like to know whether the credit card presented by the buyer really does
belong to the party or whether a check provided is legitimate and authentic. Customers
would like to make sure they present their confidential information such as a credit card
to the merchant of their choice, but not anybody else. Similarly, merchants need to
authenticate the MAs and their owners. This is necessary to prevent repudiation, which
could be a very simple attack to devise using MAs. Even honest users may change their
minds well after the transaction took place and deny that they didn't send any MAs to
buy any such product. On the other hand, a hostile MA could masquerade a legitimate
MA and hence its owner, to engage in fake trading to harm either or both of the principals
of the transaction. Therefore a MA should be capable of digitally signing a contract
agreed on by both parties to authenticate themselves and their owners, remotely and
publicly, meaning that on the hosts they execute.
Our objective in general, is to meet the requirements of solutions proposed for any
aspect of MA security problem. These requirements were identified in Chapter 1.
Our specific goals in this chapter are to achieve a solution to the remote digital
signing problem which should be as simple, realistic, flexible and ubiquitous as possible.
With simplicity, we mean that the solution will be easy to understand and implement. By
the use of already established and standardized digital signature schemes, such as RSA
and El Gamal algorithms, if the original signing and verification functions can be used
then specific implementation may not even be needed for our problem. To be realistic, it
is meant that a proposed solution should fit into the real world environments, where they
are to be used. For example, in theory, threshold signature schemes seem to fit very well
in the MA paradigm when a multi-agent model is used. However, in practice it is
necessary to identify the hosts where these MAs are going to be executed. The number
and location of these hosts are to be restrictive as explained in detail later. Flexibility is
related to the autonomy of MAs from another perspective. Unlike some other solutions
proposed, it is important to distinguish what can be done (i.e., signed) by a MA and what
actually has been accomplished. Ubiquity is again related with the cryptographic
functions used. Widely implemented cryptographic signature schemes improve the
scalability in terms of number of hosts where MAs may need to find and use these
Multiple agents have first been used by Minsky et al. (1996) for fault-tolerant
distributed computing with MAs. The proposed scheme is deploying clones of an MA to
identical servers at each stage of the computation and then comparing the results. In this
scheme MAs do not communicate or cooperate. The assumptions that the identical
servers would be available and that they would be under different administration
domains, so that they would behave independently, are not realistic. Ng (2000) used
multiple agents for security purposes. In this scheme, again the agents do not cooperate;
instead the task is split into multiple agents so that any agent alone would not reveal any
useful information. In contrast to the multiple agent model we use, agents in this scheme
visit the same hosts, therefore they need to be completely anonymous to be able to defeat
attacks. Cooperating multiple agents have been first used by Roth (1998). It is shown that
two cooperating agents, under certain assumptions, can verify the path each agent takes
and whether the migration patterns adhere to the itinerary of the agents.
Sander and Tschudin (1998) introduced the concept of Mobile Cryptography. The
idea is to encrypt agents as a whole and apply computing with encrypted functions and
data. Although it is limited to polynomial and rational functions, this is a good example
of a software solution to the MA security problem that is based solely on cryptography.
In the same paper they also introduced the concept of "undetachable digital signatures,"
which is based on the concept of computing with encrypted functions. They point out that
this is a possible realization of "... an agent would like to use the secret in public e.g., to
compute the digital signature of an order form but without disclosing the secret needed to
do so." In this approach, user constraints are "glued" together with the general purpose
signature function to enforce them to be a part of the signed contract; hence the term
"undetachable signatures." Nevertheless, they also point out that the scheme on which
their proposal is based has been successfully attacked.
Kotzanikolaou et al. (2000) proposed a solution to the problem introduced by
Sander and Tschudin (1998). They use RSA (Rivest et al., 1978), which is based on
exponential functions rather than rational functions. However, as the term "undetachable
digital signatures" implies, the solution given by Kotzanikolaou et al. (2000) requires that
the signature be generated by the user (i.e., owner of the agent) and given to the agent
before the mission takes place. This contradicts MA autonomy. This is due to the fact that
the purchase decision has to be made strictly before negotiation with the sellers. User
constraints, which have to be signed before these negotiations, therefore need to be pure
data. However, it is desirable that a decision function be executed after or during the
negotiation or bargaining process. This means that agents should be capable of deciding
what to buy, where to buy, under what conditions, price, type of payment, delivery
options, etc. For example, the user demand should be able to be stated as flexibly as
possible with "I would like to purchase as many blank rewritable CDs as possible and
I've got $100." The result of the decision function will have a direct effect of the contract
to be signed. Therefore what we need is to make the agents capable of computing with
secrets in public as the quoted sentence in the previous paragraph implies. Without this
capability, either the user must have a perfect knowledge of market conditions that might
change rapidly, or user interaction during the mission is necessary. In the former case it is
highly possible that the mission may fail, in the latter, autonomy is sacrificed. The
problem arises from the fact that a malicious host should not be able to manipulate or
directly use the agent in order to sign "arbitrary" documents. On the other hand, agents
should also be capable of preparing the documents to be signed. The challenge is to
resolve this contradiction.
A threshold signature scheme in conjunction with the use of multiple agents and an
undetachable threshold signature scheme, which combines undetachable signatures with
threshold signature schemes, have been proposed (see Borselius et al. (2001) and further
references). While the former is vulnerable to attacks when used alone the latter still
carries the concerns with threshold signatures.
First concern is that threshold signature schemes come in great variety. They are
neither standardized nor widely accepted. This means that MAs may face problems in
finding the hosts to execute, which would have standardized implementations of these
schemes. The second concern is threshold signature schemes tacitly assume that there
would be sufficient number of shareholders to sign a document. Even small values of this
"sufficient number" may not be feasible for MAs since in practice, existence of hosts for
MAs to execute on, finding those hosts and location of them in the underlying network
are problems as will be explained later. So, threshold schemes are reduced to
multisignature schemes by these restrictions. Nevertheless, their complexity remains.
4.7 Multiple Cryptography
Multiple cryptography, as the name implies, covers the cryptosystems that deal
with more than two parties as opposed to the classical cryptography where there are only
two parties: the one who encrypts or signs and the other who decrypts or verifies. In fact,
there are many real-world applications that have multiple parties involved. For example,
in a banking application, electronic fund transfers require approvals of bank officials of
different ranks. Usually, at least two people are involved for a single transaction.
Ironically, this is such an application that, in the digital world, a more realistic abstraction
of the real world than the real world itself may be possible. Using the same example, a
bank cannot have a signature. Only people who work for the bank have signatures, and
they sign on behalf of the bank. But with multiple cryptography, it is possible to assign a
key to the bank, and shares of this key with the individuals who work for the bank. When
these officials sign a document like a check, the signature they generate perfectly
represents the bank itself, but not the individuals who really signed the document. So as
the example implies, it is possible, with multiple cryptography not only to share the
secrets but also compute with them without regenerating the secrets.
Our focus in this chapter is on multiple digital signatures or multisignatures, which
are a special case of multiple cryptography. The term refers to digital signature schemes,
which enable multiple parties to sign documents or messages cooperatively but
independently of each other using keys or shares of a key generated for this purpose.
Boyd (1988) shows the generalization of RSA and use it as a multisignature scheme. A
brief explanation of Boyd's work, which is related to our application, will be given later.
Multiple cryptography, in general, is intended for classical applications (e.g., a
banking application). In these applications, shareholders are usually individuals who
represent an organization or a company. There is an important distinction between these
applications and the MA applications. MAs are nothing but software entities. They are
neither organizations nor individuals. Moreover, they are owned by individuals or
organizations. In fact, it can be argued that, the MA owner and a bank have some kind of
resemblance. So, the officials of the bank and the MA perform similar operations when
signing a document. While this is not wrong, the actual difference comes from the fact
that, MA owners are active players, while organizations or companies like a bank are not.
A bank is actually an abstraction and cannot for example sign a document. But in the case
of a human MA owner, this individual can equally sign documents him/herself Also, the
shareholders do not always exist. They are created when necessary and after they
complete their work they cease to exist.
In addition to the threshold schemes like Shamir's (1979), techniques which are
known as threshold cryptography for the purpose of not only sharing keys but also being
able to compute with them without a central authority, have been proposed. A survey of
research in this area was provided by Desmedt (1997). A threshold multisignature
scheme has been given by Frankel and Desmedt (1992). In this scheme, authors combine
RSA signature scheme by Rivest et al. (1978) together with Shamir's (1979) threshold
scheme to distribute and to sign documents with shares. It is also possible to generate the
shares of a secret in a distributed fashion, which enables the shareholders to compute
their own shares without the necessity of a central authority. An example using RSA is
given by Boneh and Franklin (1997). The threshold multisignature schemes are in fact the
generalization of the multisignature schemes. While key sharing is k-out-of-k in the latter,
it is t-out-of-k in the former, which means that t of the total of k shares are enough to
Nevertheless, threshold schemes do not have specific advantages over simple secret
splitting techniques we are using, with MAs. While it is feasible to use these secret
splitting schemes to both share the keys and compute with them, it is also feasible to
come up with very simple techniques to create multiple combinations of keys for
providing fault-tolerance, as demonstrated by Wu et al. (1999). On the other hand, in our
application, secret splitting has two important advantages: simplicity and ubiquity. We
use very simple secret splitting schemes, which use only addition and multiplication. The
secret splitting schemes we use require nothing but the implementations of the standard
public key cryptosystems, namely, de facto industry standard RSA and the official Digital
Signature Standard (DSS), which is based on El Gamal public key scheme. So, these
schemes do not need any new algorithms or an implementation of those algorithms. It
should also be noted that what makes it possible to use these simple secret splitting
schemes with the El Gamal cryptosystem and DSS is the unique property of the
application that the whole secrets and all of the shares are to be computed and known by
the MA owner; therefore it is possible to perform computations in advance to be used
later when the complete signature is computed. Details of these computations are given in
the next section.
4.8 Key Splitting and Signature Generation
Boyd (1988), by using the multiplicative property of RSA, showed that the
classical RSA is actually a specialization of a general multisignature scheme. For an RSA
implementation for sequential signing, we will use this property. Boyd (1989) also
mentions about a similar technique, which enables to perform signature generation in
parallel. This is the RSA part of the techniques we will use in parallel signing. Note that,
both techniques use nothing but original RSA signing and verification algorithms. The
RSA implementations, which are standardized and used in practice, and their
implications on remote digital signing will be discussed later in the chapter. In the
following, we present techniques to do the same with El Gamal Cryptosystem, which
again use original signing and verification procedures, by using a property that is unique
to MAs, as explained.
4.8.1 Using the Multiplicative Property of RSA
Classical public key cyptosystems use two keys, one is the public key and the other
is the private key. It was shown by Boyd (1988) that this is only a specialization of a
general multisignature scheme in the case of RSA. This is possible since RSA has the
multiplicative property, namely, with the same modulus and two decryption keys d, and
S (S (mh, d,), d) = S (mh, dl d2)
where S is the signing function and mh = h(m). Here, m is the document to be signed, h is
an appropriate cryptographic hash function (i.e., SHA-1) and mh is the message digest.
Note that, for clarity we defer the discussion of recent advances in theory and practice of
computing the message digest mh for better security of RSA signature scheme until
The modulus n is still the product of two large primes p and q. However, unlike
classical RSA, which has two keys e and that are encryption and decryption keys
respectively, in this scheme k -1 keys are chosen randomly and then the kth key is
chosen to satisfy the property
d, d, **dk1 e = 1 mod .
The encryption key is e and when the d,'s multiplied together the result is the
decryption key d.
So, with three partial keys dc, d2, and d3 three agents can sign a document with
X =((m )d2 )d= mh dmod n
which can be verified by
Xe = mh e modn .
4.8.2 Using the Additive Property of RSA
Boyd (1989) mentions an alternative scheme to overcome the difficulties of
multisignatures with more than two signatories (e.g., different users). In the context of
multisignatures it is possible to assign different keys to different users, and signing
process can be done in parallel. Resulting signatures are then combined. Using the same
scheme, it is also possible for our purposes to split up a key by addition instead of
multiplication assuming three signatories as follows
d = d1 + d2 +d3.
Each agent is provided with one of the partial keys dc, d2 and d3. When it is time
to sign a contract, they are either provided a copy of the original contract or they prepare
the same contract depending on the application (see Section 4.9).
Then they sign by
S1 = mdl, modn S2 = mh2 modn S3 = mhd, modn.
Note that, the message digest mh above is computed as mentioned in the previous
Signatures Si, S2, and S3 are sent back to the server where the signatures are
required. The server computes
S S2 3 = mhd d2 mhd3 modn = mh (dd2+d3) modn = hd modn.
Therefore, the server can also verify the signature by
(S S2 S3)e = hde modn.
The scheme can be generalized for n signatories in the obvious way.
4.8.3 Using El Gamal Public Key Cryptosystem
Here we use a variant of the original El Gamal signature scheme as given by
Kaufman et al. (1995). There are two reasons to do this. First is, this scheme is simpler
and it is easy to compute with partial keys. The other reason is that, the scheme is
actually the El Gamal version used in DSS, which in turn is based on the original idea
introduced by El Gamal (1985). So this scheme will enable us an easy transition from El
Gamal to DSS. The El Gamal variant that we use is summarized below (Kaufman et al.,
* Long term public key:
* For a message m choose random number r, compute gr modp = T,, and message
digest d, (digest of m I T,)
* Sign with X= r + dm S mod (p 1)
* Verify by gx = T, Tdm modp
In the following sections, we use Figure 4-1 to illustrate the signature generation
scheme. There are three mobile agents, Alice, Bob and Carol. Alice is the master agent
and the others are support agents. Figure uses the same mission model developed in
Chapter 3, however, for clarity only a snapshot of the mission is shown.
S.. ............-" ...........' .." Domain C
SHos4 HostC Host
................ -...... "
Figure 4-1. A snapshot of a mission using multiple mobile agents
18.104.22.168 Signing in sequence with El Gamal signature scheme
The El Gamal cryptosystem uses a pair of private keys as opposed to RSA's single
key. The first one is the long term key as in the RSA. The second is a short-term, per
session, private key for each message to be signed with the long-term key. We split up
both of these keys as follows:
Long-term key: S = S -Sb -Sc (1)
Short-term key: r = r + rb + r. (2)
Here we assume again that our MA group consists of three agents, namely, Alice,
Bob and Carol. Alice is the master and the others are support agents.
To sign a message, Alice computes the message digest d, and signs with
X, = r, + d S, mod (p 1) (3)
Note that, the message digest dm here is the result of an appropriate cryptographic
hash function H applied to the contract m concatenated with T,:
dm =H(m Tm) (4)
where Tm = gr modp as given above. In sequential signing, Alice is the only agent,
who needs Tm and it is assumed here that she is provided by this value before the mission
Then, she sends her partial signature to Bob. Bob, upon receiving Alice's signature
Xa, further signs it with his portions of partial keys as
Xb=rb + X Sb mod(p -1)
=rb +Sb +d S Sb mod (p-1)
Carol does the same on Xb, which represent the partial signature generated by
Alice and Bob,
X = + Xb S mod(p-l1)
=r +rb +r Sb S +d Sb Smod(p-1)
Unfortunately, this last equation above, unlike the RSA counterpart, is not equal to
the signature X, although the last term of the equation is nothing but the last term of the
original signing equation:
dm S Sb S,= d S. (7)
This leads us to the observation that the difference between the target signature X
and the signature generated by the three agents Xc is
X,-X= (S- 1)rb +(Sb S,- )r, mod (p-) (8)
Since the right hand side of the equation consists only of constants and partial
private keys, it can easily be computed and given to agents before they are sent out to the
network. This ability is unique to the application that we consider in this chapter. In the
classical applications of digital multisignatures and threshold signatures, it is not possible
to perform the same computation since the signatories are distinct parties and the secrets
they share cannot exist in a single site as a whole. So the last agent in the row, Carol,
sends the partial signature Xc to Alice. Alice computes X, the target complete signature by
using the equation above. The general difference equation for n signatories is
X -X = rt Sk -1 mod(p -1) (9)
22.214.171.124 Signing in parallel with El Gamal signature scheme
Signing in parallel with the same variant of El Gamal cryptosystem is also possible
and even easier. For this purpose we split up the keys as follows:
Long-term key: S = S b +S, +Sc (10)
Short-term key: r = r + rb + r (11)
Then, each agent is given the partial keys as well as T, = gr modp since all of the
agents will need it to compute the message digest d, = H(m T,) where m is the contract
to be signed and H is an appropriate cryptographic hash function. They sign
independently of each other as
X, = r +dm S, mod ( -),
Xb =rb +d Sbmod (p-l), (12)
X, =r + d S mod(p 1)
and the support agents send their partial signatures to the master agent. Together
with the master agent's signature, the server combines the partial signatures and obtains
the complete signature as follows
X = X +Xb + X
= r +rb + +d S +dm Sb +dm Sc (13)
=r+d (S, +Sb +SC) =r+d S
The scheme can be generalized to n signatories in the obvious way.
126.96.36.199 Transition from El Gamal cryptosystem to digital signature algorithm
While RSA is the defacto industry standard of public key cryptography, the Digital
Signature Algorithm has been proposed as the official standard as Digital Signature
Standard (DSS) by US National Institute of Standards and Technology. It is based on the
original idea of the El Gamal public key scheme and is very similar to the variant of the
El Gamal cryptosystem.
We will neither provide the details of DSS nor the details of the signature
generation by partial keys. However, we will give the differences between the El Gamal
scheme presented in previous sections and DSS.
The signing equation in DSS is given by
X =r' (d, + S T) modq (14)
where r 1 is the multiplicative inverse of r mod q. Therefore it can be calculated in
advance and instead of splitting up r we can just as easily split up r 1
Signing in sequence with DSS. The key splitting is performed as follows:
Long-term key: S = S Sb +S +S (15)
Short-term key (inverse): r 1 = ra r rb r. (16)
The signing process is very similar to El Gamal scheme. However the difference in
this case is given by
X-X = ((r -1) rb Sb +(rb r-1) ) Sc)T (17)
For n signatories (i.e., agents), the general difference equation is
X X = T rk in S (18)
t=l k=l w=t+l
Signing in parallel with DSS. The key splitting, signing and signature
combination calculations here are very similar to the El Gamal scheme. However, the
combined value is not equal to the target complete signature X. Therefore we call this
value X' and the difference is given by
X-X'= T (rO(Sb +S,)+rb(SO +S,)+r,(S0 +Sb)) (19)
For n signatories (i.e., agents), the general difference equation is
X x, = T_ ,, rtSk (20)
4.9 The Overall System for Remote Digital Signing
As presented in the previous section, there are two major multi-signature schemes:
sequential and parallel. Figures 4-2 and 4-3 provide the overall system of signing and
verification processes as part of an MA mission, for sequential and parallel signature
generation schemes, respectively. In this section, we discuss these protocols, compare
them with respect to assumptions made and the analysis of attacks possible against each
Please note that, in this chapter we do not address fully the overall security issues
necessary for a whole MA mission. Signature generation is actually an integral part of the
whole mission. However we provide the protection mechanisms when necessary in
addition to the signature generation process to make this process more meaningful.
1. Alice asks the Server for a bid for her demand
2. Server provides Alice with its offer along with its signature for the contract
3. Alice sends the server's bid along with its signature to Bob and Carol
4. Bob and Carol verify the server's signature
5. Bob prepares the contract and signs it with his part of private key
6. Bob sends the partially signed contract C, to Carol
7. Carol signs the contract, partially signed by Bob, further with her partial key
8. Carol sends the partially signed contract C, to Alice
9. Alice, with her partial key, further signs the contract and obtains the fully
signed contract CAc
10. Alice delivers the signed contract CAc to the server
11. Server verifies the contract using the public key of the user
Figure 4-2. Protocol for sequential signing with multi-agent model
In both of the protocols, the first part is to obtain the bid of the server along with
the signature for this offer and then verify this signature in steps 1 through 4. After Alice
obtains server's signature, she sends it to both Bob and Carol. Signature verification is
carried out by both Bob and Carol independently on different hosts in different domains.
It would not make sense to let Alice verify the signature since Alice is under complete
control of the very same host that made the offer. Step 5 in Figure 4-2 contains the
contract preparation process performed by Bob. The protocol assumes that Host B does
not have any interest in forging the computation as does Host A. Although the chances
are low, this assumption is not enough for a convincing level of security, since a denial-
of-service attack by Host B is possible. This is due to the drawback of this protocol that
there is no way to check whether the contract signed by the first agent in the row is
correct. This is true regardless of the fact that the decision function is executed in
cooperation with all the members of the group. However, this drawback does not make
the protocol totally inappropriate because even an attack cannot be prevented, it would be
detected in Step 11 when the host attempts to verify the signature. Nevertheless, it is not
possible to tell which host is cheating. The parallel signature generation scheme does not
have this drawback as we see next.
Host A 4 ) (5
Server Alice r
1-4. Same as Figure 4-2
5. Alice, Bob, and Carol prepare the contract and sign it with their part of
private key and each obtain CA, CB, and Cc respectively
6. Bob sends the partially signed contract CB to Alice, Carol does the same
7. Alice, combines CA, CB, and Cc, and obtains the fully signed contract CAB
8. Alice delivers the signed contract CABC to the server
9. Server verifies the contract using the public key of the user
Figure 4-3. Protocol for parallel signing with multi-agent model
In Figure 4-3, Step 5 states that all agents prepare the contract to be signed. This is
possible since Bob and Carol receive the server's offer from Alice. Furthermore, any
decision function that needs to be executed to reach the decision for actual purchase is
shared by three agents and executed in cooperation. However, it is also possible for any
one agent to prepare the contract and communicate it to the others. Once the contract is
obtained either way, agents sign it with their shares of the private key for the chosen
algorithm as described previously. Step 6 says that Bob and Carol send their signatures
back to Alice, and in Step 7, Alice combines them to obtain the fully signed contract.
This means that combining the partial signatures takes place in the host where Alice
resides. This is because there is no trusted authority to ask for this computation. But for
the application under consideration, there is no need for it either, since there is no known
4.10 Using Limited-liability Keys and Public Key Certificates
Our multi-agent model provides a high level of security by making it difficult to
compromise all the agents, which together form an autonomous group. However, the
secret, which is a private key of the agent owner, is an extremely sensitive piece of
information. Revealing user's shopping preferences or losing electronic cash is certainly
undesirable, but in essence a part of our daily lives since we have just enough security to
protect these valuables. But a forged signature under a document may mean "anything"
and may not be tolerable or acceptable. So even a very small chance of the whole group
of agents being compromised may not be acceptable since the consequence of this
malicious action is revealing the private key of the user. Therefore we define two types of
public/private key pairs as follows.
Long-term public/private key pairs: These are the long-term keys, which are
created, registered and assigned to the user (who becomes the owner of the keys) by a
Certificate Authority (CA). The lifetime of these keys are again decided by the same
Limited-liability public/private key pairs: These are the short-term keys, which are
created by the very same user (owner of the keys). Since the creators of the keys are the
users themselves they also are the authority to decide the lifetime of the keys.
There are two limitations that can be imposed on the limited-liability keys. The first
one is the lifetime of the key and the second one is what can be done (i.e., signed) with
these keys. Both of these limitations can be flexible or restrictive and is up to the owner
of the keys. For example, the lifetime of a key may vary from a single MA mission,
which may be limited to a couple of minutes, to a total of a couple of days that spans
several different missions. Liability definition says what exactly can be signed with these
keys. For example, a typical definition may say that these keys can only be used in an m-
commerce transaction and the amount that could be involved in such a transaction cannot
exceed $500. The other type of limitation that can be imposed is the type of the
transaction. For example, it can be stated that, with these keys only one mobile phone,
one color printer or one DVD player purchase contract can be signed.
The problem with this scheme is the authenticity of this new pair of keys. One
possible solution would be to register this pair of new keys with a CA and obtain a
certificate, or ask the CA directly for a pair of new keys. Nevertheless, this solution does
not make much sense, since this introduces an overhead of obtaining a new key for every
single transaction from a CA, which could easily become unmanageable. Instead, the user
creates this key and a certificate for this key by using his/her long-term key. The idea is
that the user obtains only a single public key and a certificate for it from a CA. Using this
certificate and public key, it is possible for the very same user to create and use unlimited
number of other public keys. The key point here is that these new keys are certified by
their owners. That is, the user in essence becomes a CA for the agents he/she sends on
It may seem at first that the scheme explained in this section provides enough
security for the limited-liability private key. This is due to the fact that what can be
signed by this key is restricted by the certificate provided for it. However, it is not so for
two reasons. First problem is the same problem that the undetachable signature schemes
have as explained previously, which is the difference between the limitation of what can
be signed and what actually is signed. A certificate can only enforce what can be signed
with the key, for which it is issued. But in fact, it is necessary for agents to be able to
engage in transactions with the most favorable choices. For example, a certificate may
allow for a purchase of up to $500. However, this should not mean that the agent would
accept an offer of this amount. If the server's original bid is $300, then the server should
not be able to enforce the agent to involve in an agreement for the allowed full amount of
$500. The second problem is that an attack is possible by any host visited. Any such host
for example might learn the complete limited-liability private key from agent Alice, and
then can sign a contract to sell something. Also, even if the support agents are involved in
the decision function to be executed, this is not enough since a single agent who
possesses the complete key could be manipulated. In short, this scheme when used alone
could open a can of worms. Therefore, the limited-liability keys are protected by splitting
them up and giving them to members of a group of MAs. Their usage, on the other hand,
is protected by the certificate created by the user using the long-term key.
The complete protocol for using the certificates and limited-liability keys for agents
is given in Figure 4-4. In the protocol, P and S represent the long-term public and private
keys respectively andp and s represent the limited-liability keys. The protocol assumes
that user already has P and S. Note that P, S, p and s, are symbols for the private and
public keys, for example in the case of RSA, P andp indicate (E, N) and (e, n)
respectively. The certificate contains p and the description of the liability. Any document,
which is signed with s and therefore can be verified byp, should conform to this
description to be valid.
Note that a certificate chain that would also include CA's certificate for (P, S) rules
out the necessity for the server to connect the CA and ask for verification.
1. User creates (p, s) or uses a pre-computed pair of keys
2. User splits up s, using one of the techniques mentioned
3. User prepares a certificate and signs with S
4. Server uses P to verify the certificate and obtains the identity of the user and p
5. Agents sign the contract with their shares of s
6. Server verifies this signature using p
Figure 4-4. Limited-liability key protocol
Now let's look at what can and cannot be accomplished with these limited time and
liability keys and what can go wrong. The analysis involves three parties that can act
maliciously; agent owner, the host to which a signature is provided, and third parties,
which could presumably acquire the limited-liability private key. Since the private/public
key pair is arbitrary, meaning that they are neither created nor registered by a CA, the
host on which the transaction took place may sign a contract that states that the agent
purchased 500 mobile phones for the price of $100 each. Since the host also knows the
credit card information of the user, it can perform a transaction and bill the user's credit
card for this transaction. The solution to the dispute requires the proof of the user's
demand for this kind of purchase. But the certificate which is signed by user's long-term
private key pair states that the transaction amount may not exceed $500 and it is only
valid for a purchase of a single mobile phone. Therefore there is no way for the host to
prove such claim.
Now, suppose that a third party was able to compromise all the agents in a group
and therefore acquire the limited-liability key. Then this party could sign an arbitrary
contract on behalf of the user by masquerading as the user. In this case, however, it is not
possible to bind the user to this contract since there is no certificate signed by the user
using the long-term private key. So, such signed document is invalid because the user can
deny it rightfully.
Third attack involves a malicious user, and is known as non-repudiation problem.
The user cannot deny a contract that states a purchase demand that conforms what is
stated in the certificate signed by the user's long-term private key. This is what we expect
since this is the aim of the certificate and is completely legitimate. Also, the user cannot
deny the legitimacy of a contract by claiming that the contract was signed after the
limited-liability key had been expired. That is because agents are supposed to check
whether the expiration date and time has passed. On the other hand, as explained in the
previous paragraph, the user can deny any illegitimate contract signed by the limited-
liability key that does not conform to the certificate. Another similar attack might be
possible, if an attacker creates and uses a limited-liability key by also creating a fake
long-term key without registering this long-term key by any CA. Then the attacker
prepares a certificate for the limited-liability key using this fake long-term key. The last
step for the attacker is to let the agents engage in transactions and then deny their
existence. These transactions may or may not conform to the certificate prepared. So, the
merchants/sellers should always check the legitimacy of the short-term keys by checking
the certificates prepared for them, as well as the legitimacy of the certificates by checking
the long-term keys used to prepare them possibly consulting the CA, if not provided.
4.11 Practical Issues of Remote Digital Signing
In this section we examine the issues related with using the Remote Digital Signing
in practice. First we look at the issues related with the security level and robustness of the
multisignature schemes by discussing the recent theoretical advances in digital
signatures, their impact on implementations in practice and particularly on remote digital
signing. Then, we look at the broader picture of multiple MAs paradigm and discuss the
performance issues that might arise in practice and how to address them.
4.11.1 Probabilistic Signature Scheme and its Impact on Practice
Probabilistic Signature Scheme (PSS) has been proposed by Bellare and Rogaway
(1996). It is applied to the hashing but the signature generation is the same. The idea is to
mix the document to be signed with a random salt in a specific way and the result is a
better security proof. This is due to the fact that security of PSS can be tightly related to
the difficulty of inverting RSA. We refer the interested reader to Bellare and Rogaway
(1996) for details. As the name implies, PSS is probabilistic rather than deterministic,
which is the case for classical RSA commonly in use today. The scheme has practical
importance and has been adopted by the RSA Corporation as a standard (PKCS#1, 2002).
Unfortunately, the scheme is not applicable in environments where deterministic
signature generation is necessary. In our case, it is applicable to sequential signature
generation using RSA since signature generation is initiated by a single agent and
appropriate hashing is only performed by the same agent. The other agents (i.e., support
agents) therefore need not know the random salt value used and can apply their keys to
the signature function. However, parallel signature generation with RSA requires a
deterministic scheme since all the agents need to know or be able to generate the same
random salt. The issue is important since our main concern is to use standardized and
widely implemented and used schemes like RSA. The random salt value in PSS enhances
the security by providing a tighter security proof. However, in practice, randomness is not
critical to security (PKCS#1, 2002). In our case, parallel RSA signature generation is still
feasible by providing a fixed value to the agents or have them compute the same value
and use it when it is time to generate the underlying message digest to be signed.
Furthermore in our scheme, the lifetime of the keys and their applicability can be
extremely restricted due to the use of certificates issued for them. So, the probability of
forging the signatures is extremely low and it is difficult to justify the efforts to do so.
Some theoretical research results however lead us to question the probabilistic
schemes like PSS. Recently, Katz and Wang (2003) showed that an equally tight security
proof of PSS could be constructed in a deterministic way. The idea is to use a single bit
(0 or 1) instead of a random salt value when generating the hash value. This variant of
PSS may render the current proposed standardization of the original PSS obsolete, which
is not convenient in environments where random generation is not possible or is not
preferred as in the case with parallel signature generation presented.
4.11.2 Performance Considerations and the Big Picture
Remote digital signing is in fact a part a new computation paradigm of multiple
MA systems. Among many issues of this big picture, performance considerations deserve
specific attention since multiple agents introduces additional communication to the
classical single agent model. The immediate result follows as more communication
overhead to the underlying network and degraded performance observed by the user.
Network-awareness in general and specifically network distance estimation are hot
research topics and aims at assisting applications, which would benefit from being aware
of the underlying network characteristics and conditions. Multiple MAs are such an
application area where network-awareness as well as context-awareness, which also
addresses security considerations, is important. For example, choosing hosts to send the
agents randomly increases the security risk of conspiracies against them. So, hosts to be
chosen need to be in different administrative domains and should not have common
interests to alleviate this risk. The goal, therefore, is to find the best possible combination
of available hosts under the restrictions mentioned above, which are (in terms of network
distances) close to each other. This not only addresses the performance but also the
security since vulnerability of the agent communications over the network reduces. These
issues are the subject of following chapters.
One last remark on performance issue is the subtle difference between the
client/server paradigm and the MA paradigm in general, regarding user expectations. The
applications of the MA paradigm, which is in fact a special case of the multiple MAs
paradigm are not user-interactive as is the case for client/server systems. Users do not
expect immediate results from their MAs and it is in that aspect that constitutes the
foundation for enabling disconnected operation. Therefore, performance penalties should
be observed in a more relaxed fashion than it should be in the traditional client/server
Mobile commerce is a rapidly developing field of electronic commerce. Mobile devices
and wireless networks, which make the mobile commerce a reality, however are not
developing at the same pace. It can be expected that the limitations of these technologies
will be with us several decades from now. MAs are distinguished candidates to tackle this
problem. Although benefits offered by this technology are well understood by now,
especially in the mobile commerce field, security and interoperability are two main
concerns of this technology. It is also well understood that without proper security
mechanisms in place, MAs will not be accepted. So, advances in MA security area will
directly affect the future of mobile commerce applications.
This chapter carefully examines the implementation of remote digital signing,
which is a special case of computing with secrets in the public domain, within a larger
picture of supporting multi-agent computing. The solution approach is based on secret
sharing and the concept of protection as a whole. In addition to well-known
multiplicative and additive properties of the RSA, similar techniques with El Gamal
public-key cryptosystem are demonstrated to show their applicability in the MA systems.
Although threshold multisignature schemes fit well into the application, it may not be
feasible and even reasonable to provide the implementations of these schemes to the
MAs. Moreover, the advantage of the techniques we presented in this chapter is that they
use nothing but original signing and verification algorithms of RSA and DSS, which are
well known and widely used. In this sense, these simple schemes address the ubiquity in
a large scale MA execution environment like the Internet.
The MA security problem is not limited to signature generation, however. In fact,
signing a document is supposed to be a part of an MA mission. A complete solution to
the problem of protection against malicious hosts is still to be addressed in our future
work. However, as we have presented in this chapter, even the most challenging part of
the problem, computing with secrets by MAs, is feasible using the multi-agent model.
It is shown that both parallel and sequential signature generation schemes are
possible. There are important properties of each scheme. The former one provides data
integrity since each agent in the group signs the original document, therefore can check
its integrity. However, in this scheme there is no confidentiality for the document to be
signed. The latter scheme provides data confidentiality only if signing process begins at
the server, where the master agent is being executed. The other hosts, where the support
agents are running, can not see the document in clear, assuming the partially signed
documents have enough strength against cryptanalysis. The schemes presented in this
chapter therefore address authenticity rather than data confidentiality.
In this chapter, while applying information dispersal to mobile agents to
accomplish digitally signing contracts in the public, our tacit assumption was that we
could position these agents in the hosts over the network; this positioning as well as the
mission as a result of it would be feasible. In the next chapter we examine this
positioning problem to show that it is feasible to identify the best host locations to realize
the information dispersal with multiple mobile agents.
A NETWORK POSITIONING ARCHITECTURE FOR MOBILE AGENTS
Applications that can benefit from being aware of the underlying topology and the
network distance information are numerous. For example, in a web caching system,
clients of the system may choose the best location among the alternatives to obtain the
cache copies. Similarly, the location information is obviously useful in placing
WWW/FTP mirror sites in different areas on the network. In such a replica system,
clients may need an automated mechanism to choose the best mirror site based on
topology information. The problem of addressing this requirement for such applications
is known as the server selection problem. Another important application area is in the
design of content addressable networks (Ratnasamy et al., 2001) and overlay networks
(Stoica et al., 2001). These systems require transformation of logical network topologies
from an underlying physical network. In general, any content provider orpeer-to-peer
(p2p) file sharing facility (i.e., Napster and Gnutella) requires topology information for
the best performance, which otherwise may not be observed. Many other topology-aware
applications have been explored in literature (Ratnasamy et al., 2002).
Different from the applications described above, our interest in developing a
network positioning model came from the need for supporting a multiple mobile agent
The proposed positioning model is a p2p coordinate-based system, which maps a
physical host location to logical coordinates for efficient on-the-fly logical distance (e.g.,
communication delay) estimation between any two hosts in the system.
5.2 Related Work
Much like time services in distributed systems, distance services can be provided
by some servers or obtained collaboratively by some participating hosts. The IDMaps
(Francis et al., 2002) is an example of the former case. This approach uses triangulation
heuristics combined with a centralized, client/server architecture.
Examples of the latter case are the coordinate-based Global Network Positioning
(GNP) (Ng & Zhang, 2002), the Lighthouse (Pias et al., 2003) and the inning
(Ratnasamy et al., 2002) approaches. The GNP and inning strategies use the concept of
landmarks, which are introduced by Hotz (1994). In GNP, coordinates are computed by
modeling the Internet as a geometric space. Some hosts in the system are identified as
landmarks. These landmarks first measure their distances to each other and then compute
their coordinates by minimizing the error between the measured and the computed
distances (see Step 4 in Section 5.3.1 for details).
This results in approximate distances as represented by the coordinates among
landmarks. An ordinary host can measure its distance to these landmarks and use the
landmarks' coordinates to compute its own with the same minimization technique. Figure
5-1 illustrates two hosts A and B, which compute their coordinates using the global
landmarks L1, L2 and L3. From there on, A only needs to ask B for B's coordinates to
obtain the distance to B. The GNP is a p2p architecture as oppose to the IDMaps' central
Figure 5-1. Global network positioning model (GNP)
In the inning strategy, rather than utilizing coordinates, hosts measure their actual
distances to the landmarks and place themselves in a bin based on the sequence of sorted
distances to the landmarks. The idea is that hosts, which are close to each other relative to
the other hosts, will have similar sequences and therefore will be placed in the same bin
or in a similar one. The inning strategy assumes that fine-grained reduced errors
between measured and predicted distances do not have a considerable effect on the
application performance. As a result it is possible to make distance comparisons by using
less information namely, only a sequence of estimated distances to a set of landmarks.
However, the approach is not as flexible as the coordinate-based approaches. This is due
to the fact that in the inning strategy bins are tightly bound to the landmarks, whereas in
coordinate-based approaches the coordinates and the landmarks are relatively loosely
The Lighthouse approach (Pias et al., 2003) shares the same idea of eliminating the
landmarks to achieve scalability, as the proposed approach in this chapter. The scheme
uses a transformation matrix maintained by the hosts for making conversions between the
global and the local bases. However, the approach does not address the practical
implications, namely, it is not clear how the global basis is formed and the definition of
the local basis is not consistent with the positions of the hosts since the hosts are picked
arbitrarily. Moreover, every host that wants to participate needs to create a local basis.
While it is also not clear how to find a host that is currently participating in the system, it
does not bring any advantage over GNP in terms of accuracy of the distances.
The results of GNP study (Ng & Zhang, 2002) show that, the coordinate-based
approach provides better estimation of distances than the IDMaps. It is also more
accurate and robust due to its p2p architecture when compared to IDMaps. However, this
approach has its own drawbacks. First, the landmarks must be globally distributed to the
entire Internet to accurately measure the distances between two arbitrary distant hosts.
But the distance estimation between two local hosts is biased with the coordinates of the
widespread landmarks, which are not local to the given two hosts. Second, these
landmarks are central points of failure and may become target of attacks. Third, where to
locate the landmarks, how many landmarks there should be and how/where to move the
landmarks or add new ones as the Internet topology changes and grows are important
open scalablity problems. Finally, there is a security concern of the system. The authors
point out that (Ng & Zhang, 2002) this system may not be suitable in an uncooperative
environment since there is nothing to prevent a host from lying about its coordinates for
being chosen or not chosen depending on the application. To address these shortcomings
we propose the coordinate-based Pure Peer-to-Peer Network Positioning (Triple-P NP or
TPNP) architecture, which completely eliminates the landmarks and the problems they
5.3 TPNP Approach
The idea of TPNP is similar to the basic principle of dynamic distance vector
routing, except that hosts do not need a global picture (i.e., a routing table) of the
network. A host that is interested in participating the TPNP system first discovers the
nearby hosts that are already in the system to use them as reference hosts, which replace
the landmarks for the host in question. Then, the host contacts these references to
compute its own coordinates (see Section 5.3.1). Figure 5-2 illustrates the same hosts A
and B's (from Figure 5-1) coordinate computation process. A uses three other ordinary
hosts C, D, and E already in the system, and B uses F, G, and H locally. These hosts,
which are already in the system, are not shown in Figure 5.1 for clarity. As shown host C
may have used three other locally positioned ordinary hosts for computing its own
D G H
Figure 5-2. Local network positioning model (TPNP)
Unlike GNP or any other global positioning system local measurements as of
TPNP are likely to give more accurate results between local hosts. There are two