ATOMAS A Transaction-oriented Open Multi Agent-System. Final Report

ATOMAS:

Universität Stuttgart

Fakultät Informatik

ATOMAS: A Transaction-oriented Open

Multi Agent-System. Final Report

Authors:

Dipl.-Inform. M. Straßer

Dipl.-Inform. J. Baumann

Dipl.-Inform. F. Hohl

Dr. M. Schwehm

Prof. Dr. K. Rothermel

Institut für Parallele und Verteilte

Höchstleistungsrechner (IPVR)

Fakultät Informatik

Universität Stuttgart

Breitwiesenstr. 20 - 22

D-70565 Stuttgart

ATOMAS:

I V

P R

ATOMAS:A Transaction-oriented Open Multi Agent-SystemFinal Report

A Project Funded By Tandem Inc., Cupertino

22.6.1998

Authors: Prof. Dr. K. Rothermel Dr. M. Schwehm Dipl.- Inform. J. Baumann Dipl.- Inform. F. Hohl Dipl.-Inform. M. Straßer Institute for Parallel and Distributed High Performance Systems University of Stuttgart Breitwiesenstraße 20-22 D-70565 Stuttgart

ATOMAS:

ContentsContents

Section 1:Introduction

Section 2:Workplan and Project State

WP 2.1: Design and Implementation of Agent Migration

WP 2.2: Requirement Analysis Concerning Security

WP 2.3 Recoverable Agents

WP 2.4 Developed Concepts and Implementation

Orphan Detection for Mobile Agent Systems

Section 3:WP 2.2: Security

Abstract

Introduction

The Problem of Malicious Hosts

Existing Approaches

Blackbox Security: The Idea

Mobile Cryptography

Time Limited Blackbox Protection

What Is Changing If the Blackbox Is Time Limited?

No communication with a third party

Communication only with trusted servers

Communication with untrusted servers

Migration of the agent

How Can We Reach Time Limited Blackbox Protection?

Agent mess-up algorithms

Agent attributes that can be modified

Statements

Data

Abilities and characteristics of the attacker

Examples for mess-up algorithms267777789991013141516161617171919202020212121

ATOMAS:

ContentsVariable Recomposition

Conversion of Control Flow Elements into Value-Dependent Jumps

Deposited Keys

Counter attacks

Variable Recomposition

Conversion of Control Flow Elements into Value-dependent Jumps

Deposited Keys

Problems with mess-up algorithms

How can a blackbox protected agent be created?

Recharging of protected agents

Which Other Attacks by Malicious Hosts Can Be Prevented Using

Blackbox Protection?

New Attacks: Sabotage and Blackbox Testing

What Blackbox Security Costs

Conclusions and Future Work

Bibliography

Section 4:WP 2.3: Recoverable Agents

A Fault-Tolerant Protocol for Providing the Exactly-Once Property of

Mobile Agents

Introduction

Agent Execution Model

A Simple Solution

Protocol Overview

Voting Protocol

Monitoring and Selection Protocol

Blocking Probability and Message Complexity

Optimizing the Stage Construction

Related Work

Conclusion and Future Work

Appendix

Concepts for a Reliable and Scalable Agent Server

Requirements

Architecture of the Agent System

Lifecycle of an Agent32222232323242424252526262727283030303132333642434549515255555556

ATOMAS:

ContentsMessages

Remote Method Invocation

Migration

Current State

Bibliography

Section 5:WP 2.4: Developed Concepts and Implementation

Mole 3.0: A Middleware for Java-Based Mobile Software Agents

Introduction

Mole System Overview

Lifecycle of an Agent

Agent Migration

Agent Communication and the Session Concept

Badges

Sessions

Agent Infrastructure

Resource Manager

Directory Service

Security Model

Graphical Agent Monitor

Implementational Issues

Agent Identifiers and Name Resolution

Thread Management Unit

Using Java-Enabled Web Browsers to Run Mobile Agents

Installation

System Requirements

Configuration Files

Starting a Sample Agent

Conclusions and Future Work

Section 6:WP 2.5: An Orphan Detection Protocol for Mobile Agents

Introduction4586060606064646465666768686871717272727373747576767777788181

ATOMAS:

ContentsThe Agent Model

The Shadow Protocol

The Idea

The Protocol

Mobile Shadows

Optimizing the Communication

Fault Tolerance

Related Work

Conclusion and Future Work5828282848688899091

ATOMAS:

1Introduction6

ATOMAS:

2Workplan and Project State72Workplan and Project State

In the second year, the agent system architecure developed in the rst year had to be extendedto support migration and to provide reliable agent execution. Furthermore, requirements con-cerning security issues had to be investigated and the concepts developed during the project hadto be evaluated. Therefore, four work packages had been identi ed (Section 2.1 - Section 2.4 ).In addition orphan detection for agents has been identi ed as a very important functionality tobe supported by mobile agent systems and thus an additional work package (Section 2.5) hasbeen added that concentrates on this aspect.

The following sections contain a short introduction into the work packages and the completionstate of these work packages.

2.1WP 2.1: Design and Implementation of Agent Migration

In work package 1.2, a special form of migration, called weak migration, had already been de-veloped during the rst year. This form of migration has the advantage that it can be implement-ed without changing the Java virtual machine and therefore allows to run the developed agentsystem on each architecture for which a Java virtual machine is available. Our experience in us-ing this form of migration in several student thesises proved the validity of this concept. There-fore, no further work has been invested in this topic in the second year.

2.2WP 2.2: Requirement Analysis Concerning Security

In the rst year, driven by the importance of the security aspect of mobile agent systems, wealready started this work package. Section 7 of the last years report investigates the security as-pects of Mobile Agent Systems and identi es the problem areas which has to be handled.

In Section 3 of this report, a approach to partially solve one of the most dif cult aspects of se-curity of mobile agents systems,the problem of malicious hosts, is presented. This problem con-sists in the possibility of attacks against a mobile agent by the party that maintains an agent sys-tem node, a host.

2.3WP 2.3 Recoverable Agents

An important prerequisite for the use of mobile agents in industrial environments is to providereliable and fault tolerant execution of the agents. Section 4 describes two different approachesto provide the required reliability. In the rst approach, fault-tolerant execution of agents on un-reliable systems is provided. Section 4.1 summarizes two published papers on this topic. In thesecond approach, the reliability of agents is provided by using the TUXEDO platform on Tan-dem Himalaya to build the agent system.

2.4WP 2.4 Developed Concepts and Implementation

In this work package, the developed concepts are summarized and implemented within the mo-bile agent system Mole 3.0. Next to the concepts for agent communication and agent migration

ATOMAS:

2Workplan and Project State8designed and implemeted in the previous year, version 3.0 of Mole now provides an extensiveinfrastructure for agents, including a resource manager, a directory service and a global namingscheme for agents. In order to support the design of agents, a graphical agent monitor allows tovisualize the system behaviour as a whole or of a single agent in particular. Mole further pro-vides a thread management unit to overcome some shortcomings of the Java virtual machine.Mole provides a simple means for installation and con guration of the system.

2.5Orphan Detection for Mobile Agent Systems

Orphan detection in an agent system is very important both from the user’s and from the systemside, because a running agent uses resources which are valuable to both user and system. Theuser has to pay for resources (at least in principle), and the system has only a limited amount ofthem. So if the user does not need the results of a distributed computation in progress anymore,he wants to be able to terminate the computation to minimize the resulting cost. With an orphandetection mechanism the user simply declares the agents to be terminated as orphans. Orphandetection guarantees that the now useless agents can be determined by the system and ended,thus freeing the resources they have bound. In this paper we will present a new protocol, theshadow protocol, that allows both control of mobile agents and orphan detection.

ATOMAS:

3WP 2.2: Security93WP 2.2: Security

This section summarizes a paper published in [Vig98].

3.1Abstract

In this report, an approach to partially solve one of the most dif cult aspects of security of mo-bile agents systems is presented, the problem of malicious hosts. This problem consists in thepossibility of attacks against a mobile agent by the party that maintains an agent system node,a host. The idea to solve this problem is to create a blackbox out of an original agent. A blackboxis an agent that performs the same work as the original agent, but is of a different structure. Thisdifference allows to assume a certain agent protection time interval, during which it is impossi-ble for an attacker to discover relevant data or to manipulate the execution of the agent. Afterthat time interval the agent and some associated data get invalid and the agent cannot migrateor interact anymore, which prevents the exploitation of attacks after the protection interval.

3.2Introduction

Mobile agent systems are expected to become a possible base platform for an electronic servicesframework (see e.g. [Mob96]), especially in the area of Electronic Commerce. In this applica-tion area, security is a crucial aspect since all parties involved require the con rmation that noneof the other parties will break the rules without being punished. This requirement is not alwaysful lled even in the traditional, non-electronic commerce. The anonymity of a worldwide com-munication network and the ease of automatic exploitation of security gaps in electronic appli-cations make it necessary to meet this demand in the area of commercial transactions done bycomputers.

Mobile agents are entities that consist of code, data and control information (e.g. thread states).Mobile agent systems are platforms that allow mobile agents to migrate between different nodesof the agent system. From a more technical view, mobile agents can be compared to programsthat migrate to nodes autonomously, while nodes offer the run-time environment of these pro-grams including the program interpreters.

As in Mobile Code systems (e.g. the Java applet system), one aspect of security is the protectionof the node, orhost, against possible attacks of the mobile agent. Therefore, some of the securitymechanisms developed in this eld can also be applied to mobile agent systems. An example issandbox security, i.e. the need of authorizing security-sensitive commands like the deletion ofa le by a designated component. Other security mechanisms like authentication of singleagents instances do not have a counterpart in mobile code systems and have to be designed usingstandard cryptographic techniques like encryption or digital signatures.

The reverse security issue, the protection of a mobile agent from possible attacks by a malicioushost, is new as there are barely other areas where this aspect is important. Nevertheless, the pro-tection of mobile agents from malicious hosts is — at least from the viewpoint of the owner ofthe agent — as important as the protection of the host from malicious agents. As we will see,apart from organisational solutions, no technical approaches to solve this problem without spe-

ATOMAS:

3WP 2.2: Security10

ATOMAS:

3WP 2.2: Security11

ATOMAS:

3WP 2.2: Security12sitive when it is represented in a way that the binary number of the “coin”is the money andtherefore can be used as real world cash. But there are also other classes of data, which can beused for an attack although they have not the nature of classes like e-cash. In our example, theknowledge of the maximum price or the best price so far can be used by a malicious host to offerflowers for a slightly lower amount than the competitors, although the regular price is muchlower.

3. Spying out control flow

As soon as the host knows the entire code of the agent and its data, it can determine the nextexecution step at any time. Even if we could protect the used data somehow, it is rather difficultto protect the information about the actual control flow. This is a problem, because together withthe knowledge of the code, a malicious host can deduce more information about the state of theagent. In our example, we can recognize whether an offer is better or worse than the best offerso far by simply watching the control flow, even if we could not read any data.

4. Manipulation of code

If the host is able to read the code and if it has access to the code memory, it can normally mod-ify the program of an agent. It could exploit this either by altering the code permanently, thusimplanting a virus, worm or trojan horse. It could also temporarily alter the behaviour of theagent on that particular host only. The advantage of the latter approach consists in the fact, thatthe host to which the agent migrates cannot detect a manipulation of the code since it is not mod-ified. Applied to our example, a malicious host could modify the code of the agent with the ef-fect that it prefers the offer of a certain flower provider, regardless of the price.

5. Manipulation of data

If the host knows the physical location of the data in the memory and the semantics of the singledata elements, it can modify data as well. In our example, the host could cut down the shop listafter setting the offer of the local flower provider as the best offer.

6. Manipulation of control flow

Even if the host does not have access to the data of the agent, it can conduct the behaviour ofthe agent by manipulating the control flow. In our example, the host could simply alter the flowat the second or third if statement, forcing the agent to choose the offer of the shop preferred bythe host as the best.

7. Incorrect execution of code

Without changing the code or the flow of control, a host may also alter the way it executes thecode of an agent, resulting in the same effects as above.

8. Masquerade

It is the liability of a host that sends an agent to a receiver host to ensure the identity of that re-ceiver. Still, a third party may intercept or copy an agent transfer and start the agent by maskingitself as the correct receiver host. A masquerade will probably be followed by other attacks likeread attacks.

9. Denial of execution

As the agent is executed by the host, i.e. passive, the host can simply not execute the agent. This

ATOMAS:

3WP 2.2: Security13can be used as an attack e.g. in the case that a host knows about a time limited special offer ofanother host. The host simply can prevent the detection of this offer by the agent by delaying itsexecution until the offer expires.

10. Spying out interaction with other agents

The agent may buy the flowers remotely from a shop situated on another host. If the interactionbetween agent and the remote flower shop is not protected, the host of the agent is able to watchthe buy interaction even in case the host cannot watch the execution of the agent. In our exam-ple, the host could read e.g.wallet and spend the stored money.

11. Manipulation of interaction with other agents

If the host can also manipulate the interaction of the agent it can act with the identity of the agentor mask itself as the partner of the agent. In our example the host can e.g. redirect the buyinginteraction to another shop, or it can interrupt the interaction e.g. to prevent spending the moneyby the agent.

12. Returning wrong results of system calls issued by the agent

In line 20 of the example code (“if (location.getAddress() = home)”), the agentrequests the name of the current location. Here the host could mask itself as the agent’s homelocation by returning the corresponding address. The agent then thinks that it is at home and de-livers the wallet to the host.

After stating the problem we will now have a look on possible solutions. First we will examinesome approaches that try to prevent single attacks. In the next section we will see an approachthat try to restore the autonomy of the agent, the so calledblackbox approach.

3.4Existing Approaches

As mentioned above, a malicious host is de ned as a party that is able execute an agent that be-longs to another party and that tries to attack that agent in some way. This also means that ma-licious hosts are only a problem for agents that cannot trust a host in advance. In this casetrustmeans, that the owner either knows or hopes that the operator will not attack. Therefore, someapproaches (see e.g. [FGS96]) exist that try to circumvent the problem of potentially malicioushosts by not allowing agents to move to non-trusted hosts. There are also approaches that use atrust approach to protect hosts from agents by not allowing to accept agents that have been onnon-trusted hosts before. The problem of these approaches are that trust in this context is abso-lute (you do not hide anything from a trusted node), and that it is not always clear in advancewhether a host is trusted or not. This can severely reduce the number of hosts an agent mightmigrate to. Even if an owner trusts a big company when it comes e.g. to accounting, it may notwant them to see its secret communication key. If an agent has to obtain prices for a ight, itcannot trust the host of an air line or any other host that is maintained by a company related toan air line and so forth.

Another “trust” approach is theorganizational solution: the agent system is not open in thesense that everybody can open a host, but only trustworthy parties can operate hosts. This is theapproach General Magic [GM96] used for its agent system application, e.g. PersonaLink1, thatwas operated by AT&T [Mob96].

ATOMAS:

3WP 2.2: Security14

ATOMAS:

3WP 2.2: Security15

ATOMAS:

3WP 2.2: Security16

ATOMAS:

3WP 2.2: Security17

ATOMAS:

3WP 2.2: Security18

ATOMAS:

3WP 2.2: Security19

ATOMAS:

3WP 2.2: Security20

本文来源：https://www.bwwdw.com/article/dir1.html