ATOMAS A Transaction-oriented Open Multi Agent-System. Final(10)

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].