NEW

IMPLEMENTATION OF RMI TO PROTECT INTEGRITY AND

CONFIDENTIALITY FOR MOBILE AGENTS

Shinichi Motomura

The Graduate School of Engineering, Tottori University

4–101, Koyama-Minami, Tottori 680–8552, Japan

Takao Kawamura, Kazunori Sugahara

Department of Information and Knowledge Engineering Tottori University

4–101, Koyama-Minami, Tottori 680–8552, Japan

Keywords:

RMI, Security, Java, Mobile agent.

Abstract:

A new implementation of RMI named OnePort RMI is proposed in this paper. OnePort RMI consists of new

RMI runtime, classes which are implemented interfaces by RMI speciﬁcation, and MultiChannelSocketFac-

tory. Using OnePort RMI, when an object on a client invokes methods of remote objects on a server, the

client can use sockets of different types to connect one destination port at the same time, and the server can

accept incoming call from the sockets on only the port. In order to protect integrity and conﬁdentiality of our

mobile agent framework named Maglog, OnePort RMI is introduced into Maglog. In consequence, each agent

can select a socket depending on importance of data and programs which are contained in their agents. We

emphasize that the proposed OnePort RMI is not only for mobile agent frameworks such as our Maglog but

also for any RMI applications.

1 INTRODUCTION

In the construction of network application systems,

distributed model is widely adopted. In particu-

lar, mobile agent technology is attracting attention

as a key technology for developing distributed sys-

tems. Several mobile agent frameworks have been

proposed, such as Aglets(Lange and Oshima, 1998),

Jinni(Tarau, 1999), Mobilespaces(Satoh, 2000), and

Telescript(White, 1994). Measures against security

threats for mobile agent frameworks have been stud-

ied(Karjoth et al., 1997; Farmer et al., 1996; J.Tardo

and Valente, 1996). The security measures are classi-

ﬁed by following aspects:

Authentication is a process which identiﬁes agents.

Authentication is necessary for the below aspects.

Authorization is a process to determine what types

of grants an agent has. A computer must be pro-

tected from malicious agents, and an agent must

be protected from malicious computers and mali-

cious agents.

Integrity means the property that agents have not

been altered or destroyed in an unauthorized man-

ner. Agents may be tampered with while agents

are on computers and migrates to other comput-

ers.

Conﬁdentiality means the property that agents are

not made available or disclosed in an unauthorized

manner. Data and programs which are contained

in agents must be accessible only to agents which

are authorized to have access.

In this paper, we concentrate on integrity and conﬁ-

dentiality when agents migrate across the Network.

Generally, Secure channels, such as SSL (Secure

Sockets Layer) and IPSec (Security Architecture for

Internet Protocol), between computers via encryption

of network packets are used to protect integrity and

conﬁdentiality. If a secure channel is used in mobile

agent frameworks, all network packets are encrypted

while agents migrate. However an encryption process

uses many resources and causes performance degra-

dation. Therefore, selective encryptions of agents are

preferable, i.e., considering costs of encrypting, some

agents have to be encrypted and others do not. In mo-

bile agent frameworks, every agent should be able to

select a communication channel, i.e., secure type or

not secure type. Moreover, each agents should select

different secure channel so that encryption strength

364

Motomura S., Kawamura T. and Sugahara K. (2007).

NEW IMPLEMENTATION OF RMI TO PROTECT INTEGRITY AND CONFIDENTIALITY FOR MOBILE AGENTS.

In Proceedings of the Third International Conference on Web Information Systems and Technologies - Internet Technology, pages 364-370

DOI: 10.5220/0001274103640370

 SciTePress

can be selected according to the importance of agents.

We consider that the above manner for using se-

cure channels is introduced into mobile agent frame-

works which are implemented in a Java environment.

Because, most mobile agent frameworks, such as

the above mentioned Aglets, Jinni and Mobilespaces,

have been implemented in a Java environment. And

these mobile agents frameworks use Java Remote

Method Invocation (hereafter referred to as RMI)(Sun

Microsystems, 1997) or XML-RPC(Winer, 1998) as

transport mechanisms. In mobile agent frameworks

based on RMI, when several channels are used at the

same time, the same number of sockets are required,

as the result, the same number of ports are required.

In most networks, a ﬁrewall is used to prevent unau-

thorized access to a network, therefore the number of

open ports are limited to be minimum. Therefore, it is

necessary that one port can be associated with multi-

ple sockets. However, Sun’s implementation of RMI

cannot realize the requirement mentioned above. For

this reason, we propose new implementation of RMI

named OnePort RMI that multiple sockets can be as-

sociated with one port. On the other hand, XML-RPC

uses HTTP as the transport protocol. Therefore, we

build an HTTP server and an HTTP client with Mul-

tiChannelSocketFactory which is used in the inside

of OnePort RMI so that the HTTP server can handle

multiple sockets on one port.

To conﬁrm their behaviors, we implement

OnePort RMI and our HTTP client/server on our

mobile agent framework Maglog(Motomura et al.,

2006b; Motomura et al., 2006a). However, we em-

phasize that the proposed OnePort RMI is not only

for mobile agent frameworks such as our Maglog but

also for any RMI applications.

2 WHY WE CANNOT USE SUN’S

IMPLEMENTATION OF RMI?

In this chapter, the behavior of a client communicat-

ing with a server using RMI is described. And, it is

explained that Sun’s implementation of RMI cannot

realize the behavior of RMI which we require.

2.1 Behavior of RMI

RMI enables programmers to create distributed Java

technology-based on Java technology-based applica-

tions, in which the methods of remote Java objects can

be invoked from other JVM on different hosts. When

an object on a client tries to invoke a method of a re-

mote object on a server, the object communicates with

RMI runtime

Stub object

RMI runtime

Skeleton

object

Client’s

object

Server’s

object

RMI registry

Network

Client Server

Figure 1: A model of relation among an RMI runtime, a

stub object, and a skeleton object when a object on a client

invokes a method of a remote objects on a server.

the stub object on client’s JVM which is correspond-

ing with the remote object. A stub object is client’s

proxy for remote objects, and its roles are to hide

network connections and serialization of parameters.

A stub object has an RMIClientSocketFactory object

which creates a socket to communicate with a server.

A skeleton object which is corresponding with a re-

mote object is on server’s JVM, and the skeleton ob-

ject invokes methods of the remote object in effect.

Roles of skeleton objects are to hide network connec-

tions and deserialization of parameters. Stub objects

and skeleton objects are managed by an RMI runtime

on each of the JVMs, moreover the objects are called

automatically by each the RMI runtime if necessary.

An RMI runtime has an RMIServerSocketFactory ob-

ject which creates a server socket to wait for incom-

ing calls from clients. RMIClientSocketFactory and

RMIServerSocketFactory are provided by java’s core

library. Figure 1 shows a model of relations among an

RMI runtime, a stub object and a skeleton object.

A server executes the following steps to export a

remote object so that an object on a client can invoke

methods of the remote object on the the server.

1. An RMIClientSocketFactory object and an

RMIServerSocketFactory object are created.

2. A stub object and a skeleton object are generated

using above objects and the port number which is

used to wait for incoming calls from clients.

3. The stub object and the skeleton object are regis-

tered in server’s RMI runtime.

4. The stub object is registered in server’s RMI reg-

istry which allows remote objects on the server to

client.

NEW IMPLEMENTATION OF RMI TO PROTECT INTEGRITY AND CONFIDENTIALITY FOR MOBILE AGENTS

365

When an object on a client tries to invoke a

method of a remote object on a server, the object gets

the stub object which is corresponding with the re-

mote object from server’s RMI registry. After that,

the object invokes the method for the stub object.

By client’s RMI runtime, a socket is created by the

RMIClientSocketFactory object which is contained

in the stub object. Next, client’s RMI runtime com-

municates with server’s RMI runtime by the socket.

Furthermore, server’s RMI runtime creates a server

socket by the RMIServerSocketFactory object which

is registered in server’s RMI runtime, after that the

server socket communicates with the socket.

2.2 The Reason that we Cannot Use

Sun’s Implementation of RMI

The behaviors of RMI which we require are that a

client can use sockets of different types at the same

time and a server can accept incoming call from the

sockets on only one port. In order to realize the be-

haviors, the following mechanisms are necessary.

1. An RMIServerSocketFactory object must be able

to create multiple server sockets which are corre-

sponding with client’s sockets.

2. A client must be able to select sockets from differ-

ent types which are created by an RMIClientSock-

etFactory object.

In order to implement ﬁrst mechanism, behaviors of

RMIServerSocketFactory and RMIClientSocketFac-

tory are customized. And, it is necessary to solve ei-

ther of the following two problems to realize the sec-

ond mechanism.

1. An RMIClientSocketFactory object is created by

a server, after that when a client tries to use the

object, the object is managed by the RMI runtime

on the client. Therefore, an object on the client

cannot invoke methods of the RMIClientSocket-

Factory object. Namely, the client cannot create

sockets of different types by the RMIClientSock-

etFactory object.

2. A server exports using a pair of an RMI-

ClientSocketFactory object, an RMIServerSock-

etFactory object and a port. If a server exports

using pairs of multiple RMIClientSocketFactory

objects and the same port, a client selects requir-

ing RMIClientSocketFactory object.

It is impossible to solve the ﬁrst problem since RMI

Speciﬁcation does not deﬁne the manner to access

an RMI runtime. Moreover, Sun’s implementation of

RMI does not provide the manner to solve the second

problem.

3 ONEPORT RMI

In chapter 2, we mentioned about the reason why

a client cannot use sockets of different types at the

same time by using Sun’s implementation of RMI.

Therefore, we develop new implementation of RMI

named OnePort RMI which consists of new RMI run-

time, classes which are implemented interfaces de-

ﬁned by RMI speciﬁcation, and MultiChannelSock-

etFactory which are described the following section.

First, MultiChannelSocketFactory is described, after

that propsed RMI runtime is described.

3.1 MultiChannel Socket Factory

In a system which uses Sun’s implementation of RMI,

when a server receives a request from a client, the

server creates an object of ServerSocket class which

is contained in java’s core library by an RMIServer-

SocketFactory object. Next, the ServerSocket object

creates a server socket, after that the server socket

waits for incoming calls. In order to create multiple

server sockets which are corresponding with connect-

ing sockets, steps of above execution must be changed

as follows:

1. A server socket which is created by an object of

ServerSocket class receives a kind of sockets from

a client.

2. The other server socket which is corresponding

with the kind of sockets is created, after that the

server socket communicates with client’s socket.

For the above, on the client side, a socket which is

created by an RMIClientSocketFactory object is nec-

essary to send the kind of sockets, so that MultiChan-

nelClientSocketFactory class which is implemented

RMIClientSocketFactory interface is developed. On

the server side, in order to receive the kind of sock-

ets, MultiChannelServerSocketFactory class which

is implemented RMIServerSocketFactory interface is

developed. Furthermore, MultiChannelServerSocket

class is developed so that the server socket which

is corresponding with the kind of sockets is created.

Figure 2 shows a relation of above classes. The above

classes are deﬁned as MultiChannelSocketFactory.

3.2 Proposed RMI Runtime

In order to export remote objects in which identi-

cal port number is associated with multiple RMI-

ClientSocketFactory, we develop new RMI runtime.

Our RMI runtime is based on an Object Request Bro-

ker (hereafter referred to as ORB) which we have de-

veloped. The main components of our ORB are de-

scribed as follows:

WEBIST 2007 - International Conference on Web Information Systems and Technologies

366

Figure 3: A UML sequence diagram of which a server exports a remote object using our RMI runtime.

MultiChannel

ClientSocket

Factory

RMI Runtime

Socket

MultiChannel

ServerSocke

tFacory

MultiChannel

Server

Socket

Server

Socket

Call

Create

Send:

a kind of socket

Dispatch

Create

Wait

Client

Server

Figure 2: A relation of classes which are contained in Mul-

tiChannelSocketFactory.

ORBServer has a server role in our RMI runtime. It

accepts requests from server sockets.

ORBClient has a client role in our RMI runtime.

When an object on a client invokes methods of

a remote object on a server, ORBClient commu-

nicates with the server instead of the object.

ORBStubFactory generates a stub object, a skeleton

object, and a reference which are corresponding

with a remote object.

ORBDirectory provides the following two func-

tions. The ﬁrst is that objects which are generated

by ORBStubFactory are registered. The second is

that the registered objects are searched.

In our ORB, the following steps are executed when

a server exports a remote object. First, ORBServer

receives an RMIServerSocketFactory object. Next,

ORBStubFactory generates a stub object using a pair

of an RMIClientSocketFactory and a port. Further-

more, ORBServer creates an unique identiﬁer which

is corresponding with the stub object. Finally, ORB-

Server registers the identiﬁer and the stub object in

ORBDirectory. In consequence, a stub object can be

generated using a pair of the other RMIClientSock-

etFactory object and the same port and be registered

in ORBDirectory. Namely, OnePort RMI can real-

ize that a server exports a remote object using pairs

of multiple RMIClientSocketFactory objects and the

same port. Figure 3 shows a UML sequence diagram

of which a server exports a remote object using our

RMI runtime. The UnicastRemoteObject class has

a static method named export for exporting a remote

object. The UnicastRemoteObject class is deﬁned by

RMI Speciﬁcation.

In practice, MultiChannelClientSocketFactory

class and MultiChannelServerSocketFactory class are

used instead of RMIClientSocketFactory class and

RMIServerSocketFactory class.

4 IMPLEMENTATION

OnePort RMI is implemented interfaces deﬁned by

RMI speciﬁcation, and it includes above RMI run-

time. Figure 4 shows an overview of their classes.

NEW IMPLEMENTATION OF RMI TO PROTECT INTEGRITY AND CONFIDENTIALITY FOR MOBILE AGENTS

367

- factory

parent

marshalizer

- server

ORBClient

target

- location

- client

TargetLocation

RemoteRefImpl

# ref

RemoteRef

directory

Registry

RegistryImpl

Remote

RemoteObject

RemoteStub

RemoteServer

RegistryImpl_Stub

ORBDirectory

ORBServerSlave

UnicastRemoteObject

ORBServer

ORBStubFactory

Marshalizer

DefaultMarshalizer

Figure 4: A UML diagram which is an overview of classes

of OnePort RMI.

4.1 Secure Channels

We develop the following two secure channels

into MultiChannelSocketFactory. One is named

DES Channel in which a socket is encrypted using

the Data Encryption Standard (hereafter referred to

as DES) which is a cryptographic algorithm. The

other is SSL Channel in which a socket is imple-

mented using SSL. SSL Channel has the following

security measures,therefore its security is stronger

than DES Channel. On the other hand, DES Channel

is not necessary to have a digital certiﬁcation which

is needed by SSL Channel, therefore DES Channel

provides simple manner for utilizing.

Endpoint authentication Two computer’s identities

can be authenticated using asymmetric cryptogra-

phy such as Public Key Infrastructure.

Integrity checking Message transport includes a

message integrity check using a keyed message

authentication code.

Key exchange A symmetric cipher which is used for

encryption is exchanged between computers on

periodic basis.

DES Channel is realized by DESSocket class and

DESServerSocket class which extend Socket class

and ServerSocket class and implement DES encryp-

tion. SSL Channel is realized by SSLSocket class and

SSLServerSocket class which are provided by Java

Secure Socket Extension. The socket which is not en-

crypted is deﬁned as RAW Channel.

4.2 Applying to Mobile Agent

Framework

We have proposed a mobile agent framework named

Maglog which is based on Prolog and is implemented

in a Java environment. In Maglog, the following pred-

icate is introduced so that each agent can select a

channel.

change channel(PrevChannel,NewChannel)

After an agent is executed the above predicate, the

agent uses NewChannel to migrate to other com-

puters. A kind of channels before changing is bound

to PrevChannel. The following three channels are

deﬁned.

1. RAW: Above RAW Channel.

2. DES: Above DES Channel.

3. SSL: Above SSL Channel.

5 EXPERIMENTS

In this chapter, sample codes using OnePort RMI are

shown. Next, the experimental results for comparison

of execution time between OnePort RMI and Sun’s

implementation of RMI are shown.

5.1 Sample Code

Figure 5 shows a part of a sample code when a server

provides HelloImpl objects using DES Channel and

SSL Channel for clients. In this code, HelloImpl ob-

jects are created, then the objects are exported by

using DES Channel and using SSL Channel. After

that the objects are registered in server’s RMI reg-

istry with names which are “//server/HelloDES” and

“//server/HelloSSL”.

Figure 6 shows a part of a sample code when a

client invokes the HelloImpl objects on the server us-

ing DES Channel and SSL Channel. First, the client

takes stub objects from server’s RMI registry by in-

voking lookup method with the above names. Next,

the client invokes a method of the stub classes. Inci-

dentally, HelloImpl class implements Hello interface.

WEBIST 2007 - International Conference on Web Information Systems and Technologies

368

Figure 5: HelloImpl objects are provided using

DES Channel and SSL Channel for clients.

Figure 6: A client invokes the HelloImpl objects using

DES Channel and SSL Channel.

5.2 Comparison of Round Trip Time

between OnePort RMI and Sun’s

Implementation of RMI

This section presents the experimental results for

comparison of the round trip time for a remote method

invocation between OnePort RMI and Sun’s imple-

mentation of RMI. In the experiments, two PCs were

connected via a 100Base-T network. Under each

implementation, the experiments are performed 100

times using three channels in the following condi-

tion. A client invokes a method of a remote object

on a server with an argument which is a byte array.

The data sizes of the argument are 1KB, 5KB, 10KB,

50KB, 100KB, 500KB, and 1000KB. The total times

are shown in Figs. 7, 8 and 9. The differences of

the round trip time between OnePort RMI and Sun’s

implementation of RMI is small at all channels.

100

1000

10000

1 10 100 1000

time [ms]

data size[KB]

OnePort RMI

Sun’s implementament of RMI

Figure 7: Comparison of the round trip time between

OnePort RMI and Sun’s implementation of RMI when

RAW Channel is used.

100

1000

10000

100000

1 10 100 1000

time [ms]

data size[KB]

OnePort RM

Sun’s implementation of RMI

Figure 8: Comparison of the round trip time between

OnePort RMI and Sun’s implementation of RMI when

DES Channel is used.

6 CONCLUSION

We have developed new implementation of RMI

named OnePort RMI. OnePort RMI consists of new

RMI runtime, classes which are implemented RMI

speciﬁcation, and MultiChannelSocketFactory. Us-

ing OnePort RMI, when an object on a client invokes

methods of remote objects on a server, the client can

use sockets of different types to connect one des-

tination port at the same time, and the server can

accept incoming calls from the sockets on only the

port. We have developed two secure channels such

as DES Channel and SSL Channel into MultiChan-

nelSocketFactory. When other secure channels are

needed, they can be added to MultiChannelSocket-

Factory easily.

Note that though we have conﬁrmed the effective-

ness of OnePort RMI on our mobile agent framework

NEW IMPLEMENTATION OF RMI TO PROTECT INTEGRITY AND CONFIDENTIALITY FOR MOBILE AGENTS

369

100

1000

10000

100000

1 10 100 1000

time [ms]

data size[KB]

OnePort RMI

Sun’s implementation of RMI

Figure 9: Comparison of the round trip time between

OnePort RMI and Sun’s implementation of RMI when

SSL Channel is used.

Maglog, OnePort RMI can be utilized by any RMI

applications.

In this stage, though OnePort RMI has all neces-

sary functions to handle multiple sockets on one port,

it is not full compatible with RMI speciﬁcations. For

example, OnePort RMI lacks a distributed garbage

collector or conﬁguration properties. They will be im-

plemented in future work.

REFERENCES

Farmer, W. M., Guttman, J. D., and Swarup, V. (1996). Se-

curity for mobile agents: Issues and requirements. In

Proc. 19th Nat’l Information Systems Security Conf.

(NISSC 96), pages 591–597.

J.Tardo and Valente, L. (1996). Mobile agent security and

telescript. In Compcon ’96. ’Technologies for the In-

formation Superhighway’ Digest of Papers, pages 58–

63.

Karjoth, G., Lange, D. B., and Oshima., M. (1997). A se-

curity model for aglets. IEEE Internet Computing,

01(4):68–77.

Lange, D. B. and Oshima, M. (1998). Programming and

Deploying Java Mobile Agents with Aglets. Addison

Wesley.

Motomura, S., Kawamura, T., and Sugahara, K. (2006a). A

logic-based mobile agent framework for web applica-

tions. In Proceedings of the 2nd International Confer-

ence on Web Information Systems and Technologies,

pages 121–126. Setubal, Portugal.

Motomura, S., Kawamura, T., and Sugahara, K. (2006b).

Logic-based mobile agent framework with concept of

ﬁeld. IPSJ Journal, 47(4).

Satoh, I. (2000). Mobilespaces: A framework for building

adaptive distributed applications using a hierarchical

mobile agent system. In Proceedings of IEEE Interna-

tional Conference on Distributed Computing Systems,

pages 161–168. IEEE Press.

Sun Microsystems (1997). Java re-

mote method invocation. Web page.

http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-

title.html.

Tarau, P. (1999). Inference and computation mobility with

jinni. In Apt, K., Marek, V., and Truszczynski, M.,

editors, The Logic Programming Paradigm: a 25 Year

Perspective, pages 33–48. Springer.

White, J. E. (1994). Telescript Technology: The Foundation

for the Electronic Marketplace. General Magic.

http://www.genmagic.com/WhitePapers.

Winer, D. (1998). Xml-rpc speciﬁcation.

http://xmlrcp.com/spec.

WEBIST 2007 - International Conference on Web Information Systems and Technologies

370