Decentralized trust model

In 1996 appearing as pioneers Matt Blaze, Joan Feigenbaum and Jack Lacy supported the idea of “Decentralized Trust Management” [4] as an important component of security in network services. The Decentralized Trust Management model was the first system taking a comprehensive ap- proach to trust problems independent of any particular application or ser- vice. The main achievement was the construction of a system called Poli- cyMaker for defining policies and trust relationships. Handling of queries is the fundamental function of the PolicyMaker with the aim to determine whether a specific public-key has the permission to access certain services according to a local policy. Policies are composed in the special Policy- Maker Language. A central authority for evaluating credentials is not nec- essary. Although locally managed, each entity has the competence to achieve own decisions.

The essential point in this model targets the typical problem that, al- though the binding of the public-key to a network identity was successfully verified, usually the application itself has to subsequently ensure that this network participant is authorized to perform certain actions or is author- ized to access security sensitive data. The application for example looks-up the network identity’s name in a database and tries to verify that it matches the required service. The Decentralized Trust Modelapproach wants to es- tablish a generic method that should facilitate the development of security features in a wide range of application, unlike other systems like for exam- ple PGP. Therefore, this approach extends the common identity-based cer- tificates, which bind a public-key to a unique identity, by means of reliably mapping identities to actions they are trusted to perform. In this context, the specification of policies is merged with the binding of public keys to trusted actions. Consequently, both questions “Who is the holder of the public-key?” and “Can a certain public-key be trusted for a certain pur- pose?” are clarified with the Decentralized Trust Model. Basically, each network entity that receives a request must have a policy that serves as the ultimate source of authority in the local environment.

Currently, the PolicyMaker approach binds public-keys to predicates rather than to the identities of the public-key holders. The PolicyMaker Language is provided for the purpose of expressing conditions under

Applying Trust in Mobile and Wireless Networks 51

which a network participant is trusted to sign a certain action. As a result, a network entity has the ability to distinguish between the signatures of dif- ferent entities depending on the required services. By this means for in- stance, network entity A may trust certificates signed by network entity B for small transaction but may insist upon certificates from more reliable network entity C for large transactions.

Basically, the PolicyMaker service appears to applications like a data- base query engine and functions as a trust management engine. The input is composed of a set of local policy statements (credentials) as well as a string describing the desired trusted action. After evaluating the input, the PolicyMaker system finally returns either a yes/no answer or propositions that make the desired action feasible.

All security policies are defined in terms of predicates, called filters that are combined with public-keys. The function of the filters is to assure if the owner of the corresponding secret-key is accepted or rejected to per- form the desired action. A specific action is considered acceptable, if there is a chain from the policy to the key requesting the action, in which all fil- ters are traversed successfully. The design and interpretation of action de- scriptions, called action strings, is not part or even not known to the Poli- cyMaker. Action strings are interpreted only by the calling application and might present various capabilities as signing messages or logging into a computer system. Action strings are accepted or rejected by the filters.

Signatures can be verified by any public-key cryptosystem, for instance PGP. The main reason for it is, that the PolicyMaker system does not ver- ify the signatures by itself and that the associated action strings are also application specific. Generally, an application calls the PolicyMaker after composing the action string and determining the identity, from which the desired action originated. Finally, PolicyMaker decides whether the action string is permitted according the local security policy. The basic function of the PolicyMaker system is to process queries composed with the Poli- cyMaker Language of the form:

key1, key2, …, keyn REQUEST Action String

A query is a request for information about the trust that can be placed in a certain public-key. The PolicyMaker system processes queries based on trust information that is included in assertions.Assertions assign authority on keys and are of the form:

SourceASSERTSAuthorityStruct WHEREFilter

In this context, each a credential is a type of assertion, which binds a to a sequence of public-keys, called an authority structure. Source filter

52

assertion and AuthorityStruct specifies the public- key(s) to whom the assertion applies. Hence, a Filter is the predicate that action strings must satisfy for the assertion to hold. For example, the fol- lowing PolicyMaker credentials indicate that the source PGP key “0x01234567abcdefa0a1b2c4d5e6a4f7” asserts that A’s PGP key is “0xb0034261abc7efa0a1b2c5d4e6a4a3”: pgp:“0x01234567abcdefa0a1b2c4d5e6a4f7” ASSERTS pgp:“0xb0034261abc7efa0a1b2c5d4e6a4a3” WHERE PREDICATE=regexp:“From A”;

There are two types of assertions: certificates and policies. The major difference is that policies are unconditionally trusted locally and certifi- cates are signed messages binding a particular Authority Structure to a fil- ter. The Source field in a policy assertion is the keyword “POLICY”, rather than the public-key of an entity granting authority.

While this approach provides a basis for expressing and evaluating trust, it does not consider the simultaneous problem of how to continuously con- trol and manage trust over a longer period of time. These problems are dis- cussed by Brent N. Chun and Andy Bavier in [6], where a layered architec- ture for mitigating the trust management problem in federated systems is proposed. The authors stress that the PolicyMaker approach presumes the existence of secure, authenticated channels, for example using preexisting indicates the origin of the

public-key infrastructure, which makes it inapplicable for trust manage- ment in MANETs.