Continuous Group Key Agreement Sample Clauses

Continuous Group Key Agreement. Informally, in a CGKA protocol any party ID1 can initialise a group G = (ID1, . . . , IDn) by sending a message to all group members, from which each group member can compute a shared group key I. The initiator ID1 must know a public key pki of each invitee IDi, which in practice could be realized by having a key-server where parties can deposit their keys. As this key-management problem is largely orthogonal to the construction of CGKA, in this work we will assume that such an infrastructure exists. Apart from initialising a group, CGKA allows any party IDi currently in the group to update its key. Informally, after an Update6 operation the state of IDi is secure even if its previous state completely leaked to an adversary. Moreover any group member can add a new group member, or remove an existing one. These operations (Update, Add, Remove) require sending a message to all members of the group. As we do not assume that the parties are online at the same time, IDi cannot simply send a message to IDj. Instead, all protocol messages are exchanged via an untrusted delivery server. Although the server can always prevent any communication taking place, we require that the shared group key in the CGKA protocol – and thus the messages encrypted in the messaging system built upon it – remains private. Another issue we must take into account is the fact that (at least for the protocols discussed below) operations must be performed in the same order by all parties in order to maintain a consistent state. Even if the delivery server is honest, it can happen that two parties try to execute an operation at the same time. In this case, an ordering must be enforced, and it is natural to let the delivery server do it. Whenever a party wants to initiate an Update/Remove/Add operation, it sends the message to the delivery server and waits for an answer. If it gets a confirmation, it updates its state and deletes the old one. If it gets a reject, it deletes the new state and keeps the old one. Note that when a party gets corrupted while waiting for the confirmation, both, the old and new state are leaked. Asynchronous Ratcheting Tree (ART). The first proposal of (a simplified variant of) a CGKA is the Asynchronous Ratcheting Tree (ART) by ▇▇▇▇-▇▇▇▇▇▇ et al. [8]. This protocol (as well as TreeKEM, discussed below, and our protocol) identifies the group with a binary tree where edges are directed and point from the leaves to the root.7 Each party IDi in the group is assigned ...

Continuous Group Key Agreement. This section describes the structure and security of the continuous group key agreement (CGKA) protocol introduced by ▇▇▇▇▇ et al. [3]. They first provided a formal definition and security model of TreeKEM, the core technology of the MLS protocol, as CGKA. Then, they developed RTreeKEM by improving the vulnerability of TreeKEM through a UPKE using the normal public key encryp- tion. In this paper, we utilize RTreeKEM with UPKE applied as a CGKA proto- col. A CGKA protocol aims at providing a steady stream of shared (symmetric) secret keys for a dynamically evolving set of parties. This aspect is tied together by epochs, where each epoch provides a timestamp role in asynchronous process- ing. CGKA schemes are non-interactive; that is, a party creates a new epoch by broadcasting a single message, which can then be processed by the other mem- bers to move along. Rather than relying on an actual broadcast scheme, CGKA schemes merely assume the existence of an untrusted (or partially trusted) deliv- ery service. As multiple parties might try to initiate a new epoch simultaneously, the delivery service’s main job is to determine the first one by picking an order. As a consequence, a party cannot immediately initiate a new epoch by itself. The MLS working group has improved on such stagnation and now considers the propose-and-commit method [8]. In this section, however, we present Alwen et al.’s (without propose-and-commit) CGKA protocol for simplicity. The basic structure of both schemes is the same, and we apply our ideas to ▇▇▇▇▇ et al.’s protocol from here onward. By applying our ideas to the propose-and-commit scheme, we can immediately construct CGKA-FA (as discussed in Section 5).

Continuous Group Key Agreement. To begin with, we define the notion of continuous group-key agreement (CGKA). Parties participating in the execution of a CGKA protocol will maintain a local state γ, allowing them to keep track of a common ratchet tree, to derive a shared secret. Parties will be able to add and remove users to the execution, and to rotate the keys along sections of the tree, thus achieving FS and PCS. Our definition is similar to that of [23], with the main difference that operations do not need to be confirmed individually by the server. Instead, the stateful server works in rounds, collects operations into batches and sends them out at the end of each round (note that setting the batch size equal to 1 would just return the definition from [23]). Accordingly, a party issuing an operation will no longer be able to pre-compute its new state should the operation be confirmed. Definition 1 (Asynchronous Continuous Group-key Agreement). An asynchronous continuous group-key agreement (CGKA) scheme is an 8-tuple of algorithms CGKA = (CGKA.Gen, CGKA.Init, CGKA.Add, CGKA.Rem, CGKA.Upd, CGKA.Dlv, CGKA.Proc, CGKA.Key) with the following syntax and semantics: ← Key Generation: Fresh InitKey pairs ((pk, sk), (ssk, svk)) CGKA.Gen(1λ) consist of a pair of public key encryption keys and a pair of digital signing keys. They are generated by users prior to joining a group, where λ denotes the security parameter. Public keys are used to invite parties to join a group. Initialize a Group: Let G = (ID1, . . . , IDn). For i ∈ [2, n] let pki be an InitKey PK of party IDi. Party ID1 creates a new group with membership G by running: (γ, [W2, . . . , Wn]) ← ▇▇▇▇.▇▇▇▇ (▇, [▇▇▇, . . . , ▇▇▇] , [▇▇▇▇, . . . , svkn] , sk1) and sending welcome message Wi for party IDi to the server. Finally, ID1 stores its local state γ for later use. ← Adding a Member: A group member with local state γ can add party ID to the group by running (γ, W, T ) CGKA.Add(γ, ID, pk, svk) and sending welcome message W for party ID and the add message T for all group members (including ID) to the server. Removing a Member: A group member with local state γ can remove group member ID by running (γ, T ) CGKA.Rem(γ, ID) and sending the remove message T for all group members (ID) to the server. ← Update: A group member with local state γ can perform an update by running (γ, T ) CGKA.Upd(γ) and sending the update message T to the server.

Continuous Group Key Agreement. To begin with, we define the notion of continuous group-key agreement (CGKA). Parties participating in the execution of a CGKA protocol will maintain a local state γ, allowing them to keep track of a common ratchet tree, to derive a shared secret. Parties will be able to add and remove users to the execution, and to rotate the keys along sections of the tree, thus achieving FS and PCS. Our definition is similar to that of [25], with the main difference that operations do not need to be confirmed individually by the server. Instead, the stateful server works in rounds, collects operations into batches and sends them out at the end of each round (note that setting the batch size equal to 1 would just return the definition from [25]). Accordingly, a party issuing an operation will no longer be able to pre-compute its new state should the operation be confirmed.

Continuous Group Key Agreement. To the best of our knowledge, all next gen. E2E protocols share the following basic design para- digm. At their core lies a Continuous Group Key Agreement (CGKA) protocol; a generalization to the group setting of the Continuous Key Agreement 2-party primitive [4, 28] underlying the Double Ratchet. Intuitively, a CGKA protocol provides E2E secure group manage- ment for dynamic groups, i.e., groups whose properties may change mid-session. By properties we mean things like the set of members currently in the group, their attributes, the group name, the set of moderators, etc. Any change to a group’s properties initiates a fresh epoch in the session. A CGKA protocol ensures all group members in an epoch agree on the group’s current properties. Members will only transition to the same next epoch if they agree on which prop- erties were changed and by whom. Each epoch is equipped with its own symmetric epoch key known to all epoch members but indis- tinguishable from random to anyone else. Higher-level protocols typically (deterministically) expand the epoch key into a complete key schedule which in turn can be used to, say, protect application data sent between members (e.g. messages or VoiP data). MLS too, is (implicitly) based on a CGKA, originally dubbed TreeKEM [17]. Since its inception, TreeKEM has undergone several substantial revisions [11, 12] before reaching its current form [9, 13]. For clarity, we refer to its current version at the time of this writing as Insider-Secure TreeKEM (ITK) (using the terminology of [9] where that version was analyzed). ITK has already seen its first real world deployment as a core component of Cisco’s Webex conferencing protocol [25]. Why Consider CGKA?. CGKA is interesting because of the fol- lowing two observations. First, CGKA seems to be the minimal functionality encapsulating almost all of the cryptographic chal- lenges inherent to building next generation E2E protocols. Second, building typical higher-level E2E applications (e.g. SGM or confer- ence calling) from a CGKA can be done via relatively generic, and comparatively straightforward mechanisms. Moreover, the result- ing application directly inherits many of its key properties from the underlying CGKA; notably their security guarantees and their com- munication and computational complexities. In this regard, CGKA is to, say, SGM what a KEM is to hybrid PKE. For the case of SGM, this intuitive paradigm and the relationship between properties of the CGKA and resu...