Protecting Mobile Agents against Malicious Hosts

in an Internet-based E-commerce Environment

Xinfeng Yang   School of Information Technology,Griffith University, QLD 9726 Australia

Email:X.Yang@griffith.edu.au

Anne T-A Nguyen   School of Information Technology,Griffith University, QLD 9726 Australia

Email:A.Nguyen@griffith.edu.au

Applications of mobile agents in e-commerce environments have increasingly attracted attention from researchers and software developers. Nevertheless, there is still considerable reluctance to adopt mobile agents for such purposes. One major reason has been the security issues involved in allowing the relevant agent to visit remote hosts. This paper is primarily concerned with the risks associated with an agent being attacked by malicious hosts. Our research introduces several flexible and dynamic structures to enhance a mobile agent’s capability for self-protection. It can be demonstrated that the proposed approach is both feasible and more robust than most existing approaches to the same issue, as the latter typically involve predefined schemes to protect certain data components of the roaming agent.

Keywords: Mobile agent, agent security, Internet-based e-commerce.

To set the scene for discussion of mobile agent protection for e-commerce applications, it may be useful to consider a typical scenario for mobile agent shopping such as the one outlined in Dasgupta et al (1999) and Mandry et al (1999). They identify three consecutive phases as: itinerary preparation, offer collection and task completion.

(a) Itinerary preparation

A user creates a mobile shopping agent, equipping it with the information about products that he/she wants to buy and certain negotiation strategies and a well-defined itinerary, then dispatching it to the Internet.

(b) Offer collection

After reaching the first remote marketplace, the agent negotiates with the market operator on the best offer about certain products according to specific criteria. When this process is complete, the agent records the current offer into its memory and proceeds to its next destination to collect another offer, repeating the process.

(c) Task completion

After concluding its journey, the agent returns home with all the offers collected along the way. The agent owner accepts these offers and other related information if no doubts and suspicions can be found in the collected results.

In the above scenario, two kinds of information carried by a mobile agent are potentially vulnerable. One is the pre-defined itinerary; the other is the partial result collected en route. Without adequate protection, attacks could be instigated against the agent. For example, a dishonest host could easily prevent the agent from visiting its competitor’s platform, which is included in the original itinerary, because the agent can migrate to its next stop only with the assistance of the current working context. Also, a malicious host might delete competitive offers collected by the agent previously or even alter them illegally.

Many preventative or detection solutions have been proposed to safeguard either an agent itinerary or its partial results. Researchers are constantly distinguishing the vulnerability of a free-roaming agent and have suggested various protection schemes to address those weaknesses.

However, a mobile agent differs from an ordinary packet transfer over a network in that it is a self-contained entity. This characteristic brings both complexity and flexibility to mobile agent protection. For example, a mobile agent carries both itinerary and quote information in its memory. These two kinds of static information have certain inner relations. This can be expressed in an equation where () is the address information of the ith remote platform, () is defined as the partial results obtained by the agent at that context and then . We observed that there was an inverse relationship from an information volume viewpoint where is increasing gradually while is decreasing accordingly. Such phenomena prompted speculation as to whether our research could explore and utilise flexibility within the mobile agent characteristics and propose a dynamic solution for both an agent itinerary protection and its partial results protection.

This paper is organised as follows. Section 2 outlines related works on a mobile agent’s itinerary protection and its partial results protection. Section 3 introduces a reversible-onion protection structure and an enhanced labelled-onion approach. To improve the proposed architecture’s flexibility, an itinerary extension protocol and an inverted pyramid structure are also suggested in Section 4 and 5. Finally, a conclusion is presented in Section 6.

The protection of partial results has been a focal point in past research work. This is understandable, because a dishonest host might adopt an unfair position from their knowledge about offers provided by previous hosts. It would be even worse if a malicious host is able to modify a previous competitive offer for personal benefits. So, it is essential for a mobile agent creator to employ a reliable structure protecting partial results collected by an agent along its way. The sealed parcel structure suggested by Chess et al (1995), partial result authentication code structure suggested by Yee (1999) and encapsulated result chaining structure suggested by Karjoth et al (1998) are three successful approaches. Advantages and disadvantages of these three structures will be presented briefly as follows.

A remote host signs the partial result using its private key and attaches it to the agent like a sealed parcel. It is an earlier structure, which provides a feasible solution for a mobile agent’s partial result protection based on the digital signature technique. It is easy to compute and guarantees data confidentiality and non-repudiability of a collected offer. However, this structure could not prevent an attached parcel from being thrown away by malicious hosts afterwards.

A -bit to -bit one way function is used to generate a list of secret keys, which will be employed to authenticate an agent’s intermediate state with the help of cryptographic checksums. The used key will be destroyed before the agent migrates to its next host. The PRAC technique is faster than digital signatures to compute. It ensures partial results generated at a remote host and cannot be forged. On the other hand, it is difficult to detect and prevent colluding attacks, where two colluding hosts in an agent's journey perform illegal alteration.

A remote host digitally signs an entry with its private key and uses a secure hash function to link the results with concerned identities. More specifically, this approach tries to link the encapsulated results at each host with identities of its previous and subsequent hosts. The chain-like structure successfully prevents a host from modifying any entries in the chain without being detected. But, this method comes at a serious performance cost because of the combination use of an agent’s public key, a remote host’s private key and a secure hash function.

Agent itinerary protection has also received increasing attention recently. A well-defined itinerary is always a part of personal strategies of the agent owner. If the initial itinerary is not in a protected format, a malicious host may delete its competitor’s address and replace it with another less competitive one. It would be more harmful if a dishonest host sends the visiting agent to its accomplices, cheating the hosts in-between and getting unauthorised information. So, it is important for a mobile agent owner to protect its itinerary information from tampering. Successful solutions are a tamper-proof environment (TPE) suggested by Wilhelm and Staamann (1998), a cooperating-agents recording method suggested by Roth (1998) and an onion routing structure suggested by Westhoff et al (1999). The strong and weak points of these three solutions will be explained briefly below.

Agent behaviours will be enforced through a piece of trusted hardware called a tamper-proof environment (TPE). It provides not only a flexible platform for agents’ execution but also an operating system connecting many external facilities. A CryPO (Cryptographically Protected Objects) protocol is used to assist agents to migrate from host to host in an encrypted form. All agents residing on the environment are protected by the TPE environment exclusively from either unintentional disclosure or malicious manipulation. A disadvantage is that the TPE hardware has to be pre-installed in every agent executor’s machine, which limits the feasibility and scalability for an open system.

Two cooperating agents are employed in this scheme. When agent finishes its task and is ready to leave host , it sends a message to its partner agent over an authenticated communication channel including identities of its previous host and its next host . If the malicious host sends to a host , agent would immediately detect that event. The agent-based mutual recording method is easy to implement. Computational cost of this approach is relatively low. However, there is the disadvantage that the strategy did not take collusion attacks into consideration. There seems to be no remedial measures if one of the cooperation agents is not available. Implementation of an authenticated communication channel is another serious uncertainty.

A pre-defined itinerary is encrypted layer by layer in an onion-like structure. Only the previous and subsequent hosts’ identities are revealed at a current working context. Legal route extension is also supported. This structure provides strong data confidentiality and forward integrity protection. Technical strength of the suggested structure is convincing and easily measurable. However, this approach lacks flexibility when one of the hosts in the original itinerary is temporarily unavailable. Colluding attacks through legal route extension are also difficult to prevent.

Our literature survey revealed that most of the current work has focussed on either an agent itinerary protection or its partial result protection separately. There has been little work on exploring certain inner relations between these two kinds of information and in order to use such characteristics for mobile agent protection. Our paper proposes a reversible-onion architecture, which tries to combine an agent’s itinerary protection with its partial result protection aiming at lower development cost and stronger forward integrity and data confidentiality protection. Figure 1 depicts the reversible-onion structure.

Figure 1: The reversible-onion protection structure

As illustrated in Figure 1, a mobile agent starts its journey with a route onion, which will be peeled off layer by layer along its way. Making use of certain elements in the route onion, partial results will be sealed piece by piece and a quote onion is created accordingly. After the agent finishes its journey, the route onion is used up, and a quote onion will be taken back home. A decreasing route onion is expressed in equation (1) and an increasing quote onion is expressed in equation (2). Table 1 summarises the element notation used in both equations.

(1)

(2)

Table 1: The element notation used in equation (1) and (2)

Reversible-onion structure makes use of a mobile agent’s self-carrying and self-verification capabilities. The agent owner initializes a route onion and dispatches a mobile agent to the Internet. When the agent reaches a remote platform (), the working context decrypts the route onion using its private key and notices the agent coming from platform , and will continue its journey to platform . With the help of ’s public key, it also makes sure that the agent owner wishes to share a session key and a challenge number with it. A unique trip marker is also included for non-replaying purposes.

If the negotiation is successful, the visiting agent will notify to record its offer into its memory. Without a session key, has to encrypt its quote using both its private key and ’s public key for data confidentiality and forward integrity purposes, as suggested in Chess et al (1995) and Karjoth et al (1998). Increased computation cost is a major disadvantage of such an arrangement. Employing a session key instead of public-key cryptosystem provides a sound solution because session key cryptography is typically 100 to 1000 times faster than an asymmetric-key approach (Microsoft 2000). However, it is difficult for an agent’s home platform sharing a set of session keys with all the visited hosts en route. Thanks to the reversible onion architecture, a remote host gets its session key from the route onion safely and with the least effort. It encrypts its offer and the challenge number as well as the trip marker with its session key , forming a quote onion and sends the agent to its next stop.

Before dispatching the agent to its subsequent platform, explicitly removes its layer from the route onion including its session key and corresponding challenge number. The next platform gets a remaining route onion and a growing quote onion, but without any knowledge about the previous session key and previous offer. The same process will be carried out at all visited platforms. When the agent’s journey comes to an end, it uses up the itinerary onion and returns home with a complete quote onion. The agent owner decrypts the quote onion layer by layer with a set of shared session keys and gets all the offers from platform to . Challenge numbers and the trip marker within each piece of the quote onion guarantees that the information is up-to-date.

To demonstrate the feasibility and effectiveness of our proposed reversible-onion structure, two aspects need to be considered. One is potential threats; the other is security requirements. A protection solution works well if it meets all security requirements against all possible misbehaviours.

When a roaming agent visits a dishonest host, at least four kinds of attacks are predictable: inserting, deleting, modifying and colluding. These sorts of attacks are described below:

1. Inserting attack: A malicious host may insert some worthless platforms into the agent’s initial itinerary or insert irresponsible offers into the agent’s memory. Such attack may not be harmful, but are definitely annoying.
2. Deleting attack: A malicious host may intentionally delete its competitor’s address from the agent’s remaining itinerary, or delete competitive offers provided by its previous hosts. It is obviously a harmful attack.
3. Modifying attack: A malicious host may replace its competitor’s address with a less competitive one, or alter any existing offers for an illegal purpose. It is even worse than a deleting attack because all offers collected by the agent then become unreliable.
4. Colluding attack: Two or more dishonest hosts, acting in collusion, launch the attack. They may work together tampering with the agent’s itinerary information or collected offers and finally putting the blame onto other honest hosts en route.

In the face of all these possible attacks, it is necessary to identify a set of security requirements as a measurement to test the effectiveness of a proposed protection solution. Generally speaking, most of the security requirements come from conventional networked system. Within the mobile agent framework, five fundamental security requirements have been well recognised in Farmer et al (1996) and Jansen and Karygiannis (1999). They are confidentiality, integrity, availability, accountability and anonymity. In this paper, focus is mobile agent protection, not agent system protection, so we slightly modify the conventional security properties and pinpoint four basic requirements: data confidentiality, forward integrity, event non-reputability and non-neighbours anonymity.

1. Data confidentiality: Only the expected recipient host could extract its session key and the corresponding challenge number. Only the agent owner could open the original offers provided by all visited hosts.
2. Forward integrity: It would not be possible to tamper with the remaining contents in the original itinerary. None of the offers generated by previous hosts can be altered by any of the hosts.
3. Event non-reputability: An offer created by a specific host cannot be repudiated. Misbehaviours of any dishonest host can be identified correctly.
4. Non-neighbours anonymity: None of the identities in the original itinerary need to be disclosed to any other platforms unless for communication purposes.

The performance of our proposed reversible-onion structure is examined in the light of security requirements outlined above.

1. Data confidentiality: If the public-key cryptosystem is proven to be secure, no one other than could peel off its own layer in the original route onion and get its session key. When the agent returns home, only its owner could decrypt each layer from the quote onion and get the offer created by . A random number circumvents any attack to try and recognise the cipher text generated from the same plain text.
2. Forward integrity: It is relatively difficult to prevent a dishonest platform from mishandling a visiting agent from a forward-integrity point of view. Fortunately, a well-designed structure should detect this event and effectively identify the troublemaker.

1. Suppose a dishonest host inserts another platform after itself without the agent owner’s permission, such misbehaviour would be detected when the agent moves to because the identity of the added platform is not included in the original itinerary. Besides, without a shared session key, the added platform could not insert its offer into the quote onion properly. If the agent was rejected and sent back by to its home, the agent owner ensures that is the offender. A legal itinerary extension is allowed, but could only be performed through an itinerary extension protocol, which will be discussed subsequently.
2. Suppose a dishonest host deletes part of the contents from the original itinerary, such an action could be detected by its subsequent platform immediately because it cannot decrypt the remaining onion with its private key as expected. However, if it deletes part of the offers from the growing quote onion before creating its own layer, this misbehaviour could not be detected by the next platform because only receives a string of ciphered text. Fortunately, the agent owner could detect this event when the agent returns home because the quote onion layer generated by could not be decrypted with their shared session key.
3. A dishonest host may want to replace its competitor’s address with another one, but it has no way to know its competitor’s correct location in the initial route onion. Even if its competitor happens to be , the malicious host can only send the agent to an arbitrary host, because it does not know ’s address. Therefore, the attack becomes invalid. The quote onion is intact when receives it, and any alternation or replacement cannot be performed without detection from the agent owner. This arrangement overcomes one of the limitations of chain-like quote protection structure (Karjoth et al 1998), where a current working platform has to know all the identities of its previous platforms in order to ensure offers’ forward integrity along the journey, which may not be feasible because of a non-neighbours anonymity requirement.
4. An attack where two malicious hosts act in collusion is deemed to be more harmful than an attack triggered by a single dishonest host. The route-onion structure guarantees that a working context can only reveal the identities of its previous and subsequent hosts. Therefore, two adjacent malicious hosts are not able to do more illegal actions to the route onion than a single host.

Deleting and modifying attacks are also invalid when using the quote onion structure. This is because the offers are sealed layer by layer, so cannot be broken, providing the session-key cryptography technique is secure.

An inserting attack from colluding hosts may have harmful consequences. For instance, a malicious host might send the agent to its accomplice instead of to . The accomplice then inserts its own offer into the quote onion and sends the agent back to which in turn resends the agent to . The host cannot detect what has happened. Consequently, when the agent returns home, host will be identified as the culprit, because the quote onion fails to open in ’s layer. Technically, the chain-like protection structure does not provide a satisfactory solution against these types of attacks (Karjoth et al 1998). Hypothetically, if and are in a colluding group, host sends the agent back to , and maliciously replaces ’s offer. When the agent owner checks the offer chain, the chaining relation appears stable, but ’s offer cannot be opened, thus becomes a culprit. This drawback can be addressed by an enhanced labelled-onion structure.

3. Event non-reputability: An encapsulated offer layer in the quote onion created by platform would not be repudiated because no one other than could get its session key and one-time challenge number from the outmost layer of the route onion.
4. Non-neighbours anonymity: A working context only knows the identities of its previous and subsequent neighbours for communication purposes. All other identities either have been erased or are still sealed in the layered structure. Regarding the quote onion, the offer layer was encrypted with a secret session key other than the private signature of a visited host, so dictionary attacks would also be effectively prevented.

In summary, the proposed reversible-onion structure satisfies the security requirements of data confidentiality, event non-reputability and non-neighbours anonymity. Forward integrity protection against inserting, deleting or modifying attacks is another issue. If a single dishonest host launches the attack, then this misbehaviour can be detected and the host can be identified either by its subsequent platform or by the agent creator. However, the agent owner may not be able to correctly identify the culprit when colluding hosts perform the attack. An enhanced labelled onion structure may improve a recipient platform's ability to detect such events before the agent is processed.

In a hypothetical situation, two dishonest hosts and belong to a colluding group. The host mishandles the quote onion and sends the agent to in the name of . The host then receives the quote onion in its entirety and has no way to check its integrity before continuing to process it. If host simply creates its own layer and assists the agent to continue its journey, will eventually be identified as a culprit, because the agent owner will not be able to decrypt the offer layer generated by . In order to overcome this shortcoming, a labelled-onion structure is proposed to assist a recipient host to check the integrity of a quote onion arriving from its direct sender. A more detailed description ensues.

An inside and outside label must be worked out prior to host sending the agent to a subsequent host . The inside label will be embedded into the quote onion, and checked by the agent owner after the agent returns home. The outside label will be sent together with the agent and examined by its successor for forward integrity verification purposes. The inside and outside labels and a labelled quote onion are expressed in equation (3).

Inside Label: ()

Outside Label: ()

(3)

This structure starts from the first visited platform , which is required to create an outside label only. It generates its offer layer and calculates a hash value out of this layer. This hash value, relative identities and the trip marker will be encrypted with ’s private key and form an outside label, which will then be sent to the platform with the agent. Upon receiving the mobile agent, checks this label first. It opens the label and recalculates the hash value. An unmatched hash value indicates that an error occurred during transmission or possibly from a colluding attack. The host would then reject the coming agent. Otherwise, includes this hash value as an inside label into its own layer for the quote onion, removes the old outside label, and creates a new one as did, then sends the agent with this new outside label to its subsequent platform .

It is possible for host to illegally insert, delete or modify the quote onion, and send the agent to the platform in the name of its accomplice . However, it could not change the hash value which is protected by ’s signature. If assists to create the outside label, it has to leave a non-repudiate record in both the inside and outside labels. The agent owner could easily identify the wrongdoer later, so potential colluding attacks would then become invalid.

Itinerary extension ability is regarded as one of the important advantages for an onion-like structure (Westhoff et al 1999). A visited platform is able to easily extend a route through introducing another itinerary onion by itself. This extension could be nested further, which makes the structure very flexible. However, it creates some difficulties for the agent owner as well.

The agent owner could consider platforms extended by a visited platform to be untrustworthy. So, the task of tracing and identifying malicious hosts becomes more complicated if an extended itinerary is overlapped several times or completely out of control. In order to keep the extensible property for our proposed reversible-onion structure, we need to consider how to establish mutual trust between the agent owner and the extended platforms. One way to achieve this is to share a secret session key.

For the initial itinerary in the reversible-onion structure, a shared session key has been included in each layer. For those extended platform en route, such keys are not likely to be prepared in advance, so a key distribution scheme needs to be introduced in an on-demand fashion. We suggest a Mobile Agent iTinerary Extension (MATE) protocol as depicted in Figure 2.

Figure 2: A Mobile Agent ITinerary Extension (MATE) Protocol

There are three entities involved in the MATE protocol: a home platform , a visited platform and an extended platform as illustrated below. The notation for the additional elements in this protocol is summarised in Table 2.

Table 2: The element notation used in the MATE protocol

The MATE protocol starts from a visited platform , which requires the route to be extended. It creates an inner encrypted message for the agent owner and generates a challenge number for the extended platform and includes the trip marker and related identities, sending it to . When receives this message, it knows is the agent owner and requests the itinerary extension. Then, it generates another random number used for challenging and constructs a similar inner encrypted message, and re-sends to the agent owner.

When the platform checks this message from , it notices one of the inner messages is encrypted with the session key and containing the random number , so believes the extension request from is valid. It may still reject the extension by sending a rejection message to . Otherwise, it selects a new session key, encrypts a new message including the challenge number with the same format as that in the initial route onion and sends it back to . At the same time, an approval of extension message will be sent in reply to .

The platform receives the session key from ’s reply and utilises it when creating its own offer layer for the quote onion. After finishing its task, sends the agent back to with its outside label (step 4). This time, the challenge number will be included in the label as a unique identifier. The MATE protocol is then complete.

The route extension could be nested further to in the same manner. The quote onion is changed and more pieces are added accordingly, which could be illustrated in equation (4). The notation for additional elements in the equation is summarised in Table 3.

(4)

Table 3: The element notation used in equation (4)

The agent owner shared a secret key with an extended platform in a one-to-one authentication manner. However, from a performance viewpoint, this approach results in a higher computation cost because of the employment of both a public key () and a private key (). In fact, only ’s private key is needed for its outside label, so better performance with lower computation cost could be achieved if the agent owner shares a session key with an extended platform without using a public-key cryptosystem. Such an arrangement is also desired when each other’s public key is temporarily unavailable.

Enlightened by the Otway-Rees protocol (Otway & Rees 1987), which proposed a mutual-authentication method with the help of a key distribution centre (KDC), we propose a MATE with KDC protocol for high performance. The proposed protocol is depicted in Figure 3.

Figure 3: A Mobile Agent iTinerary Extension (MATE) with KDC Protocol

Four entities are involved in this protocol: a home platform, a visited platform , which wants to extend the original itinerary, an extended platform and a key distribution centre. The proposed MATE with KDC protocol is illustrated below. Additional elements notation in this protocol is summarised in Table 4.

Table 4: The element notation used in MATE with KDC protocol

The MATE with KDC protocol starts from a visited platform . The first message is sent to and contains a pair of random numbers, used to challenge and used to challenge , and an encrypted inner message used for the agent owner to check its identity. When receives this message, it generates another pair of random numbers, used to challenge and used to challenge the KDC. It then constructs a new message containing two challenge numbers and , and two inner encrypted messages, one for the KDC, one for the agent owner . A secret key is shared between the platform and the KDC only.

Once the message is received from , the platform verifies the challenge number and the inner challenge number to ensure that the extension request from is valid. An Internet intruder has no way of breaking the encrypted part generated by and any alteration will result in a mismatch of the two challenge numbers. If the extension is approved, the agent owner will construct an analogous one of its own containing the challenge number and a new random number , and sends this message to the KDC. Subsequently, another approval message will be sent back to.

The KDC checks to see if the in both parts is the same. Because only the KDC knows the shared secret keys and , if an Internet intruder tampers with or replaces the encrypted part in the previous message, this misbehaviour will be detected immediately. The KDC then selects a session key and encrypts it twice, once for and once for . The receiver’s challenge number will be included in each message.

Platforms and will recognise their individual challenge number in their reply from the KDC and so will believe that it is from the KDC, not an Internet intruder, and that the session key is valid. Platform then uses this session key creating its own offer layer for the quote onion and sends the agent back to with a new outside label after everything is complete (step 6). The challenge number will be embedded in the label at this stage as a unique identifier. The MATE with KDC protocol process is then complete.

As discussed previously, labelled reversible-onion architecture satisfies a travelling agent’s security requirements such as data confidentiality, forward integrity, event non-reputability and non-neighbours anonymity because it is naturally not breakable. However, it has an obvious weakness when one of the remote platforms is temporarily not available. A working context has to send the travelling agent back to its owner after trying for a certain number of times.

This may become a serious problem if an agent travels in an open network where some hosts are often not reachable. It affects the route onion more than the quote onion because no one other than the next platform is able to reveal the remaining itinerary. Such phenomenon pressed us to redesign the itinerary protection structure, which could separate the protected itinerary at each visited platform, while maintaining all its protection advantages.

In this part, we attempted to overcome such limitations by introducing a Multi-layered Inverted-Pyramid (MIP) structure with a Via Trust Third Party (VTTP) protocol for an agent’s itinerary protection that is presented in equation (5). The labelled quote onion structure will remain unchanged.

(5)

The agent owner generates a multi-layered itinerary using its private key and a visited platform’s public key. Each layer contains the identities of a visited platform’s previous and subsequent hosts. Challenge number and session key are included and will be used for a visited platform creating its own layer for the quote onion.

To ensure forward integrity for the itinerary, the agent owner calculates a group of hash values for each layer in advance. Each visited platform will get a set of hash values for all its following layers. For example, the first platform will get hash values if there are visited platforms in total and the ith platform will get hash values and the last platform gets no hash value at all. So, the length of each encapsulated layer is shorter and shorter, shaping the proposed structure like an inverted pyramid from its top to the bottom.

Each visited platform is allowed to open the top layer of the structure when it receives a coming agent and erases this layer before sending the agent to its next stop. If one of the platforms en route is temporarily unreachable, a VTTP protocol will be employed with the help of a trust third party, which is depicted in Figure 4. Additional elements notation in VTTP protocol is summarised in Table 5.

Figure 4: Via Trust Third Party (VTTP) Protocol

Table 5: The element notation used in Via Trust Third Party (VTTP) Protocol

The VTTP protocol starts from a visited platform , which discovered its subsequent platform was not available. It encrypts the challenge number and related identities with its session key and sends a message to the agent owner . At the same time, it sends the travelling agent with another encrypted message containing the same information to the trust third party using its private key.

When the platform gets this message, it notices the random number is included and encrypted by the session key , and it believes the skipping request from is valid. If agrees with such request, it will send an approval message containing the identity of with its challenge number , identity of with its challenge number and identity of with its challenge number .

Firstly, the trust third party checks to see whether the challenge number in both messages is the same. Because only and share this number, an Internet intruder has no way of accessing it. After ensuring agreement on both sides, it sends the agent and a message to containing the challenge number with the identity of . If the platform is reachable, it opens the message, and believes such replacement is authorised by the agent owner because the challenge number in ’s message is the same as that in the original route layer. If the platform is really not available, the trust third party will delete ’s layer from the MIP structure, and send the agent with a message in the same format to the following platform . This time will perform the same verification described above and process the agent accordingly. The VTTP protocol is then completed.

Due to the combined use of the agent owner’s private key and a visited platform’s public key, three of four basic security requirements, data confidentiality, event non-reputability and non-neighbours anonymity will not be affected for the proposed MIP architecture. So, our security analysis will focus on its forward integrity protection against possible inserting, deleting, modifying and colluding attacks, to observe if any misbehavior could be detected and the culprit could be identified correctly. We present the following hypotheses regarding forward integrity protection:

1. A dishonest platform inserts another platform into the initial itinerary:
   Such misbehavior will be detected by its subsequent platform immediately because a corresponding hash value is not included in the original route layer, which is protected by the agent owner’s signature. If simply inserts a platform behind it, the next platform will notice the identity of its previous platform unmatched. In addition, the illegally added platform has no way to create an outside label based on the current quote onion without revealing its real identity. So, inserting attack is proved to be invalid.
2. A dishonest host deletes certain layers from the original route structure:
   This occurrence will be detected by its subsequent platform too because it could not delete corresponding hash value records from all those layers above. For the same reason, if deletes its subsequent platform from the MIP structure, the following platform will notice the identity of its previous platform is different from the one that was encrypted in the original route. Besides, cannot forge an outside label for the quote onion without ’s private key. The itinerary protection and quote protection demonstrate a mutual-verification property here.
3. A dishonest host wants to replace its competitor’s layer with another one:
   Host has no way of knowing its competitor’s correct location in the original architecture. Any replacement will cause a mismatch of the corresponding hash value being detected by platform . If tries to replace ’s layer, it does not have the agent owner’s private key and cannot forge the encrypted part and containing relevant identities with the correct format. The agent carrying any mis-formatted information will be rejected by the receiving platform and sent back to its owner.
4. A dishonest host tries tampering with the agent with an accomplice host:
   In an onion-like architecture, it is difficult for a dishonest host to discover its accomplice on the remaining onion, because the route onion is unbreakable. However, for the MIP structure, every layer is separate. Dictionary attacks may happen. A malicious host could broadcast copies of the remaining route to its accomplice , which could then try to decrypt each layer. If host obtains a reasonable result, that means it is a member of the initial route. Thus, they could work in collusion. Inserting attack seems invalid because they could not inject corresponding hash values into any layer, which is protected by the agent owner’s signature. But they could simply delete all layers in between from to without being detected by any other platforms en route. Fortunately, they can never get correct session keys and challenge numbers, thus could not forge their offers. Host would be identified as a culprit when the agent returns home and the agent owner will discover the quote onion in layer cannot be opened as expected. If intends to replace any layers in between, either its own identity or ’s identity has to be disclosed to the added members, and be included in the inner label of the quote onion. Again, without a shared session key, the agent owner cannot open the quote onion from ’s layer, because has to take this responsibility.

In general, the proposed MIP architecture also meets all security requirements for a travelling agent and allows flexibility while one of the platforms en route is temporarily not reachable. Potential attacks can be detected, without implicating honest platforms.

Although colluding attacks performed by two malicious contexts is proved to be invalid for the MIP architecture, they are still an annoying threat. To avoid these occurrences, it is necessary to encrypt each layer in the MIP structure further. An improved Trust Third Party Checkpoint (TTPC) structure may enhance its forward integrity and non-neighbours anonymity protection. The proposed TTPC architecture is depicted below, and a modified route protection structure is expressed in equation (6).

Figure 5: Trust Third Party Checkpoint Protection Structure

(6)

The agent owner initialises an original itinerary and sends the agent to a trust third party first. When the trust party receives the agent, it opens the top layer of the itinerary and gets the trip marker and its session key . With this session key, it decrypts the second layer of the structure and identifies the first platform that the agent wants to visit. Then it deletes all irrelevant contents from this layer and sends the agent with the remaining structure to .

When accesses the agent, it decrypts the top layer with its private key, and believes that the agent owner is and the agent is coming from a trust third party. At the same layer, it gets its challenge number and its session key . After providing its own offer and constructing a labelled quote onion, it deletes this layer and sends the agent back to .

After receiving the agent, the trust third party would help to check the quote onion and the outside label provided by the platform and ensuring its integrity. If nothing suspicious, decrypts the third layer of the itinerary and gets the identity of the second platform where the agent wishes to travel. It then deletes irrelevant information from this layer and sends the agent with the remaining contents to . The same process will go on and on until the itinerary concludes. The trust party sends the agent back to its owner.

With the help of the trust third party, the agent’s multi-hop travel is changed to a set of one-hop travel. All potential attacks performed by either a single dishonest host or two colluding hosts are diminished. Even the identities of a visited platform’s neighbours do not need to be revealed. Unfortunately, slow performance is a penalty for this arrangement, especially when the original itinerary is already very long, this would seriously limit the benefits of mobile agent technology.

Admittedly, protection strength and performance degradation are two common conflicting factors. It seems that a much more difficult problem for mobile agent protection is not simply designing a very complex security mechanism, but considering agents' security requirements and their computational performance in an all-round way. To make mobile agent-mediated e-commerce applications more feasible and attractive, an optimised protection scheme in the future might be established on different agent versus system trust levels and different security versus performance tradeoffs.

Protection of mobile agents against malicious hosts has been recognised as an essential task before they could be employed for network-oriented applications. The majority of existing research has focussed on an agent’s itinerary protection or its collected data protection.

In this paper, we introduce several flexible structures to enhance a mobile agent’s capability for self-protection. A labelled reversible-onion architecture is proposed for improved agent protection and computational performance. To achieve flexibility, an itinerary extension protocol and a multi-layered inverted pyramid structure are also outlined. All proposed architectures and protocols have been analysed according to a modified set of security requirements against possible attacks, demonstrating their feasibility and effectiveness in mobile agent-mediated e-commerce applications.

Chess, D., Grosof, B., Harrison, C., Levine, D., Parris, C. and Tsudik, G. (1995). "Itinerant Agents for Mobile Computing", IEEE Personal Communications, Vol. 2, No.5, pp.34-49.

Dasgupta, P., Narasimhan, N., Moser, L.E. and Melliar-Smith, P.M. (1999). "MAgNET: Mobile Agents for Electronic Trading", IEEE Transactions on Knowledge and Data Engineering, Special issue on Web Technologies, Vol. 11, No. 4, pp.509-525.

Farmer, W. M., Guttman, J. D. and Swarup, V. (1996). "Security for Mobile Agents: Issues and Requirements", Proceedings of the 19^th National Information Systems Security Conference, Baltimore, USA, pp. 591-597.

Jansen, W. and Karygiannis, T. (1999). "Mobile Agent Security", National Institute of Standards and Technology Special Publication 800-19, National Institute of Standards and Technology, USA. Available Online: [HREF1] [2002 Sep. 22].

Karjoth, G., Asokan, N. and Gulcu, C. (1998). "Protecting the Computation Results of Free-Roaming Agents", Proceedings of the 2^nd International Workshop on Mobile Agents, (MA’98), Stuttgart, Germany, pp. 195-207.

Mandry, T., Pernul, G. and Rohm, W. A. (1999). "Mobile Agents on Electronic Markets Opportunities, Risks and Agent Protection", Proceedings of the 12^th International Bled Electronic Commerce Conference, Bled, Slovenia, pp.1-13.

Microsoft (2000). "Planning Your Public Key Infrastructure", in Microsoft® Windows® 2000 Server Resource Kit Deployment Planning Guide, Microsoft Corporation. Available Online: [HREF2][2002 Oct. 23].

Otway, D. and Rees, O. (1987). "Efficient and Timely Mutual Authentication", ACM Operating Systems Review, Vol. 21, No. 1, pp.8-10.1

Roth, V. (1998). "Secure Recording of Itineraries through Cooperating Agents", Proceedings of the European Conference on Object-Oriented Programming (ECOOP) Workshop on Distributed Object Security and the 4^th Workshop on Mobile Object Systems: Secure Internet Mobile Computations, Brussels, Belgium, pp. 147-154.

Schneier, B. (1996). Applied Cryptography: Protocols, Algorithms and Source Code in C, second edn, John Wiley and Sons, Inc., New York, pp. 151-172.

Westhoff, D., Schneider, M., Unger, C. and Kaderali, F. (1999). "Protecting a Mobile Agent’s Route Against Collusions", Proceedings of the 6^th Annual International Workshop on Selected Areas of Cryptography (SAC '99), Kingston, Canada, pp. 215-225.

Wilhelm, U. G. and Staamann, S. (1998). "Protecting the Itinerary of Mobile Agents", Proceedings of the European Conference on Object-Oriented Programming (ECOOP) Workshop on Distributed Object Security and the 4^th Workshop on Mobile Object Systems: Secure Internet Mobile Computations, Brussels, Belgium, p.135-145.

Yee, B. S. (1999). "A Sanctuary for Mobile Agents", in Secure Internet Programming: Security Issues for Distributed and Mobile Objects, Lecture Notes in Computer Science 1603, eds J. Vitek & C. Jensen, Springer-Verlag, New York, pp. 261-273.

HREF1

http://csrc.nist.gov/mobileagents/publication/sp800-19.pdf

HREF2

http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/Deploy/dgch_pki_odbg.htm

Copyright