Secure E-Mail
The final control we consider
in depth is secure e-mail. Think about how much you use e-mail and how much you
rely on the accuracy of its contents. How would you react if you received a
message from your instructor saying that because you had done so well in your
course so far, you were excused from doing any further work in it? What if that
message were a joke from a classmate? We rely on e-mail's confidentiality and
integrity for sensitive and important communications, even though ordinary
e-mail has almost no confidentiality or integrity. In this section we
investigate how to add confidentiality and integrity protection to ordinary
e-mail.
Security for E-mail
E-mail is vital for today's
commerce, as well a convenient medium for communications among ordinary users.
But, as we noted earlier, e-mail is very public, exposed at every point from
the sender's workstation to the recipient's screen. Just as you would not put
sensitive or private thoughts on a postcard, you must also acknowledge that
e-mail messages are exposed and available for others to read.
Sometimes we would like
e-mail to be more secure. To define and implement a more secure form, we begin
by examining the exposures of ordinary e-mail.
Threats to E-mail
Consider threats to
electronic mail:
message interception
(confidentiality)
message interception (blocked
delivery)
message interception and
subsequent replay
message content modification
message origin modification
message content forgery by
outsider
message origin forgery by
outsider
message content forgery by
recipient
message origin forgery by
recipient
denial of message
transmission
Confidentiality and content
forgery are often handled by encryption. Encryption can also help in a defense
against replay, although we would also have to use a protocol in which each
message contains something unique that is encrypted. Symmetric encryption
cannot protect against forgery by a recipient, since both sender and recipient
share a common key; however, public key schemes can let a recipient decrypt but
not encrypt. Because of lack of control over the middle points of a network, senders
or receivers generally cannot protect against blocked delivery.
Requirements and Solutions
If we were to make a list of
the requirements for secure e-mail, our wish list would include the following
protections.
message confidentiality (the message is not exposed en route to the
receiver)
message integrity (what the
receiver sees is what was sent)
sender authenticity (the receiver is confident who the sender was)
nonrepudiation (the sender cannot deny having sent the message)
Not all these qualities are
needed for every message, but an ideal secure e-mail package would allow these
capabilities to be invoked selectively.
Designs
The standard for encrypted
e-mail was developed by the Internet Society, through its architecture board
(IAB) and research (IRTF) and engineering (IETF) task forces. The encrypted
e-mail protocols are documented as an Internet standard in documents 1421,
1422, 1423, and 1424 [LIN93, KEN93, BAL93,
KAL93a]. This standard is actually the
third refinement of the original specification.
One of the design goals for
encrypted e-mail was allowing security-enhanced messages to travel as ordinary
messages through the existing Internet e-mail system. This requirement ensures
that the large existing e-mail network would not require change to accommodate
security. Thus, all protection occurs within the body of a message.
Confidentiality
Because the protection has
several aspects, we begin our description of them by looking first at how to
provide confidentiality enhancements. The sender chooses a (random) symmetric
algorithm encryption key. Then, the sender encrypts a copy of the entire
message to be transmitted, including FROM:, TO:, SUBJECT:, and DATE: headers.
Next, the sender prepends plaintext headers. For key management, the sender
encrypts the message key under the recipient's public key, and attaches that to
the message as well. The process of creating an encrypted e-mail message is
shown in Figure 7-43.
Encryption can potentially
yield any string as output. Many e-mail handlers expect that message traffic
will not contain characters other than the normal printable characters. Network
e-mail handlers use unprintable characters as control signals in the traffic
stream. To avoid problems in transmission, encrypted e- mail converts the
entire ciphertext message to printable characters. An example of an encrypted
e-mail message is shown in Figure 7-44.
Notice the three portions: an external (plaintext) header, a section by which
the message encryption key can be transferred, and the encrypted message
itself. (The encryption is shown with shading.)
The encrypted e-mail standard
works most easily as just described, using both symmetric and asymmetric
encryption. The standard is also defined for symmetric encryption only: To use
symmetric encryption, the sender and receiver must have previously established
a shared secret encryption key. The processing type ("Proc-Type")
field tells what privacy enhancement services have been applied. In the data
exchange key field ("DEK-Info"), the kind of key exchange (symmetric
or asymmetric) is shown. The key exchange ("Key-Info") field contains
the message encryption key, encrypted under this shared encryption key. The
field also identifies the originator (sender) so that the receiver can
determine which shared symmetric key was used. If the key exchange technique
were to use asymmetric encryption, the key exchange field would contain the message
encryption field, encrypted under the recipient's public key. Also included
could be the sender's certificate (used for determining authenticity and for
generating replies).
The encrypted e-mail standard
supports multiple encryption algorithms, using popular algorithms such as DES,
triple DES, and AES for message confidentiality, and RSA and DiffieHellman for
key exchange.
Other Security Features
In addition to
confidentiality, we may want various forms of integrity for secure e-mail.
Encrypted e-mail messages
always carry a digital signature, so the authenticity and nonrepudiability of
the sender is assured. The integrity is also assured because of a hash function
(called a message integrity check,
or MIC) in the digital signature. Optionally, encrypted e-mail messages can be
encrypted for confidentiality.
Notice in Figure 7 -44 that the header inside the message
(in the encrypted portion) differs from that outside. A sender's identity or
the actual subject of a message can be concealed within the encrypted portion.
The encrypted e-mail
processing can integrate with ordinary e-mail packages, so a person can send
both enhanced and nonenhanced messages, as shown in Figure
7-45. If the sender decides to add enhancements, an extra bit of
encrypted e-mail processing is invoked on the sender's end; the receiver must
also remove the enhancements. But without enhancements, messages flow through
the mail handlers as usual.
S/MIME (discussed later in
this section) can accommodate the exchange of other than just text messages:
support for voice, graphics, video, and other kinds of complex message parts.
Encryption for Secure E-mail
The major problem with
encrypted e-mail is key management. The certificate scheme described in Chapter 2 is excellent for exchanging keys and
for associating an identity with a public encryption key. The difficulty with
certificates is building the hierarchy. Many organizations have hierarchical
structures. The encrypted e-mail dilemma is moving beyond the single
organization to an interorganizational hierarchy. Precisely because of the
problem of imposing a hierarchy on a nonhierarchical world, PGP was developed
as a simpler form of encrypted e-mail.
Encrypted e-mail provides
strong end -to-end security for electronic mail. Triple DES, AES, and RSA
cryptography are quite strong, especially if RSA is used with a long bit key
(1024 bits or more). The vulnerabilities remaining with encrypted e-mail come
from the points not covered: the endpoints. An attacker with access could subvert a
sender's or receiver's machine, modifying the code that does the privacy
enhancements or arranging to leak a cryptographic key.
Example Secure E-mail Systems
Encrypted e-mail programs are
available from many sources. Several universities (including Cambridge
University in England and The University of Michigan in the United States) and
companies (BBN, RSA-DSI, and Trusted Information Systems) have developed either
prototype or commercial versions of encrypted e-mail.
PGP
PGP stands for Pretty Good
Privacy. It was invented by Phil Zimmerman in 1991. Originally a free package,
it became a commercial product after being bought by Network Associates in
1996. A freeware version is still available. PGP is widely available, both in
commercial versions and freeware, and it is heavily used by individuals
exchanging private e-mail.
PGP addresses the key
distribution problem with what is called a "ring of trust" or a
user's "keyring." One user directly gives a public key to another, or
the second user fetches the first's public key from a server. Some people
include their PGP public keys at the bottom of e-mail messages. And one person
can give a second person's key to a third (and a fourth, and so on). Thus, the
key association problem becomes one of caveat emptor: "Let the buyer beware."
If I am reasonably confident that an e-mail message really comes from you and
has not been tampered with, I will use your attached public key. If I trust
you, I may also trust the keys you give me for other people. The model breaks
down intellectually when you give me all the keys you received from people, who
in turn gave you all the keys they got from still other people, who gave them
all their keys, and so forth.
You sign each key you give
me. The keys you give me may also have been signed by other people. I decide to
trust the veracity of a key-and-identity combination, based on who signed the
key.
PGP does not mandate a policy
for establishing trust. Rather, each user is free to decide how much to trust
each key received.
The PGP processing performs
some or all of the following actions, depending on whether confidentiality,
integrity, authenticity, or some combination of these is selected:
Create a random session key
for a symmetric algorithm.
Encrypt the message, using
the session key (for message confidentiality).
Encrypt the session key under
the recipient's public key.
Generate a message digest or
hash of the message; sign the hash by encrypting it with the sender's private
key (for message integrity and authenticity).
Attach the encrypted session
key to the encrypted message and digest.
Transmit the message to the
recipient.
The recipient reverses these
steps to retrieve and validate the message content.
S/MIME
An Internet standard governs
how e-mail is sent and received. The general MIME specification defines the
format and handling of e-mail attachments. S/MIME
(Secure Multipurpose Internet Mail Extensions) is the Internet standard for
secure e-mail attachments.
S/MIME is very much like PGP
and its predecessors, PEM (Privacy-Enhanced Mail) and RIPEM. The Internet
standards documents defining S/MIME (version 3) are described in [HOU99] and [RAM99].
S/MIME has been adopted in commercial e-mail packages, such as Eudora and
Microsoft Outlook.
The principal difference
between S/MIME and PGP is the method of key exchange. Basic PGP depends on each
user's exchanging keys with all potential recipients and establishing a ring of
trusted recipients; it also requires establishing a degree of trust in the
authenticity of the keys for those recipients. S/MIME uses hierarchically
validated certificates, usually represented in X.509 format, for key exchange.
Thus, with S/MIME, the sender and recipient do not need to have exchanged keys
in advance as long as they have a common certifier they both trust.
S/MIME works with a variety
of cryptographic algorithms, such as DES, AES, and RC2 for symmetric
encryption.
S/MIME performs security
transformations very similar to those for PGP. PGP was originally designed for
plaintext messages, but S/MIME handles (secures) all sorts of attachments, such
as data files (for example, spreadsheets, graphics, presentations, movies, and
sound). Because it is integrated into many commercial e-mail packages, S/MIME
is likely to dominate the secure e-mail market.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.