Network Model Security

Last week I described the network model we’re building for Croquet, and was asked about some security issues. I think the main security weaknesses to what I have described come from the ability to misrepresent oneself as the Introducer or as a machine responsible for a World, or to deny others access to a World or the Introducer by sending a bunch of messages to it that demand its attention. Part of the answer in both cases is to distribute the roles of Introducer and of Worlds among many machines

Let’s assume that we can distribute the function of a given World over several machines. This is actually fairly difficult, for reasons that I won’t go into here. But let’s pretend that it can be done. (Distributing the function of the Introducer is easy, and was briefly covered last week.)

If enough folks care about the functioning of a given World, then they should be able to provide enough resources to keep it going in the presence of denial-of-service attacks. For example, an attacker can get a connection to the identified World via the Introducer, and kill that node with garbage requests, but the other nodes for the World would survive. The collective nodes of a given World could rotate among themselves as to which should be the contact point registered with the Introducer for the given World’s identifier.
However, a World of relatively specialized or local interest might not be able to produce many machines, and an attacker with a lot of resources could jamb things up by making repeated bogus attempts to join the collaboration. Since the Introducer is globally distributed, we could have the Introducer provide some level of access control, failing to even tell an unauthenticated attacker about the current contact point for a World. But I’d like to see how things go before making the Introducer do more. (Besides, I imagine that for maximum routing efficiency, the long-term model for Croquet will have every Croquet host acting as a message-passer for every World, whether the host is participating in that World or not. That will provide more opportunities to defend against denial of service attacks. The network model from last week is just meant to cover the first “simplified” version of Croquet’s TeaTime architecture for World message routing.)

Folks using the services of an Introducer node or World node can verify their contact using public key certificates. E.g., Basicallly, the creator of a World creates a pair of encrypt/decrypt keys through one of the well-known asymmetric encryption techniques. The creator distributes the encryption key to each host whom he wants to share in the responsibility of managing a World. The decryption key is given to everyone (e.g., in the World itself). A client challenges the node, who encrypts the challenge with the key he has received separately. The cleint only accepts the node if the decryption key produces the original challenge. One variation is to require each new node to verify a challenge before it can join the distributed network of Introducer or World nodes. Another is to create a separate new pair of encrypt/decrypt keys for each node, so that they can be individually revoked (by yanking the public decryption key) if compromised.

The communications can be encrypted themselves for privacy. Asymmetric keys are too slow for encrypting whole sessions, but they’re just fine for encrypting the transmission of a computationally faster symmetric key that is then used for encrypting the rest of the session.

There’s also some opportunity, that I didn’t describe last week, for folks to tamper with “World definitions” (snapshots) as they are created or sitting on disk. These can include a hash of their contents, which is then encrypted using the privately distributed keys. The receiver decrypts the hash using the public key, and compares the value against their own computation of the hash of the contents. A mismatch is evidence of tampering.

Key management and distribution is a tricky thing, and I’m no expert. But my instinct is that the details are mostly orthogonal to basic ideas in the network model I presented.