ࡱ; A  !"#$%&'()*+,-./0123456789:;<=>?@BCDRoot Entry  !"#$%&'()*+,-./0123456789;=>?@BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ ®`VTextStarWriter 5.03 SfxDocumentInfo  /1L( 01 uK Info 0 Info 1 Info 2 Info 3 /1}(h~<44Standard LIBIMBEDDED LIBIMBEDDED TASK,0,1,H-2,0,100,1,6107;2839;100;2280;0;13230;6165;0;0SW5HDR.001 !d Internet linkNumbering SymbolsBullet Symbols 394613061 402112171Outline0 #R-n#.R  n+.starbats n+.starbats6 n+.starbatsQ n+.starbatsl n+.starbats n+.starbats n+.starbats n+.starbats n+.starbats n+.starbats ZSWG, A<  #$%&'()*./0123456789:;<=>?@ABCDGHK  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFQRSTU0 )!'@yX'9@ starbats helveticaXX!'&@d d XX' @X'@.X'@RXX'(*@n. . XX@'18@ddd7dddXX!A'2*@dxddxdXXR'D@%X4yGP$' '(. . p. @ . . . . . P. . . !. $. `'. 0*. -. /. 2. p5. @8. ;. =. @. 6')2  Internet link Internet link@!''Numbering SymbolsNumbering SymbolsBullet SymbolsBullet Symbols''StandardStandard@'('33HeadingStandard Text body''2A'DR'  Text bodyStandard Text body2A' Heading 2Heading Text body' '' Hanging indent Text bodyHanging indent('1@'First line indent Text bodyFirst line indent1@'R!oGSBX sb Z Standard StarBASICSBX ARSBX AR SBX AR2c%bqqOh+'0 h t 14@ƸG@)@c@U  SW5HDR.001 ! Frameformat ZeichenformatTextformatvorlageStandard Heading Text body  Heading 2Hanging indentFirst line indent Internet linkNumbering SymbolsBullet SymbolsRoot 13Standard  Illustration Table TextDrawingY .Y .Y .Y .q= GeneralGeneraldNC#,###.00#,###.00SystemNC #,##0.00 CCC#,##0.00 CCCNC$#,##0.--;[RED]-$#,##0.-- $#,##0.---$#,##0.--REDNC$ MM/DD/YYYYMM/DD/YYYY def/SystemNC%MM/DD/YYMM/DD/YY def/SystemNC&NNNNMMMM DD, YYYYNNNNMMMM  DD, YYYYSystemNC' MMM D, YYMMM D, YY def/SystemNC. [HH]:MM:SS.00 [HH ]:MM:SS .00NC3MM/DD/YYYY HH:MM:SS MM/DD/YYYY HH :MM:SS  NCK MMM D, YYYYMMM D, YYYY def/SystemNCL MMMM D, YYYYMMMM  D, YYYY def/SystemNCM NN, MMM D, YYNN, MMM D, YY def/SystemNCNNN, MMMM D, YYYYNN, MMMM  D, YYYY def/SystemNCONNNNMMMM D, YYYYNNNNMMMM  D, YYYY def/SystemNCP D. MMM. YYYYD. MMM. YYYYDIN 5008 (EN 28601)NCQ D. MMMM YYYYD. MMMM  YYYYDIN 5008 (EN 28601)NCRMM-DDMM-DDDIN 5008 (EN 28601)NCSYY-MM-DDYY-MM-DDDIN 5008 (EN 28601)NCT YYYY-MM-DDYYYY-MM-DDDIN 5008 (EN 28601)NCUWWWWNCBXoePp 2$99 SAAP/=APdddAPddSAAP/=APdddAPddZSW5HDR.001 C(569a(Build:5169)(SV569)]DAddress bookaddress! Frameformat ZeichenformatTextformatvorlageStandard Heading Text body  Heading 2Hanging indentFirst line indent Internet linkNumbering SymbolsBullet SymbolsRoot 13Standard  Illustration Table TextDrawingdTW41 4 5*jK standard.dic soffice.dicXsun.dic@ IgnoreAllListY .Y .Y .Y .6NLTT)EbolaSA A @T&orSA A @T9The Abolition of RootSA A @T/ Version 0.1SA A @T3Justin TownsendSA A @Thxiitone@nolab.orgSA A @A38 mailto:xiitone@nolab.orgT$SA A @TSA @Tf IntroductionSGAPdddA A @A @ 3946130613TC 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.SGAP6ddd6A A @A @ 3946130613 !TK This paper is not intended to address certain important issues such as:SGAP6ddd6A A @A @ 3946130613 !TF physical ownership and security of the hardware platformS=AP6ddd6A @A @ 394613061A8F3 !TM various legal issues concerning legal issues such as key escrowS=AP6ddd6A @A @ 394613061A8M3 !Tz"the pseudo-random number generatorS=APdddA @A @ 3946130613$Tg An OverviewSGAPddd6A A @A @ 3946130613 TvThe 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.S=AP6ddd6A @A @ 394613061A8v3 !THThe 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. S=APQdddQA @A @ 394613061A8H3 "TEbola'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. SGAPldddlA A @A @ 3946130613#T#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.SNAP6ddd6A @A@. A @ 394613061A83 !Tf The KernelSGAPddd6A A @A @ 3946130613 TqThe kernel selected for this architecture is a microkernel. This selection was made using the following criteria:S=APQdddQA @A @ 394613061A823 "TJStability-A primary constraint of this architecture is its unwieldiness inS=APdddA @A @ 3946130613%Tinitial 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 kernelS=APdddA @A @ 3946130613%TZS=APdddA @A @ 3946130613%TqSecurity-By their very nature, microkernels consist of a smaller codebase, owing for more thorough code auditing.S=APdddA @A @ 3946130613%T SA @TdJ Flexibility-As noted above, the architecture must be able to add or SA @T`F remove various protocols and filesystems without endangering theSA @T3 core functionality.SA @TSA @T^D Scheduling-The kernel must be able to allocate processing timeSA @T in a very granular fashion. Microkernels have been used extensively in real-time systemsSA @TCS8APdddA @A@K. TjThe SubsystemsSGAPddd6A A @A @ 3946130613 T`The subsystems of Ebola constitute the majority of the functionality visible to users. They are:SGAP6ddd6A A @A @ 3946130613 !Tj CryptographyS=APdddA @A @ 402112171A8 3Tg CommunicationSGAPdddA A @A @ 4021121713TaLoggingSGAPdddA A @A @ 4021121713Tf Input/OutputSGAPdddA A @A @ 4021121713TqElection/AuthenticationSGAPdddA A @A @ 4021121713TZSGAPdddA A @A @ 4021121713 TZ3.1 CryptographyS1APdddA A @A8TThe most straightforward of the subsystems is the cryptography subsystem. It provides an API to the cryptographic subsystems so important to the Ebola platform.S1APdddA A @Tu9The primary cryptographic alogorithms made available are:S1APdddA A @Tg Assymetric key encryptionSBAPdddA A @A@. Tf Symmetric key encryptionSBAPdddA A @A@. Tf Threshold key encryptionSBAPdddA A @A@. TThe 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.S1APdddA A @Tj.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.S1APdddA A @T<S1APdddA A @T<S1APdddA A @TM3.2 CommunicationS1APdddA A @TCThe next subsystem to be considered is the communication subsystem.S'APdddA @A8CTZThe 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. S'APdddA @A8UTThe 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.S'APdddA @ThAnother function of the communication subsystem is the interface to voting, whether anonymous or public.S'APdddA @T 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.S1APdddA A @T<S1APddxdA A @TG 3.3 LoggingS1APdddA A @T<S1APdddA A @T 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.SBAPdddA A @A@. A8TMSBAPdddA A @A@. T]3.4 Input/OutputSBAPdddA A @A@. TAs 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.SBAPdddA A @A@. TMSBAPdddA A @A@. TMSBAPdddA A @A@. T'3.5 Election/Authentication Subsystem'sSBAPdddA A @A@. A8'TThe 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.SBAPdddA A @A@. TMSBAPdddA A @A@. TX 4 CreationSBAPdddA A @A@. T 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.SBAPdddA A @A@. TMSBAPdddA A @A@. Tl4.1 The Initial ConfigationS8APdddA @A@. A8TeThe 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). SBAPdddA A @A@. TMSBAPdddA A @A@. Tl4.2 User AdditionSBAPdddA A @A@. A8TI 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.SBAPdddA A @A@. T8One 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.SBAPdddA A @A@. TaThe 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.S8APdddA @A@. A8aTWhenever 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.)SBAPdddA A @A@. T_4.3 Group CreationSBAPdddA A @A@. T#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.SBAPdddA A @A@. TGroup 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.SBAPdddA A @A@. T;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.SBAPdddA A @A@. JGeneric PrinterSGENPRT PostScriptDVT$mVT$md,,lprdefault_queueSGENPRT7 Ue ^ !V88/8?/=U!k2P  °U!k2?B!B!B*!B?!BT!Bi!B~!B!B! B !E  B! E  B! E  B! E  B! ElT B!E B !<E <B &!<E6<BF+!EQoB^-!0E 0">/=U!k2p  U!k2?B!$E $HB$!E B9!E6BQ! E9 B]!$E9$B ! E9 B !E9B ! B! B! B! @B! AB! BB! DB! E !EB!E "FB&!E #HB>! E; $IBJ! E; %JBV! E; &KBb! E; 'LBn! E; (MBz! E  )NB !E*OB!!$E$+RB$! E ,SB%! E -TB&! E .UB'! E /VB(!E0XB+!TET1_к}/=U!k2P  šU!k2?B! E 2`B ! E 3aB!E 4bB-! E 5cB9!0E06gBi!TET7nB!E8pB!$E$9sB! E :tB!E ;uB!E <vB/!E=B'! E >B(!E?B*!TET@%U/=U!k2p  ¤U!k2?B!E@+B! E AB$!EBB9!ECBN!HEHDB !EEB !FB !$GB! HB!EIB!x Ex J B}! E KB!ELB!0E0MB#!`E`NB.,!<E<O%/=U!k2P  ³U!k2?B!$E$OB$!l El P B !EQB !HEHRB!HEHSB5!x Ex T lZRoot Entry ®`VCompObj<Ole persist elements" SfxDocumentInfo uStarBASIC BasicManager2 4SfxWindows=SwNumRulesSfxStyleSheetsStandard:jSummaryInformation( <(SwPageStyleSheets$ AoStarWriterDocument&[