O'Reilly logo

Mobile Agents by Wilhelm R. Rossak, Peter Braun

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

198 Chapter 5 Mobile Agent Security
communication channel. Agent β, therefore, also knows the name of the
agency A
i
that α is currently visiting. Now, agent β can verify that prev
i
(α)
equals A
i1
. If they do not match, we have two possible error situations. First,
A
i1
could have sent agent α to agency A
x
instead of A
i
—or A
i
is returning
wrong information for prev
i
(α). For example, agency A
i
may be malicious
and want to incriminate agency A
i1
, which is actually not malicious at all.
It is not possible to determine which of the two agencies cheats.
Then, agent β can verify that A
i
matches next
i1
(α); that is, it checks that
the current agency is really the one to which agent α wanted to migrate. In
this case, agency A
i
must masquerade its identity or deny communication
between the two agencies to mask the error situation. On the other hand, if
agency A
i
does not deny communication and does not masquerade, then β
will discovers that A
i1
has sent the agent to a wrong agency.
This protocol has some drawbacks. First, communication between the
two agents is expensive. Second, the agent might be killed after the agent
has sent its position message to β but while it is still on agency A
i
or after
the agent has been received by A
i+1
and before the agent has sent its new
position message.
To make this protocol work, it must be guaranteed that both agents α and
β are at each point in time on two hosts for which it is clear that they do not
work together. In the other case, the two malicious agencies might cooperate
to attack the protocol. For example, it could be possible that simply both
agents are killed at the same time.
Roth, therefore, proposes to mark all agencies with the colors white, gray,
and red. White agencies are benevolent. Possibly, only the home agency is
marked white. Gray agencies are not completely trusted, and red agencies
are those that might collaborate with some other agency to attack an agent.
Then, Roth defines the following condition to make his protocol work: The
two agents migrate into two disjunct sets of agencies, and no red agency
from one set is willing to cooperate with a red agency from the other set.
The question that remains is how this condition can be guaranteed.
5.6 Protecting Agencies
We now consider the problem of how agencies can be protected against
malicious agents. Actually, this problem is played down and regarded as
almost solved in large parts of the literature, because Java as a programming
5.6 Protecting Agencies 199
language and execution environment already provides several techniques
that can be used to protect the underlying agency from several types of
attacks carried out by malicious agents. In fact, the problem of malicious
agents seems to be better understood than the reverse problem of malicious
agencies.
One of the main concerns is how the underlying operating system
and hardware can be protected against unauthorized access by agents.
Although Javas sandbox concept provides an already-sophisticated solu-
tion for this problem, we will show that many problems still remain and
that the sandbox in its current version is by no means a complete solution.
In this section, we start with an introduction to Java security and then
present techniques for agent authentication and authorization. Finally,
we present techniques to protect an agency from malicious agents dur ing
runtime.
5.6.1 Introduction—Java and Security
In Chapter 2 we introduced some of the major benefits of Java as a pro-
gramming language for mobile agent toolkits. In this section we extend this
introduction and provide a deeper overview of Java security aspects. For a full
introduction to Java security, we point the interested reader to Oaks [2001].
Java as a Safe Programming Language
One of the major benefits of Java—and not only for mobile agent toolkits—
is that it can be considered a safe programming language compared with C
or C++, for example. Many typical programming flaws that result in severe
runtime errorsinC or C++ simplycannotoccur in Java.With regardtosecurity,
one of the main differences between Java and C is that Java is a strictly typed
programming language and has a pointer model that does not allow illegal
type casting or pointer arithmetic. For example, in Java the programmer has
no chance to access arbitrary memory locations and overwrite and destroy
data there. In Java it is impossible to access arrays beyond their boundaries,
as can be done in C, for example.
Code Signing
Code signing is a technique used to verify the integrity of mobile code,
and it can also be used as one step in the agent’s authentication process.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required