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:
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:
provides a runtime environment for MC and VMC
guards the system from malicious attacks
provides services such as migrating facility, inter-agent communication (facilitator and mediator)
A dynamic program for a specific task
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:
|
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.
There are few examples of mobile code that can be injected into the network:
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.
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,
|
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:
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:
|
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:
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:
The jar, TelnetDaemon.jar, can be seen with command:
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.
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.
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
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
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
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
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.
