CHAPTER 7
Public Key Infrastructure
We’ll Cover
What is Public Key Infrastructure (PKI)? Components of PKI Fundamentals of PKI Applications of PKI Process of PKIWe have covered a lot so far in this book, and in this chapter we will cover something known as PKI, or Public Key Infrastructure. PKI is an important component of today’s world and in fact can be said to be the “glue” that holds together and enables many of the services we may take for granted.
Without PKI, many of the processes and technologies we enjoy would not even be possible, or at least not be possible in their current form. So what technologies depend on PKI? Well, the answer is many, so many in fact that we couldn’t possibly list them all here, but the short list includes:
E-commerce applications, such as those used by Amazon.com Financial applications, such as those for logging in to your bank account online to manage your account details or to pay a bill Webmail systems, which use protected communications to safeguard your credentials, including username and password, as well as your e-mail messages Common Access Card (CAC) systems, which are used to safely and securely log in to computer systems and networks such as those used by the U.S. GovernmentEssentially all these systems require a secure means of transferring information, and PKI facilitates that transfer for us and makes these and other systems possible.
Your Plan
By the end of this chapter, you should be considering and envisioning the ways that PKI may be of help in your organization or in the projects you may have. If you work in an environment where a PKI system is already present, think about why your company may be using the system and what this means to you.
So What Is PKI?
A PKI system can be a lot of different things, but the most prominent and obvious is a system that provides safe and secure communication over an insecure medium. The system also allows for the validation of credentials, known as digital certificates, that themselves are the cornerstone of the system.
PKI is by far the most common implementation of several of the cryptographic systems we have discussed in this book. As has been mentioned, PKI facilitates the mechanism through which two parties can confidently communicate over an insecure medium. So how does it do this? This is both an easy question and a complex one, as you’ll see as we break into the actual technical details of the system. First, let’s start with the basics.
LINGO
PKI or Public Key Infrastructure is combination of software, hardware, and policies used to secure communications. The system itself is platform agnostic (in other words, it doesn’t depend on a specific technology or environment; rather, it depends on the mechanisms to maintain a standard).
Let’s assume a situation where two parties need to communicate: We’ll call them Farore and Nayru. The problem is that neither of these two actually know the other directly, nor do they have any sort of prior relationship. So how do these two parties establish a secure channel for exchanging information if no prior relationship exists? Well, it just so happens that both these parties trust a third party, who we will say is named Din. Because both parties trust Din, they can inquire as to the trustworthiness of the other through Din. In other words, Farore can ask Din whether Nayru is okay, and Nayru can ask Din whether Farore is okay. It is through this use of a trusted third party that two parties with no prior relationship can work together.
TipIf it helps, think of the trusted third party as the person your best friend introduces you to. You may not know the person, but because your friend trusts them and you trust your friend, you trust this person as well. Simple analogy, but it does work for us at the most basic level.
PKI is vitally important to us mainly due to the complexities and realities of cyberspace and the Internet that make a trust relationship trickier to establish; in other words, one cannot just walk into a location and verify that it is trustworthy. In fact, the vendor you may be dealing with in today’s world online may be on the other side of the planet. In these situations, it is more than possible there may not even be a physical location at all to trust. PKI was made to address these concerns and bring trust, integrity, and security to electronic transactions. The PKI framework exists to manage, create, store, and distribute keys and digital certificates safely and securely. The components of this framework include the following:
Certificate authority (CA) The entity responsible for enrollment, creation, management, validation, and revocation of digital certificates. Registration authority (RA) The entity responsible for accepting information about a party wishing to obtain a certificate. Note that RAs do not issue certificates or manage certificates in any way. Certificate revocation list (CRL) A location where certificates that have been revoked prior to their assigned expiration are published. Digital certificate A piece of information (much like a driver’s license in the real world) that is used to positively prove the identity of a person, party, computer, or service. Certificate distribution system A combination of software, hardware, services, and procedures used to distribute certificates. NoteDon’t sweat the details yet, because each of these items will be discussed in this chapter and put into context within the system so as to give you the best view of what the system looks like.
Before we go too far, let’s look at each of the components involved in PKI just so we can make sure we are on the same page and have all the information we need to put everything together. Here are the components from previous chapters we need to make this work:
Symmetric encryption Asymmetric encryption or public/private key cryptography HashingLet’s take another look at each briefly.
Symmetric Encryption
As we explored a few chapters ago, symmetric encryption is a form of encryption that uses a single key to perform both encryption and decryption.
In this form of encryption, unencrypted data known as cleartext or plaintext is fed into the encryption process, where it is transformed into ciphertext. The plaintext is fed into the encryption algorithm along with a specific key chosen from the keyspace at random that is used to come up with the specific settings for a given encryption process. The process cannot be reversed from ciphertext to plaintext if one does not posses the correct key, which is the intended effect.
LINGO
Remember, a key is used to determine that specific settings for a specific encryption session. Although many potential keys are available in the keyspace, only the one used to encrypt in the symmetric encryption process can be used to decrypt. Always remember that keys represent a significant and substantial factor in determining the effectiveness of a given encryption session.
As you saw earlier, one of the defining characteristics of the encryption process is the fact that the same key is used to encrypt and decrypt. This immediately tells us that the key must be safely and securely distributed to all parties without comprising the secrecy of the key itself. Therefore, a mechanism must be in place to distribute these keys, and this is a role that PKI can fulfill. With PKI, if implemented correctly, the keys can be distributed safely without the worry of a third party getting their hands on them.
Here’s a list of some of the more common symmetric systems:
3DES An extended, more secure version of DES that performs DES three times Advanced Encryption Standard (AES) A replacement for DES that is more resistant to attack Blowfish A highly efficient block cipher that can have a key length up to 448 bits International Data Encryption Algorithm (IDEA) Uses 64-bit input and output data blocks and features a 128-bit key RC4 A stream cipher designed by Ron Rivest that is used by WEP RC5 A fast block cipher designed by Ron Rivest that can use a large key size RC6 A cipher derived from RC5 NoteWe discussed a lot of different algorithms in the chapter on symmetric algorithms. The ones listed here are just meant to refresh your memory on the different ones that can be used along with a PKI system. I have chosen the most commonly used ones, just to keep things simple. In fact, as you learned earlier, at this level the different algorithms all essentially look the same on the outside; it is just a case of being implemented differently on the inside.
Asymmetric Encryption
One of the biggest players in PKI is the asymmetric encryption system. In fact, as you’ll recall, the algorithms in this class are also called public/private key encryption systems. This is a description that will come into play in this chapter and will undoubtedly make much more sense to you after all is said and done.
Asymmetric systems are sometimes called public key cryptosystems, which is in fact the name they are commonly known by. In this type of system, whatever is done with one key can only be reversed with the corresponding key, and nothing else. This key pair is generated with one key being held in secret and the other one distributed publicly. In fact, by their very design, these systems are set up so everyone and anyone has access to the public key whenever they want. However, by the same token, the private key is only accessible or available to a small number of individuals—or even just one individual. Whoever has access to the public key can encrypt or decrypt data, but can never do so at the same time to the same chunk of information.
TipYou need to keep in mind that in practice the only real difference between a public key and a private key is access (or who possesses it at any time). You learned before that when a key pair is generated, either key, by definition, can be given to an individual for their exclusive use. Once this is done, this key becomes that person’s private key and needs to be secured. This means that, on the other hand, the other key is put in a commonly available and publicly accessible area where it is now labeled the public key.
With asymmetric systems, much like with symmetric, a number of algorithms are available. Some of the more common ones are listed here for reference:
Diffie-Hellman Developed in 1976, this process is used to establish and exchange keys over an insecure medium Elgamal Functions by calculating discrete logarithms instead of the factoring of large numbers Elliptic curve cryptography Commonly implemented on mobile devices or devices with lesser processor power or battery power RSA Widely used in various applications and processes such as e-commerce and comparable applicationsWe care about asymmetric encryption in this chapter because it gives us something we need for PKI: an answer to the problem of key distribution. Whereas symmetric encryption uses the same key to encrypt and decrypt, asymmetric uses two related but different keys that can reverse whatever operation the other performs. Unlike symmetric systems, the unique design of asymmetric systems does not compromise the secrecy of the other key in any way whatsoever. We can safely distribute the public key and can pretty much not worry about compromising security in any way. This public key can be used by anyone needing to send a message to the owner of the public key. Because the public key only encrypts and cannot decrypt anything it has performed the operation on, there is no fear of unauthorized disclosure.
Hashing
The conversion of plaintext to ciphertext is not the only function that cryptography performs, and the science of hashing proves that. Hashing is strictly a one-way function that is designed to do what the other forms of cryptography cannot, which is to verify the integrity of information. As you may recall, a hashing function is designed to derive a fixed-length value from a piece of information. This fixed-length value is relatively easy to calculate in one direction, but is not easy to do in the other.
TipThink of the one-way function as something that is easy to do one way and not the other. Consider, if you will, three large numbers, any three. Using a calculator, it is relatively easy to multiply these numbers together to get a final result, but taking the final number and trying to figure out the original three numbers is quite hard.
This process allows for the unique and powerful ability to verify information and to detect but not prevent changes. In fact, any change will result in a value that is radically different from the one before the change is done.
NoteIt is important for you to realize that the process of hashing does not provide data confidentiality; it provides the ability to ensure integrity only. Hashes are used to create and verify the unique digital fingerprint for a file. Due to the design and functioning of a hash, a change can be readily detected, but its exact location within the file is quite difficult to ascertain. Because the process provides the ability to detect changes, it is commonly used to detect alterations in data and files due to any sort of expected or unexpected behavior.
Hash functions create a fixed-length value that is generated by computing the hash from the plaintext that is put into the process. Once the hash is generated from this process, it becomes essentially impossible to reverse to get the original plaintext that generated it—although some would say it is “mathematically infeasible.”
In our system of PKI, you should remember that hashes provide the ability to verify the integrity of transmitted messages. A sender could easily create a message hash and send it on its way, giving the receiver the instructions as to how to repeat the process. In fact, we will use this exact same process later on when we discuss digital signatures and how PKI figures in.
Some of the most common hashing algorithms include the following:
Message Digest 2 (MD2) A one-way hash function used in the Privacy Enhanced Mail (PEM) protocols, along with MD5. Message Digest 4 (MD4) Provides a 128-bit hash of the input message. Message Digest 5 (MD5) An improved and redesigned version of MD4 that produces a 128-bit hash. NoteMD5 figures prominently into digital certificates, as you will see in a moment.
HAVAL A variable-length, one-way hash function and modification of MD5. Secure Hash Algorithm-0 (SHA-0) Provides a 160-bit fingerprint. SHA-0 is no longer considered secure and is vulnerable to attacks. Secure Hash Algorithm-1 (SHA-1) Processes messages up to 512-bit blocks and adds padding, if needed, to get the data to add up to the right number of bits.Digital Certificates
As you’ll recall when we spoke about asymmetric encryption and symmetric encryption, one of the many issues at play is key distribution. And one of the problems that goes along with this is how to identify the user or holder of a key. This is one task that PKI is intended to handle. The core item that assists in identifying the holder of a particular key is the digital certificate. Figure 7-1 shows the SSL process with attention paid to certificates.
Figure 7-1 The SSL process
In all types of transactions, certificates provide several services:
Identity The binding of a public key to a party such as an individual, organization, or any other entity that needs to prove its identity. Authority A list of the actions the holder of the certificate is allowed to exercise, much like a driver’s license authorizes an individual to operate certain vehicles. Secure confidential information Used to keep information private and safe from unauthorized access TipDigital certificates are used for many purposes within many systems, such as SSL and digital signatures. Many of the mechanisms you rely on to safely and securely communicate would not even be possible without the use of digital certificates.
Consider the issues in the systems we have discussed so far if a key is distributed to a given party. If the key is presented by one party to another, the receiving party must take it on absolute trust and faith that the presenter is who they say they are. The recipient, as of yet, has no way of positively identifying whether the owner is who they say they are—which can be a problem. Additionally, the presenting party is also making a claim that they are authorized to use the key for what they are actually attempting to use it for. Let’s look at this problem from another perspective to make things a little clearer. Consider a situation where I, your humble guide, present a credential (such as a driver’s license) to you. You have to take it on faith that the credential is valid and not the fake one I used in college (long story). So that you don’t have to do this, I present you with an official document that you can verify by checking with a third party you trust (which would be the DMV—or in the case of digital certificates, something known as a certification authority). A digital certificate, as presented to a web browser, is shown in Figure 7-2.
Figure 7-2 A digital certificate as presented to the Firefox web browser
NoteYou can consider certification authorities as the issuing authority for digital certificates, kind of like the DMV is for driver’s licenses.
In the case of digital certificates, you get the ability to verify whether the holder is doing something for which they are authorized.
A digital certificate is not an overly complex topic if you think of it as a driver’s license, but on some level it is different to be sure. It is a cryptographically sealed object that is populated with various pieces of information, including the following:
Version Serial Number Algorithm ID Issuer Validity Not Before Not After Subject Subject Public Key Info Public Key Algorithm Subject Public KeyNote that the digital certificate includes the public key, which is bound to the credential so that the key can be associated with a specific owner. Additionally, it is worth noting that the certificate also includes information stating who issued the credential to the specific holder.
As a matter of normal practice, a certificate typically has a public key bound to it, along with the authority who issued the certificate (and is asserting the individual is who they say they are), a serial number, any supporting policies describing how the certificate was issued, and information on how the certificate may actually be used. Although other information may be included as part of the certificate, only certain basic information is required.
IMHO
Digital certificates are like driver’s licenses in the sense that they are issued to people and identify the privileges allowed as well as the period of time for which they are valid. However, a digital certificate can also be issued to a device or even a piece of software, depending on the context. This is where the analogy breaks down for us. After all, as we all know, a driver’s license can be issued to a person, but not to a car.
LINGO
What is a cryptographically sealed object? In essence, it is an object that cannot be changed without the change being noticed. How can this be done? Through the use of our good friend hashing, of course.
A certificate is not a complex concept. In technical terms, it is a cryptographically sealed object that includes a party’s identity and public key. The certificate is populated with various pieces of information and a public key. It is then signed by generating a hash value and encrypting it with the issuer’s private key. At this point, if the certificate is altered (for example, if a party tries to replace the public key), the hash value becomes invalid, the certificate becomes invalid, and the client should see a warning indicating as much. If a client possesses the issuer’s public key and trusts the issuer of the key, then the client will assume the public key in the certificate checks out. For an attacker to compromise the system, they would have to have access to either the private key of the server or the private key of the issuer to successfully impersonate one of these parties.
LINGO
When you encounter certificates in the real world, you will undoubtedly hear the term X.509. This term refers to a standard that is used to format certificates and thus ensure compatibility between applications and parties. Consider the following situation to understand this better: What would happen if every state in the United States made up entirely different rules as to what to include on a driver’s license, with each one being radically different? It would be mayhem. As it stands now, each state has slightly different formatting, but they are all close enough that they can be understood by different parties, sight unseen.
A digital certificate allow us to associate the previously mentioned public key with a particular service, such as a web server for use in e-commerce, which can then be authenticated. If someone was to claim they are the person who is the true owner of the key and certificate, they would not be able to do so as the holder of the private key.
Authenticating the Certificate
A digital certificate can and does complement or replace other forms of authentication. A user who presents the credential must have a method in place that allows for the credential to be validated (such is the role of the CA, which we will discuss in a moment). When you present a certificate to another party, the credential is validated and allows that party to have their identity confirmed as part of the transaction. Once a series of steps is undertaken, secure communication or the validation of items such as the digital signature can take place.
Enter the PKI System
As you would expect, certificates cannot and do not exist on their own and in fact have a home out there in cyberspace, known as a certification authority (CA). A certification authority is nothing more than a repository that controls, creates, and revokes certificates, along with the associated public keys. As you will see, a CA can be controlled by a company for its internal use or by a public entity for use by anyone who wishes to purchase a credential from the controlling party.
So let’s take it from the top and start with a discussion of each of the components themselves, starting with the certification authority.
So What Is a Certification Authority?
So what is a CA and what does it do for us? A CA forms the bedrock, if you will, of the whole PKI system and makes it work the way we need it to. A CA is nothing more than a trusted third party responsible for issuing, managing, identifying, and revoking certificates as necessary, as well as enrolling parties for their own certificates. The CA vouches for the identity of the holder of any given certificate. A CA is sort of like a friend who introduces you to a friend of theirs; you may not know this other person, but because your trusted friend does, you trust the other person by extension. A CA acts as this trusted friend and can vouch for the identities of the parties who have been issued certificates by the CA. In the real world, a CA can and does issue credentials to numerous entities, including banks, webmail, VPNs, and smart cards. The CA gathers information and then validates and issues a credential to the requesting party if everything checks out.
LINGO
A trusted third-party is nothing more than someone you (or your computer) trusts. The idea is that a group of parties who don’t know each other can each trust a public entity such as the CA. Even though the parties don’t know each other, they can trust one another as long as the CA can vouch for them.
Since we are talking trust here and we have to consider that anyone can claim to be someone else, a CA must have processes in place to prevent a person from claiming they are someone else. The CA will require information to be provided that proves identity. Items such as name, address, and phone, physical data such as faxed records, and other records and personal interviews might also be required, as policy dictates. Once this information is obtained and validated, the CA will issue the certificate or validate an existing certificate.
In Actual Practice
In the real world, a certificate can be issued by many commercial certification authorities even if actual documentation has not been provided. In these cases, the certificate that the CA issues is said to be “unverified” until the holder provides supporting documentation of their claimed identity to the CA. Either certificate, verified or unverified, can be used to perform the same actions; it is just up to the party who is presented the certificate to decide whether they wish to accept the credential or not (if it is unverified).
Only a small number of CAs (relatively speaking, of course) can issue certificates. In the real world, a CA will accept a request for a digital certificate or a validation thereof. When the CA accepts a request for a digital certificate, the applicant will undergo some sort of check—background or otherwise—to verify that they are who they say they are or claim to be. A publicly owned CA such as Thawte or VeriSign typically will perform this background check by asking the requester to provide documentation such as a driver’s license, passport, or other form of ID.
When a CA issues a certificate, several actions take place that we know about:
1. The request is received.
2. Background information is requested by the CA and then validated.
3. The information provided by the requester is applied to the certificate.
4. The CA hashes the certificate.
5. The issuing CA signs the certificate with their private key.
6. The requester is informed that their certificate is ready for pickup.
7. The requester installs the certificate on their computer or device.
NoteSo how does the application or person requesting validation of a certificate know the CA itself is legitimate? That is a question we will address (and answer) later in this chapter, so stay tuned.
In practice, a CA is able to (and typically does) perform a number of different roles in addition to the validation process outlined here. The actions a CA is called upon to perform include the following:
Generation of the key pair or the public and private key pair When a CA goes through the process of creating a certificate, a key pair that is made up of a public and private key is generated. The public key will be made available to the public at large, whereas the private key will be given to the party requesting the digital certificate itself. TipAs you may recall, the public and private keys are mathematically related and what is performed by either key can only be undone by the other. Typically, the only fact that separates one key from the other is who has access to it. If everyone has access to the key, it is public. If only one person or a few people have access to the key, it is private.
Generation of certificates The CA will generate digital certificates for any authorized party when requested. This certificate will be generated after validation of the identity of the requesting party. Publishing of the public key The public key is placed upon and bound to each digital certificate as both are generated. Anyone who trusts the CA or requests the public key will, in practice, get the key for their use. Validation of certificates When a certificate is presented by one party to another, it must be validated. Because both parties involved typically do not know one another, they must rely on a third-party who is trusted. This is the role of the CA. Revocation of certificates If a certificate is no longer needed or trusted, it can be revoked before it expires. This is much like what happens if a driver’s license is revoked prior to its normal expiration date.When a CA is called upon to validate a certificate, what is really happening? When a CA is asked to perform a validation, it is actually confirming that a specific public key bound to a certificate does indeed belong to the entity named in the credential. During normal operation, a CA will verify a presenter’s credentials to allow two parties who previously were foreign to each other to have confidence that they are who they claim to be and that the public key is actually theirs.
But are all certification authorities the same? Absolutely not. There are several different types of CA, and each is a little different from the others, as you will see. A CA has the primary responsibility to create key pairs and to bind these key pairs to a user’s identity and certificate. Once this has been done, validation of the key to a user can take place, as needed or requested. The CA in any form is intended to be a trusted entity in much the same way as the DMV is trusted with driver’s licenses and the FAA is trusted with pilot’s licenses. CAs include the following types:
Root CA This is the CA that initiates all trust paths. The root CA is the top of the food chain or the point at the top of a pyramid from where trusts emanate. As the entity at the top of the pyramid, the root CA must be secured and protected, because if its trust is called into question, all other systems will become invalid. Trusted root CA A trusted root CA (or trusted root certificate) is a certificate from a CA that is added to an application such as a browser by the software vendor. It signifies that the application vendor has a high level of trust in the CA.In Actual Practice
If you have ever looked into your favorite browser (such as Internet Explorer or Firefox), you will notice that each has some certificates pre-installed by the software vendor. These certificates make it so we automatically trust certain public CA providers automatically. It’s kind of like a guest list that we can check people against to make sure we can trust them.
Peer CA A peer CA has a self-signed certificate that is distributed to its certificate holders and is used by them to initiate certification paths. Subordinate CA A subordinate CA is a certification authority in a hierarchical domain that does not begin trust paths. Trust initiates from some root CA. In some deployments, this is referred to as a “child CA.” Registration authority (RA) An RA is an entity positioned between the client and the CA and is used to support or offload work from a CA. Although the RA cannot generate a certificate, it can accept requests, verify a person’s identity, and pass along the information to the CA that will perform the actual certificate generation. RAs are usually located at the same location as the subscribers for which they perform authentication.LINGO
One notable difference between registration authorities (RAs) and certification authority (CAs) is the fact that RAs typically do not possess a database or generate certificates or keys. As a result of this difference, they do not have the same security requirements as CAs. In most cases, an RA will have lesser security than a CA.
Building a PKI Structure
Now that you understand what a CA is and what a digital certificate is, we can now go about the business of building a PKI system. Before we start building a PKI system, let’s first make clear that the term does not refer to a single technology, but rather, a group of technologies and concepts that work together as a unit to accomplish the tasks mentioned earlier. PKI is designed to validate, issue, and manage certificates on a large scale. The system is simply a security architecture we use to provide an increased level of confidence for exchanging information over an insecure medium.
NotePKI should never be thought of as a technology that is the exclusive domain of one software or hardware vendor because it is independent of any of them. In fact, although it may be easy for you to think of PKI as a Microsoft, Linux, Unix, or other technology, it is actually all of these and none of these. The system is indeed a standard used by all vendors and applications.
Any systems that interact with this structure must be PKI aware, but that is a common feature in today’s environment. For us, a PKI-aware application is any application that knows how to interact with a PKI system or can be enabled to do so. Fortunately, we do not have to worry about an application having the ability to do this; most applications, such as web browsers, e-mail applications, and operating systems, already have this capability. All of these applications offer us the ability to interact with the system described in this chapter and do so transparently.
When working with PKI, you must understand that tying the whole system together is trust. Trust is absolutely important because without it the system falls apart pretty quickly. In fact, it could be said that without trust, the system is less than worthless to us. For example, if your friend from before introduced you to someone who is their friend, but you didn’t completely trust your friend, then you wouldn’t trust their friend either. The problem presented here would also be the equivalent to the real-world scenario of having a fake or questionable ID: If the ID doesn’t ring true to the party to which it is presented, the credential is essentially worthless.
With this in mind, let’s look at some different PKI systems. The first type of PKI system is simple in design and implementation. The design incorporates one root CA with two subordinate CA systems. This is ideal for large- and medium-sized organizations that may handle a lot of certificate management requests and issues. All the CA systems can do the same thing in this environment, but typically only the subordinates will issue the bulk of the certificates, with the root not doing as much. In fact, in this setup, the root would more than likely only be issuing certificates to the subordinate to, in essence, license them to issue credentials. Figure 7-3 shows this simple PKI system.
Figure 7-3 A simple PKI structure with a root and two subordinates
Another different type of structure would include an RA, or registration authority. Note that the two look very similar in design, with the RA typically limited to registering potential applicants before sending the request on to the parent CA. Figure 7-4 shows a PKI system that includes an RA as part of its makeup. In this environment, the RA may very well be set up to take some of the load off of the CA, or at least to offload some of the traffic to the RA and leave the other management tasks to the CA.
Figure 7-4 PKI system showing an included RA as part of its makeup
Finally, in high-security environments, there may exist a situation where the root CA is taken offline; in these cases, it is called an offline root. An offline root is created in order to issue certificates to those CA systems underneath it. An offline root does not typically (and shouldn’t) do any sort of work on a day-to-day basis. Figure 7-5 shows a PKI system with an offline root.
Figure 7-5 PKI system with an offline root
IMHO
In my opinion, an offline root is ideal for environments that have a large and important PKI structure. Because compromising the root would be catastrophic, it makes sense to keep it offline and out of harm’s way. Although such a setup does make some tasks a little harder, in many cases the inconvenience is outweighed by the security benefits. Having said that, you may be in an organization where such an inconvenience is too much.
After PKI Has Been Set Up
Once the PKI system has been set up, it is now time to start issuing certificates. The process of issuing certificates is simple, but very methodical and procedural, as you will see. The process can be viewed in Figure 7-6.
Figure 7-6 The certificate request process with a CA
NoteIn Figure 7-6, take note of step 3. In this step, a requesting party may have been identified or authenticated, but they still may not be allowed to have a certificate for the type of action they are requesting (or maybe not at all). The owner of the CA would include rules that dictate who can have what type of certificate based on their needs at that time.
Let’s examine each of the steps in Figure 7-6 a little closer:
1. Certificate requested. This means that some party has requested a certificate and, as such, has made one to the CA or to an RA.
2. User authenticated. A user needs to be authenticated to positively identify who they claim themselves to be. In some cases, this may already be done, such as with Microsoft’s Active Directory and Certificate Services, where the user has already logged in to the network and identified themselves. In other cases, the user may need to provide info that identifies them. The CA may even go the additional step of requesting personal documentation, as needed.
3. Policy applied. In this step, the requesting party is checked to see if they are cleared to obtain the certificate they are requesting. This may mean that they are allowed to have only certain types of certificates.
4. Request sent to CA. In this step, the CA receives the information and, in turn, creates the public/private key pair, creates the digital certificate, and then cryptographically seals the certificate after placing the user’s public key upon it.
5. Certificate issued. In this step, the certificate is actually issued and is ready to be used.
6. Requesting party notified. In this step, the requesting party is told that their newly minted certificate and private key are ready to be picked up.
7. Certificate installed. Finally, the certificate is installed on the device or system that the user originally intended it for.
NoteSteps 2 through 5 may indeed be on the same system, such as is the case with Microsoft Certificate Services and certain systems on Linux and Unix.
So now that the user is in possession of the certificate and is using it, everything is fine until the certificate expires, right? Wrong. In actuality, you can have your certificate pulled or revoked at any time for a number of reasons, with the major reason being that you cannot be trusted anymore. Going back to our driver’s license analogy for a moment, consider if you had a license issued that said you could only drive cars, but you somehow decided to go out for a spin on your friend’s motorcycle? If you got pulled over, there would be some explaining to do to the officer. Clearly, he could look at your license and see what you are authorized for and even call it in for verification. When you eventually have to appear before a judge, she may decide that you are not responsible enough and cannot be trusted. Therefore, your license is revoked. This is the way it is for certificates generally. If you cannot be trusted or if you no longer need your certificate, it is generally revoked.
IMHO
Yes, I know certificates can be revoked for other reasons, including situations where someone leaves the company or changes jobs and doesn’t need one anymore. It is also possible that they simply shouldn’t have gotten one in the first place, so it is pulled.
One of the most important roles of a CA is that of revocation of certificates. As I told you previously, a certificate can be revoked for any number of reasons, including misuse, mistrust, and no longer being needed. The CA is responsible for performing this action as well as informing others of the revocation. In the world of PKI, a certificate revocation list (CRL) is used to verify the current status of a certificate. The CA publishes this list at regular intervals, and is responsible for updating it with the most current information as to who has a legit certificate and who does not. The CA must keep the CRL up to date and available to clients of the system who need to check the status of certificates.
When a certificate is revoked and placed on a CRL, it will appear in one of two states:
Revoked Certificates that have been placed on the CRL as revoked include any that need to be pulled out of circulation permanently, and it is assumed that they will never be needed again. Of course, this should be done cautiously, because anyone who has their certificate revoked will need to get a new one. A good example of this situation would be where you lose your smartcard or laptop that holds your private key; your certificate would be revoked and placed as revoked on the CRL so that it is never used again. Hold or Suspended Different than revoking is the status of Hold or Suspended, which is intended to be reversible if needed. However, when a certificate is put on hold or is suspended, it acts exactly like a revoked certificate, meaning that it will not be valid for use in any situation. Citing the example for a revoked certificate, if the individual who lost their private key suddenly found it and it was determined that it wasn’t compromised, it could be taken off suspension.IMHO
If you ever have to manage a PKI system, you may want to consider the benefits of suspending a certificate over revoking it outright. Essentially, you should consider suspending first and then, if a specific interval lapses and no determination can be made as to whether or not there is a compromise, the certificate should be revoked.
When either of these actions takes place, it means the key may no longer be used and a new one must be issued if a revocation is performed.
A CRL is generated, updated, and published on a schedule defined by the CA owner. In addition to being updated on a schedule, it may be manually updated as needed if a particularly hot issue arises—for example, if someone leaves the company on bad terms and no one’s sure whether they have a copy of the key. In fact, thankfully for us, CRLs are updated usually once a day to make sure the latest information is always available to the clients. After this time period expires, the CRL is invalidated and a new one is published in its place. During a CRL’s validity period, it may be contacted by any PKI-enabled application that needs to verify a certificate prior to acceptance. When placed on the CRL, the key’s serial number will be listed for some number of update periods until the normal expiration of the certificate is reached.
PKI in Action
So now that you understand PKI and its cast of characters, let’s look at some applications of this technology and see how all the cryptographic factors fit in. We’ll first examine the process of Secure Sockets Layer (SSL).
SSL is a technology that powers many online transactions and makes them safe and secure for the exchange of information. Webmail, purchasing, banking, health care, and other applications use this technology to make sure your personal information cannot be pilfered by the “bad guys.”
SSL is a simple technology and, as such, can be broken down into a few short steps:
TipDon’t worry if the steps seem confusing at this point. I will diagram them out for you afterward. This is just to get you acquainted with the process before I dump some graphics on you.
1. Request The client requests a session with the server.
2. Response The server responds by sending its digital certificate and public key to the client.
3. Negotiation The server and client then negotiate an encryption level.
4. Encryption Once they agree on an encryption level, the client generates a session key, encrypts it, and sends it with the public key from the server.
5. Communication The session key then becomes the key used in the conversation.
Figure 7-7 illustrates the interaction between the client and server in a CA system. Note the lines of trust, where each party trusts the other indirectly through the CA.
Figure 7-7 The certificate exchange and establishment of an SSL session
TipNote that SSL is normally used in e-commerce situations, but the same process takes places when SSL is used for webmail, e-mail, or financial transactions. In fact, the e-mail client I use, Mozilla Thunderbird on Linux, uses SSL because I have configured it to use SSL to secure the communication channel.
Digital Signatures
One of the more popular mechanisms that rely on PKI, and the cryptographic mechanisms that underlie the system, is digital signatures. A digital signature is something that you may have used yourself when you signed a loan application for your new house, signed paperwork online, or sent a signed e-mail. Simply put, a digital signature is something that allows for the authentication and validation of the legitimacy of a message.
LINGO
Digital signatures are used to verify the authenticity of messages as well as to provide a means through which they can be validated as being original. Think of digital signatures as performing the same function as a traditional pen-and-paper signature. Traditional signatures, when applied to a paper document, assert that you, as the signer, agree to the contents of a document. At the same time, the uniqueness of the signature is bound to you (forgeries not withstanding).
When implemented correctly, a digital signature is easily transportable across systems, cannot be replicated by another party, and can be time stamped (meaning that you can verify when the signature was applied to the document). By providing these features, a digital signature offer elements in the digital world that allow you as a creator of one to be uniquely identified with the utmost certainty.
TipDigital signatures also provide something known as non-repudiation, which means that the originator of an action cannot deny carrying out the action.
In Actual Practice
For over a decade, digital signatures have been recognized as a legally binding method of signing electronic documents. For example, when I recently purchased a home, all of the documents, save for the initial ones, were required to be signed digitally. In essence, what I had to go through signing these documents was a simpler and more secure way of stating I agreed to the terms of the sale and loan than in years past.
So what makes a digital signature so important for us and how is one created? Let’s take a look a closer look at the mechanism that creates a digital signature.
First, what is contained in a digital signature? Simply put, a hash, an encrypted bundle, and something that identifies the signer. A digital certificate contains the digital signature of the certificate-issuing authority so that anyone can verify that the certificate is real.
Digital signatures make use of several of the different types of encryption we have used before in order to render their capabilities—namely, asymmetric or public and private key encryption and hashing. By combining these cryptographic functions, we can provide authentication of a message or digital item. Let’s look at each component:
Public/private key encryption Although it is true that you can encrypt with a private key and then decrypt whatever you have encrypted by accessing the public key on the corresponding digital certificate for the encrypting party, this does not provide all of what we need. However, because a public key is possessed by a specific party, only it can (and does) play an important part in digital signatures. Digital certificates A digital certificate is absolutely an essential component of a digital signature. Remember early when I said that a public key is bound to a digital certificate? This fact pays off its reward here. The digital certificate tells whomever retrieves the public key that it belongs to a specific party and, by extension, it is the companion of the private key (recall what you learned in an earlier chapter about asymmetric encryption). Hashing This is the mechanism that lets us know whether or not an item has been altered. Earlier I said that a traditional signature, when applied, indicates that the signer agrees to the terms of the document as presented. Hashing does the same thing in the digital world with signatures. The hash states that the signer agrees to the current state of the document.Let’s put these items together, along with a CA and trust, and see how the signature is created. Let’s say we have two parties by the names of Link and Zelda. Link will be the sender of the message, and Zelda will be the receiver. With that being said, let’s take a look at the process:
1. Link creates a message.
2. Link then hashes the message using an algorithm, such as MD5 or SHA.
3. Link then encrypts the hash with his private key.
4. Link then binds the encrypted bundle and the plaintext message together.
5. Link then sends the combination to Zelda.
6. Zelda sees that the message came from Link.
7. Seeing who the sender is, Zelda retrieves Link’s public key from the CA they both trust.
8. Zelda then decrypts the hash. If it is decrypted successfully, the identity of the sender is validated.
9. After the hash is decrypted, Zelda then reruns the MD5 algorithm against the plaintext message and compares the new hash with the one she received from Link.
10. If the two hashes match, the message has not been altered since Link signed it.
In Actual Practice
The same process described here is used in e-mail systems all over the world, where enabled. It is very common to see digital signatures in use in government offices, the military, and other places where the verification of a message both in origin and content is required.
We’ve Covered
What is Public Key Infrastructure (PKI)?
PKI is a key management system. PKI is used to issue and manage certificates. Digital certificates are credentials used to identify an entity.Components of PKI
PKI is a combination of hardware, software and policies. PKI-aware applications can interact with a PKI system.Fundamentals of PKI
PKI is software independent. PKI is used in many applications.Applications of PKI
PKI is used to verify digital signatures. PKI is used with smartcards and SSL.Process of PKI
PKI sets certificate usage policies. PKI is platform independent. PKI is a system used to validate certificates...................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.