Jyrki Heikkinen
ICL Personal Systems
TeamWARE Division / Enterprise Messaging Development
jhe@to.icl.fi
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: from the first chapters, novices should get general knowledge on current secure e-mail systems and standards they are based on; others can jump straight to the critical discussion on the subject.
The first part of the paper introducessecurity 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, and its successor, MIME Object Security Services (MOSS). Their fundamental ideas, and use in e-mail are compared. The secure X.400 message handling standards are also covered.
After the facts, the paper concentrates on controversial hot topics - those familiar with the basic concepts may start herein. First, the limitations of the current systems and missing security services are pointed out. Then, the right to privacy, as well as other legal and ethical issues in the free secure messaging are discussed. Finally, tight integration of security to future e-mail packages is predicted, and some usability requirements are set.
The paper does not cover protection of messages in workstations or mailboxes.
Outside the paper are also viruses received in e-mail messages, corrupted
messages because of broken transport, and e-mail based applications, like
workflow and electronic money.
2. Security Services
"One uncommon security threat: masquerading eavesdropper."
- Secure deep thought
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.
2.1 Content Confidentiality
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. They are much like hand-written signatures, in that they are unforgeable, authentic, and not reusable, they verify that the document is not altered, and they cannot be repudiated. Of course, these definitions can be critized. 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.
Signature and encryption can be combined in three ways:
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
Non-repudiation of origin in its simplest form is just message origin
authentication (content integrity) with asymmetric encryption
algorithms.
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. UK GOSIP MHS(88) implementations shall interpret receipt as not less than "presentation of the message to a human recipient such that the latter is made aware of the fact that the message has been received and acknowledges such receipt in some way" [14] Purchasers may wish to impose more stringent conditions, though.
EDI systems may require that the recipient cannot read the message
without a signed receipt notification. This can be achieved using the
digital certified mail protocol
[22].
The protocol is theoretically sound, but quite complicated and
impractical, requiring 200 messages sent between the sender and the
recipient. The protocol is based on revealing the secret keys bit by
bit to the two parties.
Another way is to use an arbitrator, who would prevent the recipient
reading the message before he has sent a signed receipt.
3. Public Key Management
"Trust me, I know what you are doing."
- Secure deep thought
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. CA's form a hierarchical structure, thus allowing cross-certification. For example, PGP and PEM are based on two different public key distribution models.
The X.509 standard [12] 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: [7] 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.
Müller [21] points out several defects in X.509. First, it is not possible to detect a fraudulent user that starts to act like a CA, issuing fake certificates. Second, encryption algorithms are not precisely specified, which seriously retards settling on a small set of generally recognized algorithms. The secret key of a CA is the ultimate target of an attacker. A chain of CA's also sounds dubious: it is like revealing a secret to your best friend, who will tell it to his best friend, and so on. Hierarchical CA's can be seen as a threat to privacy. For example, in an organization, a boss could sign the certificates of his inferiors. How dare anyone send e-mail related to the boss after that.
More information can be found in the
RSA Cryptography Today FAQ [28].
4. Standards and Products
4.1 Pretty Good Privacy - PGP
"It's personal. It's private. And it's no one's business but yours."
(PGP
User's Guide)
PGP (Pretty Good Privacy) was implemented in 1991, 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. Hot discussion has surrounded PGP since its creator Phil Zimmermann was convicted for making the exportation from the U.S. easy, that is, giving the program to the Internet.
A mail message is encrypted and signed as follows:
PGP public keys are kept in individual "key certificates" that include the key owner's user ID (which is 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.
A few Internet Drafts have been written about adding PGP security
services to MIME.
MIME Security with Pretty Good Privacy (PGP)
is the newest draft, which uses security content types described in
Security Multiparts for MIME:
Multipart/Signed and Multipart/Encrypted, RFC 1847.
4.2 PEM and MOSS
PEM (Privacy Enhanced Mail) is a standard for secure e-mail, defined in
RFCs 1421-1424.
The first RFC 989 was published in 1987, almost simultaneously with
the X.400 Recommendations that included
security services. In fact, PEM catches the essential core of OSI
security services: encryption, authentication, and certificate-based
key management. Moreover, it defines the algorithms to be used. PEM
does not provide authentication of the recipient.
Being a practical standard, it is much simpler than X.400, and it can
run on top of almost every existing e-mail system.
Trusted Information Systems (TIS) developed the reference implementation of PEM, and RIPEM (Riordan's Internet PEM) is the most famous PEM implementation. The Message Security Protocol (MSP) is the military equivalent to PEM. NIST Open System Implementors Workshop Security Working Group also defined an X.400 body part to carry PEM messages [7]. PEM was never accepted widely, though. According to some, it failed due to its dependency on a non-existent certification and directory infrastructure.
"Mime provides secure voice mail."
- Secure deep thought
Finally 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.
Unfortunately, MOSS is not interoperable with PGP, and
it does not provide symmetric encryption services.
Lately there has been lots of discussion on the subject in the
info.pem-dev newsgroup.
S/MIME is another consortium effort to integrate security into MIME,
backed by Microsoft and RSADSI inter alia. It defines signature and
encryption formats, and a mechanism for including secured objects in
MIME-format messages. To create the complete chaos, S/MIME cannot
interoperate with MOSS or PGP. However, for example Netscape is
working to get S/MIME into its e-mail agent.
4.3 Comparison of PGP and PEM
Similarities between PGP and PEM are so many that the emphasis is here
on the most visible dissimilarities.
First of all, PGP is a product (de facto standard), whereas PEM is a
standard (RFC). The main differences are thus derived from the
functional properties of PGP, and the functional specifications of
PEM. On the other hand, a PGP standard is about to be released soon, and
there are some PEM implementations. All in all, this is like comparing the
reality and high hopes because not all PEM features are implemented.
For example, RIPEM, the flagship of PEM, does not implement certificates.
First of all, public key managament 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 PGP is not very scalable. However, this is only the way how PGP is used today for there are no technical reasons why the public keys could not be managed by the authorities. Conspiracies are possible with small webs: a group of users could certify dummy certificates and thus impersonate invalid users. PGP public keys can be distributed by e-mail, bulletin boards or special key servers; there are also plans to store them in the X.500 Directory.
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. In theory, this seems nice, well organized, so it is not a big surprise that commercial and governmental applications are very interested in PEM. In practice, though, the lack of the infrastructure, public directories, has been the main obstacle in proliferation of PEM.
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!
Eventually, the two should merge - maybe we'll have PGPEM someday! It
may be decisive, which one is first implemented within MIME, and
integrated to popular e-mail applications.
4.4 X.400 Security Services
"X.400 has security defined; Internet Mail has PGP, PEM and MOSS."
-
The Canonical Internet vs X.400 Debate
Many beliefs surround X.400 security. First, X.400 has well-defined security model and services, but there are hardly any implementations. Second, X.400 messages are ASN.1-encoded, which makes some think that they are more secure than ASCII-encoded Internet messages. Obviously, with a simple ASN.1 to ASCII converter anyone can read an unencrypted X.400 message.
An X.400 message envelope and content (typically, interpersonal message) are separate, which makes it easy to apply security to the whole content, and not just the body parts of the message. Even though MIME (RFC 1521) allows sending multi-part non-textual messages in Internet mail, many interpersonal message attributes, like subject, are actually in the message headers. Of course, the same level of content confidentiality could be achieved with double envelope techniques: in MIME, this means encrypting the actual message within a message/rfc822 body part.
Transfer protocol oriented encryption used by X.400 requires a lot from the underlying message transfer system (MTS). Therefore, X.400 security services cannot be transferred via old message transfer agents (MTA). Internet systems, on the other hand, use document oriented encryption, whereupon secure messages are transparent to the MTS.
If X.400 recommendations have something better than Internet RFCs, it is that they at least have separate service and protocol definitions, whereas Internet mail definitions, like Standard for the Format of ARPA Internet Text Messages (RFC 822), just define the protocol. Herein only the service definitions are discussed.
X.402 [10] defines the security model, and X.400 [9] defines security capabilities of the message handling system, as well as security elements of service. Services are divided into two subtasks: Message Transfer and Message Store.
Many of these services can be adopted to the Internet mail as soon as corresponding delivery reports and receipt notifications have been defined. Drafts on Internet mail notifications have already been written, and these new message types - Delivery Status Notifications and Message Disposition Notifications - will eventually include PGP- or PEM-based security.
Message sequence integrity is a unique service, allowing the originator to provide to a recipient proof that the sequence of messages has been preserved. Security context limits the passage of a message between entities by reference to the security labels associated with the message. Message security labelling, or classification, can indicate the message be restricted, confidential, or (top) secret.
Security services are divided into three security classes, which can be viewed as tools to implement a security policy. Each class includes a set of mandatory and optional security services, and the classes are incremental subsets of the base security features. The first class (SEC0) requires support of end-to-end services between UAs: content integrity, message origin authentication, and proof of delivery. SEC1 additionally requires support of secure access management, and SEC2 additionally support of origin authentication checks. The confidential security class variants SECnC additionally require support of content confidentiality.
X.411 [11] defines the security protocol, as well as one security related non-delivery diagnostic code: a secure messaging error indicates that the message could not be progressed because the message security label would violate the security policy in force, which goes against the security context.
The great number of security services and the possibility to use
them in contradictory ways cause problems. Fortunately, functional
standards and profiles restrict and clarify the use of optional
services specified in base standards, thus helping OSI-based
implementations to interoperate.
Secure Messaging Guidelines [13]
define how secure messaging is used within the framework of the X.400.
5. Weaknesses in the Design of Secure Systems
5.1 Missing Architecture and Services
"A general security policy can be defined as the set of laws,
rules, and practices that regulate how an organization manages,
protects, and distributes sensitive information. Thus a security
policy defines an orginization's overall approach to security and must
cover all security aspects."
[13]
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 [19, 20].
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.
5.2 Threats Outside E-mail
"The brute-force will be with you, always."
- Secure deep thought from ITAR Wars
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.
One source of compromised security may be the encryption tools themselves. For example, the random number generator they use may be too simple, producing easy-to-guess symmetric encryption keys; or when the program swaps, a private key, or an unencrypted message, might be left behind. Private keys may also be protected only by a pass phrase. Hence, whatever the length of a key, guessing the pass phrase gives one access to private messages. The Passphrase FAQ discusses more on the issue.
Choosing an algorithm is based on the security and speed; the
security of an algorithm is based on the security of the key.
First of all, one must beware of proprietary algorithms. The algorithm
should be one which is widely regarded as strong enough to serve the
purpose and have stood the test of time.
For example, PGP uses IDEA (International Data Encryption Algorithm),
which was invented in 1990. It may be secure, but no one knows yet.
Finally, the length of the keys used are also essential in making the
system secure.
6. Legal and Ethical Issues on Secure E-mail
6.1 The Right to Privacy
"Intercepting and reading other people's e-mail is a
felony."
- Electronic Communications Privacy Act (1986)
Today the issue of private e-mail is more topical than ever since European Commission has suggested strong cryptography be made illegal. In the EC secure e-mail model, there is one trusted component: Big Brother. Discussion on the subject continues...
Illusion of privacy of e-mail is common. Because the originator and the recipients can see no tangible evidence of the message, they easily assume that the medium is secure and private. Written e-mail policies have therefore been used to guide the employees of organizations and companies to clarify how to use e-mail. For example, a policy can state that sending personal, or company confidential e-mail is entirely prohibited [16].
In the U.S., Electronic Communications Privacy Act of 1986 is the current law, which also applies to e-mail. However, it only extends protection to messages sent over public telephone lines, national e-mail, and on-line systems. The law does not extend protection to private e-mail systems. As the law protects letters delivered by the postal service, there is one interesting consequence: e-mail messages sent through a Postal Delivery Service (PDS) are public till they arrive the PDS, but private after they have been printed and put to a letter. If confidential messages were sent through the PDS, they should be encrypted with the public key of the PDS, thus making the PDS a trusted component in the system.
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.
6.2 Other Issues
"Incognito, ergo sum."
- Anonymous secure deep thought
Export of strong encryption is restricted from the U.S. since it is regarded as munition. However, if the keys used in a secure application are short enough, exporting is allowed. This has lead to ridiculous applications that claim to be secure, but are in fact breakable. Obviously, the main reason for the restrictions is to maintain the ability of government, or National Security Agency (NSA), to wiretap the traffic. Basically the matter in question is thus the privacy: how not to let people communicate without the fear of being eavesdropped. As signatures are only used in authenticating users, the applications that only use authentication can be exported freely.
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.
More discussion on these issues can be found in
Controlling and Securing Personal Privacy and Anonymity in the Information
Society.
7. Conclusions
"In order to ensure that a secure email package is useful it
needs to be available, convenient, reliable and simple."
- UKERNA
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. On the other hand, some external devices may be required to achieve the adequate level of security; for example, smart cards are technically feasible, but some may think their use inconvenient. The UKERNA Secure Email project project investigates how PGP can be made easy to use for sending email: integration of PGP into MUAs, management of PGP keys for the community, and user education.
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. EEMA (European Electronic Messaging Association) is about to decide in November 1995 on Secure inter-organisational electronic messaging, and Policy on the regulation of encrypted electronic messages.
Another need is the standard interface to security services. X/Open, the leading open systems group, is defining a generic Cryptographic Services API, which will allow a single interface to multiple encryption services. A preliminary version is planned for early in 1996. They are also defining distributed authentication based on the Generic Security Services API (GSS-API). A preliminary specification is passed to the IETF [18].
Unencrypted e-mail messages are like postcards: anyone can read them easily. Encrypted messages are like letters within envelopes: one has to open the envelope to read them, or even break the seal. To hamper eavesdroppers, everyone should encrypt and sign all of his correspondence, even when the content does not warrant secrecy. Theoretically, there is an optimal time to start using security services, that is, when the critical mass is reached. Nowadays, only a few people use security services, so their messages are caught by eavesdroppers; someday most people will use use the services, so unencrypted messages may be caught first because their information is fastest to solve.
Glossary
"Why is 'abbreviation' such a long word?"
| CRL | Certificate Revocation List |
| DES | Data Encryption Standard |
| DSA | Digital Signature Algorithm |
| DSS | Digital Signature Standard |
| ECPA | Electronic Communications Privacy Act |
| EES | Escrowed Encryption Standard |
| EIS | Electronic Information Security |
| EPIC | Electronic Privacy Information Center |
| IDEA | International Data Encryption Algorithm |
| ITAR | International Traffic in Arms Regulation |
| PKCS | Public-Key Cryptography Standards |
| LEAF | Law Enforcement Access Field |
| MDn | Message Digest (e.g., MD5) |
| MIC | Message Integrity Check |
| MOAC | Message Origin Authentication Check |
| MOSS | MIME Object Security Services |
| MSP | Message Security Protocol |
| NIST | National Institute of Standards and Technology |
| NSA | National Security Agency |
| PEM | Privacy Enhanced Mail |
| PGP | Pretty Good Privacy |
| PKCS | Public Key Cryptosystem |
| PKI | Public-Key Infrastructure |
| PSRG | Privacy and Security Research Group |
| RCn | Rivest's Code (e.g., RC2, RC4) |
| RFC | Request for Comments |
| RIPEM | Riordan's Internet PEM |
| RSA | Rivest-Shamir-Adleman |
| RSAREF | RSA Reference |
| SHA | Secure Hash Algorithm |