[Next] [Up] [Previous] [Contents]
Next: 2.7 API Up: 2 Yoid Architecture Previous: 2.5 Parent Discovery and

2.6 Security Architecture Overview

This section gives only a scant overview of security in yoid. To be honest, I haven't given this area a great deal of thought, and in any event am not an expert in security. Clearly this area needs more work.

For yoid security, we are interested in the following:

  1. Preventing unauthorized members from joining a group.
  2. Preventing unauthorized members from reading content.
  3. Preventing any member from modifying content forwarded over the tree-mesh.

The first two items are probably somewhat easier than in IP multicast because the rendezvous can act as a point of access control and key distribution. For instance, the rendezvous could create a shared key for the group, and distribute these to joining members when they first contact the rendezvous. Members would not allow any host without the shared key to attach to them. Or, for something stronger but less scalable, members could always contact the rendezvous before allowing another member to become its child.

The third item is somewhat harder than in IP multicast. Assuming a single group key for content encryption, an authorized member attached to the tree-mesh can read and modify any sender's content before passing it on. To protect against this, it is necessary to use asymmetrical keys, with each sender holding a private key for itself, and all members holding a shared private key for the group (as well as the public keys for all senders and the group). The rendezvous would also have its own private key, which could be used to distribute senders' keys via the tree-mesh.

Content would be encrypted with the group's shared symmetric key, and the signature of the content would be encrypted with the sender's private key.

For more casual applications, such as a public chat group, where anybody can be a member, and where members cannot really be expected to use encryption, we need a way to prevent easy modification of content. Observing that a rogue member may by and large only modify content for those members ``behind it'' relative to the sender, one approach may be to have members transmit signatures of received content to their mesh neighbors. This would at least allow detection of modified content, though it might be quite hard to locate the rogue member.


[Next] [Up] [Previous] [Contents]
Next: 2.7 API Up: 2 Yoid Architecture Previous: 2.5 Parent Discovery and

Paul Francis
Fri Oct 1 11:06:22 JST 1999