Postscript document

next up previous
Next: Member Join Protocol Up: Protocols Previous: Protocols

Notation

 

We use the following notation:

n,N   number of protocol parties (group members)
i,j   group member indices: i,j ∈{1,&ldots;,N}
Mi   i-th group member; i ∈{1,&ldots;,N}
ri   Mi's session random (secret key of leaf node Mi)
bri   Mi's blinded session random, i.e. ri p
kj   secret key shared among M1...Mj
bkj   blinded kj, i.e. kj p
p   large prime number
α   exponentiation base

Tree-specific notation
Nj   Tree node j
INl   Internal tree node at level l
LNi   Leaf node associated with member Mi
Ti   Tree of member Mi
BTi   Tree of member Mi including all of its blinded keys

  figure228
Figure 1: Notation for STR

Figure 1 shows an example of an STRkey tree. The tree has two types of nodes: leaf and internal. Each leaf node is associated with a specific group member. An internal node INi always has two children: another (lower) internal node INi-1 and a leaf node LNi+1 . The exception is IN1 which is also a leaf node corresponding to M1. (Note that, consequently, r1=k1.)

Each leaf node LNi has a session random ri chosen and kept secret by Mi. The blinded version thereof is bri = 4ri p.

Every internal node INj has an associated secret key kj and a public blinded key bkj = 5kj p. The secret key ki (i > 1) is the result of a Diffie-Hellman key agreement between the node's two children. (k1 is an exception and is equivalent to ri.) ki  (i > 1) is computed recursively as follows:

ki = (bki-1)4ri p = (bri)4ki-1 p = 4riki-1 p if i > 1.

The group key in Figure 1 is the key associated with the root node:

k4 = 4r44r34r2r1

We note that the root (group) key is never used directly for the purposes of encryption, authentication or integrity. Instead, such sub-keys are derived from the root key, e.g., by applying a cryptographically secure hash function to the root key. All blinded keys bki are assumed to be public.

The basic key agreement protocol is as follows. We assume that all members know the structure of the key tree and their initial position within the tree. (It is simple to have an ordering that uniquely determines the location of each member in a key tree.) Furthermore, each member knows its session random and the blinded session randoms of all other members. The two members M1 and M2 can first compute the group key corresponding to IN2 . M1 computes:

k2 = (br2)4r1 p = 4r1r2 p, bk2 = k2 p k3 = (br3)4k2 p, bk3 = k3 p ... kN = (brN)4kN-1 p

Next, M1 broadcasts all blinded keys bki with 1 ≤i ≤N-1. Armed with this message, every member then computes kN as follows. (As mentioned above, members M1 and M2 derive the group key without additional broadcasts.) Any Mi (with i>2) knows its session random ri and bki-1 from the broadcast message. Hence, it can derive ki = bki-14ri p. It can then compute all remaining keys recursively up to the group key from the public blinded session randoms: ki = bri+14ki p (i ≤N).

Following every membership change, all members independently update the key tree. Since we assume that the underlying group communication system provides view synchrony (see Section 2.1), all members who correctly execute the protocol recompute an identical key tree after any membership event. The following fact describes the minimal requirement for a group member to compute the group key:
 remark305

Proof. This follows directly from the recursive definition of the group key. In other words, both M1 and M2 (the member at the lowest leaf nodes) can obtain the group key by computing pairwise keys recursively and using blinded session randoms of other members.


 remark309

Proof. This also follows from the definition of the group key. To compute the group key, member Mi needs 1) ri, 2) bki-1, and 3) bri+1,bri+2,&ldots;,brN.

The protocols described below benefit from a special role (called sponsor) assigned to a certain group member following each membership change. A sponsor reduces communication overhead by performing "housekeeping" tasks that vary depending on the type of membership change. The criteria for selecting a sponsor varies as described below.


next up previous
Next: Member Join Protocol Up: Protocols Previous: Protocols

Adrian Perrig
Sat Mar 31 16:41:33 PST 2001