Embed Size (px)
Citation preview
Chord-PKI: A Distributed Trust Infrastructure based on P2P Networks
Agapios Avramidisa, Panayiotis Kotzanikolaoua, Christos Douligerisa, Mike Burmesterb
aDepartment of Informatics, University of Piraeus,Karaoli & Dimitriou 80, Piraeus 18534, Greece
bDepartment of Computer Science, Florida State University,Florida 32306-4530
Abstract
Many P2P applications require security services such as privacy, anonymity, authentication, and non-repudiation.Such services could be provided through a hierarchical Public Key Infrastructure. However, P2P networks are usuallyInternet-scale distributed systems comprised of nodes with undetermined trust level, thus making hierarchical solu-tions unrealistic. In this paper, we propose Chord-PKI, a distributed PKI architecture which is build upon the Chordoverlay network, in order to provide security services for P2P applications. Our solution distributes the functionalityof a PKI across the peers, by using threshold cryptography and proactive updating. We analyze the security of theproposed infrastructure and through simulations, we evaluate its performance for various scenarios of untrusted nodedistributions.
Keywords: Peer-to-Peer (P2P) Networks, Security Services, Threshold Cryptography
1. Introduction
Peer to peer (P2P) networks have received consid-erable attention in the last few years. In particular,one class of P2P networks, namely structured overlays[1, 2, 3], seems a very attractive choice for buildinglarge scale systems. Almost all structured overlay net-works utilize Distributed Hash Tables (DHTs). TheDHT uses a collision-resistant hash function – e.g. acryptographic hash function such as the Secure HashAlgorithm (SHA) family of functions [4] – in order toassign identifiers to nodes and keys1. Moreover, theDHT allows the look up operations (get and put) to beperformed with logarithmic cost in terms of communi-cation messages. DHTs offer a desirable set of proper-ties for distributed applications such as:
• Load balancing. DHTs provide a degree of loadbalance, due to the cryptographic hash functionwhich assigns (almost evenly) key identifiers otnodes.
Email addresses: [email protected] (Agapios Avramidis),[email protected] (Panayiotis Kotzanikolaou),[email protected] (Christos Douligeris ),[email protected] (Mike Burmester)
1These keys correspond to indices to objects such as files, and arenot keys in the cryptographic sense
• Decentralization. No peer is more important thanany other
• Scalability. The cost of a get (and put) operationscales logarithmically to the number of nodes inthe system.
• Availability. DHTs provide protocols that effi-ciently handle high churn situations where nodesjoin and leave the system continuously. These pro-tocols guarantee the success of the lookup opera-tion.
Until recently, the main focus of research regardingDHTs was targeted to the performance of the lookupprotocols, the overlay topology (e.g. Rings, Tori, But-terflies, de Bruijn Graphs and Skip Graphs topologies),load balancing and search issues such as range queries,multi-attribute and aggregation queries. An excellentsurvey on the above issues can be found in [5]. Al-though the aforementioned properties make P2P net-works desirable for building distributed applications,standardized and transparent security mechanisms arestill required, in order to support their wide deployment.
As in any network architecture, security in P2P net-works can be structured in a layered-based approach asillustrated in Figure 1. The first layer of security in-volves the overlay network. Security mechanisms at this
Preprint submitted to Elsevier August 11, 2010
Figure 1: Grouping security services into layers
layer will protect from attacks against overlay routingsuch as incorrect routing look ups (e.g. [6, 7, 8, 9, 10]),incorrect routing table updates (e.g. [6, 7, 9, 11, 10]),network partitioning attacks (e.g. [7]) and Sybil attacksat the overlay layer (e.g. [6, 8, 12, 13, 14, 9, 15]). Se-curity at the overlay network (routing) layer is very im-portant, since it guarantees the robustness of the infras-tructure, (i.e. network connectivity and message deliv-ery). Note that routing security protocols typically re-quire the employment of node authentication, data en-cryption and integrity services, which in turn require theemployment of a key management service.
The second layer of P2P network security involvesthe application layer. The open nature of P2P applica-tions makes the system vulnerable to malicious users.For example in P2P file sharing applications, malicioususers might alter the content of a specific file (contentinfringement), deliberately provide files whose contentsare different from their description (content poisoning),insert “bad” chunks/packets into a valid file (contentpolluting) or make use of the network without contribut-ing resources (freeloading). Such application-layer at-tacks can be prevented or detected with higher layersecurity services such as user authentication, data in-tegrity and encryption, non-repudiation of delivery andof receipt. As in the previous case, application-layer
security services also require the employment of a keymanagement service.
Key management services can be provided throughtrust infrastructures, which would enable peer nodes toauthenticate and distribute cryptographic keys. A pos-sible solution would be the use of a centralized PublicKey Infrastructure. However, the open nature of P2P ap-plications, imposes certain restrictions related to secu-rity. P2P users usually belong to different organizations,groups and locations in a worldwide scale. Thus, it ispractically impossible to find a single entity that everyuser is willing to trust as the root of the trust hierarchy.Another issue with a universal centralized certificationauthority is that the cost may be prohibitive or impracti-cal [16]. An interesting alternative is to explore possiblesolutions which distribute the certification functionalitybetween the overlay nodes.
Contribution
In this paper we propose Chord-PKI 2, a distributedPublic Key Infrastructure, which is embedded into theChord [1] structured overlay network. Chord-PKI dis-tributes the certification, revocation, storage and re-trieval functionalities among the nodes by utilizing theChord lookup protocol, thus making the architecture au-tonomous and fully distributed, in contrast to externaland/or centralized PKI architectures. Our model guar-antees security, under strong cryptographic assurances.The system uses well known cryptographic techniquesas building blocks, such as threshold cryptography [18]and proactive updating [19]. Since our solution utilizesthe Chord, it is designed to deal with security problemsof the Chord routing protocol and it guarantees resis-tance to distributed attacks through redundancy.
Since Chord-PKI is an autonomous key managementservice, it can be used to support security servicesboth into the Chord layer (e.g. certified node identi-fiers), as well as in the application layer for DHT basedapplications, such as distributed file sharing [20, 21],distributed filesystems [22, 23], multicasting [24, 25],caching [26] and content delivery networks [27, 28].
The rest of the paper is organized as follows. Sec-tion 2 describes related work on P2P security. Section3 defines the functional, security and efficiency require-ments for the implementation of a distributed PKI. Sec-tion 4 describes the building blocks of the proposed so-lution. Section 5 introduces the Chord-PKI architectureand describes the protocols utilized by the Chord-PKI.
2A high level description can be found in a preliminary version ofthis paper [17]
2
Section 6 analyzes the security of the Chord-PKI, whilesection 7 evaluates its performance. Finally section 8concludes the paper.
2. Related work
Overlay networks are not secure since they are de-signed to be open and work with a large number ofunknown parties. The distributed nature of overlaynetworks makes the security problem interesting sincethere is no central system to protect. Unfortunately, theexistence of malicious users is very common, thus thesystem must be resilient to their presence. Moreover,security mechanisms must not compromise the scala-bility and the distributed nature of such systems.
In [7] a number of attacks against structure overlaynetworks are presented, where a malicious node mayforward lookups to an incorrect or non-existent node.Moreover, a malicious node could corrupt the routingtables of other nodes by sending incorrect routing up-dates. Another type of routing attack exploits the waynew nodes join the system and directs them to incor-rect networks, thus partitioning the system. As a firstdefense against routing attacks the authors propose thatnode identifiers should be produced in a verifiable way(e.g. basing the node identifier on a cryptographic hashof its IP address). This approach is employed in Chord-PKI. Furthermore, the authors take into considerationthe use of long-term identities for node identifiers basedon public keys.
Castro et al. [6] define the basic requirements for se-cure routing in structure overlay networks. They statethat secure routing requires secure assignment of nodeidentifiers, secure routing table maintenance and securemessage forwarding. As a solution to secure assignmentof node identifiers they propose to delegate the problemto a central, trusted authority. A trusted set of certifica-tion authorities (CAs) assign node identifiers to princi-pals and sign nodeId certificates, which bind a randomnodeId to the public key that represents the principal andits IP address. The CAs ensure that the identifiers arerandomly chosen from the id space and prevent nodesfrom forging identifiers.
An alternative choice to the central certification au-thority is a distributed trust infrastructure which ex-ploits the trust relationships between the P2P partici-pants. Wolfl [29] proposes a Public Key Infrastruc-ture for P2P systems. The proposed solution exploitsthe undelying overlay network (Chord) to provide effi-cient search for certificates. The author uses Maurer’sPKI [30] to model complex trust-relationships whicharise in a P2P environment. The proposed solution does
not handle certificate revocation and expiration since theemployed trust model does not deal with these aspects.
In [17] a distributed PKI is presented, which dis-tributes the cost of certificate storage and retrievalamong the peer nodes of the Chord overlay network.The cost of signing node’s certificates is also distributedamong a group of trusted nodes, by employing crypto-graphic techniques such as threshold cryptography. Thismodel is extended in this paper. In the same spirit,Lesuer et al. [31] propose a distributed certification sys-tem for ovelay networks, where the operation of signinga certificate is distributed to a fixed ratio of nodes thathold a share of a secret key. While the ratio is fixed,the actual number of nodes required to sign a certificateincreases (decreases) as new nodes enter (leave) the sys-tem. Thus, the certification costs are distributed amongthe nodes of the overlay network.
Another decentralized trust management approachcan be build upon reputation-based mechanisms [32, 33,34, 35, 36]. Although reputation models fit well withthe nature of P2P applications and provide adequate so-lutions in several cases, they are not always appropriate.Reputation-based models are usually based on the localtrust views of the users (peer nodes) in order to build theglobal trust view of the network. Distributing the globaltrust view to all the nodes is not always easy to achieve.Moreover, in reputation-based systems the trust views(either local or global) of the nodes are not protectedwith strong integrity protection mechanisms, such ascryptographic integrity checks or digital signatures. Theintegrity of the trust values is usually protected by stor-ing the trust views of a node to several other nodes andby using majority voting in case of disputes. Althoughthis may work with loose security models, in strong se-curity models where nodes may alter stored or trans-mitted data, reputation-based models are not applica-ble. The reputation based approaches could support se-curity services such as integrity, encryption, and non-repudiation, only if they are combined with public keybased solutions. Thus, the design of a decentralized, au-tonomous and embedded trust infrastructure which pro-vides authentication and cryptographic services for P2Psystems, remains an interesting challenge.
3. Requirements for a P2P Public Key Infrastruc-ture
Several requirements need to be satisfied, for the im-plementation of a distributed PKI within a P2P networksuch as Chord. These can be divided into functional,security and efficiency requirements.
3
3.1. Functional requirements
These concern the design of the required PKI servicesand include:
1. Node Certification. Any node must be able to re-quest a public key certificate. Upon receipt of arequest, the PKI service issues the certificate, pro-vided that the requesting node satisfies some pre-defined properties (e.g. a trust or reliability met-ric).
2. Node Revocation. Any certificate issued in thepast by the PKI service can also be revoked by thePKI service, if the corresponding node fails to sat-isfy some predefined properties.
3. Certificate storage. The PKI service should storeboth the valid and the revoked public key certifi-cates.
4. Certificate retrieval. The PKI service should pro-vide retrieval functionality both for the valid andthe revoked certificates.
3.2. Security requirements
These concern the security controls that should be inplace, in order to be protect the infrastructure from var-ious attacks.
1. Availability. The PKI service must always beavailable to nodes requesting certification. More-over, the issued certificates (valid or revoked) mustalways be available to other nodes for retrieval.A more relaxed assumption is that the certifica-tion service may be unavailable only for a limitedamount of time and for a small fraction of certifi-cation and retrieval requests.
2. Resiliency. The PKI service must be resilient tomalicious and non-malicious faults, provided thatthe number of faults is bounded by a threshold.This means that the system should not be vulnera-ble to single point failure or to failures of a limitednumber of nodes.
3. Unforgeability. Malicious nodes must not be ableto generate a forged certificate (or a forged certifi-cate revocation), provided that the number of ma-licious nodes is bounded by a threshold.
4. Proactive security. The system must be protectedfrom an active adversary which is able to adap-tively compromise nodes over long time periods.In particular the system must provide forward se-curity [37], i.e. nodes that have been compromisedin a certain time period should not be able to col-laborate with nodes compromised in another pe-riod.
5. Support secure communication. The PKI ser-vice must provide nodes with the ability to supportconfidentiality, integrity, authentication and non-repudiation of origin,3 of submission and of deliv-ery services.
3.3. Efficiency requirements
Finally, the PKI service must be efficient in terms ofcertification, revocation, storage and retrieval costs andit must scale well in terms of the expected number ofparticipating nodes. More particulary, the following re-quirements must be satisfied:
1. Scalability. The cost of the PKI service for certifi-cation, revocation, storage and retrieval must effi-ciently scale to the number of nodes in the system.
2. Distribution of functionality. The certification,revocation and storage functionality of the PKI ser-vice should be evenly distributed among the peersand no peer node should be more burdened thanany other, over the lifetime of the system. This canbe further divided into the following requirements:
(a) Load balancing of certification and revo-cation. The PKI service must efficientlyissue or revoke a certificate. Ideally, thecost for certification and revocation should beevenly distributed among the peer nodes. Amore relaxed requirement would be the cir-culation of the certification and revocationfunctionality. More specifically, some peernodes may have added functionality for cer-tain time periods, which is recirculated be-tween all the peers. In this way in the longterm the certification and revocation func-tionality will be evenly distributed among allthe peers.
(b) Load balancing of certificate storage. ThePKI service must efficiently store the certifi-cates (valid or revoked) among the nodes.Ideally, the storage cost should be evenly dis-tributed among the peer nodes.
3. Tolerance to frequent changes. The PKI servicemust tolerate frequent joins and leaves, since P2Pnetworks face high churn situations where nodesjoin and leave the system continuously.
3Note that for strong guarantees, several non-repudiation servicesmay also require a time-stamping service
4
Figure 2: Chord Ring with 10 nodes: 6 keys and m=6 (e.g. ID ∈[0 − 63])
4. Building Blocks
Our goal is to build a distributed PKI for the Chordstructured overlay network. Since our system enhancesthe Chord protocol, we briefly describe the functional-ity of Chord. After that, we shall describe the crypto-graphic primitives that will be used in order to distributethe cryptographic protection mechanisms and in partic-ular threshold cryptography and proactive key updating.
4.1. Chord
Chord [1] is a distributed lookup protocol, suitablefor dynamic P2P networks with frequent node arrivalsand departures. The protocol supports one basic opera-tion: given a key (e.g. a file name), it maps that key ontoa node. In particular, Chord uses a hash function (e.g.one of the SHA family [4]) to assign to each node andkey an m-bit identifier. The node’s identifier is chosenby hashing the node’s IP address, while the key identi-fier is produced by hashing the key. Identifiers are or-dered on an identifier circle modulo 2m (Chord Ring). Akey with identifier Ki is assigned to the first node (clock-wise) which satisfies the following condition Ki ≤ Nj,where Nj is the identifier of node N. Node N is theso called successor node of key Ki. Note that by usinga collision-resistant and pre-image resistant hash func-tion a malicious node cannot select an identifier of itschoice. Figure 2 presents an example of a Chord Ringwith m = 6.
Routing in Chord. Chord offers a scalable lookupoperation with an average hop count of 1/2 log2 |N |,where |N | is the number of nodes in the system. Eachnode in the system tracks its predecessor (the previousnode in the circle), its successor (or a list of successors)and a routing table called finger table. Each entry in thefinger table contains the identifier of a node and its IPaddress (and port number). The finger table contains m
Figure 3: Chord Ring with 10 nodes, dotted arrows denote the routesavailable for N8 and N42. Solid arrows show the actual path towardsthe successor for K58
entries, where m is the bit length of the identifier pro-duced by the hash function. The i th entry in the fin-ger table of node N contains the identifier of the firstnode S that succeeds N by at least 2i−1 on the identi-fier circle (i.e., S = successor((N + 2i−1) mod m)), with1 ≤ i ≤ m. Using the finger table, each hop is at leasthalf the remaining distance around the ring to the tar-get node. Figure 3 illustrates how the lookup protocolworks in a system when the identifier bit length is 6. Inparticular, we demonstrate the scenario where node 8(N8) is looking for key 58 (K58). Dotted arrows denotethe possible routes from a node (8 and 42) while thesolid arrows show the actual path from node 8 towardsthe successor node for key 58.
Join. A new node N ′ joins the system by asking anyexisting node N to find its immediate successor. Thisprocess sets the successor pointer for N ′ but does notmake the rest of the network aware of N ′. This task ispart of the stabilization protocol [1].
4.2. Threshold Cryptography
Threshold cryptosystems [18] enable the distributionof a cryptographic operation, such as a digital signature,among a set of entities. With a (t, n) threshold signaturescheme, a set of n entities is able to share the secret keyS K of a public/secret key pair (PK, S K), in such a waythat any t (or more) entities can use their shares of S K tojointly generate a digital signature which can be verifiedwith the public key PK. We denote the jth share of thekey as S K j, j ∈ [1, n]. On the other hand, any set of lessthan t entities is unable to generate a valid signature. In
5
(M)SIG SK
..
. Combiner
(M)SIGtSK
(M)SIG1SK
(M)SIG2SK
Partial Signatures
Figure 4: Combining partial signatures of a (t, n) threshold scheme toproduce a valid signature of a message
order to sign a message M, any set of t share holdersuse their shares S K j of the key S K to compute partialsignatures S IGS Kj (M). The partial signatures are sent toone of the t entities which combines them with its ownpartial signature to produce the signature S IG S K(M) onthe message M, as shown in Figure 4. Note that anysubset of t (or more) valid key shares can be used toproduce a valid signature and that any entity can act asa combiner. By using the corresponding public key PK,any entity (and in particular the combiner) can verify thevalidity of the generated signature. If the signature fails(due to an incorrect partial signature), another subset tof key shares can be used to produce the signature.
The basic threshold schemes cannot deal efficientlywith the problem of incorrect partial signatures. Thisproblem can be efficiently solved by using robustthreshold schemes [38, 39]. A robust threshold schemeprovides verifiability of the correctness of the par-tial signatures, since they incorporate mechanisms todistinguish valid from invalid partial signatures. Al-though this increases the computation costs, it providesresilience to dishonest or misbehaving share holders,since invalid partial signatures can be identified. An-other enhancement of threshold cryptography, first pro-posed in [40], enables the computation and sharing ofthe partial keys without a trusted dealer (also known asrandomized threshold cryptography). In this case, allthe parties participate in the generation of the shared se-cret in such a way that no one knows the secret key tobe shared, even in the key generation phase.
4.3. Proactive Cryptography
A threshold cryptosystem can also be enhanced byusing a proactive update of key shares. If an adversaryis given the ability to compromise share holders overa long time period, it may be easier for the adversaryto ultimately compromise the secret key. With proac-tive schemes (e.g. [19, 41, 42]) the entities that holdthe key shares periodically engage in a share refreshing(updating) protocol. This enables the entities to update
their shares, without changing the secret key itself. Theupdated shares determine a new (t, n) sharing of the se-cret key S K. After the share updating, the entities dis-card the old shares and use the new shares to generatepartial signatures. Note that it is not possible to com-bine partial signatures generated by key shares of differ-ent update periods in order to produce a valid signaturewith the key PK. Briefly, an update relies on the homo-morphic property that if S K1, S K2, ..., S Kn is a sharingof S K and S K ′1, S K′2, ..., S K′n is a sharing of S K ′, thenS K1 + S K′1, S K2 + S K′2, ..., S Kn + S K′n is a sharing ofthe key S K + S K ′. If S K ′ = 0, then the result is a newsharing of S K. Several proactive updating schemes [42]also allow the threshold scheme to change its configu-ration from (t, n) to (t′, n′). This adds flexibility to thenumber of sharers as well as to the security parameterof the key sharing.
5. The Chord-PKI
The Chord-PKI implements the functional require-ments described in Section 3, by combining and extend-ing the building blocks described in the previous sec-tion. Our solution minimizes the burden imposed by theuse of public key cryptography by distributing the cryp-tographic functionality within the peers through thresh-old cryptography. It also minimizes the storage and re-trieval requirements for the public keys, by exploitingthe distributed storage and retrieval functionality of theChord protocol. The certificate and certificate revoca-tion list (CRL) storage is evenly distributed among thesystem nodes and is implemented as a Chord put op-eration, thus balancing the storage cost. Moreover, thelookup of a certificate also exploits the Chord function-ality and is implemented through a simple Chord getoperation. Bellow we describe the specific assumptionsfor the deployment of the Chord-PKI service, as well asthe required protocols that implement the system oper-ations.
5.1. Assumptions
Before the actual operation of the Chord-PKI a boot-strapping protocol is executed asynchronously by anumber of nodes (this can be triggered by a node re-questing other nodes to participate in the bootstrapping).The nodes will partition the network identifier spaceinto a number of continuous virtual segments. We as-sume that after this partitioning, the size of each seg-ment will be publicly known to every node. We assumethat all nodes involved in the bootstrapping, are mutu-ally trusted. Furthermore, we assume that each segment
6
contains a threshold of at least t trusted nodes (a systemparameter).
Although the assumption on the initially trustednodes during the bootstrapping is a “strong” assump-tion, it is not possible to distribute and manage trust inany system, without assuming that some initial trust ex-ists. Also, this assumption is feasible in any P2P envi-ronment, since it is reasonable to expect that some nodeswill have previous off-line trust relationships (e.g. [12]).
5.2. Protocols
The Chord-PKI utilizes the following protocols tosupport the functionality of the distributed PKI service.
5.2.1. BootstrappingThe nodes participating in the bootstrapping protocol
partition the Chord identifier (ID) space into s virtualsegments, as shown in Figure 5. Thus, if the identifierspace of a Chord overlay network is [0, 2m−1], the iden-tifier space of each segment is 2m/s. The segments arecontinuous, i.e. S EGi = [(i − 1) · (2m/s), i · (2m/s) − 1],i ∈ [1, s]. The value s is a system parameter and byusing an asymptotic analysis model with an identifierspace of 2m, a realistic number of s is of order o(m) (forexample s could be 256 if SHA256 is used as a hashfunction). Suppose that after the partitioning, in eachsegment S EGi there are (at least) n ≥ 2t + 1 nodes,where t is the system threshold for trusted nodes. Thesenodes are the initial certification nodes of each segment,which in turn will be able to certify any other nodewithin S EGi, for a certain period. After this period theset of the certification nodes will be updated by othernodes.
After the partitioning of the Chord identifier space, ineach segment S EGi, i ∈ [1, s], the bootstrapping proto-col is executed. This can be performed asynchronouslywithin the segments. During this protocol, the initialn certification nodes securely generate and certify thepublic/secret segment key pair (PKi, S Ki) of S EGi, us-ing a public key cryptosystem, (such as RSA or DSS).The secret key S Ki will be used for the certification ofany existing or forthcoming node within the segmentS EGi, as described in Section 5.2.2. The public seg-ment key PKi is self-certified and is used for the veri-fication of any node certificate signed with the segmentsecret key.
The secret key S Ki of the segment S EGi is jointlygenerated by the n nodes, by using a verifiable randomsecret sharing algorithm (e.g. the Joint-Exp-RSS algo-rithm described in [43]), using a (t, n) threshold sharing,where n ≥ 2t+1. In this way, the actual secret key is not
Ci,1 (SKi,1)
Ci,2 (SKi,2) Ci,n (SKi,n)CERTi CLi Listi
CERTi CLi ListiCERTi CLi Listi
SEGs
PKi, SKiCERTi
SEG1
SEG2
SEGi
PK1, SK1CERT1
PK2, SK2CERT2
PKs, SKsCERTs
Figure 5: Partitioning the Chord and threshold sharing of the segmentkey during bootstrapping
known to any node, while any set of at least t nodes willbe able to generate a signature with S Ki. Less than tnodes will not be able to generate a valid signature. Al-ternatively, and since all the initial nodes are trusted, onenode can act as a dealer, generate and distribute the keyshares and the verification information and then discardthe secret key. At the end of this protocol, each certi-fication node Ci, j ∈ S EGi, 1 ≤ j ≤ n will have a keyshare S Ki, j of the key S Ki. After the successful sharing,the nodes (at least t of them) will use their shares to gen-erate a self-signed certificate4 CERTi = S IGS Ki (i, PKi).
After the generation of a segment’s public/secret keypair, the certification nodes of the segment should dis-tribute the public segment key PKi to all the certifica-tion nodes of the other segments. This can be achievedin several ways. For example, the certification nodescan exchange the segment public keys with out-of-bandmethods. This is scalable since only a fraction of nodesof the order o(m) need to exchange keys. Also, inP2P environments it is common that the nodes havesome form of off-line trust relationship with some othernodes, such as the first point of contact needed in or-der to join the network. Another solution is to use anode (acting as a point of contact during the bootstrap-ping), through which all the segment public keys areexchanged.
After all the certification nodes have exchanged
4All the certificates used (segment or node certificates) may beformatted following the ITU-T X.509 standard, also containing otherattributes such as certification time, expiration time etc. For simplicitywe omit these values.
7
the segment public keys, they generate and store acertified list of the public segment keys as CLi =
S IGS Ki(PK1, PK2, ...PKs) and each one stores the list.The certified list CLi is also stored at the nodes that cor-responds to the Chord identifier H(CERT i), 1 ≤ i ≤ s,where H is a cryptographically secure hashing functionused by the Chord implementation for node and Chord-key assignment [1].
Finally, in each segment, the certification nodes gen-erate a list Listi containing: the identifiers and IPaddresses of the current certification nodes, the ex-piration date and time of the current threshold shar-ing and the segment’s boundaries, i.e. List i =
[ID(Ci, j), IP(Ci, j), ThresExpT ime, IDstart−i, IDend−i],∀ j ∈ [1, n]. The list is also signed with the segmentsecret key S Ki and is exchanged between all the currentcertification nodes.
Remark: Although for simplicity the bootstrappingprotocol is assumed to take place in a single step of ex-ecution, in realistic implementations, it is possible toexecute the bootstrapping asynchronously in differentsegments at different time periods. Note however thatthe segmentation of the network shall be decided duringthe first step of the bootstrapping. Until all the segmentshave performed their bootstrapping protocol, the nodesbelonging into segments that have not yet performed thebootstrapping, will not be able to use the certificationservices.
5.2.2. Node CertificationIn order to certify the public key of a node N, the
following protocol is executed.
1. Segment identification. First, the node N identifiesthe segment S EGi to which it belongs, the numberof segments s and the segment certificates.
2. Key pair generation. The node N generates a pairof public/secret keys (pkN , skN) of a public keycryptosystem such as RSA or DSS.
3. Lookup for a certification node. The node N findsa certification node of the segment S EGi it be-longs to, according to the protocol described inSection 5.2.6. For simplicity and without loss ofgenerality, we assume that the contacted certifica-tion node is Ci,1 (i.e. the certification node of S EGi
that holds the segment secret key share S Ki,1).4. Certificate issuing. Node N sends to Ci,1 its public
key, along with a certification request and a proofof knowledge of the corresponding secret key sk N
(for example following the PKCS#10 certificate re-quest format). If Ci,1 decides to certify N, then
it can act as a combiner of a threshold signature(such as threshold RSA or DSS) and issue a certifi-cate for the node N. For this purpose, the combinergenerates a (partial) signature S IGS Ki,1 (i,N, pkN).Additionally, it contacts with t − 1 other certifica-tion nodes of its segment (these can be selectedrandomly from Listi) and requests partial signa-tures from these nodes for the message (i,N, pkN).After the combiner has received the partial sig-natures S IGS Ki,2 (N, pkN), ..., S IGS Ki,t (N, pkN), thecombiner is able to produce a valid certificate forthe node N. By combining the t partial signa-tures, the combiner generates a valid certificatecert j = S IGS Ki (i,N, pkN) for the node N.Note that if a verifiable threshold signature schemeis used, then any fault during the partial signaturegeneration – malicious or not – will be traced.
5. Verification. The combiner Ci,1 verifies the signa-ture of the certificate and if it is not valid, it repeatsthe previous step with another subset of certifica-tion nodes.
6. Certificate Delivery. The combiner sends the cer-tificate to node N. The node N stores the certificatecertN and it also stores the contact information forthe certification node Ci,1 in its local cache for fu-ture communication.
5.2.3. Certificate RevocationThe certification nodes of each segment i receive re-
vocation requests concerning nodes that belong to theirown segment, originated by certified nodes. A revoca-tion request is considered as valid only if it is signed bya certified node, which may belong to any segment. Thecertification nodes periodically examine the revocationrequests and may decide to revoke a node certificate. Inorder to revoke the certificate certN of a node N the fol-lowing protocol is executed.
1. Selection of revocation set. A certification nodeCi, j decides to act as a combiner and selects t − 1other certification nodes from Listi.
2. Revocation signing. The revocation setwill sign a revocation message revN =
S IGS Ki (certN ,RevT ime) of the public key ofthe misbehaving node, where RevT ime is thetime of the revocation. The revocation messagemust then be stored in a certificate revocation list(CRL).
8
certN –… …
CERT CRL
H(certN,1) Y1
Y2X
N
… …… …
CERT CRL
certN revN
… …
CERT CRL
YtLocal store of Yt
H(certN ,2) Y2
certN revN
… …
CERT CRLY1
Local store of Y1H(certN ,t )
Yt
certX –… …
CERT CRL
Local store of N
find Yt H(certN,t ) Local store of Y2
Local store of X
Figure 6: Distributed storage and retrieval in Chord-PKI
5.2.4. Certificate and CRL storageThe certificate and the CRL storage is distributed
among all the Chord nodes, as shown in Figure 6. Eachnode has a local certificate and CRL store and is respon-sible to retain a number of certificates of other nodes.The certificates and the CRLs are stored in a distributedmanner as follows:
1. Certificate Generation. Node N follows the pro-tocol described in 5.2.2 and acquires its certificatecertN .
2. Certificate Storage. Node N requests node Y1 tostore its certificate, where H(certN , 1)→ Y1. Thusany node that wants to verify a claimed certificateof another node, knows where the received certifi-cate should be stored.
3. CRL Storage. In the case when the certificate certN
is revoked by the certification nodes, the revoca-tion revN is also stored in the local CRL of thenode Y1 that corresponds to the Chord identifier,H(certN , 1) → Y1. Thus, any node that requires toverify a certificate certN will check the local cer-tificate and CRL store of Y.
4. Redundancy. For redundancy, the certificate cert N
or the revocation revN is stored into t insteadof one nodes. The node N selects the storagenodes (including the first storage node) Y1, ..., Yt as:H(certN , i)→ Yi, i = 1, ..., t).
5.2.5. Certificate – CRL retrieval and verificationAs explained above, a certificate and a CRL retrieval,
is the same as a Chord look up. Any node is able to
look up and verify a certificate of another node belong-ing to any segment, as shown in Figure 6. The followingprotocol is applied when node X receives a claimed cer-tificate certN presented by node N as valid.
1. Look up the appropriate storage node. The nodeX applies the Chord hash function to the claimedcertificate certN , in order to find the t storage nodesof the certificate. Without loss of generality, saythat node X starts from the first storage node Y1
(i.e. H(certN , 1)→ Y1).2. Look up the Certificate. Node X will query the cer-
tificate and CRL store of node Y1 for the particularcertificate. If the CRL store of Y1 contains a re-vocation of the certificate, then X rejects certN asrevoked. If the certificate store of Y1 does not con-tain the certificate then goto step 3, else goto step4.
3. Redundant Look up of Certificate. Look up if nodeYi → H(certN , i), i = 2, ...t contains the certificatein its store. If the certificate is found goto step 4.If not, while i ≤ t repeat this step. If after all thet storage nodes have been examined the certificateis not found, then X rejects certN .
4. Certificate Verification. Node X verifies the sig-nature of the certificate certN by using the corre-sponding segment certificate and by checking theexpiration time of the certificate. If all checks aresuccessful then the node X accepts certN as gen-uine.
5. Check for Certificate Revocation. Finally, the nodeX will check the CRL store of the rest of the t stor-age nodes (the storage nodes that were not checkedduring step 2), for a possible revocation revN of thecertificate. The certificate is considered as revokedif at least one valid (signed) revocation is found.Else, if no revocation is found, the certificate isconsidered as valid.
5.2.6. Certification node look up by ordinary nodeswithin a segment
The certification of a public key (or a revocationclaim for an issued certificate) requires the communi-cation between an ordinary node N and a certificationnode Ci, j. This can be implemented with the followingprotocol. Assume that node N wishes to find a certi-fication node of segment S EGi. Then it performs thefollowing steps:
1. Segment Identification. Node N calculates thebounds of S EGi as [(i − 1) · (2m/s), i · (2m/s) − 1].
9
2. Local Look up. The node N looks up in its fingertable for a node whose identifier falls between thesegments bounds (e.g. [(i − 1) · (2m/s) ≤ X ≤ i ·(2m/s) − 1]. If such a node exists go to step 4,otherwise continue.
3. Random Selection. Node N selects a random iden-tifier id with [(i − 1) · (2m/s) ≤ id ≤ i · (2m/s) − 1]and locate the node X that is responsible for therandom id (i.e. successor(id) = X).
4. Request Propagation. The node N sends a mes-sage to X, requesting the ID of a certification nodewithin the same segment.
5. Finding Certification Node. Node X can either be:(a) A certification node. In this case X returns its
identifier and IP address to N.(b) An ordinary node who has already been cer-
tified and has a certification node in its cache.In that case X pings its cache entry and if theentry is alive it returns to N, the identifier andthe IP address of the certification node. Oth-erwise proceeds as in step 5c.
(c) An uncertified node who does not know anycertification node. In that case X forwardsthe request to its immediate successor and theprotocol continues from step 4.
6. Request for Certification. N sends a certificationrequest to the node returned by the previous step.
5.2.7. Communication between certification nodeswithin a segment
All the certification nodes that belong to the samesegment can trivially lookup for each other, by access-ing the current list of the certification nodes Listi, gen-erated during bootstrapping (section 5.2.1) or updatedafter an updating period (section 5.2.9).
5.2.8. Communication between certification nodes ofdifferent segments
If a certification node Ci, j of the segment S EGi wantsto find a certification node Ck, j of another segmentS EGk, then it executes a protocol similar to the one de-scribed in section 5.2.6.
5.2.9. Updating the segment key sharesAt the end of the current threshold period
ThresExpT ime the certification nodes will runthe following update protocol, after which both thecertification node set and the key shares will have beenupdated.
1. Availability Check. The certification nodes ofS EGi communicate with each other to verify thatat least t nodes are active. If some nodes do notparticipate then the rest of the nodes will gener-ate their shares (i.e. through Lagrange interpo-lation), provided that at least t nodes participate.This procedure is also followed in the case wheresome nodes drop out half-way through the updat-ing. They are also treated as non-participants andthe rest of the nodes will generate their shares. Atthe end of this check all the n shares of the key willbe available.
2. Updating the Set of the Certification Nodes. Thecurrent certification nodes use a random functionto select the new set of n certification nodes withinthe segment for the next period. This can be con-structed as follows. Each certification node pro-vides a random binary string R j of sufficient lengthas an input to the hash function5. Say that theresult of the hash function is a Chord identifierID = H(R1, ...,Rn). If ID is an identifier outsidethe limits of the segment i then repeat the process.Else, the successor node for the identifier ID is acandidate certification node. In order to preventa malicious node from manipulating the candidatecertification node selection procedure, all the cur-rent certification nodes will sign their share andsend it to all the other segment certification nodes.In this way a malicious node cannot replace therandomness selected by the others. Also, a ma-licious node cannot manipulate the selection byexhaustive search, since the hash function is pre-image resistant and each share R j has sufficientlength (e.g. 256-bits). Note that if a significantportion of the input of a hash function is random,then the output is random.
(a) Lookup for the node with the identifier ID. Ifthe node has already been certified and agreesto participate, one good candidate is found.Repeat the previous step until n nodes arefound.
(b) Each old certification node is assigned to anew certification node. Then, each old certi-fication node encrypts its segment key shareS Ki with the public key of its assigned newcertification node and sends the encryptedshare to the new node, along with a proof ofcorrectness. If a share is not valid, the new
5For this purpose, a timer may be used, to provide loose synchro-nization
10
node will raise a claim and the share can bereconstructed by at least t certification nodesof the old sharing.
3. Proactive update. The new nodes will proceed ina proactive update [19] of the key shares and thenthey will verify their new shares. After the proac-tive update the old shares are discarded both by theold and the new certification nodes.
6. Security Analysis
6.1. Threat Model
Our threat model assumes a Byzantine adversary.All entities, including the adversary, have polynomi-ally bounded resources. We distinguish between twotypes of entities: trusted and untrusted. Trusted entitiesbehave as expected (adhere to protocol requirements).Untrusted entities may deviate from their expected be-havior. An untrusted entity is malicious if it activelyattempts to undermine the security of the system, e.g.,it attempts to disrupt message delivery or to manipulatethe certification procedure. Compromised entities areuntrusted entities whose private keys have been com-promised by the adversary.
All the untrusted entities are controlled by the adver-sary. We consider both passive and active adversaries.A passive adversary will only eavesdrop on the mes-sages exchanged by the entities. An active adversarymay also corrupt or inject messages.
To deal with such adversaries we shall use appro-priate cryptographic mechanisms. We will assume thatthe number of untrusted entities is bounded, less than aconstant t— a system parameter, and will use thresholdcryptography and redundancy to guarantee the securityof our protocols.
6.2. Security of the Chord-PKI
We examine how the proposed Chord-PKI infrastruc-ture satisfies the security requirements given in sec-tion 3.2, against the examined adversarial model. Weanalyze the security of the Chord-PKI in two layers;(i) security of the key management services providedby Chord-PKI (i.e. application-layer security) and (ii)security against Chord routing attacks (i.e. network-layer). Application layer security shows the robustnessof the proposed infrastructure, while network layer se-curity analysis shows the availability and reliability ofthe Chord-PKI in the presence of denial of service at-tacks on the underlying network infrastructure.
6.2.1. Security of the key management services
a) Resilience to untrusted nodes. Within each seg-ment, the certification nodes are responsible to is-sue/revoke certificates, for a certain time period. At theend of the certification period, the set of the certifica-tion nodes of each segment is replaced by a new set ofnodes. We examine the resilience of the Chord-PKI tountrusted nodes, both during the certification (working)periods and during the certification set updating periods.
Theorem 1 (Resilience during the certification periods).If the number of untrusted nodes within a certificationnode set is less than t, then the certification/revocationprocess provided by Chord-PKI cannot be controlled bythe adversary.
Proof. This follows directly from the fact that a (t, n)threshold system is used. Thus, in order to prove the re-siliency of the system during the certification periods, itsuffices to prove that for a given probability distributionp of untrusted nodes, the adversary can control x ≥ tcertification nodes only with negligible probability, if aproper threshold setting (t, n) is applied. We use prob-ability theory, in order to compute the proper (t, n) set.During a certification period, any node within a segmentcan either belong to the trusted or to the untrusted set.Since the nodes may change from one state to the otherduring their lifetime, we assume that within a period anode may belong to the untrusted set with a probabilityno more than p, while it may belong to the trusted setwith a probability of q = 1 − p.
In each working period, n nodes out of the segmentset have been randomly selected6 to act as certificationnodes. Since the nodes may be re-selected in a fu-ture period, we use the binomial probability distribu-tion. Thus the probability that x out of the n selectednodes belong to the untrusted set is given by the equa-tion:
Pr(P = x) =
(nx
)pxqn−x. (1)
The cumulative probability that at most t − 1 out ofthe n certification nodes belong to the untrusted set canbe computed as:
Pr(P < t) =t−1∑x=1
(nx
)pxqn−x. (2)
6Random selection is guaranteed since in the certification updateprocess, the certification nodes are selected randomly – see Theorem2.
11
p = 0 (trusted set)
p = 0.1 p = 0.2 p = 0.3
(6, 13) 1 > 0.999 > 0.969 > 0.834 (12, 25) 1 > 1 – 1.49·10-6 > 0.998 > 0.955 (24, 49) 1 > 1 – 5.10·10-12 > 1 – 5.30·10-6 > 0.995 (48, 97) 1 > 1 – 8.30·10-23 > 1 – 8.50·10-11 > 1 – 4.5·10-5
(96, 193) 1 > 1 – 2.95·10-44 > 1 – 3.02·10-20 > 1 – 7.5·10-9
Threshold scheme (t, n)
Probability p ofuntrusted
nodes
Table 1: Probability of selecting less than t untrusted certificationnodes for various distributions of untrusted nodes
By using Equation 2 we can compute, for given val-ues of p, n and t the probability Pr(P < t) ≥ 1 − εwhere ε is negligible. Table 1 shows the probability thatat most t − 1 untrusted nodes belong to the threshold setfor various threshold settings (t, n) and for various dis-tributions p of untrusted nodes. For example, in a net-work where the expected population of untrusted nodesis at most p = 0.2, an (24, 49) threshold setting guaran-tees with probability Pr(P < 24) ≥ 1 − 5.3 × 10−6, thatthe certification process cannot be practically compro-mised.
Thus, the proposed Chord-PKI architecture is re-silient to untrusted nodes, for appropriate values (t, n)of threshold sets.
Theorem 2 (Resilience during the certification set up-dating). If at least one certification node is honest dur-ing the updating period of the certification set, then theadversary cannot control the selection of the new certi-fication nodes.
Proof. Recall from Section 5.2.9 that during the updat-ing of the certification nodes’ set, each old certificationnode participates in the selection of candidate certifi-cation nodes, by contributing a random input R j to thehash function. The identifier of a candidate node for thenew set is derived from the output ID = H(R1, ...,Rn)where each old certification node contributes a statisti-cally independent random input. In order to prevent amalicious node from manipulating the random input tothe hash function, all the current certification nodes signtheir share R j and send it to all the other segment certifi-cation nodes. Thus, a malicious node cannot replace therandomness selected by the others. Obviously the ad-versary cannot control the selection of a candidate nodewith an identifier of his choice, even if at least one nodeis honest and provides a truly random input. Further-more, the adversary cannot manipulate the selection byexhaustive search, since the hash function is pre-imageresistant and each share R j has sufficient length (e.g.256 bit).
b) Unforgeability. This comes directly from the sys-tem’s resilience to untrusted nodes. Since the adver-sary is polynomially bounded, forging a certificate (ora CRL) requires that the adversary controls at least tcertification nodes of a segment within a threshold pe-riod. However, as shown before, this is possible onlywith a negligible probability, for properly selected (t, n)parameters. Therefore, the adversary cannot generatesignatures with the segment secret key and thus forgecertificates.
c) Proactive security. The Chord-PKI provides proac-tive security, since an active adversary cannot com-bine key shares from certification nodes which havebeen compromised in different threshold periods, as itis shown by the following theorem.
Theorem 3 (Limitation of the attack time-frame). Theadversary can successfully forge a signature, only if hecan forge x ≥ t certification nodes within a thresholdperiod.
Proof. Recall from Section 5.2.9 that during the cer-tification set updating period, after the new thresholdcertification set has been selected, the old nodes proac-tively refresh their shares by adding sharings of zero.Then, the refreshed shares are securely transferred tothe new certification nodes along with a proof of cor-rectness (each new node receives one share) and the oldshares are discarded. In this way, an active adversarywho has compromised key shares in a period i cannotcombine them with shares compromised in period j > iin order to construct the segment signature key, sincethe adversary will not know the zero sharing containedin each refreshed key share. Thus, the adversary cansuccessfully attack the segment signature key only if hecompromises at least t shares within the same thresholdperiod.
d) Availability of certificate storage. We examine thedenial of service attacks from untrusted storage nodes,which refuse to provide certificates of other nodes fromtheir local store. Chord-PKI preserves availability inthe presence of malicious storage nodes through redun-dancy. The certificate (or the revocation of a certifi-cate) of each certified node is stored into the t distinctnodes, indicated by IDi = H(certN , i) i = 1...t, as de-scribed in 5.2.4. Since each certificate is stored intot nodes, the requested certificate can be retrieved if atleast of them is trusted. Note that since the storagenodes are randomly selected by applying the collision-resistant hash function and since nodes may be selectedmultiple times, by applying the binomial distribution
12
the probability that all t storage nodes are untrustedis given by Pr(P = t) = pt. For example, with anexpected population of untrusted nodes p = 0.2, andfor a (24, 49) threshold setting, the probability that allt nodes storing a requested certificate are untrusted isPr(P = 24) = 0.224 ≈ 1.6×10−17. Thus, it is practicallyimpossible for the adversary to control all of them, for agiven certficate.
6.2.2. Security against routing attacksSince messages related with the Chord-PKI key man-
agement functionality are signed and encrypted beforethey are exchanged between nodes, the security attacksof the network layer basically involve routing attacksagainst the availability of the infrastructure, i.e. thelookup of the stored certificates. Chord inherently pro-vides availability in the case of non-malicious faults,since if a node is not available at a given time, the firstsuccessor of this node automatically takes over the roleof the failed node, through the Chord stabilization pro-tocol. However, in our adversarial model we also con-sider malicious nodes that may attack routing in twoways: a) deliberately provide incorrect routing lookupand b) deliberately provide incorrect routing update.We examine the availability of the infrastructure for theaforementioned routing attacks.
a) Protection from incorrect routing lookups.We examine how Chord-PKI addresses incorrect
routing lookup attacks. By using an iterative implemen-tation of Chord, the initial node performing a lookup(the requesting node) can always monitor the lookupprocess. In each hop of the lookup, the requesting nodechecks whether the request is getting closer to the des-tination until the requested data are returned. If the dis-tance towards the destination is not decreased at eachhop, the initial node can select another entry from itsrouting table to forward the query from an alternativepath. The probability that an alternative path from therequesting node to the destination exists is high, if themalicious nodes cannot select their location (i.e. Chordidentifiers). Since in Chord-PKI the node identifier isderived by applying a pre-image resistant hash functionover the node IP address, a malicious node cannot se-lect an ID of its choice. We consider a system withN nodes, where the untrusted nodes are randomly dis-tributed around the identifier space with probability p,0 ≤ p ≤ 1. We examine the probability of successfulcertificate lookup.
The probability of successful communication be-tween two honest nodes (the node requesting a certifi-cate and the node storing the certificate) is Ps = (1−p)h,
where h is the average path length (h = 1/2log 2N inChord). In case of failure, the initial node can forwardthe query to another routing table entry. Each chordnode has k = logN [1] entries in its routing table. Anode will fail to lookup a certificate if and only if all itsrouting table entries are compromised. This probability
can be computed as Pr(x = k) =
(kx
)(1 − Ps)xPk−x
s .
Thus, the probability of finding at least one valid pathtowards the destination is P(x < k) = 1 − Pr(x = k).Since each certificate is replicated into t storage nodes,the probability of finding at least one valid certificate is1 − Pr(x = k)t. For example in a network with N =1024 nodes, a fraction of untrusted nodes p = 0.2 andan (6, 13) threshold setting, the probability of finding atleast one valid certificate is approximately 1−4.5×1011.
b) Protection from incorrect routing table updates.Since any node builds its routing table by consult-
ing others, a malicious node may corrupt the routingtables by sending incorrect routing updates. The mostvulnerable time for incorrect routing update attacks isduring the joining operation. Since at this time joiningnodes do not know anything about the overlay topol-ogy, they are at the mercy of their bootstrap node forbuilding their routing tables. In such a scenario, a ma-licious node could provide routing table entries point-ing to other malicious nodes and thus totally eclipse thehonest node from the rest of the network. This attackcan be prevented, by requiring that the join procedure isperformed by the certification nodes. Recall from sec-tion 5.2.1 that for each segment i the certified list List i,provides the location of the current certification nodes.
Also, during the working period, a malicious nodecould return a routing update entry pointing to a wrongor non existent node. A node receiving such updates caneasily detect them by contacting the node to the claimedIP address and port number.
In addition, a malicious node could return routing ta-ble entries pointing to a distant, but honest node. Thisattack is possible but it can only affect the performanceof the lookup. Furthermore, if the returned entries pointto other malicious nodes, then a portion of the routingtables are controlled by the attackers. If these routingentries remain undetected, the probability of incorrectrouting table entries, increases in each update of therouting table. In particular, in a network where the frac-tion of untrusted nodes (returning incorrect routing tableentries) is p, then the probability that a routing table en-try (of an honest node) is faulty is P f = p + (1 − p) p.Since in a chord network with N nodes, each routingtable contains approximately k = logN distinct entries,
13
Key Generation
(sec)
Partial Signature
Generation (sec)
Signature
Verification (sec)
Threshold
set
msg
1024
msg
2048
msg
4096
msg
8192
msg
1024
msg
2048
msg
4096
msg
8192
msg
1024
msg
2048
msg
4096
msg
8192
(6, 13) 3.38 2.60 2.52 3.62 1.17 1.12 1.13 1.18 1.07 1.02 1.05 1.12
(12, 25) 3.66 3.65 3.45 2.99 2.30 2.30 2.30 2.35 2.17 2.06 2.05 2.13
(24, 49) 4.43 4.33 4.64 4.76 5.03 4.93 4.93 4.92 4.60 4.46 4.37 4.35
(48, 97) 6.98 7.29 7.10 7.68 11.92 12.33 12.67 12.14 9.72 10.17 9.98 10.02
(96, 193) 15.56 17.50 16.58 15.54 38.02 41.68 40.55 36.74 28.45 30.44 29.79 27.18
Table 2: Computational costs of the threshold signature scheme: Keygeneration, signing and verification
then the probability that a node is eclipsed from the restof the network is Pr(x = k) = (P f )k = (p + (1 − p) p)k.For k = 10 and p = 0.2 this probability is approximately3.6 × 10−5.
In theory, in each routing table update operation theprobability that a routing entry is incorrect may be in-creased, if each node does not verify the correctness ofeach entry. Since the routing table entries are used to ef-fectively lookup certificates, an honest node can alwaysdetermine if an entry of its routing table points to a validpath towards a valid certificate. If this is not the case,then this entry is recorded (not to be used in subsequentrouting table updates) and removed from the routing ta-ble.
7. Evaluation-Simulations
7.1. Computation costs
In order to evaluate the efficiency of the proposed sys-tem, we have implemented an RSA threshold signaturescheme with 1024 bit modulus in two variations; a ba-sic threshold scheme and a verifiable (robust) thresholdscheme, where each partial signature can be verified. Inthe second case, malicious nodes participating in a cer-tification set can be identified and excluded. Since alarge-scale P2P network will be based on typical com-puters, we run our experiments on a typical workstationwith a Pentium IV processor at 2.8GHz.
Then, we run a set of simulation scenarios for thethreshold sets, (t, n) of (6, 13), (12, 25), (24, 49),(48, 97) and (96, 193). We evaluated the computationand communication costs for a Chord network consist-ing of s = 256 segments, while each segment containsup to 10, 000 nodes. Since the network must be resilientto malicious nodes, we evaluated scenarios of networkswhere the probability of a node belonging to the un-trusted node set ranges from p = 0% (a trusted nodesscenario) up to 30%. All the scenarios were tested bothfor the basic and for the verifiable threshold scheme.
The computational costs for the basic threshold sig-nature scheme is presented in table 2. In particular, wemeasure the processing time required to generate thekeys, the time required to sign a message (processingtime of t partial signatures) of variable length (1K, 2K,4K and 8K) and the processing time required to verifythe signature. The times presented are the mean timesof the 10, 000 operations that where executed. As il-lustrated in table 2 the processing times are indepen-dent from the message size. The results show that allthe examined threshold sets are applicable for a real-time system. For example in the (96, 193) threshold set,the processing time for a node certification is approxi-mately one minute, while in the (24, 49) threshold set,the processing time is approximately 15 seconds (with-out considering the communication delay). This orderof cost can be considered as reasonable time, since thecertification occurs only once per user.
The signing and verification costs for a verifiablethreshold scheme are multiplied with a factor of 2. Al-though, in the verifiable threshold scheme the time toacquire a certificate is doubled in respect to the typicalscheme, the costs for the partial signatures in the pres-ence of malicious nodes (which are presented bellow),show that the verifiable scheme is the only viable solu-tion.
In figures 7 (a) and (b), we show the number of par-tial signatures required to certify 10, 000 nodes underthe basic threshold scheme for various settings. It canbe observed that even with a small percentage of mali-cious nodes the number of partial signatures is signif-icantly increased for all the examined threshold sets.The exponential increase in the number of partial sig-natures can be justified by the fact that under the basicthreshold scheme, the combiner cannot identify the ma-licious certification nodes that produce the invalid sig-natures, hence cannot exclude them from the next se-lection. Note that if the percentage of malicious nodesp exceeds 10% of the population the basic thresholdscheme is practically unusable.
In order to make the system usable under the pres-ence of a large number of malicious nodes we use a ver-ifiable threshold scheme, where the combiner can verifythe validity of each partial signature and exclude the ma-licious node from future selections. As we can observefrom the results in Figure 8, the number of partial sig-natures is substantially smaller from the basic thresholdscheme.
7.2. Communication costsIn order to measure the communication costs of the
certification procedure we examine the number of mes-
14
46797337 7360
15560
30165
4800
8465
0
5000
10000
15000
20000
25000
30000
35000
Percentage p of untrusted nodes
Par
tial s
igna
ture
s pe
r no
de
6, 13 4615 4679 7337 7360
12, 25 4800 8465 15560 30165
0% 10% 20% 30%
(a) (6, 13) and (12, 25) threshold sets
2472091
17872 68396
557131
737244948
2543107
0
500000
1000000
1500000
2000000
2500000
3000000
Percentage p of untrusted nodes
Par
tial s
igna
ture
s pe
r no
de
24, 49 4897 17872 68396 557131
48, 97 4948 73724 2472091 19776728
96, 193 4974 2543107 20344856
0% 10% 20% 30%
(b) (24, 49), (48, 97) and (96, 193) threshold sets
Figure 7: Basic threshold signature scheme: partial signatures pernode vs percentage of malicious nodes
6162 6187
13623
18983
21808
46234615
6858 8906 10911
16984
950113330
19171
23948 25976
0
5000
10000
15000
20000
25000
30000
Percentage p of untrusted nodes
Parti
al s
igna
ture
s pe
r nod
e
6, 13 4615 4623 6162 6187
12, 25 4800 6858 8906 10911
24, 49 4897 9501 13330 16984
48, 97 4948 13623 18983 21808
96, 193 4974 19171 23948 25976
0% 10% 20% 30%
Figure 8: Verifiable threshold signature scheme: partial signatures pernode vs percentage of malicious nodes
sages exchanged between the certification nodes in or-der to certify 10, 000 nodes within a segment.
As it is shown in Figures 9 and 10 the use of the basicthreshold scheme is not suitable under the presence of
38456590
15260
30437
668038844400
8008
0
5000
10000
15000
20000
25000
30000
35000
Percentage p of untrusted nodes
Mes
sage
s pe
r nod
e
(6, 13) 3845 3884 6680 6590
(12, 25) 4400 8008 15260 30437
0% 10% 20% 30%
(a) (6, 13) and (12, 25) threshold sets
532496
4692 18446 6624079571
2416693
4845
2429815
0
500000
1000000
1500000
2000000
2500000
3000000
3500000
4000000
4500000
5000000
Percentage p of untrusted nodes
Mes
sage
s pe
r nod
e(24, 49) 4692 18446 66240 532496
(48, 97) 4841 79571 2416693 21750237
(96, 193) 4845 2429815 21868335
0% 10% 20% 30%
(b) (24, 49), (48, 97) and (96, 193) threshold sets
Figure 9: Basic threshold signature scheme: average messages pernode vs percentage of malicious nodes
38656336
833810472
9286
13125
16780
13520
18733
21641
18415
2411125227
3845
5305 53154400
0
5000
10000
15000
20000
25000
30000
Percentage p of untrusted nodes
Mes
sage
s pe
r nod
e
(6, 13) 3845 3865 5305 5315
(12, 25) 4400 6336 8338 10472
(24, 49) 4692 9286 13125 16780
(48, 97) 4841 13520 18733 21641
(96, 193) 4845 18415 24111 25227
0% 10% 20% 30%
Figure 10: Verifiable threshold signature scheme: average messagesper node vs percentage of malicious nodes
malicious nodes. The results follow the same patterns asin the case of the partial signatures experiments. Thus,the use of the verifiable threshold is prefered.
15
7.3. Certificate lookup and verification costs
In the case of non-malicious faults, the cost for a cer-tificate (or revocation) lookup is equal to the cost of anordinary Chord lookup, which is logarithmical to thenumber of nodes. In case of malicious storage nodes,a lookup may take up to t times the cost of an ordinarylookup, since a certificate can be stored to the t succes-sor nodes indicated by the hash function.
The verification cost of a node certificate is equal tothe cost of an ordinary signature verification, in the casewhere the certificate has not been revoked. For the ver-ification of the revocation, a second signature verifica-tion is required.
8. Conclusions
In this paper we propose Chord-PKI, a decentralizedPKI that exploits the characteristics of the Chord proto-col in order to meet the requirements of P2P networks,namely scalability, efficiency and resilience to compro-mised nodes. Our system provides certification to theChord nodes through a distributed protocol that enablesthe collaboration of the nodes themselves, without theneed for an external PKI. By relying on cryptographictechniques such as threshold cryptography our systemcan tolerate a significant fraction of malicious nodeswithin each segment. Moreover, by segmenting the net-work, the possible damage will be restrained within onesegment. By exploiting the natural load balance prop-erty of the consistent hash function of Chord the certifi-cates and CRL storage is evenly distributed among thesystem nodes. The lookup for a certificate (or CRL) isaccomplished in log2 N steps, where N is the number ofnodes in Chord-PKI.
An important issue for any trust infrastructure suchas the Chord-PKI is fine-tuning the trust and revocationmodels. Several papers in the literature use reputationmodels for P2P systems [32, 35, 44] to address these is-sues. Unfortunately, many of these have open scalabil-ity issues when the number of nodes is large. Thus, it isimportant to design a trust model which fine-tunes certi-fication and revocation decisions and which exploits thescalability and functionality distribution provided by theChord-PKI.
[1] I. Stoica, R. Morris, D. Liben-Nowell, D. Karger, F. Dabek,H. Balakrishnan, Chord: a scalable peer-to-peer lookup protocolfor internet applications, IEEE/ACM Transactions on Network-ing 11 (1) (2003) 17–32.
[2] S. Ratnasamy, P. Francis, M. Handley, R. Karp, S. Schenker,A scalable content-addressable network, SIGCOMM Comput.Commun. Rev. 31 (4) (2001) 161–172.
[3] A. I. T. Rowstron, P. Druschel, Pastry: Scalable, decentralizedobject location, and routing for large-scale peer-to-peer systems,in: Middleware ’01: Proceedings of the 1st IFIP/ACM Interna-tional Conference on Distributed Systems Platforms, Vol. 2218,Springer Berlin / Heidelberg, Heidelberg, Germany, 2001, pp.329–350.
[4] FIPS 180-2: Secure hash standard (August 2002).URL http://csrc.nist.gov/publications/fips/
fips180-2/fips180-2withchangenotice.pdf
[5] J. Risson, T. Moors, Survey of research towards robust peer-to-peer networks: Search methods, Elsevier Computer Networks50 (17) (2006) 3495–3521.
[6] M. Castro, P. Druschel, A. Ganesh, A. Rowstron, D. S.Wallach, Secure routing for structured peer-to-peer overlaynetworks, SIGOPS Oper. Syst. Rev. 36 (2002) 299–314.doi:http://doi.acm.org/10.1145/844128.844156.
[7] E. Sit, R. Morris, Security considerations for peer-to-peer dis-tributed hash tables, in: Peer-to-Peer Systems - IPTPS 2002Proceedings, Vol. 2429 of LNCS, Springer Berlin / Heidelberg,Heidelberg, Germany, 2002, pp. 261–269.
[8] D. S. Wallach, A survey of peer-to-peer security issues, in: Soft-ware Security - Theories and Systems - ISSS 2002, Vol. 2609 ofLNCS, Springer Berlin / Heidelberg, Tokyo, Japan, 2002, pp.253–258.
[9] M. Srivatsa, L. Liu, Vulnerabilities and security threatsin structured overlay networks: A quantitative analy-sis, in: ACSAC ’04: Proceedings of the 20th AnnualComputer Security Applications Conference, IEEE Com-puter Society, Washington, DC, USA, 2004, pp. 252–261.doi:http://dx.doi.org/10.1109/CSAC.2004.50.
[10] W. Heinbockel, M. Kwon, Phyllo: a peer-to-peer overlay secu-rity framework, in: NPSec 2005: 1st IEEE ICNP Workshop onSecure Network Protocols, 2005, pp. 43–48.
[11] T. Condie, V. Kacholia, S. Sankararaman, J. Hellerstein, P. Ma-niatis, Induced churn as shelter from routingtable poisoning, in:NDSS’06:Proceedings of the 13th Annual Network and Dis-tributed System Security Symposium, 2006.
[12] G. Danezis, C. Lesniewski-Laas, M. F. Kaashoek, R. Ander-son, Sybil-resistant dht routing, in: Computer Security - ES-ORICS’05 Proceedings, Vol. 3679 of LNCS, Springer Berlin /Heidelberg, 2005, pp. 305–318.
[13] C. Hota, J. Lindqvist, K. Karvonen, A. Yla-Jaaski, M. C.K.J,Safeguarding against sybil attacks via social networks and mul-tipath routing, in: Networking, Architecture, and Storage, 2007.NAS 2007. International Conference on, IEEE Computer Soci-ety, Los Alamitos, CA, USA, 2007, pp. 122–132.
[14] N. Borisov, Computational puzzles as sybil defenses, in: P2P’06: Proceedings of the Sixth IEEE International Conference onPeer-to-Peer Computing, IEEE Computer Society, Los Alami-tos, CA, USA, 2006, pp. 171–176.
[15] A. Singh, M. Castro, P. Druschel, A. Rowstron, Defendingagainst eclipse attacks on overlay networks, in: 11th work-shop on ACM SIGOPS European workshop Proceedings, ACM,2004, p. 21. doi:http://doi.acm.org/10.1145/1133572.1133613.
[16] C. Lesniewski-Laas, M. F. Kaashoek, Whanau: A sybil-proofdistributed hash table, in: Symposium on Networked SystemDesign and Implementation, San Jose, California, 2010.
[17] A. Avramidis, P. Kotzanikolaou, C. Douligeris, Chord-PKI: Em-bedding a public key infrastructure into the chord overlay net-work, in: Public Key Infrastructure - EuroPKI’07 Proceedings,Vol. 4582 of LNCS, Springer Berlin / Heidelberg, 2007, pp.354–361.
[18] Y. Desmedt, Y. Frankel, Threshold cryptosystems, in: Advancesin Cryptology - Crypto ’89 Proceedings, Vol. 435 of LNCS,Springer Berlin / Heidelberg, Heidelberg, Germany, 1990, pp.
16
307–315.[19] A. Herzberg, M. Jakobsson, S. Jarecki, H. Krawczyk, M. Yung,
Proactive public key and signature systems, in: CCS ’97: Pro-ceedings of the 4th ACM conference on Computer and commu-nications security, ACM, New York, NY, USA, 1997, pp. 100–110.
[20] Neonet, http://www.neonetwork.com.[21] Bittorrent, http://www.bittorrent.com.[22] F. Dabek, M. F. Kaashoek, D. Karger, R. Morris,
I. Stoica, Wide-area cooperative storage with cfs,SIGOPS Oper. Syst. Rev. 35 (5) (2001) 202–215.doi:http://doi.acm.org/10.1145/502059.502054.
[23] A. Muthitacharoen, R. Morris, T. M. Gil, B. Chen, Ivy: aread/write peer-to-peer file system, in: OSDI ’02: Proceed-ings of the 5th symposium on Operating systems design andimplementation, ACM, New York, NY, USA, 2002, pp. 31–44.doi:http://doi.acm.org/10.1145/1060289.1060293.
[24] I. Stoica, D. Adkins, S. Zhuang, S. Shenker, S. Surana, In-ternet indirection infrastructure, in: SIGCOMM ’02: Pro-ceedings of the 2002 conference on Applications, technolo-gies, architectures, and protocols for computer communi-cations, ACM, New York, NY, USA, 2002, pp. 73–86.doi:http://doi.acm.org/10.1145/633025.633033.
[25] M. Castro, P. Druschel, A.-M. Kermarrec, A. Rowstron, Scribe:a large-scale and decentralized application-level multicast in-frastructure, Selected Areas in Communications, IEEE Journalon 20 (20) (2002) 1489–1499.
[26] A. Rowstron, P. Druschel, Storage management and cachingin past, a large-scale, persistent peer-to-peer storage util-ity, SIGOPS Oper. Syst. Rev. 35 (5) (2001) 188–201.doi:http://doi.acm.org/10.1145/502059.502053.
[27] M. J. Freedman, E. Freudenthal, D. Mazires, Democratizingcontent publication with coral, in: NSDI’04: 1st USENIX/ACMSymposium on Networked Systems Design and Implementa-tion, USENIX, 2004, pp. 239–252.
[28] Gnunet, http://www.gnunet.org.[29] T. Wolfl, Public-key-infrastructure based on a peer-to-peer net-
work, in: HICSS ’05: Proceedings of the 38th Annual HawaiiInternational Conference on System Sciences, Vol. 7, IEEEComputer Society, Washington, DC, USA, 2005, p. 200.1.doi:http://dx.doi.org/10.1109/HICSS.2005.514.
[30] U. M. Maurer, Modelling a public-key infrastructure, in: Com-puter Security - ESORICS ’96 Proceedings, Vol. 1146 of LNCS,Springer Berlin / Heidelberg, 1996, pp. 325–350.
[31] F. Lesueur, L. Me, V. V. T. Tong, An efficient distributed PKIfor structured P2P networks, in: Proceedings of the 9th Inter-national Conference on Peer-to-Peer Computing (P2P), IEEEComputer Society, Seattle, USA, 2009.
[32] S. D. Kamvar, M. T. Schlosser, H. Garcia-Molina, The eigen-trust algorithm for reputation management in P2P networks, in:WWW ’03: Proceedings of the 12th international conference onWorld Wide Web, ACM Press, New York, NY, USA, 2003, pp.640–651.
[33] L. Xiong, L. Liu, Peertrust: supporting reputation-based trustfor peer-to-peer electronic communities, Knowledge and DataEngineering, IEEE Transactions on 16 (7) (2004) 843–857.
[34] R. Zhou, K. Hwang, Powertrust: A robust and scalable repu-tation system for trusted peer-to-peer computing, Parallel andDistributed Systems, IEEE Transactions on 18 (4) (2007) 460–473.
[35] B. Yu, M. Singh, K. Sycara, Developing trust in large-scale peer-to-peer systems, in: IEEE First Symposium on Multi-Agent Se-curity and Survivability, 2004, 2004, pp. 1–10.
[36] K. Aberer, Z. Despotovic, Managing trust in a peer-2-peer in-formation system, in: CIKM ’01: Proceedings of the tenth
international conference on Information and knowledge man-agement, ACM, New York, NY, USA, 2001, pp. 310–317.doi:http://doi.acm.org/10.1145/502585.502638.
[37] M. Bellare, S. Miner, A forward-secure digital signaturescheme, in: Advances in Cryptology - Crypto 99 Proceedings,Vol. 1666/1999 of LNCS, Springer Berlin / Heidelberg, Heidel-berg, Germany, 1999, p. 786.
[38] Y. Frankel, P. Gemmell, M. Yung, Witness based cryptographicprogram checking and robust function sharing, in: Proceedingsof the 28th Annual Symposium on Theory of Computing, ACM,1996, pp. 499–508.
[39] R. Gennaro, S. Jarecki, H. Krawczyk, T. Rabin, Robust thresh-old RSA, in: Advances in Cryptology – Crypto’96 Proceedings,Vol. 1109 of LNCS, Springer Berlin / Heidelberg, Santa Bar-bara, California, USA, 1996, pp. 157–172.
[40] T. P. Pedersen, A threshold cryptosystem without a trusted party,in: Advances in Cryptology – Eurocrypt’91 Proceedings, Vol.547 of LNCS, Springer Berlin / Heidelberg, Brighton, U.K.,1991, pp. 522–526.
[41] A. Herzberg, S. Jarecki, H. Krawczyk, M. Yung, Proactive secretsharing or: How to cope with perpetual leakage, in: Advancesin Cryptology - Crypto’95 Proceedings, Vol. 963 of LNCS,Springer Berlin / Heidelberg, Santa Barbara, California, USA,1995, pp. 339–352.
[42] Y. Desmedt, S. Jajodia, Redistributing secret shares to new ac-cess structures and its applications, Technical Report ISSE TR-97-01, George Mason University (1997).
[43] R. Gennaro, S. Jarecki, H. Krawczyk, T. Rabin, Robust Thresh-old DSS Signatures, Inf. Comput. 164 (1) (2001) 54–84.
[44] A. Datta, M. Hauswirth, K. Aberer, Beyond web of trust: en-abling P2P e-commerce, in: CEC 2003. IEEE International Con-ference on E-Commerce, 2003., 2003, pp. 303–312.
17
