Conventional Mobile Code Systems Are Static Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Conventional mobile code systems are static configuration where the mobility of data, code and execution state is limited by physical link between the client & server, data structures used and programs that need to be in sync between the client/server systems. Communication between the hosts is done by physical links that are limited by single point network failure. Various portions of the distributed applications that run on the nodes of the system are bound to such nodes for their life time. Hence, the topology for these systems is assumed to be fixed.

This architecture is challenged by experts and introduced degree of mobility in the logical structure. This can be achieved by fluid software fabric where components of the application can dynamically change their location. This form of Logical Movement is often called as Mobility. This mobility in the software program allows the code and possibly the execution state is migrated in parts or as a whole at runtime. Variants exist on how to migrate the code and the execution state. The decision on migration is autonomously taken by the program at runtime. This kind of roaming applications often called Mobile Agents. Agents have ability to move from system to system on same network and communicate with an object on a remote system and then take advantage of being on the same host and the network as an object.

Mobile Agents have emerged as a promising alternative to other mobile code systems. While agents have generated a lot of excitement in the research community, they have not been translated into significant number of real time applications. Security of Mobile Agents (from Malicious Agents & Hosts) and Hosts (from Malicious Agents) continues to be a challenge.

Conventional agents are designed to perform a predefined task on a host, however in many enterprise networks, creating a distinct agent for each task to be performed would result in managing a too many agents. Also, if same set of hosts are to be visited by two different agents for a performing a similar task (like gather status or check utilization), instead of using two different agents to perform the task, a single agent should be able to perform both the operations. Agents can be programmed to adapt to performing one or more task on a host during its visit can be termed Adaptive Agents.

While security and adaptability are the basic requirement for communicating in a single network, Inter Agent communication forms the basis of distributed networks. Agents offer unified and scalable framework for applications in widely distributed heterogeneous open networks such as Enterprise Network Management and Distributed Decision Making. A number of Mobile Agent systems have been developed such as Aglets, Mole, Telescript etc., they differ to each other in different applications, however, the fundamental ability is to communicate between Agents in heterogeneous systems remains a key challenge to be addressed.

Agents that are autonomous and intelligent to perform a task can also be programmed with a calculated amount of intelligence so that they can react to a situation and take decision. This approach of agent's ability to take few decisions and act proactively or reactively would decentralize the decision making in an enterprise network.

The scope of this thesis is to propose a new security mechanism for mobile agents that can secure data/bid from each host from subsequent hosts and perform partial encryption of data for each host, enhance the functionality of mobile agents to communicate with multiple ports/applications at each visit to a host with practical implementation of Mobile Agent Service Tracking System. Also, the thesis would discuss techniques to program intelligence into mobile agents that can take decisions on their own and also communicate with each other with the help of an Inter Agent Communication protocol to route messages among Agents in a heterogeneous enterprise networks.



Mobility is an orthogonal property of agents, that is, not all agents are mobile. An agent can just sit there and communicate with its environment through conventional means, such as remote procedure calling and messaging. We call agents that do not or cannot move stationary agents. A stationary agent executes only on the system on which it begins execution. If it needs information not on that system or needs to interact with an agent on another system, it typically uses a communication mechanism, such as remote procedure calling.

1.1 Why Mobile Agents

The Mobile Agent is an autonomous software program that can move from one host to other in a network and perform a specified task. Agent is programmed with intelligence to decide where to migrate next. Its features like mobility, autonomy, size bring several advantages like less bandwidth requirement, limited latency and higher degree of robustness. Due to the mentioned advantages, Mobile Agents are now finding its applications in Distributed Computing, information management, contract negotiations systems and applications along with electronic commerce and auctions.

Danny B Lange [1] gave 7 good reasons for using Mobile Agents.

They overcome network load

They overcome network latency

They encapsulate protocols

They execute asynchronously and autonomously

They adapt dynamically

They are naturally heterogeneous

They are robust and fault-tolerant

Everything that can be done with a mobile agent can be done with client/server applications or remote procedure calls however these are synchronous operations which require both the parties to be in continuously active. Mobile agents are preferred in applications that need data intensive operations, disconnected operations, dynamic deployment of software and highly user specific applications.

1.2 Objective of the Work

Mobile Agents find their applications in areas like distributed computing and e-commerce applications. Beyond simple information gathering tasks, the agents now take over all the tasks that include commercial transactions such as contract signing, price negotiation and delivery of goods and services. The benefits of using Mobile Agents in various business and technological areas are great; however the existing technology brings some serious security risks. Security of agents always remains an active area of research and a challenge to application of mobile agents in new business areas.

Among many challenges security of agents is a key challenge to be addressed. We could classify the security issues of mobile agents as

Protection of the host from malicious code/agents

Protection of the agents from malicious hosts trying to tamper the code and the agent data

Both these issues are addressed by the RSA key exchange technique discussed in the thesis. Though RSA key exchange is a costly technique to be used for mobile agents, reusing the keys make them feasible for implementation.

The current generation agents are autonomous and subjective that can perform a task independently on a remote host however, they lack the ability to dynamically adapt to the requirement of performing multiple tasks in a single visit. Performing a similar task on the same set of hosts would require multiple agents. The agent service on a host is limited to the interaction with the respective port or application. In many enterprise heterogeneous networks, the agent needs to communicate with multiple ports on a host or access different services on the host, like network monitoring, check the status of processes & services running on a host or a server, CPU & Memory utilization, performance monitoring, a separate agent is required to monitor each one of these factors. Though the bandwidth and network utilization of agents is limited, maintaining a different agent for each of these system services will always be an overhead to the agent server. This can be addressed by programming more intelligence into the Agent so that it can communicate with multiple ports and services on a host at the same time. These dynamic adaptive agents can further reduce the number of agents that are required for monitoring a network. A single application can be designed that would report the status of all the services and performance metrics with the help of Adaptive Mobile Agents. This thesis focuses on building an application using Adaptive agents that can track and monitor the services on an enterprise network. The performance metrics of both the techniques are compared in detail.

The next important challenge faced by the enterprises implementing Mobile Agents in network monitoring, distributed computing and related applications is Location Transparency and Distributed Decision Making. The solution to both the challenges is to make the agents to talk to each other. Agent communication is not just limited to sharing the status but also react to a situation on a network. The modern day Mobile Agents are either objective or subjective. These agents autonomous and intelligent and can react to different situations on a host or a network. The agents can be programmed to be proactive or reactive reacting to a situation. This can be addressed by setting up an efficient communication protocol for the agents to talk to each other. An Inter-Agent communication protocol is setup to establish communication between the agents. The protocol is explained in detail depicting each scenario.

1.3 Background to Agent Communication

Mobile Agents are defined as objects capable of certain level of intelligence and autonomy which can migrate from host to host within a distributed network and can accomplish the task given to it. Contrary to the previous remote communication method like Remote Procedure Calls (RPC), based on Client/Server model that requires continuous connection between the hosts, Mobile Agent technology is designed to bypass the communication link and utilize the local resources directly from the hosts where the resources are located. For its capability, mobile agents can be considered as a new potential paradigm to fulfil the need of effective and scalable answer for the problems in the area of distributed computing.

Being able to move between hosts is a special characteristic of Mobile Agent which makes it a favourable solution to address most of the real time problems. Firstly, being mobile, the agent can access remote resources without requiring constant connection with the host, therefore saving network bandwidth and reduces latency. In addition, while the conventional remote access communication obligates the hosts to be always synchronous, mobile agent communication allows asynchronous communication. Different issues that need to be considered while designing a Mobile Agent system are mobility of Agents, naming of agents & hosts, security of Agents & Hosts, applicability with in heterogeneous environment, authentication etc.

Mobile Agents should meet the following four quality requirements;

Interoperability: Two mobile agent systems are interoperable if a mobile agent of one system can migrate to the second system, the agent can interact and communicate with other agents (local or even remote agents), the agent can leave this system, and it can resume its execution on the next interoperable system.

Interoperability can be achieved with the help of three key elements

Common agent communication language & protocol

Common format of context of communication

Shared ontology

Scalability: Scalability of Mobile Agents can be defined as how well the capacity of the agent to do useful work increases as the size of the agent increases.

Mobility: Performance can be achieved by moving the agents closer to the services available on the new host.

Security: Security of Mobile Agents can be further classified into

Confidentiality: Sensitive data must be secure

Integrity: Altering data must be detected

Authentication: An agent must authenticate itself to the host and an agent server must authenticate itself to the agent.

Authorization: Agent authorizes strict access control to its data and resources

Auditing: Agent keeps track of the system and log the agent behaviour over a period of time

Non-Repudiation: The property that no party to a contract can later deny having signed

1.4 Mobile Agent Life Cycle

A Mobile Agent is Created on a home machine

The agent is Cloned to create two copies

The cloned Agent is Dispatched to the remote machine

The agent Executes on both host & remote machines

An Agent can be put to sleep and its state is stored on a disk of the host. This state is Deactivation

A deactivated agent is brought back to life and its state is restored from disk before it resumes execution. This state is Activation

The Home machine Retracts the agents and data brought by these agents are analyzed

The agents are then Disposed


Mobile Agent consists of the following four components.

Code: the program (in a suitable language) that defines the agent behaviour

State: the agents internal variables which enables the agent to resume its activities after moving to another host

Attributes/Data: information describing the agent, its origin and owner, its movement history, resource requirements, authentication keys etc. Part of this may be accessible to the agent itself, but the agent must not be able to modify the attributes

Message: message/bid received from a remote host


This thesis is organized in 5 chapters. A brief overview about the organization of this thesis in terms of the chapters and their contents is as follows.

Chapter 2 deals with the security aspects involved with the mobile agents. Sections 2.1 & 2.2 of this chapter deals with the existing security mechanisms mobile agents use and their limitations are discussed and section 2.3 discuss the proposed new security approach using RSA Key exchange technique. This chapter concludes with the performance evaluation between these techniques.

Chapter 3 deals with implementing the conventional mobile agents using JADE and how runtime adaptive agents can perform multiple tasks in a single visit to a host. Runtime Adaptive Agents are explained by building an application Mobile Agent Service Tracking System and comparing the features with conventional mobile agents. Finally a comparative performance evaluation is made between the two techniques and shown how the proposed approach is superior over the conventional agents system.

Chapter 4 focuses on how and why agents need to communicate and how agents can be programmed with limited intelligence so that they can be part of decision making. Programming objective agents that can react to situations and independently handle failures through agent communication is discussed. The main objective of this chapter is to set Inter Agent Communication protocol where agents can communicate to each other through agent servers. The protocol is implementation is discussed along with the setup.

Chapter 5 concludes the thesis along with the scope of the work and performance evaluation. The scope of future work is also given.


A new security technique has been defined along with the performance evaluation

Agent functionality is enhanced to perform multiple tasks on a single visit to a host.

Agents are programmed with intelligence to take decisions on its own in a given set of circumstances

Agent communication is setup by creating message boxes that decouples agents with the message box

Inter-Agent communication has been setup



The benefits from utilizing the mobile agents in various business areas are great. However, this technology brings some serious security risks: one of the most important is the possibility of a tampering an agent. In the mobile agent systems the agent's code and internal data autonomously migrate between hosts and could be easily changed during the transmission or at malicious host site. An agent cannot itself prevent this, but different countermeasures can be utilized in order to detect any manipulation made by an unauthorized party. They can be integrated directly into the agent system, or only into the design of an agent to extend the capabilities of the underlying agent system.

On the one hand, host platforms receiving and executing mobile agents must be protected against malicious code. Common mechanisms addressing this issue include cryptographic authentication and integrity checks, code signing and encryption, etc. On the other hand, mobile agents must protect themselves against hosts trying to tamper maliciously with either the code or the data carried by incoming agents. This issue, known as the malicious host problem, is usually addressed by the introduction of application-level cryptographic protocols [26, 28, 29, 30] whose aim is providing two basic guarantees: confidentiality and integrity.


Security threats for agents generally fall into three main classes: disclosure of information, denial of service, and corruption of information. There are a variety of ways to examine these classes of threats in greater detail as they apply to agent systems. The components of an agent system to categorize the security threats as a way to identify the possible source and target of an attack are discussed. It is important to note that many of the threats that are discussed have counterparts in conventional client-server systems and have always existed in some form in the past (e.g., executing any code from an unknown source either downloaded from a network or supplied on floppy disk). Mobile agents simply offer a greater opportunity for abuse and misuse, broadening the scale of threats significantly.

A number of models exist for describing agent systems [22, 26, 27]; however, for discussing security issues it is sufficient to use a very simple one, consisting of only two main components: the agent and the agent platform. An agent is comprised of the code and state information needed to carry out some computation on a remote host. Mobility allows an agent to move, or hop, among agent platforms. The agent platform provides the computational environment in which an agent operates. The platform from which an agent originates is referred to as the home platform, and normally is the most trusted environment for an agent. One or more hosts may comprise an agent platform, and an agent platform may support multiple computational environments, or meeting places, where agents can interact. Four threat categories are identified: threats stemming from an agent attacking an agent platform, an agent platform attacking an agent, an agent attacking another agent on the agent platform, and other entities attacking the agent system. The last category covers the cases of an agent attacking an agent on another agent platform, and of an agent platform attacking another platform, since these attacks are primarily focused on the communications capability of the platform to exploit potential vulnerabilities. The last category also includes more conventional attacks against the underlying operating system of the agent platform.


The agent-to-platform category represents the set of threats in which agents exploit security weaknesses of an agent platform or launch attacks against an agent platform. This set of threats includes masquerading, denial of service and unauthorized access. MASQUERADING

When an unauthorized agent claims the identity of another agent it is said to be masquerading. The masquerading agent may pose as an authorized agent in an effort to gain access to services and resources to which it is not entitled. The masquerading agent may also pose as another unauthorized agent in an effort to shift the blame for any actions for which it does not want to be held accountable. A masquerading agent may damage the trust the legitimate agent has established in an agent community and its associated reputation. DENIAL OF SERVICE

Mobile agents can launch denial of service attacks by consuming an excessive amount of the agent platform's computing resources. These denial of service attacks can be launched intentionally by running attack scripts to exploit system vulnerabilities, or unintentionally through programming errors. Security threats resulting from programming errors and intentional flaws have been written about since the early 1970's [35]. Program testing, configuration management, design reviews, independent testing, and other software engineering practices have been proposed to help reduce the risk of programmers intentionally, or unintentionally, introducing malicious code into an organization's computer systems. The mobile computing paradigm, however, requires an agent platform to accept and execute an agent whose code may have been developed outside its organization and has not been subject to any a priori review. A rogue agent may carry malicious code that is designed to disrupt the services offered by the agent platform, degrade the performance of the platform, or extract information for which it has no authorization to access. Depending on the level of access, the agent may be able to completely shut down or terminate the agent platform. UNAUTHORIZED ACCESS

Access control mechanisms are used to prevent unauthorized users or processes from accessing services and resources for which they have not been granted permission and privileges as specified by a security policy. Each agent visiting a platform must be subject to the platform's security policy. Applying the proper access control mechanisms requires the platform or agent to first authenticate a mobile agent's identity before it is instantiated on the platform. An agent that has access to a platform and its services without having the proper authorization can harm other agents and the platform itself. A platform that hosts agents representing various users and organizations must ensure that agents do not have read or write access to data for which they have no authorization, including access to residual data that may be stored in a cache or other temporary storage.


The agent-to-agent category represents the set of threats in which agents exploit security weaknesses of other agents or launch attacks against other agents. This set of threats includes masquerading, unauthorized access, denial of service and repudiation. Many agent platform components are also agents themselves. These platform agents provide system-level services such as directory services and inter-platform communication services. Some agent platforms allow direct inter-platform agent-to-agent communication, while others require all incoming and outgoing messages to go through a platform communication agent. These architecture decisions intertwine agent-to-agent and agentto-platform security. MASQUERADE

Agent-to-agent communication can take place directly between two agents or may require the participation of the underlying platform and the agent services it provides. In either case, an agent may attempt to disguise its identity in an effort to deceive the agent with which it is communicating. An agent may pose as a well-known vendor of goods and services, for example, and try to convince another unsuspecting agent to provide it with credit card numbers, bank account information, some form of digital cash, or other private information. Masquerading as another agent harms both the agent that is being deceived and the agent whose identity has been assumed, especially in agent societies where reputation is valued and used as a means to establish trust. DENIAL OF SERVICE

In addition to launching denial of service attacks on an agent platform, agents can also launch denial of service attacks against other agents. For example, repeatedly sending messages to another agent, or spamming agents with messages, may place undue burden on the message handling routines of the recipient. Agents that are being spammed may choose to block messages from unauthorized agents, but even this task requires some processing by the agent or its communication proxy. If an agent is charged by the number of CPU cycles it consumes on a platform, spamming an agent may cause the spammed agent to have to pay a monetary cost in addition to a performance cost. Agent communication languages and conversation policies must ensure that a malicious agent doesn't engage another agent in an infinite conversation loop or engage the agent in elaborate conversations with the sole purpose of tying up the agent's resources. Malicious agents can also intentionally distribute false or useless information to prevent other agents from completing their tasks correctly or in a timely manner. REPUDIATION

Repudiation occurs when an agent, participating in a transaction or communication, later claims that the transaction or communication never took place. Whether the cause for repudiation is deliberate or accidental, repudiation can lead to serious disputes that may not be easily resolved unless the proper countermeasures are in place. An agent platform cannot prevent an agent from repudiating a transaction, but platforms can ensure the availability of sufficiently strong evidence to support the resolution of disagreements. This evidence may deter an agent that values its reputation and the level of trust others place in it, from falsely repudiating future transactions. Disagreements may arise not only when an agent falsely repudiates a transaction, but also because imperfect business processes may lead to different views of events. Repudiation often occurs within non-agent systems and real-life business transactions within an organization. Documents are occasionally forged; documents are often lost, created by someone without authorization, or modified without being properly reviewed. Since an agent may repudiate a transaction as the result of a misunderstanding, it is important that the agents and agent platforms involved in the transaction maintain records to help resolve any dispute. UNAUTHORIZED ACCESS

If the agent platform has weak or no control mechanisms in place, an agent can directly interfere with another agent by invoking its public methods (e.g., attempt buffer overflow, reset to initial state, etc.), or by accessing and modifying the agent's data or code. Modification of an agent's code is a particularly insidious form of attack, since it can radically change the agent's behaviour (e.g., turning a trusted agent into malicious one). An agent may also gain information about other agents' activities by using platform services to eavesdrop on their communications.


The platform-to-agent category represents the set of threats in which platforms compromise the security of agents. This set of threats includes masquerading, denial of service, eavesdropping, and alteration. MASQUERADE

One agent platform can masquerade as another platform in an effort to deceive a mobile agent as to its true destination and corresponding security domain. An agent platform masquerading as a trusted third party may be able to lure unsuspecting agents to the platform and extract sensitive information from these agents. The masquerading platform can harm both the visiting agent and the platform whose identity it has assumed. An agent that masquerades as another agent can harm other agents only through the messages they exchange and the actions they take as a result of these messages, but a malicious platform that masquerades as an authorized platform can do more harm to the duped agent than a single agent can do on its own. DENIAL OF SERVICE

When an agent arrives at an agent platform, it expects the platform to execute the agent's requests faithfully, provide fair allocation of resources, and abide by quality of service agreements. A malicious agent platform, however, may ignore agent service requests, introduce unacceptable delays for critical tasks such as placing market orders in a stock market, simply not execute the agent's code, or even terminate the agent without notification. Agents on other platforms waiting for the results of a non-responsive agent on a malicious platform must be careful to avoid becoming deadlocked. An agent can also become livelocked if a malicious platform, or programming error, creates a situation in which some critical stage of the agent's task is unable to finish because more work is continuously created for it to do. Agent livelock differs from agent deadlock in that the livelocked agent is not blocked or waiting for anything, but is continuously given tasks to perform and can never catch up or achieve its goal. EAVESDROPPING

The classical eavesdropping threat involves the interception and monitoring of secret communications. The threat of eavesdropping, however, is further exacerbated in mobile agent systems because the agent platform can not only monitor communications, but also can monitor every instruction executed by the agent, all the unencrypted or public data it brings to the platform, and all the subsequent data generated on the platform. Since the platform has access to the agent's code, state, and data, the visiting agent must be wary of the fact that it may be exposing proprietary algorithms, trade secrets, negotiation strategies, or other sensitive information. Even though the agent may not be directly exposing secret information, the platform may be able to infer meaning from the types of services requested and from the identity of the agents with which it communicates. For example, someone's agent may be communicating with a travel agent, although the content of the message may not be exposed, this communication may indicate that the person on whose behalf the agent is acting is planning a trip and will be away from their home in the near future. The platform may share this information it has inferred with a suitcase manufacturer that may begin sending unsolicited advertisements, or even worse, the platform administrators may share this information with thieves who may target the home of the traveller. ALTERATION

When an agent arrives at an agent platform it is exposing its code, state, and data to the platform. Since an agent may visit several platforms under various security domains throughout its lifetime, mechanisms must be in place to ensure the integrity of the agent's code, state, and data. A compromised or malicious platform must be prevented from modifying an agent's code, state, or data without being detected. Modification of an agent's code, and thus the subsequent behaviour of the agent on other platforms, can be detected by having the original author digitally sign the agent's code. Detecting malicious changes to an agent's state during its execution or the data an agent has produced while visiting the compromised platform does not yet have a general solution. The agent platform may be running a modified virtual machine, for example, without the agent's knowledge, and the modified virtual machine may produce erroneous results.

A mobile agent that visits several platforms on its itinerary is exposed to a new risk each time it is in transit and each time it is instantiated on a new platform. The party responsible for the malicious alteration of an agent's code, state, or data if not immediately detected may be impossible to track down after the agent has visited other platforms and undergone countless changes of state and data. Although check-pointing and rollback of mathematical computations may be possible in non-agent environments, mobile agent frameworks make this task extremely difficult since an agent's final state and data on a platform may be the result of a series of non-deterministic events that depend on the behaviour of autonomous agents whose previous behaviour cannot be recreated.

The security risks resulting from an agent moving from its home platform to another is referred to as the "single-hop" problem, while the security risks resulting from an agent visiting several platforms is referred to as the "multi-hop" problem. The risks associated with the single-hop problem are easier to mitigate than the risks associated with a multi-hop scenario, since the protection mechanisms within the trust environment of the home platform are more difficult to use in the latter situation.

Agent platforms can also tamper with agent communications. Tampering with agent communications, for example, could include deliberately changing data fields in financial transactions or even changing a "sell" message to a "buy" message. This type of goal oriented alteration of the data is more difficult than simply corrupting a message, but the attacker clearly has a greater incentive and reward, if successful, in a goal-oriented alteration attack.


The other-to-agent platform category represents the set of threats in which external entities, including agents and agent platforms, threaten the security of an agent platform. This set of threats includes masquerading, denial of service, unauthorized access, and copy and replay. MASQUERADE

Agents can request platform services both remotely and locally. An agent on a remote platform can masquerade as another agent and request services and resources for which it is not authorized. Agents masquerading as other agents may act in conjunction with a malicious platform to help deceive another remote platform or they may act alone. A remote platform aan also masquerade as another platform and mislead unsuspecting platforms or agents about its true identity. UNAUTHORIZED ACCESS

Remote users, processes, and agents may request resources for which they are not authorized. Remote access to the platform and the host machine itself must be carefully protected, since conventional attack scripts freely available on the Internet can be used to subvert the operating system and directly gain control of all resources. Remote administration of the platform's attributes or security policy may be desirable for an administrator that is responsible for several distributed platforms, but allowing remote administration may make the system administrator's account or session the target of an attack. DENIAL OF SERVICE

Agent platform services can be accessed both remotely and locally. The agent services offered by the platform and inter-platform communications can be disrupted by common denial of service attacks. Agent platforms are also susceptible to all the conventional denial of service attacks aimed at the underlying operating system or communication protocols. These attacks are tracked by organizations such as the Computer Emergency Response Team (CERT) at the Carnegie Mellon University and the Federal Computer Incident Response Capability (FedCIRC). COPY AND REPLY

Every time a mobile agent moves from one platform to another it increases its exposure to security threats. A party that intercepts an agent, or agent message, in transit can attempt to copy the agent, or agent message, and clone or retransmit it. For example, the interceptor can capture an agent's "buy order" and replay it several times, having the agent buy more than the original agent had intended. The interceptor may copy and replay an agent message or a complete agent.


When mobile agents visit a sequence of hosts, it is desirable that the information that they gather is protected from attackers, including subsequent potentially malicious hosts to which the agents will migrate. Karjoth et al. [1998] define a number of security properties that should be achieved with respect to an attacker that has captured a mobile agent holding a chain of encapsulated information:

Data Confidentiality: Each offer oi (i = 1, ..., n) that is encapsulated in Oi is encrypted with the originator S0's public key k0. Only S0 can decrypt it to extract the offer, thus confidentiality is preserved.

Non-reputability: Each offer oi (i = 1, ..., n) that is encapsulated in Oi is signed by Si with ki. Therefore, Si cannot deny its offer oi once the agent carrying Oi returns to the originator S0.

Forward Privacy: Each offer oi (i = 1, ..., n) that is encapsulated in Oi is first signed by Si but then encrypted with S0's public key k0. Therefore, the identity of Si will not be disclosed to others (except S0) by examining Oi. In addition, as a random number ri is used in computing the checksum hi, it reveals no identity information by examining hi. However, as σi will be sent to Si+1 and Si+2 in order to verify that two adjacent hosts are different on the agent migration path, the identity of Si will be disclosed to S i+1 and S i+2. This implies a slight weakening of forward privacy in our protocol.

Strong Forward Integrity: Each offer oi (i = 1, ..., n) that is encapsulated in Oi is signed by Si. Any change to the signed offer will be detected. Furthermore, even Si cannot change its own encapsulated offer Oi in the chain O1...Oi...On without being detected. Suppose Si wants to replace oi with òi. To make this change undetected, Si needs to get a new countersignature Ői=Sigμi-1(tempi ) from Si-1 which should also satisfy

H(Oi, ri+1, Si+2) = H(Ői, ri+1, Si+2). Even if Si-1 is willing to collude on generation of Ői, the equation will not be satisfied under our assumption of collision-free hash function.

Publicly Verifiable Integrity: Each encapsulated offer oi (i = 1, ..., n) contains Si temporary public key μi that is certified by Si-1 with its temporary private key μi-1. With Oi, anyone can obtain μi and use it to verify Oi+1. Therefore, the integrity of O1...On is publicly verifiable.

Insertion Resilience: As all encapsulated offers O1...On are chained, if a new encapsulated offer Ox is inserted between Oi and Oi+1 without being detected, some chaining relations have to be changed in Oi and Oi+1. Suppose an attacker Sx tries to insert Ox as follows.

hx = H(Oi; rx; S i+1)

tempx = Enck0 (Sigkx(ox, μx, σi-1, σi), rx), hx, μx

Ox = Sigμi (tempx)

σx = Sigkx (hx)

This implies that Sx at least needs to ask Si to counter-sign tempx, and ask Si+1 to replace its signature in temp i+1 as Sigki+1(o i+1, μ i+1, σi, σx). So it is impossible for Sx to insert Ox without collusion with Si and Si+1.

Truncation Resilience: The chaining mechanism used in the insertion defence also works for the truncation defence. Suppose an attacker Sx tries to truncate the encapsulated offers O1...Oi, Oi+1... from Oi+1 thereafter and may also add Ox after Oi. Then, Sx needs to revise Oi as follows.

Ћi = H(Oi-1, ri, Sx)

temp`i = Enck0(Sigki (oi, μi, σi-2, σi-1), ri), Ћi, μi

O`i = Sig μ` i -1 (temp` i )

σ`i = Sig k` i (h` i)

Obviously, Sx is unable to make the above revisions without collusion with Si and S i-1. In other words, our protocol defends against truncation attacks if there are no more than two colluders. A straightforward extension of our protocol is possible to defend truncation attacks with more colluders.

A number of solutions and tools for partial result encapsulation and chaining have been proposed that offer (a subset of) these properties [Karjoth et al. 1998; Loureiro et al. 1999; Yee 1999; Young and Yung 1997]. These solutions are usually based on the normal cryptographic primitives: hosts digitally sign the data that they give to the agent, and the data are encrypted with the public key of the agent owner; the "chaining" property is, for example, provided by including the hash of the previously gathered data and the identity of the next host into the current data before signing them. Note that flaws have been identified in some of the proposed protocols [Roth 2001].

Instead of cryptographically preventing attackers from tampering with agent data, it might be sufficient in some applications to detect tampering in some other way. For example, dummy data items can be inserted by the agent owner that will not be modified by legitimate hosts. If these "detection objects" (see Meadows [1997]) have not been modified, then probably the real data have also not been corrupted.

Several degrees of agent's mobility exist, corresponding to the existing possibilities of relocation code and state information, including the values of instance variables, the program counter, execution stack, etc. The mobile technologies can be divided into two groups:

Weakly Mobile: only the code is migrating no execution state is sent along with an agent program.

Strong Mobile: a running program is moving to another execution environment (along with its particular state).

In this thesis we discuss the agent system mobile in the strong sense.


Each of these protocols has distinct phases: Initial setup by the originator, initial visit on intermediate hosts, updating of data, and verification of data integrity. The originator programs the agent with the information required by the first host on its itinerary. Each host is visited at least once. If the host offers a bid, a MAC is calculated on it and the bid is added to the agent data collection set. If a host later decides to update the bid it earlier made, it can do so and the MAC is recomputed on the new bid. Finally the source system verifies the integrity of the agent data when it returns.



Source System of the Agent (Origin of Mobile Agent)

Si (i>=1)

Set of hosts the Agent visits (intermediate Hosts)


Original Bid made by host Si


Encapusalated offer from Si


Cryptographic hash function


Nonce generated by Si


Message Authentication Code generated using secret key ki

Each of the protocols discussed has a common sequence of phases: Initial setup by originator, initial visit on intermediate hosts, update of data and verification of data integrity. The agent visits a sequence of hosts s1, s2,, and obtain an offer oi from each host, where an offer includes not only a price but some indication of the source of the offer, usually set of offers ω, a set of encapsulated offers Ω and key k, and we use subscript to denote these values over time. For example, ωi represents the value of ω after the agent has visited the ith host.


Yee's Strong forward integrity, which says none of the offers in the agent data can be modified without detection by the originator, was extended by others. Each offer in the data set is chained to the next one using the identity of the next host to be visited by the agent. Upon agent return, for each visited host, the originator decrypts the random nonce and generates the secret keys. If the chaining relation fails at a particular point, all subsequent offers are rejected.

As the agent follows its itinerary, each host generates a random nonce ri, which serves as a token of the agent instance, and creates a key from this data and the identity of the next host to be visited by the agent.

Setup on Source System

S0 -> S1:

ω0 = Ø; Ω0 = Ø

K1 = random initial key

Initial Visit on a host

Encapsulated Offer

Oi = (oi, MACKi(ri, oi, Si+1))


Si -> Si+1:

Ri = ENC0(ri) ; ωi = ωi-1 U {oi, Ri }

Ωi = Ωi-1 U {Oi}; Ki+1 = h(ki, ri, oi, Si+1)

Each host generates a random nonce ri and encrypts it using the originator's public key to include the offer from ith and the identity of the i+1 (next) host. The value ri is an input to the computation of the next secret key ki+1. The term ri prevents a host si from being able to modify the offers of hosts that follow it, since it cannot identify the chaining value that must be inserted into the encapsulated offer of the hosts that follow it. Since the offer itself is used in computing the key for the next host, offers may not be changed, and a new key must be generated each time when the agent re-visits a host.

Update: (Changing a previous offer oj)

Encapsulated Offer

Oi = (oi, MAXCkj (ri, oi, Si+1))


Si - > Si+1:

Ri = ENC0(ri) ; ωi= ωi-1 U {(oi, Ri) }

Ωi = Ωi - 1 U {Oi}; Ki+1 = h(ki, ri, oi, Si+1)

The chaining relation ensures that none of the offers in the agent can be modified by a malicious host, thus ensuring strong forward integrity. A limited degree of insertion resilience is ensured by this protocol. A malicious server cannot insert spurious offers into the chain of hosts visited prior to it. However, it is possible for a malicious server to insert data in the chain from this point onward, since the technique explicitly allows a host to do so. In a chain of encapsulated offers O1, … Om, it is possible to detect any truncation at k < m, assuming that m is not malicious. However, a malicious host can truncate all the offers following its own and can insert fake offers.


One of the limitations of this technique is that verification by the originator must be performed sequentially, which means that the knowledge of the sequence of hosts visited is mandatory for verification. In addition, multiple visits to a host for updates leads to a prohibitive increase in the size of the agent as old data may not be removed.


The detailed description of the Set Authentication Code method and the cryptographic mechanisms involved in this method is described by G.karjoth, N.Asokan, and C.Gulcu [10].

Let (ki)1≤i≤n be a set of secret keys, (oi)1≤i≤n be a set of offers, and (Oi)1≤i≤n be a set of encapsulated offers, with Ω = {Oi | 1≤i≤n}, as before. We use a function Г(Ω) which gives a cryptographic 'integrity proof' for set Ω, and has the following properties (for specific function satisfying these properties, see [10]; however, note that the insert and delete notations are for our own simplification, but directly maps to operations on the integrity proof in the cited paper):

Г(Ω) can't be computed without knowledge of the Oi values (or, equivalently, without knowledge of the oi and ki values).

There exists an efficient function insert() such that given an integrity proof value g = Г({x1,…xk}) for some set X = {x1,…xk} (the xi values do not have to be known), and a new value y,

insert(g,y) = Г(X U {y}) = Г({x1, … xk,y}).

There exists an efficient function delete() such that given integrity proof value g = Г({x1,…xk}) for some set X = {x1,…xk}, and a specified value xi,

delete(g,y) = Г(X - {xi})

= Г(xi,…,xi-1,xi+1,…,xk})

Removing or modifying an offer oi, while maintaining the integrity of the set, requires knowledge of the corresponding secret key ki.

The function Г() is the "Set Authentication Code" which can be used to securely collect offers from various hosts in such a way that the set can be verified by any party that knows the key ki and offers oi for all 1 ≤ i ≤ n.

Each visited host Si>0 (i.e., each host except the originator) exchanges a shared secret key ki with source So, using the Diffie-Hellman key exchange technique. The originator, So, then sends the agent to visit a set of hosts S1, S2,…,Sn with an initial set integrity value Г0 and empty data collection list ω0. The set authentication code function, Г(), is maintained over the set of the MACs calculated on the offers (i.e., encapsulated offers) through the use of the insert and delete functions. This set is conceptually the same as the Ω in the previous methods, but may not be carried with the agent in the set authentication code method. In this case, the single integrity proof value substitutes for the set Ω, would allow hosts to modify the integrity proof to change bids.

Setup on Originator

S0 -> S1:

ω0 = Ø; Г0 = Г(Ø)

Initial visit on a host

MAC on the offer

Ki = key from DH key exchange

Oi = MACki(oi)


Si -> Si+1 ; ωi = ωi-1 U {oi}

Г i = insert (Г i-1, Oi)

Update (Changing a previous offer oj)

MAC on the offer

O i = MACki(oi)


Si -> S i+1

ωi = ωi-1 - {oj} U {oi}

Г i = insert(delete(Г i-1, Oj),O i )

None of the offers in the data set can be modified by a malicious host, since the encapsulated offer and the secret key is known only to the host and to the originator. In addition, since each host must exchange a secret key with the originator using the Diffie-Hellman key exchange, and no unauthorized offers can be inserted into the agent data set, assuming that the original key exchange is secure. If the original key exchange is compromised (for example 'Man-In-The-Middle' Attack), unauthorized offers can be inserted into the agent data. If two hosts collude, they can replace the original dataset with a new dataset from the start of the truncated path, so truncation resilience is limited. The path integrity needs to be verified to ensure complete truncation resilience.


One of the limitations of this method is that a shared, secret key is required between originator and each host that the agent visits. To perform the integrity check verification, the originator must be in possession of all the secret keys. The agent can visit a random host but that host then needs to exchange a secret key with the originator, using the Diffie-Hellman key exchange. If the host is not known at the time of agent creation, then the originator must remain online to participate in this exchange. Furthermore, the basic Deffie-Hellman key exchange method is vulnerable to 'man-in-the-middle' attacks, a fact that compromises the security of this technique.


RSA Key Exchange is a popular key exchange technique where the Originator O0 generates an RSA public key OPk and is sent to all the hosts in the network. Each host then generates its own key Ki, encrypts it with the public key of the originator and sends it back to the originator. Now that the Originator has the key the encrypted messages from each host is decrypted with the respective key of the host. The complete life cycle of an agent starting from the originator, collecting the message/bid from the host, performing partial encryption using the RSA key and moving back to the originator is shown in Fig 2.2. The MAC is calculated on with the random nonce generated by the originator for each host ri, actual offer (message) oi, and the Host id Hi. This makes the partial encryption of the message from each host more secure and can be decrypted only by the Originator as only the originator knows both the key and the random nonce. The length of the key can be chosen depending on the complexity required by the application. As the key length increases, the time taken for encryption & decryption also increases.

Setup on Source System

S0 -> S1:

ω0 = Ø; Ω0 = Ø

OPk = Public key set up by the originator

Ki = random initial key generated by each host

ri = random nonce generated by originator for each host

Initial Visit on a host

Encapsulated Offer

Oi = (oi, MACKi(ri, oi, H0))


Si -> Si+1:

Ri = ENC0(ri) ; ωi = ωi-1 U {oi, Ri }

Ωi = Ωi-1 U {Oi}; Ki+1 = h(ki, ri, oi, Si+1)

The proposed approach of partially encrypting the messages (offers) using RSA key encryption technique not only eliminates the Man-in-the-Middle attack but also makes the approach best suitable for implementing all the seven security properties defined.

Advantages of RSA Keys:

The key can be reused for subsequent visits to the host, only initial key generation and message encryption is needed.

Though RSA encryption and decryption is costly, however, reusing the key in the subsequent visits makes it more affordable than Deffie-Hellman key exchange technique.

The size of the mobile agent is less using RSA keys as it only carries encrypted secret keys.


The application is tested with the Agent visiting from 2 to 15 hosts and querying status of different services. The Agent is tested for querying 2 to 5 services on each host and the average latency of 50 ms at each host. The first section of the performance evaluation is focused on the key generation time and the size of the agent during key exchange process. Graph 1 depicts that the key generation time between Deffie-Hellman Key exchange technique and the RSA Key technique. The graph clearly indicates the key generation time for RSA is lesser than the Deffie-Hellman key exchange technique. Though the RSA data encryption is costlier than the regular encryption technique, the key can be reusable.

Graph 2 indicates the size of the Agent during key exchange. The key size can be determined by the programmer and in this setup; a 512 bit key is used. The size of the Agent while using RSA key exchange technique is comparatively more than Deffie-Hellman technique, however the key can be reused, thus decreases the cost and network bandwidth usage.

Graphs 3 & 4 depicts the performance of the Agents with a processing time of 500 ms and 50 ms respectively at each port. In either case, RSA Key encryption technique's perforce is getting better with the number of hosts visited when compared to the Deffie-Hellman technique.



Conventional Mobile Agents have the capability to communicate with only one port or application when it reaches a host. These agents find their applications in e-commerce, e-bidding and other transactional applications where the data carried by an agent is considered confidential and the agent is communicating with a set of hosts on an un-trusted network. However, given a scenario of a trusted network like an enterprise network and agents are used to monitor parameters of the network like network traffic, network bottlenecks, services on host servers, network and server load factors, CPU & memory utilization there is a need for agents that can perform multiple tasks at a given time. The agents that are designed to perform multiple tasks on a given host can be considered as Adaptive Agents through the scope of this work.

As discussed in Chapter 2, a reusable RSA key is exchanged for each host with the originator. The agents continue to use the same RSA key encryption to secure the data and partial data encryption is performed on the data collected at each host. However, all the data (messages) obtained from the host is encrypted by the same RSA key shared by the host unlike a separate RSA key is used to encrypt the data from each port. Using the same RSA key serves the following purpose

As the number of ports used on a host are dynamic and varies during each visit, having a separate RSA key for each port make the agent cumbersome

Since the all the ports on a host are still controlled by the same Agent Server application, a separate RSA key is not required

Individual RSA keys would increase the computation complexity and would also increase the agent size thus using more network bandwidth

Technically it would be similar to asynchronous remote procedure call

Thus a unique key is used for each host to encrypt the data (messages) received from a host. The originator agent server application is additionally programmed to decrypt each message, separate the messages collected from each port/application and send it to appropriate application for processing. The dynamic agents find their use in applications like distributed computing and distributed decision making on enterprise networks.


Conventional mobile agents are designed to communicate with only one port/application on each host it arrives. These agents collect message/offer from one or more hosts, encrypt the offer and once the iteration on all the hosts it is designated to reach is complete, the data is delivered to the Originator. These agents find their usage in applications where the Data in the agent source encrypted with the public key need to be secure and the agent is visiting a set of hosts on an un-trusted network like internet. Fig 3.1 depicts the conventional mobile agent.


The conventional mobile agents are usually implemented using JADE. Java Agent DEvelopment Framework (JADE) is an open source mobile agent framework that can be used to simplify implementation of Agents. It simplifies the implementation of multi-agent systems through a middle-ware that complies with the FIPA specifications and through a set of graphical tools that supports the debugging and deployment phases. The agent platform can be distributed across machines (which not even need to share the same OS) and the configuration can be controlled via a remote GUI. The configuration can be even changed at run-time by moving agents from one machine to another one, as and when required. JADE is completely implemented in Java language and the minimal system requirement is the version 1.4 of JAVA (the run time environment or the JDK). The synergy between the JADE platform and the LEAP libraries allows obtaining a FIPA-compliant agent platform with reduced footprint and compatibility with mobile Java environments down to J2ME-CLDC MIDP 1.0.


Mobile Agent Service Tracking System (MASTS) is an online service monitoring system that has the ability to check the status of all the essential Services in a trusted enterprise network. The system is designed to start from an agent server and check all the Servers on an enterprise network that hosts services that are essential for an enterprise network. For example, there could be different servers hosting services like DNS, DHCP, Account Manager, Anti-virus, Firewall services etc on an enterprise network and it is important that all the services on these servers are up 24X7 to support an enterprise network.

Mobile Agent Service Tracking System (MASTS) is an Agent based monitoring system that visits each of the servers and checks the status of each service on the server. The information is consolidated and presented to the Agent host server that would consolidate and publish the service status periodically as defined during the setup. The system implemented is designed to collect the status and present on a manual trigger. JADE is used to implement the proposed MASTS.

The messages triggered by the agent reaches the JADE container and the messages are communicated to each of the server from JADE server using Agent Control Language (ACL). The architectural diagram depicting the transfer of messages from Agent Server to each of the hosts using JADE server is shown below.

In this research, JADE has been adopted among various multi-agent platforms as the underlined architecture and implementation of Multi Agent Service Monitoring System (MASTS) due to the following advantages

Distributed autonomous applications development - In order to achieve the objectives of MASTS, agents that are autonomous, intelligent, and capable of communicating and collaborating need to be implemented. JADE simplifies such a development.

Negotiation and coordination - In MASTS, JADE provides easy-to-use software libraries (i.e. patterns of interaction between agents) to solve negotiation and coordination among a set of agent, where the resources and the control logics are distributed in the environment.

Pro-activity - JADE agents have been designed to control their own thread of execution. These agents can be easily programmed to initiate the execution of actions without human intervention just on the basis of pre-defined goals and state changes. The property of proactivity is essential in designing physician agents of MASTS, which requires controlling their own actions guided by regulations.

Multi-Party applications - Peer-to-peer architectures that JADE used are more efficient than client-server architectures for developing multi-party applications. Sometimes, the server might become the bottleneck and the point of failure in the entire system. The implementation of MASTS based on JADE architecture that allows

Clients (medical staff or patients) to communicate each other without the intervention of a central server and subsequently reduces the network traffic.

Interoperability - JADE complies with the FIPA standard that enables end-to-end interoperability between agents of different agent platforms.

Versatility - JADE provides a homogeneous set of APIs that are independent from the underlying network and Java version. It also provides the same APIs for J2EE, J2SE, and J2ME environments. This feature makes MASTS a heterogeneous client (PC, PDA, mobile phone, etc.) environment.

Ease of use - JADE APIs and ready to use functionalities can shorten the system development cycle (some estimations have been give that indicates the reduction of development time cab be up to 30%).

The JADE-implemented MASTS is hence expected to be capable of integrating disparate information sources and isolated heterogeneous components to perform autonomous health monitoring. The code implementing JADE Agent is shown in the fig below.


Conventional Mobile Agents can are programmed to perform a single task/operation during each visit to a host. However, in an enterprise network where each server/host is configured to perform multiple operations, there would be a necessity to multiple tasks/operations to be performed on each server/host. One such example is discussed in section 3.3. Mobile Agent Service Tracking System (MASTS) is an application designed during the course of this work to check the status of different services mounted on each host. The Agent is designed to visit each host, check the status of a service at each host and report at the agent server. The application is further enhanced to Start/Stop/Restart the services on remote hosts from the Agent server. The details of further discussed in section 3.5.

The adaptive agents are programmed to dynamically change the message queue to adjust to the requirements of the host to be visited. There may be a necessity for the agent to track the status of 2, 3, 4 and so on services or communicate with multiple ports on each host it visits during its iteration. The conventional Agent having a static message queue doesn't find itself adapted to the dynamic tasks to be performed or communicate with multiple ports on each of the host it visits. To implement a similar functionality using conventional agents, the agents need to visit a host multiple times to know the status of each service or to communicate with each port. These multiple iterations require a new ag