There's no shortage of pundits bemoaning the poor security in current operation systems. At the start of the 1970s, Multics had security features that modern systems still don't match (Paul A. Karger, Roger R. Schell, Thirty Years Later: Lessons from the Multics Security Evaluation (IBM, 2002)). The computer systems the commercial world is built upon rarely exceed class "C" in the criteria used to evaluate military computer systems (the "Orange Book"), due to inherent limitations in the security architecture of commodity operating systems.

This saddens me. So for ARGON I've designed what I hope is a good security model, that should allow installations to achieve classes "B" or "A" with ease.

ARGON doesn't have an "element named" component for security, as it's not the responsibility of an isolated software component; different aspects of security are handled throughout the kernel components, and this page documents how it all fits together. However, there will clearly be a need for a core library of encryption algorithms and tools like operations on classifications and clearances (eg, finding the sum of two, seeing if one is a superset of another, finding out if a given clearance is sufficient for a given classification, and so on) that are needed by the various components, which will go into the ARGON kernel glue code.

Security within the node

User code is run by LITHIUM, by asking an appropriate handler for the type of code. The only handler I'm specifying for now is CHROME, a high-level programming language that compiles to the HYDROGEN code generation interface. HYDROGEN code is able to "do anything"; HYDROGEN provides a single address space, and no way of preventing access to low-level device interfaces. As such, CHROME has to ensure sandbox safety of the compiled code it generates, like a Java virtual machine.

Within CHROME, access to privileged functions is provided in controlled ways by wrapping up priveleged capabilities into objects that are injected from outside the sandbox, and can be used by user code within it. There is no way for user code to generate objects with capabilities the code does not already have access to, nor to introspect into objects it is given to interfere with their operation.

Other language handlers might take different approaches, including using hardware memory management to run untrusted code with the ability to manipulate pointers directly.

HELIUM provides resource usage limits for user code, too; handlers are given CPU time and memory limits, and a priority for scheduling access to the CPU and I/O resources, in order to mitigate denial of service attacks through resource starvation.

Security within the cluster

As recommended by the Orange Book, we provide both mandatory and discretionary access control.

Information is assigned a classification, from a list of classifications defined cluster-wide by a security administrator (stored in the cluster entity). One site may use "Private" and "Public", another might use a complex classification system. The representation of classifications of information, and the clearances of devices that are entitled to process that information, allows for both a linear "secrecy level" from an ordered list and a set of "codewords" (see the Wikipedia page on Compartmentalization in information security).

Places where information may be stored, processed, or carried from place to place are awarded "clearances", which reflect the maximum secrecy level of information they are trusted to carry and a list of what codewords they are trusted with.

A given clearance is allowed access to data with a given classification if the secrecy level in the trust is greater than or equal to that of the classification, and that either the classification has no codewords or that at least one codeword is shared between the classification and the clearance.

Classifications are awarded to volumes, and apply to all the entities within the volume; those entities may only be stored on, or their handlers run on, nodes whose clearance exceeds the classification of the volume.

The individual entry points in MERCURY protocols exposed by entities are assigned classifications, too. Each entity is assigned a clearance (which cannot be more than the classification of the volume holding it), and in-cluster MERCURY will not allow an entity to access endpoints classified above its clearance. MERCURY entry points also have a discretionary access control list of entities that may access it, which applies to in-cluster communications as well, but is explained in more detail in the next section.

Trust and classifications cover information in transit, too. The cluster has a set of available encryption algorithms, each with a clearance assigned; it is assumed that classified information can be carried over untrusted links if it is encrypted with an algorithm whose clearance rates it for that classification. WOLFRAM also stores a list of "communication groups" of nodes that are connected by particularly featureful network links. The security configuration of the cluster can assign clearances to these groups, allowing encryption to be foregone for classified information that is communicated purely within those groups. This is intended to allow dropping the encryption overhead between machines located entirely within a secure facility, where network traffic between them cannot leave that facility.

The classification level of a message is specified by its sender. WOLFRAM messages replicating TUNGSTEN data will classify the messages based on the classification of the volume the entity is from. MERCURY request messages (be the in-cluster or intra-cluster; the interpretation of classifications between clusters is explained below) are classified with at least the classification requested by the target entity for the endpoing in the CARBON metadata declaring it (but the sender may choose to go higher if it wishes; the MERCURY server stack will reject an under-classified message, however), and replies are classified however the sender chooses. MERCURY traffic within a connection has at least the classification applied to the connection as a whole, but individual requests and responses may be given a higher classification by the sender. Note that the requested transit classification of a MERCURY endpoint (which is published in CARBON) is distinct from the access-control classification it is assigned (which is private); a shop service would have a "public" access-control classification so that anyone can use it, but a transit classification appropriate for personal information such as orders, delivery addresses, and payment information.

Within the node, each mass storage device attached to the node may have a clearance. Only volumes whose classification is accepted by that clearance may be stored on them. Encryption may be configured on a mass storage device, but it does not raise the clearance of that device, as the clearance of a device also covers the ability of an attacker to deny service or erase data, rather than merely snooping!

Security between clusters

Security between clusters is more interesting. Any cluster may contact any other over the public Internet via MERCURY, packet filters permitting.

Every cluster has a public keypair, the private key of which is known to every node in the cluster, and the public key of which is part of the public ID of every entity within the cluster.

Discretionary access control (and other trust decisions) between clusters are based upon the entities originating the messages. However, we only actually authenticate the originating cluster, and when ensuring that our messages cannot be snooped, we merely ensure that they reach the correct cluster. This is because we cannot trust an entity any more than we can trust the cluster that hosts it. If we trust an entity with some information, we cannot really tell if the cluster hosting that entity is really sending the information to that entity or some other, so there is no point in authenticating at a finer granularity than the cluster.

Every entity maintains its own mapping of classifications to inter-cluster communications protection algorithms. The function of such an algorithm is, given the source cluster's public key pair and just the target cluster's public key, to convey sequences of bytes (raw MERCURY messages) over a lower-level IRIDIUM transport, while ensuring that only the target cluster can recover the message, that no men-in-the-middle can recover or alter the message without detection, and that the target cluster can check that the source cluster sent the message.

Of course, how well an algorithm does this job varies wildly. There's a null algorithm, that just sends the bytes as-is with no encryption or signing whatsoever. This is pretty naff from a security perspective, but it's fast, so might be used for 'public' classified communications.

On the other hand, a better algorithm might open an IRIDIUM virtual circuit and negotiate a session key, signing requests so that each end can check the identify of the other, then proceed to exchange messages using a modern block cipher with the session key, and frequent renegotation of said session key.

MERCURY, assuming that algorithms attempt to be fast in the general case by doing session key negotation at VC setup and shutdown, will attempt to cache already-negotiated algorithm channels between nodes and reuse them for more than one communication operation.

Now, if a node is attempting to send a message to a node in another cluster, it will consider the classification of the message, and will attempt to use the algorithm that cluster is configured to use for that classification. Classification hierarchies are unique to each cluster, but when the message (or initial request to set up shared session keys etc) is received by the destination, it applies its mapping from classifications to algorithms to decide which classification this algorithm represents (from its perspective), to tag the incoming message with.

If the destination cluster does not recognise the algorithm, it replies with a rejection, specifying the list of algorithms it would consider sufficiently trusted for the transit classification of the target endpoint. The sending node then finds an algorithm it will trust with the message (eg, an algorithm associated with the message's classification or higher) that is in the list, and uses that. If there is none, then it must sadly fail!

MERCURY requests from other clusters are bound by the access classifications of endpoints, too. A request from some random entity is given a default access clearance, whichever one the cluster considers "public", meaning that any endpoints with classifications above that will generally only be accessible to entities within the same cluster. However, the security configuration of the cluster allows the security administrator to assign trust relationships with other clusters. A cluster may be given a clearance, which acts as a maximum access clearance assigned to any request from that cluster. It is also given a list of specific access clearances of specific entities within that cluster, which allows the security administrator to grant access to classified endpoints within the cluster to those specific entities. It is also possible to configure a default clearance for entities within the remote cluster that are not specifically listed, rather than the default "public" level.


It is possible for an entity to act on behalf of another entity for a while. For example, when somebody logs onto a desktop computer, they (in effect) tell that computer what their user entity is, then enter a password so that the computer can demonstrate to their user entity that it's really them. The user entity then sends the computer your favourite user-interface software and settings, but as you browse CARBON from the computer, the entities you interact with must see the actions as coming from your entity, not from the computer you're on, or else they will be unable to make useful access-control decisions.

This could be done by proxying all your activities through your user entity, but that would not be very efficient. Instead, the user interface software keeps a connection to your user entity open for the duration of your session, and every minute, your user entity sends it a certificate (signed by the cluster as coming from that entity), stating that the entity of the user interface is allowed to act as it for the next two minutes.

This certificate is then sent along with every MERCURY message issued on your behalf by the user interface (or early on in every virtual circuit, and then left out thereafter). The messages are still signed by the algorithm chosen for communications between the user interface node and the target node, but with the certificate wrapped within. The recipient, upon seeing the certificate, checks that the entity authorised to act on behalf within the certificate is the same entity that's originating the request, checks the certificate is not out of date, and then subsequently considers the request to have come from the entity that issued the certificate for access control purposes (with the identify of the intermediate entity still kept for auditing purposes).



Every piece of data in an ARGON system is given a "classification" which reflects how hard the system should try to protect it and who should be able to see it. It consists of two parts, a secrecy level and a set of codewords. The data may only be accessed by users with sufficient clearance; the secrecy level in the clearance must be greater than or requal to that of the data's classification, and the classification must either have no codewords (indicating that codeword compartmentalisation is not in use), or the clearance and the classification must have at least one codeword in common. In other words, adding more codewords to a classification makes it more widely available.


Every place where data might be stored, or every agent that might process data, needs sufficient clearance to have access to that data. A clearance has the same structure as a classification - a secrecy level and a set of codewords. The secrecy level reflects the maximum secrecy level of classification this user may access, and the codewords indicates the set of codeword-compartmentalised classifications they can access. While a classification with no codewords indicates that it is accessible by all clearances with sufficient secrecy level, a clearance with no codewords indicates that it is only able to access classifications without codewords.

Secrecy level

A linear measure of how secret something is. The cluster's security administrator gets to choose the list of secrecy levels. There is always a bottom one, called "public", indicating that no special effort need be made to keep it secret. A user wishing to access some information needs a clearance whose secrecy level is greater than or equal to the secrecy level in the classification.


A security classification used to compartmentalise information, so that only users who need to be able to access it can do so, in addition to a secrecy level. In order to access something classified with a codeword, the user must have a clearance that includes that codeword. The absence of codewords in a classification means that all clearances with sufficient secrecy level can access it.

Access classification

Of a MERCURY operation on an entity, the clearance of user required to access the operation.

Transit classification

Of a message in transit through the system, the clearance of link or intermediate node required to see the message in unencrypted form.

Entity classification/clearance

The clearance an entity posesses, indicating what information it can be trusted with; and therefore, the classification of that entity's state. Whether it's referred to as a classification or a clearance depends on the context. A message with a classification above this clearance may not be received by an entity (it'll be rejected).