Walnut/Secure Distributed Computing/E Capabilities

From Erights

E Capabilities

E has no pointer arithmetic. E has no mutable statics. E has an API carefully thought out to prevent capability leaks. This would make it a capability secure language for single-processor applications. But E goes a step further. It takes the concept of a secure, unforgeable object reference and extends it to distributed objects:

• The communication links are encrypted. Third parties cannot get inside the connection.
• The objects are unfindable without a proper reference received (directly or indirectly) from the creator of the object. You must have the key to unlock the door.
• No object can pretend to be the object you are trying to contact because identity cannot be hijacked.

These aspects of E protocol can be understood better by looking at the URI that identifies an E object to other objects outside its own vat.

A closer look at E capability URIs

Security as an inexpensive lunch

There is no such thing as a free lunch, but this does not rule out the possibility of lunches at bargain prices. When programming in E, you are automatically working in a capability secure environment. All references are secure references. All powers are accessible only through capabilities. Making an E program secure is largely a matter of thinking about the architecture before you code, and doing a security audit after you code. When designing and auditing you use a small number of principles for scrutinizing the design:

Principle of Least Authority (POLA) for Computer Programs

The Principle of Least Authority (known henceforth as POLA), which has been used by human beings instinctively for thousands of years, translates to computer programs fairly straightforwardly: never give an object more authority than it needs. In particular, if an object may be running on a remote untrusted machine, think very carefully about the minimum set of authorities it needs, and give it capabilities only on facets (described later) that ensure it gets no more. A simple word processor needs read and write access to the one file it is being used to edit, and it needs read-only access on all the system fonts. It does not need any access to anything else. Do not give it access to anything else. If it asks for something else, it is lying to you, and you should not trust it.

Principle of Hardware Software Ownership

When developing software, remember that the person who controls the hardware always, at the end of the day, controls the software. Hence, if you send someone a piece of a distributed program to run on their own equipment, that person totally and utterly owns everything that resides on his machine. They can modify the code you gave them, or rewrite it from scratch yet make it look from the outside like it is identical. You must therefore think carefully about what features of your system you really trust on that remote machine. A key feature of E that enhances its reliability is that objects which are manufactured in a particular vat remain resident in that vat, so that the objects remain as reliable as the objectMakers used to produce them. Only transparent immutables (immutables that don't encapsulate anything) actually move across computational boundaries.

Many people have made the error of believing this principle of hardware ownership can be circumvented. At the time of this writing, the music recording industry is throwing away truly fabulous sums of money on schemes that assume they can somehow control data after it has arrived on a user's own hardware. Microsoft is busily developing Palladium (uh, I mean, NGSCB). Intel is busily developing TCP (uh, I think they changed the name to La Grande). Their fate has already been foretold in the fate of the popular game Diablo I: authoritative representations of data were allowed to reside on user computers, assuming that the object code was too difficult to understand to be hacked and that the Diablo client code would always behave as the designers intended. They were 99% correct, which in the computer security field means they were 100% wrong. Today, 99% of the people who hack Diablo I don't understand the object code. But somewhere some single individual figured it out and posted the result on the Web. Now your grandmother can sabotage shared Diablo I games as quickly and easily as the most accomplished hacker in history. For Diablo II, the developers had learned the lesson. Authoritative information is stored only on the server, giving them the beginnings of true security.

Not only does hardware own the software, so too does the underlying operating system. As we have stated repeatedly here, E enables the construction of extremely secure computing systems. However, E systems can still be attacked from below, by viruses granted authority by the operating system underneath the E world. Such attacks can only be prevented by completing the security regime, either with capability-based operating systems, or with computers on which only capability-secure programs are allowed. There is one open-source capability-based OS under development, at www.eros-os.org.

Denial Of Service Attacks

One form of attack that even E cannot defend against is denial of service (DOS). In a denial of service, someone simply swamps your system with requests, making your system unable to operate. Such attacks take many forms, but the key limitation in such attacks is this: such an attack can never steal your secret data or gain control of your sensitive operations. If DOS were the only kind of attack possible, the world would be a vastly better place. Indeed, if only DOS attacks were possible, even most modern DOS attacks would fail, because the serious DOS attacks require that the attacker first gain control of hundreds of computers that belong to other people, by using attacks far more invasive and damaging than DOS itself.