On the Evolution of Adversary Models
This presentation is the property of its rightful owner.
Sponsored Links
1 / 23

On the Evolution of Adversary Models (from the beginning to sensor networks) PowerPoint PPT Presentation


  • 71 Views
  • Uploaded on
  • Presentation posted in: General

On the Evolution of Adversary Models (from the beginning to sensor networks). Virgil D. Gligor Electrical and Computer Engineering University of Maryland College Park, MD. 20742 [email protected] Lisbon, Portugal July 17-18, 2007. Overview.

Download Presentation

On the Evolution of Adversary Models (from the beginning to sensor 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


On the evolution of adversary models from the beginning to sensor networks

On the Evolution of Adversary Models

(from the beginning to sensor networks)

Virgil D. Gligor

Electrical and Computer Engineering

University of Maryland

College Park, MD. 20742

[email protected]

Lisbon, Portugal

July 17-18, 2007


On the evolution of adversary models from the beginning to sensor networks

Overview

  • New Technologies often require a New Adversary Def.

  • - continuous state of vulnerability

2. Why is the New Adversary Different ?

- ex. sensor, mesh networks, MANETs

- countermeasures

  • Challenge: find “good enough” security countermeasures

4. Proposal: Information Assurance Institute


On the evolution of adversary models from the beginning to sensor networks

A system without an adversary definition cannot

possibly be insecure; it can only be astonishing…

… astonishment is a much underrated security vice.

(Principle of Least Astonishment)


On the evolution of adversary models from the beginning to sensor networks

Why an Adv. Def. is a fundamental concern ?

1. New Technology > Vulnerability ~> Adversary <~> Methods & Tools

  • sharing user-mode confidentiality anduntrusted user- sys. vs. user mode (’62->)

  • programs& data; integrity breaches;mode programs rings, sec. kernel (’65, ‘72)

  • - computing utility system penetration;& subsystems FHM (’75)theory/tool(’91)*

  • (early – mid 1960s) acc. policy models (’71)

- shared stateful DoS instances untrusted user DoS = a diff. prob.(83-’85)*

servicesprocesses; formal spec. & verif. (’88)*

e.g., DBMS, net. protocolsconcurrent, DoS models (’92 -> )

dyn. resource alloc.coord. attacks

(early - mid 1970s)

  • PCs, LANs; read, modify, block, “man in the middle” informal: NS, DS (’78–81)

  • public-domain Crypto replay, forge active, adaptive semi-formal: DY (‘83)

  • (mid 1970s) messages network adversary Byzantine (‘82 –>)

  • crypto attk models (‘84->)

  • auth. prot. analysis (87->)

  • internetworking large-scale effects: geo.distributed, virus scans, tracebacks

  • (mid – late 1980s) worms, viruses, coordinated intrusion detection

  • DDoS (e.g., flooding) attacks(mid ’90s ->)

2. Technology Cost -> 0, Security Concerns persist


On the evolution of adversary models from the beginning to sensor networks

New

Technology >

New

Vulnerability ~>

New

Adversary Model <~>

New Analysis

Method & Tools

+O(years)

+/- O(months)

+O(years)

… a perennial challenge (“fighting old wars”)

Reuse of Old (Secure)

Systems & Protocols

New

Technology ~>

New

Vulnerability

Old

Adversary Model

mismatch

Continuous State of Vulnerability


On the evolution of adversary models from the beginning to sensor networks

New Technology Ex.: Sensor Networks

Claim

Sensor Networks introduce:

- new, unique vulnerabilities: nodes captured and replicated

- new adversary: different from and Dolev-Yao and traditional Byzantine adv.s

and

- require new methods and tools: emergent algorithms & properties

(for imperfect but good-enough security)

Mesh Networks have similar but not identical characteristics


On the evolution of adversary models from the beginning to sensor networks

Limited Physical Node Protection

Two Extreme Examples

High end: IBM 4764 co-proc. (~ $9K)

Low end: Smart Cards (< $15)

  • tamper resistance, real time response

    • independent battery, secure clock

    • battery-backed RAM (BBRAM)

    • wrapping: several layers of non-metallic

    • grid of conductors in a grounded shield

    • to reduce detectable EM emanations

    • tamper detection sensors (+ battery)

      • temp., humidity, pressure, voltage,

      • clock, ionizing radiation

    • - response: erase BBRAM, reset device

  • no tamper resistance

  • non-invasive phys. attacks

    • side-channel (timing, DPA)

    • unusual operating conditions

      • temperature, power clock glitches

  • invasive phys. attacks

    • chip removal from plastic cover

    • microprobes, electron beams


On the evolution of adversary models from the beginning to sensor networks

Limited Physical Node Protection

Observation:

a single on-chip secret key is sufficient to protect

(e.g., via Authenticated Encryption)

many other memory-stored secrets (e.g., node keys)

Problem:

how do we protect that single on-chip secret key ?

Potential Solution: Physically Unclonable Functions (PUFs)

observation: each IC has unique timing

basicPUF: Challengeextracts unique, secret Response (i.e., secret key) from

IC-hidden, unique timing sequence


On the evolution of adversary models from the beginning to sensor networks

Basic PUF circuit [Jae W. Lee et al. VLSI ‘04]

unknown challenge bit

IC

b62

feed-fwd arbiter

255

0

1

Response

e.g., 255 bits

Arbiter

b0

b1

b2

b61

b128

LFSR

Challenge

e.g., 128 bits

0

Arbiter

1

Arbiter

bi=0

bi=1

switch

Arbiter operation


On the evolution of adversary models from the beginning to sensor networks

Basic PUF counters:

brute-force attacks (2*128 challenge-response pairs => impractical)

duplication (different timing => different Secret Response)

invasive attacks (timing modification => different Secret Response)

Basic PUF circuit [Jae W. Lee et al. VLSI ‘04]

However,

Pr. 1: adversary can build timing model of Arbiter’s output

=> canbuild clone for secret-key generation

Pr. 2: Arbiter’ output (i.e., secret-key generation) is unreliable

Reality: intra-chip timing variation (e.g., temp, pressure, voltage)

=> errors in Arbiter’s output (e.g., max. error: 4 – 9%)


On the evolution of adversary models from the beginning to sensor networks

Suggested PUF circuit [Ed Suh et al. ISCA ‘05]

Solution to Pr. 1:

hash Arbiter’s output to provide new Response

- cannot discover Arbiter output from known Challenges and new Responses

Solution to Pr. 2:

add Error Correcting Codes (ECCs) on Arbiter’s output

e.g., use BCH(n, k, d)

n(timing bits) = k(secret bits) + b(syndrome bits) for (d-1)/2 errors

BCH (255,63,61) => 30 (> 10%n > max. no.) errors in Arbiter’s output are corrected

> 30 errors ? (probability is 2.4 X10-6)

probability of incorrect output is smaller but not zero

hash Arbiter’s output and verify against stored Hash(Response)


On the evolution of adversary models from the beginning to sensor networks

However, syndrome reveals some (e.g., b=192) bits of Arbiter’s output (n=255)

Suggested PUF circuit

known

Syndrome

e.g., 192 bits

IC

BCH

b62

feed-fwd arbiter

255

bits

secret

Response

Arbiter

Hash

known

Challenge

e.g., 128 bit

b0

b1

b2

b61

b128

LFSR

generate response: C -> R, S; retrieve response: C, S -> R

(Off-line) Verifiable-Plaintext Attack:

Get C, S, hash(R); guess remaining (e.g., 63) bits of Arbiter’s output; verify new R;

repeat verifiable guesses until Arbiter’s output is known; discover secret key


On the evolution of adversary models from the beginning to sensor networks

Some Characteristics of Sensor Networks

1. Ease of Network Deployment and Extension

- scalability => simply drop sensors at desired locations

- key connectivityvia key pre-distribution=>

neither administrative intervention nor TTP interaction

2. Low Cost, Commodity Hardware

- low cost => physical node shielding is impractical

=> ease of access to internal node state

(Q: how good should physical node shielding be to prevent access

to a sensor’s internal state ?)

3. Unattended Node Operation in Hostile Areas =>

adversary can capture, replicate nodes (and node states)


On the evolution of adversary models from the beginning to sensor networks

Replicated Node Insertion: How Easy ?

3

Captured

Node

NEIGHBORHOOD j

NEIGHBORHOOD i

shared key

outside neighborhood

1

path key

shared key

inside neighborhood

NEIGHBORHOOD k

i

3

shared key

outside neighborhood

2


On the evolution of adversary models from the beginning to sensor networks

Attack Coordination among Replicas:

How Easy ?

Node

Replica 1

3

Node

Replica 2

3

3

collusion

Captured

Node

NEIGHBORHOOD j

NEIGHBORHOOD i

1

NEIGHBORHOOD k

i

3

2

Note: Replica IDs are cryptographically bound to pre-distributed keys and cannot be changed


On the evolution of adversary models from the beginning to sensor networks

New vs. Old Adversary

Old (Dolev-Yao) Adversary can

- control network operation

- man-in-the-middle: read, replay, forge, block, modify, insert messages

anywhere in the network

- send/receive any message to/from any legitimate principal (e.g., node)

- act as a legitimate principal of the network

Old (Dolev-Yao) Adversary cannot

1) adaptively capture legitimate principals’ nodes and discover a legitimate principal’s secrets

2) adaptively modify network and trust topology (e.g., by node replication)

Old Byzantine Adversaries

- can do 1) but not 2)

- consensus problems impose fixed thresholds for captured nodes

(e.g., t < n/2, t < n/3) and fixed number of nodes, n.


On the evolution of adversary models from the beginning to sensor networks

Countermeasures for Handling New Adv.?

  • Detection and Recovery

  • - Ex. Detection of node-replica attacks

    • Cost ? Traditional vs. Emergent Protocols

    • Advantage: always possible, good enough detection

    • Disadvantage: damage possible before detection

  • Avoidance: early detection of adversary’s presence

  • - Ex. Periodicmonitoring

  • - Cost vs. timely detection ? False negatives/positives ?

  • - Advantage: avoids damage done by new adversary

  • - Disadvantage: not always practical in MANETs, sensor and mesh networks

  • Prevention: survive attacks by “privileged insiders”

  • - Ex. Subsystems that survive administrators’ attacks (e.g., auth)

  • - Cost vs. design credibility ? Manifest correctness

  • - Advantage: prevent damage; Disadvantage: very limited use


On the evolution of adversary models from the beginning to sensor networks

Example of Detection and Recovery

(IEEE S&P, May 2005)

  • naïve: each node broadcasts <ID, “locator,” signature>

  • perfect replica detection: ID collisions, different Iocators

  • complexity: O(n2) messages

  • realistic: each node broadcasts locally <ID, “locator,” signature>

  • local neighbors further broadcast to g << nrandom witnesses

  • good enough replica detection: ID collision, different Iocators at witness

  • detection probability: 70 - 80% is good enough

  • complexity: O(n x sqrt(n)) messages


On the evolution of adversary models from the beginning to sensor networks

A New App.: Distributed Sensing


On the evolution of adversary models from the beginning to sensor networks

A New Application: Distributed Sensing

Application: a set of m sensors observe and signal an event

- each sensor broadcasts “1” whenever it senses the event;

else, it does nothing

- if t m broadcasts, all m sensors signal event to neighbors; else do nothing

Operational Constraints

- absence of event cannot be sensed (e.g., no periodic “0” broadcasts)

- broadcasts are reliable and synchronous (i.e., counted in sessions)

Adversary Goals: violate integrity(i.e.,issues t  m/2 false broadcasts)

deny service (i.e., t > m/2, suppresses m-t+1 broadcasts)

New (Distributed-Sensing) Adversary

- captures nodes, forges, replays or suppresses (jams) broadcasts

(within same or across different sessions)

- increases broadcast count with outsiders’ false broadcasts


On the evolution of adversary models from the beginning to sensor networks

An Example: distributed revocation decision

[IEEE TDSC, Sept. 2005]

m=6, t = 4 votes in a session => revoke target

Keying Neighborhood

revocation

target

Communication

Neighborhood

4

10

3

2

8

14

5

11

propagate revocation

decision

1

propagate revocation

decision

7

13

9

6

12


On the evolution of adversary models from the beginning to sensor networks

New vs. Old Adversary

A (Reactive) Byzantine Agreement Problem ?

- both global event and its absence are (“1/0”) broadcast by each node

- strong constraint on t ; i.e., no PKI => t > 2/3m; PKI => t >m/2

- fixed, known group membership

No.

New (Distributed-Sensing) Adv. =/= Old (Byzantine) Adv.

- new adversary neednot forge, initiate, or replay “0” broadcasts

- new adversary’s strength depends on a weakert (e.g., t < m/2)

- new adversary may modify membership to increase broadcast count ( > t)


On the evolution of adversary models from the beginning to sensor networks

Conclusions

  • New Technologies => New Adversary Definitions

  • - avoid “fighting the last war”

  • - security is a fundamental concern of IT

  • No single method of countering new and powerful adversaries

  • - detection

  • - avoidance (current focus)

  • - prevention (future)

  • How effective are the countermeasures ?

  • - provide “good enough” security; e.g., probabilistic security properties


  • Login