WO2009141471A1

WO2009141471A1 - Method for protecting computing platforms against repeated external attacks from mobile agents and protected computing platform system

Info

Publication number: WO2009141471A1
Application number: PCT/ES2009/000270
Authority: WO
Inventors: Carlos Garrigues Olivella; Sergi ROBLES MARTÍNEZ; Joan Borrel Vlader
Original assignee: Universidad Autonoma De Barcelona
Priority date: 2008-05-19
Filing date: 2009-05-19
Publication date: 2009-11-26
Also published as: ES2327310B1; ES2327310A1

Abstract

The invention relates to a method for protecting computing platforms against repeated external attacks from mobile agents identified using path markers or agent identifiers. In particular, the invention relates to a method consisting of using authorisation entities in order to generate new path markers that enable the mobile agent to migrate and be executed legally on the same platform a dynamically determined number of times during the execution time. The invention also relates to a system of protected computing platforms that are protected against repeated external attacks from mobile agents, which system is designed to implement the aforementioned method.

Description

Method for the protection of computer platforms against external attacks of repetition of mobile agents and system of protected computer platforms

Technical sector

The present invention concerns, in a first aspect, a method for the protection of computing platforms against external repetitive attacks of mobile agents identified by path markers or agent identifiers, and in particular a method comprising using entities of authorization to generate new path markers that allow the mobile agent to migrate and be legally re-executed on the same platform a number of times dynamically determined at runtime.

A second aspect of the invention concerns a system of computer platforms protected against external attacks of repetition of mobile agents, and adapted to apply the proposed method.

State of the prior art

Mobile agents can provide multiple benefits in the development of distributed applications, but their use also poses security threats. Different investigations in the field of mobile agent technology have identified and solved some of the security-related issues that one of these threats posed, but there are still many that remain unsolved, as indicated in the article by J. Zachary "Protecting Mobile Code in the WiId" Internet Computing, IEEE, vol. 7. No. 2, p. 78-82, 2003.

Most of the research work carried out regarding the security of mobile agents is focused on the problem presented by malicious platforms, since the platforms have complete control over the execution of the agent, and can therefore do almost anything with the agent code or data. Therefore, it is considered that achieving a complete solution is an impossible task. However, several problems can be mitigated. For example, although in spite of the fact that platforms cannot be prevented from manipulating the results generated by the current execution of the agent in them, it can be avoided that the platforms manipulate the results generated by the agent in other platforms in an unauthorized manner.

The majority of solutions proposed in the protection of mobile agents against malicious platforms try to provide a generic solution that cover as many security threats as possible, in general without putting the solution into practice in any real application. On the other hand, most real agent-based applications do not take security into account. This is probably the reason why some proposals in security of mobile agents have failed to consider some specific scenarios where their solutions may not be valid. More specifically, the solutions presented for some agent repetition attacks have failed to consider scenarios where the agent has to go through a loop that contains a certain number of platforms an indeterminate number of times (see YY Tsipenyuk document, "Detecting External Agent Replay and State Modification Attacks, "Master's thesis. University of California, 2004).

Agent repetition attacks can be classified into two different categories (see B. Yee's article. "Monotonicity and partial results protection for mobile agents," in "Proceedings of the 23rd Int. Conf. On Distributed Computing Systems. IEEE Computer Society ", 2003, pp. 582-591):

• Internal repetition attacks: These occur when the agent is executed inside a single platform using different inputs, in order to obtain different responses and draw conclusions about his behavior.

• External repeat attacks: These are executed by malicious platforms by forwarding the agent to another platform, thus causing the agent to re-execute part of his itinerary.

. Internal repetition attacks are impossible to avoid because the platform has full control over the execution, and can always reset the agent to its arrival state. External attacks, on the contrary, can be avoided if the platforms keep a record of previously executed agents.

The problem with current solutions against external repetition attacks (which will be described later) is that they do not allow an agent to be executed n times on the same platform, especially if n is determined at runtime. However, the agent's itinerary often contains round trips that require the same platform to be visited several times. Thus, current solutions force programmers to sacrifice part of the flexibility inherent in the itineraries of mobile agents.

Repeat attacks have traditionally been considered as a form of network attacks (see article by J. Zachary "Protecting Mobile Code in the WiId" Internet Computing, IEEE, vol. 7. No. 2, pp. 78-82, 2003 ). These are based on the capture of some of the messages exchanged between two entities and their forwarding later. These attacks are generally carried out during authorization processes or the execution of key exchange protocols, in order to carry out, for example, phishing attacks.

The traditional mechanisms used to prevent repetition attacks are based on the use of "nonces" (numbers used only once), time stamps, session tokens or any other kind of information that allows entities to link their messages to the execution of the current protocol (T. Aura, "Strategies against Replay Attacks" in Proceedings of the Computer Security Foundations Workshop. IEEE Computer Society, 1997, pp. 59-68).

For example, an HTTP exchange between a web browser and a server can include a session tab that identifies only the current interaction session. The file is generally sent as an "cookie" http, and is calculated by applying a "hash" function to the session data, user preferences, etc.

Mobile agent systems are also exposed to traditional repeat attacks. Any communication between two agents, or two platforms, or an agent and a platform is exposed to this kind of attacks. To combat this kind of attacks, traditional mechanisms such as those mentioned previously (based on "nonces" or session cards) can be used.

Patent document EP1879323 proposes a method to protect the data and itinerary of a mobile agent sent from a first server through a network to which a plurality of servers are connected. It is proposed that the data and itinerary provided for each of the servers to which the mobile agent must visit following its scheduled itinerary, are encrypted together in a nested structure, with a number of elements equal to the number of servers to visit, of so that each of these servers can only access, by means of the corresponding decryption, the data provided for it and a section of the itinerary, respectively. This document proposes, in order to avoid traditional repetition attacks, the use of "nonces", digital signatures, public and private keys, wrapping functions, such as "hash" functions, etc.

Mobile agent systems are also exposed, in addition to traditional repeat attacks, to agent repeat attacks. Agent repetition attacks are not based on repeating a message sent by the network, but on re-executing an agent that had previously been executed on a platform. In addition, these attacks are not carried out by external attackers, but by the agent platforms that are part of the agent's itinerary. As it has been In the above, agent repetition attacks can be divided into two classes: internal repetition attacks and external repetition attacks.

Internal repetition attacks occur when a dishonest platform repeatedly executes an agent by applying the same or different inputs each time. A platform can execute an agent multiple times in order to understand its behavior, or until the desired output is obtained. This kind of attacks is also known as "blackbox testing" (F. Hohl, "Time Limited Blackbox Security: Protecting Mobile Agents From Malicious Hosts," in Mobile Agents and Security, ser. Lecture Notes in Computer Science. Springer Verlag, 1998, vol. 1419, p. 92), and is generally carried out when the agent code has been protected using some obfuscation technique.

These kinds of attacks are carried out inside a single platform, and cannot be observed externally by any other entity. Even if the agent tried to register all his actions in an external monitoring service, the execution environment could still interfere with these external communications, and direct the messages towards an incorrect receiver, or alter the contents of the messages, etc. In addition, the agent's attempts to store his status information in a secure external entity could easily be avoided by malicious platforms by altering the agent's execution. In practice, internal repetition attacks are impossible to prevent or detect (B. Yee. "Monotonicity and partía! Results protection for mobile agents," in "Proceedings of the 23rd Int. Conf. On Distributed Computing Systems. IEEE Computer Society ", 2003, pp. 582-591).

External repeat attacks occur when a dishonest platform migrates an agent to a remote platform, without this migration being defined in the agent's itinerary. This kind of attack is especially difficult to combat, since it is difficult to distinguish between a legal migration of the agent to his next destination and a repeated migration that the agent did not intend to carry out. For example, assuming that the agent's itinerary includes a migration from a platform A to a B, then platform A is authorized to send agents to platform B, and the agent is also authorized to be executed on platform B. As a result , no authentication mechanism can be used to prevent platform A from maliciously forwarding the agent to platform B multiple times.

In order to provide a solution to this problem, Yee ("Monotonicity and partial results protection for mobile agents" in "Proceedings of the 23rd Int. Conf. On Distributed Computing Systems. IEEE Computer Society", 2003, pp. 582-591 ) suggests considering a repeat attack as an illegal state transition. Every platform within the itinerary implements an algorithm for detecting inconsistencies in state transitions (STID), which is able to determine when a migration from one platform to another is an illegal transition. The problem with this approach is that platforms must be aware of the legal status transitions of each agent executed. In addition, legal status transitions can be mistakenly identified if the agent is executing a loop in which the same platform is repeatedly accessed.

Other works concerning the protection of mobile agents against malicious platforms suggest the use of path markers to prevent repetition attacks. Some of such works are those set out in the following documents:

- "Methods for Protecting a Mobile Agent's Route," in "Proceedings of the 2nd Int. Information Security Workshop (ISW '99), ser. Lecture Notes in Computer Science", vol. 1729. Springer-Verlag, 1999, p. 57-71, by the authors D. Wcsthoff, M. Schneider, C. Unger, and F. Kaderali;

- "On the problem of trust in mobile agent systems," in "Proceedings of the Symposium on Network and Distributed System Security". Internet Society 1998, by U. G. Wilhelm, S. Staamann, and L. Buttyan;

- "A Secure Route Structure for Information Gathering Agent" in "Proceedings of the 3rd Pacific Rim Int. Workshop on Multi-Agents: Design and Applications of Intelligent Agents, ser. Lecture Notes in Artificial Intelligence", vol. 1881. Springer-Verlag, 2000, pp. 101-114, by T. Li, C. Y. Seng and K. Y. Lam;

- "Mobile Agent Protection With Data Encapsulation And Execution Tracing," Ph. D. dissertation. The Florida State University. 2003, by A. Suen;

- "Protecting Mobile Agent Itineraries," in "Mobile Agents for Telecommunication Applications (MATA), ser. Lecture Notes in Computer Science", vol. 2881. Springer Verlag, 2003, pp. 275-285, by J. Mir and J. Borrell; Y

- "A Novel Solution of Mobile Agent Security: Task-Description-Based Mobile Agent," "IJCSNS International Journal of Computer Science and Network Security", vol. 6, no. 2B, pp. 121-125, 2006, by the authors H. Che, D. Li, J. Sun. and H. Yu.

A path marker is an identifier of the agent that must be stored by the platforms, so that they can detect and prevent future re-execution attempts of the same agent. Again, the problem with these solutions is that they do not take into account the case where the agent's itinerary includes one or more platforms that must be visited more than once. As a result, a legal re-execution of the agent on the same platform can be misunderstood as a repeat attack. These aspects were identified in the article "Protecting Mobile Agent Loops," in "Mobility Aware Technologies and Applications, ser. Lecture Notes in Computer Science", vol. 3744. Springer-Verlag, 2005, p. 74-83, by J. Cucurull, J. Ametller, JA Ortega-Ruiz, S. Robles, and J. Borrell, who proposed a solution based on the inclusion of counters within the agent's path marker. A different counter is assigned to each platform, which indicates the maximum number of times an agent can be executed on a platform. The platforms keep track of which agents have been executed, and the number of times they have been. Before starting the execution of an agent, the platforms verify that the number of times that the agent has been previously executed does not exceed the number of allowed executions recorded in the agent's path marker.

The problem with this proposal, however, is that the number of times a given platform can be visited must be known in advance, when the agent's itinerary is created, so that this information can be entered into the path marker of the agent. Consequently, this proposal does not allow the agent to dynamically decide how many times a given platform will be visited.

Some of the proposed works to prevent the agent from being executed on more than one occasion have been based on preserving the so-called "unique execution property" ("exactly-once execution property"). In general this property is taken into account when designing fault tolerance mechanisms for mobile agents. Securing said property implies that, when the agent has been sent to perform a specific task: first, the task will be finally executed, regardless of possible failures in the platform or in its communications; and secondly that the task will not be performed more than once.

The solutions presented to ensure the single execution property are based on the use of external entities that monitor the execution of the agent. When a failure prevents the agent from continuing his itinerary, another agent is sent to resume execution at the point that the original agent left. The problem with these solutions is that communications between the agent and the monitoring system produce a considerable amount of network traffic. In addition, these protocols severely reduce the autonomy of the agent, because the agent has to constantly interact with the monitoring entity. Thus, they sacrifice one of the greatest advantages associated with the use of mobile agent technology.

In summary, there is no known solution presented so far against repeat attacks that allows an agent to be executed on a platform. dynamically determined number of times. Considering that one of the great attractions of mobile agents is their dynamism and flexibility, fixing in advance in the agent code the number of possible migrations to a platform can be a serious impediment when implementing real applications.

Explanation of the invention

It is necessary to offer an alternative to the state of the art that actually allows a mobile agent to be legally re-executed in the same computing platform, while preventing the external attacks of repetition of mobile agents described in the previous section, improving security without sacrifice the intrinsic flexibility to mobile agents.

For this, the present invention proposes a method and system based on the use of designated authorization entities to generate new identifiers for the agent, thus allowing it to migrate to the same platform any number of times. Therefore, the proposed invention allows programmers to develop applications based on mobile agents in a secure manner, without sacrificing their intrinsic flexibility.

In a first aspect, the present invention concerns a method for the protection of computing platforms against external attacks of repetition of mobile agents, which comprises using a system of computing platforms connected to a network for the shared execution of distributed applications based in mobile agents, and comprising using path markers or agent identifiers to allow one or more mobile agents to be legally executed on a computing platform more than once, while preventing an illegal re-execution of said or said mobile agents, for considering it as an external attack of repetition.

Unlike the proposals mentioned in the previous section that suggest the use of path markers to prevent repetition attacks, the method proposed by the present invention comprises using one or more authorization entities to generate at least a new path marker or identifier to be used as authorization for the mobile agent, to allow it to be legally executed on said computing platform a number of times dynamically determined at runtime.

For a preferred embodiment, the method comprises using several authorization entities for the generation of new path markers for the mobile agent, in order to allow it to re-run on different computing platforms.

With regard to the aforementioned legal re-execution, for an example of realization this refers to the execution of different tasks in different respective nodes or stages of the itinerary of the mobile agent, each of said nodes being different and representative of a visit to said computing platform at a different time than the rest of the nodes.

For another example of realization, the aforementioned legal re-execution refers to the execution of the same task in different respective visits to said computing platform along the itinerary of the mobile agent, each of said visits being represented by the same node or stage.

In other words, each node is associated with a specific task and platform, and in the event that each visit to the same platform is to execute a different task, these visits will be represented by different nodes associated with the same platform, and for the In case the successive visits to the same platform are to execute the same task, said visits will be represented by the same node.

In any case in this report the term node is understood as a respective visit to a platform, either the same or another platform, in order to execute a task, either the same or a different one. In the following, when reference is made to the execution of a node, it will imply the execution of the task associated with said node on the platform also associated with said node.

The method comprises generating and associating a different path marker or identifier to each of several mobile agents, even if they execute exactly the same tasks, and to each instance of the same mobile agent.

Likewise, the method proposed by the first aspect of the invention is provided for the prevention of repeated attacks, instead of subsequent detection, since this subsequent detection is in many cases useless.

The method comprises storing in each computing platform a node identifier previously executed by each mobile agent in said computing platform, together with its respective path marker, in order to allow the agent to visit the same platform to execute different nodes , or re-execute the same node a certain number of times.

By storing in each computing platform the path markers of the mobile agents that have previously visited it, it is achieved that no agent You can re-execute the same node using a path marker that has been previously used.

By means of the application of the method proposed by the invention, in order to offer a more effective solution in preventing repetition attacks, there is no interaction of the mobile agent with external entities, which allows the agent to run from autonomously, without relying on control or interaction with any monitoring service.

The method proposed by the first aspect of the invention comprises performing the following steps, which will be described later in greater detail for some examples of embodiment:

- initially create, by a proprietary user or programmer, a mobile agent protected against repeated attacks, including at least an initial route marker or identifier, a protected itinerary and the mobile agent itself, with the data included in it,

- send said protected mobile agent to a computing platform,

- receive said protected mobile agent on said computing platform,

- extract, by said computing platform, at least part of the information included in said protected mobile agent and use it to check if said protected mobile agent has already been re-executed previously, by comparing part or all of the information extracted with information stored in the computing platform, including said information stored at least the path markers of previously executed agents, together with respective node identifiers representative of the node tasks executed by said agents.

Regarding the aforementioned protected itinerary, the method includes constructing it by performing the following actions:

- define a set of nodes or stages that make up said mobile agent itinerary, each of said nodes being, as indicated above, associated with a specific task and a certain platform, and each of said nodes being associated with a corresponding authorization entity that is the only one responsible for generating new valid path markers used as authorizations for the execution of the task associated with said node;

- protect said agent itinerary using a protection protocol.

For reasons of clarity, the method is being described in different parts of this report by referring to a receiving platform of a protected mobile agent, but obviously said description is applicable to all platforms of computing connected to the network of said system that are in said situation, that is to say that they receive a mobile agent protected in the manner described.

The method comprises using each path marker as an authorization that allows the mobile agent to execute a specific set of tasks, each of which is associated with a node of said set of nodes.

In order to define said set of nodes, the method comprises assigning the following information to each of the nodes that make up the set:

- a node identifier;

- a computing platform where it will be executed;

- A homework;

- a type of node;

- next platform;

- an authorization entity;

- an authorization node;

- an agent identifier.

For the application of the method proposed by the first aspect of the invention it is only necessary to classify the nodes into two types of node, in particular the following:

- a type of regular node, which refers to a node that is a stage of the itinerary where the mobile agent executes his task and jumps to the next computing platform of the itinerary;

- a type of loop node, which refers to a node that is a stage of the itinerary where the mobile agent determines whether or not to start an iteration of a certain number of nodes.

Continuing with the rest of the information assigned to each node of the set of nodes, in particular the method comprises defining said authorization node as an identifier of the node where the path marker of the mobile agent must be generated, either said initial path marker or one of said new route markers, and defining said authorization entity as the corresponding computing platform or the owner or programmer user who must generate and sign the route marker.

The method comprises assigning a respective authorization node to each node or not, depending on whether or not the node is located inside a loop of nodes.

Specifically, the method comprises assigning as an authorization node to each node that is located inside a loop, the loop node located at the beginning of the loop (which in this memory is understood as not being inside the loop) and as its corresponding authorization entity the computing platform where the task of said initial loop node is executed, and to each node that It is not located inside a loop, assign any authorization node and as its corresponding authorization entity the owner of the mobile agent.

As regards the protection protocol used for the protection of the itinerary of the mobile agent, the method proposed by the first aspect of the invention comprises defining it by guaranteeing the following properties:

- prevent computing platforms from accessing or modifying any part of the itinerary that is planned for other computing platforms;

- make it impossible to travel the itinerary nodes in a different order from the one initially established; Y

- uniquely link each node of the itinerary with the mobile agent to which it belongs, to prevent the reuse of any part of the itinerary of the mobile agent in a different mobile agent.

For the definition of said protocol, the method comprises using a unique agent identifier to uniquely link the itinerary nodes to the mobile agent. As an agent identifier, depending on the exemplary embodiment, it can be used from a temporary stamp attached to a random number formed by a large number of digits, or any other information that uniquely identifies each instance of the agent.

The method comprises generating each of the route markers of each mobile agent, either said initial route marker or one of said new route markers, with the following information:

- an agent identifier identical to said agent identifier included in the protected itinerary and used to link the itinerary nodes with the mobile agent, to ensure that any instance of mobile agent can be uniquely identified;

- an authorization node as an identifier of the node where the path marker is generated;

- an expiration date after which the route marker can no longer be used; Y

- a loop counter increased by one unit each time the mobile agent has to start a new iteration of a loop. When the generated route marker is said initial route marker it is generated by the owner or programmer user, once he has built the said protected itinerary.

On the other hand, when the generated route marker is one of said new route markers, it is generated by the computing platform corresponding to the authorization entity assigned in the protected itinerary.

Once the route marker has been generated, the method comprises signing it by the owner user or the authorization entity and placing it on top of a stack of agent route markers configured to store route markers previously used by the mobile agent during execution.

Except in an initial state where said battery is empty before depositing said initial path marker therein, in the other cases the battery will store at least part of the aforementioned path markers previously used by the mobile agent, always containing at its top the current path marker, that is, the one that is being used or has been arranged to be used in the next node.

As indicated above once the platform has received a mobile agent protected according to the method of the present invention, it proceeds to extract some of its information. For a preferred embodiment, said extraction of information carried out by the computing platform from the protected mobile agent received concerns:

- extract the information from the current node of the protected itinerary to obtain the node identifier, agent identifier, task, type of node, next platform, authorization entity and authorization node; Y

- recover the agent path marker from the top of the agent path marker stack and extract the agent identifier, the authorization node, the expiration date and the loop counter from the recovered path marker.

As regards the information stored in the computing platform used to compare it with that extracted from the mobile agent, it is represented, for an example of embodiment, by a table, although for other examples of embodiment said information can be structured in another way that does not include the use of a table.

Next, a preferred embodiment example of the method proposed by the first aspect of the invention is described, for which the method comprises First, use, by the receiving computing platform of the protected mobile agent, the type of the current node to determine if the agent is executing a regular type node or a loop type node.

Once the type of node has been determined, if it is of a regular type, the method includes carrying out, by the receiving computer platform of the protected mobile agent, part, or all, if necessary, of the following operations: a) verify the signature of the route marker to check if the route marker has been signed by the current authorization entity, and if such verification is not successful discard the execution of the agent, or if it is successful to perform the following operation; This verification is carried out, for an exemplary embodiment, by using a public key server to obtain the public key of the current authorization entity, and its use to verify the signature; b) verify that the current authorization node, which is included in the route marker is the same as that extracted from the protected itinerary, and if said verification fails to discard the execution of the agent, or if it is successful to perform the following operation; c) verify that the agent identifier included in the route marker is equal to that obtained from the protected itinerary, and if said verification fails to discard the execution of the agent, or if the following operation is successful; d) check the expiration date of the route marker, and if the route marker has expired, discard the execution of the agent, or if the following operation has not expired; e) use the agent identifier to search for a previous path marker of the same agent in said information stored in said table (or other data structure) stored in the computing platform, and: e1) if there is no path marker with the same agent identifier in said table, storing the new path marker together with the identifier of the current node in said table; e2) If there is a previous path marker with the same agent identifier in that table, which means that the same agent had already been previously executed on this computing platform, check if the identifier of the current agent node is equal to of the previous execution, by means of the consultation of said table; and e2a) if the identifier of the current node of the agent is different from that of the previous execution, which means that the agent will execute a different task corresponding to a node of the different itinerary, storing the path marker along with the new identifier of the current node in said table; e2b) if the identifier of the current node of the agent is equal to that of the previous execution, which means that the task of this node of the itinerary had been executed in the previous execution, compare the current loop counter with the one included in the marker of previous path, and: e2b1) if the current loop counter is greater than the previous one, which means that the agent is performing a new iteration of a loop, replace, in said table, the previous path marker with the current one; e2b2) if the current route counter is not greater than the previous one, which means that the route marker has already been used, discard the execution of the agent; f) if the execution of the agent has not been discarded in any of the previous operations, execute the task corresponding to the current node.

Operations a) to f) are, in general, carried out on said computing platform receiving the protected mobile agent.

If it has been determined that the current node is of the loop type, the method comprises performing, by the receiving computer platform of the protected mobile agent, part, or all, if necessary, of the following operations: i) verify the signature of the route marker to check if said route marker has been signed by the current authorization entity or by the current computing platform, and if both checks fail to discard the execution of the agent, or if at least one of both checks is successful to perform the next operation; ii) perform the following operation:

-Check that the current authorization node, which is included in the route marker, is the same as the one extracted from the protected itinerary or coincides with the current node and if both checks fail to discard the execution of the agent, or if at least one is successfully perform these operations c) ae); iii) generate and sign a new path marker containing the same information as the previous path marker, with the exception of the authorization node, the current node being assigned as the authorization node, and also with the exception of the loop counter, which is incremented in a unit; iv) check if the agent is visiting the loop-type node for the first time, which means that the agent has not yet performed any previous iteration of the loop started on the loop-type node, and: vat) if the agent is visiting the node loop for the first time, add the new path marker to the agent path marker stack, placing it on top of it; ivb) if the agent has already performed some iteration of the loop previously, replace the current path marker, which was arranged at the top of the agent path marker stack, with the new path marker; v) perform said operation f); vi) determine, by the agent, whether to iterate the loop; and: via) if an iteration must be carried out, make the protected mobile agent jump to the next platform inside the current loop, check the type of node and, depending on the type of node, carry out operations a) to f) or i) to vi); vib) if an iteration of the loop is not required, extract, by the agent, the path marker from the top of the stack, skip the protected mobile agent to the next platform outside the current loop, check the type Node and depending on the type of node perform the operations a) to f) or i) to vi).

Operations i) to v) are, in general, carried out on said computing platform receiving the protected mobile agent.

Comparing the operations to be performed when the node is of the loop type with those previously described for a regular type node, it can be seen how one of the main differences between them is the verification that for the regular type node, it is done in the operation b ), which, for the loop type node, is done in i), and that differs from the operation b) in that the comparison of the current authorization node included in the path marker, is made not only with the one extracted of the protected itinerary, but also with the current node, which allows the agent to execute the current loop type node using a path marker generated by the same platform in a previous iteration.

Another difference is that concerning the verification of the signature of the route marker, which in i), unlike in the operation a), contemplates that if it has not been carried out by the current authorization entity, a checking if the signature of the current path marker has been performed by the platform current computing (for example using its own public key), which allows the agent to execute the current loop type node using a path marker generated by the same platform in a previous iteration.

Finally, through the operation iii) of generating and forming a new path marker for the mobile agent, a new execution of all nodes included in the loop initiated in the current loop type node is made possible. By arranging the new path marker in the upper part of the agent stack (iva operation) or ivb)), it is allowed for it to recover the path marker used before entering the loop (vib operation), which is an essential feature for the present embodiment, since the new path marker for the current platform will not be valid when the agent leaves the loop.

As regards the determination carried out in the operation vi) by the mobile agent, it can be carried out in various ways, depending on the example of embodiment, the programmer having marked, in general, one or more conditions to be verified by the mobile agent, based on whose compliance it determines whether or not to exit the loop.

For an exemplary embodiment, said conditions are simply that a variable reaches a value that is below a tolerance, said verification being carried out by means of the reading, by the agent, of said variable, and the repetition of said reading until it offer said value below the tolerance set by the programmer, in which case the agent determines to exit the loop.

A second aspect of the present invention concerns a system of computer platforms protected against external attacks of repetition of mobile agents, comprising a plurality of computer platforms connected to a network and adapted to run distributed applications based on mobile agents that include path markers or agent identifiers to allow one or more mobile agents to be legally executed on one or more of said computing platforms more than once, while preventing an illegal re-execution of said mobile agent or said agents, considered as a external repeat attack.

Unlike the conventional proposals, the system proposed by the second aspect of the invention comprises one or more authorization entities in connection with said network, intended to generate at least a new path marker or identifier to be used as authorization, for the agent mobile, for allow it to be legally executed on said or said computing platforms a number of times determined dynamically at runtime.

For an example of realization of the proposed system, said authorization entity is one of said computing platforms, and for another embodiment it is a programmer or user owner of said mobile agent.

The system proposed by the second aspect of the present invention is adapted to apply the method proposed by the first aspect.

Brief description of the drawings

The foregoing and other advantages and features will be more fully understood from the following detailed description of some embodiments with reference to the attached drawings, which should be taken by way of illustration and not limitation, in which: Fig. 1 illustrates schematically a series of nodes that form a simple itinerary where the same platform is visited twice according to the method proposed by the present invention for an embodiment;

Fig. 2 schematically shows an itinerary of nodes that includes a loop formed by three computing platforms that can be visited repeatedly according to the method proposed by the first aspect of the present invention for a more complex embodiment example than that of Fig. 1;

Fig. 3 schematically illustrates another node itinerary that includes two loops, one inside the other, formed by computing platforms that can be visited repeatedly according to the method proposed by the first aspect of the present invention for another example of more realization;

Fig. 4 is a schematic representation of the components included inside a mobile agent protected against repeated attacks by applying the method proposed by the present invention; and Figs. 5a and 5b show individual parts of the same flowchart, which represent the different operations to be carried out according to the method proposed by the first aspect of the invention, for the previously explained preferred embodiment, after checking if the node is of the regular type , in which case the operations a) to f) illustrated in Fig. 5a (all or in part depending on the path followed in the flow chart), or loop type, in which case the operations i) are performed a vi) illustrated in Fig. 5b (all or in part depending on the path followed). Detailed description of some embodiments

Referring firstly to Fig. 1, it can be seen the simplest case in terms of the itinerary to be traveled by a mobile agent, where said itinerary does not contain any loop of nodes. In this case, when the agent has to migrate to a certain platform several times, he will do it at different stages or nodes of his itinerary, which means that he will execute different tasks. Specifically in said Fig. 1 platform B is visited twice, a first visit in node 2 and a second visit in node 4.

In this case, repetition attacks are simple to prevent, by storing an identifier of the node or of the task executed, together with the path marker of the agent.

Said Fig. 1 is an example of an itinerary that can be protected against re-execution attacks using simpler protocols than those proposed by the present invention, some of which have been cited in the state of the art section.

In Fig. 2 an itinerary of nodes representative of a more complex case is illustrated for which the mobile agent has to perform the same task on the same platform several times, a number of times which is dynamically determined by the method proposed by The present invention.

In particular, in said Fig. 2 an itinerary formed by five nodes is illustrated, with a loop initiated in node 2, which runs on platform B, and which includes nodes 3 and 4. In this case and referring to The type classification of nodes described in a previous section, nodes 1, 3, 4 and 5 are of the regular type and node 2 is of the loop type, since I could decide whether to enter the loop or not, that is, if continue to node 5.

In this case the detection of agent repetition attacks is more complicated, since for example when the platform C forwards the agent to the platform D, the latter must find out if a new execution is a repeat attack or a new iteration of the loop , Which could not be carried out with conventional proposals, but by means of the application of the method proposed by the present invention, specifically by performing operations a) to f) for nodes 1, 3, 4 and 5, and operations i) to vi) for node 2.

Fig. 3 illustrates an itinerary even more complicated than that of Fig. 2, since it incorporates two loops, one external formed by nodes 1, 2 and 3, and another internal formed by nodes 3 and 4. In this case nodes 1 and 3 are loop type, and nodes 2, 4 and 5 are regular type. In said Fig. 3 the authorization entities, referred to as EA, and the authorization nodes, referred to as NA, assigned to each node according to the description made in the explanation section of the invention have been indicated. Specifically, nodes 1 and 5, which are not inside any loop, have no authorization node and its authorization entity is the owner or programmer of the mobile agent. On the other hand, nodes 2 and 3, which are located inside the external loop, have as authorization entity the platform A and as authorization node node 1. Finally, node 4, which is located inside with an internal loop, the authorization C has the C platform and the node 3. As an authorization node, that is to say that for the itinerary illustrated by Fig. 3, there are three authorization entities: the owner of the agent, the A platform and Ia platform C.

According to Fig. 3, for a preferred embodiment the operations a) to f) (all of them as long as the execution of the agent as a result of any of them is not ruled out) are carried out when the nodes that receive the agent Protected mobile are nodes 2, 4 and 5, and stages i) to vi) when the receiving node is loop node 1 or 3, in its entirety, that is from i) to vi), as long as the execution of the agent as a result of some of these operations is not ruled out.

For an exemplary embodiment based on Fig. 3, for which the agent requires performing a series of iterations of the external loop, platform A generates and signs a new path marker for each new iteration (step ii) and also verifies (operation i)) that the signature of the path marker of the agent receiving said platform A has been carried out by the owner (in case a previous iteration of the external loop has not been performed) or by itself (case in which has performed a previous iteration of the external loop, and therefore the agent carried a path marker generated and signed by platform A). The mobile agent determines in operation vi) whether or not it exits the loop, for example in the case of the external loop said determination will take place on platform A, and if the determination is to exit the loop, this will imply a jump of the agent to the platform E to execute node 5, in which case the path marker disposed in the upper part of the stack, and which has allowed me to iterate the loop, is extracted from the agent stack, so that the path marker Original and generated and signed by the owner can be used again to continue the execution on platform E.

Platform C would act in a manner analogous to that described in the previous paragraph for platform A, to allow legal iterations of the internal loop that are not interpreted as re-execution attacks. In Fig. 4 the content of a protected mobile agent created according to the method proposed by the first aspect of the present invention has been schematically illustrated.

Specifically in said Fig. 4, the protected itinerary created by the programmer can be seen, consisting of n nodes, the stack of path markers and, in detail, one of the path markers of the stack, signed by the corresponding authorization entity , being appreciated that it contains the elements described in the explanation section of the invention, that is to say an agent identifier, an authorization node, an expiration date and a loop counter.

In said Fig. 4, on the right, the information contained in each of the nodes of the set of nodes that make up the protected itinerary included in the protected mobile agent, that is to say a node identifier, an agent identifier, a entity and an authorization node, the type of node and the task to be performed on said node, as well as the computing platform where it will be executed and the next platform.

The use of such information by a platform that receives the protected mobile agent has already been conveniently explained before.

Through the method proposed by the invention, each platform will only execute the current node of the agent's itinerary if the current path marker (the one located in the upper part of the stack) has been signed by the appropriate authorization entity.

By associating each node of the itinerary with both an entity and an authorization node, the possibility of an attacker attempting a repeat attack with an agent is prevented, reusing a path marker signed by the appropriate authorization entity but not generated in the appropriate itinerary node, that is, in the authorization node. This attack will be detected by the platforms when they verify if the path marker has been generated and signed on the appropriate node, that is, the authorization one.

Each itinerary node also contains an agent identifier, which is also included in the agent path marker, which prevents a given path marker from being reused in different agents, as this will be detected by the platforms computing when, applying the proposed method, compare the. agent identifier extracted from the current node with the one included in the path marker.

As explained above, the method proposed by the present invention also includes protecting, for example by encryption, the itinerary of the agent so that no attacker can change the information associated with a given node. This protection also prevents the agent's task from being executed on a platform different from those initially established.

The proposed method does not require the agent to interact with external entities, and only assumes that the loop-type nodes will be executed on reliable platforms for the programmer, since it is not possible to prevent the platforms from manipulating the execution of the agent that reaches them.

For an exemplary embodiment, the platforms prevent their route marker tables from being overfilled by eliminating entries that have expired. Additionally, another policy can be applied in order to enable the elimination of entries when no more route markers fit in a table (for example, eliminating the oldest ones.

In order to demonstrate the feasibility of the method proposed by the present invention, an example of its implementation is described below by applying the proposed method to a scenario such as that described in "Secure integration of distributed medical data using mobile agents", from "IEEE Intelligent Systems 2006"; 21 (6): 47-54, by the authors Vieira-Marques P, Robles S, Cucurull J, Cruz-Correia R, Navarro G, Martí R.

This scenario corresponds to that of medical institutions in which an information management system based on mobile agents has been implemented. In these scenarios, the patient registration process is managed by an agent platform, which maintains a registry of the patients attended by the institution. In addition, each of the departments of the medical institution has an agent platform that manages the history of the patients treated, and the services that have been performed.

In these scenarios, mobile agents are used, among other tasks, to automate the process of recovering medical records distributed by different institutions. Suppose an urgent surgical operation is required for a victim of an accident. Before beginning any operation in which there is contact with blood, medical personnel should know if the patient is carrying the HIV virus or Hepatitis B. The performance of the relevant tests before the intervention is unfeasible, because they are needed days to get the results. It is also not possible to rely on patients to obtain this information, as they may be unconscious. For this reason, the recovery of this information is done through an application based on mobile agents. The application is initiated by a medical professional who enters the patient's data and the identification of the results of the tests that must be obtained in a graphic interface. From here, the application generates a mobile agent to which it introduces all the information collected previously. The mobile agent, first, consults a database with information about all the institutions that carry out the HIV and Hepatitis B tests, in this specific case. The agent thus obtains a list of all those institutions in which these tests are performed.

Next, the agent conducts a remote consultation to each of these institutions to determine if the patient has ever been visited in that institution or not. If positive, the mobile agent travels to the relevant department of the medical institution to choose and extract the results that are needed. This process is repeated for each and every one of the institutions that carry out the tests corresponding to the HIV virus and Hepatitis B. As can be seen, the use of mobile agent technology makes it possible to greatly automate and speed up the recovery and extraction process of information.

However, the use of mobile agents can lead to problems of theft of private information from patients if the appropriate security measures are not used. An attacker could capture the agent and re-execute it later to obtain private information from a patient. For example, an agent could be captured and forwarded to the same institution later to obtain results of subsequent tests performed on the patient.

In addition, said re-execution attack could also entail economic losses for the patient, in case the agent visited a private institution to carry out a paid service. For example, an X-ray of the patient performed in a medical center could be transported by the agent for later analysis to a private institution. The use of the mobile agent would allow the patient to avoid a trip to said institution. However, if the agent were forwarded by an attacker to the same institution repeatedly, the patient would end up paying multiple times for the same service.

Therefore, the implementation of the protection method against re-execution attacks presented in the present invention is essential for the safe use of mobile agents in this distributed application scenario. This scenario is a clear example of the need to use adequate mechanisms for the prevention of re-execution attacks. In this implementation, the proposed method has been applied to a scenario related to medical institutions, but the method proposed by the present invention is applicable to many other scenarios related, for example, to financial institutions, travel agencies, or any other that involves the processing of confidential information or commercial transactions.

A person skilled in the art could introduce changes and modifications in the described embodiments without departing from the scope of the invention as defined in the appended claims.

Claims

1.- Method for the protection of computing platforms against external attacks of repetition of mobile agents, of the type that comprises using a system of computing platforms connected to a network for the shared execution of distributed applications based on mobile agents, and that it includes using path markers or agent identifiers to allow at least one mobile agent to be legally executed on a computing platform more than once, while avoiding an illegal re-execution of said mobile agent, considered as an external attack of repetition, characterized in that it comprises:

- create a mobile agent protected against re-execution attacks, including at least one initial path marker or identifier, a protected itinerary and said mobile agent itself, which is at least one,

- generate at least one new path marker or identifier, for said protected mobile agent, which is at least one, using at least one authorization entity;

- send said protected mobile agent to said computing platform,

- receive said protected mobile agent on said computing platform, and

- using, by said computing platform, said new path marker or identifier of the mobile agent received as an authorization to allow said mobile agent to be legally executed on at least said computing platform a number of times dynamically determined in time of execution, where to carry out said step of using said new path marker, or identifier of the mobile agent received, as an authorization, the method comprises extracting, by said computing platform, at least part of the information included in said protected mobile agent and use it to check if said protected mobile agent has already been executed previously, by at least comparing at least part of said extracted information with information stored on said computing platform, including said information stored at least path markers of previously executed agents, together with respective node identifiers representative of the node tasks executed by said agents.

2. Method according to claim 1, characterized in that it comprises storing in said computing platform an identifier of the task executed by said protected mobile agent in said computing platform, together with its respective path marker, in order to allow a certain number of times to be re-executed.

3. Method according to claim 2, characterized in that said legal re-execution refers to the execution of different tasks in different respective nodes or stages of the itinerary of the mobile agent, each of said nodes being different and representative of a visit to said computing platform at a different time than the rest of the nodes, each node being associated with a specific task and platform.

4. Method according to claim 2, characterized in that said legal re-execution refers to the execution of the same task in different respective visits to said computing platform along the itinerary of the mobile agent, each of said visits being represented by the same node, or stage, associated with a specific task and platform.

5. Method according to claim 2, characterized in that it comprises generating and associating a different path marker or identifier to each of several mobile agents, even if they perform exactly the same tasks, and to each instance of the same mobile agent.

6. Method according to claim 5, characterized in that it comprises carrying out said creation of said protected mobile agent by a proprietary user or programmer.

7. Method according to claim 6, characterized in that it comprises constructing said protected itinerary by performing the following actions:

- defining a set of nodes or stages that make up said mobile agent itinerary, each of said nodes being representative of a respective visit to said computing platform at a different time to execute a corresponding task, and each of said nodes being associated to a corresponding authorization entity that is solely responsible for generating new valid path markers used as authorizations for the execution of the task associated with said node;

- protect said agent itinerary using a protection protocol.

8. Method according to claim 7, characterized in that, in order to define said set of nodes, the method comprises assigning the following information to each of the nodes that make up the set:

- a node identifier;

- a computing platform where it will be executed;

- A homework; - a type of node;

- next platform;

- an authorization entity;

- an authorization node;

- an agent identifier.

9. Method according to claim 8, characterized in that, in order to define said type of node, establish the following two types of node:

10. Method according to claim 9, characterized in that it comprises defining said authorization node as an identifier of the node where the path marker of the mobile agent must be generated, either said initial path marker or one of said new path markers, and defining said authorization entity as the corresponding computing platform or the owner or programmer user who must generate and sign the route marker.

11. Method according to claim 10, characterized in that it comprises assigning or not assigning a respective authorization node to each node, depending on whether or not the node is located inside a loop.

12. Method according to claim 11, characterized in that it comprises assigning as an authorization node, to each node that is located inside a loop, the loop node located at the beginning of the loop and as its corresponding authorization entity the platform computing where the task of said initial loop node is executed, and to each node that is not inside a loop, no authorization node and as its corresponding authorization entity to said user owner of the mobile agent.

13. Method according to claim 12, characterized in that it comprises using an agent identifier to link the itinerary nodes to the mobile agent.

14. Method according to claim 12, characterized in that it comprises generating said path marker for the mobile agent, either said initial path marker or one of said new path markers, with the following information: - an agent dentifier identical to said agent identifier included in the protected itinerary and used to link the itinerary nodes with the mobile agent, to ensure that any instance of mobile agent can be uniquely identified;

- an authorization node as an identifier of the node where said path marker is generated;

- an expiration date after which the route marker can no longer be used; Y

- a loop counter increased by one unit each time the mobile agent has to start a new iteration of a loop.

15. Method according to claim 14, characterized in that when said path marker generated is said initial path marker it is generated by said owner or programmer user, and when it is one of said new path markers it is generated by of the computing platform corresponding to the authorization entity assigned in said protected itinerary.

16. Method according to claim 15, characterized in that it comprises signing said route marker generated by said owner user or said authorization entity and placing it on top of a stack of agent route markers configured to store previously used route markers. by the mobile agent during its execution.

17. Method according to claim 16, characterized in that said extraction of information carried out by said computing platform from said protected mobile agent received concerns:

- extract the information from the current node of said protected itinerary to obtain said node identifier, agent identifier, task, type of node, next platform, authorization entity and authorization node; Y

18. Method according to claim 17, characterized in that it first comprises using, by said receiving computing platform of the protected mobile agent, the type of the current node to determine if the agent is executing a regular type node or a type node loop.

19. Method according to claim 18, characterized in that it comprises performing, by said computing platform receiving the protected mobile agent, at least part of the following operations if said current node is a regular type node: a) verify the signature of the route marker to check if the route marker has been signed by the current authorization entity, and if said verification is not successful discarding the execution of the agent, or if it is successful to perform the following operation; b) verify that the current authorization node, which is included in the route marker, is the same as the one extracted from the protected itinerary and if said verification fails to discard the execution of the agent, or if it is successful to perform the following operation; c) verify that the agent identifier included in the route marker is equal to that obtained from the protected itinerary, and if said verification fails to discard the execution of the agent, or if the following operation is successful; d) check the expiration date of the route marker, and if the route marker has expired, discard the execution of the agent, or if the following operation has not expired; e) use the agent identifier to search for a previous path marker of the same agent in said information stored in the computing platform that includes path markers of agents previously executed together with the respective node identifiers representative of the tasks executed by said agents , said stored information being represented by a table, and: e1) if there is no path marker with the same agent identifier in said table, store the new path marker together with the identifier of the current node in said table; e2) If there is a previous path marker with the same agent identifier in that table, which means that the same agent had already been previously executed on this computing platform, check if the identifier of the current agent node is equal to of the previous execution, by means of the consultation of said table; and e2a) if the identifier of the current node of the agent is different from that of the previous execution, which means that the agent will execute a different task corresponding to a node of the different itinerary, store the path marker along with the new identifier of the current node in said table; e2b) if the identifier of the current node of the agent is equal to that of the previous execution, which means that the task of this node of the itinerary had been executed in the previous execution, compare the current loop counter with the one included in the marker of previous path, and: e2b1) if the current loop counter is greater than the previous one, which means that the agent is performing a new iteration of a loop, replace, in said table, the previous path marker with the current one; e2b2) if the current route counter is not greater than the previous one, which means that the route marker has already been used, discard the execution of the agent; f) if the execution of the agent has not been discarded in any of the previous operations, execute the task corresponding to the current node.

20. Method according to claim 19, characterized in that it comprises performing, by said receiving computing platform of the protected mobile agent, at least part of the following operations if said current node is a loop type node: i) verify the signature of the route marker to check if said route marker has been signed by the current authorization entity or by the current computing platform, and if both checks fail to discard the execution of the agent, or if at least one of both checks is successful. The next operation; ii) perform the following operation:

-Check that the current authorization node, which is included in the route marker, is the same as the one extracted from the protected itinerary or coincides with the current node and if both checks fail to discard the execution of the agent, or if at least one is successfully perform these operations c) ae); iii) generate and sign a new path marker containing the same information as the previous path marker, with the exception of the authorization node, the current node being assigned as the authorization node, and also with the exception of the loop counter, which is incremented in a unit;

V) check if the agent is visiting the loop type node for the first time, which means that the agent has not yet performed any previous iteration of the loop started on the loop type node, and: vat) if the agent is visiting the loop node for the first time, add the new path marker to the agent path marker stack, placing it on top of it; ivb) if the agent has already performed some iteration of the loop previously, replace the current path marker, which was arranged at the top of the agent path marker stack, with the new path marker; v) perform said operation f); vi) determine, by the agent, whether to iterate the loop; and: via) if an iteration must be carried out, make the protected mobile agent jump to the next platform inside the current loop, check the type of node and, depending on the type of node, carry out operations a) to f) or i) to vi); vib) if it is not necessary to perform an iteration of the loop, extract, by the agent, the path marker of the upper part of the stack, skip the protected mobile agent to the next platform outside the current loop, check the type Node and depending on the type of node perform the operations a) to f) or i) to vi).

21. Method according to claim 19, characterized in that said operations a) to f) are carried out on said computing platform.

22. Method according to claim 20, characterized in that said operations i) to v) are carried out in said computing platform.

23.- System of computer platforms protected against external attacks of repetition of mobile agents, of the type comprising a plurality of computer platforms connected to a network and adapted to execute distributed applications based on mobile agents that include path markers or ¡ agent dentifiers to allow at least one mobile agent to be legally executed on at least one of said computing platforms more than once, while avoiding an illegal re-execution of said mobile agent, considered as an external repeat attack , characterized in that it comprises at least one authorization entity in connection with said network, intended to generate at least one new path marker or identifier to be used as authorization, for said mobile agent, which is at least one, to allow it to be legally executed in at least said computing platform a dynamically determined number of times and n runtime.

24.- System according to claim 23, characterized in that said authorization entity is one of said computing platforms.

25.- System according to claim 23, characterized in that said authorization entity is a programmer or user owner of said mobile agent.

26.- System according to claim 23, 24 or 25, characterized in that it is adapted to apply the method according to any one of claims 1 to 22.