Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "1 Security for Broadcast Network Most slides are from the lecture notes of prof. Adrian Perrig."— Presentation transcript:

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

2 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 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 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 5 Scale & Dynamics Small groups contain up to ~100 members Medium-size groups contain 100-1000 members Large groups contain 1000-10 9 members How does scale affect security? Dynamic membership: members may join and leave at any time How do dynamics affect security?

6 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 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 Join Forward Secrecy Leave Backward Secrecy Time

8 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 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 10 What should we do? Group key generation 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 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 12 Group key generation methods

13 13 Centralized Flat Table Proposed by Chang et al., Infocom 1999; and Waldvogel et al., IEEE JSAC 1999 Idea: 2 keys for each bit of member ID Member with ID=9 (1001) gets keys K 0,1 K 1,0 K 2,0 K 3,1 K 4,0 K0,0K0,0 K 1,0 K 2,0 K 3,0 K4,0K4,0 K 0,1 K 1,1 K 2,1 K 3,1 K 4,1 Bit=0 Bit=1 LSB ID Bit 0MSB ID Bit 4

14 14 Centralized Flat Table How to add or expel a member? Advantages Low communication and computation overhead Low memory overhead at KDC Disadvantages Does not provide key independence! Collusion attack possible!

15 15 Double One-way Key Chains Goal: Join members for a pre-determined time period, preserve forward and backward secrecy Approach: use two one-way key chains For interval T3-T6, member gets K3 ’ and K6 Key for interval T3 is K3 ’  K3 T1 T2T3T4T5T7T8T6 t K1K2K3K4K5K7K8K6 K1’K2’K3’K4’K5’K7’K8’K6’

16 16 Double One-way Key Chains Advantages Low storage overhead at KDC Only 2 keys need to be sent by unicast communication after join event, no broadcast overhead! No communication on leave events! Disadvantages Cannot expel member Does not provide key independence, collusion attack!

17 17 MARKS Idea: derive key tree top-down, each leaf key is associated with a time interval K12 = H( “ left ” || K14 ) K34 = H( “ right ” || K14 ) K1 is key used to encrypt data in time T1 K34 enables member to receive data in intervals T3 & T4 K1K2K3K4 K12K34 K14 T1 T2T3T4 t

18 18 MARKS Member pays for time T3-T8, receives K34 and K58 K1K2K3K4K5K7K8 K12K34K56K78 K14K58 K18 T1 T2T3T4T5T7T8 K6 T6 t

19 19 MARKS Discussion Advantages O(log(T)) unicast communication after join events, no broadcast overhead! No communication on leave events! Tradeoff between storage and computation overhead on KDC Disadvantages Cannot expel member

20 20 Logical Key Hierarchy (LKH) Idea: arrange members at leaves of a key tree, each member receives keys on its path K1K2K3K4K5K7K8 K12K34K56K78 K14K58 K18 M1 M2M3M4M5M7M8 K6 M6

21 21 Logical Key Hierarchy (LKH) In LKH, root key is group key Each member shares leaf key with KDC How to join a member? Computation and communication overhead? How to expel a member? Computation and communication overhead?

22 22 LKH Redistribute new keys when M6 is expelled K1K2K3K4K5K7K8 K12K34K56’K78 K14K58’ K18’ M1 M2M3M4M5M7M8 K6 M6

23 23 LKH Redistribute new keys when M6 is expelled K1K2K3K4K5K7K8 K12K34K56’K78 K14K58’ K18’ M1 M2M3M4M5M7M8 E K5 (K56’); E K78 (K58’); E K56’ (K58’); E K14 (K18’); E K58’ (K18’)

24 24 LKH Discussion Advantages Low computation and communication overhead: join and leave only require O(log(N)) broadcast message size Disadvantages Requires broadcast message for each event Key storage requires O(N) memory at KDC

25 25 LKH+ How can we reduce broadcast message overhead for join events? Simply compute one-way function on all keys on key path of joining member Advantage: only send the position in key tree of joining member to group, all members can adjust their keys

26 26 LKH++ How can we reduce broadcast message overhead for leave events? Suggested by Canetti et al. at Infocom 99 Idea: derive parent key from child key through one-way function Key path that is updated after leave event forms a one-way key chain, starting at leaf node

27 27 LKH++ Re-key K1K2K3K4K5’K7K8 K12K34K56’K78 K14K58’ K18’ M1 M2M3M4M5M7M8 E K5’ (K56’); E K78 (K58’); E K56’ (K58’); E K14 (K18’); E K58’ (K18’) K56’ = H( K5’ ), K58’ = H(K56’), K18’ = H(K58’)

28 28 LKH++ Discussion Advantages log(N) bits broadcast for join event |K| log(N) bits broadcast for leave event (LKH used 2 |K| log(N) bits) Secure against collusion attacks Disadvantages Memory storage overhead

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

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

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

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

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

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

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

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

37 37 One-Way Hash Chains Versatile cryptographic primitive Construction Pick random r N and public one-way function F r i = F(r i+1 ) Secret value: r N, public value r 0 Properties Use in reverse order of construction: r 1, r 2 … r N Infeasible to derive r i from r j (j<i) Efficiently authenticate r i using r j (j<i): r j = F i-j (r i ) Robust to missing values r6r6 r7r7 r4r4 r3r3 FFF r5r5 F

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

39 39 TESLA: Robust to Packet Loss K5K6K7 t Time 4Time 5Time 6Time 7 K4K3 P2 K5 P1 K3 Verify MAC F FF Authenticate K5 K5 Time 3 F

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

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


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

Similar presentations


Ads by Google