\chapter{Applications}
\label{chap:applications}

Since data which is sealed into satchels can be read only by Nox, Nox
can be used to provide all of the required security and authorization
functions for an application.  This allows the security aspects of the
application to be decoupled from the application itself.  In a
distributed environment, this decoupling is extremely useful.

\section{Filesystems}

Filesystems are the most basic class of applications which can be based
on Nox.  Historically, many applications have used the security built
into the filesystem to provide the security policy for the application
--- this was especially true on single-host, non-distributed systems.
However, was discussed in section~\ref{refmon}, the filesystem need not
be included in the Trusted Computing Base if uses the Nox server to
encrypt all of its data in satchels before they are stored on disk.

\section{Discuss}

Discuss's use of Nox is straightforward, partially because it was the
client which inspired the initial design of Nox, and partially because
as a electronic conferencing system, its design is very close to that of
a filesystem --- data is stored when a user enters a transaction (which
is analogous to a file) into a meeting (which is analogous to a
directory), and when a user reads a transaction, the system retrieves
the data stored by referencing it by transaction number.  

The only addition to the filesystem model made by Discuss is that the
transactions numbers are ordered by date of entry into the meeting,
whereas in a filesystem they generally are not.  In addition,
transactions are immutable once entered into the meeting.  The
properties of the transaction numbers would allow the transaction number
to be modeled by the sequence number of the satchel used to store the
transaction.  This might not be advisable, since the sequence numbering
feature requires that the Nox server update part of the compartment's
state each time a satchel is created.  This might cause an unnecessary
load on the Nox server, especially if Nox is extended so that the Nox
servers are replicated.  (See section~\ref{multiserver}.)  The
sequencing of Discuss transactions is generally not very important in
any case, since users with delete access are allowed to delete
transactions0, which would introduce gaps into the transaction sequencing.
In other words, Discuss does not require that the transaction number be
strongly sequenced; the transaction number is actually only used as a
handle to retrieve a transaction from storage.  Thus, Nox should need
not maintain the transaction number using its sequencing feature since
the Discuss server could maintain it more efficiently and with no loss
in functionality or security.

Modifications to the Discuss subsystem to allow it to use the Nox system
would be relatively simple, and would only require modifications to the
Discuss client.  When a user enters a transaction into a private
meeting, instead of sending it immediately to the Discuss server, the
Discuss client first authenticates the user to the Nox server and asks
it to encrypt the transaction into a satchel.  The client then sends the
satchel to the Discuss server, which stores it in the normal fashion ---
the server doesn't care about the contents of the transaction, so it
doesn't matter that the server is storing a satchel instead of {\sc
ASCII} text.  When the Discuss client retrieves a transaction from a
private meeting, it receives a satchel from the Discuss server which it
can send to the Nox server to obtain the {\sc ASCII} message.  Each
private Discuss meeting would have its own encryption compartment, which
would control who would be able to encrypt and decrypt messages for that
meeting.

\section{Audit Logs}
\label{ssyslog}

In secure systems it is often required that audit trails be kept of security
related events which are protected from destruction, modification, or
unauthorized access.  While Nox cannot protect against the destruction
of the security log, since it does not perform any storage functions, it
is possible to protect the audit trails again modification and
unauthorized access.  This is done by sending each logged event to the
Nox server and sealing it in a satchel.  To detect the deletion of
all or part of the log, strong sequencing is enabled for that encryption
compartment.  This causes each satchel to be monotonically numbered, and
for the Nox server to keep track of what the highest numbered satchel
is.  Thus, if any satchels which comprise the log are removed, this can
be detected as a gap in the numbering of the satchels.

\section{Secret Bank Accounts}

A secret bank account is an example of an application which takes
advantage of many of the features of Nox.  In this scenario, we posit a
bank who would like to maintain the balances of a certain class of
accounts accurately; however, the bank officials would like these
accounts to be protected so that even if the bank were subpoenaed, it
would be impossible for the bank to produce the balances of the accounts
or who owned the accounts.\footnote{These requirements are somewhat
simplified, since the bank would also need to be able to audit these
secret accounts.  We will ignore this requirement since it can only be
partially be satisfied without compromising the other restrictions, and
because the partial solution would unnecessarily complicate the
example.} 
This can be done by encoding the bank balance in a satchel.
The compartment for the satchel is set up so that the owner of the
compartment can decrypt the satchels, but only the bank can encrypt
satchels.  In addition, the compartment has sequencing enabled.

When the user wants to transfer money either into or out of his
account, he asks Nox to create a proxy which will allow the bank to
decrypt the satchel containing his account balance, and sends both the
proxy and the satchel to the bank.  The bank sends the proxy and the
satchel to Nox, and obtains the decrypted bank balance.  The fact that
the bank can obtain the decrypted balance is proof that the user to whom 
the bank is connected is the legitimate owner of the account, since
only the owner could have obtained a proxy from Nox authorizing the
decryption of the satchel.

At the end of the transaction, the bank updates the balance and uses
Nox to reseal the balance in a new satchel which is sent back to the user.
To detect an attempt to send an old satchel which contains
out-of-date account balance, when the bank decrypts a satchel, it
compares the sequence id of the satchel with the most recent satchel id
which was encrypted by Nox.  Since Nox maintains the sequence id, it
cannot be spoofed by the user.

Since the bank destroys the decrypted balance and almost all other
information related to the transaction, the balance of the account is
stored only while a transaction is being processed by the bank.  So if
the bank is asked to provide the balance for a customer whose account
is protected by this system, the bank officials can honestly say that it
is impossible for them to obtain the information.  The most the
government could do would be to subpoena the Nox and Kerberos servers
--- but if the Kerberos principal used to authenticate the user to the
Nox server is not used for any other purposes, the Kerberos user name
can not be used to track down the identity of the owner of a bank
account.

% 
% Local variables:
% version-control: t
% make-backup-files: t
% mode: TeX
% End:

