text.tex

早期freebsd实现

\noindent
This format is widely called ``822'' after the number assigned to the
defining report\cite{DCroc82}.%
\nfootnote{Although an 822--style framework is employed by the \TMA/ prototype,
the 822 \eg{Encrypted:} header is not currently present in encrypted messages.
This is due to a design decision which assumes that nothing in the headers of
a message is sacred to the transport system,
and that ``helpful'' munging might occur at any time.
In the real world, such helpfulness is often a problem.}

To support the cipher activities described below,
the \TMA/ contains internal routines to perform the following DES functions:
electronic code book (ECB) for key encryption,
cipher block chaining (CBC) for mail message encryption,
checksumming (CKS) for mail message and \CSM/ authentication.
Readers interested in these different modes of operation for the DES should
consult \cite{FIPS81}.

\subsection{Encrypting Mail}
To encipher a message, the method used is a straightforward adaptation
of the standard encrypting/authentication techniques
(though the terminology is tedious).
Consider the following notation:
\smallskip
{\advance\leftskip by\parindent
\itemm $a_x(s)$ the checksum of the string $s$ using the key $x$
(DEA~{\it checksumming} authentication)

\itemm $a_{x+y}(s)$ the checksum of the string $s$ using the exclusive-or
of the two keys $x$ and $y$

\itemm $e_x(y)$ the encryption of the key $y$ using the key $x$
(DEA~{\it electronic code book} encryption)

\itemm $e_{x,y}(s)$ the encryption of the string $s$ using the key $x$
and initialization vector $y$
(DEA~{\it cipher block chaining} encryption)

\itemm $h$ the headers of the message

\noindent and,

\itemm $b$ the body of the message
\smallskip}
\noindent
For each message to be encrypted,
a data key, initialization vector, authentication key (KD/IV/KA)
triple is generated by a random process.
(It goes without saying that the integrity of the system depends on the
process being {\it random\/}).
Then, for each user to receive a copy of the encrypted message,
the following actions are taken:

First, the headers of the message are output in the clear.
Then, a {\it banner} string, $i$, is constructed and placed at the beginning
of the body of the message:
\example ENCRYPTED MESSAGE: TTI TMA\endexample
which identifies the message as being encrypted by the \TTI/ \TMA/.
Following the banner string is a structure, $m$,
which takes on the syntax and most of the semantics of a cryptographic
service message:
$$\displayindent=\leftskip	\advance\displayindent by1.5\parindent
    \halign{\hfil#/&	\enspace#\hfil\cr
	MCL&	MAIL\cr
	RCV&	rcvid\cr
	ORG&	orgid\cr
	IDK&	kkid\cr
	KD&	$e_{kk}(ka)$\cr
	KD&	$e_{kk}(kd)$\cr
	IV&	$e_{kd}(iv)$\cr
	MIC&	$a_{ka}(b)$\cr
	MAC&	$a_{kd+ka}(m)$\cr
}$$
After this, the encrypted body is output, $e_{kd,iv}(b)$.
In short, the entire output consists of
$$h+i+m+e_{kd,iv}(b).$$

The purpose of the structure $m$ is many-fold.
The MCL field indicates the structure $m$'s type;
currently only the type MAIL is generated and understood.
The RCV and ORG fields identify the intended recipient of the message
and the originator.
The IDK field identifies the key-encrypting key, KK,
used to encrypt the next two fields.
The first KD field has the encrypted authentication key, KA,
used to calculate the MIC of the plaintext of the body of the message.
After the body of the message is deciphered, $a_{ka}(b)$ is calculated and
compared to the value of the MIC field.
Hence, the MIC field authenticates the message body.
The second KD field has the encrypted data encrypting key, KD,
which along with the encrypted initialization vector in the IV field
was used to generate the ciphertext of the body.
Finally, the MAC field authenticates the $m$ structure itself.
The use of a data key, initialization vector, authentication key (KD/IV/KA)
triple permits us to perform key distribution in a hierarchical fashion and
allows the system to use a KK-relationship over a longer cryptoperiod
without fear of compromise.

The \TMA/ provides three primary interfaces to a \UA/ to send encrypted mail:
the first takes a file-descriptor to a message
and returns a structure $g$ (called a {\it group})
describing the ciphertext version of the body
(this structure contains a KD, IV, and KA generated at random,
along with a file-descriptor to the plaintext headers,
a file-descriptor to the ciphertext body,
and the checksum of the plaintext body);
the second takes a user entry (or \MTS/ address) and $g$,
and returns a file-descriptor to the encrypted message
for that user (or \MTS/ address);
the third takes $g$ and performs clean-up operations.
The chief advantage to this scheme of encryption
is that if the message is to be sent to more than one recipient,
then the MIC and the encrypted body need only be calculated once,
since the KD, IV, and KA remain constant
(only the KK's change with each recipient,
hence for each copy of the encrypted message,
only the structure $m$ need be re-calculated).

There are, however, a few subtleties involved:
\underbar{first},
the \MTS/ usually accepts only 7--bit characters,
so the encrypted text is exploded to consist of only printable characters;%
\nfootnote{%
As a rule, in all \CSM/s,
when encrypted information is transmitted,
it is exploded after encryption by the sender,
and imploded prior to decryption by the receiver.}
\underbar{second},
since the \MTS/ may impose limits on the length of a line,
each line of output is limited to 64~characters;
and,
\underbar{third},
since the body may require trailing padding,
during encryption
one last unit of 8~bytes is written (and encrypted),
naming the number of characters (presently, nulls) padded in the
previous 8~bytes ($0\tdots7$).

\subsection{Decrypting Mail}
To decipher a message, the method is also straightforward:
The headers are output in the clear.
The banner string is essentially ignored,
and the structure $m$ is consulted to identify the correct key-encrypting key.
The \TMA/ checks to see if it knows of that KK.
If not, it asks the \KDS/ to supply it.
From that point,
the KA, KD, and IV are deciphered.
The $m$ structure is then authenticated.
With the correct key,
the remainder of the body is deciphered,
and all except for the last 16~bytes are output.
The last 8~bytes indicate how many of the previous 8~bytes should be output.
So,
the appropriate number of bytes is output,
and the plaintext body is authenticated and compared to the MIC.
Needless to say,
as the body is deciphered,
it is imploded back to 8--bit characters and lines are restored to their
previous lengths.
To indicate that the message was correctly deciphered,
a new header of the form
\example X-KDS-ID: orgid (originator's name)\endexample
is appended to the headers of the message.
Note that this provides an authentication mechanism.
Note, further,
that the \UA/ did not have to know the identity of the sender of the message.

\section{Modifications to MH}
\MH/ is a public domain \UA/ for \unix/,
which is widely used in dealing with both a large number of electronic mail
application and a large number of messages.
Although this document does not intend to describe \MH/,
parts of the system are described as they relate to the \TMA/.
Readers interested in \MH/ should consult either the user's
manual\cite{MRose85a} for a detailed description,
or \cite{MRose85d} for a higher-level description.

To modify \MH/ in order to make use of a \TMA/,
three programs were changed (with a high degree of transparency to the user),
and two new programs were introduced.

In \MH/,
when a user wishes to send a composed draft
(which may be an entirely new message,
a re-distribution of a message,
a forwarding of messages,
or a reply to a message),
the user invokes the \pgm{send} program.
This program performs some minor front-end work for a program called
\pgm{post} which actually interacts with the \MTS/.
A new option to the \pgm{send} and \pgm{post} programs,
the \switch{encrypt} switch,
is introduced.
If the user indicates
\example send\ -encrypt\endexample
then \pgm{post} encrypts the messages it sends.

When sending an encrypted message,
\pgm{post} first checks that each addressee has a mapping to a \KDS/ ID
during address verification.
Then, instead of batching all addresses for a message in a single posting
transaction,
for each addressee,
\pgm{post} consults the \TMA/ for the appropriately encrypted text and
posts that instead.
(Appendix~A discusses the reasons for this more fully.)
Hence,
assuming the user has established mappings between \MTS/ addresses
and \KDS/ IDs,
the \TMA/ does all the work necessary to encrypt the message,
including contacting the \KDS/ as necessary.%
\nfootnote{Once the \TMA/ establishes a connection to the \KDS/,
it retains that connection until the \UA/ terminates.
This is done to minimize connections to the \KDS/.
In the context of \MH/,
since the trusted mail agent is active over the lifetime of an invocation of
a program such as \pgm{post},
this means that the connection is terminated just before the program
terminates.}

In \MH/,
when a user is notified that new mail has arrived,
the \pgm{inc} program is run.
As each message is incorporated into the user's message handling area,
a scan (one-line) listing of the message is generated.

By default,
the \pgm{inc} program upon detecting one or more encrypted messages,
after the scanning process,
asks the \TMA/ to decipher the message,
and if successful,
scans the deciphered messages.
This action can be inhibited with the \switch{nodecrypt} switch.
Hence, if the user wishes to retain messages in encrypted form,
\pgm{inc} can be told to note the presence of encrypted messages,
but otherwise not to process them.
By using the \MH/ user profile mechanism,
\pgm{inc} can be easily customized to reflect the user's tastes.
Again,
the actions of the \TMA/ are transparent to the user.
In fact,
if encrypted mail is received from users unknown to the \TMA/,
it queries the \KDS/ as to their identity prior to retrieving the
KK-relationship.

If \pgm{inc} fails to decrypt a message for some reason,
or if \pgm{inc} was told not to decrypt a message,
the \pgm{decipher} program can be used.
This simple program merely deciphers each message given in its argument
list.
The \pgm{decipher} program can be given the \switch{insitu} switch,
which directs it to replace the ciphertext version of the message with the
plaintext version;
or,
the \switch{noinsitu} switch can be used indicating that the ciphertext
version of the message should be left untouched and the plaintext version
should be listed on the standard output.

Finally,
the \pgm{tma} program is used to manipulate the \TMA/ database,
containing commands to boot the database,
add new users to the database,
and to establish mappings between addresses and users in the \TMA/ database.
This program can also be used to disconnect KKs between other \TMA/s,
and the KK/KA between itself and the \KDS/.

Appendix~A of this paper contains a transcript of an \MH/ session.

\section{Remarks}
We now consider the merit of the system described.