How to Organize Companywide Authentication and E-Mail Encryption
Manfred BOGEN <firstname.lastname@example.org>
In the last three years, encryption utilities like Pretty Good Privacy (PGP) and Privacy Enhanced Mail (PEM) have matured to a point where they have begun to receive widespread acceptance among users of electronic mail on the Internet and intranets. Many employees of research institutes, universities, and companies have started to use encryption and digital signatures to protect and to authenticate their e-mail.
To achieve a maximum benefit from these security measures, though, the organization has to provide an infrastructure for its employees which includes trusted or untrusted key servers, a key certification authority and a definite policy about the utilization of the new technology.
In this paper, the authors present a skeleton security policy on which others can base their custom made solutions to the authentication problem. Experiences are also described from establishing a certification authority within the German National Research Center for Information Technology (GMD) and from maintaining a certification authority for the individual network domain rhein.de.
The foundation of the work is the policy for certification authorities as issued by the German Research Network (DFN), which will be discussed and extended so that it suits the requirements of middle-size to large companies or organizations.
The paper also addresses the problem of handling different authentic keys for different applications -- like encryption of electronic mail, Secure Shell (SSH) host keys, and Secure Socket Layer (SSL) certificates for Web browsers -- as well as giving various practical hints which will help to avoid the pitfalls that lurk on the way.
The intention of this paper is to serve as a base for a security handbook for other organizations wishing to establish such an authentication infrastructure.
There are millions of people using the Internet nowadays. Formally invented for communication and cooperation among more or less closed groups of scientists or military personnel, it now reaches business, the mass market, and private homes. This worldwide coverage and penetration, however, impose some security requirements for all kind of applications and their users. As in the paper-based normal life, transactions of any importance through the Internet have to be authenticated -- people want to have a proof of the origin of these transactions.
This is difficult in a worldwide communication environment and in a global market. Public key (asymmetric) cryptography is mostly used for authentication purposes using a private key accessible only to a user/entity and a public key known to the rest of the world. A user who wants to trust the origin of some application data has to obtain the other user's public key from a source that it trusts. And here is the problem: How does one obtain a public key over an insecure network?
This paper is structured as follows: In section 2 it describes the key exchange problem in more detail together with two possible setups: the web of trust and a certification authority. Section 3 introduces a skeleton policy for a certification authority. Practical hints to organize a certification authority with trusted key servers and different key types are given in section 4. Software tools to be used in a secure environment are listed and assessed in section 5. Final advice on how to use a certification authority or how to run it depending on a company's size concludes the paper in the last section.
The crucial factor of all cryptography is the key exchange. Unfortunately, the Internet is the worst possible scenario for a secure key exchange. Due to the nature of the IP packet routing, it is possible to intercept connections, no matter whether they are electronic mails or file transfers, and to act as a man in the middle. (Please see [WEBNET] for more indefensible attacks.)
The so-called "man-in-the-middle attack" is one of the most efficient and hence most dangerous attacks that may be used to compromise the security of systems. It works as follows: Say that two persons, Alice and Bob, want to have an encrypted conversation. So they send each other their public keys via electronic mail.
Mallory, the malicious attacker, is a third person who wants to eavesdrop on the conversation. She happens to have administrator privileges on a system that lies on the path between Alice's and Bob's machines. Then she can do the following:
All conversation between Alice and Bob may now be eavesdropped on by Mallory due to the fact that Alice and Bob trust their respective public keys in good faith. And even worse, Mallory can also modify the messages. Neither Alice nor Bob is able to recognize that their conversation is being eavesdropped upon. Not even digital signatures remedy this situation, as Mallory is perfectly able to sign her modified messages with the key Bob believes to be Alice's and vice versa. Since all traffic in the Internet can potentially be rerouted, modified, or discarded, this threat is not a theoretical one -- it is very real.
Because the very purpose of public key cryptography is to enable parties that did not know each other before to communicate securely, it is not feasible to assume that everybody is able to exchange public keys over a secure channel. But for the man-in-the-middle attack described above, an insecure channel is not appropriate for the key exchange, either.
Fortunately there is a way out of the dilemma and that is to exchange digitally signed public keys. The idea is simple: People sign a public key, so the receiver can verify that the key has not been tampered with. It is not very helpful, though, to sign a key with itself. What one needs is a third known and trusted key that is used to authenticate the "new arrival." Just consider the following procedure:
This protocol is secure. An attacker has no way of replacing the public keys. But the protocol can only work if both Alice and Bob know Trent's public key, if Trent also knows Alice's and Bob's public keys, and if all participants trust each other not to cheat.
Unfortunately, the setup described above is rare at best. In a worldwide network, hardly any two persons wishing to communicate with each other will have a mutual friend they both trust.
Because the idea of using digital signatures to implement a secure key exchange through an insecure channel is much too appealing to simply drop it, a more complex scheme has been developed: the Web of Trust.
In the key exchange protocol explained before, Alice and Bob need a trustworthy person that both of them know for the protocol to succeed. In the Web of Trust model, several levels of trust are introduced: "complete," "marginal," or "unknown." These trust levels specify to what extent a person is willing to trust a signature issued by another person. If a person trusts someone's signature completely, every key this person has signed will be accepted as authentic -- just as in the previous setup with Alice, Bob, and Trent.
If a person trusts someone's signature "marginally," it means that it will not accept a key as authentic if the only certifying signature comes from the marginally trusted person. It might accept the key, though, if it has been signed by n people it trusts marginally, with n being usually equal to or greater than 2.
The Web of Trust has been described in [PGPDOC1] and implemented in early PGP versions, even though back then this model was not called "Web of Trust" but merely a "unique grass-roots approach."
The advantage of the Web of Trust model is that every user can follow its own policy about whether a key is accepted as authentic or not. Curiously enough, the same point is one of the biggest disadvantages of the Web of Trust: Every user has to create a security policy of its own.
Another disadvantage of the Web of Trust model is that it is hard to authenticate all keys with this approach: It does not scale very well. Sooner or later, a user will have to communicate with someone living on the other side of the earth and then chances are low that both of them will be able to relate to each other through a chain of trusted signatures.
In fact, most PGP keys used today are hardly signed by two or three different people, if at all. Obviously, most encrypted conversations take place without proper authentication of the keys.
A different approach for certifying encryption keys with digital signatures is the concept of a certification authority (CA). A certification authority is a central, trustworthy entity whose certification key is commonly known and trusted. Every user in the domain of the certification authority can exchange its key with the certification authority in a secure manner, in order to have it digitally certified by the authority. Other users can then verify the authenticity of the key by checking the signature of the authority. This concept is similar to the well-known approach of having the government issue tamper-proof, personal picture IDs for its citizens.
The difference is, though, that the certification authority does not necessarily have to be run by the government. Companies, organizations, or individuals can also run it, as long as people trust the certification authority to act faithfully according to their policy.
Having keys certified by a central authority solves the scalability problem the Web of Trust suffers from. A user wishing to have a secure communication with someone else needs only a small number of trusted certification keys to be able to verify the identity of its peer. While this approach is certainly not perfect, it can much more realistically be implemented in a worldwide forum like the Internet.
[X.509], the authentication framework of CCITT/ISO, deals with the creation and management of key pairs and certificates in general. Following X.509, a certificate contains the public key of a user, together with some other information, rendered unforgeable by encipherment with the secret key of the certification authority (CA) which issued it. It identifies three methods to produce a user's key pair:
According to X.509, "a certificate associates the public key and unique distinguished name of the user it describes." Therefore, the CA must know the identity of a user before creating a certificate for it and it "must not issue certificates for two users with the same name." The production of a certificate is done offline. However, all information for the CA must be transported in a secure manner.
As certificates have a limited lifetime, it is within the tasks of a CA to provide replacements in time.
Organizing a certification authority is mostly a problem of working out an appropriate policy. Once a set of rules has been defined, the operation of the certification authority itself is rather clear. A good policy should clarify the procedures for certification of a key as much as how to handle other events that may occur, such as if an employee leaves the organization or major changes in the organization's management occur.
This chapter will serve as a skeleton policy which can be used as a template to create a custom policy for the reader's organization. The following text has been loosely based on the [DFN-PCA] policy, as used by the "Deutsche Forschungsnetz (DFN)" in Germany.
Any policy should contain at least the following items:
This is a very important question, which should be answered thoroughly in the policy. If a person receives a certified key, what can it conclude by verifying the signature? What does it mean in practice?
There are two different models:
The difference may seem minor at first glance, but it is in fact substantial. In the second scenario, the certification authority must not only verify the key, but also check the employment status of the person the key belongs to.
Furthermore, there must be some mechanism that expires certificates after a certain period of time, so that an employee who has left the organization is not able to abuse the old key. This may be unfeasible, as many encryption programs lack the ability to expire or revoke signatures.
The authors strongly recommend avoiding the second approach, for the following reasons:
There are quite a few issues of key handling that need to be addressed in the policy of the certification authority. From the authors' experience, the following guidelines should be followed:
This topic includes two points:
The following set of rules should be included in the certification authority's policy:
Even though this skeleton policy has been created with the [DFN-PCA] policy serving as a real-world example, it differs substantially from policies as deployed by other certification authorities.
The most significant difference is the fact that the authors do not recommend inferring any meaning from a certificate other than that the key belongs to the person, as stated in the ID string. Certificates should certify the credibility of the key and not the credibility of a person or entity.
Not only does this strike the authors as being more "natural" than other models, it also greatly simplifies the whole process of key certification and running a certification authority. From everyday experience, the authors learned quickly that ease of use and ease of understanding are vital for any certification authority project and any security measure in general.
In a large organization or company, many employees will use electronic mail without knowing or even caring about the underlying principles, as they have been hired to worry about other, possibly nontechnical, things. As a consequence, they will use encryption only if it is easy for them to do so. Keeping the certification authority policy simple helps a great deal to keep the whole process simple, too.
Other changes include the removal of rules that regulate the handling of the user keys. Without a doubt, proper key handling by the users is important, but this needs to be addressed elsewhere and not in the certification authority's policy.
A certification authority (CA) consists of two parts. One part, the public CA side, can be built on an open, well-connected computer using a Web interface; the other part, the closed CA side, has to be kept in a closed environment, accessible only to the CA operators.
The public CA side is a Web server using the https protocol which is supported by almost all common browsers with a (self) signed certificate. The following steps are recommended:
For the closed side of the CA, a standalone computer is needed. It must be installed as securely as possible. Its only job is to be the CA. Access is granted to the CA operators; daily backup onto tape is necessary. Private keys and certificates of the CA are installed here and nowhere else. Only backup copies should be kept in a safe place. After verifying the user's identity, the keys must be copied from the public CA side into the closed CA side and later back to the public CA side. This can be done with floppies or a private line between the two machines (ISDN, V.24, or direct host-to-host connection). The exchange between the public CA side and the closed CA side happens manually, not via cronjobs or automatic programs. The closed CA side should not be accessible from the company's network.
Depending on the size of the company, the incoming requests can be collected for some hours, a day, or a week. At least two people should run the CA. The closed CA side is used for bookkeeping of the CA's work. The information source for all the information on the public CA side, such as CRLs and trusted key rings, is built here.
Registration authorities (RAs), as mentioned before, are easy to insert between the open CA side and the closed CA side, using signed and encrypted e-mail to transfer the requests and processed certificates.
A trusted key server is a key server that not only distributes the keys, but also guarantees the authenticity of all keys available on it.
In a X.509-like certification environment, a trusted key server is not necessary. Each application gets the public part of the CA's certification key and is able to verify all incoming certificates. Expiring is handled in the CA policy and is inserted in the certificate. The only measure is to check whether the key is revoked or not. This can be done via the CA's Web server and needs no action from the user.
Users can build their own key ring to encrypt outgoing mail, but almost all modern mailtools with S/MIME extension will use LDAP Directory Service to search for (trusted) certificates and can verify them on the fly.
For PGP keys, though, a trusted key server might be beneficial. A simple way to implement one is to take the source of one of the normal PGP key servers and to disable the upload feature. Then the system administrator can control which keys are available from the server, following an appropriate policy.
Using such a key server in accordance with a local CA is a simple way to implement a good public key ring for the whole company. The key server can, for example, be defined as being the definite source for keys of employees. If an employee leaves the company, his or her key can be removed from the trusted server, without having to revoke the signature or the whole key itself.
In a secure and private environment, encryption keys and certificates are needed. A certificate contains a public key and some additional information, much more information than a PGP or SSH key, but the base is always a public RSA key (some protocols use other encryption methods too). There are keys and certificates for personal use and for machines or services as Web servers and programs.
Although the basic encryption method (RSA) can be used for PGP, X.509, SSL, and SSH, for each of the protocols a different key or certificate is used. It would be possible to generate one single key pair and take this as input for all the above mentioned methods, but this is not supported by the individual applications. Each application generates the RSA keys itself. So there exist different nonpersonal keys, mainly SSH host keys and SSL Web server certificates, which cannot be shared among different programs. Personal key environment consists of SSH keys (authorized keys), PGP Keys, X.509 certificates for Web clients, S/MIME, and software distribution. X.509 certificates can be generated in a way such that one X.509 certificate can be used for S/MIME, software distribution, and personal identification and authentication via Web clients.
So a person will need at least one PGP key, one SSH key, and one X.509 certificate to fit most of the secure protocols in the Internet. Additionally, a SSH host key for every host and a Web server certificate for each Web server (virtual host) are needed. A suitable way to deal with these different things is to set up one CA which handles the management of all kinds of important keys and certificates for a company. Experience shows that a number of users are using PGP for e-mail and they will not replace PGP completely with S/MIME or the other way around. The company's CA should try to avoid the use of different root CAs in the company, or, if this is impossible, care for establishing all needed root CAs company-wide.
No authentication, confidentiality, or data integrity properties are provided in the most common Internet e-mail protocols like SMTP, RFC 822, or MIME. People desiring any or all of those security properties in their e-mail should look into the use of related software tools.
S/MIME was developed by RSADSI and has been specified in [RFC 2311] and [RFC 2312]. It uses X.509 certificates, RSA for digital signatures, and, in the export version, RC2 with 40-bit key for encryption. As with all X.509 based procedures, S/MIME needs certification authorities (CAs) and a directory service to hold the user certificates. S/MIME is becoming more popular since the mail reader included in Netscape and Microsoft's Internet Explorer has built-in support for it.
Each user needs its own RSA key. The key can be generated within the user's application. There is no need to hand out the private key to the CA. The public keys are embedded in a certificate, which contains some information about the user and its key, and it is signed by a CA. Commercial CAs sign user keys, but it is possible to set up a company's own CA. All user certificates can be placed in a company-wide accessible LDAP server, where unknown keys will be searched. It is also possible to store the certificates from other local users in the application's certificate store, but then the issuing CA's certificate is needed for verifying.
Certificates (and CAs) have a fixed period of validity, renewal of which is needed. This can be overhead, especially if a user stores the certificates locally in the applications, because they have to remove invalid certificates themselves. Planned expiring does not fit real life. Employees will change and suddenly their keys will become invalid for further use.
Some different (incompatible) implementations (versions) of S/MIME seem to exist whereby acceptance of certificates may not work between all of them. A central (company-wide) certificate-handling infrastructure is needed, not necessarily a company's own CA, but a maintained directory service. The parallel existence of many so-called Root CAs can lead to the necessity of maintaining more than one certificate for each user.
Because S/MIME is completely integrated in Netscape Navigator and Microsoft's Internet Explorer, there is no need to install local extensions: Standard software can be used. Another advantage is the hierarchical certification structure. Well-known trusted CAs exist; everyone can prove their keys and use them to check the presented e-mail for validity. All certificates have an expiration date; the CAs have to publish a key revocation list, which can be consulted to check a certificate. All this makes a simple, well-defined level of trust for all users.
S/MIME will work well in an intranet, best with a company's own CA. After installing an S/MIME environment, only simple key management is needed. Small companies and single persons will have big overhead to join a trusted area.
PEM is an extension of RFC 822. It provides end-to-end confidentiality, authentication, and message integrity assurance by encryption of RFC 822 messages. It is a subset of the X.400 security services, UA-level only. It can use any encryption algorithm (private and public). RSA is the default public key algorithm.
A PEM header consists of five components:
From a security viewpoint, the "Encapsulated Header Portion" is the most interesting part. It contains encryption control fields inserted in plaintext. A PEM user can choose three different types of PEM messages depending on the security services to be applied. Additionally, PEM supports the expiration and revocation of signatures and certificates.
PEM supports asymmetric and symmetric key management and a two-level keying hierarchy: Data Encrypting Keys (DEKs) are used for encryption of message text and for computation of message integrity check (MIC) quantities. In the asymmetric key management environment, DEKs are also used to encrypt the signed representations of MICs in PEM messages to which confidentiality has been applied. DEKs are generated individually for each transmitted message; no redistribution of DEKs is needed to support PEM transmission.
Interchange Keys (IKs) are used to encrypt DEKs for transmission within messages. Ordinarily, the same IK will be used for all messages sent from a given originator to a given recipient over a period of time. Each transmitted message includes a representation of the DEK(s) used for message encryption and/or MIC computation, encrypted under an individual IK per named recipient.
The PEM standard calls for key management by certificates. The key management architecture is compatible with the X.509 and goes beyond it by establishing procedures and conventions for use with PEM and with other protocols in the future.
PEM additionally describes a Certification Authority hierarchy with an Internet Policy Registration Authority (IPRA) as the root and several Policy Certification Authorities (PCAs) and Certification Authorities (CAs) with different rights and tasks.
Several implementations work with PEM such as TIS/PEM by Trusted Information Systems, RIPEM (Riordan's Internet Privacy Enhanced Mail), or SecuDE-PEM by GMD. Additionally, there are some implementations for military purposes only such as MSP (Message Security Protocol) and PMSP (Preliminary MSP).
The future of PEM depends on the number of implementations and the establishment of a certification authority hierarchy.
The most popular encryption program today is "Pretty Good Privacy," or simply, PGP. PGP was originally written by Philip Zimmermann and has since then been enhanced by volunteers all over the world. PGP is freely available from [PGP] and [PGPi].
PGP is a hybrid system, using a mixture of public key and conventional cryptography, even though this is hidden in the internals. PGP can encrypt any kind of data for one or several recipients. It can also issue and verify digital signatures.
Public keys can be revoked, if their security has been compromised, but unfortunately, this feature is not available for signatures. Nor does PGP have a feature that lets signatures expire at a certain date. Modified PGP versions have been distributed that remedy these shortcomings (see [PGPin-CH]), but these modified versions were not adopted by the general public.
Authentication of public keys is done using the Web of Trust approach described earlier, but PGP can easily be used in a certification authority scenario, too. In fact, PGP can combine the central authentication approach with the Web of Trust by setting the trust levels for the keys appropriately, which gives all the power to the user.
The most important advantage of PGP is its popularity. On the Internet, a broad variety of supporting products are available and many of them are free. These include mail readers with built-in support for PGP encrypted mails, graphical user interface front-ends, or a public key server infrastructure (see [PGP-NET]).
Furthermore, several organizations (DFN, USENIX, etc.) have already organized certification authorities for PGP keys, which can be used instead of undergoing all the effort oneself.
The task of establishing an authentication infrastructure for a mid- to large-sized organization is challenging. Currently, the available software has not matured to the point where building up a certification authority is straightforward. No matter which software will be used and which kind of policy will be deployed, running the certification authority smoothly does require some time and effort.
Consequently, organizing a certification authority should be avoided unless the organization has, say, 100 employees or more. Otherwise the effort is not justified.
People planning to organize a certification authority should also consider using one of the available certification authorities instead, rather than doing everything themselves. Most certification authorities are willing to register other organizations as independent registration authorities, as described in section 3.5.4. Maintaining a registration authority is much less trouble and should be suitable for small organizations also.
Finally, the question may arise as to which solutions should be supported by a certification authority. Should one go for PGP, PEM, or S/MIME?
S/MIME is not as widespread as PGP, which is important for e-mail contacts out of the company. Because S/MIME uses 40-bit encryption keys (512 bit RSA keys for signing), it is weaker than PGP. As commercial use of e-mail grows, however, S/MIME has a chance to become acknowledged for juridical use in opposition to PGP.
From the authors' experience, PEM is rarely used at all, mostly due to the lack of software supporting it. S/MIME, on the other hand, is supported by the mail readers incorporated into the Netscape browser and the Internet Explorer -- two programs that are available on virtually all machines connected to the Internet. Unfortunately most other mail readers do not support S/MIME at the moment, so the usage of S/MIME is limited to small, homogenous networks, where all people use these two programs.
Larger organizations, which depend on electronic mail communication with the outside world a lot, should definitely go for PGP, for the sheer popularity of the program. The chance of communicating with someone who uses PGP is higher than that of finding peers that support S/MIME or PEM.
Ultimately, certification authorities for large organizations will have to support at least S/MIME and PGP in parallel, because both implementations have their own domains, in which it is hard to go without them.