MOBILE AGENT SECURITY – AGLET

PLATFORM

Thesis

Submitted in partial fulfillment of the requirements for the degree of

MASTER OF TECHNOLOGY in

COMPUTER SCIENCE & ENGINEERING – INFORMATION SECURITY

by

MANE DNYANESHWAR RANGNATH

(08IS07F)

DEPARTMENT OF COMPUTER ENGINEERING

NATIONAL INSTITUTE OF TECHNOLOGY KARNATAKA

SURATHKAL, MANGALORE-575025

June, 2010

D E C L A R A T I O N

I hereby declare that the Report of the P.G. Project Work entitled “MOBILE

AGENT SECURITY – AGLET PLATFORM” which is being submitted to the

National Institute of Technology Karnataka Surathkal, in partial fulfillment of the

requirements for the award of the Degree of Master of Technology in Computer

Science and Engineering – Information Security in the Department of Computer

Engineering, is a bonafide report of the work carried out by me. The material contained

in this report has not been submitted to any University or Institution for the award of any

degree.

08IS07F Mane Dnyaneshwar Rangnath

-------------------------------------------------------

(Register Number, Name and Signature of Student)

Department of Computer Engineering

Place: NITK, SURATHKAL

Date:

C E R T I F I C A T E

This is to certify that the P.G Project Work Report entitled “MOBILE AGENT

SECURITY – AGLET PLATFORM” submitted by MANE DNYANESHWAR

RANGNATH (Register Number: 08IS07F) as the record of the work carried out by him, is

accepted as the P.G Project Work Report submission in partial fulfillment of the

requirements for the award of degree of Master of Technology in Computer Science and

Engineering – Information Security in the Department of Computer Engineering, National

Institute of Technology Karnataka, Surathkal.

Mr. B.R. Chandavarkar

Assistant Professor

Department of Computer Engineering

NITK Surathkal

Mr. Alwyn R Pais

Assistant Professor

Department of Computer Engineering

NITK Surathkal

Chairman- DPGC

Dedicated to

my family, teachers

and

friends

ACKNOWLEDGEMENT

I take this opportunity to express my deepest gratitude and appreciation to all

those who have helped me directly or indirectly towards the successful completion of this

project.

Foremost, I would like to express my sincere gratitude to my guides Mr. Alwyn

R. Pais, Assistant Professor, Mr B.R. Chandavarkar, Assistant Professor and Dr.

Asoke Talukder, Adjunct Faculty, Department of Computer Engineering, NITK

Surathkal. Their advice, constant support, encouragement and valuable suggestions

throughout the course of my project work helped me successfully complete the project.

This project drew upon the knowledge and experience of my guides. Without their

continuous support and interest, this thesis would not have been the same as presented

here.

I am thankful to Dr. Santhi Thilagam, Head, Department of Computer

Engineering for her co-operation and for providing necessary facilities throughout the

M.Tech. program.

Besides my guides, I would like to thank entire teaching and non-teaching staff in

the Department of Computer Engineering, NITK for all their help during my tenure at

NITK. I am grateful to all my friends specially Mr. Nrupatunga Y., for their help,

encouragement and invaluable suggestions.

Last but not least, I am thankful to my parents to whom I am greatly indebted for

their support and encouragement to pursue my interests.

Mane Dnyaneshwar Rangnath

ABSTRACT

Mobile Agents is a new paradigm for distributed computing where security is of

paramount importance to gain widespread acceptance for this platform in a large scale

distributed environment. The aglet framework remains highly vulnerable to Denial of

Service (DoS) attacks despite multilayered security provided by existing frameworks.

The first layer of security is provided by the Java Virtual Machine. The second layer

of security is provided by the security manager of aglet platform and the final layer is

Java’s new Security API. Attacks against availability mainly attempt to overload the

resources or make a particular facility unavailable at a certain time, thus making them

unavailable to genuine entities. Attacks in this category are usually referred as Denial

of Service (DoS) attacks.

In this project, we have demonstrated detection of DoS attack on aglet platform

caused due to cloning and threads creation. Also, project elucidates mitigation

techniques for the same. The algorithm proposed in this work is capable of detecting

as well as mitigating the mentioned DoS attacks thus increasing the availability of the

platform. The overhead introduced on the Aglet platform by the proposed solution is

negligible compared to the security it offers.

Keywords: Mobile Agent Security, Aglets, Mobile Agents, Mobile Agent Platform

Security, Mobile Agent System.

i

TABLE OF CONTENTS

Page No.

Title

Declaration

Certificate

Dedication

Acknowledgement

Abstract

Table of contents i

List of figures iv

List of tables v

Chapter I INTRODUCTION 1

1.1 Aglets Architecture 2

1.1.1 Aglets Runtime Layer 2

1.1.2 Communication Layer 3

1.2 Aglets Life Cycle Model 4

1.3 Aglet Object Structure 5

1.4 Benefits of using Mobile Agents 6

1.5 Application of Mobile agents 8

1.6 Motivation 10

1.7 Problem Statement 10

1.8 Organization of the Thesis 11

Chapter II RELATED WORK 12

ii

Chapter III IDENTIFIED ATTACKS ON AGLET PLATFORM 17

3.1 Security in Aglets 17

3.1.1 Domain Authentication 17

3.1.2 Integrity-Checked Communication 18

3.1.3 Authorization of Aglets 19

3.2 Malicious Agents 21

3.3 Identified Attack on Aglet platform 21

3.3.1 Clone Attack 22

3.3.2 Attack on Virtual Memory 24

Chapter IV PROPOSED SOLUTION 27

4.1 Clone Attack 27

4.1.1 What is “OutOfMemoryError” Exception? 27

4.1.2 Clone Attack Mitigation Algorithm 28

4.1.3 Working of checkLoad function 29

4.2 Attack on Virtual Memory 30

4.2.1 Thread Monitor Algorithm 31

Chapter V PERFORMANCE EVALUATION 32

5.1 Performance Analysis of Solution 32

5.1.1 Normal execution of Aglet platform without any

monitoring modules 32

5.1.2 Clone Attack 33

5.1.3 Attack on Virtual Memory (Resource Thread) 36

5.2 Performance Analysis of Aglet platform 37

5.2.1 Clone Attack 37

5.2.2 Attack on Virtual Memory 40

Chapter VI CONCLUSION AND FUTURE WORK 42

iii

APPENDIX-I TAHITI USER’S GUIDE 43

REFERENCES 50

RESUME (Bio-Data) 52

iv

LIST OF FIGURES

Fig

No. Description Page No

1.1 Mobile Agent System 1

1.2 Aglet Architecture 2

1.3 Communication Layer Architecture 4

1.4 Aglet Life-cycle 5

1.5 Aglet Object Structure 6

3.1 Security setting in aglets.policy file 20

3.2 Variation of number of threads depending on thread stack size 23

4.1 Flow Chart-Clone Attack Mitigation 29

4.2 Flow Chart - Mitigation of Attack on Virtual Memory 31

5.1 Number of Agents Vs Memory Usage (Bytes) 33

5.2 Number of genuine Agents Vs Memory Usage (KBytes) 34

5.3 Number of genuine Agent Vs Attack detection time (ms) 35

5.4 Number of genuine Agents Vs Mitigation Algorithm Processing Time (ms) 35

5.5 Time (sec) Vs CPU Usage (%) 36

5.6 Number of genuine Agents Vs Mitigation Algorithm Processing Time (ms) 37

5.7 Execution Time (sec) Vs CPU Usage (%) 39

5.8 Execution Time (sec) Vs Memory Usage (Bytes) 39

5.9 Execution Time (sec) Vs CPU Usage (%) 41

5.10 Execution Time (sec) Vs Memory Usage (Bytes) 41

v

LIST OF TABLES

Table

No. Description Page No

5.1 Clone Attack – Execution Time 38

5.2 Attack on Virtual Memory – Execution Time 40

1

CHAPTER 1

INTRODUCTION

Mobile Agent System (Ma and Tsai, 2006) consists of two main components: mobile

agents and mobile agent platforms (Aglet platform i.e. Tahiti server) as shown in

figure 1.1. Mobile agents are software which are goal-directed and can automatically

suspend their execution on one platform and migrate to another platform, where they

resume execution to accomplish their tasks.

Mobile agent platforms (Ma and Tsai, 2006) are execution environments for mobile

agents on different computers, including the home platform and guest platforms. A

home platform of a mobile agent is responsible for creating, initializing, dispatching,

receiving, and eliminating a mobile agent. The home platform environment is the

most secure environment.

Home Platform

Agent Platform

Agent Platform

Agent Platform Agent

Agent Agent

Agent

Figure 1.1: Mobile Agent System

2

1.1. AGLETS ARCHITECTURE

An Aglet is a Java-based mobile agent system (Lange and Oshima, 1998). The Aglets

architecture consists of two layers and APIs that define interfaces for accessing their

functions as shown in figure 1.2. The Aglets runtime layer is the implementation of

the Aglet API, and defines the behavior of the API components, such as AgletProxy

and AgletContext. It provides the fundamental functions for aglet to be created,

managed, and dispatched to remote hosts. The communication layer is primarily

responsible for transferring a serialized agent to a destination and receiving it. It also

supports agent-to-agent communication and facilities for agent management.

1.1.1. Aglets Runtime Layer

The Aglets runtime layer implements Aglets interfaces such as AgletContext. It also

consists of a core framework and subcomponents. The core framework provides the

following mechanisms fundamental to aglet execution:

Serialization and De-serialization of aglets

Class loading and transfer

Reference management and garbage collection

Aglet API

Aglets Runtime Layer

Core Framework

- SecurityManager

- CacheManager

- PersistenceManager

Communication API

Communication Layer

- ATP, HTTP

Figure 1.2: Aglets Architecture

3

The subcomponents are designed to be extensible and customizable because these

services may vary depending on requirements or environments. For example, the

PersistenceManager for applets may store deactivated aglets only in the memory, or

else on the Web Server if it can do so. In other cases, it may have to use the default

security manager set by the Web browser.

PersistenceManager

The PersistenceManager is responsible for storing the serialized agent, consisting of

the aglet's code and state into a persistent medium such as a hard disk.

CacheManager

The CacheManager is responsible for maintaining the bytecode used by the aglet.

Because the bytecode of an incoming aglet needs to be transferred when the aglet

moves to the next destination, the CacheManager caches all bytecode even after the

corresponding class has been defined.

SecurityManager

The SecurityManager is responsible for protecting aglet platforms and aglets from

malicious entities. It hooks every security-sensitive operation and checks whether the

caller is permitted to perform it. There is only one instance of SecurityManager in the

system, and it cannot be altered once it has been installed.

These components are defined as an interface or an abstract class, so server

developers can implement these components for their own use and plug them at

runtime.

1.1.2. Communication Layer

The Aglets runtime itself has no communication mechanism for transferring the

serialized data of an aglet to destinations. Instead, the Aglets runtime uses the

communication API that abstracts the communication between agent systems. This

API defines methods for creating and transferring agents, tracking agents, and

4

managing agents in an agent-system and protocol-independent way. The architecture

of communication layer is as shown in figure 1.3.

Figure 1.3: Communication Layer Architecture

The current Aglets use the Agent Transfer Protocol (ATP) as the default

implementation of the communication layer. ATP is modeled on the HTTP protocol,

and is an application-level protocol for transmission of mobile agents. To enable

remote communication between agents, ATP also supports message-passing.

1.2. AGLET LIFE CYCLE MODEL

Aglet is a library written in Java which was introduced by IBM to support the

development of mobile agent. The execution environment within which Aglets are

executed is referred to as the Aglet’s Context and is responsible for enforcing the

security restrictions of the mobile agent.

Client/Sender Server/Receiver

MAFAgentSystem_AgletsImpl

ATP Daemon

RMI_daemon

CORBA/ORB

Aglets

Framework

Application

Aglets

Framework

MAFAgentSystem

ATP_Stub

RMI_Stub

CORBA

Communication

Layer

5

The different states in Aglet life cycle (Evens et al., 2007) are as follows:

Activated: Aglet is loaded from storage and allowed to resume execution.

Deactivated: Aglet’s execution is halted and its state is saved.

Cloned: Aglet is copied for concurrent execution.

Disposed: Execution of the aglet ceases permanently

Created: Aglet is initialized for execution

Dispatched: Aglet is sent to another execution context.

Retracted: Aglet is obtained from another execution context.

The Aglet Life cycle state diagram is shown in figure 1.4.

1.3. AGLET OBJECT STRUCTURE

The Aglet object structure is shown in figure 1.5. An AgletRef object is an internal

representation of an aglet object. It has all necessary components for the aglet: a

MessageManager to control incoming messages, and a ResourceManager to manage

resources consumed by the aglet as well as to manage its related resources such as

security information and the AgletInfo object. The AgletRef object is what the aglets

framework deals with. The latter has a reference table to store the mapping from the

AgletID to the actual aglet instance. An AgletRef object is created and inserted into

Aglet

Class

Aglet

Secondary

Storage

Context-B Context-A

Clone

Dispatch

Retract

Activate Deactivate Create

Dispose

Figure 1.4: Aglet Life-cycle

6

this table when an aglet is created or arrives, and removed from it when the aglet is

dispatched or disposed of.

1.4. BENEFITS OF USING MOBILE AGENTS

There are at least seven main benefits to start using mobile agents (Lange and

Oshima, 1999). Those are as follows:

1. They reduce the network load. Distributed systems often rely on communication

protocols involving multiple interactions to accomplish a given task. The result is

a lot of network traffic. Mobile agents allow users to package a conversation and

dispatch it to a destination host where interactions take place locally. Mobile

agents are also useful when reducing the flow of raw data in the network. When

very large volumes of data are stored at remote hosts, that data should be

processed in its locality rather than transferred over the network. The motto for

agent-based data processing is simple: Move the computation to the data rather

than the data to the computation.

Figure 1.5: Aglet Object Structure

Aglet

AgletRef

MessageManager

Properties

ResourceManager

AgletProxy

AgletProxy

Remote Server

AgletProxy

Messages

Reference Table

id = 0x01

id = 0x02

…

7

2. They overcome network latency. Critical real-time systems, such as robots in

manufacturing processes, need to respond in real time to changes in their

environments. Controlling such systems through a factory network of substantial

size involves significant latencies. For critical real-time systems, such latencies

are not acceptable. Mobile agents offer a solution, because they can be dispatched

from a central controller to act locally and execute the controller’s directions

directly.

3. They encapsulate protocols. When data is exchanged in a distributed system,

each host owns the code that implements the protocols needed to properly code

outgoing data and interpret incoming data. However, as protocols evolve to

accommodate new requirements for efficiency or security, it is cumbersome if not

impossible to upgrade protocol code properly. As a result, protocols often become

a legacy problem. Mobile agents, on the other hand, can move to remote hosts to

establish “channels” based on proprietary protocols.

4. They execute asynchronously and autonomously. Mobile devices often rely on

expensive or fragile network connections. Tasks requiring a continuously open

connection between a mobile device and a fixed network are probably not

economically or technically feasible. To solve this problem, tasks can be

embedded into mobile agents, which can then be dispatched into the network.

After being dispatched, the agents become independent of the process that created

them and can operate asynchronously and autonomously. The mobile device can

reconnect at a later time to collect the agent.

5. They adapt dynamically. Mobile agents can sense their execution environment

and react autonomously to changes. Multiple mobile agents have the unique

ability of distributing themselves among the hosts in the network to maintain the

optimal configuration for solving a particular problem.

6. They are naturally heterogeneous. Network computing is fundamentally

heterogeneous, often from both hardware and software perspectives. Because

mobile agents are generally computer and transport layer-independent (dependent

on only their execution environments), they provide optimal conditions for

seamless system integration.

8

7. They are robust and fault-tolerant. Mobile agents’ ability to react dynamically

to unfavorable situations and events makes it easier to build robust and fault-

tolerant distributed systems. If a host is being shut down, all agents executing on

that machine are warned and given time to dispatch and continue their operation

on another host in the network.

1.5. APPLICATION OF MOBILE AGENTS

There are no mobile agent applications, but there are plenty of applications that

benefit from using mobile agents. Several applications clearly benefit from the mobile

agent paradigm:

1. E-commerce. Mobile agents are well suited for ecommerce. A commercial

transaction may require real-time access to remote resources, such as stock quotes

and perhaps even agent-to-agent negotiation. Different agents have different goals

and implement and exercise different strategies to accomplish them. We envision

agents embodying the intentions of their creators, acting and negotiating on their

behalf. Mobile agent technology is a very appealing solution for this kind of

problem.

2. Personal assistance. Mobile agents’ ability to execute on remote hosts makes

them suitable as assistants performing tasks in the network on behalf of their

creators. Remote assistants operate independently of their limited network

connectivity; their creators can even turn off their computers. For example, to

schedule a meeting with several other people, a user can send a mobile agent to

interact with the agents representing each of the people invited to the meeting. The

agents negotiate and establish a meeting time.

3. Secure brokering. An interesting application of mobile agents is in collaborations

in which not all the collaborators are trusted. The parties could let their mobile

agents meet on a mutually agreed secure host where collaboration takes place

without risk of the host taking the side of one of the visiting agents.

4. Distributed information retrieval. Instead of moving large amounts of data to

the search engine so it can create search indexes, agent creators can dispatch their

agents to remote information sources where they locally create search indexes that

9

can later be shipped back to the system of origin. Mobile agents can also perform

extended searches that are not constrained by the hours during which a creator’s

computer is operational.

5. Telecommunication networks services. Support and management of advanced

telecommunication services are characterized by dynamic network reconfiguration

and user customization. The physical size of these networks and the strict

requirements under which they operate call for mobile agent technology to

function as the glue keeping the systems flexible yet effective.

6. Workflow applications and groupware. The nature of workflow applications

includes support for the flow of information among coworkers. Mobile agents are

especially useful here, because, in addition to mobility, they provide a degree of

autonomy to the workflow item. Individual workflow items fully embody the

information and behavior they need to move through the organization-independent

of any particular application.

7. Monitoring and notification. This classic mobile agent application highlights the

asynchronous nature of these agents. An agent can monitor a given information

source without being dependent on the system from which it originates. Agents

can be dispatched to wait for certain kinds of information to become available. It

is often important that the life spans of monitoring agents exceed or be

independent of the computing processes that created them.

8. Information dissemination. Mobile agents embody the so-called Internet push

model. Agents can disseminate information, such as news and automatic software

updates, for vendors. The agents bring the new software components, as well as

installation procedures, directly to customers’ computers where they

autonomously update and manage the software.

9. Parallel processing. Given that mobile agents can create a cascade of clones in

the network, another potential use of mobile agent technology is to administer

parallel processing tasks. If a computation requires so much processor power that

it must be distributed among multiple processors, an infrastructure of mobile agent

hosts can be a plausible way to allocate the related processes.

10

1.6. MOTIVATION

The security is an important issue in mobile agent framework, since such technology

potentially provides an easy method to propagate malicious code. Conversely, aglet

themselves may carry sensitive information, and so aglet must be protected from their

host environments. The current aglet frameworks address these requirements by

providing a multilayered approach to security. The first layer is provided by the Java

Virtual Machine itself. Incoming aglet code is subject to byte code verification before

execution. The second layer of security is provided by the security manager, which

allows customizable security policies for local and remote aglet in regard to host

resources. The final layer is Java’s new Security API, which provides services such as

encryption, authentication, and digital signatures. The framework is still vulnerable to

Denial of Service attacks.

1.7. PROBLEM STATEMENT

Attacks against availability mainly attempt to overload the resources or make a

particular facility unavailable at a certain time, thus making them unavailable to

genuine entities. Attacks in this category are usually referred as Denial of Service

(DoS) attacks. In this project, we propose detection and mitigation of the Denial of

Service attacks on Mobile Agent System – Aglet platform.

The scope of the project is to identify various mechanisms to materialize DoS attacks

on Aglet platform. Also, mitigation schemes need to be devised and integrated within

Aglet platform to thwart identified attacks.

11

1.8. ORGANIZATION OF THE THESIS

The remaining part of the thesis is organized as follows: Chapter 2 throws light on the

work carried out in the related area. It discusses work done by others which include

identification of attacks on the Mobile agents and mitigation techniques for the same.

Chapter 3 outlines various attacks to which Aglet platform is vulnerable. Some of the

discussed attacks are newly introduced which are contribution of this project. Chapter

4 elucidates detection and mitigation algorithm to identify attacks and further it details

proposed mitigation technique. Chapter 5 provides the performance evaluation of our

technique. Chapter 6 concludes the thesis along with the future work. Appendix-I

outline important instruction to configure and use Aglet platform (Tahiti server).

12

CHAPTER 2

RELATED WORK

Evens (Evens et al., 2007) has attempted to bridge the gap from theory to practice by

analyzing the security mechanisms available in Aglet. They have proposed several

mechanisms, stemming from theoretical advancements, intended to protect both

agents and hosts in order to foster the development of business applications that fully

exploit the benefits of agent technology. Their proposed mechanisms lay the

foundation for implementation of application specific protocols capable of

implementing access control, secured communication and ability to detect tampering

of agent data. They have demonstrated their contribution through application

scenarios of a prototyped Information Retrieval system.

Elhum (Elhum et al., 2008) has presented a new model for Aglet security based on

existing Aglets architecture. They propose use of a new service agent along with a

policy file incorporated with the existing Aglets architecture. This novel service agent

will control & co-ordinate all communication between the agent and the platform and

would provide an extra layer of security by a set of API. They claim to have enhanced

overall security of the platform using this extra layer of security. Service agent will

control authentication and will manage other resources. Policy file is used by service

agent for resource management. Service agent would also perform the message

communication and resource allocation job. Authentication part is enhanced by using

public/private key cryptography.

The protection mechanisms for mobile agents have been highlighted by Ismail

(Ismail, 2008). In these mechanisms, the authentication of mobile agents and the

access control to the system resources are controlled by the mobile-agents platform.

Each agent defines its own access control policy with regard to other agents using an

Interface Definition Language (IDL), thus enforcing modularity and easing

programming task. An evaluation of these mechanisms has also been conducted. An

13

important advantage of the proposed protection mechanisms are transparency to

agents and the portability of non-secure applications onto a secure environment.

Venkatesan (Venkatesan and Chellappan, 2008) have proposed a new Attack

Identification Scanner (AIS) to scan and kill the malicious agent from the malicious

host in the distributed environment using MIP (Malicious Identification Police). This

new Scanner overcomes the drawbacks present in the previous models for Agent

platform protection. The scanner will protect the platform and also identify the

malicious agent and malicious remote host.

Jansen (Jansen and Karygiannis, 2000) has come up with a technical report which

provides an overview of the range of threats facing the designers of agent platforms

and the developers of agent based applications. The report also identifies generic

security objectives, and a range of measures for countering the identified threats and

fulfilling these security objectives.

Borselius (Borselius, 2002) in his article talks about the security issues that need to be

addressed before multi-agent systems in general, and mobile agents in particular, can

be used as a viable solution for a broad range of commercial applications. The article

considers the implications of the characteristics given to agents and general properties

of open multi-agent systems. According to Borselius the security issues for non-

mobile agents can, at least in theory, to a great extent be tackled through existing

security technology and protocols. Issues related to trust and delegations in a large

scale multi agent system are non-trivial to solve. The article also outlines that a public

key infrastructure is likely to be an important part of the solution; agents need to be

able to reason and make decisions based on various security parameters. Execution of

agents (mobile as well as non-mobile) on untrusted platforms is another factor

introducing non-trivial security concerns, in particular related to correct agent

execution and confidentiality of agent data. The required security level and security

measures must, as always, depend on the application. The article suggests another

way to tackle the security problems in mobile agents by means of trusted hardware.

14

Proof-carrying code (PCC) is a technique proposed by Necula (Necula and Lee, 1998)

to enable a host to be absolutely certain that it is safe to execute an un-trusted piece of

mobile code. The work was initiated outside the research of mobile agents. The

authors refer to problems in the field of operating systems, where a code fragment

should be installed in the operating system kernel. They also mention possible

applications in the field of distributed and Web-based computing, where mobile code

is sent from a host platform to a remote platform. They illustrate their technique by

using an example of a mobile agent that visits several online stores.

Karjoth (Karjoth, Lange and Oshima, 1997) has proposed a security model for aglets

is a first step towards alleviating these threats. The model clearly defines the

principals within an aglet system with respect to their responsibilities (liabilities) and

interests. The model explains how aglets migrate, and depicts their access to local

resources. Thus it serves as a reference for corresponding security architecture. Also

introduced are two elements of the security architecture the policy database and

owner-specified preferences and demonstrated how these elements control security-

unaware aglets. Their current work addresses the aglet security API that will enable

aglet application developers to enforce their own security so that an aglet can, for

example, control access to its own data or audit its own security-relevant activities.

The API design takes into account the security features added to the Java Developer’s

Kit Version 1.1 and subsequent versions. In particular, protection domains and a

uniform way to access user identities that were established in different ways have

been proposed.

The goals of history-based access control are to maintain a selective history of access

requested by the code and to use this information to decide between trusted and un-

trusted code. The approach presented by Edjlali (Edjlali et al., 1998) targets mobile

code, especially Java applets, and is motivated by the following examples: In some

application scenarios it might be too restrictive to prohibit all access to the local file

system or to open a socket to a remote host. With static privileges it is possible only to

define that the code has either both privileges or neither of them. The authors argue

that it is worthwhile to define mutual exclusive privileges so that the code is allowed

15

to first open a file for reading but it is not allowed to open a network connection later,

where the file might be sent to a remote host. Another example is access to a database,

where the code is allowed to read only one of two relations but not both of them.

The concept presented by Edjlali (Edjlali et al., 1999) is based on unique identifiers

for programs, which are computed using hash functions over the entire code of the

program. This prevents the applicability of the approach for programs that use

dynamic code loading during runtime. In our opinion, history-based access control

needs some extensions to be applicable with mobile agents. Consider the previous

example in which a program has opened a file for reading. In contrast to Java applets,

which can open network connections only to remote hosts in case they want to steal

data, mobile agents have other means, such as simply carrying the file as part of their

own code. Therefore, some kind of firewall is needed to examine the mobile agent

before it leaves the current agency.

The problem of malicious agents that consume resources in an unauthorized way must

be mentioned. Java does not provide any means to restrict memory allocation or CPU

usage. Future versions of Java will provide built-in solutions for this problem; until

then, other techniques that are based on modified virtual machines or that rewrite the

code of an agent must be used. Czajkowski (Czajkowski and von Eicken, 1998) has

described a technique that relies on native code implementation, a different

implementation of several Java packages, and code rewriting to track memory usage

and CPU and network bandwidth consumption. Because this approach is not fully

implemented in Java, it is not applicable to mobile agent toolkits. This would require,

at a minimum, installation of modified packages from the Java API.

Villazon (Villazon and Binder 2001) has proposed a solution that relies completely on

Java bytecode rewriting, making it suitable for mobile agent toolkits. Their approach

can also be applied for CPU, memory, and network control. It creates a so-called

meta-agent for each mobile agent currently residing at the agency. Reification of

network bandwidth, for example, consists of redirecting calls to the component that

provides network services to the meta-agent, which itself then calls the network

16

service. Reification of memory works in a similar manner but is more difficult

because every object creation and disposal must be taken into account. Finally,

reification of CPU usage is done by analyzing the agent’s code and inserting

accounting instructions at selected points in the control flow. The drawback of this

approach is that execution time increases because of the process of bytecode rewriting

and additional inspections. The authors report an overhead of about 20% only for

CPU reification.

17

CHAPTER 3

IDENTIFIED ATTACKS ON AGLET PLATFORM

3.1. SECURITY IN AGLETS

Aglets use an organizational approach whereby all agent systems in a certain domain are

deemed trustworthy, and evaluate the authenticity of the agent depending on the domain

in which it has been roaming around. A user first authenticates him/her to the system, and

the system then issues the credentials of the user's agent. The agent system then evaluates

the authenticity of the credentials, to determine whether or not they were issued within

the same domain. It may downgrade the authenticity or simply deny access, depending on

conditions such as where the agent has traveled and so forth. Host aglet platform

authentication is used to identify the domain to which the communicating host aglet

platform belongs.

Although the current Aglets do not fully support these services because of the limited

support for encryption in JDK, it does provide a reasonable level of security to make it

safe to use mobile agent applications. The following security features are supported in the

latest Aglets runtime:

Domain Authentication.

Integrity checked communication between aglet platforms within a domain.

Authorization of Aglets.

3.1.1. Domain Authentication

Aglet platforms are able to authenticate whether the contacting platform belongs to a

certain domain. All aglet platforms that belongs to one domain share a secret key, and

can authenticate the contacting aglet platforms by means of that secret key using MAC

18

(Message Authentication Code: a secure hash value computed from a content and nonce

value). The advantage of this approach is that MAC need not be signed by means of

encryption algorithms.

After the authentication between aglet platforms has been established, the credentials of

the aglet are sent along with the aglet. The receiver will then decide how much it trusts

the credentials sent by the aglet platform on the basis of the information obtained by the

host authentication. In Aglets, the aglet platform simply trusts the credentials if they were

sent from the aglet platform in the same domain.

To use the domain authentication, each user (or aglet platform administrator) needs to

obtain the secret key of the domain from the domain authority. The domain authority is

responsible for generating a domain key for a specific aglet platform. The shared secret

key is signed with the user's password, and thus the user is required to give the correct

user id and password to make it effective. This key file must be kept secret, because it is

not encrypted.

One disadvantage is that it cannot identify and verify the communicating hosts. Once the

shared key is stolen from aglet platform in the domain, there is no way of distinguishing

valid aglet platform and the aglet platform from which the key was stolen. As a result, all

aglet platforms in the same domain are exposed to dangers.

3.1.2. Integrity-Checked Communication

Since all aglet platforms within one domain share a secret, the integrity checking can be

done in the same way as that described under the domain authentication. The sender

computes the MIC (Message Integrity Code) value of the content and the shared secret,

and sends it along with the nonce and the content. The receiver then verifies the MIC by

using the nonce, the content and the secret maintained by the receiver itself. Because only

aglet platform that knows the secret can generate the same MIC, the receiver can make

19

sure that the content was sent by aglet platform in the same domain and has not been

tampered with.

3.1.3. Authorization of Aglets

When an aglet accesses the security-sensitive information and resources such as Java

properties, threads, and/or any other external resources such as files, it must be controlled

under the permissions given to the aglet. The permissions can be specified either by a

GUI or by direct editing of the policy database. The format of the policy database used by

Aglets is designed to conform to that in the JDK1.6 specification. A user can specify the

following permissions in the policy database.

Aglet security permission:

com.ibm.aglets.security.ContextPermission

ContextPermission specifies whether an aglet can access the context property, shutdown

the context, etc. The name for a ContextPermission can be one of the following: "start",

"retract", "create.<codebase@classname>", "listener.add", "listener.remove",

"property.<key>".

Java supported security permission:

java.io.FilePermission : File read/write/execute

java.net.SocketPermission : Socket resolve/connect/listen/accept

java.awt.AWTPermission : showWindowWithoutWarningBanner, accessClipboard

java.util.PropertyPermission : Java property

java.lang.RuntimePermission : queuePrintJob, load library

java.security.SecurityPermission : getPolicy, setSystemScope

java.security.AllPermission : all other permissions

com.ibm.aglets.security.ContextPermission : context property, start, shutdown

com.ibm.aglets.security.AgletPermission : dispatch, deactivate, etc.

com.ibm.aglets.security.MessagePermission : messaging

20

com.ibm.aglets.security.AgletPermission

This class represents access to an aglet. An AgletPermission consists of a principal name

of target aglet and a set of operation names for that aglet.

The principal name is the user name of the target aglet (e.g. "aglets", "isuser", or

"anonymous"), and the operation name is the method name of the Aglet class (e.g.

"dispatch", "dispose");

com.ibm.aglets.security.MessagePermission

This class represents permission to send a message to an aglet. A MessagePermission

consists of the principal name of the target aglet and a kind of message.

The principal name is the user name of the target aglet (e.g., "aglets", "isuser", or

"anonymous"), and the kind of the message is the kind of message to be sent. The kind of

message should be prefixed with "message" (e.g. "message.show", "message.getResult");

Figure 3.1: Security setting in aglets.policy file

Aglets are identified by their code base and owner. The author of an aglet is currently

anonymous because code signing is not supported in the current Aglets. Thus, the

permissions for aglets are defined in terms of the aglets' owners and codebase

information. For example, the configuration shown in figure 3.1 gives the aglets owned

by "isuser" that have the codebase "atp://172.16.17.52:4434" read access to local files on

"/home/isuser/Desktop/", write access to any property in the context, and permission to

grant codeBase "atp://172.16.17.52:4434", ownedBy "isuser"

{

permission java.io.FilePermission ""/home/isuser/Desktop/", "read";

permission com.ibm.aglets.security.ContextPermission "property.*", "write";

permission com.ibm.aglets.security.AgletPermission "isuser", "dispose";

permission com.ibm.aglets.security.MessagePermission "isuser", "message.getResult";

}

21

dispose of any aglet owned by isuser. This policy file is created

at $HOME/.aglets/security/aglets.policy on an individual user basis. A domain-based

policy is not yet supported. Once supported, the domain authority should be able to

specify domain-wide permissions. Once code signatures are supported, "signedBy" will

be available as a means of specifying the manufacturer of an aglet.

3.2. MALICIOUS AGENTS

Malicious agents are those that try to attack the hosting agent platform. Malicious agents

are further classified according to the type of resource on the platform they attack.

Consuming resources of the hosting platform in an improper way is one common trait of

malicious agents. Examples of such resources are all computational resources such as

memory, CPU cycles, or network bandwidth. These resources are consumed in a way that

the mobile agent platform eventually is not able to provide its usual service to other

agents. Such attacks are therefore called Denial-of-Service attacks. In the following

subsections, we describe some of the identified attacks on Aglet platform.

3.3. IDENTIFIED ATTACK ON AGLET PLATFORM

We could successfully launch DoS attack on the aglet platform using Clone Attack and

Attack on virtual memory. Also, we have proposed and implemented mitigation schemes

for the same. These attacks have been observed in following execution environment:

22

3.3.1. Clone Attack

Clone Attack is attributed to clone() method of java.lang.Object class. The impact of this

attack is on memory of Operating system i.e. non-heap memory and heap memory. For

every process, Operating system allows limited number of threads which depends on the

thread stack size and heap memory; default stack size is ≈320KB and heap memory is

≈512MB on Java HotSpot(TM) Server VM version 11.3-b02. Figure 3.2 shows the

maximum number of threads that can be created for particular thread stack size, keeping

heap memory constant at 512MB. When clone() method gets called in an aglet, new

instance of agent is created, with current state but with new identity. Each cloned agent

requires some amount of Non heap and heap memory. Allocated memory will only be

released after agent is disposed.

Execution Environment:

Software :

Operating System

- Ubuntu (Kernel Linux 2.6.28-16-generic, GHOME 2.26.1)

Java

- Sun Java 6

- Ant version 1.7.1

Hardware :

Processor :

- Processor 1: Intel(R) Pentium(R) 4 CPU 3.20GHz

- Processor 2: Intel(R) Pentium(R) 4 CPU 3.20Ghz

Memory:

- RAM: 1.95GiB (2GiB)

- Swap: 2.0GiB

Mobile Agent system:

Aglet - 2.0.2

Result Analysis Tool:

JConsoler 1.6

23

Figure 3.2: Variation of number of threads depending on thread stack size

Consider the following example of aglet which performs clone attack on Aglet platform.

0

5000

10000

15000

20000

25000

30000

35000

0 200 400 600 800 1000 1200

Nu

mb

er o

f T

hre

ad

s

Thread Stack Size (KB)

Example: CloneAttack Agent 1 public class CloneAttack extends Aglet 2 { 3 public void run() 4 { 5 Clone(); 6 } 7 }

Stack Trace: Exception in thread "No.7523]" java.lang.OutOfMemoryError: unable to

create new native thread

at java.lang.Thread.start0(Native Method)

at java.lang.Thread.start(Thread.java:597)

at com.ibm.aglets.AgletThread.handleMessage(Unknown Source)

at com.ibm.aglets.MessageImpl.activate(Unknown Source)

at com.ibm.aglets.MessageManagerImpl.processNextMessage(Unknown

Source)

at com.ibm.aglets.MessageManagerImpl.resume(Unknown Source)

at com.ibm.aglets.LocalAgletRef.resumeMessageManager(Unknown

Source)

at com.ibm.aglets.LocalAgletRef.startClonedAglet(Unknown

Source)

at com.ibm.aglets.LocalAgletRef._clone(Unknown Source)

at com.ibm.aglets.LocalAgletRef.clone(Unknown Source)

at com.ibm.aglet.Aglet.clone(Unknown Source)

at CloneAttack.run(CloneAttack.java:9)

at com.ibm.aglets.SystemMessage.handle(Unknown Source)

at com.ibm.aglets.AgletThread.run(Unknown Source)

24

CloneAttack agent keeps on cloning itself until JVM throws “OutOfMemoryError”

Exception. As a result, Aglet platform does not allow either creation or arrival of new

agents. Whenever a new request for memory allocation is raised, JVM throws a message

“A Fatal error has been detected by the Java Runtime Environment” and Aglet platform

execution is aborted.

3.3.2. Attack on Virtual Memory

This is resource vulnerability in Aglet platform. One agent can create any number of

threads which could result Java virtual machine (JVM) throwing

“java.lang.OutOfMemoryError: unable to create new native thread error”, and JVM

stops creating new threads. Due to non-availability of free memory, Aglet platform is

unable to handle new requests for agent creation or reception. This is a kind of denial of

service attack. If those threads contain an infinite loop or some CPU intensive code then

JVM throws Fatal Error message and Aglet platform execution is aborted.

#

# A fatal error has been detected by the Java Runtime Environment:

#

# java.lang.OutOfMemoryError: requested 327680 bytes for GrET in

/BUILD_AREA/jdk6_16/hotspot/src/share/vm/utilities/growableArray.cpp.

Out of swap space?

#

# Internal Error (allocation.inline.hpp:39), pid=20618,

tid=3040500624

# Error: GrET in

/BUILD_AREA/jdk6_16/hotspot/src/share/vm/utilities/growableArray.cpp

#

# JRE version: 6.0_16-b01

# Java VM: Java HotSpot(TM) Client VM (14.2-b01 mixed mode, sharing

linux-x86 )

# An error report file with more information is saved as:

# /home/isuser/Desktop/Working/bin/hs_err_pid20618.log

#

# If you would like to submit a bug report, please visit:

# http://java.sun.com/webapps/bugreport/crash.jsp

#

Aborted

25

Examples are as follows:

Source code: crashThread Thread

1 class crashThread extends Thread 2 { 3 public void run() 4 { 5 Thread.sleep(Interger.max); 6 } 7 }

Stack Trace:

Exception in thread "No.1]" java.lang.OutOfMemoryError: unable to

create new native thread

at java.lang.Thread.start0(Native Method)

at java.lang.Thread.start(Thread.java:597)

at crashThread.thread(Stack.java:59)

at CrashThread.run(CrashThread.java:14)

at com.ibm.aglets.SystemMessage.handle(Unknown Source)

at com.ibm.aglets.AgletThread.run(Unknown Source)

Example: CrashThread Agent.

1 public class CrashThread extends Aglet 2 { 3 crashThread thread = null; 4 public void run() 5 { 6 for ( int i =0; i < 10000; i++) 7 { 8 thread = new crashThread(); 9 } 10 } 11 }

26

Source code: crashThread Thread (with infinite loop)

1 class crashThread extends Thread 2 { 3 public void run() 4 { 5 while (true); 6 } 7 }

Stack Trace:

Exception in thread "No.2]" java.lang.OutOfMemoryError: unable to

create new native thread

at java.lang.Thread.start0(Native Method)

at java.lang.Thread.start(Thread.java:597)

at crashThread.thread(Stack.java:59)

at CrashThread.run(CrashThread.java:14)

at com.ibm.aglets.SystemMessage.handle(Unknown Source)

at com.ibm.aglets.AgletThread.run(Unknown Source)

#

# An unexpected error has been detected by Java Runtime Environment:

#

# java.lang.OutOfMemoryError: requested 503240 bytes for Chunk::new.

Out of swap space?

#

# Internal Error (allocation.cpp:218), pid=15550, tid=2433293200

# Error: Chunk::new

#

# Java VM: Java HotSpot(TM) Server VM (11.3-b02 mixed mode linux-x86)

# An error report file with more information is saved as:

# /home/isuser/Desktop/MAS/bin/hs_err_pid15550.log

#

# If you would like to submit a bug report, please visit:

# http://java.sun.com/webapps/bugreport/crash.jsp

# The crash happened outside the Java Virtual Machine in native code.

# See problematic frame for where to report the bug.

#

Aborted

27

CHAPTER 4

PROPOSED SOLUTION

Java Sandbox technique helps alleviate issues of malicious mobile agents to a great

extent. Although the Java Sandbox is quite comprehensive, it does not solve all

problems with malicious agents; for example, in Java it is not easy to control memory

access or CPU usage. Here we propose solution to the above identified DoS attacks

on Aglet platform (Tahiti server).

4.1. CLONE ATTACK

Cloning (Lange and Oshima, 1998) is a feature of mobile agent system which creates

a new instance of same agent with same state. To clone one of the agent, aglet uses

clone() method declared in java.lang.Object class. The recursive use of the clone()

method results in a agent performing Denial of Service attack (Evens et al., 2007) on

Aglet platform. Those agents keep on cloning itself until platform resources are

exhausted. After this any new request will cause “OutOfMemoryError” Exception to

be thrown by JVM and further requests are either denied or server execution gets

aborted.

4.1.1. What is “OutOfMemoryError” Exception?

The subclasses of Error (Boyland, 2005) represent errors that are normally thrown by

the class loader, the virtual machine, or other support code. Application-specific code

should not normally throw any of these standard error classes. This error is thrown

when the JVM fails to allocate memory.

JVM Memory Allocation

Heap (Boyland, 2005) is the runtime data area from which memory for all class

instances and arrays are allocated. It is created at the JVM start-up. Heap memory for

objects is reclaimed by an automatic memory management system which is known as

a garbage collector. Heap size is controlled with -Xms/-Xmx startup parameters.

28

If a computation requires more heap than the available memory by the automatic

storage management system, the JVM throws an “OutOfMemoryError”.

Non-Heap Memory (Boyland, 2005) The Java virtual machine manages memory

other than the heap which is referred as non-heap memory.

The JVM has a method area which is shared among all threads. The method area

belongs to non-heap memory. It stores per-class structures such as a runtime constant

pool, field and method data, and the code for methods and constructors. It is created at

the JVM start-up. The method area is logically part of the heap but a JVM

implementation may choose not to either garbage collector compact it. In addition to

the method area, a JVM implementation may require memory for internal processing

or optimization which also belongs to non-heap memory.

4.1.2. Clone Attack Mitigation Algorithm

Input: threshold: = maximum number of agents that can be created

Output: cloned agents are disposed

Algorithm:

Step 1: Get the list of agents and its clone count.

Step 2: Repeat

If clone count of agent > 75 % of threshold

Then dispose all cloned agents

If clone count of agent > 20% and less than 75% of threshold

Retain 20% clone corresponding to that agent and dispose

rest of them.

disposed clone count: = clone count + disposed clone count

Until agents count > 0

Step 3: Exit

Algorithm 4.1: Clone Attack Mitigation algorithm

29

4.1.3. Working of checkLoad function

For our experiment purpose, we have restricted agent to clone maximum up to 80% of

Create Agent Clone Agent Receive agent Activate Agent

checkLoad()

Run clone attack mitigation algorithm

Busy server, request denied

checkLoad()

Request granted

Figure 4.1: Flow Chart-Clone Attack Mitigation

Input: threshold: = maximum number of agents that can be created

Output: True/False

Algorithm:

Step 1: Get the present agent count

Step 2: If agent count >= threshold and heap memory usage >= 90% of

maximum heap memory

Return true

Step 3 Return false

False

False

True

True

Algorithm 4.2: Check Load algorithm

30

the total available agent count and rest of them are reserved to high priority local

agents for creation and to receive agents from other servers in the network. Whenever

new request comes for execution, it will check the number of agents present in system

using checkLoad function.

When the server is fully loaded and new agent request arrives, it checks for clone

attack. If the attack is detected; it will either mitigate it using the aforementioned

algorithm or it would display busy message. This might be the case for another type

of DoS attack.

4.2. ATTACK ON VIRTUAL MEMORY (RESOURCE THREAD)

Each JVM thread has a private JVM stack, created at the same time when the thread is

created. A JVM stack stores frames. It holds local variables and partial results, and

plays a part in method invocation and return. Because the JVM stack is never

manipulated directly except to push and pop frames, frames may be heap allocated.

The JVM specification permits JVM stacks either to be of a fixed size or to

dynamically expand and contract as required by the computations. If the JVM stacks

are of a fixed size, the size of each JVM stack may be chosen independently when

that stack is created. A JVM implementation may provide the programmer or the user,

control over the initial size of JVM stacks. It also provides, in the case of dynamically

expanding or contracting JVM stacks, control over the maximum and minimum sizes.

From the experiment that we carried out, it was learnt that 3300 threads could be

created per second.

The following exceptions are associated with JVM stacks:

If the computation in a thread requires a larger JVM stack than is permitted,

the JVM throws a StackOverflowError exception.

The JVM throws an OutOfMemoryError exception under two conditions:

i. JVM stacks can be dynamically expanded, and expansion is

attempted while the available memory is insufficient.

ii. While initiating a new thread the memory available for the JVM

stack is insufficient.

31

In the current scenario agent can create any number of threads, so there is possibility

of “java.lang.OutOfMemoryError: unable to create new native thread” exception.

This means java process has run out of virtual memory as a process is trying to create

a new thread.

4.2.1. Thread Monitor Algorithm

For our experimental purpose, we started ThreadMonitor thread in the Tahiti server

(Aglet Platform). This thread checks the number of agent threads currently active. We

set the thread limit to 100 threads per agent and the sleep time as 100ms. This will not

have considerable affect on CPU utilization. Next section compares performance of

platform with and without ThreadMonitor module.

Start

Thread Count >

Threshold

value

Thread Sleep

Dispose agent

Figure 4.2: Flow Chart - Mitigation of Attack on Virtual Memory

Exit signal from Main Thread

Yes

No

Step 1: Set thread limit per agent as threshold value.

Step 2: Check whether Active Thread count of any agent crosses the threshold

value. Then dispose the agent.

Step 3: go to step 2.

Algorithm 4.3: Thread Monitor algorithm

Stop

32

CHAPTER 5

PERFORMANCE EVALUATION

5.1. PERFORMANCE ANALYSIS OF SOLUTION

We are using following agents to analyze the performance of our solution;

1. 10% agents are of MySQLAccess – agent performs some database operation.

2. 10% agents are of SearchFromFile – agent searches number of occurrence

of current string in file.

3. 10% agents are of Prime – agent checks if given number is prime or not.

4. 10% agents are of Hello – agent displays “Hello” string on console.

5. 20% agents are of Factors – agent finds factorial of a number.

6. 20% agents are of NQueen – agent solves the 8 Queens Problem.

7. 20% agents are of Ackermann – agent uses Ackermann function.

5.1.1. Normal execution of Aglet platform without any monitoring modules

We calculate utilization with respect to number of agents, number varies from 1 to

5000 and reading are taken for values 1, 5, 10, 25, 50, 75, 100, 250, 500, 750, 1000,

2000, 3000, 4000 and 5000. The graph obtained for number of agents vs. memory is

shown in Figure 5.1. By using JConsoler we have recorded the memory use with

respect to number of agents.

We conclude the following facts from the graph.

Memory usage depends on the number of agents and the state of garbage collection

process at that instance. When agents are created, platform allocates initial memory to

them. Generally, as the number of agents increase, memory usage increases. This

scenario may change at the time of garbage collection. Whenever automatic garbage

collection is done by JVM, the memory usage sometimes shows a decrease even when

33

number of agents is increased. This is not guaranteed as automatic garbage collection

is an unreliable process and depends on system state.

Figure 5.1: Number of Agents Vs Memory Usage (KBytes)

5.1.2. Clone Attack

Here, we use CloneAttack agent which includes clone() method of class

java.lang.Object. We have used execution environment same as previous one. We

then integrated clone attack mitigation algorithm within aglet platform. The graph in

Figure 5.2 depicts the situation after resolving the clone attack.

Case –A curve indicates the variation of memory usage with respect to number of

genuine agents, after resolving clone attack.

Case – B curve indicates the variation of memory usage with respect to number of

genuine agents, after detecting clone attack.

For example, at a point where number of genuine agents is equal to 1000; attack is

detected. Memory usage is 107130056 Bytes and agents spawned after cloning is

5094. After mitigation the memory usage drops down to 68587536 Bytes and all

cloned agents are disposed. Where at a point where number of genuine agents is equal

to 5000; clone attack agents ≈131 are disposed. The total number of agents is 5000.

0

10000

20000

30000

40000

50000

60000

1 10 100 1000 10000

Me

mo

ry (K

Byt

es)

Number of Agents

34

As the number of genuine agents approach 5000, the number of clones reduce. Hence,

at 5000, the amount of memory consumed by both cases (A and B) is the nearly same.

Figure 5.2: Number of genuine Agents Vs Memory Usage (KBytes)

The graph in figure 5.3 shows the variation of time requires for detection of attack as

the number of genuine agents is increased. Detection time includes the time required

for obtaining the list of agents from the system and detecting the clones out of them.

Variation in the detection time with respect to number of genuine agents is negligible

and can be assumed to be constant. As seen from the graph, the detection time

remains constant (4 ms) till the number of genuine agents is 3000. Beyond that, the

detection time increases linearly with increase in number of agents.

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

1 10 100 1000 10000

Me

mo

ry (K

Byt

es)

Number of genuine Agents

Case - A Case - B

35

Figure 5.3: Number of genuine Agent Vs Attack detection time (ms)

The graph in figure 5.4 depicts the plot of Number of genuine agents vs. time for

mitigation of the clone attack. On an average, as the number of agent increases,

Mitigation time decreases. Because as the number of agents increase, the number of

clones to be disposed off decreases. The graph is not purely linear because the nature

of cloned agent also affects the mitigation time. If the cloned agent contains an

infinite loop or highly complex computation like the factorization problem, cloned

agent’s response is slowed down and thus the mitigation time increases.

Figure 5.4: Number of genuine Agents Vs Mitigation Algorithm Processing Time (ms)

0

1

2

3

4

5

6

7

8

9

1 10 100 1000 10000

Tim

e (m

s)

Number of genuine Agents

0

10000

20000

30000

40000

50000

60000

1 10 100 1000 10000

Tim

e (m

s)

Number of genuine Agents

36

5.1.3. Attack on virtual memory

The setup environment is same as above. The agent used for attack is “CrashThread”,

which creates very large number of native threads at the rate of 3300 threads per

second.

Our mitigation technique adds a thread to aglet platform which counts the number of

threads running. The graph in Figure 5.5 depicts variation of CPU utilization with

respect to time for both the scenarios i.e. before adding the mitigation thread and after

adding the mitigation thread.

Figure 5.5: Time (sec) Vs CPU Usage (%)

The graph shows negligible increase in CPU utilization after adding mitigation thread.

Hence our mitigation strategy puts only negligible load on the aglet platform.

The graph in Figure 5.6 plots variation in mitigation time with respect to number of

genuine agents. Variation in mitigation time depends heavily on the internal

processing of the thread created by the agent and to some extent on the number of

agents in the aglet platform. This happens due to the fact that while disposing off the

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

0 20 40 60 80 100 120

CP

U U

sage

(%

)

Time (sec)

Case - A Case - B

Case – A: shows CPU utilization before adding the mitigation thread.

Case – B: shows CPU utilization after adding the mitigation thread.

37

agent, the threads are created by that agent needs to be stopped first. Mitigation time

varies because the response time for the threads to be stopped is not constant.

Figure 5.6: Number of genuine Agents Vs Mitigation Algorithm Processing Time (ms)

5.1. PERFORMANCE ANALYSIS OF AGLET PLATFORM

Our requirement was to increase load on the server substantially for considerable

amount of time. We made this possible by having an agent calculate a^n.

Values we used were,

a = 200000000000000000000000000000000001

n = 50000

5.1.1. Clone Attack

We are using cloneAttack agent as an attacking agent, which contains clone() method.

To increase the CPU utilization by this agent, the task to be performed by agent was

to calculate a^n.

Here the values are,

a = 200000000000000000000000000000000001

0

100

200

300

400

500

600

700

800

1 10 100 1000 10000

Tim

e (m

s)

Number of genuine Agents

38

n = 10000

To analyze the performance of aglet platform, we consider the following three

different cases,

Case – A: Only the agent executing the exponential calculation is running,

Case –B: The agent executing the exponential calculation and clone agent are running

on the aglet platform.

Case - C: The agent executing the exponential calculation and clone agent are running

on the aglet platform with mitigation algorithm.

Execution time required to calculate a^n for our agent in above three cases is given in

the Table 5.1.

Table 5.1: Clone Attack-Execution Time

The graph in Figure 5.7 depicts variation in CPU utilization with time for all the three

cases. As seen in the graph, highest CPU utilization (in the range 50% - 90%) is for

case B and case C, when the cloneAttack agent is attacking the platform. It also

depicts the execution completion time for all the three cases, the CPU utilization

drops to zero when execution in completed. The overhead of the mitigation algorithm

is tolerable for 2 facts viz. the additional time required for completion is reduced by

63% with mitigation technique and the additional CPU usage by the mitigation

technique is negligible. Also in case B the platform is under denial of service attack

which prevents agent creation, reception and cloning on the platform. In case C the

platform is free of clone attack and behaves in normal way, similar to case A, after the

completion of the execution.

Case Time to Execute

Case – A 1083369ms

Case – B 1580856ms

Case – C 1267676ms

39

Figure 5.7: Execution Time (sec) Vs CPU Usage (%)

The graph in Figure 5.8 depicts the memory utilization for the above three cases. As

anticipated, the memory utilization is highest during attack scenario. It is apparent

from graphs in figures 5.7 & 5.8 that the memory and CPU utilized by Case C is less

than that of case B from time 276th

second onwards. This is due to the detection of the

clone attack and invocation of the mitigation technique which results in disposal of

clones.

Figure 5.8: Execution Time (sec) Vs Memory Usage (Bytes)

0

10

20

30

40

50

60

70

80

90

100

0 300 600 900 1200 1500 1800

CP

U U

sage

(%

)

Time(sec)

Case - A

Case - B

Case - C

0

10000000

20000000

30000000

40000000

50000000

60000000

70000000

80000000

90000000

0 250 500 750 1000 1250 1500 1750 2000

Mem

ory

(Byt

es)

Time (sec)

Case - A

Case - B

Case -C

40

5.1.2. Attack on Virtual Memory

An agent creates a thread which uses CPU cycles to perform a certain computation

and then make thread to go to sleep state for maximum possible delay.

To analyze the performance of aglet platform we consider the following three

different cases,

Case – A: only the agent executing the exponential calculation is running,

Case – B: The agent executing the exponential calculation and CrashThread agent are

running on the aglet platform.

Case - C: The agent executing the exponential calculation and CrashThread agent are

running on the aglet platform with mitigation algorithm.

Execution time required to calculate a^n for our agent in above three cases is given in

the Table 5.2.

Table 5.2: Attack on Virtual memory-Execution Time

As shown in Figure 5.9, the computation is completed without an interruption in case

A and case C where as in case B, the execution is aborted and JVM throws a fatal

error when it is under attack. In case C the computational time is slightly more than

case A due to attack and mitigation algorithm.

Case Time to execute

Case – A 1083369ms

Case – B No Result (Fatal Error)

Case – C 1140078ms

41

Figure 5.9: Execution Time (sec) Vs CPU Usage (%)

The graph in Figure 5.10 shows the memory utilization for the above three cases. The

memory utilization is highest when platform is under attack and after mitigation it

comes to normal state. As seen from the graphs in figures 5.9 & 5.10, the memory and

CPU utilized by case C is less than that of case B from 100th

second onwards. This is

due to the detection of the attack on virtual memory and invocation of the mitigation

technique which results in disposing of the agent. Also, due to attack on virtual

memory and absence of mitigation technique, the aglet platform stops execution from

700th second onwards. This is shown in case B.

Figure 5.10: Execution Time (sec) Vs Memory Usage (Bytes)

0102030405060708090

100

0 200 400 600 800 1000 1200

CP

U U

sage

(%)

Time(sec)

Case - A

Case - B

Case - C

0

10000000

20000000

30000000

40000000

50000000

60000000

0 300 600 900 1200 1500 1800

Mem

ory

(Byt

es)

Time (sec)

Case -A

Case- B

Case -C

42

CHAPTER 6

CONCLUSION AND FUTURE WORK

We have proposed a solution to overcome the Denial of Service attack caused by

cloning and exhaustion of virtual memory on aglet platform. The proposed solution

introduces negligible overload on the existing aglet platform and successfully resolves

the Denial of Service attacks caused by Cloning and Thread Creation. The results

show that the proposed mitigation schemes are effective as they are capable of

detecting as well as mitigating DoS attacks which results in reduced CPU and

memory utilization. Our mitigation techniques work by disposing off the malicious

clones/agents and hence preventing the platform from becoming available to genuine

agents. This way it ensures high availability of the platform.

Future Work

Excessive message generation and too many agents in a platform can overwhelm

the whole system. This work can be extended to prevent DoS attack caused by

other means; viz. synchronized Thread.class and infinite object creation.

Proposed system can include key distribution mechanism in agent architecture.

We need to define which key distribution model best suit the security model.

Access control policy should be improved. Policy setting should be based on

agent manufacturer, agent owner, context service provider and domain authority.

Security model need to include context level security. The security policy should

be enforced when agents try to arrive from another platform.

43

APPENDIX I

TAHITI USER’S GUIDE

A. INSTALLATION INSTRUCTIONS

Make sure that you have Aglets-2.0.2.jar with you before proceeding with the

installation. The following steps detail how to install platform as well as APIs needed

to author custom Aglets.

1. Decompress the archive:

isuser@linux:$ jar xvf aglets-2.0.2.jar

Once you have extracted the archive, you should see a set of subdirectories as

follows:

bin: contains executable programs for the aglets 2 platform.

cnf: contains configuration files for the aglets platform

public: contains a few examples of agents, and should be your root directory as

base of your own agents.

lib: contains the Aglets 2 library and libraries required by the Aglets technology.

2. Install the platform (Tahiti server)

isuser@linux:$ cd bin

isuser@linux:$ chmod 755 ant

isuser@linux:$ ./ant

3. Set up policy

isuser@linux:$ ant install-home

44

4. Set up environment variable

isuser@linux:$ export AGLETS_HOME=/java/aglets

isuser@linux:$ export AGLETS_PATH=$AGLETS_HOME

isuser@linux:$ export PATH=$PATH:$AGLETS_HOME/bin

5. Run the aglet platform with the default configuration file:

isuser@linux:$ aglets –verbose –f ../cnf/aglets.props

Tahiti has a set of options for specifying its parameters. Some of these parameters can

be set from the dialog box.

B. START UP OPTIONS FOR AGLETSD

Create a command prompt window and execute the script "agletsd" with "-help"

option, then you will get following messages.

linux@isuser$ agletsd -help

usage: agletsd [-options]

Where options include:

-help print this message

-f <props file> specify platform properties file

-verbose turn on verbose mode

-nogui no AWT initialization

-nosound no Sound initialization

-port <port> set the port used by daemon

-cleanstart

45

-help - The list of available options (above) is shown.

-f <props file> - Specifies platform properties file. Please see Platform Properties

Guide to get what to define in it. This option can appear more than once.

Properties which are set by this option will be overridden by subsequent ones.

-verbose - Turn on verbose mode. Platform prints out platform process to your

console.

-nogui - No AWT initialization. Aglets in the platform may fail to load AWT

classes.

-nosound - No sound initialization. Aglets in the platform may fail to load Sound

classes.

-port <port> - Set the port number, which is used by the daemon process. If you

are a UNIX user, please note that, in most case, you are prohibited to use the port

whose number is less than 1024.

46

C. TAHITI SETTINGS

Following options can be configured in Tahiti:

General Preference

Font: Defines the size of the font in Tahiti window. The change of the setting

becomes effective immediately.

List View: Defines the order of the Aglet items in the list box of the Tahiti window.

The change of the setting will be reflected after clicking one of the items on the list

box.

Startup: You can specify an aglet that automatically starts up when Tahiti is started.

(The Launch Startup Aglet check box enables this function.)

Cache Control: Clearing up the class cache.

Figure 1: General Preference

47

Network Preference

Http Tunneling: In case you are protected by a firewall, you can specify an http

proxy platform to access the information outside the firewall. We call this method as

Http Tunneling. Check Use HTTP Proxy and Specify your http proxy information like

a setting in a World Wide Web browser.

Authentication: This is a switch for security options. When you enable

Authentication, Tahiti have to keep at least one secret file. Tahiti can communicate

with each other only if the other aglet platform has (can access) the same secret file.

Accept HTTP Request as a Message: We can create an aglet, which has a URL and

returns html. When we enable this option, aglets receives HTTP request as a message.

Figure 2: Network Preference

48

Security Preference

We have a dialog box for specifying security settings. As for the security model of

aglet and its details, please refer the description of aglet security. User can specify the

access privilege for the following items.

- FileSystem

- Socket:

- Window

- Property

- Runtime

- Security

- All

- Aglet

- Message

- Context

- Protection (Aglet and Message)

Security access privileges are assigned to codebase, signer, and owner of aglets.

(Codebase can be specified using wildcard after the security architecture of JDK1.6.)

For each codebase, you can specify access privileges for above items.

Figure 3: Security Preference

49

D. TAHITI AGENT CONTROL OPTIONS

All the agents are displayed in the list box in Tahiti. By selecting one of the listed

agents, you can control the corresponding agent.

Figure 4: Tahiti agent control options

Create: Creates a new aglet. A dialog window for the aglet's URL specification will

appear. (Detailed information on creating an aglet is here)

Dialog: Sends a request to an aglet to open its dialog panel. (When this button is

clicked, an onDialog() message is sent to the aglet.)

AgletInfo: Shows the properties of the agent.

Dispose: Destroys the agent.

Clone: Make a copy of the agent. Cloned agent runs on the same context.

Dispatch: Sends the agent to another platform. After dispatching agent, original agent

on the current platform no more exists on your platform. The protocol for the

destination URL is Agent Transfer Protocol. Please specify it as in the following

example:

atp://172.16.17.45:4434

Retract: Retracts a dispatched agent from a remote platform. First specify the target

platform and you will get a list of agents on the target platform. Then, you can specify

one of the aglets form the platform.

50

REFERENCES

Aglet Development group, (2009). “The Aglet-2.0.2 User’s Manual”,

Alex Villazon and Walter Binder, (2001). “Portable Resource Reification in Java-

Based Mobile Agent Systems”, volume 2240 of Lecture Notes in Computer Science,

pages 213–228, Springer-Verlag, 2001.

Danny B. Lange and Mitsuru Oshima, (1998). “Mobile agents with Java: The Aglet

API”, Programming and Deploying JavaTM Mobile Agents with Aglets, Addison-

Wesley Professional, 1998.

Danny B. Lange and Mitsuru Oshima, (1999). “Seven Good Reasons for Mobile

Agents”, Vol. 42, No. 3 Communications of the ACM, March 1999.

Elhum Nusrat, Abu Shohel Ahmed, Gazi Mushfiqur Rahman, and Lafifa Jamal,

(2008). “SAGLET- Secure Agent Communication Model”, 11th International

Conference on Computer and Information Technology (ICCIT 2008) 25-27

December, 2008, Khulna, Bangladesh.

Evens Jean, Tu Jiao, Ali R Hurson, and Thomas E. Potok, (2007). “SAS: A Secure

Aglet Server”, Computer Security Conference 2007, Myrtle Beach, SC, USA, April-

2007.

George C, Necula and Peter Lee, (1998). “Safe, untrusted agents using proof-carrying

code”. Mobile Agents and Security, volume 1419 of Lecture Notes in Computer

Science, pages 61–91. Springer-Verlag, 1998.

Grzegorz Czajkowski and Thorsten von Eicken, (1998). “JRes: A resource accounting

interface for Java”, ACM SIGPLAN Notices, 33(10):21–35, 1998.

Gunter Karjoth, Danny B. Lange and Mitsuru Oshima, (1997). “A Security Model for

Aglets”, IEEE Internet Computing archive, Volume 1, July 1997.

Guy Edjlali, Anurag Acharya, and Vipin Chaudhary, (1998). “History-based access

control for mobile code”. Fifth ACM Conference on Computer and Communications

Security (CCS ’98), San Francisco (USA), November 1998, pages 38–48. ACM

Press, 1998.

Guy Edjlali, Anurag Acharya, and Vipin Chaudhary, (1999). “History-based access

control for mobile code”, volume 1603 of Lecture Notes in Computer Science, pages

413–432, Springer-Verlag, 1999.

51

John Boyland, (2005). “Position Paper: Handling “Out Of Memory Errors”, ECOOP

2005 Workshop on Exceptional Handling in Object-Oriented Systems, July – 2005.

Jonathan Bredin, David Kotz, and Daniela Rus, (1998). “Market-based Resource

Control for Mobile Agents”, Autonomous Agents, pages 197-204, Association of

Computing Machinery (ACM), May 1998.

Leila Ismail, (2008). “A Secure Mobile Agents Platform”, Journal of

Communications, VOL. 3, NO. 2, April 2008.

Lu Ma, Jeffrey J. P. Tsai, (2006). “Security Modeling and Analysis of Mobile Agent

Systems”, Series in Electrical and Computer Engineering-vol. 5, Imperial College

Press, 2006.

Mitsuru Oshima, Guenter Karjoth, and Kouichi Ono, “Aglets Specification 1.1”,

http://www.trl.ibm.com/aglets/spec11.htm

Niklas Borselius, (2002). “Mobile agent security”, Mobile VCE Research Group

Information Security Group, Royal Holloway, University of London Egham, Surrey,

TW20 0EX, UK.

Peter Braun and Wilhelm Rossak, (2005). “Mobile Agents Basic Concepts, Mobility

Models, and the Tracy Toolkit”, Elsevier Inc. (USA) and dpunkt.verlag (Germany) -

2005.

S.Venkatesan and C.Chellappan, (2008). “Protection of Mobile Agent Platform

through Attack Identification Scanner (AIS) by Malicious Identification Police

(MIP)”, First International Conference on Emerging Trends in Engineering and

Technology, 2008,

Sun Microsystems, (2006). “Memory Management in the Java HotSpot™ Virtual

Machine”, Sun Microsystems, Inc, 2006.

Wayne Jansen and Tom Karygiannis, (2000). “NIST Special Publication 800-19 –

Mobile Agent Security”, National Institute of Standards and Technology Computer

Security Division Gaithersburg.

52

RESUME (BIO-DATA)

Name: Mane Dnyaneshwar Rangnath

Date of Birth: March 7, 1986

Permanent Address: At/Post: Pedgaon,

Tal: Daund, Dist: Pune,

Pin Code – 413801,

Maharashtra.

Email: Dnyaneshvar.mane@gmail.com

Contact Numbers: +91-9743084167

Educational Qualification:

Degree: B.E

Discipline: Computer Engineering

Year: 2007

University: University of Pune