Components of a security architecture

The previous sections already gave an idea of necessary components and services to build a security architecture for mobile agent based management systems. Figure shows this architecture with major dependencies between components during the life cycle of an agent.

It is obvious that many parts will depend on cryptographic functions based on symmetric and asymmetric keys to encrypt and sign data. Therefore, a security architecture should integrate a cryptographic library in its base services. Certainly, existing libraries should be used whenever possible. As usual, with asymmetric key functions it is necessary to have a safe and reliable key management and distribution. In order to be able to assign rights to identities there is also a need for a trust center that certifies accreditation of identities including agent systems.

  

Figure: Security Architecture

Security must also have implications on the general design and architecture of agent systems. The agent system must be able to protect itself and access to the host system. The development of Java [#!gmps97!#] shows that this must start with the programming language and includes concepts like sandboxes and virtual machines. They provide a locked, secured run-time environment for mobile agents that prevents any action out of control of the agent system. Each mobile agent running has its own sandbox that no other agent can directly access. Therefore, the agent system must be designed with security in mind. If not, it will not be possible to implement secure access control and security boundaries.

In order to prove integrity it is not sufficient to simply check some signatures. As mobile agents can visit several places integrity must include all computations since initiation. As any place inbetween may tamper with signatures added before, checking integrity may require doublechecking with a logging or integrity service.

Rights are the concept to properly use and exploit access control mechanisms. As already mentioned before the main components for establishing and handling rights are authentication and authorization. They depend on the basic concepts of rights like subject or object-based access rights, i.e. whether subjects carry access rights or objects have access lists. Moreover, the access control and resource constraining capabilities of the agent system must be instrumented to suit the concept of rights.

If agents are able to delegate rights everything gets more complex. With rights being `movable', an entity may try to steal rights. This makes clear that delegation is not just a local matter between two agents and an agent system. On the contrary, an independent and trusted delegation service must probably mediate and enforce delegated rights. In addition, the conceptual design of rights must reflect delegation.

The problems of non-repudiation are similar to but more general as delegation. While delegation is only about rights non-repudiation is about any operation. These parallels may lead to some synergy between both problems. Similar to delegation non-repudiation requires a third-party non-repudiation service that records any operation that might be subject to repudiation. Moreover, it mediates in cases of repudiation proving who was responsible for actions recorded.

Configuration management of all components and services mentioned as well as of the agent system in general is an important task to establish and maintain a high level of security. Policies define a general outline of these requirements. Therefore, a policy component must enforce policies on agent systems. It parses policies and configures the system and the rights of agents.