![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to text.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / mh / papers / trusted|
Return to text.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / mh / papers / trusted |
1.1 root 1: % begin text
2:
3: \banner
4:
5: \section{Introduction}
6: Initially,
7: a brief model of a user community employing a trusted mail service is
8: introduced.
9: Following this introduction,
10: a prototype system is described which attempts to meet the needs of a user
11: community.
12: Finally,
13: open issues are discussed,
14: which are currently not satisfied by the prototype system or its model of
15: operation.
16:
17: Two or more entities,
18: called {\it users},
19: wish to communicate in a {\it secure} environment.
20: Depending on their available resources,
21: different levels of security are possible.
22: At the extreme,
23: two parties with substantial resources may wish to communicate in a fashion
24: which prevents any third parties,
25: known as {\it adversaries},
26: from observing their communication.
27: At this level,
28: not only is an adversary unable to capture the communication for analysis,
29: but in fact, the adversary is unaware that any communication is occurring at
30: all.
31: In most applications,
32: this level of security is prohibitively expensive.
33: A more economic method is to translate messages into a form which is useless
34: to an adversary and then to communicate those messages on an insecure medium.
35:
36: This latter method requires the two users to have some sort of {\it key}
37: with which to ``lock'' the plaintext into ciphertext when transmitting,
38: and then to ``unlock'' the ciphertext back into useful form when receiving.
39: Hence, there are two central issues to deal with:
40: \underbar{first},
41: keys must be generated, distributed, and maintained in a secure fashion;
42: and,
43: \underbar{second},
44: the keys must be ``intricate'' enough so that sense can't be made out of the
45: ciphertext without knowledge of the key.
46: The first part is handled by a {\it key distribution center} (\KDC/),
47: which maintains a list of users and a set of keys for each pair of users.
48: The second part relies on sophisticated encryption and decryption algorithms.
49: It is beyond the scope of this paper to describe cryptographic techniques in
50: detail.
51: For a detailed survey of this area, the reader should consult \cite{VVoyd83}.
52:
53: \tagfigure{1}{The \MTS/ Model}{mtsmodel}
54: In the context of our discussion (using the terminology of \cite{X.400}),
55: the medium used to transport is supplied
56: by a {\it message transport system} (\MTS/),
57: which is composed of one or more {\it message transport agents} (\MTA/s).
58: Usually,
59: the entire \MTS/ is distributed in nature,
60: and not under a single administrative entity;
61: in contrast, an \MTA/ is usually controlled by a single administration and
62: resides in a particular domain.
63: At every end-point in the medium,
64: a {\it user agent} (\UA/) acts on behalf of a user and interfaces
65: to a local \MTA/.
66: This model is briefly summarized in Figure~\mtsmodel.
67:
68: A message, in our context, consists of two parts:
69: the {\it headers} and the {\it body}.
70: The headers are rigorously structured;
71: they contain addressing information and other forms useful to a \UA/.
72: The body is freely formatted and is usually not meaningful to a \UA/.
73:
74: When a message is sent from one user to another,
75: the following activities occur:
76: The originating user indicates to the \UA/ the address of the recipient;
77: the \UA/ then posts the message through a {\it posting slot} to an \MTA/,
78: which involves a posting protocol in which the validity of the address
79: and the syntax of the message are considered.
80: Upon successful completion of the protocol,
81: the \MTA/ accepts responsibility for delivering the message,
82: or if delivery fails, to inform the originating user of the failure.
83: The \MTA/ then decides if it can deliver the message directly to the
84: recipient;
85: if so, it delivers the message through a {\it delivery slot} to the
86: recipient's \UA/,
87: using a delivery protocol.
88: If not, it contacts an adjacent \MTA/, closer to the recipient,
89: and negotiates its transfer (using a protocol similar to the posting protocol).
90: This process repeats until an \MTA/ is able to deliver the message,
91: or an \MTA/ determines that the message can't be delivered.
92: In this latter case,
93: a failure notice is sent to the originating user.
94:
95: \tagfigure{2}{Mappings in the \MTS/ model}{mappings}
96: It is important to note that there are two mappings which occur here.
97: The first, which is performed implicitly by the originating user,
98: maps the name of the recipient into the recipient's address;
99: the second, which is performed explicitly by the \MTS/,
100: maps the address of the recipient into a route to get from the originator's
101: \MTA/ to the recipient's \MTA/.
102: These mappings are depicted in Figure~\mappings.
103:
104: Obviously, there is no guarantee that the \MTS/ can be made secure,
105: in {\it any} sense of the word.
106: This is particularly true if it is under several administrations.
107: Regardless of the number of administrations in the \MTS/,
108: this problem quickly degenerates to a problem of
109: Byzantine generals\cite{LLamp82}.
110: Further, trying to secure each \MTA/ in the path that a message travels is
111: equally questionable.
112:
113: \tagfigure{3}{Modifications to the \MTS/ model}{tmodel}
114: To support secure communications in this environment,
115: a new entity,
116: the {\it trusted mail agent} (\TMA/) is introduced into our model.
117: A solution is to have the \UA/ interact with this entity
118: both when posting a message and when taking delivery of a message.
119: The \UA/ first contacts a \TMA/ to encrypt the body of the message for the
120: recipient,
121: prior to pushing it through the posting slot.
122: Upon receipt from the destination \MTA/,
123: the \UA/ examines the message and contacts
124: the \TMA/ to decipher the body of the message from the source.
125: An overview of the relationship between the standard \MTS/ model
126: and the augmentations made for the \trustedmail/ system is shown in
127: Figure~\tmodel.
128:
129: To achieve these tasks,
130: the \TMA/ interacts with a {\it key distribution service} (\KDS/),
131: which manages keys between pairwise users.
132: At this point, a third mapping takes place:
133: the \UA/ must be able to map addresses into the identifier(s)
134: by which the originator and recipient are known by the \TMA/ and \KDS/.
135: These identifiers are known as \KDS/ IDs, or simply IDs.
136: Usually, a fourth mapping also occurs,
137: which maps the ID of a user into the name of a user.
138: In our context,
139: there is an exact one-to-one mapping between the name of a user and the ID
140: of that user.
141: In contrast,
142: there may be a one-to-many mapping between the name of a user and
143: that user's address in the \MTS/.
144: Further, there are usually many different routes which a message may traverse
145: when going from an originating user to a recipient user.
146:
147: The \TMA/ is said to be {\it trusted} because it can be relied on to perform
148: only those actions specifically requested by the user.
149: In the context of this paper,
150: this means, given proper construction and maintenance of the \TMA/,
151: that the software will communicate with the \KDC/ in some secure fashion to
152: negotiate key relationships and that it will not disclose those key
153: relationships to other parties.
154: Furthermore,
155: the body of mail messages exchanged between users which employ
156: a trusted mail agent will be unintelligible to other parties.
157: Finally,
158: a recipient of a message receives authenticated information from the
159: trusted mail agent as to the identify of the sender.
160:
161: Hence,
162: when each user employs a \TMA/,
163: end-to-end encryption occurs at the \UA/ level
164: (to avoid any problems with malicious \MTA/s).%
165: \nfootnote{Note that in the scope of this system,
166: the end-points are the user agents, not the hosts they reside on.
167: In fact,
168: it may very well be the case that the user agent and the local message
169: transport agent do not reside on the same host.}
170: Any adversary listening in on the \MTS/,
171: may observe messages,
172: but make no sense out of them
173: (other than rudimentary traffic analysis).
174: Note, however,
175: that since the medium itself is not secure,
176: an adversary may still introduce new messages,
177: corrupt messages,
178: or remove messages,
179: as they traverse the \MTS/.
180: In the first two cases, however,
181: the recipient would be suspicious
182: because the adversary lacks the encrypting key employed by the source user.
183: In the third case,
184: the source user can retransmit the message after a suitable time.
185: Of course,
186: there is no built-in retransmission policy~---~this aspect depends on the
187: user's sending mail and is beyond the scope of the system.
188:
189: It is important to understand the target community for the \trustedmail/ system
190: described herein.
191: In particular,
192: the \TMA/ is intended for a commercial and not a military environment.
193: This distinction is important,
194: since it is the {\it fundamental} assumption of this paper that
195: the latter community has much stricter requirements than the former.
196: Because of this,
197: the prototype system is able to make certain simplifying assumptions which
198: permit it to operate in a mode which is less secure than military
199: applications would permit.
200: Although these issues are explored in greater detail at the end of the paper,
201: for the moment recall that, like most qualities, trustedness is not absolute:
202: there are varying degrees of trustedness,
203: and as a system becomes more trusted,
204: it becomes more expensive, in some sense, to operate and maintain.
205:
206: It is perhaps instructive at this point to consider why the introduction of a
207: key distribution center is appropriate in this environment,
208: and why the {\it fundamental} assumption that trusted mail agents do not
209: directly communicate with each other is necessary.
210: Although a user agent is able to converse with the local message transport
211: agent in real-time,
212: it is frequently not able to communicate with other user agents in real-time.
213: Furthermore,
214: considering the vast problems and overhead
215: of trying to establish secure communications from ``scratch''
216: (a problem far beyond the scope of this paper),
217: it is would not be a good idea to try and communicate key relationships with
218: other user agents,
219: even if it were always possible to do so.
220: In addition,
221: by separating the trusted aspects of the message transport system from the
222: system itself,
223: many other advantages can be seen.
224: These are presented in greater detail at the end of the paper.
225:
226: The discussion thus far has considered only a single recipient.
227: In practice, a user might wish to send to several others,
228: using a different key for each.
229: Hence each copy of the message is encrypted differently,
230: depending on the particular recipient in question.
231: Note that this has the effect of {\it un-bundling} message transfer in the
232: \MTS/,
233: as advanced \MTA/s tend to keep only a single copy of the message for any
234: number of recipients in order to save both cpu, disk, and I/O resources.
235:
236: For example,
237: in some existing mail systems,
238: if a message was sent to $n$ users on a remote system,
239: then the $n$ addresses would be sent from the source \MTA/ to the remote \MTA/
240: along with one copy of the message.
241: Upon delivery,
242: the remote \MTA/ would deliver a copy to each of the $n$ recipients,
243: but the virtual wire between the source \MTA/ and the recipient \MTA/ was
244: burdened with only one copy of the message.
245: But in a secure environment,
246: since a different key is used by the source user when communicating with each
247: of the $n$ recipients,
248: $n$ different messages will be posted with the local \MTA/,
249: and the advantages of recipient bundling are lost.
250:
251: Along these lines however,
252: private discussion groups may wish to avoid this problem by establishing
253: access to a single ID for their use.
254: In this case,
255: a subscriber to the \KDS/ may actually have more than one ID,
256: one for ``personal'' use and one for each discussion group.
257: The appropriate ID is used when posting messages to the discussion group.
258: Naturally the administrative policy for deciding who is allowed to use the
259: \KDS/ ID of a discussion group is left to the moderator of the group.
260: Observant readers will note that this vastly decreases the aspect of
261: secure communications for the discussion group.
262: This method is suggested as a compromise
263: which permits the bundling of messages for multiple recipients
264: to reduce \MTS/ traffic.
265: The price is high however,
266: as a compromise on behalf of {\it any} member of the discussion group
267: compromises the entire group.
268: For large discussion groups and a bandwidth limited \MTS/,
269: this price may be worth paying.
270: The prototype implementation of the \TMA/ supports multiple recipients but
271: not multiple \KDS/ IDs.
272:
273: Having described this environment for communication,
274: the designs of a \KDS/ and \TMA/ which form the heart of the \TTI/
275: \trustedmail/ system are discussed.
276: The prototype system was developed on a \vax/-11/780 running 4.2\bsd/ \unix/.
277: The system is based on the \ansi/ draft\cite{FIKM}
278: for financial key management,
279: but diverges somewhat in operation
280: owing to the differences between the electronic mail (CBMS)
281: and electronic funds (EFT) environments.
282: Note however that the \ansi/ data encryption algorithm\cite{DEA,FIPS46} is
283: used in the current implementation.
284: A public-key cipher system was not considered as the basis for the prototype
285: since, to the authors' knowledge,
286: an open standard for a public-key system has yet to be adopted by the
287: commercial community.
288: In contrast,
289: the \ansi/ draft for financial key management appears to be receiving
290: wide support from the commercial community.
291:
292: \tagtable{4}{Abbreviations used in this paper}{terms}
293: In the description that follows,
294: a large number of acronyms are employed to denote commonly used terms.
295: In order to aid the reader,
296: these are summarized in Table~\terms.
297:
298: \section{The Key Distribution Service}
299: The prototype version of the \KDS/
300: was designed to provide key distribution services for
301: user agents under both the same or different administrations.
302: As a result,
303: the means by which a trusted mail agent connects to a key distribution server
304: is quite flexible.
305: For example,
306: the prototype system supports connections via
307: standard terminal lines,
308: dial-ups (e.g., over a toll-free 800 number),
309: \unix/ pipes,
310: and over TCP sockets\cite{IP,TCP}.
311: In the interests of simplicity,
312: for the remainder of this paper,
313: a TCP/IP model of communication is used.
314: Initially,
315: a server on a well-known service host in the ARPA Internet community
316: listens for connections on a well-known port.%
317: \nfootnote{The term {\it well known} in this context means that the
318: location of the service is known {\it a priori} to the clients.}
319: As each connection is established,
320: it services one or more transactions over the lifetime of the session.
321: When all transactions for a session have been made,
322: the connection is closed.
323: If the necessary locking operations are performed by the server
324: to avoid the usual database problems,
325: then more than one connection may be in progress simultaneously.
326: Of course,
327: a time-out facility should also be employed to prevent a rogue agent from
328: monopolizing the key distribution server.
329:
330: Once a session has been started,
331: the client (a.k.a.~\TMA/) initiates transactions with the server
332: (a.k.a.~\KDS/).
333: Each transaction consists of the exchange of two or three
334: {\it cryptographic service messages} (\CSM/s):
335: the client sends a request,
336: the server attempts to honor the request and sends a response,
337: and,
338: if the server responded positively,
339: the client then acknowledges the transaction.
340: By exchanging these cryptographic service messages,
341: the \KDS/ and the \TMA/ are able to communicate key relationships.
342: Obviously, the relationships themselves must be transmitted in encrypted
343: form.%
344: \nfootnote{Otherwise an adversary could simply impersonate a \TMA/ and ask
345: for the desired key relationships.
346: Similarly, this also prevents an adversary from successfully impersonating a
347: key distribution server.}
348: Hence, not only are key relationships between two \TMA/s communicated,
349: but key relationships between the \KDS/ and the \TMA/ are communicated as well.
350:
351: This leads us to consider the key relationships that exist
352: between a \TMA/ and the \KDS/.
353: A client usually has three keys dedicated for use with the server.
354: The first is the {\it master key} (denoted MK),
355: which has an infinite cryptoperiod, and is rarely used.
356: This key is distributed manually.
357: The second is the {\it key-encrypting key} (denoted KK),
358: which has a shorter cryptoperiod.
359: Whenever a KK is transmitted to the \TMA/,
360: it is encrypted with the master key.
361: The third is the {\it authentication key} (denoted KA),
362: which is used to authenticate transactions that do not contain data keys
363: (a count field is also used to avoid play-back attacks).
364: Whenever a KA is transmitted to the \TMA/,
365: it is encrypted with the key-encrypting key.
366: When transactions contain keys,
367: an associated count field is included to indicate the number of
368: keys encrypted with the key-encrypting key used.
369: Although not used by the prototype implementation,
370: a production system would employ audit mechanisms to monitor usage histories.
371:
372: Currently four types of requests are honored by the \KDS/:
373: two key relationship primitives, and two name service primitives.
374: The type is indicated by the {\it message class} (MCL) of the first
375: cryptographic service message sent in the transaction.
376: As each message class is discussed,
377: the appropriate datastructures used by the \KDS/ are introduced.
378: Space considerations prevent a detailed description of the information
379: exchanged in each transaction.
380: Appendix~B of this paper presents a short example of an interaction between
381: the \KDS/ and a \TMA/.
382:
383: The first two requests are used to create (or retrieve) key relationships,
384: and to destroy key relationships:
385:
386: The {\it request service initialization} (RSI) message class
387: is used to establish a {\it key-encrypting key} (KK) relationship
388: between the \TMA/ and another \TMA/,
389: or between the \TMA/ and the \KDS/.
390: As implied by the name,
391: a key-encrypting key is used to cipher keys which are used to cipher data
392: exchanged between peers.
393: These other keys are called {\it data keys} (KDs).
394:
395: The {\it disconnect service message} (DSM) message class
396: is used to discontinue a KK-relationship
397: between the \TMA/ and another \TMA/,
398: or between the \TMA/ and the \KDS/.
399: This prevents keys which are felt to have been compromised,
400: or are vulnerable to compromise,
401: from receiving further use in the system.
402: It should be noted that,
403: owing to mail messages (not \CSM/s) in transit,
404: a discontinued key relationship
405: may be needed to decipher the key used to encipher a mail message.
406: The prototype \KDS/ supports this capability.
407:
408: In addition to maintaining an MK/KK/KA triple for each \TMA/,
409: the \KDS/ also remembers KK-relationships between \TMA/s.
410: The reason for this stems from a fundamental difference between the
411: electronic funds transfer and computer-based message system worlds.
412: The \KDS/ assumes that no two arbitrarily chosen \TMA/s can communicate in
413: real-time,
414: and as a result,
415: \TMA/s do not exchange cryptographic service messages.
416: (See Appendix~C for a more detailed discussion.)
417: This means that when a \TMA/ establishes a KK-relationship with another \TMA/,
418: the former \TMA/ may start using the KK before the latter \TMA/ knows of the
419: new KK-relationship.
420: In fact,
421: it is quite possible for a KK-relationship to be established,
422: used,
423: and then discontinued,
424: all unilaterally on the part of one \TMA/.
425: It is up to the \KDS/ to retain old cryptographic material
426: (possibly for an indefinite period of time),
427: and aid the latter \TMA/ in reconstructing KK-relationships as the need arises.
428: Naturally,
429: discontinued KKs are not used to encode any new information,
430: but rather to decode old information.
431: (Again, refer to Appendix~C for additional details.)
432:
433: The other two requests are used to query the directory service aspects of the
434: key distribution server:
435:
436: The {\it request user identification} (RUI) message class
437: is used to identify a subscriber to the \KDS/.
438: Both the \KDS/ and \TMA/ are independent of any underlying mail transport
439: system (\MTS/).
440: As a result,
441: a subscriber to the \KDS/ is known by two unique attributes:
442: a ``real-world'' name,
443: and a \KDS/ identifier (ID).
444: The user of a mail system,
445: or the \UA/,
446: is responsible for mapping an \MTS/-specific address
447: (e.g., {\tx [email protected]})
448: to the person associated with that maildrop
449: (e.g., \eg{Marshall\ T.\ Rose}).
450: When conversing with the \KDS/,
451: the \TMA/ uses the \KDS/ ID of another user to reference that person's \TMA/.
452: Since it is inconvenient to remember the IDs (as opposed to people's names),
453: the \KDS/ provides the RUI message class to permit a \TMA/ to query the
454: mapping between names and IDs.
455: If the \KDS/ cannot return an exact match,
456: it may respond with a list of possible matches
457: (if the identifying information given was ambiguous),
458: or it may respond with a response that there is no matching user.
459:
460: Finally,
461: the {\it request identified user} (RIU) message class
462: performs the inverse operation:
463: given a \KDS/ ID, a ``real-world'' name is returned.
464: This request is useful for disambiguating unsuccessful RUI requests
465: and in boot-strapping a \TMA/.
466:
467: The \KDS/ maintains two directories:
468: a private directory and a public directory.
469: The private directory contains all information on all clients to the \KDS/.
470: The public directory is a subset of this,
471: and is used by the \KDS/ when processing RUI and RIU requests.%
472: \nfootnote{In the prototype implementation,
473: the two directories are, for the moment, identical.}
474: As a result,
475: certain clients of the \KDS/ may have unlisted IDs and names.
476:
477: \section{The Trusted Mail Agent}
478: The prototype version of the \TMA/
479: was designed to interface directly to the user agent in order to maximize
480: transparency to the user.
481: In present form,
482: the \TMA/ is available as a load-time library under 4.2\bsd/ \unix/,
483: although efforts are currently underway to transport the \TMA/ to a PC-based
484: environment.
485:
486: The software modules which compose the \TMA/ contain a rich set of interfaces
487: to the \KDS/.
488: In addition,
489: the \TMA/ manages a local database,
490: so responses from the \KDS/ may be cached and used at a later time.
491: In all cases,
492: the \KDS/ is consulted only if the information is not present
493: in the \TMA/ database,
494: or if the information in question has expired (e.g., KK-relationships).
495: This caching activity minimizes connections to the \KDS/.
496: Although connections are relatively cheap in the ARPA Internet,
497: substantial savings are achieved for PCs which contact the \KDS/ over a
498: public phone network (dial-up) connection.
499:
500: The \TMA/ performs mappings between pairs of the following objects:
501: user names, \KDS/ IDs, and \MTS/ addresses.
502: The \TMA/ considers all trusted mail agents, including itself,
503: as a user name, \KDS/ ID, and one or more \MTS/ addresses.
504: Although the \TMA/ does not interpret addresses itself,
505: in order to simplify mail handling,
506: the \TMA/ remembers the relationship between these objects so the user enters
507: this information only once.
508:
509: Initially,
510: when a \TMA/ is booted,
511: the user supplies it with the master key and the user's \KDS/ ID.
512: Both of these quantities are assigned by the personnel at the key
513: distribution center,
514: and subsequently transmitted to the user via an alternate, bonded service.%
515: \nfootnote{In this fashion,
516: the problems of boot-strapping over an unsecure medium are avoided.}
517: The \TMA/ connects with the \KDS/ and verifies its identity.
518: From this point on,
519: the \TMA/ manages its KK-relationships between the \KDS/ and other \TMA/s
520: without user intervention.
521:
522: The current implementation of the \TMA/ assumes a ``general memo framework''
523: in the context of the Standards for ARPA Internet Text Messages\cite{DCroc82}:
524: \smallskip
525: {\advance\leftskip by\parindent
526: \item{1.} A message consists of two parts:
527: the {\it headers} and the {\it body}.
528: A blank line separates the headers from the body.
529:
530: \item{2.} Each (virtual) line in the headers consists of a keyword/value
531: pair, in which the keyword is separated from the value by a colon (:).
532: The headers are rigorously structured in the sense that they contain
533: addressing and other information useful to a user agent.
534:
535: \item{3.} The body is freely formatted and must not be meaningful to a
536: user agent.
537: However, as will be seen momentarily,
538: the body of encrypted messages must have an initial fixed format which the
539: \TMA/ enforces.
540: \smallskip}
541: \noindent
542: This format is widely called ``822'' after the number assigned to the
543: defining report\cite{DCroc82}.%
544: \nfootnote{Although an 822--style framework is employed by the \TMA/ prototype,
545: the 822 \eg{Encrypted:} header is not currently present in encrypted messages.
546: This is due to a design decision which assumes that nothing in the headers of
547: a message is sacred to the transport system,
548: and that ``helpful'' munging might occur at any time.
549: In the real world, such helpfulness is often a problem.}
550:
551: To support the cipher activities described below,
552: the \TMA/ contains internal routines to perform the following DES functions:
553: electronic code book (ECB) for key encryption,
554: cipher block chaining (CBC) for mail message encryption,
555: checksumming (CKS) for mail message and \CSM/ authentication.
556: Readers interested in these different modes of operation for the DES should
557: consult \cite{FIPS81}.
558:
559: \subsection{Encrypting Mail}
560: To encipher a message, the method used is a straightforward adaptation
561: of the standard encrypting/authentication techniques
562: (though the terminology is tedious).
563: Consider the following notation:
564: \smallskip
565: {\advance\leftskip by\parindent
566: \itemm $a_x(s)$ the checksum of the string $s$ using the key $x$
567: (DEA~{\it checksumming} authentication)
568:
569: \itemm $a_{x+y}(s)$ the checksum of the string $s$ using the exclusive-or
570: of the two keys $x$ and $y$
571:
572: \itemm $e_x(y)$ the encryption of the key $y$ using the key $x$
573: (DEA~{\it electronic code book} encryption)
574:
575: \itemm $e_{x,y}(s)$ the encryption of the string $s$ using the key $x$
576: and initialization vector $y$
577: (DEA~{\it cipher block chaining} encryption)
578:
579: \itemm $h$ the headers of the message
580:
581: \noindent and,
582:
583: \itemm $b$ the body of the message
584: \smallskip}
585: \noindent
586: For each message to be encrypted,
587: a data key, initialization vector, authentication key (KD/IV/KA)
588: triple is generated by a random process.
589: (It goes without saying that the integrity of the system depends on the
590: process being {\it random\/}).
591: Then, for each user to receive a copy of the encrypted message,
592: the following actions are taken:
593:
594: First, the headers of the message are output in the clear.
595: Then, a {\it banner} string, $i$, is constructed and placed at the beginning
596: of the body of the message:
597: \example ENCRYPTED MESSAGE: TTI TMA\endexample
598: which identifies the message as being encrypted by the \TTI/ \TMA/.
599: Following the banner string is a structure, $m$,
600: which takes on the syntax and most of the semantics of a cryptographic
601: service message:
602: $$\displayindent=\leftskip \advance\displayindent by1.5\parindent
603: \halign{\hfil#/& \enspace#\hfil\cr
604: MCL& MAIL\cr
605: RCV& rcvid\cr
606: ORG& orgid\cr
607: IDK& kkid\cr
608: KD& $e_{kk}(ka)$\cr
609: KD& $e_{kk}(kd)$\cr
610: IV& $e_{kd}(iv)$\cr
611: MIC& $a_{ka}(b)$\cr
612: MAC& $a_{kd+ka}(m)$\cr
613: }$$
614: After this, the encrypted body is output, $e_{kd,iv}(b)$.
615: In short, the entire output consists of
616: $$h+i+m+e_{kd,iv}(b).$$
617:
618: The purpose of the structure $m$ is many-fold.
619: The MCL field indicates the structure $m$'s type;
620: currently only the type MAIL is generated and understood.
621: The RCV and ORG fields identify the intended recipient of the message
622: and the originator.
623: The IDK field identifies the key-encrypting key, KK,
624: used to encrypt the next two fields.
625: The first KD field has the encrypted authentication key, KA,
626: used to calculate the MIC of the plaintext of the body of the message.
627: After the body of the message is deciphered, $a_{ka}(b)$ is calculated and
628: compared to the value of the MIC field.
629: Hence, the MIC field authenticates the message body.
630: The second KD field has the encrypted data encrypting key, KD,
631: which along with the encrypted initialization vector in the IV field
632: was used to generate the ciphertext of the body.
633: Finally, the MAC field authenticates the $m$ structure itself.
634: The use of a data key, initialization vector, authentication key (KD/IV/KA)
635: triple permits us to perform key distribution in a hierarchical fashion and
636: allows the system to use a KK-relationship over a longer cryptoperiod
637: without fear of compromise.
638:
639: The \TMA/ provides three primary interfaces to a \UA/ to send encrypted mail:
640: the first takes a file-descriptor to a message
641: and returns a structure $g$ (called a {\it group})
642: describing the ciphertext version of the body
643: (this structure contains a KD, IV, and KA generated at random,
644: along with a file-descriptor to the plaintext headers,
645: a file-descriptor to the ciphertext body,
646: and the checksum of the plaintext body);
647: the second takes a user entry (or \MTS/ address) and $g$,
648: and returns a file-descriptor to the encrypted message
649: for that user (or \MTS/ address);
650: the third takes $g$ and performs clean-up operations.
651: The chief advantage to this scheme of encryption
652: is that if the message is to be sent to more than one recipient,
653: then the MIC and the encrypted body need only be calculated once,
654: since the KD, IV, and KA remain constant
655: (only the KK's change with each recipient,
656: hence for each copy of the encrypted message,
657: only the structure $m$ need be re-calculated).
658:
659: There are, however, a few subtleties involved:
660: \underbar{first},
661: the \MTS/ usually accepts only 7--bit characters,
662: so the encrypted text is exploded to consist of only printable characters;%
663: \nfootnote{%
664: As a rule, in all \CSM/s,
665: when encrypted information is transmitted,
666: it is exploded after encryption by the sender,
667: and imploded prior to decryption by the receiver.}
668: \underbar{second},
669: since the \MTS/ may impose limits on the length of a line,
670: each line of output is limited to 64~characters;
671: and,
672: \underbar{third},
673: since the body may require trailing padding,
674: during encryption
675: one last unit of 8~bytes is written (and encrypted),
676: naming the number of characters (presently, nulls) padded in the
677: previous 8~bytes ($0\tdots7$).
678:
679: \subsection{Decrypting Mail}
680: To decipher a message, the method is also straightforward:
681: The headers are output in the clear.
682: The banner string is essentially ignored,
683: and the structure $m$ is consulted to identify the correct key-encrypting key.
684: The \TMA/ checks to see if it knows of that KK.
685: If not, it asks the \KDS/ to supply it.
686: From that point,
687: the KA, KD, and IV are deciphered.
688: The $m$ structure is then authenticated.
689: With the correct key,
690: the remainder of the body is deciphered,
691: and all except for the last 16~bytes are output.
692: The last 8~bytes indicate how many of the previous 8~bytes should be output.
693: So,
694: the appropriate number of bytes is output,
695: and the plaintext body is authenticated and compared to the MIC.
696: Needless to say,
697: as the body is deciphered,
698: it is imploded back to 8--bit characters and lines are restored to their
699: previous lengths.
700: To indicate that the message was correctly deciphered,
701: a new header of the form
702: \example X-KDS-ID: orgid (originator's name)\endexample
703: is appended to the headers of the message.
704: Note that this provides an authentication mechanism.
705: Note, further,
706: that the \UA/ did not have to know the identity of the sender of the message.
707:
708: \section{Modifications to MH}
709: \MH/ is a public domain \UA/ for \unix/,
710: which is widely used in dealing with both a large number of electronic mail
711: application and a large number of messages.
712: Although this document does not intend to describe \MH/,
713: parts of the system are described as they relate to the \TMA/.
714: Readers interested in \MH/ should consult either the user's
715: manual\cite{MRose85a} for a detailed description,
716: or \cite{MRose85d} for a higher-level description.
717:
718: To modify \MH/ in order to make use of a \TMA/,
719: three programs were changed (with a high degree of transparency to the user),
720: and two new programs were introduced.
721:
722: In \MH/,
723: when a user wishes to send a composed draft
724: (which may be an entirely new message,
725: a re-distribution of a message,
726: a forwarding of messages,
727: or a reply to a message),
728: the user invokes the \pgm{send} program.
729: This program performs some minor front-end work for a program called
730: \pgm{post} which actually interacts with the \MTS/.
731: A new option to the \pgm{send} and \pgm{post} programs,
732: the \switch{encrypt} switch,
733: is introduced.
734: If the user indicates
735: \example send\ -encrypt\endexample
736: then \pgm{post} encrypts the messages it sends.
737:
738: When sending an encrypted message,
739: \pgm{post} first checks that each addressee has a mapping to a \KDS/ ID
740: during address verification.
741: Then, instead of batching all addresses for a message in a single posting
742: transaction,
743: for each addressee,
744: \pgm{post} consults the \TMA/ for the appropriately encrypted text and
745: posts that instead.
746: (Appendix~A discusses the reasons for this more fully.)
747: Hence,
748: assuming the user has established mappings between \MTS/ addresses
749: and \KDS/ IDs,
750: the \TMA/ does all the work necessary to encrypt the message,
751: including contacting the \KDS/ as necessary.%
752: \nfootnote{Once the \TMA/ establishes a connection to the \KDS/,
753: it retains that connection until the \UA/ terminates.
754: This is done to minimize connections to the \KDS/.
755: In the context of \MH/,
756: since the trusted mail agent is active over the lifetime of an invocation of
757: a program such as \pgm{post},
758: this means that the connection is terminated just before the program
759: terminates.}
760:
761: In \MH/,
762: when a user is notified that new mail has arrived,
763: the \pgm{inc} program is run.
764: As each message is incorporated into the user's message handling area,
765: a scan (one-line) listing of the message is generated.
766:
767: By default,
768: the \pgm{inc} program upon detecting one or more encrypted messages,
769: after the scanning process,
770: asks the \TMA/ to decipher the message,
771: and if successful,
772: scans the deciphered messages.
773: This action can be inhibited with the \switch{nodecrypt} switch.
774: Hence, if the user wishes to retain messages in encrypted form,
775: \pgm{inc} can be told to note the presence of encrypted messages,
776: but otherwise not to process them.
777: By using the \MH/ user profile mechanism,
778: \pgm{inc} can be easily customized to reflect the user's tastes.
779: Again,
780: the actions of the \TMA/ are transparent to the user.
781: In fact,
782: if encrypted mail is received from users unknown to the \TMA/,
783: it queries the \KDS/ as to their identity prior to retrieving the
784: KK-relationship.
785:
786: If \pgm{inc} fails to decrypt a message for some reason,
787: or if \pgm{inc} was told not to decrypt a message,
788: the \pgm{decipher} program can be used.
789: This simple program merely deciphers each message given in its argument
790: list.
791: The \pgm{decipher} program can be given the \switch{insitu} switch,
792: which directs it to replace the ciphertext version of the message with the
793: plaintext version;
794: or,
795: the \switch{noinsitu} switch can be used indicating that the ciphertext
796: version of the message should be left untouched and the plaintext version
797: should be listed on the standard output.
798:
799: Finally,
800: the \pgm{tma} program is used to manipulate the \TMA/ database,
801: containing commands to boot the database,
802: add new users to the database,
803: and to establish mappings between addresses and users in the \TMA/ database.
804: This program can also be used to disconnect KKs between other \TMA/s,
805: and the KK/KA between itself and the \KDS/.
806:
807: Appendix~A of this paper contains a transcript of an \MH/ session.
808:
809: \section{Remarks}
810: We now consider the merit of the system described.
811: After presenting some of the basic strengths of the system
812: and a few unresolved questions,
813: the discussion centers on the simplifying assumptions made by the system,
814: and how these can be defended in a non-military environment.
815:
816: \subsection{Strengths}
817: It can be argued that the prototype system
818: (and the augmented model in which it finds its basis)
819: present many strengths.
820:
821: Perhaps the most important is the high-level of independence from the \MTS/
822: enjoyed by the system.
823: As a result,
824: since the \TMA/ does not interact directly with the \MTS/,
825: it can be made to be completely free from any \MTS/-specific attributes,
826: such as naming, addressing, and routing conventions.
827: Furthermore,
828: when interfacing a \trustedmail/ system,
829: no modifications need be made to the \MTS/ or local \MTA/.
830:
831: In addition to the systems-level advantage to this scheme,
832: users of the system profit as well,
833: since many disjoint \MTS/s can be employed by a user with a single \TMA/.
834: This reduces the number of weaknesses in the system and allows a user to keep
835: a single database of ``trusted'' correspondents.
836: It should also make analysis and verification of the \TMA/ easier.
837:
838: Of course from the user-viewpoint,
839: once the \TMA/ has been initially booted,
840: all key management is automatic.
841: Not only does this reduce the risk of compromise of cryptographic material
842: (given proper construction and maintenance of the \TMA/),
843: but it relieves the user of a tedious and error-prone task.
844:
845: Finally,
846: although the \KDS/ described herein is used to support \trustedmail/,
847: other applications which require key management,
848: could employ the services offered by the key distribution center.
849:
850: \subsection{Open Questions}
851: At present, there are many restrictions on the prototype implementation
852: described.
853: Some of these result from that fact that the implementation is a prototype
854: and not a production system.
855: Others deal with more fundamental issues.
856:
857: In terms of the \TMA/,
858: the expiration delay for keys is hard-wired in;
859: it should be user-settable.
860: In the prototype version,
861: the KK and KA with the \KDS/ are good for 2~days or 10~uses
862: (whichever comes first),
863: while a KK for use with another \TMA/ is good for 1~day or 5~uses.
864: In actual practice,
865: keys with long cryptoperiods might be good for 6~months or 100~uses,
866: while keys with short cryptoperiods might be good for 1~month or 25~uses.
867: The choice of actual values is an open question
868: beyond the scope of prototype system.%
869: \nfootnote{The current values were chosen by guess work.
870: Although not necessarily technically sound,
871: the small numbers were very good for debugging purposes.}
872: In many respects, this issue is a classic trade-off:
873: with relatively small cryptoperiods,
874: an adversary has less chance of breaking a key,
875: but with longer cryptoperiods less connections have to be made to the key
876: distribution server.
877:
878: A fundamental issue,
879: owing to differences between the EFT and CBMS environments,
880: is that the \KDS/ implements only a subset of the \ansi/ draft
881: and the semantics of certain operations have changed somewhat.
882: It would be nice to unify the CBMS and EFT views
883: of a {\it key distribution center}
884: (in the former environment, the center is called a \KDC/,
885: while in the latter environment, the center is known as a \CKD/).
886: Appendix~C of this paper discusses the differences between the two
887: perspectives in greater detail.
888:
889: At present,
890: the relationship between errors in the \TMA/ and the posting process is an
891: open question.
892: For example,
893: if an address doesn't have a mapping in the \TMA/ database,
894: \pgm{post} treats this as an address verification error.
895: This prevents the draft from being posted.
896: The philosophy of the \UA/ is unclear at this point,
897: with respect to how recovery should occur.
898: A second area, also in question, deals with the way in which plaintext and
899: ciphertext versions of a message are present in a system.
900: Clearly, it is a bad idea to make both versions available,
901: but since the \TMA/ doesn't try to concern itself with first party
902: observation,
903: there seems to be little possibility of preventing this behavior.
904: The best that can be done,
905: at this stage,
906: is simply to choose a consistent policy that user's should attempt to adhere
907: to.
908: The software can help somewhat in implementing this policy,
909: but it certainly can't circumvent the user.
910:
911: The prototype is built on the assumption that a single key
912: distribution server is present.
913: Since the \ansi/ draft\cite{FIKM} makes provisions for
914: {\it key translation centers},
915: the \trustedmail/ prototype should perhaps be made to operate in a more diverse
916: environment.
917: Until the issues become clearer,
918: this remains open.
919:
920: Finally,
921: for distribution lists,
922: a large number of people would need to share the same \KDS/ ID.
923: The current implementation doesn't support this.
924: Each \TMA/ database is for a particular ID.
925: A user with multiple IDs would need multiple databases,
926: or the database should be re-organized.
927:
928: \subsection{Weaknesses}
929: As pointed out earlier,
930: this prototype system situates itself in a commercial, not military,
931: environment.
932: With respect to this decision,
933: several aspects of the system are now discussed,
934: which we feel are acceptable in a commercial environment,
935: but which would be considered weaknesses in a military environment:
936:
937: \item{1.} Traffic Flow\hbreak
938: The prototype \TMA/ makes no attempt whatsoever to prevent or confuse traffic
939: analysis by augmenting traffic flow.
940:
941: \item{2.} The Database of \KDS/ Subscribers\hbreak
942: Since information returned by the request user identification (RUI)
943: and request identified user (RIU) MCLs are returned in the clear,
944: this allows an adversary to ascertain subscribers to the \KDS/,
945: and perhaps deduce some information about the system.
946: Without knowledge of the master key however,
947: an adversary could not impersonate a subscriber though.
948: Still, in the military sense, this is a weakness.
949: However,
950: all this assumes that the database maintained by the \KDS/ accurately
951: reflects the real-world.
952:
953: \item{3.} Multiple Recipients\hbreak
954: It is possible, though not proven to the authors' knowledge,
955: that the scheme used to avoid encrypting the body of a message more than once
956: for multiple recipients might permit one of the recipients who is also an
957: adversary to compromise the key relationship between the sender and another
958: recipient.
959:
960: \item{} The scenario goes like this:
961: When a message is being prepared for encryption,
962: a single KD/IV/KA triple is generated to encrypt the body.
963: Since the sender has a different key relationship with each recipient,
964: each message sent is different, since the structure $m$ depends not only on
965: the KD/IV/KA triple but also on the key relation between the sender and a
966: particular recipient.
967: Now suppose that one of the recipients, $r_1$,
968: in addition to receiving the copy of the message meant for him/her also
969: intercepts a copy of the message destined for another recipient, $r_2$.
970: At this point,
971: the recipient $r_1$ has both the plaintext and ciphertext version of the body,
972: the plaintext version of the KD/IV/KA triple,
973: and the ciphertext version of the KD/IV/KA triple that was generated using
974: the key relationship between the sender and the recipient $r_2$.
975: The question is:
976: can $r_1$ now deduce the key relationship between the sender and $r_2$?
977:
978: \item{} If so, then the way that the \TMA/ attempts to minimize the use of
979: encryption resources is a weakness.
980: But, even if this is possible,
981: given relatively short cryptoperiods for key relationships between \TMA/
982: peers,
983: this becomes a non-problem.
984:
985: \item{4.} Discussion Groups\hbreak
986: As discussed earlier,
987: the proposed method of associating a single \KDS/ ID with the membership of a
988: discussion group does introduce a significant weakness for the security of
989: messages sent to the discussion group.
990: Since the \TMA/ does not assume a general broadcast facility,
991: it appears that there are no good solutions to the problem of discussion
992: group traffic.
993: Of course,
994: it is easy enough to simply send to each member of the group.
995:
996: \item{} For the sake of argument,
997: let's assume that the discussion group has $n$ members.
998: Now,
999: since a different key relationship would exist between the sender and
1000: each of the $n$ recipients,
1001: the structure $m$ would be different for each recipient
1002: and so a different message would have to be sent to each recipient.
1003: To make matters worse,
1004: if one rejects the way the \TMA/ handles multiple recipients,
1005: not only does the \MTS/ get burdened with $n$ different messages,
1006: but the sender's \TMA/ gets burdened by having to encrypt
1007: the body of the message $n$ times.
1008: For meaningful values of $n$ (say on the order of~500, or even~25),
1009: the amount of resources required for any trusted discussion group are simply
1010: too costly.
1011:
1012: \subsection{Compromises, Compromises}
1013: Each of the possible weaknesses discussed above represent a compromise
1014: between the expense of the system and the level of security it can provide.
1015:
1016: The first two areas, if addressed by the \TMA/,
1017: could result in much less background information being available to an
1018: adversary.
1019: In an application where it is important that an adversary not know who is
1020: talking to whom,
1021: or who can talk at all,
1022: this is very important.
1023: It is the authors' position that in the commercial environment,
1024: this issue is not paramount.
1025: By ignoring the issue of traffic flow,
1026: the \TMA/ has a lot less work to do and the \MTS/ is kept clear of
1027: ``useless'' messages.
1028: By keeping the information returned by the RUI and RIU MCLs in the clear,
1029: the complexity of the \TMA/ is significantly reduced.
1030:
1031: The second two areas, if addressed by the \TMA/,
1032: could result in a lesser probability of traffic being deciphered by an
1033: adversary.
1034: Regardless of the application,
1035: this is always extremely important.
1036: However,
1037: the authors' feel that the compromise made by the \TMA/ in these two issues
1038: is not substantial,
1039: and does not result in an explicit weakness when a message is sent to
1040: multiple recipients
1041: (note that when there is only a single recipient of a message,
1042: these two policies can not introduce weaknesses).
1043: In return, efficient use can be made of both the \MTS/ and the \TMA/ when
1044: messages are being sent to multiple recipients.
1045: Given scarce resources or large numbers of recipients,
1046: this approach may prove to be quite winning.
1047:
1048: Of course, much work remains to be done to prove the success of the \TMA/ in
1049: all four of these areas.
1050:
1051: \section{Acknowledgements}
1052: The prototype implementation described herein utilizes a public domain
1053: implementation of the DES algorithm\cite{DEA}
1054: which was originally implemented by James J.~Gillogly in May, 1977
1055: (who at that time was with the Rand Corporation,
1056: and is now affiliated with Gillogly Software).
1057: Interfaces to Dr.~Gillogly's implementation were subsequently coded by
1058: Richard W.~Outerbridge in September, 1984
1059: (who at that time was with the Computer Systems Research Institute
1060: at the University of Toronto,
1061: and is now affiliated with Perle Systems, Incorporated).
1062:
1063: The authors would like to acknowledge Dennis Branstad,
1064: Elaine Barker, and David Balensen of the National Bureau of Standards
1065: for their comments on the prototype system
1066: and insights on the ANSI draft\cite{FIKM}.
1067: In particular, Dr.~Branstad originally suggested the method used for
1068: encrypting a single message for multiple recipients under different keys.
1069:
1070: The authors (and all those who have read this paper) would like to thank
1071: Willis H.~Ware of the Rand Corporation,
1072: and Jonathon B.~Postel of the USC/Information Sciences Institute.
1073: Their extensive comments resulted in a much more readable paper.
1074: In addition,
1075: the authors would like to thank
1076: Dr. Stephen P.~Smith and Major Douglas A.~Brothers
1077: for their insightful comments.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.