Trust Management Systems

The trust management approach to distributed system security was developed because of the perceived inadequacy of traditional authorisation mechanisms for distributed systems (Blaze, Feigenbaum et al. 1996). Traditionally, every application implemented its own mechanisms for specifying access policy, checking compliance, and binding user authentication to authorisation to perform security-critical operations. This approach exposed the security of the application to high levels of risk because an application developer might make simple but subtle mistakes in the design and implementation of the system. The main aim in the development of trust management systems is to produce an off-the-shelf security module that can be integrated into any application, specifically as

a solution for access control in large distributed systems. The module allows each application to define application-specific policies and credentials.

Blaze et al. (Blaze, Feigenbaum et al. 1996) describe trust management as a ‘unified approach to specifying and interpreting security policies, credentials, relationships which allow direct authorization of security-critical actions.’ The notion of a ‘resource’ that a security system is designed to protect varies widely across different distributed systems. They recognised that the system should be able to define what a resource is within its local environment. The next step is to allow the system to define access and restriction policies that apply to its resources. Policies and credentials can be modified to reflect changes in the usage patterns of the system over time. Current trust management solutions include PolicyMaker, KeyNote, REFEREE, the IBM Trust Establishment Framework, and the SULTAN toolkit.

The solution proposed by Blaze et al. (Blaze, Feigenbaum et al. 1996; Blaze, Feigenbaum et al. 1998) in their trust management system, PolicyMaker, is to bind a set of specific keys directly to authorisation to perform a specific task, i.e., a credential. PolicyMaker takes as input a set of local policy statements, a collection of credentials, and a string describing a proposed trusted action. Acting as a query engine, it evaluates whether the credentials prove that a requested action complies with local policy, which is a trust assertion that is made by the local system and is unconditionally trusted by the system. The fundamental question that the trust management system asks is ‘Does the set, C, of credentials prove that the request, R, complies with the local security policy, P?’ The request, R, the local policy, P, and the set of credentials, C, are passed to a trust management engine, which processes the request and outputs an authorisation decision as to whether the request and credentials provided are valid according to the local policy. Moreover, PolicyMaker provides a general-purpose, application-independent algorithm for checking proof of compliance. Applications using the single general-purpose compliance checker in a distributed system can be confident that results from the checker are correct. This reduces the need to have each resource in a distributed system implement its own compliance checker.

KeyNote, the successor to PolicyMaker, addresses further design goals, i.e., easier integration for applications and standardisation (Blaze, Feigenbaum et al. 1999). KeyNote assigns more responsibility to the trust management engine, i.e., signature verification and use of a specific policy assertion language, rather than to the calling application, making it easier to integrate into applications. It requires that assertions (policies and credentials) be written in a specific language, so that processing by the compliance checker proceeds more smoothly. The application passes an ‘action environment’ to the KeyNote tool. This is similar to the PolicyMaker ‘query’ in that in contains three elements: the security policy, a list of credentials, and the proposed action. KeyNote’s response to the action environment is an application-defined string. In the simplest case, the result would be ‘authorised.’ KeyNote, like other trust management engines, does not enforce policy directly - it only provides advice to applications that call it.

The Rule-Controlled Environment for Evaluation of Rules and Everything Else (REFEREE) is a trust management system that makes access control decisions related to web documents (Chu, Feigenbaum et al. 1997). Based on PolicyMaker, REFEREE is a query-engine that may be integrated into a host application to evaluate proposed action requests. It interprets trust policies and returns a tri-value (true, false, or unknown) and statement list. ‘True’ means that the requested action is approved because sufficient credentials were supplied, ‘false’ means that the requested action is denied, and ‘unknown’ means that the supplied credentials were insufficient to approve or deny the requested action. The statement list provides the context for the decision and a justification for the answer. All statements are ‘two element s-expressions’ in which the first item specifies the context of the statement and the second item specifies the statement’s content. For example, the statement that Alice is untrustworthy in a REFEREE certification module would be ((“certification module”)(“Alice” (untrustworthy yes)).

The IBM Trust Establishment Framework (Herzberg, Mass et al. 2000) uses certificates to build trust for e-commerce from the grass roots up, i.e., certificate-issuing third parties are either known in advance or can provide sufficient certificates for a policy to consider them a trusted authority. Certificates can be issued by various users who vouch for an entity in a particular role, e.g,. for an entity’s status as a seller, and the role conveys useful information about the subject (not necessarily its identity). These certificates are evaluated by IBM’s role-based access control model which is comprised of a Trust Policy Language (TPL) and a Trust Establishment module. Local policy is specified in TPL, which maps unknown users to predefined business roles, e.g. for the role ‘seller’ there may be rules governing group membership for the seller group. After the Trust Establishment module has determined that an entity can be assigned to a certain role, this information is sent to another module that applies the access rights that are bound to that role. The authors state that their implementation may be used as an extension of a web server or as a separate server interfacing to applications.

The trust management solutions discussed thus far are closely tied to systems that implement access control or authentication (Grandison and Sloman 2000). These systems do not acknowledge that trust changes over time and have no mechanism for monitoring trust relationships to re-evaluate their constraints in light of new observations. Therefore, to monitor changing trust relationships, Grandison et al. propose the Simple Universal Logic-oriented Trust Analysis Notation (SULTAN) trust management system, a computational framework designed to facilitate ‘the activity of collecting, codifying, analyzing, and presenting evidence related to competence, honesty, security, or dependability with the purpose of making assessments and decisions regarding trusting relationships for Internet applications’ such as the management of trust relationships relating to employee data access and client service provision for an e-commerce vendor (Grandison and Sloman 2003). The SULTAN trust management model is comprised of four components, a specification editor, an analysis tool, a risk service, and a monitoring service.

The specification editor is used by a system administrator to define trust relationships in terms of the parties involved and the interaction context, or trust purpose. A trust statement has the following

format: TrustPolicyName trust Tr Te As L: ( , , , )←Cs, where TrustPolicyName is the unique name for the assertion that a trust origin, Tr, trusts a trust target, Te, for a trust purpose, i.e., to perform a set of actions, As, at trust level, L, if constraint(s), Cs, is true. A recommendation statement has the following format: RecPolicyName:recommend Rr( , Re,As L, )←Cs, where RecPolicyName is the unique name for the assertion that a recommender, Rr, recommends a recommendee, Re, for a trust purpose, i.e., to perform a set of actions, As, at a level of confidence in the recommender, L, if constraint(s), Cs, is true. Trust statements and recommendations are expressed in the SULTAN policy language. The analysis tool allows the system administrator to perform simulations and property analysis to determine if specified properties hold on trust and recommendation statements or if there are conflicts between statements.

The risk service retrieves risk information and calculates risk. Risk is a measure of the probability of a transaction failing. For example, if there is high risk associated with a service provider, then trust in that entity will be lower. Risk is also related to transaction value, e.g., a client may trust a supplier who is considered a high risk when services supplied cost only $10, but may not trust a medium risk supplier when purchasing goods for $10,000. Risk is calculated based on the following elements: a list of common risks, e.g., refusal to produce goods, service failure, information theft, and fraud; the probability of each risk occurring; a list of action dependencies; a list of trust origins and their maximum allowable losses/risk thresholds; and a list of system resources.

The monitoring service monitors interactions and updates risk, experience, and system state information to an information store. For example, when a customer makes a payment to an e- commerce vendor, the customer’s balance is updated by the monitoring service.

This system incorporates two concepts notably lacking from the trust management systems previously discussed, i.e., the elements of capturing trust dynamics through observation monitoring, and the element of risk information retrieval, which facilitates the evaluation of risk in trust-based decision- making. SULTAN provides limited support for decision-making in that it allows the specification of simple authorisation policies which query the trust management system for access control based on trust levels. However, it has been found (Dulay, Lupu et al. 2005) that the system is too heavyweight for automated trust decision support as SULTAN’s emphasis remains on trust specification analysis rather than trust-based decision-making. Moreover, while Grandison et al. differentiate between trust and authorisation, saying ‘to state that you trust someone to do something and to say that you allow someone to do something in a given situation are two different things. Trust is a statement of belief. Access control is a statement of what is permitted (or not permitted)’, SULTAN is primarily a means of specifying and analysing a system administrator’s beliefs about access control for system users.