Channels ▼
RSS

Design

Securing Community Networks


Decentralized Trust-Management Framework

Requirements

We propose a decentralized trust-management framework for managing trusted member identity in self-organizing networks. The trust-management system creates and manages a trusted domain, called a trusted community. This framework satisfies the following requirements:

Removes dependency on a centralized authority. We envision a completely decentralized system in which every node in the domain has the potential to be a naming authority. Many authorities in a domain allow users to join and use the system from anywhere in the network.

Makes on-line evidence distribution a first-class ingredient. All members in the system provide a variety of evidence to help calculate the initial and ongoing trust and reputation of other members. It is important to provide on-line mechanisms so that members can distribute trust evidence, in order to build a practical trust-management system.

Provides accountability. The trusted community uses the authentication procedure to enforce accountability that cannot be repudiated, for actions performed by a member of the domain. To achieve accountability, identities must be individual, unique, and undeniable, within the administrative domain.

Treats relationships as a central component of the network. The usage of identities in P2P communications is often relevant only to the communicating parties within the domain. Identities created and managed in the trusted community should signify P2P member relationships and members' relationships with the trusted community, via the relationship the credential issuer maintains with the community.

Decentralized Trust-Management Paradigm

At a high level, a trust-management framework should provide the following functions to be able to secure communities:

  • Bootstrap, or create, the community.
  • Enroll members in the community.
  • Authenticate members to one another.

The framework mechanisms to generate and manage identities for each member should be decentralized. They must permit members to authenticate and securely communicate with each other through mediation of any other members in the trusted community. Members self-organize the trusted community by using trust calculations to evaluate their evolving relationships within the community.

Relationships exist between roles within a community. Each community contains members who are entities that can participate in community activities with full member privileges. Issuers are special members. In addition to ordinary member privileges, issuers have the responsibility of generating identities for new members. We represent identities with identity certificates that can be used as authentication credentials within the community.

Authentication within the community is achieved by the holder of an identity credential issued by a recognized issuer proving possession of a key that is bound to the credential. Authentication fails if the authenticated party does not possess a certificate from an issuer who is recognized by the authenticator as such. A member may recognize all or some subset of the other members as issuers in the community. When a member is first enrolled in the community, this member's enroller is, by default, the first issuer recognized by the member. A member may gain trust and recognize new issuers by collecting trust evidence from the community and applying the evidence to a "trust calculation". A member can become an issuer as a result of a consensus reached by a group of issuers and members; this group is called the issuer's election committee. The "election committee" can consist of a single member, but an issuer has little impact unless it is recognized broadly across the community. Members of the election committee execute a joint trust calculation algorithm to elect an issuer. Once elected, an "issuer certificate" is issued to the new issuer, signed by each of the electors. The purpose of this signed certificate is to demonstrate that the issuer is recognized by more than a single member. However, having the certificate signed by multiple parties raises security issues about collusion and about members with multiple identities, which are discussed later in this article.

"Founders" are special issuers who initially establish the trusted community. Founders recognize each other as founders, issuers, and members.

Lastly, some entities are treated as guests in the community. Any community member can introduce new entities to other community members as "guests". An issuer can enroll a guest as a member by following certain procedures. Creating the guest role allows a newcomer to participate in a trusted community without having to first contact an issuer.

It is important to stress that community credentials provide more than just identities for community members.

Credentials are relationship signifiers. Each one signifies a relationship between the member and its issuer. In this model identity is not necessarily who you say you are, but rather who your issuer says you are. Other members of the community believe this identity because it is asserted by an issuer they trust. The community collectively holds its issuers accountable for issuing identities that do not conform to the rules of the community.

In this trust-model, framework, each entity implements the same set of trust-management functions: (1) trust evidence collection and distribution; (2) identity generation and auditing; and (3) trust calculation and propagation of identities. In addition, each entity maintains a community database locally that stores the entity's knowledge about the trusted communities it belongs to. Some examples of the type of data stored in the community database are community name, policy, recognized identity certificates, recognized issuer certificates, and relevant trust evidence. Figure 1 illustrates the three major trust-management functions and their relationships. Each entity collects evidence through its own measurements, and also through communication with other entities within the community. Entities use on-line, evidence-distribution mechanisms to share evidence gathered from either first-hand observations or from recommendations by other community members they trust.

Figure 1: Distributed Trust Framework for Identity Management (Source: Intel Corporation, 2009)

Once sufficient evidence is collected, an entity can compute an initial trust value for the target entity. For initial enrollment, an issuer generates a name label that is based on collected evidence. The issuer binds the name label to the relevant evidence in a credential for the target entity.

For authentication, the identity auditing mechanisms ensure that the entity uses its identity properly, the one that is laid out in the authentication and authorization procedures. In particular, the entities need to pay close attention to identity-related attacks (discussed later in this article), and they need to utilize certain approaches to detect or mitigate identity attacks. The auditing function requires knowledge of both the name label and trust evidence that is bound to the entity's identity in the community.

Lastly, each entity builds its trust value or reputation upon joining the community. To establish and update trust on an existing member, the entity utilizes trust calculus to incorporate opinions from its peers, as well as first-hand observations. More specifically, the main goal of trust calculus is to compute the trust value on a member without communicating directly with the member. Often, this is done by utilizing the transitive property of trust. Later on in this article, we introduce a novel trust-calculation model that has two unique features: it supports both positive and negative trust values, and it utilizes relationships among devices and their users inherited from other contexts to root trust whenever possible. The outcome of the trust calculation is fed back to trust-evidence collection and auditing components to further improve the knowledge of trust evidence and the binding of entity attributes with the identity of the entity.

In the remaining sections of this article, we discuss in detail our vision for these three components with our focus on bootstrapping trust and propagating trust in the community.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video