Ebola
or
The Abolition of Root
Version 0.1
Justin Townsend
Introduction
Modern security systems follow a paradigm that is rooted in the earliest days of computer science. This paradigm, in turn, is rooted in the structure of the majority of human culture for the past few thousand years. This is the idea of the all-powerful ruler who generously hands down favors reflected in all aspects of culture. In biology, it is the alpha male ruling the group with an iron fist. In government, it is the figurehead of a king or, more potently, the president and most religions have either one all-powerful deity or universal force who is the foundation of all reality. Information systems, whose structure crudely mirrors our thought processes, are not devoid of this idea. The kings of these systems are known as administrators have power only limited by largely ineffectual organizational policies and less knowledgeable superiors. These "kings" have "vassals" in the form of printer administrators, user administrators, and security administrator. The architecture described in this paper, tentatively entitled Ebola (Equality Based Operating LAir) is designed, not to arbitrarily throw away these ideas as they have their use in some implementations, but to provide a more flexible set of solutions for creating new systems, including those with a completely flat hierarchy, or a totally democratic administrative system.
This paper is not intended to address certain important issues such as:
physical ownership and security of the hardware platform
various legal issues concerning legal issues such as key escrow
the pseudo-random number generator
An Overview
The primary goal of Ebola to to allow flexibility in the hierarchical structure of an operating system. However, the original design goal was to create a totally "flat" security architecture. The flexibility of Ebola arises from this architecture, to the point where a traditional security could be emulated, making the Ebola architecture a superset of traditional security.
The basic idea behind Ebola is the retention of power by users. The users in a "flat" Ebola system all share equal power, expressed in the priority of processes, amount of physical memory, and amount of long-term storage space. This power is, however, transferrable at will to other users, group processes, or the total system.
Ebola's concept of a group is markedly different than that in UNIX. A Ebola group is essentially a user created by one or more Ebola users.
The process of creating a group consists of an initial contract(described later) which creates an UID (user identification) and allows an allocation of resources from the creating users to the new UID. This new UID's control can be handled in several ways outlined later. There is one initial group which, admittedly, holds the power thought of as root access, control of which is outlined in the section concerning initial system configuration. This group controls ratio of system resources to user resources and administration of the subsystems.
The Kernel
The kernel selected for this architecture is a microkernel. This selection was made using the following criteria:
Stability-A primary constraint of this architecture is its unwieldiness in
initial booting. Also, it must be easy to add different modules such as filesystems and protocols without endangering existing processes and the stability of the core kernel
Security-By their very nature, microkernels consist of a smaller codebase, owing for more thorough code auditing.
Flexibility-As noted above, the architecture must be able to add or
remove various protocols and filesystems without endangering the
core functionality.
Scheduling-The kernel must be able to allocate processing time
in a very granular fashion. Microkernels have been used extensively in real-time systems
The Subsystems
The subsystems of Ebola constitute the majority of the functionality visible to users. They are:
Cryptography
Communication
Logging
Input/Output
Election/Authentication
3.1 Cryptography
The most straightforward of the subsystems is the cryptography subsystem. It provides an API to the cryptographic subsystems so important to the Ebola platform.
The primary cryptographic alogorithms made available are:
Assymetric key encryption
Symmetric key encryption
Threshold key encryption
The concepts of assymetric and symmetric encryption should be familiar, but special attention is needed for threshold key encryption, as it is not widely in use.
Threshold key encryption consists genrating a key, and from this key, generating sub-keys, which, when recombined, generate the original key. The central feature of the algorithm is that the algorithm can be configured to provide a threshold, in that only a subset of the keys, in any combination, can be used to generate the original. For instance, an algorithm could be produced to generate 10 keys, but only need 6 keys to reconstitute the original. This functionality is of the utmost importance to the Election/Authorization subsystem, as will be shown.
3.2 Communication
The next subsystem to be considered is the communication subsystem.
The communication subsytem deals with communication between users in the Ebola system. It provides anonymous, pseudo-anonymous(discussed later), group or user non-repudiative posting of information. These postings are timestamped by the server and can be marked for future release.
The communication subsystem supports trivial communication as well as a serving as a record for contracts. In the initial design the communication subsystem will also incorporate the functionality of scheduled execution as provided by the cronjob facility and the automatic creation of processes provided by inetd under unix. This functionality supports the execution of contracts as will be discussed later, and might be moved to another subsystem during implementation of the system.
Another function of the communication subsystem is the interface to voting, whether anonymous or public.
The communication subsystem will provide an API as well as a user interface that is as yet to be decided. The interfaces under consideration are a console interface, an http interface and an email interface.
3.3 Logging
The logging system will be able to achieve logging by either of two methods, local or distrubuted. In either case the logs will be encrypted by the orginator. In the local method of logging, the logs will be placed in a file as in a standard computing base. In the distributed system, logs will be placed in a file until a defined threshold is met. When the threshold is met or exceeded the file will be rotated out and copied to a designated recipient. When a signed receipt is returned, the original file will be digitally signed, the signature stored in a log file, and the original will be deleted. The digital signature logs will be rotated out in a recursive fashion to ensure unlimited logging storage space. This is a fairly straightforward process for logs for an individual user. However when a group process creates a log (including system logs) special care must be taken to insure anonymity and security of logs. The logs must be ensured to expose no information of their contents to the receiving party. Upon creation of a group requiring logging, it must be decided if the logs will be publicly available to all, if they can only be accessed by a quorum agreement, or a combination of the two.
3.4 Input/Output
As most implementations of an Ebola platform will not require terminal connectios, except in special cases, the majority of the input/output subsystem's functionality concerns networking. The primary protocols used with Ebola will initially by standard TCP/IP using Ipv4. IPv6 will be considered, but will not be difficult to integrate, as it will facilitate much of the functionality needed by Ebola, such as authentication. The Input/Output subsystem will primarily deal with the binding of reserved ports (1024 and below) to processes. In doing so, it will interface to the Election subsystem The other use of the I/O subsystem will be that of a protocol loader if other protocols are needed.
3.5 Election/Authentication Subsystem's
The E/A subsytem is the most radical and important subsystem in the Ebola system. It is the system that assigns new UID's to new users and groups. It transfers and records the communal allocation of resources, in an anonymous manner if mandated by the formation of the group. It also interfaces with the cryptographic and communication subsystems to destroy and create new keys and with the logging subsystem to record past public keys.
4 Creation
The best way to illustrate the interoperability of the Ebola subsystems is to provide the processes of creating the system itself, the creation of new users, and the creation of new groups.
4.1 The Initial Configation
The initial configuration begins with a group of users colluding to create an Ebola platform. They create a "contract," a signed document that will resign on record in the communication system outlining the base rules of the system. These rules cover the amount of resources set aside for system use, rules for adding users (covered later), rules for dissolution of the platform, logging procedures, rules for the expungement of users, rules for allocation of priveleged ports, and other configuration parameters. An important common feature of these rules is that they must all be completely concrete and measurable. Thus, a rule cannot be made to remove a user accused of any act, but instead would indicate the percentage of the user base required to vote for user expungement (if any).
4.2 User Addition
The method for user addition is to be decided in the initial configuration process. The users of an Ebola platform can be static, all added during initial configuration, or dynamic with additional users being added during the lifetime of the platform.
One potential process of adding a user dynamically (after the initial configuration) consists first of a sponsor for the new user posting a recommendation to the communication subsystem. The potential user then creates a public/private key set on another(presumably secure) computer. Users that support the addition then sign a copy of the user's public key and post it to the communication subsystem. When enough signed copies are obtained, the election subsystem retrieves the signed public key, associates it with a new UID, and allocates resources to the new user.
The allocation of new resources and the amount of pre-existing users needed to create a new users is an issue dealt with during initial configuration. Total system resource allocation can be either divided up between all users, with each user losing resources when a new user is added. Another solution is to have the new user's resources being drawn from a pool of resources allocated during initial configuration. Yet another solution is to have the sponsoring and/or affirming users donate portions of their resources for the new users. Algorithms for resource generation will be presented at a later date.
Whenever users are created, they are given a portion of user-allocatable system resources (processing cycles and storage). A portion of the storage must be allocated by the user to create his/her "safe," a subset of the primary filesystem that is encrypted by a key only possesed by the owning user. This "safe" is primarily designed tp hold private encryption keys of the user, but can be allocated with enough space to hold any other information as desired. The "safe" will not be accessible by any process not running under any other UID than the user, even if the process holds the proper key for decryption (except during the login process.)
4.3 Group Creation
Groups on a Ebola platform are created when a group of users decide to collude for a common purpose. These users start by setting up a group charter in the communication subsystem, and then setting aside system resources for use by the group. The charter is not unlike initial configuration for the platform, with a contract describing control of the resources, the addition and deletion of group members, and resource and data reallocation after the group is disbanded.
Group control is achieved through the communication subsystem. The communication subsystem will have a queue resmebling that used in batch operations on mainframe systems. The primary difference is that these commands will not be executed until they have been digitally signed by the appropriate key. The key used is created during the contract phase of group creation, described forthwith.
When a group is created, the contract will specify the control parameters of the use of group resources. A threshold key is created for group decisions, but this is not the key used to sign commands, but rather for group contract modifications, user addition/deletions, and group dissolution. For control, a key is generated that can either be delegated to a trusted user, or distributed in a threshold scheme. In the case of a trusted user, that user will be in complete control, but their control can be revoked by an appropriate quorum, as decided in the contract. Otherwise, commands will have to be validated using a standard threshold key decision. Provisions will be made in the future to describe a more hierarchical scheme for group control.