Analysis of Secure Electronic Mail
by Daniel Digeratu
Abstract
The privacy of an e-mail message in transit can be protected using end-to-end cryptography. The standard security services and the main secure e-mail systems are presented; the missing services, and the limitations of current systems are also pointed out.
Table of Contents
1. Introduction
2. Security services
2.1 Content Confidentiality
2.2 Message Origin Authentication
2.3 Content Integrity
2.4 Non-repudiation
3. Public key management
4. Products
4.1 Pretty Good Privacy
- PGP
4.2 PEM ,MIME and MOSS
4.3 Comparison of products
5. Weaknesses in the Design of Secure Systems
5.1 Missing Architecture and
Services
5.2 Threats Outside E-mail
6. Other Issues
7. Conclusions
This paper is about secure e-mail, how the privacy of a message in transit
can be protected. The aim of the paper is on two sides:
a) to present current secure e-mail systems and standards
they are based on.
b) critical discussion on the subject.
The first part of the paper introduces security services of the real world, as well as those defined in standards. Public key management is shortly described. Then, current systems are presented. These include Pretty Good Privacy (PGP), a widely-used public key encryption package; and implementations of the Privacy Enhanced Mail (PEM) standard, MIME, and its successor, MIME Object Security Services (MOSS). Their fundamental ideas, and use in e-mail are compared.
After the facts, the paper concentrates on open issues related to this topic. The limitations of the current systems and missing security services are pointed out.
First of all, it should be noted that most security services discussed herein are not e-mail specific; for example, any private document can be encrypted and signed. However, the services are mostly used in e-mail. In general, e-mail security services provided by the products and standards can only detect misuse, but not recover. The message handling vulnerabilities, or threats, include masquerading, message sequencing, modification of information, denial of service, repudiation, and leakage of information.
To achieve the goal of security the following 4 services should be provided:
Confidentiality means protecting the message against disclosure to unauthorized users, that is, no one else but the originator's intended recipients. This is achieved by encrypting the message, using either symmetric or asymmetric algorithms. Submission of messages to multiple recipients requires symmetric techniques, either alone, or combined with asymmetric techniques.
2.2 Message Origin Authentication
Origin authentication simply gives an answer to the question: "Who sent this message?" End-to-end message origin authentication is typically provided by content integrity. Origin authentication is provided by digital signatures. Digital signatures present the have the following features: unforgeable, authentic, and not reusable, they verify that the document is not altered, and they cannot be repudiated. Digital signatures are unforgeable as long as no one guesses your pass phrase. Messages with digital signatures are not reusable in general, but they may be replayed, though. Moreover, even though the message content cannot be altered, digital signatures do not necessarily guarantee that the message headers, like Date and Subject are not altered.
It is recommended that the following sequence be followed in order to
solve the problem of authorship and protecting clear text and signature:
1) sign the document
2) encrypt both the document and its signature
Integrity provides assurance that the message content has not been modified. End-to-end message origin authentication is automatically provided by content integrity. In fact, they should always be used together: the maintained integrity is of no value if the originator cannot be authenticated; the authenticated originator is of no value if the integrity cannot be maintained.
Verifying content integrity of a large message is an exhausting operation. Thus a separate hash value is computed for the message, and included into it, whereupon the message origin authentication check (MOAC) is a signed hash value over those partial hash values.
2.4 Non-repudiation (of origin and receipt).
Non-repudiation of origin in its simplest form is just message origin authentication (content integrity) with asymmetric encryption algorithms.
Digital signatures prove who sent the message, and that the message was not altered either by error or design. It also provides non-repudiation, which means the sender cannot easily disavow his signature on the message.
There are a few problems in using non-repudiation of receipt. For example, junk mail cannot be detected beforehand. The recipient could first be shown a digital fingerprint of a message, but then he could reject the message, and deny receipt, even though he may had enough information on the message, e.g., subject. The question is: what attributes of a message should be included in a digital fingerprint? Moreover, there is no one accepted definition of the term reception. Usually it means reading, but nothing is said about understanding the message, or taking any action on it.
A solution to this issue is to use an arbitrator, who would prevent the recipient reading the message before he has sent a signed receipt.
In a secure e-mail environment, public keys can be stored in the Directory. A certificate is used to bind a public key to an individual or other entity, and certifications are issued by a certification authority (CA), which can be any trusted administration. A certificate contains at least a key and a name, but it should also contain the expiration date, the name of the certifying authority, and the serial number of the certificate. Above all, it contains the digital signature of the certificate issuer.
If a secret key is compromised or becomes otherwise invalid before its expiration date, it can be added to a certificate revocation list (CRL), which should always be checked before a public key is used.
PGP and PEM are based on two different public key distribution models.
The X.509 standard constitutes a widely-accepted basis for the authentication framework, defining data formats and procedures related to distribution of public keys via certificates digitally signed by CA's. The X.500 Directory is used by X.400, and it has been developed for the needs of the Internet: specified the basis of a Public-Key Infrastructure (PKI) to be used in PEM, and the IETF Working Group on the PKI was formed lately to revise that work. One of the main objectives is to support for a range of trust and hierarchy environments. Several RFCs and Internet Drafts on X.500 have been written to make its concepts more understandable. X.509 also presents a few defects one of the most important ones being that it is not possible to detect a fraudulent user that starts to act like a CA, issuing fake certificates.
The most difficult aspect of using PGP, or any public-key application, is getting your hands on the public keys of the people with whom you wish to correspond. You must make sure you have the true public key of each individual in your electronic Rolodex. Suppose I create a linked pair of public and private keys and send you the public key, declaring that I am Elvis. How do you know I am the real Elvis and not an impostor? If I am an impostor, I could send you signed messages and you would be sure they were from Elvis. If you send an encrypted message to Elvis, I can capture the message and recover the plain text.
PGP provides a number of tools and recommended procedures for obtaining public keys in trusted ways. One handy tool is the public-key fingerprint, which is nothing more than a string of printable characters based on the MD5 hash code of the key. For all practical purposes, the fingerprint of a key is unique. So, if Alice knows Bob's voice, Bob could send his public key to Alice via e-mail. Alice then could generate the fingerprint of that key, call Bob, and have Bob read the fingerprint over the phone to make sure there is a match.
Once you have a few trusted keys, you can make use of PGP's signature capability. If you have Bob's public key and you trust Bob to provide you with other public keys of other persons, Bob can send you John's key signed by Bob. That is, Bob takes John's public key and feeds it through the signature mechanism of PGP. Alice can use Bob's public key to ensure that John's key was provided by Bob and that the key has not been altered.
There also are a number of servers on the Internet that are public-key repositories. Most of keys are signed by one or more people. You can obtain someone's public key from the server and if you trust the signatories to the key, you can have faith that it is genuine. These public-key servers do not authenticate the keys; they merely serve as repositories.
One public-key directory that does attempt to provide authenticated PGP keys is SLED (Stable Large E-mail Database). The public keys in the directory are signed by SLED, indicating that the user's authenticity has been verified.
PGP (Pretty Good Privacy) was implemented in 1991 by Phil Zimmermann , and is the most successful product for secure e-mail so far. It was aimed to be used within existing e-mail systems, and is available on almost any platform.
Here's how it works. Suppose Alice wants to correspond with Bob. If Alice prepares a message and encrypts it with Bob's public key, only Bob can decrypt the message using his private key. If Alice prepares a message and encrypts it with her private key, then anyone, including Bob, can decrypt the message. But only Alice could have encrypted the message, therefore the encrypted message is, in effect, signed by Alice.
A mail message is encrypted and signed as follows:
1.A one-way hash of the message is generated.
2.The hash value is signed with the originator's signature.
3.The message and the signature are concatenated.
4.A random session key is created.
5.The signed message is encrypted with the session key, using a private
key algorithm, like IDEA in
PGP.
6.The session key is encrypted with the recipient's public key, using
a public key algorithm, like
RSA in PGP.
7.The encrypted message and the encrypted session key are bundled together.
PGP public keys are kept in individual key certificates that include the key owner's user ID (which s that person's name), a timestamp of when the key pair was generated, and the actual key material. Key certificates are stored in a file that is called a key ring. Secret keys of a user are in a secret key ring, which is encrypted with a password. PGP Public Key Servers are repositories of PGP public keys; requests are processed in the form of e-mail messages.
It turns out that RSA, and all other known public-key algorithms, are time-consuming and inefficient. Therefore PGP, like most other encryption applications, does not use RSA directly to provide confidentiality and digital signatures.
For confidentiality, PGP encrypts messages with an efficient single-key or conventional encryption algorithm known as IDEA. It then uses RSA to encrypt, with the receiver's public key, the IDEA key used to encrypt the message. The receiver can use RSA to recover the IDEA key and use that key to recover the message.
The IDEA cipher has a 64-bit block size for the plaintext and the ciphertext. It uses a key size of 128 bits. It is based on the design concept of "mixing operations from different algebraic groups". It runs much faster in software than the DES. Like the DES, it can be used in cipher feedback (CFB) and cipher block chaining (CBC) modes. PGP uses it in 64-bit CFB mode.
For digital signatures, PGP uses an efficient algorithm known as MD5 to produce a summary code, or hash code, of the message that is, for all practical purposes, unique to that message. PGP hen uses RSA to encrypt the hash code with the sender's private key. The receiver can use RSA to recover the hash code and verify that it is the correct hash code for the message. If it is correct, then only the alleged sender could have prepared the encrypted hash code.
PEM
PEM (Privacy Enhanced Mail), MIME and MOSS are Internet standards and
are published as RFCS. PEM catches the essential core of OSI security services:
| Certificate information | PEM certificates are X.509v1 certificates. |
| CA arrangement | PEM uses a rigid, top-down CA hierarchy. |
| CA <-> Subject <-> User relationship | Users and subjects are distinct from CAs. No PEM user can be a CA. |
| CA <-> Subject <-> User trust relationships | All PEM users must place complete trust in the Internet Policy Registration Authority (IPRA), as all certification paths start with the IPRA’s key. A user must also trust the Policy Certification Authorities (PCAs) and CAs they encounter in a certification path. The user must be familiar with each PCA’s policies, and trust that the PCA and the CAs have not deviated from those policies. |
| Certificate validation method | Certificates are validated "online" using email. It is expected that the message originator would include the full certification path to his key in the message, which the recipient can validate using the IPRA’s key. While performing this validation, the user must also verify that no certificates have been revoked or expired, and that DN subordination has been followed. |
| Certificate revocation method | PEM uses X.509v1 CRLs, distributed via email to each user. |
| Identity vs. credential certificates | PEM certificates are purely X.509v1 identity certificates. |
| Irrefutability and strong authentication | The PEM architecture allows for strong authentication of users. |
| In-band vs. out-of-band authentication | Each user needs to obtain the IPRA’s key via some out-of-band means. Given that key, all other authentication can be performed in-band. |
| Anonymity | PEM provides an anonymity mechanism through what it calls "PERSONA" CAs. A PERSONA CA is distinct from a regular PEM CA in that it explicitly does not vouch for the identity of its subjects. |
To illustrate some aspects of PEM’s operation, assume that Alice wishes
to send a message to Bob, with whom she has never communicated, and that
they both operate within the certification structure shown in Figure 1
(the arrows represent a certification, such as PCA1 issuing a certificate
for CA1’s public key).
When Alice composes her message, she appends the certification path between her and the Internet Policy Registration Authority (IPRA), i.e. the certificates for herself, CA2, CA1 and PCA1. Note that she does not issue (i.e. sign) these certificates, she merely includes them in her message (she obtained them when she was issued her own certificate by CA2). She then signs the entire message, including the certification path (see Figure 2).
When Bob receives the message and wishes to validate it, he starts with
the IPRA key and validates the certificate path included in the message
to obtain Alice’s public key (checking not only that the included certificates
have neither expired nor been revoked, but also that Distinguished Name
subordination has been observed). If this is the first time that Bob has
followed a certification path down PCA1’s branch of the hierarchy, his
PEM software is required to ask Bob to explicitly accept PCA1’s certificate.
This is to alert Bob that he is entering a new certification policy domain,
and that he would be wise to review PCA1’s policy (as well as the policies
of any CAs subordinate to PCA1, depending on how much PCA1 allows its CAs
to refine their own policies).
This requirement for policy awareness helps Bob to determine whether
the origin of the message agrees with its contents. For example, Bob might
be suspicious of a purchase order message requesting an educational discount
that is certified beneath a PCA that represents commercial organizations.
However, it is entirely up to Bob to be aware of the policies of the various
PCAs. PEM has no automatic policy-verification mechanism. The need for
all users to be familiar with the policies of each PCA they encounter resulted
in PEM requiring that there only be a small number of PCAs. This meant
that PEM would have had to describe every aspect of Internet communications
with only a handful of policies.
-----IPRA-----
|
|
v
v
PCA1
PCA2
|
|
v
v
CA1
CA3
|
|
CA2
|
|
|
v
v
Alice
Bob
Figure 1
=============
||
Message ||
||
Text ||
|| ---------------
||
|| Certificates for
||
||
PCA1 ||
||
CA1 ||
||
CA2 ||
||
Alice
||
||
||
==============
||
||
KEY
Figure 2
Being a practical standard, PEM is much simpler than X.400, and it can run on top of almost every existing e-mail system.
MIME
MIME, the Multi-purpose Internet Mail Extensions, is a freely available
set of specifications that offers a way to interchange text in languages
with different character sets, and multi-media e-mail among many different
computer systems that use Internet mail standards.
If you were bored with plain text e-mail messages, thanks to MIME you
now can create and read e-mail messages containing these things:
Before MIME became widespread, you might have been able to create a message containing, say, a PostScript document and audio annotations, but more often then not, the message was encoded in a proprietary, non-transportable format. That meant that you couldn't easily handle the same message on another vendor's workstation, or even get it intact through a mail gateway in the first place. Now, depending on the completeness of your MIME-capable mail system, there's a good chance that it'll "just work" .
MIME was carefully designed to survive many of the most bizarre variations of SMTP, UUCP, and other mail transport protocols that like to slice, dice, and stretch the headers and bodies of e-mail messages.
PEM was being applied to MIME in RFC 1848, MIME Object Security Services (MOSS), and RFC 1847, Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. MOSS supersedes PEM, and has many advantages: it does not require certificates; it allows e-mail addresses and arbitrary strings for identifying the public keys of users, instead of only distinguished names; and it allows non-text messages.
MOSS
MOSS is a Privacy Enhanced Mail (PEM) derivative that is a Proposed
Internet Standard (RFC 1847 & RFC 1848) for adding security services
to Multi-purpose Internet Mail Extensions (MIME). It uses the cryptographic
techniques of digital signature and encryption to provide origin authentication,
integrity, and confidentiality to MIME objects. Users of MOSS can know
who originated a message, that the message has not been changed enroute,
and that the message was kept secret from everyone except the intended
recipients.
MOSS depends on the existence of public/private key pairs to support its security services. Users must exchange public keys with those other users with whom they wish to exchange MOSS email. This may be accomplished manually, via mechanisms available in the protocol, via X.509 certificates, or any other suitable mechanism.
PGP is a product , whereas PEM is a standard (RFC).
Public key management is based on totally different philosophies. In short, PGP is a distributed network of individuals. It uses a so called web of trust: you can certify public keys of your friends, and you do not have trust but them. A user cannot verify the validity of every other PGP key, and one probably will not ever trust most people - so in the beginning PGP was not very scalable.
PEM public key management is hierarchical (bureaucratic): keys are verified at trusted Certification Authorities (CA), and it is guaranteed that any two users have a common CA above them in the hierarchy. You have to trust your CA, and, in fact, also other CA's since keys can be verified transitively, by a chain of CA's. PEM public keys can be distributed by any means, e.g., by e-mail or X.500 Directory look-up.
PEM provides digital signature and encryption services to text-based electronic mail. It depends on X.509 certificates that are issued within the Internet certification hierarchy. PEM is a standard in the Internet.
PGP can provide the same services. It is not integrated with MIME (although MIME can carry a PGP object) so the interpretation of the protected content is necessarily user controlled. PGP depends on public/private key pairs and does not support X.509 certificates.
MOSS is a PEM derivative. It integrates the security services of PEM and the user friendly functions of PGP with MIME, taking advantage of the extensive structuring and formatting facilities of MIME. MOSS is a standard in the Internet.
There are a few restrictions in the use of security services on both sides. In PGP, the signature of a message cannot be verified while the message is encrypted. This means that third-parties cannot verify the originator of a message.
PEM users cannot send unsigned messages at all, but this is possible with MOSS. One could say that both of these restrictions just add security. Actually, there is a way to hide the origin of a message in PEM: one can still use anonymous remailers, like anon.penet.fi, and sign the message using the public key of his anonymous mail address!
5. Weaknesses in the Design of Secure Systems
5.1 Missing Architecture and Services
Most secure e-mail services can be used as such in other applications, like encrypting own private documents, and signing documents on bulletin boards. E-mail is just a way to distribute documents.
Unfortunately, there is no standard for the open system security architecture that would define the general services to be used by e-mail and other applications.
It is easy to find requirements for new security services not yet provided by current standards and products. For example, a document may have several authors, who would like to sign the chapters they wrote. Separating the message sender and the author(s) is not generally supported by e-mail systems, let alone secure ones.
Specification of security issues related to distribution lists, mailing lists, recipient redirection, auto-forwarding, and gatewaying between different e-mail systems are typically left to system implementators. Of course, the systems remain proprietary.
Some security threats are cumbersome to protect against. Traffic analysis could be disturbed by encrypting the envelope, in addition to the message content. This double envelope technique hides the originator and recipients of a message from eavesdroppers. Unfortunately, one could still analyze how often messages are sent and received. Therefore, we would need monotonous submission of fixed sized double envelopes! One drawback with double envelopes is that cryptanalysts can infer some format of the encrypted envelope: they can look for predefined bytes and other repetitive structures, like the header fields of the inner message. Similarly, adding a signature in each message you encrypt, may help cryptanalysts.
In general, e-mail security services provided by the products and standards can only detect misuse,but not recover.
Securing the messages in transit is not enough because the user's mailbox or Message Store (MS) is liable to security attacks. In X.400, the MS is defined as the main repository of the user's messages. However, the MS does not usually have access to the user's private keys, which makes it impossible to provide the proof of delivery service. The Internet mail Post Office Protocol (POP- 3), defined in RFC 1725, and Interactive Mail Access Protocol (IMAP), defined in RFC 1203, discuss practically nothing on security issues.
Here is a list of possible attacks:
Compromised Pass Phrase and Secret Key
Of all the attacks this is the simplest especially if you leave your
pass phrase for your secret key written down somewhere. If someone gets
it and also gets your secret key file, they can read your messages and
make signatures in your name.
Public Key Tampering
A major vulnerability exists if public keys are tampered with. This
may be the most crucially important vulnerability of a public key cryptosystem,
in part because most novices don't immediately recognize it. When you use
someone's public key, make certain it has not been tampered with. A new
public key from someone else should be trusted only if you got it directly
from its owner, or if it has been signed by someone you trust. Make sure
no one else can tamper with your own public key ring. Maintain physical
control of both your public key ring and your secret key ring, preferably
on your own personal computer rather than on a remote timesharing system.
Keep a backup copy of both key rings.
"Not Quite Deleted" Files
Another potential security problem is caused by how most operating
systems delete files. When you encrypt a file and then delete the original
plaintext file, the operating system doesn't actually physically erase
the data. It merely marks those disk blocks as deleted, allowing the space
to be reused later. It's sort of like discarding sensitive paper documents
in the paper recycling bin instead of the paper shredder. The disk blocks
still contain the original sensitive data you wanted to erase, and will
probably eventually be overwritten by new data at some point in the future.
If an attacker reads these deleted disk blocks soon after they have been
deallocated, he could recover your plaintext.
Viruses and Trojan Horses
Another attack could involve a specially-tailored hostile computer
virus or worm that might infect your e-mail program or your operating system.
This hypothetical virus could be designed to capture your pass phrase or
secret key or deciphered messages, and covertly write the captured information
to a file or send it through a network to the virus's owner. Or it might
alter your e-mail program behavior so that signatures are not properly
checked. This attack is cheaper than cryptanalytic attacks.
Another similar attack involves someone creating a clever imitation
of your e-mail program that behaves like it in most respects, but doesn't
work the way it's supposed to. For example, the e-mail program might
be deliberately crippled to not check signatures properly, allowing bogus
key certificates to be accepted. A "Trojan horse" version of an e-mail
program might not be too hard for an attacker to create, especially
when the source code is widely available; so anyone could modify the source
code and produce an imitation of your e-mail program that looks real but
does
a lot of damage to your security.
You should make an effort to get your copy of your program from
a reliable source. Or perhaps from more than one independent source, and
compare them with a file comparison utility.
Physical Security Breach
A physical security breach may allow someone to physically acquire
your plaintext files or printed messages. A determined opponent might accomplish
this through burglary, trash-picking, unreasonable search and seizure,
or bribery, blackmail or infiltration of your staff.
Don't be lulled into a false sense of security just because you have
a cryptographic tool. Cryptographic techniques protect data only while
it's encrypted-- direct physical security violations can still compromise
plaintext data or written or spoken information.
Traffic Analysis
Even if the attacker cannot read the contents of your encrypted messages,
he may be able to infer at least some useful information by observing where
the messages come from and where they are going, the size of the messages,
and the time of day the messages are sent. This is analogous to the attacker
looking at your long distance phone bill to see who you called and when
and for how long, even though the actual content of your calls is unknown
to the attacker. This is called traffic analysis. PGP alone does not protect
against traffic analysis. Solving this problem would require specialized
communication protocols designed to reduce exposure to traffic analysis
in your communication environment, possibly with some cryptographic assistance.
Protecting Against Bogus Timestamps
A somewhat obscure vulnerability of e-mail programs (PGP especially)
involves dishonest users creating bogus timestamps on their own public
key certificates and signatures.
There's nothing to stop a dishonest user from altering the date and
time setting of his own system's clock, and generating his own public key
certificates and signatures that appear to have been created at a different
time. He can make it appear that he signed something earlier or later than
he actually did, or that his public/secret key pair was created earlier
or later. This may have some legal or financial benefit to him, for example
by creating some kind of loophole that might allow him to repudiate a signature.
Tempest Attacks
Another kind of attack that has been used by well-equipped opponents
involves the remote detection of the electromagnetic signals from your
computer. This expensive and somewhat labor-intensive attack is probably
still cheaper than direct cryptanalytic attacks.
Exposure on Multi-user Systems
On multi-user systems such as UNIX, VAX/VMS, etc., there are much greater
risks of your plaintext or keys or passwords being exposed. The Unix system
administrator or a clever intruder can read your plaintext files, or perhaps
even use special software to covertly monitor your keystrokes or read what's
on your screen. On a Unix system, any other user can read your environment
information remotely by simply using the Unix "ps" command.
Cryptanalysis
An expensive and formidable cryptanalytic attack could possibly be
mounted by someone with vast supercomputer resources, such as a Government
intelligence agency.
E-mail privacy is surrounded with the similar problems as voice mail - in fact, voice messages can also be sent by e-mail. PGPfone is a new technique for using PGP in telephone discussion, and will surely arouse hot debate.
One way to keep e-mail private is to use anonymous remailers, which hide the actual address of the message originator. It is even possible to reply to an anonymous message originator, but there is no way to tell his real identity - except breaking in the remailer server's databases. It also makes sense to sign anonymous messages, so that the recipients can authenticate the anonymous originator. It is useful to know that the person you are exchanging messages with, whoever he is, remains the same.
Usability is already and will be the critical issue in adopting secure e-mail. When security services are tightly integrated to applications, transparent to the user, and do not cost anything, they can be used in everyday messaging.
Open secure communication is not easy in the world of numerous standards: picking the right one is hard. PGP and PEM, as well as other minor alternatives, must eventually become one because they cannot interoperate. Before one standard, security policies can be used for bilateral agreements.
References
Web Links
http://www.pgp.com/products/
http://www.internetworld.com
http://www.nsi.org
http://www.counterpane.com
http://world.std.com/~franl/crypto
RFCs and Internet Drafts
-David Balenson. Privacy Enhancement for Internet Electronic Mail: Part
III: Algorithms, Modes, and Identifiers, RFC 1423, 1993
-Burton S. Kaliski. Privacy Enhancement for Internet Electronic Mail:
Part IV: Certification and Related Services, RFC 1424, 1993
-Steve Kent. Privacy Enhancement for Internet Electronic Mail: Part
II: Certificate-Based Key Management, RFC 1422, 1993