text.tex

早期freebsd实现

After presenting some of the basic strengths of the system
and a few unresolved questions,
the discussion centers on the simplifying assumptions made by the system,
and how these can be defended in a non-military environment.

\subsection{Strengths}
It can be argued that the prototype system
(and the augmented model in which it finds its basis)
present many strengths.

Perhaps the most important is the high-level of independence from the \MTS/
enjoyed by the system.
As a result,
since the \TMA/ does not interact directly with the \MTS/,
it can be made to be completely free from any \MTS/-specific attributes,
such as naming, addressing, and routing conventions.
Furthermore,
when interfacing a \trustedmail/ system,
no modifications need be made to the \MTS/ or local \MTA/.

In addition to the systems-level advantage to this scheme,
users of the system profit as well,
since many disjoint \MTS/s can be employed by a user with a single \TMA/.
This reduces the number of weaknesses in the system and allows a user to keep
a single database of ``trusted'' correspondents.
It should also make analysis and verification of the \TMA/ easier.

Of course from the user-viewpoint,
once the \TMA/ has been initially booted,
all key management is automatic.
Not only does this reduce the risk of compromise of cryptographic material
(given proper construction and maintenance of the \TMA/),
but it relieves the user of a tedious and error-prone task.

Finally,
although the \KDS/ described herein is used to support \trustedmail/,
other applications which require key management,
could employ the services offered by the key distribution center.

\subsection{Open Questions}
At present, there are many restrictions on the prototype implementation
described.
Some of these result from that fact that the implementation is a prototype
and not a production system.
Others deal with more fundamental issues.

In terms of the \TMA/,
the expiration delay for keys is hard-wired in;
it should be user-settable.
In the prototype version,
the KK and KA with the \KDS/ are good for 2~days or 10~uses
(whichever comes first),
while a KK for use with another \TMA/ is good for 1~day or 5~uses.
In actual practice,
keys with long cryptoperiods might be good for 6~months or 100~uses,
while keys with short cryptoperiods might be good for 1~month or 25~uses.
The choice of actual values is an open question
beyond the scope of prototype system.%
\nfootnote{The current values were chosen by guess work.
Although not necessarily technically sound,
the small numbers were very good for debugging purposes.}
In many respects, this issue is a classic trade-off:
with relatively small cryptoperiods,
an adversary has less chance of breaking a key,
but with longer cryptoperiods less connections have to be made to the key
distribution server.

A fundamental issue,
owing to differences between the EFT and CBMS environments,
is that the \KDS/ implements only a subset of the \ansi/ draft
and the semantics of certain operations have changed somewhat.
It would be nice to unify the CBMS and EFT views
of a {\it key distribution center}
(in the former environment, the center is called a \KDC/,
while in the latter environment, the center is known as a \CKD/).
Appendix~C of this paper discusses the differences between the two
perspectives in greater detail.

At present,
the relationship between errors in the \TMA/ and the posting process is an
open question.
For example,
if an address doesn't have a mapping in the \TMA/ database,
\pgm{post} treats this as an address verification error.
This prevents the draft from being posted.
The philosophy of the \UA/ is unclear at this point,
with respect to how recovery should occur.
A second area, also in question, deals with the way in which plaintext and
ciphertext versions of a message are present in a system.
Clearly, it is a bad idea to make both versions available,
but since the \TMA/ doesn't try to concern itself with first party
observation,
there seems to be little possibility of preventing this behavior.
The best that can be done,
at this stage,
is simply to choose a consistent policy that user's should attempt to adhere
to.
The software can help somewhat in implementing this policy,
but it certainly can't circumvent the user.

The prototype is built on the assumption that a single key
distribution server is present.
Since the \ansi/ draft\cite{FIKM} makes provisions for
{\it key translation centers},
the \trustedmail/ prototype should perhaps be made to operate in a more diverse
environment.
Until the issues become clearer,
this remains open.

Finally,
for distribution lists,
a large number of people would need to share the same \KDS/ ID.
The current implementation doesn't support this.
Each \TMA/ database is for a particular ID.
A user with multiple IDs would need multiple databases,
or the database should be re-organized.

\subsection{Weaknesses}
As pointed out earlier,
this prototype system situates itself in a commercial, not military,
environment.
With respect to this decision,
several aspects of the system are now discussed,
which we feel are acceptable in a commercial environment,
but which would be considered weaknesses in a military environment:

\item{1.} Traffic Flow\hbreak
The prototype \TMA/ makes no attempt whatsoever to prevent or confuse traffic
analysis by augmenting traffic flow.

\item{2.} The Database of \KDS/ Subscribers\hbreak
Since information returned by the request user identification (RUI)
and request identified user (RIU) MCLs are returned in the clear,
this allows an adversary to ascertain subscribers to the \KDS/,
and perhaps deduce some information about the system.
Without knowledge of the master key however,
an adversary could not impersonate a subscriber though.
Still, in the military sense, this is a weakness.
However,
all this assumes that the database maintained by the \KDS/ accurately
reflects the real-world.

\item{3.} Multiple Recipients\hbreak
It is possible, though not proven to the authors' knowledge,
that the scheme used to avoid encrypting the body of a message more than once
for multiple recipients might permit one of the recipients who is also an
adversary to compromise the key relationship between the sender and another
recipient.

\item{} The scenario goes like this:
When a message is being prepared for encryption,
a single KD/IV/KA triple is generated to encrypt the body.
Since the sender has a different key relationship with each recipient,
each message sent is different, since the structure $m$ depends not only on
the KD/IV/KA triple but also on the key relation between the sender and a
particular recipient.
Now suppose that one of the recipients, $r_1$,
in addition to receiving the copy of the message meant for him/her also
intercepts a copy of the message destined for another recipient, $r_2$.
At this point,
the recipient $r_1$ has both the plaintext and ciphertext version of the body,
the plaintext version of the KD/IV/KA triple,
and the ciphertext version of the KD/IV/KA triple that was generated using
the key relationship between the sender and the recipient $r_2$.
The question is:
can $r_1$ now deduce the key relationship between the sender and $r_2$?

\item{} If so, then the way that the \TMA/ attempts to minimize the use of
encryption resources is a weakness.
But, even if this is possible,
given relatively short cryptoperiods for key relationships between \TMA/
peers,
this becomes a non-problem.

\item{4.} Discussion Groups\hbreak
As discussed earlier,
the proposed method of associating a single \KDS/ ID with the membership of a
discussion group does introduce a significant weakness for the security of
messages sent to the discussion group.
Since the \TMA/ does not assume a general broadcast facility,
it appears that there are no good solutions to the problem of discussion
group traffic.
Of course,
it is easy enough to simply send to each member of the group.

\item{} For the sake of argument,
let's assume that the discussion group has $n$ members.
Now,
since a different key relationship would exist between the sender and
each of the $n$ recipients,
the structure $m$ would be different for each recipient
and so a different message would have to be sent to each recipient.
To make matters worse,
if one rejects the way the \TMA/ handles multiple recipients,
not only does the \MTS/ get burdened with $n$ different messages,
but the sender's \TMA/ gets burdened by having to encrypt
the body of the message $n$ times.
For meaningful values of $n$ (say on the order of~500, or even~25),
the amount of resources required for any trusted discussion group are simply
too costly.

\subsection{Compromises, Compromises}
Each of the possible weaknesses discussed above represent a compromise
between the expense of the system and the level of security it can provide.

The first two areas, if addressed by the \TMA/,
could result in much less background information being available to an
adversary.
In an application where it is important that an adversary not know who is
talking to whom,
or who can talk at all,
this is very important.
It is the authors' position that in the commercial environment,
this issue is not paramount.
By ignoring the issue of traffic flow,
the \TMA/ has a lot less work to do and the \MTS/ is kept clear of
``useless'' messages.
By keeping the information returned by the RUI and RIU MCLs in the clear,
the complexity of the \TMA/ is significantly reduced.

The second two areas, if addressed by the \TMA/,
could result in a lesser probability of traffic being deciphered by an
adversary.
Regardless of the application,
this is always extremely important.
However,
the authors' feel that the compromise made by the \TMA/ in these two issues
is not substantial,
and does not result in an explicit weakness when a message is sent to
multiple recipients
(note that when there is only a single recipient of a message,
these two policies can not introduce weaknesses).
In return, efficient use can be made of both the \MTS/ and the \TMA/ when
messages are being sent to multiple recipients.
Given scarce resources or large numbers of recipients,
this approach may prove to be quite winning.

Of course, much work remains to be done to prove the success of the \TMA/ in
all four of these areas.

\section{Acknowledgements}
The prototype implementation described herein utilizes a public domain
implementation of the DES algorithm\cite{DEA}
which was originally implemented by James J.~Gillogly in May, 1977
(who at that time was with the Rand Corporation,
and is now affiliated with Gillogly Software).
Interfaces to Dr.~Gillogly's implementation were subsequently coded by
Richard W.~Outerbridge in September, 1984
(who at that time was with the Computer Systems Research Institute
at the University of Toronto,
and is now affiliated with Perle Systems, Incorporated).

The authors would like to acknowledge Dennis Branstad,
Elaine Barker, and David Balensen of the National Bureau of Standards
for their comments on the prototype system
and insights on the ANSI draft\cite{FIKM}.
In particular, Dr.~Branstad originally suggested the method used for
encrypting a single message for multiple recipients under different keys.

The authors (and all those who have read this paper) would like to thank
Willis H.~Ware of the Rand Corporation,
and Jonathon B.~Postel of the USC/Information Sciences Institute.
Their extensive comments resulted in a much more readable paper.
In addition,
the authors would like to thank
Dr. Stephen P.~Smith and Major Douglas A.~Brothers
for their insightful comments.