Download presentation
Presentation is loading. Please wait.
Published byMyles Jennings Modified over 9 years ago
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 u i Key pair RSA(pk i,sk i ) Certificate cert i ={u i,pk i,T sign,T expire } Secret share (of SK) Pu i Certificate revocation list CRL
9
Architecture - Services Certification service requests service responses with SK i An entity requests certification services from its neighbors. Each neighbor computes SK i from Pu i and sends it back. Once the entity has >K SKs, signs its certificate with system key. 1 2 3 1 2 3
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 SK i 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 u i : 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!
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.