Abstract

Mobile Agents are software programs that can »jump« from one computer to another over the Internet and thereby autonomously search for information or carry out other tasks. Distributed systems are pushed to their limits by mobile agents, since not only can the computations be distributed, but also the program code that performs them. With the help of mobile agent technology, algorithms for filtering data can be transported directly to the source of that data and then only the results of this filtering have to be sent over the network.

Contact

Christoph Busch
Email: christoph.buschh-da.de

Volker Roth
Mehrdad Jalali
Ulrich Pinsdorf

Secure Mobile Agents (SeMoA)

Since mobile agents carry their program code with them, filtering can also take place in disconnected mode. In other words, the computer from which a mobile agent is dispatched does not have to maintain a permanent network connection. The network connection is only required again when the mobile agent wishes to return or transfer its results. In order to exploit such benefits, the utilized mobile agent solution has to be able to cope with a number of threats. The route of a mobile agent can include several servers, even those of competing operators. A malicious server could monitor, manipulate, or modify an agent’s data in such a way that the agent causes damage to other servers - in other words, it could use an agent as a trojan horse, there- by incriminating the agent’s owner.

On the other hand, a malicious agent could also try to attack a server, in order to obtain unauthorized access. Another alternative involves the agent attacking other agents that are hosted by the same server. Mobile agents are a perfect hiding place for viruses, worms and trojan horses. In particular, mobile agents could use their servers as a base for launching attacks on other servers, thereby concealing their tracks. Servers, as well as agents, can also be the target of attacks »from outside«. An attacker could attempt to manipulate agents while they are being transfered over the network. A sophisticated security model must be able to handle these threats, as well as others, so that this fascinating technology can be exploited.

SeMoA Security Architecture

SeMoA’s security architecture can be compared to an onion: agents have to pass through an entire series of security layers before they are allowed into the runtime system and the first class of an agent is loaded into the server’s JVM.

The first (outermost) layer is a transport layer security protocol like TLS or SSL. This layer provides mutual authentication, transparent encryption and integrity protection. Connection requests of authenticated servers can be accepted or rejected on the basis of a configurable security policy.The second layer consists of a pipeline of security filters. Separate pipelines for incoming and outgoing agents are supported. Each filter inspects and processes every incoming/outgoing agent, and accepts or rejects it. We also call this filtering process »content inspection« in analogy to comparable concepts in the area of firewalls. SeMoA currently offers two complementary filter pairs that support digital signatures and selective encryption (signature verification and decryption of incoming agents, as well as encryption and signing of outgoing agents). An additional filter at the end of the pipeline for incoming agents assigns permissions to agents on the basis of a configurable security policy and information from previous filters. The filters themselves can be dynamically registered or unregistered at runtime or also directly at the boot time of the SeMoA server.

After an agent has successfully passed through all filters, SeMoA generates a socalled »sandbox« for the agent (this can be viewed as the fourth layer). Each agent is assigned its own thread group and its own class loader. Deserialization of an agent occurs through a thread already running in the agent’s thread group, which becomes the agent’s first thread. Serialization occurs again through this thread after all other agent threads have terminated. Only then does SeMoA migrate this agent to its next target. This prevents agents from migrating and then refusing to terminate. An agent’s classes are loaded by its class loader. The class loader supports the loading of classes that are bundled with the agent, as well as the loading of classes from sources that are specified in the agent in the form of URLs. All loaded classes (except for the locally installed ones) are verified against a list of cryptographic hash values that the agent owner has signed together with the agent (this can be considered layer three). So, only those classes are loaded that the agent owner has released for the agent. This prevents an agent from being able to load a trojan horse into another agent in the form of a class with the same name.

Before a class can be loaded into the Java VM, it must - just like an incoming agent - pass through a pipeline of filters for bytecode. SeMoA contains a filter that rejects the loading of classes that implement the finalize() method. Malicious agents could implement this method to attack the Java VM garbage collector. Additional filters could be used, for instance, to add a transparent resource management for agents.

Agents are strictly separated from other agents in the server. In general, it is not possible to exchange object references with other agents. The only possibility for such an exchange is in the so-called »global environment«. Within this environment, objects can be published and requested. However, this environment wraps each published object in a dynamically generated proxy, so that references to the actual objects are never released. This occurs automatically, for instance, if the registering agent terminates, and thus enables the garbage collection of the released objects.

Agent Structure

SeMoA transports mobile agents as Java Archives (JAR files). The JAR specification from Sun Microsystems extends the widely distributed zip format to provide mechanisms for adding signature files to the contents of such archives. The digital signature format is PKCS#7, a standard for cryptographic messages that builds upon other standards, such as, for example, ASN.1, X.501 and X.509.
SeMoA extends the JAR format to include mechanisms for the selective encryption of JARs for multiple recipients. The PKCS#7 format is also used here.

The enand decryption occur transparently for the agents, which greatly simplifies their development and makes it much more secure. The execution of the cryptographic operations is assumed by the above-mentioned security filters. Attacks launched by copying encrypted data from one agent to another (cut & paste attacks) are detected through a cryptographic »proof«.

Each agent is signed twice. The agent owner signs its static part (the part that cannot be changed for the life of the agent) and authorizes the agent to operate in his name. Each server that forwards this agent signs the complete agent (the volatile and the static part) and thereby binds the current state of the agent to its static part.

SeMoA also computes implicit names for agents by applying the SHA1 one-way hash function to the owner’s signature. This guarantees that agent names are globally unique and anonymous. SeMoA uses these names for agent tracing and the locationindependent routing of messages between agents.