Download - MOBILE AGENT SECURITY AGLET PLATFORM
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: [email protected]
Contact Numbers: +91-9743084167
Educational Qualification:
Degree: B.E
Discipline: Computer Engineering
Year: 2007
University: University of Pune