Walnut/Secure Distributed Computing/Satan at the Races

From Erights

Jump to: navigation, search

Example: Satan at the Races

Earlier we presented a single-computer racetrack game as an example. Here we present a distributed version of Racetrack, allowing people to compete over the network. And, just for a bit of spice, we have thrown in the assumption that one of the drivers will be Satan. Satan will, of course try to win...or try to wreck other people's cars (keeping his own safe, of course)...or try to ensure that someone Satan favors will win, presumably someone who has offered up his soul in exchange for victory.

Fortunately, as we all know from the story of the time the Devil came down to Georgia, as long as we can force Satan onto a fair playing field, he can indeed be beaten. We will need scrupulous capability security, however, to keep that field fair.

As noted earlier, security within the E framework is largely a matter of architecture. Therefore we will look at the issues for a secure distributed architecture before we look at the code.

First of all, where do we want to put the divide between the server functionality and the client functionality? If the author of this book owned stock in a diskless workstation company, we would undoubtedly present a "thin client" architecture, wherein everything except user interface code lived on the server. We will look at other possibilities here, however, since other possibilities abound.

E allows us to distribute the computation to suit our needs. We could build a thin client, a thin server, or anything that lies between these extremes. The particular architecture strategy we will use for this security example, with our souls on the line because Satan is coming to the party, is a "thin network" layout. We will minimize the amount of information being sent back and forth between the server (owned by the trusted third party who authoritatively asserts who won the race) and the clients (owned by the race car drivers, including Satan). We will especially minimize the number and power of the references (capabilities) the clients have on objects on the server, since this is the major path Satan will have for attacking the system.

With this as the architectural goal, we can reduce the information flow from client to server to merely proposals for the acceleration changes for the cars. Each driver (i.e., each client) should have access to the server only to the extent of being able to tell their respective cars on the server what acceleration the driver proposes. The clients must absolutely not have access to any cars on the server but their own. Consequently, a method like, "setAccelerationForCar(name)" cannot be the way car directions are specified: Satan, upon learning the names of the cars, could easily start specifying accelerations for everyone's cars, not just his own.

The server will initially send out maps to the clients: rather than giving the clients read authority on the raceTrack's map, the server will send each client an immutable pass-by-copy description of the map and the car starting locations. Sending out immutable copies that are locally accessible will simplify the code, reduce the communication needed during the actual game, and most significantly, will eliminate a set of interfaces that would need security audits.

As in the single-computer version of the game, the raceTrack will collect accelerations input by the drivers until it has accelerations from all the drivers, then it will authoritatively describe those accelerations to all the drivers. Note the careful language we use to describe the accelerations being sent around the system: driver clients send proposed accelerations for their own accelerations to the server; the server sends authoritative accelerations to the clients. Satan's easiest technique for assaulting the track would be to simply modify his client so he can specify accelerations beyond -1,0,+1; it would be a substantial advantage for Satan to be able to accelerate +15 in a single turn. So the server must validate the accelerations, and not rely on validation in the user interface as the single-computer version did.

As noted earlier when discussing pet names, another clever attack is to forge someone else's signature. If Satan could pretend to be whichever driver actually wins the race, and persuade people to believe him, it would be as good as actually having won (and quite a bit sweeter as well). This racetrack does not use the full-strength pet name strategy to prevent this. Rather, the server assigns each car a name. No negotiation is allowed.

So far, we have only considered attacks that can be made from the client on the server. Are there any security concerns going the other way, i.e., secret information that, if acquired by Satan, would improve his situation? If this were a game of poker, not a game of racetrack, the answer would be yes, and we would have to audit the data being sent to the client as well as the capabilities. For racetrack, however, this is not an issue.

What else can Satan do to sabotage the race? He can, of course, flood the server with spurious messages in a denial of service attack. As stated earlier, E by itself cannot prevent this. But for this critical game, we can assume the trusted third party operating the server will work with the ISPs to prevent it from inhibiting game play. There is one other denial-of-service attack Satan can undertake, the simplest attack of all: he can simply walk away from his computer, leaving the game with one car that never gets new acceleration instructions. In the single-computer version of racetrack, the game never stepped forward to the next turn until all the cars had new instructions. Left unchanged, this would allow Satan to starve all the drivers to death and then claim victory. Consequently, we must put a time limit into the distributed version, so that game play continues even if one of the players loses his soul in the middle of the competition.

That completes the security-oriented architectural considerations for the racetrack. One other architectural note: The cars will be implemented using the unum design: each client system will have a client presence of the car locally instantiated, synchronized in each game turn with the host presence of the car that resides on the server. As noted briefly earlier, the unum is a supercharged version of the Summoner pattern; in the Summoner pattern synchronization is not performed. Before this becomes cast in stone, I don't love "host presence". "Authoritative presence" is too long. How 'bout "essence"? Or "true presence"?

racetrack code

Personal tools
more tools