Bootstrapping Trust in the Community
Trust Evidence and Evidence Collection
Bootstrapping trust starts from collected trust evidence. In this scenario, any information useful for computing trust value on an entity is referred to as trust evidence. In general, there are three types of evidence:
- First-hand observation or measurement. The observer can collect such evidence by direct interaction with the target entity. For instance, MAC address, hardware identifier, and past network activities associated with these hardware identifiers are observable directly.
- Second-hand observation. Members can share their first-hand observations with each other to help trust calculation.
- Recommendations. Members can also share their opinions on other entities with each other. Recommendations result from the distillation of evidence by the trust calculations of other members. For instance, one member may recognize another as an issuer. By doing so, the first member has decided that certificates issued by the issuer are an acceptable form of identity within the community. Responding to a query from another member for the issuer's certificate is its way of "recommending" the issuer.
The mechanisms to share trust evidence are critical to enable decentralized trust calculation. A general requirement for trust evidence sharing is that trust evidence be distributed to wherever it is needed as quickly as possible. Several P2P communication systems have the potential to satisfy this requirement, such as ant-based routing, content-based information routing, publish and subscribe systems, delay tolerant transport protocols, P2P file sharing, P2P gossip protocols, and so on. Part of our future work is to choose appropriate protocol and communication primitives to support distributed trust evidence sharing.
Bootstrapping Trust from Evidence
Device credentialing requires the creation of a relationship with a new community. This problem may be broken down into two separate problems. Firstly, the device must somehow be able to unambiguously recognize the community, and the community must somehow be able to recognize the device. Secondly, both the owner of the device and the community have to agree to form the relationship signified by the credential being established. Solutions to the first problem, such as Wi-Fi Protected Setup , utilize an out-of-band channel to exchange some sort of setup key, which cannot be forged, between the device and the administrative domain. The solution to the second problem requires human choice: both the device owner and the new community must somehow indicate their desire for this new relationship. (Solutions such as factory-installed identities remove human choice, thereby defeating the essential purpose of authentication credentials.)
All electronic identity establishment mechanisms require an out-of-band channel to be secure. The purpose of the out-of-band channel is demonstrative identification; that is, the out-of-band channel establishes beyond a doubt that the identity is being assigned to the intended party. We believe pre-existing relationships can serve as the out-of-band channel in many circumstances. However, this is not always possible. A newly purchased device, for instance, has no prior relationship with any organization deploying it; therefore, it lacks any useful credential to bootstrap a new relationship. Consequently, mechanisms, such as Wi-Fi Protected Setup, will always be needed. However, this lack of credentials is no longer true after a device has been enrolled in even a single administrative domain. A device with a credential has a relationship with one administrative domain, and this relationship can be used as a basis for forming relationships with other members of other administrative domains who possess relationships with the first.
To illustrate this point, suppose A and B both belong to community C1, while A also belongs to community C2. If both B and C2 desire that B become a member of C2, then A can use its relationship with B in C1, as evidence in C2. That is, A can use this relationship to assert that it has demonstrably identified B as evidence supporting B's request to join C2. Similarly, B can use A's recommendation of an issuer I in C2 as evidence that it is indeed joining C2, by accepting an identity certificate from I. In order to protect the confidentiality of the relationship in C1 between A and B, the new credential should not indicate which external relationship was used to identify B to the C2 relationship. On the other hand, A is revealing something about its own relationships within C2 by recommending an issuer to B, but our assumption is that relationships within a community are open to all members for inspection. This is in keeping with current practice, as the authentication credentials provisioned by existing manual solutions to the problem do not inherently reveal the human relationships used to provision the credentials.
A practical trust-management system should address the problem of bootstrapping the trusted domain, a central concern in any decentralized trust models. Here we introduce flexible approaches to establish a new trusted community. The key consideration is to reduce the cost of forming a trusted community. More precisely, we are looking into approaches that require only a limited amount of information and human intervention.
In some cases, a trusted community can be constructed with only one party, but one-party communities are usually not very interesting. Instead we illustrate the more general case where two or more parties create a new community through the following steps:
- Establish an initial trust relationship, as described earlier, based on some form of demonstrative identification, including the use of credentials from some other community.
- Run a commitment protocol to agree on the following parameters:
- Community name, as an arbitrary name string
- Community policy, stating membership and naming rules
- Founders' identity information
- Lifetime of the community
The string that identifies the community is the concatenation of community name, founders' public keys, and the community policy description. The public keys are included to uniquely identify the community.
- Create credentials to represent the community. The founders create and sign a special community certificate that contains the information of the newly established community. The founders also recognize each other as issuers and members of this new community.
- Exchange credentials and update the community database. Each founder inserts the newly-generated community certificate, issuer certificates, and member certificates into its own community database.
At this point, the founders successfully establish a community by themselves and are collectively responsible for the management of the community. Issuers propagate this community information and certificates to new members as part of any successful enrollment ceremony.
By using this procedure, parties can self-organize trusted communities. This procedure is flexible and allows for parties to establish long-lived or transient communities to suit different kinds of secure applications.