A Framework of Decentralized PKI Key Management Based on Dynamic Trust

A Framework of Decentralized PKI Key Management Based on Dynamic Trust Zhiqian Xu 1 and Hai Jiang 2 1 FedEx Corporation, Collierville, TN, U.S.A. 2 Dept. of Computer Science, Arkansas State University, Jonesboro, AR, U.S.A Abstract - Node mobility in a P2P network causes frequent changes of the network topology. The absence of centralized services in P2P systems and the nature of unpredictable network topology make it difficult to support centralized and pre-existing third party trust authority relied by Public Key Infrastructure (PKI). This paper presents a framework of a decentralized PKI key management system based on distributed trust management. This framework makes three major contributions. First, a dynamic trust model is set up while all peers have their own trust authorities. Second, an infrastructure is proposed to dynamically and systematically maintain peers trust values and keys. Third, a new way to federate decentralized PKI systems is provided. With these, secure P2P systems can still remain completely decentralized. Keywords: Trust, Reputation, Certificate, PKI Key Management, P2P Systems. In P2P systems, no entity can serve as the pre-established trust third party to issue key pairs and certificates which in turn are issued by individual entity/peer. Then their credibility and reliability are questionable. Decentralized trust model is required. Pretty Good Privacy (PGP) is well known for achieving this through a web of trust. The trust is introduced through people knowing each others. Individuals choose their own trust introducers. As time goes by, they grow into a web of trust. This seems to work well in a dynamic and decentralized environment, but in fact this is more suitable to establish trust among people, not electronic devices which cannot determine whether another machine is trustful based on the previous experience and the sense of feeling. The trust in PGP is based on building a graph or chain to end entities. In fact, trust can be established through the satisfactory rate from successful transactions and the reputation collected within a community. Properly combining these two can derive the dynamic trust value for the key management on each peer. 1 Introduction Peer-to-Peer (P2P) systems provide a scalable approach to effectively share system resources such as content, storage, CPU cycles, etc. Without any centralized server or authority, a P2P system can be characterized by a number of properties: there is no central coordination or database, no peer has a global view of the system, global behavior emerges from local interactions, peers are autonomous, and peers and connections are not reliable [1]. Modern distributed systems have been migrating to P2P domain for scalability. The Public Key Infrastructure (PKI) is a widely adopted for data security in P2P systems. PKI uses trust to manage and distribute keys among entities which are not necessary to know each other. The keys are bonded to entities through the trusted third party called Certificate Authority (CA). Traditional PKI adopts the centralized trust model, i.e., CAs are pre-established. The identities of entities must be unique to CAs. Therefore a CA has to maintain all identities for the certificates it has issued or will issue. Sometimes human being has to involve in the verification process and this is not suitable to the peers in dynamically changing P2P systems. This paper makes the following contributions: First, a dynamic trust model is proposed to acquire trust values without centralized trust authority. Second, an infrastructure of the PKI key management system is developed to acquire dynamic trust values effectively. Third, the proposed framework provides a way to federate decentralized PKI systems. Therefore, secure P2P systems will contain no centralized server or authority as they are supposed to be. The remainder of this paper is organized as follows: Section 2 discusses the current key management in P2P systems. In Section 3, some design issues are introduced. Section 4 presents major strategies in decentralized key management. Conclusions and future work are given in Section 5. 2 Key Management in P2P Systems PKI-based key management in P2P systems needs to solve the following problems: Trust management with no centralized trust authority. Unique identity management due to the lack of centralized identity management.

The first problem can be addressed by distributed trust management whereas the second one is tackled by the data structure proposed in the framework. 2.1 Distributed Trust Management The concept of trust is a peer s belief about capabilities of another peer. The capabilities are reliability and honesty based on its own experiences. On the other hand, the capabilities about reputation are honesty and reliability based on recommendations received from other peers [2]. The electronic trust can be managed through different trust models. In general the trust model can be broken into two types: hard and soft. A hard trust model is for managing trust relationships derived from crypto-based mechanisms, such as authentication and access control. A soft trust model is for managing trust relationships derived from security related behavioral evidence through a new set of social control mechanisms, such as trust and reputation [3]. Distributed Trust management was first addressed by Blaze et al in [4]. Different trust and reputation engines are classified in [5]. Rating systems including ebay, google, amozon, etc, have been reviewed with their methods and calculation formulas. Carmen Fernandez-Gago et al gave an overview of some existing trust management systems in P2P environment [6]. Most of those systems use the concept of reputation which is collected and calculated based on different aggression methods and formulas. Aberer et al [1] proposed a reputation based trust management by collecting and aggregating complains of agents. PeerTrust [7] is a dynamic trust model for quantifying and assessing the trustworthiness of peers in P2P e-commerce communities. To evaluate the trustworthiness of a peer, it has identified five important factors: feedback a peer obtains from other peers, the feedback scope, such as the total number of transactions that a peer has with other peers, the credibility factor of the feedback source, the transaction context factor for discriminating mission-critical transactions from less or noncritical ones, and the community context factor for addressing community-related characteristics and vulnerabilities. 2.2 Distributed Key Management Zhou et al. [8] proposed a distributed key management system by using threshold cryptography to distribute trust among a set of servers. That set of servers act as whole to be a CA to sign the certificates. The whole network system has a pair of keys. The public key is distributed to the system. The private key k is divided into n shares using an (n, t +1) threshold cryptography scheme. The shares are distributed to n arbitrarily chosen nodes (servers). In order to obtain a certificate, a node contacts t+1 servers and have each server generate a signature with its share of the private key. The t+1 partial signatures are submitted to a combiner to compute the certificate signature. This proposal assumes that there is an authority that initially empowers the servers and that some of the nodes must behave as servers. A MObile Certificate Authority (MOCA) method has been proposed in [9] and [10]. They employ threshold cryptography to distribute the CA functionality over specially selected nodes based on the security and the physical characteristics of nodes. The certificate request server composes the final signature instead of a delegate signature composer. Sardjan et al [11] proposed a fully self-organized publickey management scheme. There is no pre-established trust authority. Certificates are stored and distributed and each node maintains a local certificate repository that contains a limited number of certificates selected by the node according to an appropriate algorithm. Key authentication is performed via chains of certificates. Although threshold key management uses a set of servers as the Certificate Authority, it needs offline settings prior to the network formation, such as using a trusted third party for CA s key pair generation, the CA servers selection and private key share distribution. Any entity can request a certificate by collecting t+1 signatures without proper validations. The fully self-organized public key management does not have shared key generation and pre-distribution. The key validations are achieved by building certificate chains among entities. A chain can be un-reliable by any revoked certificates within the chain. The entities holding the certificates are not properly validated either. Our proposed PKI key management framework uses dynamic trust management system. It properly eliminates the drawbacks of threshold key management system and fully self-organized public key management scheme. 3 Framework Design To eliminate the traditionally centralized trust model in PKI, the key management of a P2P system should be able to issue keys based on dynamic trust relationship among peers. Thus, both trust model and integrated infrastructure need to be designed. 3.1 Trust Metric We use reputation and credibility values to compute the trust values. In our system, reputation refers to the average trust value collected from other nodes. Credibility represents

the confidence a node has towards another node. Credibility is derived from feedbacks and cooperative ratings about a transaction or service recommendation. Each node has both reputation and credibility data for some other nodes. The difference between reputation and credibility is that the reputation is a node s average trust value collected from the other nodes whereas the credibility is the average value of a node s personal transaction feedbacks or corporative ratings toward that node. The trust metric of PeerTrust in [7] is modified to fit our framework s need. For node v, node u s credibility at a given time can be computed using the following equation: 3.3 Infrastructure On each peer, there exists three sub-systems: Trust Manager, Network Architecture Manager and Key Manager, as shown in Figure 2. The Trust Manager updates peers trust values, maintains transaction history, records feedbacks, and updates peers credibility values. The Network Architecture Manager maintains the network topology and peers identity information, manages network Cr(u) =,, (1) where T(u) is the total transactions node u has participated,, denotes the transaction feedback v gives to u for the ith transaction if u is the service provider, and CR(u,i) represents the cooperative rating v gives to u for ith transaction if u is a participant. The node u s trust value at a give time is calculated as: TV(u), (2) where V(n) is the total neighboring nodes stored by node v, RV(k, u) is the reputation value node k gives to u, and Cr(k) is node k s credibility toward v. 3.2 The Network Architecture In P2P systems, peers are self-contained and selfmanaged. Each peer is only connected to the ones in its neighborhood which keeps changing all the time. Because of the dynamicity nature of an unstructured P2P network, the number of each node s neighbors may be different at different moments. Each node gradually learns, builds and updates the network topology based on the transactions and service searching/requesting messages. To make it generic, an unstructured P2P network is selected to demonstrate our design. To simplify our explanation, we assume the network topology as showed in Figure 1. Figure 2. Three sub-systems on each peer messages, provides routing information, and issues nodes corporative ratings. The Key Manager validates certificates, evaluates the trust value periodically to renew / issue or revoke keys, and maintains Certificate Revocation List (CRL). The trust value, node credibility, network topology, service provider information, node identification and certificates are stored in different tables or data storages maintained by different managers. The contents of several major tables based on the sample network in Figure 1 are listed as follows: Figure 1. The P2P network example.

Table1: Node Table on N 1 ID IP Node Name Credibility Trust Value Trust Value Timestamp Neighbor Node Online H(PK(N 2 )) IP(N 2 ) N(N 2 ) Cr(N 2 ) TV(N 2 ) GMT(SysTime) Y Y H(PK(N 3 )) IP(N 3 ) N(N 3 ) Cr(N 3 ) TV(N 3 ) GMT(SysTime) Y Y H(PK(N 4 )) IP(N 4 ) N(N 4 ) Cr(N 4 ) TV(N 4 ) GMT(SysTime) Y Y H(PK(N 5 )) IP(N 5 ) N(N 5 ) Cr(N 5 ) TV(N 5 ) GMT(SysTime) Y Y H(PK(N 6 )) IP(N 6 ) N(N 6 ) Cr(N 6 ) TV(N 6 ) GMT(SysTime) Y Y H(PK(N 7 )) IP(N 7 ) N(N 7 ) Cr(N 7 ) TV(N 7 ) GMT(SysTime) N Y Table 2: Transaction History Table on N 1 Service Provider Node Service Transaction Feedback Transaction Participating Node, Feedback Time Stamp Type/Info H(PK(N 3 )) Svc(N 3 ) S rate TP(S N1 (N 3 )) GMT(CurTime) H(PK(N 7 )) Svc(N 7 ) S rate TP(S N1 (N 2 ),S N2 (N 7 )) GMT(CurTime) H(PK(N 9 )) Svc(N 9 ) S rate TP(S N1 (N 3 ),S N3 (N 8 ), S N8 (N 9 )) GMT(CurTime) Table 3: Routing Table on N 1 Node ID Neighbor Nodes / Cost Cooperative Updated Time Rating H(PK(N 1 )) Neighbor(H(PK(N 2 ),Cos 1 ), H(PK(N 4 ) Cos 2 ), H(PK(N5), Cos 3 ), CR1 GMT(CurTime 1 ) H(PK(N 6 ), Cos 4 )) H(PK(N 8 )) Neighbor(H(PK(N 3 ), Cos 5 ),H(PK(N 6 ), Cos 6 )) CR2 GMT(CurTim 2 ) Node Table: The node table stores node identification information and the trust values. A node is uniquely identified by the hash value of its public key. The sample data in the node table is showed in Table1. H(PK(N i )) is the hash value of node i s public key. GMT(SysTime) is the time stamp to record when the data was updated. Transaction Table: The transaction table maintains transaction history and feedback information as showed in Table 2. Svc(N 3 ) is the requested service description. TP(S Ni (N k,), S Nj (N v ) ) denotes the feedbacks given by the participating nodes to the neighboring nodes in the transaction. Routing Table: The network structure and topology are maintained in a routing table as showed in Table 3 which is used to find the best route to a server if two or more nodes can satisfy the same request. The best path is determined by the combination result of node trust value, network hops, and hop costs. This table is dynamically built and updated based on periodically pinging or service polling messages. Cos i denotes the cost between the two nodes. Certificate Storage: Certificates and revocation list (CRL) are stored in the certificate storage maintained by Key Managers. 4 Strategies in Decentralized Key Management 4.1 System Initialization When a node joins the network, its Network Architecture Manager broadcasts messages to all neighbors to acquire related information about them and fills out local node table. Then another round of messages is sent to acquire all neighbors public keys and their CA s certificates. Such messages also piggyback the local node s own certificate and CA s public key. In the node table, every neighbor s trust value is initialized by its reputation value which is the average of trust

values collected from all other neighbors regarding to this neighbor. Flooding technique is adopted and broadcasting messages are all encrypted. Initially, the hop counter is set to n and attached to broadcasting messages. When a message reaches a node, its hop counter will be decremented by one and the message is forwarded to receiving nodes neighbors. When a hop counter reaches zero, an acknowledgement message is sent back along the same path. For all those nodes having trust values about the particular neighbor of the original node, the average trust value will be calculated and returned. When activating the flooding, the original node also sets up a timer for each message. Once the timer goes off or all messages have returned, the original node can calculate the reputation value for the specified neighbor. The initial value of credibility for each neighbor is assigned to a default one. The overall strategy is given in Algorithm 1 used by the Trust Manager. Algorithm 1 Trust_Value_Init for i = 1 to Length(NeighborNodes) for j = 1 to Length(NeighborNodes) If i j RV(N i, N j ) <= RequestTrustValue(N i, N j, timer); end for Credibility(N i ) <= Cr(default) TV(N i ) <= Compute with Equation (2) end for If other nodes trust values are over a certain threshold, the local Key Manager will issue cross CA certificates to their CAs. According to each CA s policy and trust values, certificate validation periods are also assigned. The original node s Network Architecture Manager sends the cross CA certificate encrypted with the receiver s CA public key. The receiver s Key Manager decrypts the message and saves the certificate. If a node just joins a network, no reputation information has been collected and its certificates are marked untruthful temporarily. 4.2 P2P Service Selection When a node requests a service and does not know where to get it, it broadcasts a message to its neighbors. In the message, it also specifies a hop counter n and a timer to tolerate any unreachable or offline nodes before the hop counter is decreased to zero. If a node provides the service, an acknowledgement message is sent back. Otherwise, it forwards the request to its neighbors and decreases the hop counter by one. Flooding stops when the hop counter turns zero. When the service request message reaches a service provider, an acknowledgement message will be sent back along the same path. All nodes on the path will attach and sign their trust values regarding to the service provider. Then the original node s Trust Manager calculates the trust value about the service provider. If there are more than one service providers, the Network Architecture Manager builds path graphs and updates the network topology table if new nodes are found at the same time. The service provider node is selected based on its trust value and the cost of the path to it. The node cooperative ratings are updated based on their responses and service recommendations. A peer might provide a good service, but also spread malicious trust values about its competitors. This type of situation can be minimized by adjusting the weight on the credibility value. 4.3 Certificate Management We assume that there is no pre-existing or established CA and each node has its own CA. Since the trust or credibility values are bonded to each individual node, nodes issue cross certifications to other nodes CAs as showed in Figure 3. Figure 3. Node 1 and Node 2 issue cross certificates to each other s self signed CAs. A node can use a well known CA to issue its public key or its CA s public key. However, such CA lists can be configured differently. A negotiation process is conducted to see if the two nodes agree upon a well known trusted CA which can act as a bridge CA between them. Each CA can also be selected by other nodes as a certificate broker (a bridge CA) for issuing certificates for other nodes. However the selected bridge CA has to have cross CA certificates issued by those nodes. Figure 4 shows the diagram of a bridge CA. Node identities are achieved through the hash value of their public key, their CA s public key, the IP addresses, and node names. This combination can uniquely identify a node.

4.3.1 Certificate Issuing Process When issuing certificates, nodes can use trust values to If a node s trust value is below to its certificate security level, the current certificate will be revoked. However, a new certificate might be issued based on the current credibility, trust data, and certificate policies. 4.3.3 Other Certificate Management Processes Each node s Key Manager periodically validates other nodes credibility and trust value against its issued certificates. When a node trust value has not been updated for a certain period of time, the Key Manager will initiate an update event. The Key Manager is also responsible for maintaining CRL which needs to be online and available for the other nodes. When a node s CA certificate or public key expires, a new certificate request message is sent out. The tables need to be updated to reflect the changes. Figure 4. A bridge CA at Node 3 acts as a trusted broker between Node1 and Node 2. establish trust relationship. Their CAs have a set of certificate policies to issue different types of certificates with different levels of security, trust domains, validation periods, etc. When a node just joins the network and no reputation data has been collected from other nodes, a temporary certificate can be issued with a very low security insurance and short validation period. When a certificate expires, the credibility and trust data are evaluated by the Key Manager to decide whether the certificate is renewable or not, what type of new certificate should be issued and how long the validation period should be. If the trust data has not been updated for a certain period of time, the Key Manager will ask the Network Architecture Manager to send out reputation value request messages. The Trust Manager updates the node table to reflect the new values. The Key Manager evaluates the new data and renews the certificate if necessary. 4.3.2 Certificate Revoking Process A certificate is revoked when the private key is comprised or a node s trust value is below the threshold of that type of certificate. When a private key becomes comprised, the certificate is stored in the CRL list. The Network Architecture Manager sends out messages to the related nodes based on the stored transaction history and network topology information. 5 Conclusions and Future Work In this paper we proposed a framework to implement a decentralized key management system based on a dynamic trust model. No centralized or pre-established trust authority is required. Certificate management is maintained based on peer trust values which are dynamically calculated and maintained. The framework introduces three sub-systems to integrate dynamic trust and key management. After getting rid of the possible central authority in PKI, secure P2P systems are completely decentralized. The future work includes the introduction of semantic overlay networks for services, exploiting causal relationship between trusts, and implementing the proposed framework in a P2P system. 6 References [1] K. Aberer and Z despotovic, Managing Trust in a Peer- 2-Peer Information System, in Proceedings of the tenth international conference on Information and knowledge management, 2001. [2] Y. Wang and J. Vassileva, Trust and Reputation Model in Peer-to-Peer Networks, University of Saskatchewan, Canada, 2004. [3] C. Lin and V. Varadharajan, A Hybrid Trust Model for Enhancing Security in Distributed Systems, Iin Proceedings of the Second International Conference on Availability, Reliability and Security, 2007. [4] M. Blaze, J. Feigenbaum, and J. Lacy. Decentralized Trust Management, in IEEE Symposium on Security and Privacy, 1996.

[5] A. Jøsang, R. Ismail and C. Boyd. A Survey of Trust and Reputation Systems for Online Service Provision, Decision Support System, vol. 43, no. 2, 2007. [6] M. Carmen Fernandez-Gago, R. Roman, and J. Lopez, A Survey on the Applicability of Trust Management Systems for Wireless Sensor Networks, in Proceedings of the Third international workshop on security, privacy and trust in pervasive and ubiquitous computing, 2007. [7] L. Xiong and L. Liu. PeerTrust: Supporting Reputation- Based Trust for Peer-to-Peer Electronic Communicates, IEEE Transactions on Knowledge and Data Engineering, vol. 16, no. 7, 2004. [8] L. Zhou and Z. Haas, Securing Ad Hoc Networks, IEEE Network, vol. 13, no. 6, pp. 24-30, Nov./Dec. 1999. [9] S. Yi, R. Kravets. MOCA : Mobile Certificate Authority for Wireless Ad Hoc Networks, The 2nd Annual PKI Research Workshop, 2003. [10] J. Sen, M.Chandra, P. Balamuralidhar, Harihara S.G, and H. Reddy. A Scheme of Certificate Authority for Ad Hoc Networks, in Proceedings of the 18th International Conference on Database and Expert Systems Applications, 2007. [11] P. Zimmermann, The Official PGP User s Guide. MIT Press, 1995. [12] T. Wolfl and K. Fischbach, A Method for the Certification and the Delegation of Trust in Distributed Systems, in Proceedings of the 27th International Conference on Distributed Computing Systems Workshops, 2007. [13] J. Weise, Public Key Infrastructure Overview, http://www.sun.com/blueprints/0801/publickey.pdf. [14] S. Capkun, L. Buttya n, J.-P. Hubaux, Self-Organized Public-Key Management for Mobile Ad Hoc Networks, IEEE Transactions on Mobile Computing, vol.2, no. 1, 2003.