1 / 48

Membership Control in P2P and MANETs

Membership Control in P2P and MANETs. Nitesh Saxena, Gene Tsudik, Jeong H. Yi Computer Science Department University of California at Irvine {nitesh, gts, jhyi}@ics.uci.edu. Outline. Introduction and Motivation Admission Control Distributed Cryptography System Design and Integration

neylan
Download Presentation

Membership Control in P2P and MANETs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Membership Control in P2P and MANETs Nitesh Saxena, Gene Tsudik, Jeong H. Yi Computer Science Department University of California at Irvine {nitesh, gts, jhyi}@ics.uci.edu

  2. Outline • Introduction and Motivation • Admission Control • Distributed Cryptography • System Design and Integration • Performance Evaluation • Conclusion

  3. Distributed and scalable security services required Peer Group Settings • Common in MANETs and Internet • At many protocol layers • Many applications • No centralized control • No hierarchy • Fault-tolerant • Dynamic membership Decentralized P2P MANETs

  4. P2P Security: Prior Work Secure communication: • Key management • Authentication • Anonymity • Secure routing

  5. Key Management E D F A C B

  6. Sybil attack • Douceur [IPTPS’02] • An adversary may createmultiple identities G I A3 A3 D B H E A2 A2 J C F A1 A1 Lesson: Verify identities

  7. Motivation • Secure group communication does not address membership eligibility • Without secure admission control, secure communication (e.g., key management) is useless

  8. Outline • Introduction and Motivation • Admission Control • Distributed Cryptography • System Design and Integration • Performance Evaluation • Conclusion

  9. Group Membership Issues • Naming: • Nameownership? Location? • Presence: • on-line: e.g., replicated servers, MANETs • off-line: e.g., Gnutella, MANETs • Membership: • Static, ad hoc: reflected where? • Enumerated • Dynamic: admission rules/policies? • Longevity: • Long-term • Transient

  10. What does a prospective member know? • Group name, at least… • Group location? • Group membership? • Group charter/policy? • Group member(s)’ name(s)/address(es)?

  11. Threshold Sig. Algo Dealer etc. Terminology • Group Charter • defines admission policies • Group Membership Certificate (GMC) • proves membership • Group Authority (GAUTH) • Bootstrapping entity

  12. Admission Control Models • Admission via Public ACL • Not suitable for dynamic peer groups • Admission by Centralized Authority • Not suitable for dynamic peer groups • Single point of failure • Admission by Members  our focus

  13. Vote2 Vote1 Mnew Vote2 Vote2 Admission Control • New member (Mnew) wants to join the group • A quorum of t current members need to issue Mnew a group membership certificate (GMC) • If no quorum, membership is denied • Step 1: Join request • Step 2: Join commit (Vote) Mnew • Step 3: GMC issuance & share acquisition

  14. Threshold Types • Fixed Threshold • Expressed as minimum # of votes (e. g., 5) • What if group size < threshold? • Dynamic Threshold • Expressed as percentage of # of current members (e.g., 30%) • Threshold = percentage * group size • Need to keep accurate state of up-to-date group size • Group Authority (GAUTH),as bootstrapping node, is only trusted to keep account of group size.

  15. Relevant crypto techniques • Plain signatures • ASMs • Aggregated Signatures • Threshold Signatures • Static • Dynamic • Group signatures

  16. Plain Signatures • Inefficient in bw/space • Efficient in generation/verification • Can be gathered asynchronously • Can be used to prove membership • No membership awareness • Accountability • Limited anonymity • Linkable • Lineage problem!

  17. Accountable sub-Group Multi-Signatures • Due to Ohta, et al. (CCS’01) • Based on aggregating Schnorr signatures • Efficient (but still linear in size) • Synchronous (on-line protocol) • Membership awareness • Can be used to prove membership • Accountability • Limited anonymity • Linkable • Lineage Problem!

  18. Threshold Signatures • Desmedt/Frankel (1989) and many others • Usually fixed t • Function sharing to avoid reconstruction • Inefficient • Synchronous (on-line protocol) • Membership awareness (partial) • No Accountability • Limited anonymity • Linkable? • (Usually) need trusted dealer to set up • No lineage problem!

  19. Dynamic Threshold Signatures • Frankel, et al. (FOCS’97) • Shrinkable t • Very inefficient • Synchronous (on-line protocol) • Membership awareness (partial) • No Accountability • Limited anonymity • Linkable? • Still need trusted dealer

  20. Dynamic Threshold Signatures • Kong, et al. (ICNP’01) • Supports growing t • Efficiency unclear • Synchronous (on-line protocol) • Membership awareness (partial) • No Accountability • Limited anonymity • Linkable? • Still need trusted dealer to set up

  21. Group Signatures • Chaum & Van Heijst (1991) and many others • Inefficient • Asynchronous • No membership awareness • Can be used to prove membership • Accountability (off-line, by Gr. Mgr) • Anonymity • Unlinkable (except by Gr. Mgr)

  22. Outline • Introduction and Motivation • Admission Control • Distributed Cryptography • System Design and Integration • Performance Evaluation • Conclusion

  23. Shamir’s Secret Sharing • Dealing Secret Shares • Dealer randomly selects polynomial f(x) of degree t-1 • Note: f(0) = S • Dealer distributes secret shares to users f(x) = S + a1x + a2x2 + … + at-1xt-1 (mod q) ssi = f(idi) (mod q) • Secret Recovery • Distributed Share Computation What if users are malicious?

  24. Setup • p, q (q divides p-1) • b  Zp* , (mod q) (mod p) Verifiable Secret Sharing (VSS) • P. Feldman [FOCS’87] • Select f(x) over Zqas in Shamir’s f(x) = a0 + a1x + a2x2 + … + at-1xt-1 (mod q) • Exponent is in mod q • q, p : large prime • q | p-1 • Witness generation (publicly known) Wi = gai(mod q) (mod p) • Secret share verification

  25. 2 3 7 5 mSK3 mSK2 m m mSK5 m Threshold RSA (TS-RSA) • d is never reconstructed. • mod N (composite) • J.Kong, et al. [ICNP’01, ISCC’02, WCMC’02] • Setup • Generate RSA key pairs: d, e, N • Dealer randomly selects polynomial f(x) of degree t-1 f(x) = d + a1x + a2x2 + … + at-1xt-1 (mod N) • Signature generation SK2 + SK3 + SK5 d (mod N) mSK2 + SK3 + SK5

  26. 2 3 7 mSK2 + SK3 + SK5 5 mSK3 mSK2 22 msec m m mSK5 m TS-RSA: t-bounded offsetting SK2 + SK3 + SK5 d (mod N) • CRT not applicable • Prime factorsof N are known only to the dealer SK2 + SK3 + SK5= tN + d mSK2+SK3+SK5 = mtN+d = mtNmd Y = mtN+d; for (i=0; i <= t; i++) { Y = Y * m-N mod N; if (Ye = m mod N) break; } return Y (= md mod N)

  27. 2 pss3(7)=74 3 7 pss2(7) =71 7 7 7 pss5(7)=72 5 (mod 119) TS-RSA: VSS failure • Example: f(x) = 77 + 2x + 5x2 (mod 119), g=3 • Witnesses: w0=377=12, w1=32=9, w2=35=5 (mod 119) Impossible to detect malicious members, i.e, no robustness provided! pssi(idj) = ssili(idj) mod N ss7 = pss2(7) + pss3(7)+ pss5(7) = 98 mod(N) Impossible to verify if ssi is correct.

  28. TS-RSA: Summary • No verifiability of secret shares • Gennaro [Crypto’96] and Shoup [Eurocrypt’00] proposed schemes to provide verifiability • require trusted dealer to generate a key-pair • Boneh & Franklin [Crypto’97] distributed RSA key generation • very high communication and/or computation overhead • impractical in many group setting such as MANETs • Trusted dealer involved at initialization phase

  29. Threshold DSA (TS-DSA) • Extention of threshold DSS scheme by Jarecki, et al. [Eurocrypt’96] • group size (n) can be increased. • threshold (t) can be changed. • No dealer involved • VSS holds

  30. TS-DSA: Setup • Self-initializationby founding members • uses Joint Secret Sharing (JSS), Pedersen [Eurocrypt’91] User1 User2 Usern No one knows S. • Each user computes fi(j) (j=1..n, j != i),and sends it to others. • Each user computes his own secret share

  31. 2 s2 s3 3 r, m r, m 7 s5 r, m 5 TS-DSA: Signature Generation • DSA signature: (r, s) O(t2) comm. 2 u3, v3 u2, v2 3 7 u5, v5 extra exp. 5 (t+1)/2-secure

  32. 2 pss3(7)=7 3 7 pss2(7) =2 7 7 7 pss5(7)=4 5 (mod 11) TS-DSA: VSS holds • Example: f(x) = 7 + 2x + 5x2 (mod 11), g=9, q=11, p=23 • Witnesses: w0=97=4, w1=92=12, w2=95=8 (mod 23) pssi(j) = ssili(j) mod p ss7 = pss2(7) + pss3(7)+ pss5(7) = 2

  33. TS-DSA: Summary • Pros: • VSS guaranteed • Key generation fully distributed • Cons: • Robust only if fewer than ë(t+1)/2û malicious users • Extra O(t2) communications between signers to jointly generate random secret k

  34. Feature Summary

  35. Outline • Introduction and Motivation • Admission Control • Distributed Cryptography • System Design and Integration • Performance Evaluation • Conclusion

  36. Distributed Cryptography ASM TS-RSA TS-DSA System Design - ”Bouncer” toolkit Peer Group Applications (Gnutella, Secure Spread, etc.) GAC APIs Policy Management Module Certificate Management Module Data Encoding Module Protocol Handling Module General Crypto. Functions SHA-1,AES,RSA,DSA,etc. Crypto Primitives: OpenSSL Linux

  37. Dynamic Threshold Update

  38. GAC APIs • TS-RSA APIs • GAC_PACKET *TSS_Join_Request(); • GAC_PACKET *TSS_Join_Commit(); • GAC_PACKET *TSS_Sign_Request(); • GAC_PACKET *TSS_Part_Sign(); • GAC_PACKET *TSS_GMC_Request(); /* optional */ • GAC_PACKET *TSS_GMC_Reply(); /* optional */ • ASM APIs • GAC_PACKET *ASM_Join_Request(); • GAC_PACKET *ASM_Join_Commit(); • GAC_PACKET *ASM_Sign_Request(); • GAC_PACKET *ASM_Part_Sign(); • GAC_PACKET *ASM_GMC_Request(); /* optional */ • GAC_PACKET *ASM_GMC_Reply(); /* optional */ • Plain RSA APIs • GAC_PACKET *PS_Join_Reqest(); • GAC_PACKET *PS_Join_Commit(); • GAC_PACKET *PS_GMC_Request(); /* optional */ • GAC_PACKET *PS_GMC_Reply(); /* optional */ • TS-DSA APIs • GAC_PACKET *TSD_Join_Request(); • GAC_PACKET *TSD_Join_Commit(); • GAC_PACKET *TSD_Chal_Req(); • GAC_PACKET *TSD_Chal_Rly(); • GAC_PACKET *TSD_Rnd_Req(); • GAC_PACKET *TSD_Rnd_Rly(); • GAC_PACKET *TSD_Sign_Request(); • GAC_PACKET *TSD_Part_Sign(); • GAC_PACKET *TSD_GMC_Request(); /* optional */ • GAC_PACKET *TSD_GMC_Reply(); /* optional */

  39. SPing Ping Join Pong SPong Commit Query SigReq QueryHit SigRly Push (Download by http) Admission Protocol Integration with Gnutella New Member Current Members Gnutella Protocol Secure Gnutella

  40. Integration with Secure Spread • Spread: A wide area reliable group communication system • Secure Spread: Integrates security services with Spread • Supports only static access control • daemon level ACL’s • flush mechanism • No notion of secure, dynamic, distributed admission. • Modified Spread APIs • SP_GAC_Join(); /* new */ • SP_receive(); /* modified */ Application Bouncer Crypto Library Secure Spread GKA_API Encryption Access control Engine Spread

  41. Outline • Introduction and Motivation • Admission Control • Distributed Cryptography • System Design and Integration • Performance Evaluation • Conclusion

  42. Performance Evaluation • Gnutella Experiment: • Integrated decentralized protocol with Gnut-0.4.21 • Tested on a high-speed LAN • Secure Spread Experiment: • Integrated centralized protocol with Secure SPREAD-2.1.0 • Spread daemons on 10 machines at Johns Hopkins Univ. • A client at UCI • Measurements • Fixed threshold • Dynamic threshold Source code available at http://sconce.ics.uci.edu/gac

  43. Computation Cost Signature verification Signature generation

  44. Signature Size t: threshold K: private key id: signer’s id q: modulus q E: challenge (hash size)

  45. Fixed Threshold Experiments Gnutella Secure Spread

  46. Dynamic Threshold Experiments Gnutella Secure Spread

  47. Conclusions • Designed several P2P admission control mechanisms • Assessed practicality of distributed cryptography for dynamic peer groups. • Threshold signaturesare currently NOT PRACTICAL in MANETs and sensor networks • Reasonable for Internet-based P2P systems that operate in (at least partially) synchronous mode • Difficult to identify one scheme best-suited for all peer group admission scenarios. • If admission is difficult, distributed membership revocation is even harder!

  48. Future Work • TS-RSA • Efficient RSA distributed modulus generation • VSS in Dynamic setting • TS-DSA • Better communication efficiency? • Aggregated Signatures? • Other, more “systems” approaches? • Revocation?

More Related