Error Detection and Correction for Distributed Group Key Agreement Protocol
Group Key Agreement
description
Transcript of Group Key Agreement
![Page 1: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/1.jpg)
1
Group Key AgreementGene Tsudik
SCONCE Lab, UC Irvine
![Page 2: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/2.jpg)
2
OUTLINE
1. Group Communication
2. Security Services
3. Group Key Management Overview
4. Zooming in:1. DH-based Protocols
2. Authentication
3. Consistency
4. Measurements
5. Robustness / Integration with GCS
6. Other models
![Page 3: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/3.jpg)
3
General Setting:Security in Group Communication
?
![Page 4: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/4.jpg)
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
![Page 5: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/5.jpg)
5
Dynamic Peer Groups (DPGs)
No hierarchy
Anyone can send and receive
Membership changes
Relatively small (<100 of members)
![Page 6: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/6.jpg)
6
DPG Security Layers
Encryption, Authentication
Key Management
Authorization, Access control, Non-repudiation …
Video / audio conferencing, distributed web servers,collaborative work space, multi-player games, replication
Secure Applications
Security Starts Here
Membership Control
Cert-n: PKI, Revocation
![Page 7: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/7.jpg)
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
![Page 8: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/8.jpg)
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
![Page 9: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/9.jpg)
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
![Page 10: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/10.jpg)
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?
![Page 11: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/11.jpg)
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
![Page 12: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/12.jpg)
12
Group Key Evolution: Epochs
Epoch 1 Epoch 2 Epoch i Epoch n-1 Epoch n
![Page 13: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/13.jpg)
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.
![Page 14: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/14.jpg)
14
Layers of Key Agreement
Implicit (Key) Authentication
Raw Key Agreement
Explicit Authentication
Key Confirmation
Key/Content Consistency
Crashes, Malicious Disruption
passive
activ
e*No defense against passive insiders… except, of course, not having a common key.
activ
e
![Page 15: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/15.jpg)
15
Layers of Key Agreement – contd.
Implicit (Key) Authentication
Raw Key Agreement
Explicit Authentication
Key Confirmation
Key/Content Consistency
Crashes, Malicious Disruption
*most viable approaches based on Diffie-Hellman
Amir, et al.’01, Cachin/Strobl’04
Katz/Yung’03, Bresson, et al.’02
BD’93, Ateniese, et al.’00, PQ’01, etc.
ING’82, STR’88, BD’93, GDH’96, Becker/Wille’99, TGDH’00
![Page 16: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/16.jpg)
16
OUTLINE
1. Group Communication
2. Security Services
3. Group Key Management Overview
4. Zooming in:1. DH-based Protocols
2. Authentication
3. Consistency
4. Measurements
5. Robustness / Integration with GCS
6. Other models
![Page 17: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/17.jpg)
17
Diffie-Hellman Setting
• p – large prime • g – generator
A B : NA = ga mod p B A : NB = gb mod p A : NB
a = gab mod p B : NA
b = gab mod pa b
gab
![Page 18: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/18.jpg)
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
![Page 19: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/19.jpg)
19
Man-in-the-Middle Attack
),( agA ),( egA
),( bgB),( egB
Secret Key with A is .
ebgSecret Key
with B is .
eag
)(MDES eag)(MDES ebg
Need authentication: explicit or implicit?
![Page 20: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/20.jpg)
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)
![Page 21: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/21.jpg)
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 /Ni mod p• How can we build this information?
![Page 22: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/22.jpg)
22
GDH.2 Example: formation
1) AB: g, ga
2) BC: gb, ga, gab
3) CD: gbc, gac, gab, gabc
4) DG: gacd , gbcd , gabd, {gabc}
Everyone computes gabcd
![Page 23: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/23.jpg)
23
GDH.3 Example: formation
1) AB: ga
2) BC: gab
3) CG: gabc
4) Everyone ‘factors out’ its contribution• AD: gbc
• BD: gac
• CD: gab
5) DG: gbcd , gacd , gabd, {gabc}
Everyone computes gabcd
![Page 24: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/24.jpg)
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
![Page 25: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/25.jpg)
25
Join: 2 rounds
{gN1…Nn’Nn+1/Ni | i [1, n]}
gN1…Nn’Nn+1
n exp-ns each
{gN1…Nn’/Ni | i [1, n]}
• 2n serial exp-ns
![Page 26: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/26.jpg)
26
Join: 3 rounds
gN1…Nn’
{gN1…Nn’/Ni | i [1, n-1]}
{gN1…N
n’Nn+1/Ni | i [1, n]}
• n+3 serial exp-ns
![Page 27: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/27.jpg)
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
![Page 28: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/28.jpg)
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)
![Page 29: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/29.jpg)
29
Key Tree (General)
n4 n5
gn4n5 n6n1
n2 n3
gn2n3
gn1gn
2n
3
ggn1gn2n3 gn6gn4n5
gn6gn
4n
5
No more
![Page 30: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/30.jpg)
30
Key Tree (M3’s view)
gn4 gn5
ggn4n
5 gn6gn1
gn2 n3
gn2n3
gn1gn
2n
3
GROUP KEY
ggn6gn4n5
= ggn1gn2n
3 gn6gn4n
5
n3
gn2n3
gn1gn
2n
3
GROUP KEY
Key-path: Set of nodes on the path from member node to root node
gn1
gn2
ggn6gn4n5
Co-path: Set of siblings of nodes on the key-pathMember knows all keys on the key-path and all blinded keysAny member who knows blinded keys on every nodes andits own contribution can compute the group key.
![Page 31: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/31.jpg)
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
![Page 32: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/32.jpg)
32
Clustering Effect: repeated partitions
1 2 3 4 5 6 7 8 1 3 5 7 2 4 6 8
1 3 5 7 2 4 6 8
Partition: (1,3,5,7) (2,4,6,8)
Repeat Partition: (1,3,5,7) (2,4,6,8)
Merge
![Page 33: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/33.jpg)
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
![Page 34: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/34.jpg)
34
Common DPG setting
LAN
![Page 35: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/35.jpg)
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?
1024-bit mod exp
Pentium II 450 8 ms
Pentium III 800 4 ms
Sun Ultra 250 20 ms
![Page 36: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/36.jpg)
36
Another realistic DPG setting
WAN
LAN
LAN
wireless dial-upsattelite
![Page 37: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/37.jpg)
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)
Communication roundtrip (Ping)
UCI Columbia U 88 ms
UCI Thailand 420 ms
UCI Mozambique 670 ms
![Page 38: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/38.jpg)
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)
![Page 39: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/39.jpg)
39
STR Key Tree
gn1
gn1n2
gn3gn
1n
2 gn4
gn3
gn4gn
3gn
1n
2
gn2
![Page 40: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/40.jpg)
40
Summary
Efficiency
• Average # mod exp-ns (leave): 2n
• Max rounds: 2
• Max messages: 3
![Page 41: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/41.jpg)
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
![Page 42: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/42.jpg)
42
BD Example: formation
Stage 1: AG: ga
BG: gb
CG: gc DG: gd
Stage 2: AG: Xa=(gba/gda) BG: Xb=(gcb/gab) CG: Xc=(gdc/gbc) DG: 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
![Page 43: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/43.jpg)
43
Summary
* Not negligible if n >10 or so…
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
![Page 44: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/44.jpg)
44
Overhead SummaryComm Comp
Rounds Msg Uni Broad Exp
GDH.3
Join 1
Join 2
2
3
2
n+2
1
n
1
2
2n
n+3
Leave, Partition 1 1 0 1 n-1
Merge k+2 n+2k+1 n+2k-1 2 n+2k+1
TGDH
Join, Merge 2 3 0 3 2log n
Leave 1 1 0 1 log n
Partition log n/2 log n 0 log n log n
STR
Join 2 3 1 3 7
Leave, Partition 1 1 0 1 3n+6
Merge 2 3 0 3 4k+4
BD 2 2n 0 2n 3 (4?)
![Page 45: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/45.jpg)
45
Other Services
![Page 46: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/46.jpg)
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…
![Page 47: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/47.jpg)
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
![Page 48: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/48.jpg)
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
![Page 49: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/49.jpg)
49
BD Example: formation
Stage 1: AG: ga
BG: gb
CG: gc DG: gd
Stage 2: AG: Xa=(gba/gda) BG: Xb=(gcb/gab) CG: Xc=(gdc/gbX) or Xc=(gX) DG: Xd=(gad/gcd)
Everyone computes? K = gab+bc+cd+da
![Page 50: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/50.jpg)
50
GDH.3 Example: formation
1) AB: ga
2) BC: gab gX
3) CG: gabc
4) Everyone ‘factors out’ its contribution• AD: gbc
• BD: gac
• CD: gab -- gX
5) DG: gbcd , gacd , gabd -- gX
Everyone computes gabcd
![Page 51: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/51.jpg)
51
Experimental Results (Computation)
Results without communication Meaningful for LAN-s Avg time for each membership event Considerations
• 1024 Bit RSA signature• TGDH: Random Tree• STR: picking random member for leave
![Page 52: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/52.jpg)
52
Computation Cost (Join and Leave)
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 128
Number of Remaining Group Members
Se
co
nd
s
BD
TGDH
GDH
STR
0
0.2
0.4
0.6
0.8
1
1.2
1.4
8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 128
Number of Current Group Members
Se
con
ds
BD
TGDH
GDH
STR
x-axis: # members before join TGDH, STR: almost 0.1 sec GDH worst TGDH: Joining node is near to
root due to random tree BD: hidden cost => signature
verification, modular multiplication
x-axis: # members after leave TGDH best STR worst
![Page 53: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/53.jpg)
53
Experimental Result (WAN)
Using Spread over high delay WAN• JHU: 11 machines
• UCI: 1 machine
• ICU (Korea): 1 machine
Approx. 300 ms r/t time
![Page 54: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/54.jpg)
54
WAN Experimental Results
Computational cost negligible Communication cost dominates Longest path determines delay
![Page 55: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/55.jpg)
55
Summary Seemingly efficient (i.e., least computation & smallest message sizes)
protocol is not always best Need to consider other parameters
• # of messages (esp. b-cast!)
• Resilience to failures
• Complexity of implementation
• Behavior in high-latency and mixed networks
The herd moves at the speed of the slowest beast…
![Page 56: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/56.jpg)
56
Other Models
![Page 57: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/57.jpg)
57
Asynchronous Model: Crashes+Read-only Insider Adversary
See Cachin/Strobl (PODC’04) Self-sufficient: no reliance on view-
providing GCS Needs tc-resilient consensus protocol n2 messages and O(1) extra rounds General; not DH-based (though can
be)• Needs encryption• Scalability?• Experiments?
![Page 58: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/58.jpg)
58
Further Info
GKA (CLIQUES) toolkit: GDH, STR, TGDH, BD
http://sconce.ics.uci.edu/cliques
Membership Control
http://sconce.ics.uci.edu/gac
Secure Spread:
http://www.cnds.jhu.edu/research/group/
secure_spread/
![Page 59: Group Key Agreement](https://reader033.fdocuments.net/reader033/viewer/2022051316/56814afd550346895db80f95/html5/thumbnails/59.jpg)
59
All done…