Cascaded Events

Since network disruptions are random and unpredictable, it is natural to consider the possibility of so-called cascaded membership events. (In fact, cascaded events and their impact on group protocols are often considered in group communication literature, but, alas, not often enough in the security literature.) A cascaded event occurs, in its simplest form, when one membership change occurs while another is being handled. Event here means any of: join, leave, partition, merge or a combination thereof. For example, a partition can occur while a prior partition is being dealt with, resulting in a cascade of size two. In principle, cascaded events of arbitrary size can occur if the underlying network is highly volatile.

We claim that the TGDHpartition protocol is self-stabilizing, i.e., robust against cascaded network events. This is quite rare as most multi-round cryptographic protocols are not geared towards handling of such events. In general, self-stabilization is a very desirable feature since lack thereof requires extensive and complicated protocol "coating" to either 1) shield the protocol from cascaded events, or 2) harden it sufficiently to make the protocol robust with respect to cascaded events (essentially, by making it re-entrant).

The high-level pseudocode for the self-stabilizing protocol is shown in figure 9. The changes from figure 8 are minimal.

  
Figure 9: Self-stabilizing protocol pseudocode

 
 

Figure 10: An Example of Cascaded Partition

Instead of providing a formal proof of self-stabilization (which we omit due to page limitations) we demonstrate it with an example. Figure 10 shows an example of a cascaded partition event. The first part of the figure depicts a partition of $M$₁, $M$₄, and $M$₇ from the prior group of ten members $\{M$₁,&ldots;,M₁₀}. This partition normally requires two rounds to complete the key agreement. As described in section 5.4, every member constructs the same tree after completing the initial round. The middle part shows the resulting tree. In it, all non-leaf nodes except $K$_2,3 must be recomputed as follows:

1. First, $M$₂ and $M$₃ both compute $K$_2,0 , $M$₅ and $M$₆ compute $K$_2,1 while $M$₈, M₉ and $M$₁₀ compute $K$_1,1 . All blinded keys are broadcasted by each sponsor$M$₂, M₅ and $M$₈.
2. Then, as all broadcasts are received, $M$₂, M₃, M₅ and $M$₆ compute $K$_1,0 and $K$_0,0 . The blinded keys are broadcasted by the sponsor$M$₆.
3. Finally, all broadcasts are received and $M$₈, M₉ and $M$₁₀ compute $K$_0,0 .

Suppose that, in the midst of handling the first partition, another partition (of $M$₃ and $M$₈) takes place. Note that, regardless of which round (1,2,3) of the first partition is in progress, the departure of $M$₃ and $M$₈ does not affect the keys (and blinded keys) in the subtrees formed by $M$₉ and $M$₁₀ as well as $M$₅ and $M$₆. All remaining members update the tree as shown in the rightmost part of figure 10. The blinded key of $K$_1,0 is the only one missing in all members' view of the tree. It is computed by $M$₂, M₅ and $M$₆ and broadcasted by $M$₆. When the broadcast is received, all members compute the root key.

The only remaining issue is whether a broadcast from the first partition can be received after the notification of the second (cascaded) partition. Here we rely on the underlying group communication system to guarantee that all membership events are delivered in sequence after all outstanding messages are delivered. In other words, if a message is sent in one membership view and membership changes while the message is not yet delivered, the membership change must be postponed until the message is delivered to the (surviving) subset of the original membership. This is essentially a restatement of View Synchrony (as discussed in section 3).