PROVIDING ROBUST AND UBIQUITOUS SECURITY SUPPORT FOR MOBILE AD-HOC NETWORKSGeorgios Georgiadis6/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

Absolute security not feasible, nodes become corrupted eventually

But users demand security anywhere, anytime

Who do you trust?

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

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

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

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).

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!

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

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.

1

2

3 1

2

3

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.

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!

f x

11 1

KKf x d f x f x

modiv iP f v n

1 1

0 mod modj j

K K

v v jj j

d P l n SK n

1 1 1

1 1 1j

j j Kv

j j j j j j K

x v x v x v x vl x

v v v v v v v v

(Langrage coefficients)

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!

1 2 1 2K KSK SK SK SK SK SKX X X X

modiSKM n

1 mod

K

jj

SK

M n

modt n dM n

moddM n

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)

modiv iP f v n

, , ,

1 1

modx x j x j

K K

v x v v x x jj j

P f v P l v SS n

xv

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

Evaluation Real world evaluation: UNIXRSA, cert vs key size (K=5) Cert vs K

(key=1024bits)SPEC 20.5

SPEC 12.1

SPEC 1.37

Evaluation Simulations: NS2

Evaluation Simulations: NS2

Evaluation Simulations: NS2

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

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

Q&A, round 2 Hit me!