Secure Group Communication

The secure group communication abstraction provides both point-to-point communication and secure multipoint communication. Point-to-point messages are encrypted with a key shared by the two ends. Multicast messages are encrypted with the group key. For data flows, we use DES encryption in CBC mode, which provides data secrecy and integrity. Except for the first group-join request message, which has a segment of clear text noting the name of the requester, all messages are fully encrypted. (Anonymity can be achieved through other means that are not discussed here.) Following the fail-stop and the explicitness principles [1, 10], we make every message unique by including in the message the identities of the sender and of the recipient, a timestamp, and a sequence number, as follows: {Sender_ID, Recipient_ID, Sequence_Number, Timestamp, Message_Body}. Such a format ensures that a message cannot be reused successfully in a different place, time, or context. This rather conservative approach results in quite long messages even when the real message body is short. This can be optimized when the encryption key can identify the sender or the context cannot be misunderstood.

Currently, the secure multicast mechanism performs best-effort communication and does not provide additional semantics such as group-wide causality or atomicity [3]. For example, messages within the group are not necessarily causally or totally ordered.

There are a few reasons for this design choice. First, the weaker the multicast semantics, the faster the mechanism can be. Second, in a leader-controlled group, all crucial traffic is serialized at the leader site; therefore, no synchronization is necessary at lower levels. Moreover, users tend to tolerate failures more intelligently than processes. For example, suppose there is a temporary network link failure so that updates to a file cannot be communicated between a leader and a group member. A member can queue his changes locally and then ``flush'' them when the network becomes functional again. He can also push a button to refresh the file manually to pull in all the updates from the group leader. In other words, a weak low-level secure multicast semantics ensures efficiency, while upper-level mechanisms handle failures and exceptions. In the extreme case where a member has been cut off because of network partition, he can join the group again and instantly obtain the fresh group state. We believe that such an approach provides the best ``economy'' for general users.

When a leader becomes inactive (e.g., because of system crash or other failures), there is currently no mechanism to automatically reestablish the group with a new leader. It is not clear that such a mechanism is required or even desirable in user-level groups. For example, certain group tasks depend on a specific person as the group leader (e.g., a lead drafter of a contract), and it does not make sense for the group to continue in his absence. Certain types of user groups may benefit from automatic leader election, and this is an area for further study.

Need help? Use our Contacts page.

Conference Index USENIX home