|< Day Day Up >|| |
The public key infrastructure (PKI) standard provides a method of transmitting data and exchanging money securely across insecure networks. A PKI is a network of services, procedures, and encryption software that work in conjunction to create a secure loop. At the heart of a PKI system is the Certification Authority (CA). The CA is a trusted third party that centralizes the issuance, management, renewal, and revocation of Digital Certificates. PKI employs a complex, multifaceted set of standards, procedures, and policies that are outlined in the following sections.
A digital certificate contains a few vital pieces of information that vary depending on who or what it is certifying. These elements typically follow a format defined by the X.509 standard. A common certificate is comprised of the following:
Identifying information: This includes the name and other identifiers of the entity in question. This could be an individual’s full name, e-mail address, photo, and so on. For a server certificate, this section might contain the server’s host name, IP address, and other information.
The public key: This is simply the public-key data of the certificate holder. These days, the public key will most likely be an RSA key. However, some certificates might use another form of asymmetric key.
The signature of the Certification Authority (CA): This element of the certificate is what validates the whole package. When the CA applies their Digital Signature (DS) to the certificate, they are in effect making the statement that the information it contains is true. Because a CA is putting their name on the line here, you can be sure that they will confirm this information themselves before signing it. This can be accomplished by any number of electronic and/or paper-based authentication methods.
When a DS is checked and verified by an individual or their software package, it can be assumed that all of the other data contained in the certificate is factual. Note that a private server within an intranet can be used to issue certificates exclusively to company employees or guests. In this private setting, authentication methods can be customized to fit the needs of the organization and would likely be less severe than those used in a public setting.
A CA is the trusted body that issues and manages certificates.
There are two basic types of certificates–server and personal. Each is assembled in a similar manner while serving different purposes.
A server certificate can be put to use for many reasons. For example, a company that issues software updates online might have a certificate on the Internet server that hosts the updates. When a user requests an update, their software contacts the server to see if one is available. If there is an update and the user selects a download, the software can initiate the validation process. The server hands over the certificate, the software checks the DS, and if everything looks good, the update is applied without the user being bothered by the whole process. If not, the user would be warned of the bad certificate for several reasons such as an expired certificate. This prevents corrupted or altered versions of the software from making their way into a user’s system.
If a company wishes to conduct secure transactions on their Web site, they would likely employ SSL. To put SSL to use, the server needs a certificate—preferably one from a well-known, trusted source. To obtain an SSL Web server certificate from a trusted entity for use in e-commerce, a company must first prove several aspects of their identity including their right to use the company name, their right to use the domain name, proof of phone numbers, and so on. An issuing CA might ask for bank statements, phone records, copies of passports or drivers licenses, fictitious name records, tax records, articles of incorporation, and so on. Simply put, you can’t just ask for a certificate and then open shop—you will need to convince the CA of your identity and your legitimacy.
There is also a fee involved when obtaining such a certificate. However, the CA is not in business simply to sell certificates—they are after a much more lofty goal. The CA seeks to provide the Internet community with a quick and reliable way to help decide whether or not to do business with a particular company. The trusted certificate in this scenario ensures potential customers that data transfers between them and a company’s server will not be intercepted and that the company has proven itself to be a stand-up operation.
A personal certificate, which can be obtained at no cost from some CAs, enables users to sign and encrypt transfers such as e-mail messages. The steps in this process are as follows—note that they employ the use of public-key cryptography.
Two users, Bryan and Drew, want to share some classified data over the Internet. Bryan has chosen the PKI method for the secure transmission and has obtained a digital certificate that proves his identity. To enable these users to exchange encrypted messages, Drew must get his own digital certificate. Drew then contacts a CA, proves he is indeed Drew, and is issued a certificate. Within the certificate is information about who Drew is, a copy of his public key, the CA’s digital signature and an expiration date. Drew will also receive the other half of the key pair—the private key—which he will keep to himself.
Now that the CA has established Drew as a public key holder, Bryan can obtain Drew’s public key (as easily as anyone else can) from a certificate management system. Bryan can compose his secret message and instruct his PKI software to use Drew’s public key to encrypt the message. Bryan’s software will also use his own private key to create a digital signature that will be attached to the message. The digital signature simply proves to Drew that Bryan did indeed compose the message.
Now the message is wrapped up in its digital envelope, signed, and sent to Drew. These steps ensure that only the intended recipient will be able to read the message and if its contents are altered in transit, the recipient will know about it. Drew receives the encrypted message and uses his private key to decrypt it. Because the message was encrypted with Drew’s public key, only his private key can unlock it. Furthermore, using Bryan’s public key, Drew can authenticate the digital signature contained in the message, proving that the message is really from Bryan.
PKI attempts to emulate the paper world by providing confidentiality, authentication, data integrity, and accountability to digital correspondents. Depending on the software used, these steps are nearly transparent. We might call the process translucent to the user, as there are a few steps that at first can confuse and/or vex a novice.
PKI has its share of critics because the process is not as easy as people would like it to be. Which CA can really be trusted? There are so many to choose from. On which digital key chain should all of these keys be kept? If keys are left on a work computer then messages can’t be read at home. Also, keys are only as safe as a computer.
Despite its shortcomings, PKI provides a pretty solid method for secure communications. As far as future PKI systems are concerned, ease of use shouldn’t come at the cost of a decreased level of security. However, until this process becomes more convenient, the Internet community might not embrace PKI as their standard for secure messaging.
In the preceding e-mail scenario, the users take an active part in exchanging keys and certificates. In other situations, your software program or browser does all the work and you might not even know that a certificate was involved. When dealing with certificates, whether behind-the-scenes or directly, it’s important to know that the decision to trust an individual certificate is ultimately up to the certificate user. Luckily, there are some measures in place that assist in making this decision. Upon issuing a certificate, a CA is declaring that the public key (and other information) is bound to the individual or organization listed on the certificate. To supplement or limit that declaration, a CA can provide additional information in the form of standardized policies and statements.
As an amendment to the X.509 standard, a process of associating a certificate policy (CP) with a certificate was introduced. A CP is a collection of rules that states how an individual certificate pertains to a particular function and/or set of functions that share similar security demands. The CP exists to protect both the certificate user and issuer (the CA).
Upon examination of a CP, a certificate user can get the extra information needed to decide if the certificate is trustworthy. Likewise, upon association of a CP with a certificate, the CA is, among other things, protecting themselves from claims of loss or expense associated with certificate misuse. Represented within a certificate by a unique Object Identifier (OID), typically, a CP is detailed in additional documentation available from the CA. This information can be outlined in print and made available on the Internet. As described in RFC 2527, a certificate contains three extensions (or fields) that support the CP: Certificate Policies extension, Policy Mappings extension, and Policy Constraints extension.
This extension, which has two variations, details the intended uses of the certificate. The first variation, called noncritical, lists the CPs that apply to the certificate in question. It is known as noncritical because the certificate is not limited to the uses outlined in the respective CPs. The other variation, called—you guessed it—critical, has a slightly different purpose. This type of certificate policies extension defines the restricted uses of the certificate as outlined in a particular CP. Also, this extension can include a pointer to a CA’s certification practice statement (CPS), which we’ll discuss shortly.
This field is solely intended for use in CA certificates or certificates issued to one CA from another. It is found in certificates when two organizations have agreed to cross-certify one another’s PKI. This extension defines the CPs that are predetermined to be interchangeable between the two entities. This provides an easy way of mapping CPs that exist in both organizations without the overhead of redefining rules within certificate-dependant applications.
The constraints field can define one of two desired types of certification path behavior. A certification path is simply a hierarchical flow of trust between issuing CAs, similar to the trust between domains within a local or wide area network. The first choice inhibits policy mapping by disabling additional certificates in a certification path after a predetermined number of additional certificates have been issued. The number can be set to zero, if desired. This protects CAs from transitive trust security issues. If CA-1 trusts CA-2 and CA-2 trusts CA-3 but CA-1 does not wish to trust CA-3, CA-1 could disable policy mapping.
Conversely, the other option requires the enforcement of an explicit CP in a certification path after the issuance of a predetermined number of additional certificates. Instead of cutting ties a few steps down the path, this option simply enforces a CP once the CA in a trusted domain is effectively certifying outside that domain.
The CP exists to protect both the certificate user and the CA.
The certification practice statement (CPS) is simply documentation containing a CA’s rules and regulations regarding certificate usage. It outlines the details of how a particular organization operates its network of trust.
A CPS is sometimes considered part of the agreement between a CA and a certificate user. This is a declaration that each CA customizes based on its own strengths and areas of specialization. Although it’s recommended that any standards in use by a CA be discussed within a CPS, it has no set syntax or precise format. The CPS exists to provide information to potential certificate users or prospective partnering CAs. This information can assist individual users with any questions of trust they might have. It also provides an easy way for potential partnering CAs to determine if the technology employed by the CA in question is well suited for interoperability with their systems.
VeriSign, Inc., a leader in the field of electronic trust services, has a CPS posted on their Web site that outlines their practices and procedures. If you happen to be near a terminal, the latest version can be viewed at https://www.verisign.com/repository/CPS/.
A CPS will include instructions for certificate use and a CA’s provisions on how it suspends, revokes, or destroys certificates.
When any certificate is issued, it is given an expiration date. This can be any amount of time but typically you’ll find that the average certificate lasts for a year or so. When the certificate expires, a new one must be issued in its place. The main reason for this should be obvious; certificates are like driver’s licenses or credit cards. It’s just a bad idea to have valid certificates hanging around out in cyberspace for decades. Also, the more a particular public key is used, the more clues a hacker can gather to determine its private component.
There are occasions, however, when a certificate must be revoked before its actual expiration date. This might become necessary if the private component of a key pair is lost or discovered by a third party. Another reason could simply be that some of the supplementary information within a certificate has become outdated, necessitating a reissuance.
Most CAs also facilitate the suspension of certificates. Suspension might occur if the certificate in question is associated with a temporary problem and after the problem is fixed, the certificate will be listed as valid once again. There are several methods that enable software to determine if a certificate has been revoked or suspended but we’ll discuss the two most common, CRL and OCSP.
The CRL is the most widely used method for certificate status lookup. This list, which is made available on the Internet, can be queried via LDAP or transferred via HTTP or other means. When any certificate is issued, it is also assigned a unique serial number. The CRL contains a searchable database of all revoked certificates from a particular CA. When a program queries this list, it submits the serial number and obtains the certificate status in return. If a revoked, expired, or suspended status is returned, the application will reject the certificate. A software program might query a CRL only when needed or periodically download the entire list and check certificate status on the local machine.
An OCSP server (or responder) is at the heart of this newer method for checking certificate status. One advantage of this protocol is that it can operate across TCP/IP networks in conjunction with the most common protocols. This enables an easier implementation of status lookup in client applications. Because OSCP supports the typical client/server method of data retrieval using TCP/IP standards, it’s more compatible with applications and networks already in place. OCSP is touted as either a substitution or a supplementation to a CRL as most OCSP servers are getting their information from a CRL anyway. OSCP just packages the data in a form that’s easier to retrieve and can also supply additional information not available in a CRL.
As we learned in our discussion of certificate policies, it is common practice for CAs to cross-certify each other’s PKI. This enables organizations to expand their base of trusted individuals and entities. Remember, a CA can still control the depth of trust regarding a specific certificate through the use of CPs. This type of cross-certification is a variation of the hierarchical trust model. A trust model is simply a series of rules that tells an application how to decide whether or not a certificate is legitimate. For our purposes, we’ll discuss the two basic categories of trust models: hierarchical and Web-of-trust.
This trust model (also called the CA model) is the basis for most certification systems in use. It is now the traditional model in use by large-scale certification authorities. In this model, certificate users place their trust in the CA instead of trying to come to their own decisions regarding the authenticity of a certificate. Once you feel that you can trust a certain CA, you are essentially agreeing to trust every other certificate the CA vouches for.
Hierarchical trust places the CA at the top level and the trust flows all the way down to the end user. This makes it easier for users because the burden is out of their hands. It’s important to note that if a CA that you trust is cross-certifying another CA’s PKI, your system will accept automatically the certificates of that CA as well. In high-risk situations, this might be undesirable. Comprehensive knowledge of a specific CA’s practices is your only protection against unwittingly accepting the certificates of strangers. Know your CA well!
This model is best known for its implementation in PGP. In the Web-of-Trust or keyring trust model, there is no centralized organization making the decisions. The users decide whom to trust based on personal knowledge or on the opinions of other users that they already trust. For instance, if someone you know personally hands you their public key, it’s safe to tell your software that the key is trustworthy. This is accomplished by signing the key. Later on, a user who receives your public key can determine the keys you’ve signed. If they decide to trust you and sign your key, they are in turn making the decision to trust all whom you trust. This is how the Web-of-Trust grows.
PGP servers maintain a database of keys and the signatures that have been added to them. This method works great for small groups but corporate or government environments usually require a centralized system. In fact, the X.509 certificate standard used by CAs does not by design allow this type of trust model. The main problem with a Web-of-Trust is thecareless or malicious user who signs bad keys. If just one person in the Web-of-Trust turns evil, the whole group can be affected.
The trust model that an organization chooses depends on their particular needs. There are also new and crafty ways that enable the combination of both of the aforementioned models. These implementations grow with the research of the cryptographic community and are only limited by the imagination of software developers.
|< Day Day Up >|| |