\chapter{Security}
\label{chap:security}

\section{Security Assumptions of Nox}

The security of Nox is based on several assumptions:

\begin{itemize}
\item The authentication system used by Nox can reliably set up a
trusted and secure connection between the Nox client and server such
that each can be assured of the identity of the other.

\item The cryptographic system used by Nox is resistant to 
known-plaintext and chosen-plaintext attacks.

\item The Nox server is physically secure, to prevent intruders from
stealing the secrets stored in the server.
\end{itemize}


\subsection{The Authentication System}

Nox requires an authentication system in order to identify the user
submitting a request so that it may check the user's authorization.  If
an intruder can compromise the authentication system, he can impersonate
an authorized user and convince the Nox system to perform whatever
action the intruder desires.

The initial implementation of Nox will use Kerberos\cite{Kerberos}, a
private key authentication system which was developed at MIT and which
is in use at Project Athena.  The security of Kerberos has been
investigated by Michael Burrows\cite{Burrows}, and the design of the
basic protocol of Kerberos appears to be secure, as long as the time
source for both the Nox and Kerberos servers are secure. 

Nox also assumes that during the authentication process, the Nox server
and client will be able to securely exchange a session key with which to
encrypt data to be sent between the server and the client.  Encrypting
the data in the session key is necessary to ensure that Nox is always
talking to the authenticated client, and that some interloper has not
commandeered the connection.  It is also necessary to prevent
eavesdroppers on the network from obtaining the decrypted data as it
flows between the client and the Nox server.

\subsection{The Cryptographic System}

The cryptographic systems which are used by Nox must be resistant to chosen-
and known- plaintext attacks, since users with encrypt access to a
compartment will be able to encrypt arbitrary amounts of data which they
can control, and users with decrypt access will be able (given satchels
from that compartment) to obtain the plaintext from the satchel.  

Since the data which is being sent to the Nox server is being
encrypted in the authentication system's session key, and is being sent
back to the client encrypted in the compartment key, it might appear
that an intruder might be able to employ an ``isomorph'' attack.  In an
``isomorph'' attack, an intruder might be able to obtain some
information about the encrypted data if the data encrypted in two
different keys is available to the intruder.  Fortunately, there is
enough additional material in the format of the satchel that the data
which is encrypted while it is being sent to the Nox server and the
data inside the satchel which is sent to the client should be
sufficiently different to prevent an eavesdropper on the network from
exploiting the semi-isomorphic property of the data stream going in and
out of the server.

The initial implementation of Nox will only support the Data Encryption
Standard (DES)\cite{DES}.  However, Nox is designed so that it can use
several different encryption systems, so that when more secure
encryption systems become available, the Nox server can be easily
modified to take advantage of additional encryption systems.

\subsection{The Nox server}

Since the integrity of the satchels can only guaranteed if only the Nox
server knows the keys which were used to seal the satchels, the Nox
server must be physically secure to prevent the unauthorized release of
the those keys.  

Another consideration is that most authentication systems require Nox to
keep some sort of initial shared secret between the authenticating
server and the Nox server in private-key systems, or some sort of
private key used to decrypt messages in public-key systems.  In the case
of Kerberos  running on Unix systems, for example, each server must keep
a private service key, which is stored in {\tt /etc/srvtab}.  If the
service keys are compromised, the intruder can use the service key to
spoof the server by forging Kerberos authenticators that apparently look
like they came from any user the intruder desires.   Thus, most
authentication systems also require that the Nox server be kept
physically secure as part of their assumptions.

\section{Security Semantics Offered by Nox}

Nox's primary advantage over other cryptographic systems is that the
semantics it offers are extremely flexible.  Unlike cryptographic
systems which do not require a central server, Nox's encryption
semantics do not depend on the mathematics of the underlying
cryptographic algorithms.  For example, RSA\cite{RSA} is an extremely
popular system, since it the semantics it offers are very attractive: 
data can be encrypted by anybody such that it can be decrypted by only
one person, and messages can be signed so that the sender cannot later
deny that he sent the message.  However, RSA's semantics are an integral
part of the mathematics of its algorithms.  This is its strong point,
since this way it does not require a centralized server.  However, the
disadvantage of enforcing the semantics in the mathematics of the
algorithm is that it is difficult to modify or expand the semantics
which are offered by RSA.

As we will see later on, a Nox compartment can be set up to have the same
semantics as a public key cryptographic system.  However, unlike a
public-key system, the semantics of who may or may not create or read
satchels are completely implemented in software, which allows Nox to
offer a much more flexible and powerful semantics --- the encryption
machinery in Nox is used only to assure that only the Nox server can
encrypt or decrypt the data inside a satchel.

\label{refmon}
This property allows the Nox server to function as a {\em reference
monitor}.  A reference monitor is the part of a system (both hardware
and software) which ``validates each reference to data or programs by
any user (program) against a list of authorized types of reference for
that user.''\cite{TCSEC} The concept of a reference monitor was first
described in a report which was part of the Computer Security Technology
Planning Study\cite{Anderson}.  This report listed three design
requirements of reference monitors:

\begin{enumerate}
\item The reference monitor must be tamper proof.

\item The reference monitor must always be be invoked.

\item The reference validation mechanism must be small enough so that it 
can be comprehensively analyzed and tested.
\end{enumerate}

As we shall see, Nox satisfies these design requirements.  The first
requirement is met as long as the assumption that the Nox server itself
be stored in a physically secure location and that logical access to the
machine is restricted to the administrators of the Nox service.  This is
not an unreasonable solution, since any machine which is not physically
secure can not remain logically secure for long.\footnote{As authors of
copy-protection schemes have learned to their regret.} 

The second requirement, that the reference monitor cannot be
bypassed, is also satisfied.  This is because only Nox knows the
encryption key for a satchel.  Thus, a satchel can only be opened and
its contents revealed if Nox allows it.  Similarly, only Nox can create
satchels, since again only it knows the encryption key.  However, it
should be noted that Nox has no control over the decrypted data once it
is passed on to the client; there is nothing that can stop a malicious
client from broadcasting sensitive information returned to it form Nox.
In other words, Nox can only prevent an unauthorized client from
obtaining sensitive information; it cannot prevent authorized clients
from downgrading (and thus compromising) sensitive information.  Thus,
Nox only offers discretionary access control and does {\em not} offer
mandatory access control.

The final requirement of a reference monitor is somewhat subjective in
its wording; however, an implementation of Nox can be made to be
extremely small and simple.  Unfortunately, many system's ``reference
monitors'' fail the third design requirement because of their
complexity.  In these cases, TCSEC calls the over-large ``reference
monitor'' the Trusted Computing Base (TCB).  For example, in most
traditional systems, the filesystem {\em must} be included in the
Trusted Computing Base, since if an intruder could access the disk drive
or the disk device handler directly, he could violate the security
checks performed by the TCB.  Similarly, the backup system (including
how and where the backup tapes are stored!)  must also be considered
part of the TCB, since an intruder could steal a backup tape and read it
on another system, thus compromising the security of the data stored on
the backup tape.  Thus, we can see that the filesystem makes the TCB to
be significantly more complicated, and thus much more difficult to prove
secure.

However, Nox can be used as the reference monitor of these systems by
using Nox to enforce the security of any part of the system which
requires security protection.  For example, when data needs to be
written to the filesystem, the filesystem passes the data to Nox, which
returns the data in a satchel whose security and access control is
guaranteed by Nox.  Since all of the security is being handled by Nox,
the filesystem doesn't need to be in the TCB.

Similarly, Nox can function as reference monitor for many different
applications which would normally have to be in the Trusted Computing Base,
since they have to be trusted to be able to handle sensitive data.
Thus, these applications need no longer depend on having all or part of
their functionality be implemented in the Trusted Computing Base, as
long as they only require discretionary access control and do not
require mandatory access controls.  (See section~\ref{MLS} for a
discussion of how support for multi-level security could be added to Nox.)

