text.tex

早期freebsd实现

not multiple \KDS/ IDs.

Having described this environment for communication,
the designs of a \KDS/ and \TMA/ which form the heart of the \TTI/
\trustedmail/ system are discussed.
The prototype system was developed on a \vax/-11/780 running 4.2\bsd/ \unix/.
The system is based on the \ansi/ draft\cite{FIKM}
for financial key management,
but diverges somewhat in operation
owing to the differences between the electronic mail (CBMS)
and electronic funds (EFT) environments.
Note however that the \ansi/ data encryption algorithm\cite{DEA,FIPS46} is
used in the current implementation.
A public-key cipher system was not considered as the basis for the prototype
since, to the authors' knowledge,
an open standard for a public-key system has yet to be adopted by the
commercial community.
In contrast,
the \ansi/ draft for financial key management appears to be receiving
wide support from the commercial community.

\tagtable{4}{Abbreviations used in this paper}{terms}
In the description that follows,
a large number of acronyms are employed to denote commonly used terms.
In order to aid the reader,
these are summarized in Table~\terms.

\section{The Key Distribution Service}
The prototype version of the \KDS/
was designed to provide key distribution services for
user agents under both the same or different administrations.
As a result,
the means by which a trusted mail agent connects to a key distribution server
is quite flexible.
For example,
the prototype system supports connections via
standard terminal lines,
dial-ups (e.g., over a toll-free 800 number),
\unix/ pipes,
and over TCP sockets\cite{IP,TCP}.
In the interests of simplicity,
for the remainder of this paper,
a TCP/IP model of communication is used.
Initially,
a server on a well-known service host in the ARPA Internet community
listens for connections on a well-known port.%
\nfootnote{The term {\it well known} in this context means that the 
location of the service is known {\it a priori} to the clients.}
As each connection is established,
it services one or more transactions over the lifetime of the session.
When all transactions for a session have been made,
the connection is closed.
If the necessary locking operations are performed by the server
to avoid the usual database problems,
then more than one connection may be in progress simultaneously.
Of course,
a time-out facility should also be employed to prevent a rogue agent from
monopolizing the key distribution server.

Once a session has been started,
the client (a.k.a.~\TMA/) initiates transactions with the server
(a.k.a.~\KDS/).
Each transaction consists of the exchange of two or three
{\it cryptographic service messages} (\CSM/s):
the client sends a request,
the server attempts to honor the request and sends a response,
and,
if the server responded positively,
the client then acknowledges the transaction.
By exchanging these cryptographic service messages,
the \KDS/ and the \TMA/ are able to communicate key relationships.
Obviously, the relationships themselves must be transmitted in encrypted
form.%
\nfootnote{Otherwise an adversary could simply impersonate a \TMA/ and ask
for the desired key relationships.
Similarly, this also prevents an adversary from successfully impersonating a
key distribution server.}
Hence, not only are key relationships between two \TMA/s communicated,
but key relationships between the \KDS/ and the \TMA/ are communicated as well.

This leads us to consider the key relationships that exist
between a \TMA/ and the \KDS/.
A client usually has three keys dedicated for use with the server.
The first is the {\it master key} (denoted MK),
which has an infinite cryptoperiod, and is rarely used.
This key is distributed manually.
The second is the {\it key-encrypting key} (denoted KK),
which has a shorter cryptoperiod.
Whenever a KK is transmitted to the \TMA/,
it is encrypted with the master key.
The third is the {\it authentication key} (denoted KA),
which is used to authenticate transactions that do not contain data keys
(a count field is also used to avoid play-back attacks).
Whenever a KA is transmitted to the \TMA/,
it is encrypted with the key-encrypting key.
When transactions contain keys,
an associated count field is included to indicate the number of
keys encrypted with the key-encrypting key used.
Although not used by the prototype implementation,
a production system would employ audit mechanisms to monitor usage histories.

Currently four types of requests are honored by the \KDS/:
two key relationship primitives, and two name service primitives.
The type is indicated by the {\it message class} (MCL) of the first
cryptographic service message sent in the transaction.
As each message class  is discussed,
the appropriate datastructures used by the \KDS/ are introduced.
Space considerations prevent a detailed description of the information
exchanged in each transaction.
Appendix~B of this paper presents a short example of an interaction between
the \KDS/ and a \TMA/.

The first two requests are used to create (or retrieve) key relationships,
and to destroy key relationships:

The {\it request service initialization} (RSI) message class
is used to establish a {\it key-encrypting key} (KK) relationship
between the \TMA/ and another \TMA/,
or between the \TMA/ and the \KDS/.
As implied by the name,
a key-encrypting key is used to cipher keys which are used to cipher data
exchanged between peers.
These other keys are called {\it data keys} (KDs).

The {\it disconnect service message} (DSM) message class
is used to discontinue a KK-relationship
between the \TMA/ and another \TMA/,
or between the \TMA/ and the \KDS/.
This prevents keys which are felt to have been compromised,
or are vulnerable to compromise,
from receiving further use in the system.
It should be noted that,
owing to mail messages (not \CSM/s) in transit,
a discontinued key relationship
may be needed to decipher the key used to encipher a mail message.
The prototype \KDS/ supports this capability.

In addition to maintaining an MK/KK/KA triple for each \TMA/,
the \KDS/ also remembers KK-relationships between \TMA/s.
The reason for this stems from a fundamental difference between the
electronic funds transfer and computer-based message system worlds.
The \KDS/ assumes that no two arbitrarily chosen \TMA/s can communicate in
real-time,
and as a result,
\TMA/s do not exchange cryptographic service messages.
(See Appendix~C for a more detailed discussion.)
This means that when a \TMA/ establishes a KK-relationship with another \TMA/,
the former \TMA/ may start using the KK before the latter \TMA/ knows of the
new KK-relationship.
In fact,
it is quite possible for a KK-relationship to be established,
used,
and then discontinued,
all unilaterally on the part of one \TMA/.
It is up to the \KDS/ to retain old cryptographic material
(possibly for an indefinite period of time),
and aid the latter \TMA/ in reconstructing KK-relationships as the need arises.
Naturally,
discontinued KKs are not used to encode any new information,
but rather to decode old information.
(Again, refer to Appendix~C for additional details.)

The other two requests are used to query the directory service aspects of the
key distribution server:

The {\it request user identification} (RUI) message class
is used to identify a subscriber to the \KDS/.
Both  the \KDS/ and \TMA/ are independent of any underlying mail transport
system (\MTS/).
As a result,
a subscriber to the \KDS/ is known by two unique attributes:
a ``real-world'' name,
and a \KDS/ identifier (ID).
The user of a mail system,
or the \UA/,
is responsible for mapping an \MTS/-specific address
(e.g., {\tx [e-mail]})
to the person associated with that maildrop
(e.g., \eg{Marshall\ T.\ Rose}).
When conversing with the \KDS/,
the \TMA/ uses the \KDS/ ID of another user to reference that person's \TMA/.
Since it is inconvenient to remember the IDs (as opposed to people's names),
the \KDS/ provides the RUI message class to permit a \TMA/ to query the
mapping between names and IDs.
If the \KDS/ cannot return an exact match,
it may respond with a list of possible matches
(if the identifying information given was ambiguous),
or it may respond with a response that there is no matching user.

Finally,
the {\it request identified user} (RIU) message class
performs the inverse operation:
given a \KDS/ ID, a ``real-world'' name is returned.
This request is useful for disambiguating unsuccessful RUI requests
and in boot-strapping a \TMA/.

The \KDS/ maintains two directories:
a private directory and a public directory.
The private directory contains all information on all clients to the \KDS/.
The public directory is a subset of this,
and is used by the \KDS/ when processing RUI and RIU requests.%
\nfootnote{In the prototype implementation,
the two directories are, for the moment, identical.}
As a result,
certain clients of the \KDS/ may have unlisted IDs and names.

\section{The Trusted Mail Agent}
The prototype version of the \TMA/
was designed to interface directly to the user agent in order to maximize
transparency to the user.
In present form,
the \TMA/ is available as a load-time library under 4.2\bsd/ \unix/,
although efforts are currently underway to transport the \TMA/ to a PC-based
environment.

The software modules which compose the \TMA/ contain a rich set of interfaces
to the \KDS/.
In addition,
the \TMA/ manages a local database,
so responses from the \KDS/ may be cached and used at a later time.
In all cases,
the \KDS/ is consulted only if the information is not present
in the \TMA/ database,
or if the information in question has expired (e.g., KK-relationships).
This caching activity minimizes connections to the \KDS/.
Although connections are relatively cheap in the ARPA Internet,
substantial savings are achieved for PCs which contact the \KDS/ over a
public phone network (dial-up) connection.

The \TMA/ performs mappings between pairs of the following objects:
user names, \KDS/ IDs, and \MTS/ addresses.
The \TMA/ considers all trusted mail agents, including itself,
as a user name, \KDS/ ID, and one or more \MTS/ addresses.
Although the \TMA/ does not interpret addresses itself,
in order to simplify mail handling,
the \TMA/ remembers the relationship between these objects so the user enters
this information only once.

Initially,
when a \TMA/ is booted,
the user supplies it with the master key and the user's \KDS/ ID.
Both of these quantities are assigned by the personnel at the key
distribution center,
and subsequently transmitted to the user via an alternate, bonded service.%
\nfootnote{In this fashion,
the problems of boot-strapping over an unsecure medium are avoided.}
The \TMA/ connects with the \KDS/ and verifies its identity.
From this point on,
the \TMA/ manages its KK-relationships between the \KDS/ and other \TMA/s
without user intervention.

The current implementation of the \TMA/ assumes a ``general memo framework''
in the context of the Standards for ARPA Internet Text Messages\cite{DCroc82}:
\smallskip
{\advance\leftskip by\parindent
\item{1.} A message consists of two parts:
the {\it headers} and the {\it body}.
A blank line separates the headers from the body.

\item{2.} Each (virtual) line in the headers consists of a keyword/value
pair, in which the keyword is separated from the value by a colon (:).
The headers are rigorously structured in the sense that they contain
addressing and other information useful to a user agent.

\item{3.} The body is freely formatted and must not be meaningful to a
user agent.
However, as will be seen momentarily,
the body of encrypted messages must have an initial fixed format which the
\TMA/ enforces.
\smallskip}