Book Chapter
Reference
Police Agents for Enforcing Internet Security
BRYCE, Ciaran
Abstract
Mobile Agents have promised much as an Internet programming technology, but well publicized security problems are hampering their acceptance. This paper argues that mobile agents are a vital component of any Internet security solution. For instance, agents can move computations to safe areas, and can replace out-dated security mechanisms that adapt poorly to the Internet. To underline this argument, the paper proposes a security architecture that uses mobile agents as its basic mechanism. The semantics of agent security policies in this architecture is also given.
BRYCE, Ciaran. Police Agents for Enforcing Internet Security. In: Tsichritzis, Dionysios.
Trusted objects = Objets de confiance . Genève : Centre universitaire d'informatique, 1999.
p. 217-239
Available at:
http://archive-ouverte.unige.ch/unige:155908
Disclaimer: layout of this document may differ from the published version.
1 / 1
Police Agents for Enforcing Internet Security
Ciaran Bryce
Abstract
Mobile Agents have promised much as an Internet programming technology, but well pub- licized security problems are hampering their acceptance. lbis paper argues that mobile agents are a vital component of any Internet security solution. For. instance, agents can move computations to safe areas, and can replace out-dated security mechanisms that adapt poorly to the Internet. To underline this argument, the paper proposes a security archi- tecture that uses mobile agents as its basic mechanism. The semantics of agent security policies in this architecture is also given.
1 Introduction
The problem
Mobile Agents is a promising programming paradigm for Internet applications. A mobile agent encapsulates the code and data of a computation, and can move autonomously between net- work sites. Mobility is useful for several reasons. First, a computation can be moved near to where the resources and services that it needs reside, thus optimizing use of expensive and slow networks, and allowing the computation access to services while its home base is off-line [17).
Second, code is dynamically linked to applications; this simplifies dynamic customization of services, remote server configuration and software updates [6).
Security has been identified as the major concern for the agent paradigm [26) for two rea- sons. First, foreign code that executes on a site shares that site's services and resources with local processes and other agents. Services can include electronic commerce utilities. Resources include the file system, the GUI and the network server, as well as memory and CPU. It is dif- ficult for a site to ensure that no agent can steal information or corrupt another agent or shared resource. The second security problem is that the agent itself can be circumvented by a mali- cious site which may steal or corrupt agent data ot simply destroy the agent. These problems are hampering acceptance of the mobile agent paradigm [ 10).
The goal of this paper is to accentuate the positive aspects that agents bring to Internet security. We present a security architecture that allows for specification and enforcement of security policies in agent-based Internet applications. A mobile agent's security policy specifies if and when its execution environment and neighboring agents can access the information inside of the agent. The rules of the policy specify the changes in the allocated access rights that occur following different types of agent events.
Agent security policies
A mobile agent travels the network, communicates with other agents and services, and may create and terminate other agents. Agent creation, termination, communication and migration constitute the basic set of agent actions. One way of programming agents is in an event-driven style: for each event action that an agent is subject to, the program specifies the reaction that the agent takes to this event. The reaction is some set of agent actions1• This model is also used here to express an agent's security policy. As an example, the following policy rule states that whenever an agent observes that agent A moves to site S, the agent assigns A the access classification UNTRUSTED. The access classification is a way of grouping access rights; UN- TRUSTED could be the classification corresponding to no rights. The agent might have such a policy since it assumes that agent A can no longer be trusted when it migrates to the untrusted site S.
A moves to S A becomes UNTRUSTED
This event style for policies captures the evolution of security in a system: the actions effected by an agent are perceived as events in other agents and influence the security policies of these agents. Also, in a later stage, we wish to prove agent security properties from the policies. The goal is a way of detecting flaws or inconsistencies in policies [I 6]. For instance, the example policy rule above says nothing about the access rights that should be granted to agent A if it moves to a site other than S.
Agent security architecture
A security architecture's role is to provide mechanisms that allow for the secure execution of applications. Services on the Internet include electronic commerce facilities [24) and so the security constraints may be very stringent. The approach described in this paper uses mobile agents as the basis for its security architecture. Agents replace traditional security architecture notions such as certificates, access control lists and can carry computations to safe areas. The agents used by the security infrastructure are termed police agents. There are several reasons for using police agents to enforce security, despite the agent security problems mentioned:
• Good structuring tool: Agents have several advantages for distributed systems, e.g., they optimize the use of the network when using servers, they allow one to customize the code of a server by dynamically linking in new code. These advantages are just as pertinent to security-services like authentication, certification or authorization.
• The case against agents is primarily based on the security worries that agents pose. This paper argues that this case is often unfairly argued for two reasons. First, alternative
1 Event-driven programming is just a choice of programming style for mobile agents. Agents are meant to be autonomous, i.e., to execute on Internet sites independently of their creator. To achieve this, agents must be able to adapt or react to a range of events that can happen, e.g., network failure, broken link pointer to information, request for data access, etc.
c.
Bryce 219approaches to agents also have serious security problems. Second, some application scenarios used to highlight security failings in mobile agent applications employ flawed computational models, meaning that the network configuration is at fault in the applica- tion and not the fact that agents are being used.
• The technological follow-on to centralized operating systems were distributed systems.
Distribution posed new problems for security; notably, the number of users increased and authentication became more difficult. On the other hand, distribution offered some help:
they introduce safe areas of computation since trusted code and data can be physically isolated from untrusted users. This feature is exploited to configure security architectures like Kerberos [20). In the same way, agents constitute the next step in distributed systems:
despite the mentioned security worries, one must consider the positive aspects of agents for security. For instance, agents can move whole computations and not just data to safer areas of computation.
• Simplify security architectures: The evolution of security architectures has left a myriad of security concepts: ACLs, certificates, etc. We argue that agents as a basic security mechanism simplifies and modernizes the set of mechanisms. For instance, a certificate is a data structure sent over the network from an authority that verifies the validity of a public key [13). However, since agents are data and code, a certificate can be a pro- gram rather than just a lifeless data structure. The certificate could be used to respond differently to different clients (e.g., a high-level user uses a shorter lived validity, etc.) Road map Section 2 argues for the use of police agents for enforcing security. Section 3 defines the key concepts of the security architecture. Section 4 introduces the semantics of the architecture. Section 5 gives a small example. Section 6 describes related work and Section 7 concludes.
2 Basis for an Agent Security Architecture
Mobile a·gents pose well-known security problems [26]. The first stems from the fact that foreign and potentially untrustworthy code is able to execute on a local machine. The foreign agent typically requires access to local services and resources (e.g., GUI, database, file server, memory and CPU). It is difficult to ensure that the visiting code does not abuse these services and resources. For instance, an agent might over-consume resources (leading to a denial of service attack), or via a covert channel gain access to information which
it
is not allowed to have (confidentiality attack), or even destroy data belonging to a service or to another agent (integrity attack). There has been much work aimed at isolating or sand boxing agents from the rest of the system, e.g., [14), though a thorough isolation remains difficult to achieve.Another security problem with the mobile agent paradigm is that the agent itself is at risk from the hosting environment, which may steal information from it or even destroy it. Current approaches to this problem use privacy homo-mo1phisms [ 11, 19) or attempt to detect attacks that have already happened [25). A privacy homo-morphism is a program that is "encrypted"
in such a way that it operates on encrypted data and produces the result in encrypted form. This
means that the data in clear text need never be revealed on an untrusted site. In the detection of attacks approach, a host that executes an agent must sign intermediate computational results which are sent back to the agent's originating site for verification. Both of these methods have limitations: privacy borno-molJlhisms do not exist for a large class of problems, detection methods only detect forms of integrity attacks.
1n this paper, no attempt is made to mitigate these security worries. Rather, an attempt is made to accentuate some of the positive aspects of mobile agents with respect to security.
To this end, a security architecture is presented that is based solely on mobile agents. The remainder of this section motivates this design choice. The presentation is based around the four points mentioned in the introduction: the need for a good structuring tool, the fact that the literature contains unfair security scenarios involving mobile agents, that agents are the newest technology that can be used to secure applications, and that a resulting security architecture eliminates many redundant mechanisms.
2.1 Structuring Tool
There are several reasons why mobile agents are useful for Internet applications:
• Mobile Code for the distribution of software or of software updates. Programmes can be sent out over the network to clients and installed dynamically [4].
• Service scalability. A relatively simple interface suffices for services; new service func- tionality can be added within agents that are sent to the server and which process the results returned by the server. One application of this is in heterogeneous database man- agement, where agents are sent to the site to handle compatibility issues in a federated database [15].
• Active nerworld11g is an application of mobile agents currently grabbing much attention in the networking industry. Active network packets can include programs that execute on routers. In this way, the network is an execution platform that can take decisions like compressing a packet, changing the routing, or setting up secure channels between nodes [22].
• Off-line operation. A user can send a program to work at a server while the user and bis site is disconnected from the network. Alternatively, the server can send a computation to the client side, so that the client can operate off-line [17].
• Performance is a crucial benefit of agent t~hnology. Moving a computation nearer to where th.e services that it needs reside means that one can minimize use of expensive network connections [ 1 O].
It is clear that these benefits are also pertinent to security software and services. We consider each of the points in turn, citing typical security scenarios as informal examples.
Regarding mobile code, a security architecture could exploit this to distribute security policy code to sites. One example is a client loading a security protocol, e.g., for secure payment, in a
C. Bryce 221 network computing framework [14]. Another example currently widely used is that of a login applet sent to a user by a server that asks for a user name and password. Service scalability subsumes remote configuration. Updating the security policy in place at a server by sending a mobile agent is an example of remote security configuration. This is what will happen for active network routers to update keys and access control lists [22]. What makes the use of mobile agents for security feasible in these cases is that little changes regarding the trust relations in the system. For instance, consider a challenge response scheme used for authentication with a server; in a mobile agent implementation, the agent encapsulates the algorithm that the user must execute on a value provided by the server. The client is authenticated if the client returns a value that is expected by the server. The agent containing the challenge response algorithm can execute on any trusted site on behalf of the client. In this way, computation is moved to areas that are trusted by the client.
Active networking can benefit a security architecture by helping to maintain secure (en- crypted) paths between sites and for reconfiguring these paths when necessary. That is, each router can be dynamically programmed to decide on the safest next router for a message to be forwarded to. This is interesting since the degree of trust accorded to a route can vary, for ex- ample, with key freshness, with reports of intrusions on networks, and with trust (as represented say by PGP trust chains [ 13]) which is a dynamic relation.
Off-line operation is a feature that can benefit applications such as electronic commerce for services that can be executed at the site of any party involved in a commercial transaction. For instance, one feature of Semper is its conflict mediation functions that are used in electronic commerce transactions [5, 28]. The role of this code is to keep each party informed of his obligations at each stage of a transaction and to propose corrective actions in the event of a protocol going awry. This program should run (as an agent) at the site of each transaction party instead of at a third party site. With respect to the security of this agent approach, it is arguably more secure since a party can verify locally if he has obligations, rather than having to rely on an answer that comes in from the network.
Performance is just as important a property for a security architecture as for any application.
If security processing can be done locally rather than remotely without lowering the security of the application, then this must be exploited by the security architecture. For instance, capabil- ities are often used in this fashion as a cache of access rights on the client side [21]. Though a server can take authorization actions of its own, a trusted client site will not send a request to a server ifthe client process does not possess a capability for the action.
Using agents for security tasks is not risk free considering the kinds of security problems that agents involve which we mentioned in the introduction. What is important is that, in all of the above examples, agents are used only after an objective evaluation of the risks between agent and classic (client-server) approaches.
2.2 Attacking the Case Against
In the opening section we mentioned the main securjty problems posed by mobile agents. Much remains to be done in the treatment of these problems [26]. This section nevertheless outlines
a "case for the defense" of agents and security. There are two pillars to this defense:
1. Mobile agents are a programming paradigm for Internet applications. It is therefore important to consider how secure any alternate Internet programming paradigm. is.
2. Some of the problems mentioned in relation to mobile agent security arguably suffer from the "scenario from bell" syndrome. Contrary to what is suggested in many scenarios (7, 29), the intention of the paradigm is not to send any agent anywhere.
With respect to the first point, the alternative to sending code within applets or agents over the network is to use the classic client-server approach. Of course, this approach also poses serious security risks. Server sites can lie about the information they contain and even refuse to answer clients. The data returned traverses networks and Wltrusted sites, and so can be tampered with or illegally copied. Malicious clients can flood servers with useless requests, tlicrcby creating a resource control problem. Finnlly, considering oil the intennediarioo that requests pass through, authentication of the principatmak.ing the request cao be difficult.
Willi respect to the second point, some agent scenarios lack credibility. Take the widely cited airline reservation example [29); in the paper world, one would not circulate a letter between competing companies asking them for price quotes where the letter contained the only copy of the quote of competing companies. The Internet is not at fault here but rather the computational model of the example.
A more suitable and ored!"ble utility for agents in an airline reservation application is intel- ligent or batch bookings. For instance, an agent is sent to a server with a request "I want 2 seats on flight to Paris with an overnight stopover in Bonn. If this costs me more than 1 OOEUR, then reserve a direct llight". In this case, the request is being shipped to the server side for ex- ecution; the agent approach is u.seful because the client-server interaction is happening on the same machine, unaffected by slow network connections. This approach makes sense because the cost of an attack on an agent is equivalent to the cost of an attack on the messages that a buyer would exchange with the airline server in the client-server approach.
Nevertheless, there are situations where agents QaD be sent out with an itinerary of servers as is done in the airline reservation scenario [29). One example is an agent-based Internet search crawler, where a user starts a search of fue Internet "database" for documents matching some search string [23). One of ilie utilities of agents here is that the itinerary of search agents need not be fixed (an agent can be programmed in its own way to handle broken forward pointers, or to follow ''hints" given by sites). Like in the airline reservation scenario of [29], an agent is open to attack at each server visited, meaning that search results cannot always be trusted.
Unlike the airline reservation scenario, Internet search engines are used by everybody everyday and the accuracy of the results is variable: the user currently accepts that the quality of the results varies with the research algorithm and site availability. Thus, the agent approach to the search engine is on a level playing field to a client server approach from a trust perspective.
Again, an objective risk trade-off analysis must be done before using agents in an applica- tion. Sometimes the trade-offs make agents worthwhile.
C. Bryce 223
2.3 The Technological Follow-up
Computer security became an important issue for programmers and designers in the 1960s with the advent of time-sharing systems. Several users simultaneously shared the same CPU, memory and file system and thus had to be protected from one another.
The two important questions to address were authentication (verify the identity of the user) and authorization (determine the access rights that the process belonging to the user should have). Authentication was based on passwords or badges, and took place when the user Jogged in. Authorization occurred during file access and process creation. Access rights were either represented either as capabilities in a process' address space which the process presented when attempting a file access, or as access control lists bound to the object or file being protected.
The latter approach is taken in Unix for instance.
Distribution over local area networks brought a new dimension to the security problem [21 ].
First users had control over their local stations, and could easily fake their identity when call- ing a remote server. Further, the messages exchanged between stations could not always be considered secure from eaves-dropping or from tampering.
A further problem was that the software structure of the system evolved. To cope with the increasing demand for new services, users could offer code and services to others and new services could be dynamically added that were not part of the kernel. These services ran as ordinary user processes. This is known as client-server processing. In this model, a request made to a server could be forwarded to several other servers before the result comes back to the user. For instance, a call made to a file server for file creation provokes a call to a disk server for disk block allocation [21]. In this system model it is harder to identify the actual user responsible for a call (authentication).
To cope with problems posed by distribution, encryption techniques began to be exploited for securing data on the network and data stored in untrusted environments, e.g., diskettes.
Encryption is also the basis for digital signatures[!], which became the main authentication mechanism after passwords [12].
Despite the problems brought by distribution, new possibilities for security were opened since code and data could now be physically isolated. This meant that untrusted users could be totally separated from each other and from untrusted users. This cannot really be achieved in centralized systems since operating system kernels contain too many residual covert channels.
Today, the Internet is the computer. The Internet bri.ngs further.problems for security. The openness of the network means that one can never identify all users who may need to gain access to a service. In any case, several electronic shopping services that run on the Internet require that a client's identity can never be revealed (anonymity). This means that the notion of authentication must be revisited [8]. Another problem is that there are many authorities in the Jnternet system. This means that a public key possessed by a user might have to be certified by a recognized authority before acceptance [13, 9], and even that authoritymust be certified with another (the so called "trust chains"). As already mentioned, adding mobile agents to the Internet equation creates problems of its own.
Though mobile agents pose security problems, they do allow one to exchange code as well
as data over the network. A security architect in a positive frame of mind would see this as the basic building block on which to base security: Agents carrying computations to secure remote servers for execution. One cannot separate mobility from the mechanisms needed to secure the Internet.
2.4 Simple Set of Mechanisms
Many security concepts have now become standard. All system developers understand the notions of capabilities, access control lists, authentication, certificates, etc. All of these have served important purposes in architectures in the past. The set of security concepts available to designers has become quite large over the years and arguably, some concepts are poorly adapted to mobile agent systems.
One example of this is a certificate [9]. This is a signed message which says that some user Uhas public key k. The message is signed by a certificate authority that someone verifying the signature trusts. A signature is thus used to verify the binding of a user and his public key. "1 'his notion of certificate was introduced in (message passing based) distributed systems as a means of assuring users that parties were not forging digitally signed messages using stolen keys.
One problem with a certificate is that it is simple data unit. There is no reason why code cannot be added to the certificate to represent it as a program. In this way, one can have a certificate that validates a key binding as a function of its environment, its client, etc. The important point is that the validity of a binding is also an application specific policy. Further, since a certificate must be mobile, as it must be accessible to all who wish to validate the key, it can naturally be represented as an agent. Another reason for revisiting the certificate concept is that user-key bindings are not the only bindings that need to be verified in an Internet context. One would also like to verify bindings such as purse-to-money, user-to-capability, ISP- to-QoS promise. This is another reason for a more.general purpose certificate notion, which is best offered by representing the certificate as a (mobile) code unit. Thus, while the notion of certificate is not redundant, defining a basic static certificate format that a security architecture must implement serves little purpose. The same argument can be made against data-centered access control mechanisms like capabilities and access control lists.
Another example of a security concept that has problems adapting to the Internet world is authentication, defined as the process of verifying the identity of a principal that seeks access to a service. There are too many users in the Internet to be able to identify all individually.
Further, many electronic commerce platforms require anonymity for buyers at least for small amounts. Though it is crucial to determine what privileges an agent should be granted, there is no uniform way of obtaining this information [7], and so a basic security architecture might not need to encapsulate such a notion. For instance, authentication in Java 1 involves determining if an applet is local or remote and ensuring that its code is well-formed [ 4]; Java 2 extends this by verifying the identity of the code signer and sending site's URL. Authentication servers such as [20] of course have use in localized contexts. What is required of the security architecture is that it be able to securely exchange messages between a user and "authentication" service.
Many concepts in security can be redefined in the context of the mobile agent based Internet.
c.
Bryce 225 In this paper's framework, we look at a security architecture with minimal security mechanisms.In fact, the only security concept is the agent itself and the messages they exchange. A message can be the name of another agent, or a simple text string. All other security protocols must be progranuned over this. Thus, a password in this context is either represented as a text string, or is encapsulated inside of an agent and is referenced by the agent's name.
3 The Agent-Based Security Architecture
This section defines a security architecture that uses only agents to provide security. We first explain the basic agent model assumed for the system, and then explain what is meant by security in this architecture.
3.1 The agent model: places, agents and messages
The Internet application executes over a set of inter-connected sites or places. An agent is an autonomous program that accesses resources locally at a place; when it needs to use resources at another place, it migrates to that place [27]. Some agents at a place are system agents: these do not move and typically offer services such as storage, GUI, etc. [l 7].
A says m to B A moves to Pas B A Requests C from P new A a
start Terminate A
The set of actions that an agent can execute are listed in this table. At each place, agents exchange messages with one another and with their environment through the says action where m is the message exchanged. A and B are agents, or one of them is the local environment, denoted Env.
There are two base component types of messa~es: simple text strings and Names. A text string is not intexpreted by the environment. For instance, a password exchanged between a visiting agent and its hosting site can be represented as a string or as (the name of) a mobile password object that contains the password string. A name denotes an agent or place and it is evaluated in the current environment. Thus the name stdio at place client can refer to a different agent to that named stdio at place server. A message can also be some sequential combination of names and strings, but nothing more.
Agems are mobile meaning that they can move or be moved between sites. This is done using the moves action where agent A moves to place 'P and is named B there. When a new agent is required by an agent at a site, it can ask for it with the Request action. This means fuat agent A requests that the agent named C resident at place P be sent from place P to the current environment. This might be useful for instance to down-load a certificate (agent) if the
executing agent is involved in some authentication step. Recall that a certificate not just be some static data structure, but a program that executes. The Request action of course can be modeled by a move and a says but it is included for conciseness in agent policies.
Two actions are supported by the architecture for agent startup. The first is start and is executed by an agent on its initialization. It is the signal to the agent that it has just been created.
The new action creates an agent of a specified kind A that becomes named a. An agent's kind specifies the behavior of an agent in the same way that a class describes the behavior of an object. We will return to this feature in the subsection on security where an agent's kind is simply the set of policy rules defined for the agent.
The final action of the agent architecture is Terminate A .which kills an agent named A in the current environment. Only the environment can execute this command.
3.2 The meaning of security
There are two questions to answer about security in Uris sysli.:111. First, how can the notions of agents, places and messages be used to provide a fully fledged security architecture. Second, what security guarantees can the resulting architecture give. This section looks at these two questions.
Police agents
The only abstractions offered by the architecture are places, agents and messages and all secu- rity information is represented in this form. For instance, an access control policy attached to the file system is represented as an agent that communicates with the environment using mes- sages and is consulted when a visitor agent attempts to access a file. A code verifier belonging to the environment is also represented as an agent: when a visitor agent arrives, the name of this agent is passed to the verifier in a message. The verification takes place and the verifier will reply with the string messages "accept" or "reject". The internals of agents are not important here.
In this situation, there are numerable ways in which police agents can be employed to enforce security. Some examples of this .include:
• Traffic control agents are typically a class of agents used to protect services at a site from visitor agents. They fulfill access control and authentication like functionality. They can be provided by the owner of the server or by a third party. In an electronic commerce environment, they would be used to inspect the credentials of visiting agents, contain code verifiers or encapsulate a challenge response scheme.
• Mediation agents are used for resolving a dispute in a security sense. For instance, they can correspond to public key certificates or a mediation procedure of an electronic com- merce protocol [28]. Typically, they are used indirectly or in exceptional circumstances.
• Controller agents survey events in the system; they fulfill an audit like role in the sys- tems. In electronic commerce platforms for instance, logging of user actions is important
c.
Bryce 227in order to maintain consumer and supplier black-lists. This is also an example of agents being used for "off-line" operation. Another use of controller agents in an Internet con- text is for collection of usage statistics; this is important for detecting attacks based on analysis of usage patterns.
Many other examples of police agents can be programmed. Nonetheless, what is important from a security point of view for police agents and for all agents is how they are programmed for security. That is, what an agent security policy means.
In a standard operating system, a file's security policy is a list of access constraints govern- ing use of the file. In the Internet, given the kinds of security dangers that we mentioned, an important component of a security policy is risk or trust analysis. An agent assigns access rights to a second agent based on the latter agent's reputation or on checks (results of code analysis, digital signatures) furnished.
Agent security policies
At the basic level, an agent programmer must ensure that his agent can "decide" whether to trust its neighbors, or if moving to a site is a safe option. For instance, on arrival at a place, an agent and the place environment exchange messages. Based on this each assign each other a trust level or access group. Assigning a group is represented by the following action:
A becomes G
meaning that the agent assigns group G to the agent named A in its current environment. In a similar way, the action
A's group is G
indicates to the executing agent if the agent locally.named A possesses group G.
Each agent and place maintains its own list of groups. This is the first part of an agent's security policy kind. An agent can change the group that it attributes to the environment or other agents depending on the messages it receives and actions it observes in the system. This changing (via the becomes action) is the second aspect of a security policy kind. An agent's security policy kind is thus a set of rules that define how groups change. A rule defines what actions are taken in reaction to some event that is also an action. For instance:
A moves to S A becomes UNTRUSTED
is a security policy rule that states that when the enclosing agent observes the action of agent A moving to place S, then A is attributed the access group UNTRUSTED by the agent.
There are two main reasons for expressing policies in this form.
• Policies are described in an event-driven style. This seems a convenient programming model for agents in general since they are software units they must know how to "react"
to events they encounter on the network. Further, it neatly models the evolution of the security state of the system: An action that an agent observes provokes a reaction, which is observed as an action in another agent, etc.
• More importantly, our goal is to define a meaning for the security of the application.
An agent is considered secure in this context if it does not find itself at a place which becomes untrusted. We would later like to investigate using the policy rules as a form of access control logic [16], where the rules could be analyzed to deduce if a security hole or contradiction in the policy exists. As an example, if the agent with the above policy is moved by its environment (policy) to S, one can deduce that the agent's security is broken. Similarly, an analysis is needed to help make a policy developer answer questions such as "what happens when the agent moves to a srte other than S?".
Simple Example A user wishes to compress a file of his that is stored on a server. However, the user does not trust the local network and prefers to send the compression program in an agent to the file server which does the compression lhere. In this way, rile is ntiver exposed on the network. Of course, the compress program can be corrupted on the network but the user assumes that the environment can verify sufficient integrity properties of the code down-loaded (e.g., via a code signature). Alternatively, the user could have th.e file contents encrypted while it is on the network, but why encrypt contents when one can transfer the compress program?
The former solution requires two network transfers of a whole file instead of a single transfer of a program. Both compress and file arc encapsulated as agents. The two places are client and server. The file agent policy kind ha5 two groups: FOREIGN and FRIENDLY. The file policy is programmed to survey the environment in which it resides, to ensure that it remains FRIENDLY.
There are three security rules in file's policy (kind):
and,
and,
Self moves to client Env becomes FOREIGN
compress says "password" to Self, Env's group is FRIENDLY, Env's compress group is FRIENDLY
compress become$ FRIENDLY
start
Env becomes FRIENDLY
The part of the rules above the lines capture an event action, and some predicates that must be satisfied for the rule to fire. The actions below the line are reactions that occur when the rule is fired. The meaning of the first rule is as follows. When the (action ot) the enclosing agent moves to the client place, the agent assigns the group FOREIGN to the environment. This rule
c.
Bryce 229captures the fact that the file considers any environment other than the server place as unsafe.
The second rule governs the interaction between the compress agent and file. The event is that of the compress agent sending the awaited password, which in this case is the string
"password". This action is only fired when the environment is trusted and compress has been authenticated (is trusted) by the environment. Once fued, the rule states that the compress agent is assigned the group FRIENDLY. The third rule states that file trusts the environment that creates it. Of course, this policy rule may contradict the first of the policy rules since it is not clear what the group assigned to the environment of files created on the client should be. The rules should therefore be usable as a basis for detecting policy inconsistencies. This is the type of problem that motivates a more logical interpretation of the policy rules, as done for access control logics [ 16). On arrival at a site, an agent must authenticate itself to the file; this is modeled with the following rule which is part of compress 's policy.
Self moves to Server Self says "password" to file
4 Semantics of the Architecture
So far, a security architecture has been defined, based on agents, messages and places. The goal of this section is to define the semantics of this architecture.
An agent's or place's security policy is a set of rules r of the following form.
8
AA is an event action and set of predicates that define when the rule can be fired. B is a sequence of actions, or reactions. This classification of actions as events and reactions is important since the meaning of an action is slightly different depending on whether it is an event or reaction.
We therefore start the section with a more comprehensive though informal explanation of action semantics. In the remainder of this section, the upper part of the rule is denoted dom(r); the bottom part of the rule is ran(r). Thus, in the above policy ruler, dom(r) is A and ran(r) is B.
There are two parts to the semantics. The first concerns naming and is a set of rules that say when two messages are equal, and when two names refer to the same agent or place. The second part of the semantics governs policy rules firing. That is, when an agent with policy p1
"comes into contact
with"
(denoted by o) an agent with policy p2, we need to lrnow when the reaction of p1 can fire the event of 'P2·exec(p1), P {P1 o P2} Q, P
OQ
In this rule, the effects of p1 firing p2 is described by Pr o p2 ; the relation between predicates P and Q is defined on the agent and name spaces. The predicate exec(p1) means that the action P1 is pending, and must now execute. The rule states that if the state satisfies P, then firing happens and the next state (denoted by
0)
satisfies Q.4.1 Informal semantics
4.1.1 Naming
There are two aspects to naming in the security architecture. First, a name refers to an agent or a place, and can be contained within a message. Second, a name is always evaluated locally, in the context of the hosting place environment.
There are two reserved names: Self which denotes the agent or place in which the action that uses the name executes, and Env which denotes the envirorunent of the current place. That is, A says m to B is really a short form for Env's A says m to Env's B. In a similar way, A moves to P is really a short form for Env's A moves to Env•s P, meaning that the agent denoted by A in the current place is moved to the place denoted by the name P in the current place.
1bis generalizes for naming agents in other environments. For instance, Q's A refers to the agent named A in the place that itself is denoted by Qin the current Env. P's (Q's A) is the agent named A in the place named Q in Env's P2 •
As mentioned, the two reserved constant names are Env and Self. The file compression example of the preceding section used the local names Server and client. Names in action statements can be local or free variables. When free variables are used for names, the names are free in event statemen.ts and bound in the scopeofreaction statements. For .instance, suppose that in the execution of the system, the policy P1 (where dom(P1) is A and ran(P1) is B) fires policy P2 (where dom(P2) is C and ran(P2) is D), then the agents boun.d to free variables of reaction statements B become bound to matching free variables of C, which are then in tum bound within the scope of D.
4.1.2 Action statements
Requesting agents is done using the action:
P1 Requests A from P2
as an action statement means that the place named P1 in the current environment makes a re- quest for the agent locally named A. In this case, P2 is Env, and the statement can be shortened to P1 Requests A. Wb.en the statement is a reaction statement, it means that the enclosing agent asks the site named P2 in the current environment to send the agent named A in the current en- vironment. This can be written in short form Requests A from P2 since P1 must be ENV.
Recall that names are always evaluated locally. In this example, A can be P2 's B to indicate that the agent named B in th.e destination environment is requested.
Agent migration uses the action:
A moves to P as B
20f course, P's (Q's A) is a short form for Env's P's (Q's A).
c.
Bryce 231 When this is an action statement, A can be Self, meaning that the current agent moves to P.Alternatively, P can be Env and B denotes the new name of the agent. The moves to primitive as a reaction statement means that the agent locally named A is migrated to the place named P in the local environment. The as clause is not used.
Other actions have intuitive meanings. Agents at a place communicate with each other by exchanging messages. The statement has the format:
Asaysm to B
where A and B are agents, and m is a message. A messages is any sequence of Strings and names. The meaning of names has already been informally explained; Strings are not inter- preted.
Concerning groups, each agent or policy type bas a personal list of
its
groups. The two statements introduced were A becomes G and A's group is G which set and test the group G accorded by the encapsulating agent to the agent named A in the current environment.Agent termination is captured by the action Terminate A; the environment teoninates the agent locally namedA. The two creation actions are start and new A a. The former is an event action executed by an agent on its Startup. The latter creates an agent of kind A and names it locally as a.
4.2 The semantics of security
Naming
The system houses a set of agents (O'i E E) and a set of places (pi E P). Each agent and place has a local name space, Ins that maps names (n E N) to agents (or places). A binding in the name space may map a name to an agent or place, or map the name. to another name or compound name. Thus, the binding n 4 u in a space means that the name n in that space is bound to an agent
u.
An entryn
Hm
means thatn
is bound to the agent/place denoted bym
in the space. The name m can be a compound name, represented as a sequence, e.g., ( ni, n2 , n3) meaning that th.e namen
is bound to the agent or place denoted by the namen
3 in the place named n2 by the place named n1 in the current local name space.Each agent has a place of execution - its current environment. This is also part of the system state, place: (I:
u
P) -t P. A place is its own place, i.e., place(p) = p. The function is important since each place interprets names for agents in that place. Thus the local name space of an agent is that of its place: lns(u) = lns(place(u)).The first part of the semantics governs name interpretation. For this a function eval is used, which maps names to agents or places (N x (P U E) -t (P U L:)). Name interpretation relies on the local place. Thus eval(n, u) = evalp(n, lns(u)), where
evalp(n, s) = p ifs= s'
u
(n H p)evalp(n, s) = evalp(m, s') iflns(p) = s' u (n H m)
evalp(n, s) = evalp(q, lns(evalp(p, s'))) ifs= s'
u
(n t-+ ( p q )) evalp(n, {}) =freeand for the two reserved names:
eval(Self, o") = u eval(Env, u) = place(u)
Note that the name p sq is represented proper!~ as (p, q}. Names are equal if they refer to the same agent
w
place. Thus the name n1 in agent or place a is equivalent to nz in an agent b if eval(n i, a)= eval(n2, b).Messages are composed of sequences of strings and names (ai. t121 ••• ,a,.). Two messages ml and m2 interpreted in places p1 and p2 respectively are equal, denoted eval(ml , p1) = eval(m2, P2) if eval(a1, p1) = eval(a1, P2) for each message entry a;. For a strings, eval(s, p;) is its alphanumeric value which does not depend on any context Pi·
In order to implement security policies, each agent locallymaintruns a &l'OUp for each agent name
in its
environment. This is represented by the funchon group (of type:N x
E->
Group);thus, group( A, u) is the group that agent u assigns to the agent named A in its current environ- ment.
Actions
Actions and the reactions that they fire are perceived as occurring simultaneously. That is, a reaction provoked in one agent is perceived as an event action in another agent. We say that the former action a.fires the latter b. This is denoted as a ob. For instance, the action new A a as a reaction event fires the action event start in the created agent. The two agents might even be the same; for instance, typically a move reaction has a corresponding event action in its policy kind.
Firing is the key element of the semantics of the architecture. The following are a set of axioms and rules that capture this.
The first is an axiom that covers new A a o start:
P[eval(a, process(new A a)) r process(sta.rt), Er E u process(start), place(process(start))
r
place(process(new A a))]{(new A a) o (start)}
p
Thi.s axiom states simply that if a predicate
P
holds after agent creation, then the same predicate must bold beforehand with the name binding for a in the creating process replaced with the name of the new process. Similarly, the bindings of the place state function are updated to account for there being a new agent at th.e same place as the creating agent. The executing agent or place of an action a is denoted process( a).Message exchange via the says statement as an action fires a says statement as a reaction.
c.
Brycelet p1 =A says m1 to B, let fJ2 = C says m2 to D, eval(B, process(p1)) = eval(D, process(fJ2)) eval(C, process(fJ2)) = eval(A, process(p1)) V free eval(~
I
mi. process(fJ2}) = eval(mi. process(p1})P[eval(C, process(fJ2)) t-eval(A, process(p1)), eval(m2, process(fJ2)) t-eval(m1, process{p1))] {P1 o p2} P
233
The first pre-condition specifies that the sender is talking to the receiver, i.e., that B evaluates to the second of the agents. The second precondition says that the receiver is waiting for a message from the sender, or that the receiving agent can accept a message from any agent (its C variable is free). The message m2
I
m1 is the message where free variables in ~ are bound to corresponding name variables in m1. The rule states !hat the free names in the receiving agentare
bound with the corresponding names in the si;nding agent, and that the name variable C becomes bound to the sending agent.A move action executed at some place fires a corresponding move action at the destination place.
let p1 = A moves to B, let P2 = C moves to D as E, eval(B, process{p1)) = eval(D, process(fJ2)) eval(C, process(fJ2)) = eval(A, process(p1)) V free
P =* Q[eval(A, process(pi)) f-null, place(eval(A, process(p1))) t-place(process(p2)),
eval(E, process{P2)) t-eval(A, process(p1))]
P{p1 o P2} Q
In the rule, the first pre-condition captures the fact that the first action fires the second. The null denotes the empty binding, and the final pre-condition captures the removal of an agent from the source environment and its placement in the destination enviro.nmentunder the name E.
The requests action fires a similar request in another process.
let p1 = A requests B from C, let fJ2 = D requests E, eval{C, process{p1)) ·;,, process(fJ2) eval(D, process(fJ2)) = eval(A, process(p1)) V free eval(E, process(P:!)) = eval(B, process(p1))
v
fee P[eval(D, process(fJ2)) t-eval(A, process(p1)),eval(E, process(fJ2)) t-eval(C, process{p1))] {p1 o fJ2} P
The terminate command does not fire any action but has the effect of removing an agent.
Note that only the environment may issue this action.
let p = terminate A place(process(p)) = process(p)
P[eval(p, process(p)) t- null, .Et- .E \ process(p)] {p} P
The final two actions deals with the security groupings of agent policies. From lhe preceding section, we have:
Lastly,
A's group is G ~ group(A, process(A's group is G)) = G
let p = A becomes G P
=>
Q[group(A, process(p)) ~ G]p {p}Q
Security Architecture Execution
The evolution of the security architecture can now be explained. An important primitive for this is exec(a.) which means that the action a is pending and must now be executed. Typically an action must execute when it is a reaction to an event action. An agent's reaction to an event could be a sequence A of actions. When a sequence of actions is pending then each action must be consecutively executed.
exec({a, A)), P {a} Q
O
(Q /\ exec(A))The key aspect of the security infrastructure is that the execution of an action within an agent provokes the execution of the reactions associated. Names that are free in the reactions are bound to names in the event action.
P /\ exec(domp), P {domp} Q Q(Q[ran p
I
dom p] /\ exec(ran p))The security architecture evolves through firing; an action in an agent provokes an action in other agents. Suppose that a policy rule p1 fires a policy rule P2· Note how the free variables of the fired event are bound to names in the firing event. The definition of P {ran p1 o dom P2} Q was given in the paragraph on actions.
P /\ exec(ran P1), P {ran P1 o dom P2} Q Q(Q[dom P2
I
ran pi] /\ exec(ran P2))fu any state, several actions may be pending for execution. When these actions are indepen- dent, then the following rule governs parallel interaction. 1\vo actions are independent when they have no names in common. This means that the actions effected by agents are independent.
Firing is one example of actions not being independent.
i = l..n, P;
{a;}
Q,P1 /\ P2 /\ ··· /\ P n { 31
II
32II ··· II
lln } Qi /\ Q2 /\ ··· /\ Qnc.
Bryce 2355 Example
This small example is taken from the HyperNews system [ 17]. This is an agent platform for selling on-line newspaper articles. A user that reads an article of a news provider must first present a payment of receipt to show that he has paid the provider for that article. Once the article accepts the receipt, the article allows the user to ha:ve access to the contents. A receipt of payment is verified by the article creating a billing agent, and sending that agent to the bank.
This system employs agents to exploit the benefits·of off-line operation: an article can be read and paid for, without having to go on-line to the provider site. The places that agents visit in HyperNews are the Consumer and Bank sites; these are both constant names.
The goal of this example is to qualify the trust chains involving the article, in order to verify that an article does not enter into a non-anticipated trust state, where its data can be read or modified by non-authorized entities in the system.
The Article kind The article kind has three access groups for its environment: MY PROVIDER, PREPAID and CLIENT. The first is assigned to the creating environment, the second to a con- sumer environment that has not yet paid for the article and must therefore not have access to the contents, and the third to a consumer environment that has paid, and into which the article contents can be released.
Kind Article
I* Local variable names *I String Contents;
Billing b; !•Another kind of agent*!
Place creator;
I* Policy Groups *I
Groups= {PREPAID, CLIENT, MYPROVIDER}
start
creator= Env; Env becomes MYPROVIDER
s Requests Self from Env Self moves to s Self moves to s s becomes PREPAID
User says "open" to Self, Env's group is PREPAID new Billing b; b moves to Bank
b says "paid" to Self Env becomes CLIENT
User says "read" to Self, Env's group is CLIENT Self says Contents to User
End Article.
The set of rules in a HyperNews article policy are the following. The creating environment is the provider environment for the article, and the first rule covers this. Once created, the article awaits requests from consumers. This is covered by the second rule; note that the article can be anywhere when the request is made. On arriving, the article will not divulge its contents, until a payment has been made: The article is in a PREPAID state and awaits a command to open itself. At that point the article creates a billing agent that is currently sent to the provider.
On returning to the consumer, the billing agent indicates to the article whether the user has al.ready paid for the article or whether he has enough money to pay for the article. Finally, the article only replies to read requests from an environment if a payment has been made: this is the meaning of the 5th and 6th rules given.
With respect to security, it is clear that the security of article depends on the correctness and security of the Billing kind, and on the environme£!t to ensure that no other agent ever uses the name b; no other agent can therefore impersonate the article's billing agent and attempt to give a false reply. Thus, the article doe"s all it can to en~ure thP. i::r.r.nrity of its contents.
6 Related Work
Section 2 over-viewed several areas of distributed systems that exploit mobile agent technology, from electronic coJIUnerce [24, 17] to active networking
L3,
22), to system management [15).Exploiting these benefits for security is an issue hardly toucb.ed. Ironically, mobility is ex- ploited everyday for security; one example is the login applet sent to a user when he tries to access a remote server. Another example is the HyperNews system, where a mobile document encapsulates its own access control policy.
Related to the work in this paper are distributed security architectures like SDSl (Simple Distributed Security Infrastructure) [18). SDSI identifies the-least set of elements for enforcing access control and authentication in a wide-area distributed system. This paper's goal is to identify a minimum set of mechanisms for securitY .in a distributed application based solely on agents. There are some features in common: principals in SDSI, which correspond to agents here, execute inside of local name spaces. SDSI also has global names which are not present here.
PolicyMaker was the first system to question the role of certificates as simply validating the user to public key binding [8]. In PolicyMaker, a certificate verifies a user to capabil.ity binding. Jn this paper the notion of certificate is taken a step further since it is a programmed agent that executes on behalf of a third party. This means that it can be used to verify any binding that needs to be confirmed by a trusted third party. Examples of these bindings include the binding of an access control police agent to an environment, the binding of a sum of money to an agent's purse, the binding of a capability to an agent, as well as the binding of a key to a user. Moreover, all static data structures - capabilities, ACLs and even keys - may be extended .in this manner.
c.
Bryce 2377 Conclusions
This paper has argued that mobile agents provide benefits when used as a structuring unit for security architectures, despite the well-publicized problems that they pose. It helps to accentu- ate the positive. A security architecture based solely on agents was then presented as a means of pushing this argument to the limit.
Current work includes providing programmed police agents within the HyperNews sys- tem [ 17]. Also, we would like to broaden the scope of the semantics to a security logic that can be used to reason about the security of age.nts in some configuration. This is similar to work on access control logics [ 16]. These formalize the access control rules of a policy in the aim of isolating back door access to infonnation. In this paper's framework, we seek a similar way of ex.pressing agent security policies in the aim of detennining whether migration is a safe option in a given context. This requires an analysis in th.e style of[2, 16].
References
[1] L. Adleman, R. L. Rivest, and A. Shamir. A method for obtaining digital signature and public-key cryptosystems. Communication of the ACM, 21(2), 1978.
[2] C. Arapis. A Temporal Logic-Based Approach for the Description of Object-Oriented Behavior Evolution, volume 7 of Annals of Mathematics and Artificial Intelligence. J.C. Baltzer AG, Science Publischer, 1993.
[3] W. A. Arbaugh, J. R. Davin, D. J. Farber, and J. M. Smith. Security for virtual private intranets.
Computer, 31(9):48-56, Sept. 1998.
[4] K. Arnold and J. Gosling. The Java Programming Language. The Java Series. Addison-Wesley, Reading, MA, second edition, 1998.
[5] N. Asokan, E. V. Herreweghen, and M. Steiner. Towards a framework for handling disputes in payment systems. Research Report RZ 2996, IBM Research, Mar. 1998.
[6] J. Baumann, F. Hohl, K. Rothermel, M. Schwehm, and M. Stra6er. Mole 3.0: A Middleware for Java-Based Mobile Software Agents. In Proc. Middleware '98. Springer Verlag, 1998.
[7] S. Berkovits, J. D. Guttman, and V. Swarup. Authentication for mobile agents. Lecture Notes in Computer &ience, 1419:114-122, 1998.
[8] M. Blaze, J. Feigenbaum, and J. Lacy. Decentralized trust management. In SympSecPr, Research in Security and Privacy, Oakland, CA, May 1996: IEEE Computer Society,Technical Committee on Security and Privacy, IEEECSP.
[9] CCITT. X509, the directory - authentication framework, Nov. 1987.
[JO] D. Chess, C. Harrison, and A. Kershenbaum. Mobile Agents: Are They a Good Idea? Technical Report RC 19887 (December 21, 1994 - Declassified March 16, 1995), IBM Research Division. T.J. Watson Research Center, Yorktown Heights, New York, 1994.
(http://www.research.ibm.com/massdist/mobag.ps).
[11] R. A. DeMillo, D. P. Dobkin, A. Jones, and R. J. Lipton, editors. Foundations of Secure Computa- tion. Academic Press, New York, 1978.
[12] D. E. Denning. Digital signatures with RSA and other public-key cryptosystems. Communications of the Association for Computing Machinery, 27(4):388-392, Apr. 1984.
[13] S. Garfinkel. PGP: Pretty Good Privacy. O'Reilly & Associates, Inc., 103a Morris Street, Se- bastopol, CA 95472, USA, Tel: +I 707 829 0515, and.90 Sherman Street, Cambridge, MA02140, USA, Tel: +1617 3545800, 1995.
[ 14] L. Gong. Java security: Present and near future: Coping with the rapidly evolving security issues ofcross-platfonn computing. IEEE Micro, 17(3):14--21, May/June 1997.
[15] R. S. Gray, G. Cybenko, D. Kotz, and D. Rus. D'Agents: Security in a multiple-language, mobile- agent system. In G. Vigna, editor, Mobile Agent Security, Lecture Notes in Computer Science, pages 154-187. Springer-Verlag, 1998.
[16] B. Lampson, M. Abadi, M Burrows, and E. Wobbcr. Authentication in distributed systems: Theory and practice. ACM 1'rm1sacrions m1 rJJmpwP.r Sys/P.n•~, I 0(4):265- 310, Nov. 1992.
[17) J.-H. Morin and D. Konstantas. Hypemews: A MEDIA application for the commercialization of an electronic newspaper. In Proceesings of SAC '98 -The 1998 ACM Symposium on Applied Computing, Marriott Marquis, Atlanta, Georgia, U.S.A, Feb. 27 - Mar. 1 1998.
[18] R. L. Rivest and B. Lampson. SDSI-A simple distributed security infrastructure. Presented at CRYPT0'96 Rumpsession, Apr. 1996. SDSI Version 1.0.
[19] T. Sander and C. Tschudin. Towards mobile cryptography. In SympSecPr, Research in Security and Privacy, Oakland, CA, May 1998. IBEECSP.
[20] J. G. Steiner, C. Neuman, and J. l. Schiller. Kerberos: An authentication service for open network systems. In US.ENIX Association, editor, USENIX Conference Proceedings (Dallas, TX. USA) , pages 191- 202, Berkeley, CA, USA, Winter L988. USENIXAssociation.
[21) A. S. Tanenbaum, R. van Renesse, H. van Staveren, G. J. Sharp, S. J. Mullender, J. Jansen, and G. van Rossum. Experience with the amoeba distributed operating system. CACM, 33(12):46-63, Dec. 1990.
[22) D. L. Tennenhouse, J. M. Smith, W. D. Sincoskie, D. J. WetheraU, and G. J. Minden. A survey of active network research. IEEE Communications Magazine, 35(1):8H6, Jan. 1997.
[23] W. Theilmann and K . .Rothennel. Domain experts for information retrieval in the World Wide Web.
In M. Klusch and G. Weill, editors, Proceedings of the 2nd International Workshop on Cooperative Information Agents U: Leaming. Mobility and Electronic Commerce for lnfom1ation DiScovery on tile Internet, volume 1435 of LNAI, pages 216-227, Berlin, July 4-7 1998. Springer.
[24) van der Merwe and von Sohns. Electronic commerce with ~ure intelligent trade agent. In ICIS:
International Conference 011 Jnfonnolion and Communications Security (ICJS), LNCS, 1997.
[25) G. Vigna. Cryptographic traces for mobile agents. Lecture Notes in Computer Science, 1419: 137- 149, 1998.
[26] G. Vigna. Mobile agents and security, volume- 1419 of Lecture Notes in Computer Science.
Springer-Verlag lac., New York, NY, USA, 1998.
C. Bryce 239 [27] J. Vitek and C. Tschudin. Mobile Objects Systems. Springer Verlag, Berlin, 1997.
[28] M. Waidn.er. Development of a secure electronic marketplace for Europe. In E. Bertino, H. Kurth, G. Martella, and E. Montolivo, editors, Proceedings of the Fourth ESORICS, LNCS, Rome, Italy, Sept. 1996. SV. also published in: EDIForum 9/2 (1996) 98-106.
[29] B. S. Yee. A sanctuary for mobile agents. Technical Report CS97-537, UC San Diego, Department of Computer Science and Engineering, Apr. 1997.
