|
This is the third article in a series on OpenSSL, a library written in the C programming language that provides routines for cryptographic primitives utilized in implementing the Secure Sockets Layer (SSL) protocol. In the first article in the series, we discussed some of the basics of cryptography. The second article showed how to use OpenSSL's openssl application to explore cryptographic basics. This article will introduce Public Key Infrastructure and show the commands that OpenSSL provides for managing PKI.
PKI Overview
TLS/SSL, the protocol implemented by OpenSSL, is most commonly used to secure electronic commerce transactions on the Internet. One of the technologies TLS/SSL depends on when used for this purpose is Public Key Infrastructure (PKI). TLS/SSL uses PKI to provide authentication of the server to the client and to optionally provide authentication of the client to the server.
Public Key Infrastructure is an information repository that ties entities to key pairs. These key pairs are suitable for use with an asymmetric algorithm. A PKI facilitates dissemination of information to a wide audience on behalf of those whose information is published in it. Let's take a look at a couple f correspondents, Alice and Bob, to see how this works. Alice publishes information such as her name, snail mail address, email address, public asymmetric encryption key, and phone number using a PKI. Bob, who wishes to securely correspond with her, uses this descriptive information to acquire her public key. He can then begin secured transactions with Alice using the public key and its corresponding asymmetric encryption algorithm.
The type of PKI that TLS uses necessitates a third party to issue certificates used to mediate the authentication between entities interested in engaging in transactions. This third party verifies that the entity requesting a certificate is who or what the entity purports to be and then issues a certificate. Third parties that broker trust in this manner are called Certificate Authorities (CA).
A certificate is the signature of a public key and information that describes the holder of the public key. The signature is created using an asymmetric cipher and a private key held by a CA. The CA's private key has a corresponding public key that is part of a root certificate. A root certificate is a public key and its corresponding information that has been signed by the private key that corresponds to the aforementioned public key. A root certificate is also called a self-signed certificate because the private key in a key pair is used to sign the public key and identifying information, instead using a private key from a different key pair to sign the public key and its identifying information.
Alice decides to go into the PKI business and issue certificates. She creates a public/private key pair and associates some descriptive information with the public key. The descriptive information she uses is "Alice's PKI Root Certificate, Alice Jones, (555)555-1212, alice@jones.com". She then takes the public key and the descriptive information and runs them through the signing operation of the asymmetric algorithm using the private key of the key pair.
When Alice's friends and family want to engage in secured transactions they come to Alice and she issues them a certificate by signing their public keys and descriptive information using her PKI's root private key, which is paired to the root public key in the PKI's root certificate.
As Alice's friends and relatives use their key pairs amongst one another for protecting valuable electronic information, they authenticate the other party by checking to see if the certificates they present to one another are signed by Alice's root certificate. Since the presented certificates are signed by Alice's root, her friends and family are assured that they are corresponding with the person that the certificate represents because Alice is trustworthy and competent enough to vet whom her friends and family claim to be before she issues certificates to them. As Alice acts as a trusted third party who issues certificates, she fulfills the role of a Certificate Authority (CA).
An additional CA duty performed by Alice is publishing the certificates that have been revoked by her Certificate Authority. She does this by creating a Certificate Revocation List (CRL) and signing it with the CA's Root private key. Alice's friends and family are expected to regularly download CRLs, verify the CRLs' signature, and check the CRLs to see if any certificates have been revoked before they accept a certificate presented to them as valid.
The last step that is necessary when using a PKI is verifying the certificate, which is often taken for granted. Persons generally accept software telling them that a certificate is okay. But when is the last time you called up the site from which you were about to purchase something and asked them to verify the fingerprint of their certificate? Additionally, CRLs generally aren't consulted. When I last investigated, Internet Explorer's CRL checking capability was disabled by default and Netscape and Mozilla didn't check CRLs at all. While it is true that software and/or hardware compute the result of the signature, this doesn't tell us if the key has been compromised. It doesn't tell us if the CA performed its due diligence to verify that the entity applying for certificate issuance was really who the entity claimed to be [MSVSCertDebaucle].
The process of verification really should include physically exchanging information with the person who the key pair and related certificate is to represent, if one desires a high level of assurance. Anything less than this, even voice verification, makes it too easy for malfeasance to take place. There are a myriad of ways to attack this process when physical exchange of information doesn't take place [Schneier2000]. Since physical exchange of information is usually not a step in protocols, be careful about how much liability you assume for the transactions you make using these protocols.
Third parties, Sometimes Trusted
There are a few ways that an entity can satisfy SSL/TLS's requirement for a PKI. One is to create your own PKI and issue certificates for it yourself. This PKI could be used externally, internally, or both. The second is for you to outsource the maintenance of the PKI and have someone else assume the CA role. The motivations for either approach vary from situation to situation; however, there are a few questions that can be pondered that might lead one to a conclusion.
- Will the parties using the CA be external to the organization, internal, or both?
- If external entities are involved, are there existing trust relationships that that could be leveraged without involving a third party?
- How much will liability be assumed for the transactions that occur?
- Do the transactions need to be insured because they represent a tangible or an intangible that holds value of significance?
- Are resources for providing a PKI available in-house?
- Is either party's industries highly regulated?
- Will SSL be used to protect E-Commerce ?
If external parties are involved, there is money involved, a relationship is not yet already established with the other party, if insurance is needed, liability is incurred, in house resources aren't available, E-Commerce is being conducted, or one or both entities belong to a highly regulated industry, it may be advisable considering the possibility of outsourcing your PKI [Google2001]. Further consideration on the merits and detractions of outsourcing PKI are outside the scope of this article [OutsourceCite].
Because one of the more common uses of TLS/SSL is to secure electronic commerce transactions, it is likely that most persons will choose to have their certificates issued by an external Certificate Authority which has its own PKI that it administers. This is usually the route that is chosen because the root certificates for many CAs are already in web browsers. Choosing these CAs means that consumers won't see messages that complain that the certificate was issued by a CA that the browser doesn't know about (try pointing your browser to the SSL connection test site if you wish to see that message)
I have put together a list of instructions on how to view the certificate store of some common browsers if you need to shop for a CA and are using "certificate already in browser" as a selection criterion. These instructions are available here. If you choose to roll your own, read on.
An Introduction to ITU X.509
There are several types of PKI that exist today. The PKI that SSL uses, X.509 [ITUX509], is based on X.500's [ITUX500Cite] authentication standard. One of the assumptions of some proponents of the X.500 specification was that there would be one über directory into which all identifying information would be published. A corresponding über PKI would be based on this directory to end all directories. This means that each of us would have a record that contained all pertinent identifying information including a certificate. This certificate would be vouched for by an über trusted third party and .
The reality of life is that there are many PKIs based on X.509 that use their own directories, not a centralized behemoth. Netcraft's January 2001 SSL Web Server Survey [Netcraft2001] showed that Verisign (holder of the RSA Data Security root) just edged out Thawte Digital Certificate Services as the most commonly used PKI for TLS/SSL. These are just a couple of the Certificate Authorities (CA)s that provide services based on PKI [Google2001]. These citations only account for a portion of the PKIs that are commercially available. Additionally, there are Certificate Authorities that maintain multiple PKIs with which they service their customers, and internal PKIs at various organizations and institutions. Thus, the discombobulated idea of a single über directory and/or Certificate Authority didn't pan out.
The X.500 directory structure can be visualized as an inverted tree. One can think of a trunk floating in the air, instead of being planted in the ground. The top or root of the tree is the uppermost node. For those of you still in a zen like trance busy with visualization, this would be the floating trunk.
The first level of nodes that branch from the root (trunk) are the country of a Distinguished Name (DN). The next level is the state or province name, followed by the locality (city). Succeeding that is the name of the organization. The organization contains an organizational unit. The last level in our example is a common name. If one follows a path from the root (trunk) of the tree to the furthest node level possible, one has traveled from the most general node of a Distinguished Name (DN) to the most unique node. Beginning from the root, a DN is composed of a country, a state or province, a locality, an organization, an organizational unit and at least a common name.
To give an example of a DN, let's take a look at a hypothetical friend, let's call hime Fookie Barenta. We can uniquely represent our friend Fookie Barenta with the following DN:
CN=Fookie Barenta,OU=Bazmatic Department,O=Foo's Bar and Pub,L=Edinburgh,ST=Scotland,C=GB
Distinguished Names can also contain other information to more fully describe the value of the common name. Some examples might include: 'mail' for an e-mail address, 'street' for the street address, the 'telephoneNumber' of the common name, and even a 'jpegPhoto' of the common name. An attribute that is commonly stored in a directory that is being used as a Public Key Infrastructure (PKI) is the 'UserCertificate' attribute.
X.500's method for authentication is codified in the X.509 standard. The most current iteration of the standard is version 3. X.509 includes several methods for authentication. The class of authentication methods that we're interested in, strong authentication, utilizes certificates to authenticate users to the directory. SSL abstracts this idea from authenticating access to directory resources to a more general purpose, that of authenticating servers and clients to one another. X.509 heavily depends on another ITU standard, ASN.1 for encoding the certificate. ASN.1 allows standards writes to describe how data should be structures without being tied to a specific programming language or protocol.
Let's Get Busy...
If OpenSSL isn't already present on your system, you can refer to [ArticleOneAcqandCompile] so you can continue with the exploration of the commands below. If you have created the links (symbolic or hard) that are discussed in Acquiring and Compiling OpenSSL, then you can omit the openssl portion of the commands below. Also, users of operating systems that don't have a /dev/random-like device that OpenSSL is aware of need to generate cryptographic randomness and use the -rand command line option. See the "Randomness" section and "Generating a Seed" from the second article in this series for more information.
We are going to create a certificate authority and then issue a certificate. We will use DSA as the signature algorithm. An RSA based CA will be left as PT (physical training) for the reader.
First we need some DSA parameters. These can be generated by using:
openssl dsaparam 2048 -out dsaparams.pem
Now generate a key using:
openssl gendsa -out dsarootkey.pem dsaparams.pem
In order to generate the root (self-signed) certificate, we use the command:
openssl req -newkey dsa:dsaparams.pem -keyout dsarootkey.pem -new -x509 -days 365 -out rootcert.pem
Answer the questions however you want, although it is probably a good idea to identify this as a test or experimental root certificate when you are prompted for the common name. Congratulations, you've created your first root certificate using OpenSSL.
To see the detailed information of what you created you can use:
openssl x509 -text -in rootcert.pem | more
One can view the ASN.1 structure of the certificate with the command:
openssl asn1parse -in rootcert.pem | more
Now let's generate a certificate request so we can issue a certificate with the root certificate just created. First we need to generate a certificate request and a key with:
openssl req -newkey dsa:dsaparams.pem -keyout dsakey.pem -new -days 365 -out dsareq.pem
Unless you have a need for the extra attributes (challenge password and optional company name) you can just hit enter in response to them. Notice that in the req command above, we used req to generate the key instead of generating the key separately. If you're into saving steps, this probably isn't a bad idea. If you are so inclined, you can view the certificate request with:
openssl req -text -in dsareq.pem |more
You can issue the certificate with:
openssl x509 -days 180 -CA rootcert.pem -CAkey dsarootkey.pem -req -CAcreateserial -CAserial ca.srl -in dsareq.pem -out newcert.pem
If you already had issued a certificate with this root certificate you would omit the option -CAcreateserial because a serial number file would already exist. You can view your issued certificate with:
openssl x509 -text -in newcert.pem | more
You can also use the asn1parse if you wish.
The interesting thing to note when viewing the certificate issued by your test root certificate is that the Issuer and Subject are not the same, indicating that this is not a root certificate, as expected. The command line for the surprisingly-named verify command is:
openssl verify -CAfile rootcert.pem newcert.pem
Maintaining a busy CA with OpenSSL by hand would rapidly become tedious. A script would help significantly improve the situation, and OpenSSL includes a plain vanilla one called CA.pl that, as you might guess, depends on perl. Consult the CA.pl(1) man page for more information.
OpenSSL also includes a rudimentary ca program. I wrote a shell script to help setup files and directories properly for the ca program. Run the script as follows: demoCA yes /tmp/test_ca. Now change directories to /tmp/test_ca. Now customize the ca.conf file in /tmp/test_ca to your environment.
Use the following to create a root certificate:
openssl req -days `expr 5 \* 365` -x509 -new -newkey rsa:2048 -config ca.conf -keyout private/cakey.pem -out cacert.pem
Now generate a few certificate requests, the common name should be different for each one you create:
date=`date "+%m%d%Y%H%M%S"`;openssl req -new -nodes -newkey rsa:1024 -config ca.conf -keyout private/test_key_${date}.pem -out reqs/csr_${date}.pem
Now you can issue certificates for the certificate request you just created:
openssl ca -config ca.conf -verbose -days `expr 2 \* 365` -infiles reqs/csr_082220010638*
Revoke a few certificates so that the CRL will have some entries:
openssl ca -config ca.conf -verbose -revoke newcerts/02.pem
Now generate a CRL for your CA:
openssl ca -config ca.conf -verbose -gencrl -out crl_current.pem
If your user population utilizes web browsers, learning how to export and import certificates from the browsers is useful. Because there are several types of browsers out there, they have their own documentation, and this article is not about mangling browser configurations, we'll forego that tangential trip. However, the OpenSSL developers have provided several utilities that are useful when fighting browsers. They are: spkac, nseq, pkcs7, pkcs12, and pkcs8. For more details on PKCS refer to [PKCSCite]. If you wish to explore the contents of the certificate stores web browsers, you can refer to [CertStoreCite].
As you issue certificates, be careful to make sure that you don't issue certificates for longer than the lifetime of the root certificate because OpenSSL doesn't check to see when the root certificate expires.
Congratulations, now you have a working PKI based on OpenSSL. If you wish to create a PKI that scales, using the OpenSSL commands is probably too arduous. However, for small projects, OpenSSL's commandline interface is a decent choice.
To read An Introduction OpenSSL, Part Four: The SSL and TLS Protocols, click here.
Holt Sorenson works for Counterpane Internet Security where he wrangles tuples of bits so his colleagues can get their work done. He's always serious and never jokes or laughs. When he is not surgically attached to computers he likes to hang out with his family and engage in frivolous pursuits that purportedly keep him out of trouble.
Bibliography
[OSSLupdate]
Levitte, Richard.
"Announcement: OpenSSL version 0.9.6b released".
http://www.openssl.org/news/announce.html
Bodo Moeller.
"Weakness of the OpenSSL PRNG in Versions Up to OpenSSL 0.9.6a".
http://www.nosneros.net/hso/publications/referenced_material/openssl_prng_advisory.html
Knoble, Jim.
"OpenSSL-0.9.6a has security fixes".
http://www.securityfocus.com/archive/1/179451.
[ENGREADME]
OpenSSL maintainers.
"README.ENGINE" in OpenSSL-Engine source.
[Callas1996]
Callas, Jon.
"Using and Creating Cryptographic-Quality Random Numbers".
http://www.merrymeet.com/jon/usingrandom.html.
[egd]
Warner, Bryan.
"Entropy Gathering Daemon (EGD)".
http://www.lothar.com/tech/crypto/.
[Callas1998]
Callas, Jon; Donnerhacke, L.; Finney, H.; Thayer, R.
"RFC 2440: OpenPGP Message Format".
http://www.rfc-editor.org/rfc/rfc2440.txt.
[Ellison2001]
Ellison, Carl.
"My Padlock".
http://world.std.com/~cme/html/padlock.html.
|