\chapter{Introduction}
\hyphenation{au-then-ti-ca-tion}

\begin{singlespace}
\begin{quote}
\begin{description}
\item[{\Large Nox}] \large --- the Goddess of the Night, who knows all
secrets and keeps most of them.
\end{description}
\end{quote}
\end{singlespace}

This thesis describes the design of Nox.  Nox is a network-based server
whose function is to encrypt and decrypt information using keys which
are known only by it.  Since only the Nox server knows the keys which it
uses to encrypt data, only the Nox server can decrypt the data on behalf
of an authorized user.  This allows the Nox server to enforce a variety
of access control policies which can be configured by an administrator
to fit the needs of a particular application.  

\section{Motivation}

An example of a networked application which could benefit from the Nox
service is Discuss\cite{discuss}.  Discuss is an electronic conferencing
system, modeled after the Multics Forum Interactive Meeting
System\cite{forum} subsystem.  Many 
Discuss meetings are private, which means that their access
control lists only allow access to small set of participants.  The
nature of the discussions in some of these private meetings is such
that it is extremely important that access to these discussions be
restricted to the participants of the private meeting.  While the
Discuss server will honor the access control list for that meeting and
not allow unauthorized users to obtain transactions for that meeting,
the meeting is still vulnerable to people who have privileged or
physical access to the Discuss server.

One solution would be to physically secure the Discuss server and
restrict physical and logical access to it.  Unfortunately, there are a
large number of Discuss servers located across the campus, and it would
be extremely difficult to secure all of them.  While it might be
possible to place all of the sensitive Discuss meetings on a secured
machine, maintainence of this machine would be difficult, since (for
security's sake) only a few administrators could be allowed to have
access to the machine.  In the current model, anyone with a system and
disk space can set up a Discuss server and create his or her own
meetings.  It would be awkward if the only way to have a really secure
meeting would be to use the disk space of a centrally administered
machine.  Furthermore, standard problems which plague any secure data
storage system would arise, such as ``how will the server be backed
up?'' and ``where will the backup tapes be stored?'' 

The above problems can be solved by encrypting the data before sending
it to the Discuss server.  Since the data which is stored by the Discuss
server would be encrypted, merely having physical access would not be
enough to compromise the contents of the meeting.  In this scheme, each
authorized participant would know the encryption key for that meeting,
and they would have to supply the encryption key to the Discuss client
before he or she could read or post transactions to the meeting.
However, either each user would have to memorize the key (which would be
bad since a user might be tempted to write it down) or the Discuss
client would have to retrieve the key from a file in a user's directory 
(which would be insecure since an intruder might be able to breach the
security of the file).  An additional problem with this scheme is that 
the only way to revoke a user's access to the Discuss meeting would be
to to re-encrypt all the transactions in the Discuss meeting in a new
encryption key, and to distribute the new key to all of the participants
of the meeting except for the user whose access is to be revoked.  This
is both difficult and clumsy.  Finally, there is nothing to prevent a
user who knows the encryption key from sharing it with an unauthorized
user.

The above problems could be solved by introducing a Nox server which
would act as an encryption server by storing the keys used for
encryption as part of its state and encrypting and decrypting data on
behalf of its clients.  Communications between the Nox client and server
take place over the network, which can be easily spoofed; thus, the Nox
client would have to first authenticate itself using an authentication
protocol such as Kerberos\cite{Kerberos}.  The principal which the
client used to authenticate itself to the server would determine whether
or not the client would be entitled to encrypt or decrypt transactions
from a particular Discuss meeting.

Of course, the Nox server would have to be kept physically secure;
otherwise, it would be vulnerable to the same sort of tampering which we
were trying to prevent from happening to the Discuss servers.  However,
since the Nox server doesn't need to store any bulk data, one or two
such servers could easily provide encryption service for a large network
community.  Thus, only one or two machines would need to be protected in
this fashion.  The users of the private Discuss meeting would need to
trust the administrators of the Nox server.  At least in an environment
which uses Kerberos, users must trust the administrators of the Kerberos
service anyway; thus, Nox may not require much (if any) additional trust
assumptions.

\section{Related Work}

Many specialized schemes have attempted to take advantage of
cryptography to provide security.  Unfortunately, most of these
schemes\cite{cryptuse1,cryptuse2} base their security on the
specific mathematical properties of the cryptosystem.  For this reasons,
they cannot be generalized or adapted to use another cryptographic
system.  

David Gifford did develop such a generalized system which used
cryptographic systems in his paper, ``Cryptographic Sealing for
Information Secrecy and Au\-then\-ti\-ca\-tion.''\cite{cryptlogic}.  In this
paper, Gifford showed how primitive key-sealing techniques which mimicked
logical-AND and logical-OR properties could be built up to provide
generalized semantics.  Unlike Nox, the encryption keys were held by
each user (in a ``key-ring'') instead of by a centralized server.  In
addition, Gifford's scheme required data (especially keys) to be
encrypted multiple times to provide its desired semantics; this is not
required by Nox.

The concept of ``sealing'' data by encrypting the data in a key was
borrowed from the design of the Kerberos authentication
system\cite{Kerberos}.  Unlike Kerberos, however, the encrypting key in
Nox is known {\em only} by Nox, instead of being a shared secret known
by the server and the authenticating user.  Certificate systems (such
as those used by X.509\cite{x509}) also
seal data by encryption, typically by using a public key encryption
system where a private key is held by an authentication server (AS), and
the public key is published.  Thus, only the AS can create a
certificate, but anybody can read it.  Nox is different from certificate
systems in that only the Nox server can encrypt or decrypt its satchels,
and that Nox does not require the use of a public-key encryption system.

Access Control Lists (ACL) are by now a well-known authorization
technique.  Many past- and present-day systems use ACL as part of their
access control systems, including Honeywell's Multics\cite{multics},
SIPB's Discuss subsystem\cite{discuss}, and CMU's Andrew File System.
Nox uses a generalization of access control lists which allow threshold 
semantics\cite{threshold}, where several users need to give their
approval before the Nox server will act on a particular request.

\section{Organization of this Thesis}

Chapter~\ref{chap:concepts} describes the basic design and functional
specification of Nox.  Chapter~\ref{chap:security} explores the security
assumptions which were made during the design of Nox and the security
semantics which are offered by Nox.  Chapter~\ref{chap:applications}
describes a few sample applications which use the Nox service.
Chapter~\ref{chap:extensions} describe extensions to the basic Nox scheme
and future directions of the Nox design.

