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

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

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

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

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

6. 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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22. TESLA: Robust to Packet LossF
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

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

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