PROVIDING ROBUST AND UBIQUITOUS SECURITY SUPPORT FOR MOBILE AD-HOC NETWORKS

Georgios 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 requestsservice 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 K

v

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!