Group Key Agreement

1. Group Key Agreement Gene Tsudik SCONCE Lab, UC Irvine

2. OUTLINE • Group Communication • Security Services • Group Key Management Overview • Zooming in: • DH-based Protocols • Authentication • Consistency • Measurements • Robustness / Integration with GCS • Other models

3. General Setting:Security in Group Communication ?

4. Group Communication Settings • One-to-Many (or Few-to-Many) • Single-source broadcast: Cable/sat. TV, radio • Multi-source broadcast: Televised debates, GPS • Any-to-Any • Collaborative applications • Video/Audio conferencing, collaborative workspaces, interactive chat, network games, replication • Richer communication semantics, tighter control, more emphasis on reliability and security • Anycast

5. Dynamic Peer Groups (DPGs) Relatively small (<100 of members) • No hierarchy • Anyone can send and receive • Membership changes

6. DPG Security Layers Security Starts Here Video / audio conferencing, distributed web servers, collaborative work space, multi-player games, replication Secure Applications Authorization, Access control, Non-repudiation … Encryption, Authentication Key Management Membership Control Cert-n: PKI, Revocation

7. Group Key Management • Group key: a secret quantity known only to current group members • Group Key Distribution • One party generates key and distributes to others • Group Key Agreement • Key derived collectively by two or more parties • As a function of each member’s contribution • No one can pre-determine the result

8. Whither Key Distribution in DPG? • Key Distribution well-understood, easy semantics, synchronization • Need centralized key server(s) • Single point of failure • Attractive attack target • Arbitrary network faults can occur • Key server replication is costly • Availability in any and all possible partition

9. Need Reliable Group Communication • Group key agreement protocols rely on the underlying group communication systems • Protocol message transport • Strong membership semantics (notification of all group membership change events) • Not for security reasons • Group communication system needs specialized security mechanisms Mutual benefit and interdependency

10. Membership Events • Join: prospective member wants to join • Leave: member wants to (or is forced to*) leave • Partition: group is split (or splits) into smaller groups • Network failure: network event causes • Explicit partition: application needs to split group • Merge: two or more groups unify • Network fault heal: previously disconnected partitions reconnect • Explicit merge: application merges multiple pre-existing groups * Forced by whom?

11. Key Change Triggers: • All (or some) of membership events • E.g., sometimes a re-key on Join is not needed • Application-specific requirements • Explicit re-key, e.g. time- or data-out

12. Group Key Evolution: Epochs Epoch 2 Epoch i Epoch n-1 Epoch n Epoch 1

13. ‘Raw’ Security Requirements • Group key secrecy • computationally infeasible for a passive adversary to discover a group key • Backward secrecy • Knowledge of any (contiguous?) proper subset of group keys cannot be used to discover previous group keys. • Forward secrecy • Knowledge of any (contiguous?) proper subset of group keys cannot be used to discover subsequent group keys. • Key Independence • Knowledge of any proper subset of group keys cannot be used to discover any other group key.

14. Layers of Key Agreement Crashes, Malicious Disruption active Key/Content Consistency Key Confirmation Explicit Authentication active Implicit (Key) Authentication Raw Key Agreement passive *No defense against passive insiders… except, of course, not having a common key.

15. Layers of Key Agreement – contd. Crashes, Malicious Disruption Amir, et al.’01, Cachin/Strobl’04 Key/Content Consistency Key Confirmation Explicit Authentication Katz/Yung’03, Bresson, et al.’02 Implicit (Key) Authentication BD’93, Ateniese, et al.’00, PQ’01, etc. Raw Key Agreement ING’82, STR’88, BD’93, GDH’96, Becker/Wille’99, TGDH’00 *most viable approaches based on Diffie-Hellman

16. OUTLINE • Group Communication • Security Services • Group Key Management Overview • Zooming in: • DH-based Protocols • Authentication • Consistency • Measurements • Robustness / Integration with GCS • Other models

17. Diffie-Hellman • Setting • p – large prime • g – generator • A  B : NA = gamod p • B  A : NB = gbmod p • A : NBa= gabmod p • B : NAb= gabmod p gab a b

18. Diffie-Hellman Problem • Computational Diffie-Hellman Problem & Assumption (CDHp/a) • Given <g,ga,gb> compute gab • Given <g,ga,gb> computing gab is hard • Decision Diffie-Hellman Problem & Assumption (DDHp/a) • Given <g,ga,gb,gc> check if: gc = gab • Given <g,ga,gb,gc> checking gc =?= gab is hard • Stronger than CDH

19. Man-in-the-Middle Attack Secret Key with B is . Secret Key with A is . Need authentication: explicit or implicit?

20. Group Diffie-Hellman (GDH) • Steiner, et al. (CCS ’96) • Contributory group key agreement protocols • GDH.1 (silly), GDH.2 and GDH.3 • Security • Proof of security (passive adversary) • Key Independence • No authentication • Efficiency • Few rounds except for merge • Computational cost relatively high • Sequel introduced support for dynamic group operation (Steiner, et al. ICDCS’98)

21. Intuition • What is the “natural” extension of 2-party Diffie-Hellman to n members? • What is the form of the group secret? gN1N2…Nn mod p where Ni is Mi’s secret share • What information is required to compute the group key for each member i? gN1N2…Nn /Nimod p • How can we build this information?

22. GDH.2 Example: formation • AB: g, ga • BC: gb, ga, gab • CD: gbc, gac, gab, gabc • DG: gacd , gbcd , gabd, {gabc} Everyone computes gabcd

23. GDH.3 Example: formation • AB: ga • BC: gab • CG: gabc • Everyone ‘factors out’ its contribution • AD: gbc • BD: gac • CD: gab • DG: gbcd , gacd , gabd, {gabc} Everyone computes gabcd

24. Static vs Dynamic Groups • Early protocols supported static groups only, e.g., conferencing with fixed parameters • Not realistic for most applications • Most peer groups evolve incrementally • Leaves and partitions must be supported • Notion of efficiency must be adjusted

25. Join: 2 rounds {gN1…Nn’Nn+1/Ni | i  [1, n]} {gN1…Nn’/Ni | i  [1, n]} gN1…Nn’Nn+1 n exp-ns each • 2n serial exp-ns

26. {gN1…Nn’/Ni | i  [1, n-1]} Join: 3 rounds gN1…Nn’ {gN1…Nn’Nn+1/Ni | i  [1, n]} • n+3 serial exp-ns

27. Summary • Efficiency worst case (merge) • O(n) computation for controller (2 or 3 for all others) • (k+2) rounds • Robustness • What if a ‘token’ is lost? • Complex recovery steps needed to achieve robustness against (esp. cascaded) failures

28. TGDH • Can be based on a binary or ternary* key-tree • One function suffices for all events • Robust against cascaded faults • Contributory • Security • Provable security (passive adversary) • Key independence • Efficient • d = tree height • Maximum number of exponentiations = 4(d-1) • Number of exponentiations in GDH.3 = 2n+1 • Relative of Becker/Wille’99 hypercube/octopus protocols * If based on bilinear maps (e.g., Joux)

29. Key Tree (General) ggn1gn2n3 gn6gn4n5 gn1gn2n3 gn6gn4n5 n1 gn2n3 gn4n5 n6 n2 n3 n4 n5 No more

30. Key Tree (M3’s view) GROUP KEY gn1gn2n3 ggn6gn4n5 gn2n3 gn1 n3 gn2 Co-path: Set of siblings of nodes on the key-path Key-path: Set of nodes on the path from member node to root node GROUP KEY = ggn1gn2n3 gn6gn4n5 gn1gn2n3 ggn6gn4n5 gn1 gn2n3 ggn4n5 gn6 gn2 n3 gn4 gn5 Any member who knows blinded keys on every nodes and its own contribution can compute the group key. Member knows all keys on the key-path and all blinded keys

31. Tree Management: Keep Tree Balanced • Join or Merge Policy • Join to leaf or intermediate node, if height of the tree wouldn’t increase • Join to root, if height of the tree would increase • Leave or Partition policy? • Can’t predict such events… • Can choose to rebalance (costly!) • Success metric • Maintain ‘logarithmic’ depth (height < 2 log2 n) • Extensions • Ternary tree • Alternative tree management techniques • Rebalancing

32. Clustering Effect: repeated partitions Partition: (1,3,5,7) (2,4,6,8) 2 3 4 1 5 6 7 8 3 5 7 2 4 6 8 1 Merge Repeat Partition: (1,3,5,7) (2,4,6,8) 3 5 7 2 4 6 8 1

33. Summary • Efficiency • Average # mod exp: 2 log2 n • Max rounds: log2 n (nasty partition!) • Robustness easy due to self-stabilization • Single function handles join, leave, merge, partition • Can even handle cascaded events

34. Common DPG setting LAN

35. Computation overhead • Most GKA protocols involve modular exponentiation • Contrast with typical LAN roundtrip delay < 2ms • On paper, communication overhead is negligible • Number of protocol messages matters?

36. Another realistic DPG setting sattelite wireless dial-up LAN WAN LAN

37. Motivation: minimize rounds & messages • Over WAN (and wireless, dial-up, etc.) communication is more expensive than computation • Communication has an upper bound (speed of light) • Computation speed increases much fast than communication • Too many messages  some might be lost/corrupted • Retransmissions • Many rounds  cascaded events (protocol interruption)

38. STR: • Steer, et al. (Crypto’88)  Kim, et al. (SEC’01, ToC’03) • Communication-efficient • Max 2 rounds • Max 2 b-casts • Concise: one function does all • Fault-tolerance/robustness: simpler than TGDH • Contributory • Secure • Provable security (passive adversary) • Key independence • Computation costs higher than TGDH • Max exp-ns = 4(N-1)

39. STR Key Tree gn4gn3gn1n2 gn4 gn3gn1n2 gn3 gn1n2 gn2 gn1

40. Summary • Efficiency • Average # mod exp-ns (leave): 2n • Max rounds: 2 • Max messages: 3

41. Additive Group Diffie-Hellman (BD) • Burmester/Desmedt (Eurocrypt’94) K= gN1N2+…+Nn-1Nn+NnN1 where Ni is Mi’s secret share • Contributory group key agreement protocol • B-cast, star and other topologies • Security • Proof of security (passive adversary) • Key Independence • No authentication • Dynamic Operations • Roughly same as formation  concise but expensive

42. BD Example: formation Stage 1: • AG: ga • BG: gb • CG: gc • DG: gd Stage 2: • AG: Xa=(gba/gda) • BG: Xb=(gcb/gab) • CG: Xc=(gdc/gbc) • DG: Xd=(gad/gcd) Everyone computes: K = gab+bc+cd+da e.g., B’s version: K=(ga)4b* (gcb/gab)3 * (gdc/gbc)2 * (gad/gcd)1

43. Summary First Place: most elegant GKA protocol Efficiency • # mod exp-ns: 3 + (n2/2+n) multiplications* • Min #Rounds: 2 • Messages: 2n (n per round) • B-casts: 2n (n per round) Expensive in GCS setting * Not negligible if n >10 or so…

44. Overhead Summary

45. Other Services

46. Implicit Authentication • Ateniese, et al. (CCS’98, JSAC’00) • Motivation: • same building block (exponentiation/DH) • little additional cost • Cons: • not secure if membership not explicit • requires long-term pair-wise keys • Not recommended…

47. Authenticated GKA • State-of-the-art: Katz/Yung (Crypto’03) • “Compiler” for transforming secure GKA into secure AGKA  explicit authentication + key confirmation • signatures and 1 extra round • n2 messages • instantiated with BD

48. Consistency: Malicious Insiders • Problem: malicious insider ‘plays along’ but generates inconsistent output (messages) • Inconsistent within a message • Inconsistent between versions of same message • How do we make sure such behavior is detectable? • Possible solution: apply ‘compiler’ techiques to fortify existing protocols: each time a private contribution is used, prove equality/consistency with prior uses by the same party • E.g., Schnorr-based SKEQLOG proofs

49. BD Example: formation Stage 1: • AG: ga • BG: gb • CG: gc • DG: gd Stage 2: • AG: Xa=(gba/gda) • BG: Xb=(gcb/gab) • CG: Xc=(gdc/gbX) or Xc=(gX) • DG: Xd=(gad/gcd) Everyone computes? K = gab+bc+cd+da

50. GDH.3 Example: formation • AB: ga • BC: gab  gX • CG: gabc • Everyone ‘factors out’ its contribution • AD: gbc • BD: gac • CD: gab -- gX • DG: gbcd , gacd , gabd -- gX Everyone computes gabcd