Presentation is loading. Please wait.

Presentation is loading. Please wait.

PROVIDING ROBUST AND UBIQUITOUS SECURITY SUPPORT FOR MOBILE AD- HOC NETWORKS Georgios Georgiadis 6/5/2008.

Similar presentations


Presentation on theme: "PROVIDING ROBUST AND UBIQUITOUS SECURITY SUPPORT FOR MOBILE AD- HOC NETWORKS Georgios Georgiadis 6/5/2008."— 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 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!


Download ppt "PROVIDING ROBUST AND UBIQUITOUS SECURITY SUPPORT FOR MOBILE AD- HOC NETWORKS Georgios Georgiadis 6/5/2008."

Similar presentations


Ads by Google