Mobile  Code  Toolkit  Tutorial  By  Gatot  Susilo  

under the supervision of Prof. Andrzej Bieszczad Department Systems and Computer Engineering

Carleton University, 1125 Colonel By Drive Ottawa, Ontario, Canada K1S 5B6

Introduction The Network management is currently dominated by systems based on

client/server technologies. These technologies imply a distributed system. Typically, network devices with running agents (acting as servers) distributed throughout the networks wait for requests and then respond back to the centralized inquiring manager (acting as a client). In most cases, the agent is static and proprietary to the managed device (i.e. a router, a workstation, etc.). In terms of its functionality, it is difficult to modify and extend its behavior. Manager applications are very often monolithic and large to be able to support a variety of multi-vendor specific agents. This approach suffers from an information bottleneck on the manager side and is inefficient in using the network due to the traffic transporting data just for the management of the network. Things have improved with the advent of the Web. Network managers want to have management accessible from the Web. Therefore, a large, monolithic manager application is no longer appropriate.

In this paper, we introduce an infrastructure that is required for a new approach to network management based on mobile code or mobile agent. The agents are no longer statically resident on managed devices; in contrast, they are mobile, replaceable at any time as necessary (no more software upgrading problems), and can disappear if not needed anymore. A mobile agent may be specialized. For example, it may be equipped with mini expert systems that can diagnose and fix network faults on behalf of the manager. There are a few major concerns regarding mobile code. First, because today’s networks are typically heterogeneous and very often comprised of multi-platform, multi-vendor network components, the mobile code should be portable and run on each of those platforms. Secondly, security has been traditionally one of the major concerns. Mobile code is often active and may maliciously endanger the integrity of the managed devices. In performing its tasks, the mobile agent may carry its persistent state from one node to the next and also require a communication channel with other agents. The main goal of our research on mobile agents is their use in network management. Therefore, additional issues like access to managed resources and the way the agents manipulate data for network managing purposes are also important.

Infrastructure  

Figure 1 Infrastructure for Mobile Code Technology

Figure 1 shows the infrastructure for mobile code technology that is

already implemented in the Mobile Code Toolkit package. Every network component runs a Mobile Code Daemon (MCD) within a Java Virtual Machine (JVM) environment. The MCD provides a number of services that allow the execution of mobile code in order to perform its tasks. Those services are a runtime environment, a migration facility to transport mobile code to the next destination, a communication facility for mobile code residing not only on the same virtual machine but also on a different virtual machine, and an interface to access managed resources of the network component.

The MCD listens to both UDP and TCP connections ready to accept mobile code. The mobile code (e.g., a netlet is one of our mobile agents) received in a compressed format is passed into the Instantiator. While the Instantiator decompress the received code, it also authenticates and checks its data integrity. If the authentication is successfully conducted, the mobile code will be stored in the Storage Manager and instantiated as a thread with a separate thread group from the daemon otherwise the mobile code will be discarded. The Mobile Code Manager keeps track and stores the handles of instantiated mobile code; therefore, the mobile code will not be garbage collected.

Mobile agents communicate not only with each other, but also with the environment. They need to access the managed resources to perform network management tasks. Even though certain international organizations have defined standards that must be used by the manufactures to implement their products,

there are still many offerings that do not adhere to the standards. Some vendors may implement their products with proprietary attributes. This leads to problems while accessing the managed resources of diverse implementations of network components. To address this issue, mobile code communicates with managed resources of a network component indirectly through so-called Virtual Managed Component (VMC). The VMC provides a uniform access to the managed resource no matter what the underlying platform and the implementation are. Therefore, the same mobile code can be used on a variety of vendor specific network components.

Because the mobile code is active program, this leads to security threats such as viruses, private data disclosure, etc. To guard the network component from these threats, the daemon is completed with security feature in addition to the basic security feature of JAVA, byte code verifier. The first line of defense is authentication and data integrity. The authentication is based on user who signs the mobile code. If the signer is trusted, the mobile code can be accepted and instantiated. The data integrity is used to make sure the received mobile code is not corrupted or altered during transmission. Secondly, the Security Manager may be optionally installed to protect the network component during the mobile code runtime. The security manager implements security rules such as:

• Mobile code does not allow to access file systems • Mobile code does not allow to create a class loader • Only authorized users allow to access handles of Storage Manager and/or

Mobile Code Manager of the daemon • Mobile code does not allow to create a new process • etc.

With the security features installed, the network component is considerably safe from the attacks of harmful mobile code.

In general, the infrastructure consists of three major role players: • Mobile Code Daemon

o provides a runtime environment for MC and VMC o guards the system from malicious attacks o provides services such as migrating facility, inter-agent

communication (facilitator and mediator) • Mobile Code or Mobile Agent (MC)

o A dynamic program for a specific task • Virtual Managed Component (VMC)

o Provides an interface between managed resources and mobile code

Flow  Diagram  of  Infrastructure’s  Operation  

Figure 2 Flow Diagram of Infrastructure's Operation

Figure 2 shows the general operation of the infrastructure for code

mobility. Assume that a chunk of mobile code is about to be sent from one network component (the sender) to another (the receiver). Through the MCD’s migration facility (via either UDP or TCP connections) the sender sends the signed and compressed code (i.e., bytecode), the parameters and the persistent state obtained from serializing the instance of the mobile code. The receiver will receive and store them in the designated space for that particular mobile code. After the transmission is completed, the receiver verifies the code for authentication and data integrity. If the code passes the checks, it will be instantiated (subject to standard JVM security checks); otherwise, it will be discarded by the MCD. The mobile code may or may not have persistent state. If it has a persistent state, then de-serializing it will restore the state. That process will then be followed by calls to the methods onRestore() and onStart(). Otherwise, the mobile code will be instantiated and the methods onInit() and onStart() will be called. At this point, the mobile code is up and running as a thread. To access the managed resources, the agent obtains a handle to the VMCs from a so-called Mobile Code Manager (MCM). The methods in the agent’s code are called in an event-driven mode triggered by the MCD, other agents or the agent itself.

When an agent’s migration is requested by the manager, another agent, or the agent itself, the MCD calls method onMigrate() of the associated agent. This notifies the agent that it is about to be transported to next destination. Therefore, the agent will have time to finish its task and notify the MCD whether or not it wants to keep its persistent state or it refuses to migrate. If the agent

really wants to migrate, the MCD will start shipping the agent with the associated persistent state as necessary. When the migration has completed, the agent is destroyed and removed from the MCD. However, when the migration fails for some reasons, the agent is notified by calling its method onFailMigration(). Therefore, the agent may determine what it wants to do next. For instance, if the migration fails because of unreachable destination, the agent may alter the destination or just simply terminate itself. On destroying the agent, the MCD calls the method onDestroy() to ensure that the agent stops its tasks and perhaps releases its memory space, acquired resources, etc.

Inter-­‐Agent  Communication  

Figure 3 Inter-Agent Communication

Figure 3 shows the communication between agents not only on the same

network component but also on the different one. To enable inter-agent communication facility, every MCD must install the facilitator and one or more MCDs have the mediator installed. Once the MCD instantiates a mobile agent, it will register the agent to the facilitator (local database) that automatically relays the registration to the mediator (global database). Suppose two mobile agents exist on the same network component or more precisely on the same MCD and one of the agents wants to send a message to another. The message will be received by the facilitator and deliver it locally to the recipient. However, if the recipient is on a different MCD, the facilitator will relay the message to the mediator. The mediator knows exactly where is the current location and conveys

the message to the facilitator where the recipient is running to deliver the message. If the mediator does not find the location of the agent because the agent does not exist yet in the network, it will keep the message until the agent appears in the network.

The inter-agent communication service supports not only point-to-point communication but also broadcasting. Suppose an agent wants to broadcast a message, the message will be relayed directly by the facilitator to the mediator. The mediator duplicates and sends the message to every agent that the mediator knows of.

In the package, the mediator is implemented as a virtual managed component. Therefore, the manager may know agents that exist in the network and where is their current location, etc simply by sending an agent and querying the mediator.

Mobile  Code  Toolkit  

The mobile code toolkit implements the infrastructure that has been described above. The toolkit 100% written in JAVA consists of five packages:

• mct.admin • The admin package consists of components to build a mobile code

daemon. • mct.net • This package implements a transport protocol so-called Code Transport

Protocol (CTP) to transport the mobile code with its persistent states from one destination to another

• mct.security • This provides authentication, data integrity, and security manager to

protect the network component from malicious mobile code. • mct.mediator

• This package provides a mobile code registration and as well communication between mobile code.

• mct.users • This package provides interfaces to build mobile agents and virtual

managed component.

The toolkit package can be obtained from the Perpetuum Web page. The distribution is available in zip format. The diagram shows the directory structure of the package after unzipping.

• source code of the package – under sub-directory src, • JAVA compiled classes of the package – under sub-directory classes, • examples of using the package – under sub-directory examples, • There are few examples of mobile code that can be injected into the

network: • Hello – prints the word hello world on console • McTicTacToe – demonstrates that the mobile code can maintain its

persistent state carried along during migration. • NetletTester – demonstrates that the mobile code accesses the data

implemented in the Virtual Managed Component container and is also capable of migrating to the next destination.

• TelnetDaemon – demonstrates how to add a new service (extension) to the NetletDaemon. In this case, the TelnetDaemon (server) can accept a telnet client applications and prompts for commands.

• Installer – demonstrates how the mobile code can install another mobile code. For instance, an agent Netlet is used to install a virtual managed component (VMC) that does not exist yet. The netlet will pull a mobile code from repository and install it on the daemon.

• NetComm – demonstrates the communication between mobile codes. Subdirectory Signers (i.e. examples/Signers) contains examples of public

key and private key and certificates that must be imported into your persistent database of key management if you enable security feature of the NetletDaemon. Please consult javakey tool documentation how to install/import keys from files.

• a simple client to fetch the NetletDaemon – under sub-directory WinMCTClient

• The NetletDaemon can be found under subdirectory src\mct\ and can be executed by calling:

o java mct.NetletDaemon netletdaemon01.properties The netletdaemon01.properties is a configuration file to execute the

NetletDaemon. The example of the configuration file can be found under subdirectory conf,

• other files – javadoc of the mobile code package.

Requirements    The JAVA portability has made the code distribution much simpler without

recompiling from one platform to another. To able to use the package, it just needs the Java Development Kit version 1.1.3 above that can be obtained freely from Sun Microsystems Inc. http://www.javasoft.com or any JDK compatible. Because the toolkit is TCP/IP applications, the system must have TCP/IP stack installed.

The  Daemon  The class mct.NetletDaemon subclass of mct.admin.MobileCodeDaemon

is the daemon that is ready to do the job as described above. The daemon is a generic and extensible. It allows installing a mobile code after the daemon starts. The installed code can provide a new service for the daemon. Moreover, it is relative simple and easy to use. To invoke the daemon (i.e., start java mct.NetletDaemon configuration_file; under Windows 95/NT), it requires a configuration file that consists of six major parts:

• identity • listening ports • default migration destination • facilitator setup • installing mobile code during daemon start-up • security • enable/disable security feature • enable/disable MCDSecurityManager • list of authorized users to access StorageManager or MobileCodeManager

The following is an example of configuration file. # @(#)netletdaemon01.properties Gatot Susilo September 6, 1997 # # The NetletDaemon uses this property file to determine its behaviour. # There are six main parts of properties that should be completed: # 1. IDENTITY # This is the identity of the daemon itself. Since each network # element has the daemon running, the serial number of the network # element may be a appropriate identity for the daemon. # 2. LISTENING PORTS # The listening ports determine where the daemon receives the # incoming mobile codes. # 3. DEFAULT MIGRATION DESTINATION # The migration destination of mobile codes may be determined by # the mobile codes themselves. However, when the destination # is not specified, the daemon uses the default migration # destination as specified in this property. # 4. FACILITATOR SETUP

# Facilitator may be optionally installed on the daemon. # The Facilitator is an additional service of the daemon to allow # the mobile code to communicate (exchange information) with # others that reside not only on the same daemon but also on different # daemon accross the network. The later requires another daemon # running mct.Mediator to relay the message until it reaches the # destination. # 5. INSTALLING MOBILE CODE DURING DAEMON START-UP # You are allowed to install mobile code that exists in the # CLASSPATH; therefore, you may have initial mobile code running # as soon as the daemon is started. In addition, the JAR files # of the installed mobile code can be loaded as well; therefore # the mobile code can be migrated or transported to other # destination. # 6. SECURITY # If the security is enabled, the mobile code must be signed by # trusted identities stored in the JAVA persistent key management # database (i.e., identitydb.obj; maintainable with javakey tool). # MCDSecurityManager can be enabled as well to guard the system # from malicious mobile code that may introduce viruses, etc. # The MCDSecurityManager does not allow the mobile code to # access filesystem, create classloader, etc. The user list # to access the StorageManager and MobileCodeManager is also # provided. ######################################################################## ######################################################################## # Specify the netlet daemon id # the id is typicaly the device's serial number which is unique. ######################################################################## netletdaemon.id=ND0001 ######################################################################## # Listening ports where the daemon accepts the mobie code. ######################################################################## netletdaemon.listen.tcp.port=3100 netletdaemon.listen.udp.port=3200 ######################################################################## # Default destination of mobile code migration ################################################################

######## netletdaemon.default.migration.tcp.ip=localhost netletdaemon.default.migration.tcp.port=3300 netletdaemon.default.migration.udp.ip=localhost netletdaemon.default.migration.udp.port=3400 netletdaemon.default.protocol=tcp ######################################################################## # Set up Facilitator # If you want to diable it, set: netletdaemon.facilitator=false. # I don't bother with auto discovery of mediator's location. # So just specify the address of mediator here. ######################################################################## netletdaemon.facilitator.enable=true netletdaemon.facilitator.port=8888 netletdaemon.mediator.ip=localhost netletdaemon.mediator.port=6666 ######################################################################## # Install mobile code that exists in the classpath # You can install more than one mobile code during daemon's start up. ######################################################################## #netletdaemon.install.mobilecode.0=mct.mediator.Mediator #netletdaemon.install.mobilecode.1=mct.mediator.Communicator #netletdaemon.install.mobilecode.2=packageName.ClassName ######################################################################## # Install mobile code jars file # By installing the JAR, the mobile code can be transported to other host # by the daemon (Migratable). ######################################################################## #netletdaemon.install.mobilecode.jar.0=mct.mediator.Mediator #netletdaemon.install.mobilecode.jar.0.0=filename0.jar #netletdaemon.install.mobilecode.jar.0.1=filename1.jar ######################################################################## # Security ########################################################################

netletdaemon.security.enable=true netletdaemon.security.enable.MCDSecurityManager=true ### # NEXT LINE IS NOT IMPLEMENTED YET #netletdaemon.security.url.key.database=url ######################################################################## # The authorized signers that can access MobileCodeManager and/or # StorageManager ######################################################################## netletdaemon.security.root=Admin netletdaemon.security.user.allows.access.mobilecodemanager.0=Admin #netletdaemon.security.user.allows.access.mobilecodemanager.1=Admin1 netletdaemon.security.user.allows.access.storagemanager.0=Admin #netletdaemon.security.user.allows.access.storagemanager.1=Admin1 There are three ways to instantiate a mobile code. A mobile code:

• may be received by the daemon on its well-known port numbers, and then it will be instantiated after passing security checks.

• may be instantiated as soon as the daemon is started. This can be done by adding an entry of mobile code that is going to instantiated, on the daemon configuration file. One of the benefits a mobile code installed by this method is by-passing the security checks of the daemon. This is simply because the mobile code is trusted and it is not downloaded from anywhere.

• may be installed by other mobile code which implements MCDExtension. Therefore, a mobile code may pull another mobile code from repository and install it. This should give a greater benefit in dynamically installing a mobile code.

The  Client  

Figure 4 WinMCTClient, a simple client to inject a mobile code to the daemon

Figure 4 shows the interface to inject a mobile code to the daemon. In this case, a mobile code called Hello whose classes, Hellor.jar.sig, are stored in JAR format and signed by proper user is about to be sent to the daemon that listens at localhost port 3100 for TCP connection. Even though the mobile code may carry any object type of parameters, the interface only allows String parameters.

Writing  Mobile  Code  The package mct.users is devoted to write a mobile code. As seen on

Figure 5, there are two kinds of mobile code: mobile agent and virtual managed component. To write a mobile agent, the agent must implement interface MobileCode. The agent may be extended with provided features by choosing the building components to meet the agent needs. To write a virtual managed component, the VMC must implement interface VMCMobileCode. It may be extended with any features available as seen Figure 5.

Figure 5 Building Componets to write a Mobile Agent and a Virtual Managed

Component The building components consist of interfaces that can be implemented for

any combinations to suit the needs. Those are: • MobileCode • Every mobile agent must implement this interface. The interface gives

identification for the mobile agent. • Callback • This allow the event driven invocation of methods as described on flow

diagram of infrastructure operation. • Parameters • This interface allow the mobile code to store and retrieve data that can be

carried along during migration. The parameter may hold any data objects whose classes exist in the CLASSPATH subdirectory and also must

implement java.io.Serializable. • Migratable • This interface allows the mobile code to migrate from one host to another. • MCDExtension • This interface allows the mobile code to access handles of the

StorageManager and MobileCodeManager which are core of mobile code daemon. Moreover, the mobile code implementing this interface allows to install another mobile code.

• VMCAccess • This interface allows the mobile code to access any installed VMC on the

daemon. • MessagingAccess • Only mobile code implementing this interface can send and receive a

message from one to another. • VMCMobileCode • This is a subclass of MobileCode. This interface is used to distinguish

whether the mobile code or simply the virtual managed component. • VMCManagedResources • The interface provides methods as found on the SNMP to get and set

managed resources. • VMCProvisioningProcedures • This interface is used typically for a VMC that is instantiated during

daemon start-up. The methods will be called for mobile code daemon registration, or any daemon configurations.

• VMCRecoveryProcedures • This interface provides methods that should be called if there are any

errors occur. Basically it is used for self-testing, self-diagnostic, automatical recovery.

• VMCManagementApplet • This returns a URL where the applet can be downloaded to manage the

particular VMC. It should be noted when creating a mobile code. The mobile code is

instantiated by using class loader. Therefore, the class constructor for the mobile code must be without argument. The class loader searches classes only in the CLASSPATH and MobileCodeContainer (i.e., a container for a mobile code classes and data) for each mobile code. Each mobile code has its own name space so that no mobile agents that conflict with other classes even though having the same class name.

Persistent  States  There are two ways to keep a persistent state (data) that can be carried

along during mobile code migration. Those are through serialization and parameters (i.e. one of the building components).

Serialization  To use the serialization, the mobile code must implement interface

java.io.Serializable. Every associate objects that must be kept persistent also have to implement interface java.io.Serializable. The fields that are not serialized must be declared transient.

Parameters  Users may want to keep a particular data persistent. The parameters

perhaps is easier to do the task than the serialization does. Moreover, it allows to keep any kind of objects whose classes exist in the CLASSPATH. The classes must implement java.io.Serializable. Those classes that available are String, Integer, Float, etc.

Example  of  Mobile  Code  For better understanding of building a mobile code, please see the

examples on toolkit distribution and see as well the source code of mct.users.Netlet (e.g., a mobile agent) and mct.users.VirtualManagedComponent (e.g., a virtual managed component). The examples provided mostly extend these two classes.

Signing  A  Mobile  Code  Signing a mobile code involves using the JDK’s tools: jar and javakey that

are included on JDK 1.1.x and above distribution. The following will present how to create a jar file and how to sign it. The examples of using the tools are those that are relevant to the mobile code toolkit. For further documentation on those tools, please consult JDK documentation.

JAR  (JAVA  Archive)  The mobile code daemon accepts the code in JAR format only. The JAR

supports for code signing that is appropriate to deliver a trusted mobile code. JAR command line is like a tar command line on most UNIX. If the mobile code consists of packages, the subdirectory that represents the name of package should be included in JAR. For instance, the mobile code is implemented as a package so-called mc01.TelnetDaemon, the JAR should include subdirectory mc01 instead of just a file itself TelnetDaemon.

Example:  The classes of TelnetDaemon have been created on subdirectory

%classes%. Since TelnetDaemon is implemented as a package mc01, then the

classes created will be put on subdirectory %classes%\mc01. Thus the classes can be put on jar namely TelnetDaemon.jar as following:

• cd %classes% • jar –cf TelnetDaemon.jar mc01 • The jar, TelnetDaemon.jar, can be seen with command: • jar –tf TelnetDaemon.jar You should see the subdirectory mc01 is included in the JAR.

Javakey  The security feature of the daemon may be optionally enabled. If the

security feature is enabled, signers trusted by the daemon must sign the jar files of mobile code. The JAVA uses a persistent key management database that can be accessed by JVM and is also manageable by using javakey tool. The examples of signers have been provided as well (see subdirectory examples\Signers). The examples of mobile code are signed by these signers. Therefore, to inject the examples to the daemon, the public, private keys and certificates of users must be imported into the database. The following example how to import those of Duke into the database.

• cd %mctoolkit%\v1.0\examples\Signers • javakey –cs Duke true (create an identity Duke as a trusted identity) • javakey –ikp Duke Duke_pub Duke_priv (import keys for Duke) • javakey –ic Duke Duke.x509 (import a certificate for Duke) It should be noted that to sign a mobile code, the private key is used. To

authenticate the signer, the public key is used. Therefore, the daemon that authenticates the received mobile code just requires the public key in its database. Private key must be kept secret and safely stored. Exposure the private key to public may be misused by hostile person to introduce a virus or so to the daemon.

To sign a jar file, a sign directive file must be created. The following is an example of the sign directive file namely sign_directive_Duke that is adopted from javakey documentation. # @(#) sign_directive_Duke # Jar signing directive. This is the directive file used by javakey to # sign a jar file. # Which signer to use. This must be in the system's database. signer=Duke # Cert number to use for this signer. This determines which # certificate will be included in the PKCS7 block. This is mandatory # and is 1 based. cert=1 # Cert chain depth of a chain of certificate to include. This is # currently not supported. chain=0

# The name to give to the signature file and associated signature # block. (i.e. DUKESIGN.SF and DUKESIGN.DSA). This must be 8 # characters or less. signature.file=dukeSig

Once the sign directive file is created, the following is an example how to sign a jar file namely TelnetDaemon.jar.

• javakey –gs sign_directive_Duke TelnetDaemon.jar As a result of this command, the TelnetDaemon.jar is signed and a new file

TelnetDaemon.jar.sig is created as the signed TelnetDaemon.jar. The following is a step-by-step how to create a new identity, its public, private

keys and also its certificate. This example is adopted from javakey documentation.

• Step 1: Create the Duke identity as a Duke as a trusted identity o javakey –cs Duke true

• Step 2: Generate a key pair for Duke and store the public key in a file named Duke_pub and the private key in a file named Duke_priv

o javakey –gk Duke DSA 512 Duke_pub Duke_priv • Step 3: Generate a x509 certificate and store in a file named Duke.x509.

This output file name is given in the directive file named cert_directive_Duke

o javakey –gc cert_directive_Duke

This is the content of the directive file. # This is a sample certificate directive file. # the id of the signer issuer.name=Duke # the cert to use for the signing issuer.cert=1 # the id of the subject subject.name=Duke # the components of the X500 name for the subject subject.real.name=Duke subject.org.unit=JavaSoft subject.org=Sun MicroSystems subject.country=US # Various parameters: start and end date for validity and expiration # of the certificate. Serial number. FIle to which to output the # certificate (optional).

start.date=17 Jan 1997 end.date=16 Jan 1998 serial.number=1001 out.file=Duke.x509

• Step 4: Sign the jar file (e.g., TelnetDaemon.jar) using the parameters given in sign_directive_Duke

o javakey –gs sign_directive_duke TelnetDaemon.jar

The signed version file named TelnetDaemon.jar.sig is created. The file is ready to be shipped to the daemon.

After reading through all this tutorial, hopefully you get the idea of the toolkit and you are ready to write a mobile code for your specific applications. You may find the applications of this toolkit on the Perpetuum Mobile Procura Group Web page.