During the SCHEMESTATION Project 1997-98, a prototypical simulator of a new operating system --- SCHEMESTATION --- has been implemented. An essential part of the visioned SCHEMESTATION system is its low-level strong security paradigm. This paradigm, however, has not been properly implemented in the simulator due to the lack of resources and, partially, lack of interest.
This document examines the security paradigm and shows how it could be implemented in a SCHEMESTATION system resembling the current simulator. It is not very interesting to implement real security functionality, e.g. encrypted data channels, in a simulator because security can be assumed to be present. However, a real system could be implemented much in the same way as the simulator, and thus the workings of the simulator can be used as a model of a system where the security system would really need to be installed.
The SCHEMESTATION security paradigm consists of three main components:
Moreover, the paradigm is completely distributed.
Agent addresses are defined to be randomly chosen 256-bit bit strings (see Operating system specification). Agents are able to communicate with other agents only via asynchronous message passing. To send a message to another agent, the address of the receiver must be known. Thus, right to access an agent is to possessing the agent's address. In order to gain unprivileged access to an agent one must guess an agent address and then send a message to the guessed address. Assuming that there are n agents and that an intruder wants to guess at least one of the addresses of the agents, the probability of chosing an address that belongs to one of the agents is approximately 1 - (1 - 2-256)n. To put this value into perspective, we note that for any realistic value of n, this probability is much lower than the probability of guessing the correct key for a 128-bit state-of-art encryption method like IDEA. For example, if n = 10,000 the probability is lower than 10-73; the probability of guessing a 128 bit key is around 10-40.
The equivalence of agent addresses and access rights leads to the implication that active agent addresses need to be protected from unwanted disclosure. Due to the controlled virtual machine architecture of the SCHEMESTATION operation system, agent addresses are completely safe as long as they remain inside a properly implemented domain. However, when addresses travel accross domain boundaries they need to be explicitly protected. This protection is achieved as a side-effect of the two other components of the security paradigm, namely the protection of inter-domain communications, and trust relationships.
The inter-domain communications need to be protected against (1) voluntary and involuntary (external) modification, and (2) eavesdropping. These both security goals can be achieved by using strong cryptography, including encryption and integrity control. Usually encryption works best on stream-like connections, so a good starting point is to assume that domains maintain cryptographically protected stream-like connections between them, implemented e.g. on the top of the TCP/IP protocol suite. These connections can be created and destroyed dynamically. Together they form a dynamic intranet between active SCHEMESTATION domains.
Note that maintaining permanent, distinct connections between all SCHEMESTATION domains is not preferable as then the number of connections grows very large (quadratic to the number of domains) and many of the connections are not used at all. Thus dynamic method is a good choice.
As inter-domain links are cryptographically protected and authenticated, any domain knows which other domains are communicating with it. It is possible to correctly identify the origin of a data item that arrives from the network, to authenticate its sender and to achieve confidence of its confidentiality and integrity. This gives domains the possibility to handle data arriving from different domains in a different way. Discretion that is based on the origin and destination of a data message, on the domain level, is thought to be implemented using trust relationships in the SCHEMESTATION security paradigm. However, maintaining trust relationships is a task local to a domain, so there need not to be any global notion of a trust relationship per se.
The first component of the security paradigm is properly implemented in the currently existing simulator, naturally because without addresses the agents cannot communicate at all, and using random addresses is not a technical problem.
In the simulator, network communications are simulated by using a special component called the SCHEMESTATION Network Simulator. In real life, however, networking must be really implemented, probably on the top of an existing protocol suite, in a hostile environment.
As mentioned before, the assumed networking model for real SCHEMESTATION domains is dynamically updated cryptographically protected intranet based on stream connections, perhaps on the top of TCP/IP. An intranet like this can be maintained as follows. We present two models, a directly connected intranet, where stream connections are opened directly between any two domains doing communication, and a routing intranet, where data items may travel trough many domain-to-domain stream connections before they arrive at their intended destination domain. Naturally routing intranet is a generalization of a directly connected intranet; we discuss this later.
As we said, routing intranet is a generalization of a directly connected intranet. Because in some occasions a routing intranet can be a preferable choice, we assume from now on that the SCHEMESTATION intranet is routing in any case.
It is now time to put some flesh on the bones, and we turn to discuss how cryptographically protected inter-domain connections can be really implemented in a SCHEMESTATION domain.
The structure of a SCHEMESTATION domain is roughly the following: there is hardware, including main hardware, devices and device drivers, and on the top of this hardware runs the SCHEMESTATION domain kernel. The domain kernel provides a user space where agents execute on the top of the SCHEMESTATION virtual machine. Devices are controlled by device driver agents that are partly implemented in the kernel and partly in the user space.
A network protocol is then implemented in another agent (or a set of agents) that utilize the network device driver. When a message is sent to another domain via network agent, it is given to the network protocol agent. See Fig. 1.
Thus, to implement cryptographically protected connections, the network protocol agent needs to (1) know a cryptographic protocol that is used in the other SCHEMESTATION domains the local domain communicates with and (2) to be able to run this protocol in co-operation with other protocols. A probable scenario would be that there were first an TCP/IP agent, implementing a TCP/IP suite, and then another agent would be added that utilized this TCP/IP agent and implemented cryptographically strong connections.
The purpose of trust relationships is to control how messages from another domains are to be interpreted and handled. Examples of trust relationships and their usage are given elsewhere (see. eg. Operating system specification) so we concentrate only on the technical issues concerning their implementation.
However, there is nothing special in their implementation, so this dicussion will remain short. Namely, consider Fig. 1 again. When messages are received from the network the sending domain is known due to the authentication of inter-domain communications. After a message is received, it passed to the kernel that delivers it further. The network protocol agent can pass the domain address of the sending domain along with the message to the kernel, and then the kernel can do whatever it wishes with this address. Complex decisions based on domain addresses can be implemented in e.g. specialized agents that communicate with the kernel; thus no change in the underlying architecture is needed.
The purpose of this document was to show how the proposed SCHEMESTATION security paradigm could really be implemented in a SCHEMESTATION domain implementation. We showed that achieving this does not need any real changes in the SCHEMESTATION architecture itself. Adding a couple of new agents and perhaps a small amount of hooks to the low-level domain kernel are sufficient.