wireless network security -...

©2013 Patrick Tague

Wireless Network Security14-814 – Spring 2013

Patrick Tague

Class #6 – Broadcast Security


Agenda• Security issues in broadcast communications

– TESLA broadcast authentication

– SPINS: Security protocols for sensor networks

– TinySec


Broadcast Communication• Broadcast comm takes

advantage of the shared medium for “one-to-many” transmissions– Can be much more efficient

than “one-to-one” unicast, depending on topology and scale

– In Wifi, single collision domain 1-to-N in one shot→

– In general, 1-to-N requires relaying


Topology and Scale• Gains from “broadcast advantage” depend on

network topology and scale– In a star topology, O(1) transmissions cover N nodes

(compared to O(N) in unicast)– In general, O(N/d) transmissions cover N nodes with

density d (compared to O(N2) in unicast)• Ex: d ~ log N

• Additional considerations with network scale:– Key management overhead for broadcast

authentication and encryption


Broadcast Authentication• Broadcasts data over wireless network

• Packet injection usually easy

• Goal: each receiver can verify data origin

Sender

Bob

M

Carol

M

DaveAliceMM


WiFi Broadcast Security• In WiFi, 1-to-N broadcast security protocols use

the Group Transient Key (GTK, remember Hole196?)– GTK keys are encrypted with PTK key-encryption keys

and sent via unicast to each group member

– [Buttyan & Hubaux, Security & Cooperation in Wireless Networks, 2007]


Generic Broadcast Auth.• Allows nodes to verify the source of packet

transmissions– First idea: use symmetric key cryptography and MACs

• Symmetric key group member indistinguishability→

– Second idea: use public-key signatures• Provably correct, but very expensive

– Third idea: packet-block signatures – sign a collection of packets, partition signature over packet block

• Packet loss problems, DoS opportunities, still expensive


Symmetric Keys Enough?

Senderw/ key K

Alice w/key K

Bob w/key K

M, MACK(M)

M', MACK(M')

M, MACK(M)

Some form of asymmetry is required


Asymmetry via Crypto• The classical way of achieving asymmetry is via

asymmetric crypto:– Sender uses a private key to sign the message, all

recipients use the corresponding public key

Sender, K

Alice, K-1 Bob, K-1

M, SigK(M)

M', SigK(M')

M, SigK(M)


So, Digital Signatures?• Signatures are expensive, e.g., RSA 1024:

– High generation cost (~10 milliseconds)

– High verification cost (~1 millisecond)

– High communication cost (128 bytes/packet)

• Very expensive on low-end processors

• If we use one signature over multiple packets, intolerant to packet loss


TESLA• TESLA = Timed Efficient Stream Loss-tolerant

Authentication [Perrig et al., RSA Cryptobytes 2002]

• Uses only symmetric cryptography

• Asymmetry via time– Only the correct sender could compute MAC at time t

– Delayed key disclosure for verification

– Requires loose time synchronization


Delayed Key Disclosure

t

F(K)AuthenticCommitment

P

MACK(P)

K disclosed

1: Verify K

2: Verify MAC

3: P Authentic!

F: public one-way function


Packet Verification• Receiver knows key disclosure schedule

• If receiver is certain that sender did not yet

disclose K at time of arrival of packet P, keep P

• Otherwise, drop packet P


One-Way Hash Chains• Versatile cryptographic primitive– Pick random rN and public one-way function F

– For i=N-1,...,0 : ri = F(ri+1), then publish r0

• Properties– Use in reverse order of construction: r1, r2, …, rN

– Infeasible to derive ri from rj (j<i)

– Efficiently authenticate ri using rj (j<i): rj = Fi-j(ri)

– Robust to missing values

r6 r7r4r3FFF r5

F


TESLA Schedules• Keys disclosed 2 time intervals after use• Receiver setup: Authentic K3, key disclosure

schedule

K5 K6 K7

tTime 4 Time 5 Time 6 Time 7

K4K3FFF

K5

Time 3

F

P1,MAC

K5(P1),

K3

P2,MAC

K7(P2),

K5


Robustness to Packet Loss

K5 K6 K7

tTime 4 Time 5 Time 6 Time 7

K4K3FFF

K5

Time 3

F

P3,MAC

K5(P3),

K3 P5,MAC

K7(P5),

K5

P1,MAC

K4(P1),

K2

P2,MAC

K4(P2),

K2

P4,MAC

K6(P4),

K4


Asymmetric Properties• Disclosed value of key chain is a public key, it

allows authentication of subsequent messages (assuming time synchronization)

• Receivers can only verify, not generate

• With trusted time stamping entity, TESLA can provide signature property


TESLA Summary• Low overhead– Communication (~ 20 bytes)– Computation (~ 1 MAC computation per packet)

• Perfect robustness to packet loss• Independent of number of receivers• Delayed authentication• Applications– Authentic media broadcast– Sensor networks– Secure routing protocols


What about highly-constrained nodes in wireless sensor networks?


µTESLA for WSN• Proposed as part of the SPINS architecture [Perrig

et al., WiNet 2002]– Reduced communication compared to TESLA, key

disclosure per epoch instead of per packet

– Includes several other optimizations for minimum overhead, practical in severely-constrained devices


SNEP for WSN• SPINS also includes the Secure Network

Encryption Protocol (SNEP) to provide data confidentiality, authentication, and freshness [Perrig et al., WiNet 2002]– SNEP includes efficient key generation– SNEP authenticated + encrypted packet structure:

• Data encrypted with shared key + counter (for semantic security)

• MAC over encrypted data

• Optional nonce-exchange for provable freshness


TinySec• The TinySec architecture provides a practical

security suite for wireless sensor networks [Karlof

et al., SenSys 2004] – TinySec-Auth provides authentication only– TinySec-AE provides authenticated encryption

– Extensive discussion of design trade-offs and simulation results included in the paper


In addition to security and performance features of the security protocols, what about the underlying key management?


Key Management• How to add a member to the group without

giving them access to past group activities?

• How to remove/revoke a member from the group without giving them access to future group activities?

• How to provide fresh credentials to group members?


Key Management• What about the risk of insider threats?

• How to detect when keys are compromised?– And what action to take upon detection?

• How to ensure key management doesn't open up additional attack vectors, e.g. DoS?

• How to balance security with overhead?– Communication, computation, storage, etc.


Further Reading• Broadcast authentication in VANETs– Studer et al., ESCAR 2008 / JCN 2009.– Raya et al., SASN 2005.

• More papers @ http://lca.epfl.ch/projects/ivc/

• … in WSN– Ren et al., WASA 2006.

• DoS-resilient broadcast authentication– Gunter et al., NDSS 2004.– Karlof et al., NDSS 2004.


Next Time• Key management– Centralized group key management

– Distributed key agreement

– Why is keying different in wireless?

wireless network security -...

Documents