35
This method obtains the password or passphrase by reading it from the specified file descriptor. This method is really useful only when the tool is launched from another
process and not directly from the command line because the tools process must have inherited the file descriptor from its parent in order for it to gain access.
2.7 Seeding the Pseudorandom Number Generator
In Chapter 1
, we briefly discussed the need for cryptographic randomness. Well expand on this discussion in
Chapter 4 . For now, well just deal with how to seed the OpenSSL PRNG properly
from the command line. Because many of the cryptographic commands depend on random numbers, it is important that the PRNG be seeded properly.
The command-line tool will attempt to seed the PRNG on its own, but it may not always be able to do so. When the PRNG is not properly seeded, the tool will emit a warning message indicating
that the random numbers it generates will be predictable. Additionally, you may wish to use a more conservative seeding mechanism than the one used by default.
On Windows systems, a variety of sources will be used to seed the PRNG, including the contents of the screen. None of these sources is particularly entropic, and depending on the version of
Windows that youre using, the entropy sources vary. Unix systems that have a device named devurandom
will use that device to obtain entropy for seeding the PRNG. Most modern versions of Unix provide support for this device, which well discuss in detail in
Chapter 4 . In addition,
beginning with Version 0.9.7, OpenSSL will also attempt to seed the PRNG by connecting to an EGD socket to obtain entropy. By default, OpenSSL is built with four well-known names for
sockets that it will attempt a connection with.
In addition to the base entropy sources, the command-line tool will also look for a file to obtain seed data from. If the
RANDFILE
environment variable is set, its value will be used as the name of the file to use for seeding the PRNG. If it is not set, a default filename of .rnd will be used, and the
value of the
HOME
environment variable will be used to specify the location of that file. If the
HOME
environment variable is not set, as is often the case on non-Unix systems, the current directory will be used to find the file. Once the name of the file has been determined, the contents
of that file will be loaded and used to seed the PRNG if it exists. Many of OpenSSLs commands require that its PRNG be properly seeded so that the random
numbers it generates are unpredictable. In particular, any of the commands that generate key pairs always require unpredictable random numbers in order for them to be effective. When the tool is
unable to seed the PRNG on its own, the tool provides an option named
rand
that can be used to provide additional entropy sources.
The
rand
option requires a parameter that contains a list of files to be used as entropy sources. The list may be as short as a single file, or as long as the number of filenames you can fit on the
command line. Each file in the list is separated by a platform-dependent separator character rather than a space. The separator character is a semi-colon ; on Windows, a comma , on OpenVMS,
and a colon : on all other platforms. On Unix systems, each filename in the list is first checked to see if it is an Entropy Gathering Daemon EGD socket. If it is, entropy will be gathered from an
EGD server; otherwise, seed data will be read from the contents of the named file.
EGD is an entropy-gathering daemon written in Perl that is intended for use in the absence of devrandom
or devurandom. It is available from http:egd.sourceforge.net
and runs on any Unix-based system that has Perl installed. It doesnt work on Windows, but other entropy-
gathering solutions are available for Windows. In particular, we recommend EGADS Entropy Gathering And Distribution System, a C-based infrastructure that supports both Unix and
36
Windows. This is a preferable solution even on Unix machines because it is far more conservative in its entropy collection and estimation. It is even a good solution on systems with a devrandom.
In such cases, it uses devrandom as a single source of entropy. EGADS is available from http:www.securesw.comegads
. It can be used anywhere an EGD socket is expected. If Perl is installed on your system, EGD is easy to set up and run. Perl has become ubiquitous in
the Unix world, so its unlikely that a modern system does not have it installed. Because EGD uses Perl, its very portable, even though it was originally written for Linux systems. On the other hand,
EGD works by gathering its entropy from the output of running processes, a number of which produce a questionable amount of unpredictable data. Perhaps its biggest limitation is that it works
only on Unix systems.
EGADS can be a bit more difficult to get up and running, but will usually compile straight from the distribution with a minimal amount of effort. On systems that do not have devrandom,
EGADS also gathers its entropy from the output of running processes. These processes are not as widely varied as EGDs list. EGADS provides an EGD-compatible interface on Unix systems.
Because EGADS provides an EGD interface and will use devrandom to gather entropy, it provides a simplified interface for gathering entropy to clients such as those built with OpenSSL.
It also supports Windows NT 4.0 and higher, which have no built-in entropy gathering services. It does not work on Windows 95, 98, or ME. Finally, EGADS also contains a cryptographically
secure PRNG.
37
Chapter 3. Public Key Infrastructure PKI
In Chapter 1
, we described a scenario known as a man-in-the-middle attack, in which an attacker could intercept and even manipulate communications secured with public key cryptography. The
attack is possible because public key cryptography provides no means of establishing trust when used on its own. Public Key Infrastructure PKI provides the means to establish trust by binding
public keys and identities, thus giving reasonable assurance that were communicating securely with who we think we are.
Using public key cryptography, we can be sure that only the encrypted data can be decrypted with the corresponding private key. If we combine this with the use of a message digest algorithm to
compute a signature, we can be sure that the encrypted data has not been tampered with. Whats missing is some means of ensuring that the party were communicating with is actually who they
say they are. In other words, trust has not been established. This is where PKI fits in.
In the real world, we often have no way of knowing firsthand who a public key belongs to, and thats a big problem. Unfortunately, there is no sure-fire way to know that were communicating
with who we think we are. The best we can do is extend our trust to a third party to certify that a public key belongs to the party that is claiming ownership of it.
Our intention in this chapter is to give you a basis for understanding how PKI fits into the big picture. PKI is important to using public key cryptography effectively, and is essential to
understanding and using the SSL protocol. A comprehensive discussion of PKI is beyond the scope of this book. For much more in-depth discussion, we recommend the book Planning for PKI:
Best Practices Guide for Deploying Public Key Infrastructure
by Russ Housley and Tim Polk John Wiley Sons.
In this chapter, well look at how PKI functions. We start by examining the various components that comprise such an infrastructure. Then we demonstrate how to become a part of a public
infrastructure so that others wishing to communicate securely with us can do so. Finally, we look at how to use the OpenSSL command-line tool to set up our own private infrastructure.
3.1 Certificates
At the heart of PKI is something called a certificate. In simple terms, a certificate binds a public key with a distinguished name. A distinguished name is simply the name of the person or entity
that owns the public key to which its bound. Perhaps a certificate can be best compared to a passport, which binds a picture with a name, thus solidifying a persons identity. A passport is
issued by a trusted third party the government and contains information about the person to whom it has been issued the subject as well as information about the government that issued it
the issuer. Similarly, a certificate is also issued by a trusted third party, contains information about the subject, and contains information about the third party that issued it.
Not unlike a passport, which contains a watermark used to verify its authenticity, a certificate also contains safeguards intended to allow the authenticity of the certificate to be verified, and aid in
the detection of forgery or tampering. Also similar to a passport, a certificate is valid only for a defined period. Once it has expired, a new certificate must be issued, and the old one should no
longer be trusted.
A certificate is signed with the issuers private key, and it contains almost all of the information necessary to verify its validity. It contains information about the subject, the issuer, and the period
