1 / 21

Providing Robust and Ubiquitous Security Support for Mobile Ad-Hoc Networks

Providing Robust and Ubiquitous Security Support for Mobile Ad-Hoc Networks. Georgios Georgiadis. 6/5/2008. Introduction. Mobile Adhoc Networks (MANETs): widely spread networking solutions, expected to grow more in the future Security of transmission mediums, Air vs Wire: 0-1

dyre
Download Presentation

Providing Robust and Ubiquitous Security Support for Mobile Ad-Hoc Networks

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. Providing Robust and Ubiquitous Security Support for Mobile Ad-Hoc Networks Georgios Georgiadis 6/5/2008

  2. Introduction • Mobile Adhoc Networks (MANETs): widely spread networking solutions, expected to grow more in the future • Security of transmission mediums, Air vs Wire: 0-1 • Absolute security not feasible, nodes become corrupted eventually • But users demand security anywhere, anytime • Who do you trust?

  3. Overview • Motivation • Proposed solution • Design • Architecture (What to do) • Protocol (How to do it) • Evaluation • Q&A (mine) • Q&A, round 2 (your turn)

  4. Motivation • We need security services to be: • Intrusion-tolerant • Available anywhere, anytime • Scalable • We have security services that are: • Centralized: fails on all three accounts • Hierarchical: succeeds on scalability, concerns about the other two

  5. Proposed solution • Two branch solution: • Threshold secret sharing • Secret share updates • Intrusion-tolerant: works with < K-1 adversarial nodes in the neighborhood • Availability: experiments show high availability, even with high mobility • Scalable: all nodes provide security services

  6. Design Challenges • Users of MANETs demand security anywhere, anytime. • Volatile nature of MANETs: mobility of agents, frequent joins/leaves, node failures, channel errors. • Attractive to attackers (air as transmission medium).

  7. Intrusion model • Case #1: • The intruder cannot get the secret key of an entity in time less than the secret key update. • All other information freely accessible. • Case #2: • The intruder can get the secret key… • …but cannot forge the entity ID (intrusion detection mechanisms exist). • We discuss only case #1!

  8. Architecture - Preliminaries • System key pair: RSA(PK,SK) • Each entity maintains: • Unique ID ui • Key pair RSA(pki,ski) • Certificate certi={ui,pki,Tsign,Texpire} • Secret share (of SK) Pui • Certificate revocation list CRL

  9. Architecture - Services • Certification service requests service responses with SKi An entity requests certification services from its neighbors. Each neighbor computes SKi from Pui and sends it back. Once the entity has >K SKs, signs its certificate with system key. 3 1 2 3 1 2

  10. Architecture - Services • Secret share dealing • Initially, secret shares are distributed by a trusted central authority. • Once K secret shares are out there, new shares can be produced without a central authority. • Secret share updates • It’s a secret! • Explicit certificate revocation • If a cert is considered compromised, a counter-cert is flooded over the network.

  11. Protocol – Background • Secret polynomial • SK={d,n}, polynomial of degree K-1: • Secret shares • ≥K entities can produce d (Langrage interpolation): • But in this way, the secret d can be revealed! (Langrage coefficients)

  12. Protocol – Certification • Multi-signature protocol: • The entity sends certificate M to be signed. • Its neighbors sign it with SKi and send back the partially signed certificate . • The entity constructs , which is . • Using K-bounded coalition offsetting, acquires which is the signed certificate. • Note: the secret d has not been revealed!

  13. Protocol – Secret share dealing • Systemwide SK={d,n} • Secret d, secret share of entity ui: • Self-initialization • If already K shares exist in the neighborhood of … • Complete shuffling scheme (using nonces)

  14. Protocol – Secret share update • Initially: version 1, ID 0 • At each update: version++ • Self-initialization protocol for new version propagation • In case of version conflicts, lowest ID wins

  15. Evaluation • Real world evaluation: UNIX RSA, cert vs key size (K=5)Cert vs K (key=1024bits) SPEC 20.5 SPEC 12.1 SPEC 1.37

  16. Evaluation • Simulations: NS2

  17. Evaluation • Simulations: NS2

  18. Evaluation • Simulations: NS2

  19. Q&A, round 1 • Why certificates? • Standard solution, only anywhere, anytime needs solving • Why threshold secret sharing? • Fits well with MANETs: “1 out of N”, “N out of N” • Why secret share updates? • The MANET will be compromised, SK not easy to change

  20. Q&A, round 1 • What about DoS? • Compromised nodes offer false partial certificates • The answer: Verifiable Secret Sharing • What about <K neighbors? • Retry somewhere, sometime! • What about bookkeeping? (Cert Revoc Lists) • Implicit revocation helps keep short lists • In any case: 128-256kb/counter-cert and N<1000 but Pr{compromise}<<1

  21. Q&A, round 2 • Hit me!

More Related