Security for Broadcast Network Most slides are from the lecture notes of prof. Adrian Perrig.

Challenges for Broadcast Security Broadcast applications need security Packet injection or eavesdropping is easy Security solutions for point-to-point communication not secure for broadcast Broadcast challenges Scale to large audiences Dynamic membership Low overhead (computation & communication) Packet loss How to achieve reliability in broadcasts? Lost packets are not retransmitted

Reliable Broadcast Transmission How to reliably and scalably disseminate data to large numbers of receivers? Challenges Ack implosion problem if receivers return Ack to sender for received packets Nack implosion problem is severe as well For large numbers of receivers, there usually is a fraction of them that do not obtain message Local repair mechanisms (create tree topology and ask upstream parent for packet) faced numerous scalability difficulties

Forward Error Correction Forward Error Correction (FEC) is a mechanism to reliably transmit data to a receiver without a back channel from receiver to sender Sender adds redundant information that enables receiver to tolerate message loss Ideal for broadcast setting because receiver does not need to contact server if messages were lost, simply wait for more redundancy information

Scale & Dynamics Small groups contain up to ~100 members Medium-size groups contain 100-1000 members Large groups contain 1000-109 members How does scale affect security? Dynamic membership: members may join and leave at any time How do dynamics affect security?

Communication Pattern Group can be single-source broadcast One-to-many SSM: Single-source multicast, source-specific multicast Multiple-source broadcast Some-to-many All members broadcast Many-to-many Which one is most common? Examples?

Group Key Management Receivers join/leave at any time Require forward & backward secrecy Which property is easy to achieve? How? Challenge: scalable key management Backward Secrecy Forward Secrecy Time Join Leave

Metrics We use the following metrics to evaluate group key agreement protocols Communication overhead Number and size of messages (unicast & broadcast messages) Join / leave overheads Computation overhead (by center and by members) Security (collusion attacks?)

Security Requirements Group key secrecy Computationally infeasible for a passive adversary to discover any group key Backward secrecy Any subset of group keys cannot be used to discover previous group keys. Forward secrecy Any subset of group keys cannot be used to discover subsequent group keys. Key Independence Any subset of group keys cannot be used to discover any other group keys. Forward + Backward secrecy

What should we do? Group key generation Group Key establishment who generates? how can we generate group keys efficiently? Group Key establishment how can we authenticate sender? Key distribution by trusted third party unicast muticast broadcast Key agreement between group members

Group Key Management Protocol With a trusted Key Distribution Center (KDC), what is simplest approach for key distribution? Group Key Management Protocol (GKMP) Every member shares a key with KDC KDC unicasts all key updates to each member Advantages Security, simplicity Disadvantages Does not scale to large groups, high overhead

Key distribution How can we authentication the sender? Authentication (weaker) Receiver can only convince herself that the data was generated by the sender Sufficient for many apps – packet authentication Signature (stronger) Receiver can prove to a third party that the data was generated by the sender Important for proxy/cache application that receives data and needs to convince final receiver data ok

Broadcast Authentication Broadcasts data over wireless network Packet injection usually easy Each receiver can verify data origin Alice M Sender M Dave M M Bob Carol

Authentication Needs Asymmetry Sender K K = shared key Msg, MAC(K,Msg) MAC: Message Authentication Code (authentication tag) Msg, MAC(K,Msg) Alice K Bob K Forged Msg, MAC(K, Forged Msg)

Digital Signatures Impractical 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 aggregate signature over multiple packets, intolerant to packet loss

TESLA Timed Efficient Stream Loss-tolerant Authentication Uses only symmetric cryptography Asymmetry via time Delayed key disclosure Requires loose time synchronization

Basic Authentication Mechanism F: public one-way function 1: Verify K 2: Verify MAC P F(K) Authentic Commitment 3: P Authentic! K disclosed MAC(K,P) t

Security Condition Receiver knows key disclosure schedule Security condition (for packet P): on arrival of P, receiver is certain that sender did not yet disclose K If security condition not satisfied, drop packet

Bootstrapping Receivers Loose time synchronization Receiver knows maximum time synchronization error, upper bound on sender’s time Session setup, authenticated parameters Beginning time of one specific interval Interval duration Key chain commitment Disclosure delay Digital signature for initial authentication

One-Way Hash Chains Versatile cryptographic primitive Construction Pick random rN and public one-way function F ri = F(ri+1) Secret value: rN , public value 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 F F F F r4 r3 r5 r6 r7

TESLA Keys disclosed 2 time intervals after use Receiver setup: Authentic K3, key disclosure schedule Authentication of P1: MAC(K5, P1 ) F Authenticate K5 F F K4 K3 K5 K5 K6 K7 t Time 3 Time 4 Time 5 Time 6 Time 7 P1 P2 K5 Verify MAC K3

TESLA: Robust to Packet Loss F Authenticate K5 F F K4 K3 K5 K5 K6 K7 t Time 3 Time 4 Time 5 Time 6 Time 7 P1 P2 K5 Verify MAC K3

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 Perfect robustness to packet loss 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