The following paper was originally published in the

Proceedings of the Fifth USENIX UNIX Security Symposium

Salt Lake City, Utah, June 1995.

MIME Object Security Services:

Issues in a Multi-User Environment

James M. Galvin and Mark S. Feldman

Trusted Information Systems

For more information about USENIX Association contact:

1. Phone: 510 528-8649
2. FAX: 510 548-5738
3. Email: [email protected]
4. WWW URL: http://www.usenix.org
 MIME Object Security Services: Issues in a Multi-User Environment
James M. Galvin <[email protected]>
Trusted Information Systems

Mark S. Feldman <[email protected]>

Trusted Information Systems

functionality required to be enforced by PEM. It also

1. Introduction provides more functionality than PEM, including some
that PEM could never provide.
An Internet email message consists of two parts: the
headers and the body. The format of the headers and The popularity of the MIME protocol continues to
how they should be interpreted is described in increase. There are several publicly available
RFC822 [1]. The body is text under the user’s control implementations for various hardware/software
and is not changed during normal mail transport. platforms and a few off-the-shelf products. In addition,
the need for secure electronic communications is
Privacy Enhanced Mail (PEM) [2,3,4,5] was the first
paramount, and PEM is not meeting the needs of the
Internet standard to address security in email messages.
user community. The security multiparts framework
It adds structure to message bodies to provide digital
and MOSS are a natural evolution of the state-of-the-art.
signature and encryption to text-based email messages.
It uses a certificate-based key management system, However, it is not enough for vendors to implement
based on the X.509 [6] standard. MOSS. A MOSS implementation must address the
protection of the public/private key pairs used by the
Multipurpose Internet Mail Extensions (MIME) [7]
protocol. The MOSS specification includes a
was developed to provide for multi-part textual and non-
description of the issues that must be addressed but does
textual email message bodies. It defines a structure for
not provide specific solutions. Following a brief
the format of the body. However, until recently, MIME
summary of the protocol, the next section discusses the
did not include support for security services.
protection of the public/private key pairs and proposes a
A specification has been proposed that defines a software-based solution. This solution is applicable to
framework for digitally signing and encrypting MIME other protocols.
objects: Security Multiparts for MIME [8]. The
framework provides an embodiment of a MIME object
2. MOSS Protocol
and its digital signature or encryption key. It was
designed to be useful by a variety of security protocols. The basic operation of a single application of the
MOSS protocol is to input a MIME object and to
The MOSS protocol [9] is a derivative of PEM.
output a MIME object. The input object may be any
Although a MIME message could carry a PEM object
valid MIME object, including an output object from a
or a PEM message could carry a MIME object, a better
previous application of the MOSS protocol. The
solution is to combine the features of both and provide
output object is an embodiment of the input object and
a single, uniform solution in which the protocols
the control information that specifies which security
function in a complementary fashion. MOSS is just
service was applied to the object. This embodiment
such a solution.
may be conveyed to a recipient or archived for later use
MOSS enhances the MIME protocol without changing by its originator. An overview and some details about
its currently supported functions or features. It uses the each of the security services is described below.
security multiparts framework to provide digital
The MOSS protocol is independent of the cryptographic
signature and encryption protection to single- and multi-
algorithm used in support of its security services. The
part textual and non-textual MIME objects. MOSS
current specification includes recommended choices to
expects MIME objects as input and outputs MIME
facilitate interoperability. If other choices are desired,
objects.
the required features of the algorithms needed are
MOSS is PEM insofar as it supports all of the specified.
functionality and features included in the PEM protocol.
However, MOSS does not enforce some of the
2. 1 Overview enhanced to include this, MOSS inherits the
characteristic from MIME.
The two possible embodiments output by the MOSS
protocol are defined by the security multiparts
framework. When a digital signature is applied to a 2. 2 Digital Signature
MIME object the multipart/signed content type is used. The MOSS protocol supports the application of a
When encryption is applied the multipart/encrypted digital signature by hashing the MIME object to be
content type is used. Each of these content types is digitally signed and encrypting the hash value with a
comprised of two nested objects: one for the MOSS private key of an originator. A set of header/value pairs
control information and one for the protected MIME is created, formatted according to RFC822, and, where
object. The content of each of these is described in the header names match header names used by PEM, the
succeeding sections. values are set exactly as they are for PEM. In addition
The MOSS protocol assumes that there exists a to other management information, the signature
public/private key pair for the originator applying the (encrypted hash value) is included in the set of headers.
digital signature. When encryption is applied, the Prior to hashing the MIME object to be signed, the
MOSS protocol assumes that there exists a public key object must be represented in 7bit MIME canonical
for each recipient. Specifically, although the MOSS format. This guarantees both that a forwardable
specification acknowledges the importance of validating authentication service is always available and that the
the public keys used and evaluating the degree to which object is uniquely and unambiguously represented on all
private keys are protected from disclosure, the issues are hardware/software platforms.
considered independent topics and not addressed.
The MOSS headers created are inserted in the control
MOSS differs from PEM in this respect since PEM information body part of the enclosing multipart/signed
requires that public keys be embodied in certificates that content; the signed MIME object is inserted in the other
are managed by the Internet Certification Hierarchy body part and labeled according to its actual type.
defined in RFC1422. MOSS, in addition to supporting
certificates, has the advantage of supporting bare The digital signature is verified by the recipient as
public/private key pairs. This makes the protocol follows.
immediately usable by individuals and small 1. The received signed object is canonicalized.
communities of cooperating users.
2. The hash value of the canonical object is re-
Since the MOSS protocol uses the security multiparts computed.
framework, it can and does take advantage of the
recursive characteristic of MIME. A MIME object can 3. The encrypted hash value found in the control
have either a digital signature or encryption applied to it information is decrypted with the originator’s public
or, if it has already had one applied to it, can have key.
another applied by simply using the output object of 4. The re-computed value is compared to the decrypted
the previous application as the input object to the next value. If the values are equal and the correct public
application of the MOSS protocol. In the case of key is used, the signature is valid.
encryption, this allows it to be used by itself, in partial
support of encrypted anonymous email.1 It also allows Determining whether the correct public key has been
different protection to be applied to different parts of the used is essential to the validation of the digital
email message, in arbitrarily complex ways. signature. A complete discussion of the issues is
beyond the scope of this paper but may be found
Here again, MOSS differs from PEM, since PEM in [10].
requires that encrypted objects be signed. Also, PEM
does not currently specify how to recursively apply its 2. 3 Encryption
services. Although the PEM specifications could be
The MOSS protocol supports encryption by generating
a new encryption key for each MIME object to be
1 encrypted and encrypting the object with it. The
The issue is the headers of the email message typically
provide at least a hint of the origin of the message. So,
encryption key is then encrypted with the public key of
while the source of the encrypted MIME object can be the recipient(s) for whom the object is intended,
anonymous, the source of the message in which it appears including the originator if that is desired. A set of
may not be. header/value pairs is created, formatted according to
RFC822, and, where the header names match header With respect to public keys, a user labels the public
names used by PEM, the values are set exactly as they keys owned by other users with their identity. The
are for PEM. In addition to other management principal issue is preventing modification of the binding
information, the encrypted encryption key is included in between the public key and the identity of its owner. If
the set of headers. an adversary could modify the binding, a recipient would
incorrectly believe the indicated origin of a signed object
The MOSS headers created are inserted in the control
or an originator would unintentionally encrypt a
information body part of the enclosing
message for the wrong recipient, probably the adversary.
multipart/encrypted content; the encrypted MIME object
When a binding is compromised, no security is
is inserted in the other body part and labeled
available between the local user and the owner indicated
application/octet-stream.
by the previously valid binding.
A recipient decrypts an encrypted object by obtaining
Finally, a MOSS implementation must have access to
the encrypted encryption key from the control
a source of randomness, more precisely a source of
information, decrypting it with the recipient’s private
unpredictable bits. The unpredictable bits are required
key, decrypting the MIME object with the decrypted
when generating public/private key pairs for users and
encryption key, and processing the output of the
when generating encryption keys for sending encrypted
decryption as a MIME object.
messages. As many as several thousand bits may be
required each time they are needed. Without hardware
3. Non-Protocol Issues support, the bits can be difficult to obtain [11].
There are three issues not specifically addressed by the There are many solutions for these issues, including
MOSS protocol specification that are important to any hardware, software, and hybrid approaches. In this paper
implementation.2 These issues relate to the security of we consider only software solutions for several reasons.
local information. In a single-user environment, a user First, software solutions are applicable to a broader
controls the physical access to the computer. As a range of environments. Any changes required for a new
result, the user may not be concerned about what others environment can usually be completed quickly and
may do to or with the information on the computer. easily. Second, software solutions are quick and easy to
However, a user should still employ additional install, since they do not require any specialized
protection in case physical security is lost. hardware or other computing resources. Third, software
solutions are typically less expensive than alternate per-
However, in a multi-user environment, users must be
host or per-user hardware solutions.
concerned about both the integrity and the privacy of
their information beyond physical security. In order to
apply the MOSS protocol, an implementation must be 3. 1 Protection of Private Keys
able to access two kinds of information: private keys If private keys are kept on-line, they are vulnerable to
and public keys. The private keys are needed to access by unauthorized users. File permissions alone
digitally sign MIME objects and to decrypt the are not adequate for protecting private keys on most
encryption keys of encrypted MIME objects. The systems, though they are part of an overall solution.
public keys are needed to verify digital signatures and to Private keys protected only by file permissions are
encrypt the encryption keys of encrypted MIME objects. vulnerable to account intruders and the accidental mis-
With respect to private keys, the principal issue for a setting of the file permissions.
user is preventing the disclosure of the private key to One solution is store the private key in a file on a
others. If an adversary learns the user’s private key, removable media, e.g., a diskette. Since diskette drives
they would be able to sign MIME objects and make it are typically included with most hardware
appear as if the user had signed the object. In addition, configurations, the user is not burdened with a
the adversary would be able to read MIME objects significant additional cost. However, if the diskette is
encrypted for the user. When a user’s private key is lost or otherwise not physically protected, the private
disclosed, no security is available to the user with that key is still vulnerable.
public/private key pair.
Encryption is an accepted solution for protecting
information from disclosure. However, encryption also
2
One issue explicitly not addressed at this time is the requires access to a key that must be protected from
vulnerability of the software to Trojan horses. This paper disclosure.
assumes root is not hostile.
A solution to this problem is to derive the encryption MOSS specification, a user must determine that all
key needed to encrypt the private key from easily public keys received actually belong to the user to
available information. This process is straightforward whom they purport to belong. The first time this
for secret key algorithms, while no similar solution has validation process is completed is expensive, since it
been proposed for public key algorithms. may involve an out-of-band communication with the
owner of the public key. Thus, upon completion of
The recommended advice is to make the easily available
this process, the user may choose to store the results
information a passphrase selected by the user. A
with the public key in the database. However, if the
passphrase is different from a password in that no
database is kept on-line, it is vulnerable to modification
restrictions are placed on its length or value. This
by other users.
accomplishes two important features. First, the domain
from which the passphrase is chosen is limited only by Digitally signing entries in a local database allows a
the input device used by the user. Second, the user can user to keep the public keys on-line and to be able to
select an easily remembered value, e.g., a favorite detect if a binding has been modified. Whenever the
quotation or other concatenation of many easily public key is needed the signature would be verified
remembered words. Whenever the private key is needed, first, thus guaranteeing that the binding of the public
the user enters the passphrase, the encryption key is key and its name has not been modified since it was
derived, the private key is decrypted, and then the private stored.
key is available for use.
It should be noted that the above protection is useful
The combination of file permissions and encryption even if the public keys are distributed in certificates.
provides effective non-disclosure protection to a user’s For those correspondents using certificates that are part
private key, if the user chooses an appropriate of a hierarchy and not just bare public keys, the user
passphrase. Better protection is provided if the file could validate the certificate the first time it is received
containing the encrypted private key is stored on a and store the result with the certificate, digitally signing
removable media, e.g., a diskette. all the information in the entry in the local database.
This would enhance the performance of an
3. 2 Protection of Public Keys implementation since it may not be necessary to
complete the entire certificate validation each time it is
There are two issues relevant to the protection of public accessed.
keys. The first is establishing the identity of the owner
of the public key and the second is protecting the 3. 3 Unpredictable Bits
binding of the identity and the public key.
The ready availability of a sequence of unpredictable
With respect to the first (establishing the identity), an
bits, which are distinct from random bits, is absolutely
issue that is beyond the scope of this paper is exactly
essential to the generation of public/private key pairs
what constitutes an identity. A discussion of this issue
and encryption keys. Randomness is a statistical
can be found in [10]. In addition, an originator needs a
property of a sequence of values. The requirement is for
mechanism with which an identity and a public key
an adversary to be unable to predict the next bit in a
may be conveyed to recipients for storage in the
sequence even when all previous bits are known.
recipients’ local databases. The MOSS protocol
Pseudo-random number generators rarely include this
includes a specification for just such a mechanism, that
absolutely essential property.
is not described here.
The problem is if it is possible to predict some of the
With respect to the second (protecting the binding), the
sequence of bits used, it may be possible to reduce the
recommended solution is to create a cryptographic
size of the domain from which the key being generated
binding between the public key and the identity. Since
is selected. If the domain is significantly reduced, an
the MOSS protocol works with bare public/private key
exhaustive search of the domain for the key may be
pairs, the most basic solution is for each user to
possible.
digitally sign entries in their own local databases. This
reduces the problem of protecting public keys to the Locating a source of unpredictable bits presents a unique
problem of protecting private keys. problem on multi-user systems (and most single-user
systems for that matter). Typically, a hardware source
Preventing the modification of the binding between
of unpredictable bits is not included with most system
public keys and identities is essential to the correct
configurations. Although most computer systems
operation of the MOSS protocol. As indicated in the
include applications that will display the always
changing status of the local system, the unpredictability for bit flags that indicate if the private key is encrypted
of these bits is limited, especially on a lightly loaded and the algorithm with which it is encrypted.
system on which an adversary has access to the local
The next 16 octets are a hash of the private key with the
system around the same time that the keys are being
remaining octets comprising the ASN.1 encoding of the
generated.
private key. Encrypting the private key entails
The most effective software-based solution currently encrypting the octets of the hash and the encoded private
available is to hash with a cryptographically strong one- key.
way hash function the largest quantity of information
The hash in the file is used as an integrity check of the
with limited unpredictability available. Since a hash
private key’s value. This is most useful when the
typically generates a fixed size quantity, the process is
private key has been encrypted. Checking the hash
iterated as many times as are necessary to get the
value after decrypting the file contents provides a fast
required number of unpredictable bits.
mechanism for determining if the correct passphrase was
provided from which to derive the encryption key.
4. Implementation Without the hash value, the only mechanism by which
the private key’s value can be checked would be to use
Trusted Information Systems (TIS) has been developing
it and see if it works. This typically causes an incorrect
an openly available implementation of the MOSS
failure condition to be reported to the user. TIS/MOSS
protocol (TIS/MOSS) [12]. It is software-based and
uses the MD5 [13] hash algorithm for this check.
includes all of the solutions proposed here. In
particular, the private keys are each stored in their own
binary file while all other information, including the 4. 2 Public Keys
public keys, is stored in a flat ASCII file. A sequence Except for the private keys themselves, all information
of unpredictable bits is obtained by hashing system needed by MOSS is stored in a flat ASCII file, called
status information. the MOSS database. The permissions on the database
file should be such that only the user owning the file
4. 1 Private Keys can make changes. The database may be left readable by
other users if it is desirable to share it. The user may
Each of a user’s private keys is stored in its own file
have multiple databases and may choose the location of
with permissions that are initially created to allow only
each database. The default is a single database in the
the user to read and write the file. The location of the
file “.mossdb” in the user’s home directory.
private key files is up to the user, with the default being
the user’s home directory. Private key files can be The database is organized as a set of user records
placed on removable media by simply including the separated by a blank line. Each user record is organized
device specification in the filename. as a set of tag/value pairs, which conform to the
RFC822 header syntax. This format is extensible and
A user may optionally encrypt the private key in the
easily processed using many tools.
file. If it is encrypted, the user must input the
passphrase used to derive the encryption key every time The tags described in this paper are those necessary for
the private key is accessed; the software retains the implementing local security. TIS/MOSS makes use of
decrypted private key for as short a time period as many other tags and silently ignores all unrecognized
possible. tags and their values.
From a security perspective, this is the optimal Within a user record, all tags except the “public-key:”
behavior. However, users quickly become irritated if tag are optional but, if present and needed, their values
they send or receive more than a few messages in a will be used. All tags except the “alias:” tag must be
short time frame. As a result, TIS/MOSS includes a unique. If multiple tags are present, all except the first
feature that allows users to choose usability over are silently ignored.
security. A pair of programs, mosslogin and
The “public-key:” tag is required to be present in each
mosslogout, is included with which users may enter
user record and its value must be unique with respect to
their passphrase once for a timeframe they choose.
all other public key values in the database. User records
Each file is formatted as a sequence of octets, with the without this tag are silently ignored. Its value is the
first octet excluded from any encryption that may be base64 encoded, ASN.1 encoded public key.
used to protect the private key. The first octet is used
The “alias:” tag is a grouping mechanism. Its value is hash of a seed. The seed is incremented and hashed
a string. It provides a convenient way of addressing iteratively to produce the necessary amount of
multiple recipients, for example when sending an unpredictable bits. The seed is initialized in one of two
encrypted message. Aliases can be unique to a single ways depending on how the unpredictable bits will be
user record in the database or the same alias may appear used.
in several user records. A single user record may
If the unpredictable bits are being used to generate a
contain multiple “alias:” tags, with some aliases that
public/private key pair, the seed is based on the hashing
are unique to it and others that are not.
of the output of a large number of system commands.
A local name may be bound to a public key by The system commands included were chosen because
selecting a string and placing it in an “alias:” tag in the their output has the greatest probability of being
user record. Its value is arbitrary from the point of view different across multiple executions and hard to guess.
of TIS/MOSS; the value is always used exactly as it This can be time consuming, but it is an infrequent
appears in the database. TIS/MOSS also uses the first operation and public/private key pair generation is
“alias:” tag in a user record for display purposes, already slow, so the additional time is inconsequential.
providing a convenient way for a user to specify a local,
It is essential that only commands that are likely to
short handle for a public key.
produce unpredictable output be included. On multi-
A “trusted:” tag is the mechanism with which a user user systems, no special privileges are needed for
creates a cryptographic embodiment for each user record another user to execute the same set of commands at
in the user’s database, including the public key and the approximately the same time and possibly aid an
local identity specified in the “alias:” tag. The user exhaustive search of the key space. This is especially
record is canonicalized and a digital signature is created. important on a lightly loaded system, since otherwise
The digital signature and the alias of the user that the output is almost certain to be unpredictable for most
created it are stored as the value of a “trusted:” tag in the if not all of the commands.
user record. A user may create their embodiment by
When unpredictable bits are required for purposes other
adding their own digital signature to user records or the
than generating public/private key pairs, a faster method
user may use the digital signature created by another
of seeding the PRNG is used that makes use of the
user.
unpredictability inherent in the private key. When
Whenever a “trusted:” tag is found in a user record, the unpredictable bits are required for per-message keys or
digital signature is validated before the information in padding, a value is signed using an existing private key
the record is used. This protects all information in the to produce the seed. The value being signed need not be
user record from modification. TIS/MOSS always unpredictable, but it must be unique. Signing a unique
indicates to a user whether the public keys used came value produces a value that is unpredictable to anyone
from trusted or untrusted user records. without the private key used to generate the signature.
The uniqueness of the value to be signed is guaranteed
4. 3 Unpredictable Bits by concatenating values that are specific to a certain
Unpredictable bits are required for key generation and for time, a certain machine, a certain user, and a certain
padding certain cryptographic values. The largest process. The concatenated values are obtained from
amount of unpredictable bits is required when system calls. The combination of the system calls and
public/private key pairs are generated. Since the signature are guaranteed to produce a seed with at
public/private key pair generation is relatively least as much unpredictability as that in the private key
infrequent and all MOSS security is based on the non- and in much less time than the method used to generate
disclosure of the private key, the cost associated with unpredictable bits for public/private key pair generation.
generating the unpredictable bits may be allowed to be
quite large. When generating unpredictable bits on a 5. Conclusions
per-message basis for encryption keys and padding, the
same high-cost method of generating unpredictable bits Software-based solutions have been proposed for
used when generating public/private key pairs proves to creating and protecting the signature and encryption
be too expensive. keys used in MOSS. The proposals have been
implemented, tested, and found to provide effective
The required number of unpredictable bits in TIS/MOSS protection against various disclosure and modification
is produced by a cryptographically-strong pseudo- threats.
random number generator (PRNG) based on the MD5
The software-based solution proposed for obtaining a [7] Nathaniel Borenstein and Ned Freed. MIME
sequence of unpredictable bits has served the TIS/MOSS (Multipurpose Internet Mail Extensions) Part One:
implementation (and prior to this the TIS/PEM Mechanisms for Specifying and Describing the
implementation) for more than two years. Prior to that Format of Internet Message Bodies. RFC1521,
several alternatives methods were tried that failed. Bellcore and Innosoft, September 1993. Obsoletes
Ideally, the best solution is for hardware manufacturers RFC1341.
to include a source of unpredictable bits in all
[8] James Galvin, Sandy Murphy, Steve Crocker, and
configurations. The importance of unpredictable values
Ned Freed. Security Multiparts for MIME:
must not be underestimated.
Multipart/Signed and Multipart/Encrypted. Trusted
The MOSS protocol, in conjunction with MIME, Information Systems and Innosoft. Work in
provides a flexible, extensible means by which the progress.
addition of security services can be studied. While
[9] Jim Galvin, Sandy Murphy, Steve Crocker, and
software-based solutions may be sufficient for many
Ned Freed. MIME Object Security Services.
applications today, future work must include the study
Trusted Information Systems and Innosoft. Work
and implementation of hardware- and hybrid-based
in progress.
solutions. TIS has begun experimenting with hardware-
based cryptography and private key storage. TIS/MOSS [10] James Galvin and Sandra Murphy. Using Public
has been modified to integrate an experimental Key Cryptography: Issues of Binding and
PCMCIA-based cryptographic engine. Protection. To be published, INET’95.
In addition, future work must include the study of the [11] Donald Eastlake, Steve Crocker, Jeff Schiller.
use of trusted systems for secure email applications. Randomness Recommendations for Security.
Trusted systems can protect private keys from disclosure RFC1750, DEC, Trusted Information Systems, and
without the use of encryption. They also provide MIT, December 1994.
protection from Trojan horses and hostile roots.
[12] Available via anonymous FTP from the host
ftp.tis.com. Users should retrieve the file
6. References /pub/MOSS/README for details.
[1] David H. Crocker. Standard for the Format of [13] Ron Rivest. The MD5 Message Digest
ARPA Internet Text Messages. RFC822, Algorithm. RFC1321, April 1992.
University of Delaware, August 1982.
[2] John Linn. Privacy Enhancement for Internet
Electronic Mail: Part I: Message Encryption and
Authentication Procedures. RFC1421, February
1993. Obsoletes RFC1113.
[3] Steve Kent. Privacy Enhancement for Internet
Electronic Mail: Part II: Certificate-Based Key
Management. RFC1422, BBN Communications,
February 1993. Obsoletes RFC1114.
[4] David M. Balenson. Privacy Enhancement for
Internet Electronic Mail: Part III: Algorithms,
Modes, and Identifiers. RFC1423, Trusted
Information Systems, February 1993. Obsoletes
RFC1115.
[5] Burton S. Kaliski. Privacy Enhancement for
Internet Electronic Mail: Part IV: Key Certification
and Related Services. RFC1424, RSA
Laboratories, February 1993.
[6] The Directory—Authentication Framework:
X.509, 1993. Developed in collaboration and
technically aligned with ISO 9594-8.