|
|
|
| 09/30/2002 | Secure Spread 2.1.0 is available. Supports Cliques 1.0. |
| 02/05/2002 | Secure Spread 2.0 is available. The major feature is that it supports four additional key agreement protocols, besides GDH. For the new four key agreement protocols, only simple cases are supported for now (join, leave, partition, merge), the only protocol robust to any cascading group events is GDH. For more details see the README file available in the distribution. |
| 02/05/2002 | Patch available for Secure Spread. Also patch for Spread 3.16.1 available. Thanks to Frank Cole for providing them. Note that Secure Spread patch should be applied after the patch that solved the message type problem (available below). |
| 01/29/2002 | Secure Spread 1.0.0 does not compile out of box with Spread 3.16.1. The reason is that one variable defined by Spread and used by Secure Spread changed its name (MAX_SCATTER_ELEMENTS is now MAX_CLIENT_SCATTER_ELEMENTS). Fix: replace any MAX_SCATTER_ELEMENTS in the Secure Spread distribution tree with MAX_CLIENT_SCATTER_ELEMENTS. |
| 11/15/2001 | A patch that solves a problem with the message type for Secure Spread is available. Thanks to Roy Tromble for noticing the problem |
| 07/16/2001 | Spread 3.16.0 which is compatible with Secure Spread 1.0.0 was released. |
| 06/01/2001 | The Johns Hopkins Information Security Institute becomes a collaborator on the Secure Spread project. |
| 03/30/2001 | Secure Spread 1.0.0 available. Note that you still need Spread 3.12 or 3.14 . |
| 03/28/2001 | An incompatibility between Secure Spread and Spread 3.15 was reported. Spread 3.12 or 3.14 are required. |
| 11/05/2000 | Secure Spread 0.0.3 available. |
The Secure Spread project addresses integrating security services with reliable group communication. In particular, it enhances the Spread Toolkit with security services.
Group communication systems are application level multicast systems, providing reliable and ordered (FIFO, Causal, Agreed, Safe) message delivery, and a group membership service. The membership service notifies the upper-level application about every group change and about the list of current group members. Many group communication systems are built around a client-server architecture where a small number of servers provide service to numerous clients.
Confidentiality is the main concern of secure group communication. As using public cryptography tools is very expensive, efficient security services can be provided by means of symmetric cryptography which requires the members of a group to share a secret key.
Secure group communication requires forward and backward secrecy to protect previous or future members of the group to decipher confidential communication. In the context of a dynamic group membership, these requirements make the management of the shared key a challenging problem. Moreover, the interrelation between high-availability and security guarantees are not well understood, especially in the presence of general, possibly cascading, network events.
Our approach uses contributory key agreement methods that proved to provide advantages versus centralized key distribution schemes.
We provide a secure group communication layer and an API that uses a robust contributory key agreement protocol based on the GDH suite protocol developed by the Cliques project. Our key agreement protocol handles processor and network faults (under a fail-stop or crash-and-recover model), asynchronous membership events (such as cascading joins,leaves,merges and network partitions) and is robust to any sequence (possibly cascading) of group membership changes.
Current work consists of providing a practical, scalable secure group communication, by integrating security services into the servers. By hosting the expensive key agreement protocols at the servers we amortize the associated cost over many groups. Using this method, joins and leaves become very fast, while the cost for refreshing the key when partitions and merges occur decreases significantly. Questions: yairamir@cs.jhu.edu