Chapter 6. Integrity, Non-Repudiation, and Confidentiality
Among the foundational concepts in digital identity are message integrity, non-repudiation, and confidentiality. Integrity ensures a message or transaction has not been tampered with. Non-repudiation provides evidence for the existence of a message or transaction and ensures its contents cannot be disputed once sent. Confidentiality ensures that only the people or processes authorized to view and use the contents of a message or transaction have access to those contents. In some situations, these properties are unneeded luxuries, but in others, the lack of one of these properties can lead to disaster. Understanding them, and when to use them, is crucial to a digital identity management strategy.
Integrity
Integrity is a fundamental requirement of a trustworthy identity infrastructure. Identity systems exchange credentials as well as messages and transactions regarding attributes, provisioning information, and other data. Trusting that the contents have not been tampered with is important. As an example, consider a document representing identity credentials. To trust those credentials, we must be able to verify they are authentic and have not been changed.
Non-Repudiation
Non-repudiation is the presentation of unforgeable evidence that a message was sent or received. If messages or transactions can be disputed, then important identity actions can be challenged and jeopardized. These disputes can take two forms. Consider two people, Alice and Bob, who are exchanging messages. In one case, Alice denies sending a message to Bob that he claims to have received. Being able to counter Alice’s denial is called Non-Repudiation of Origin (NRO). In the second case, Alice claims to have sent Bob a message that he denies having received. Offering evidence to counter Bob’s claim is called Non-Repudiation of Receipt (NRR).
Confidentiality
Confidentiality can be achieved in several ways. The two most common are steganography and encryption . Steganography is the process of putting a message inside another message in such a way that observers do not know that its there. For example, modifying the low-order bits in an image to transmit a message does not interfere with viewing the image, and the presence of the message is difficult to detect. While steganography has some interesting uses, it cannot serve as the basis for confidentiality in an enterprise identity system.
Encryption is the process of transforming a message using a key so that anyone viewing the message without the key cannot determine its contents. Cryptography is the basis for the technologies, such as digital certificates, that provide properties like integrity non-repudiation and confidentiality. While digital certifications and cryptographic issues are by no means the answer to the problems of identity in and of themselves, they are an important tool for solving some critical identity problems. Understanding digital identity requires at least a passing understanding of the technology, processes, and politics surrounding cryptography and digital certificates.
Cryptography
Cryptography is the science of making the cost of discovery of hidden information greater than the value of the information itself. An important corollary to this statement is that there is no single cryptographic solution to every problem. With increasing needs for confidentiality, the methods become more involved and the costs increase.
This single idea is perhaps the most important thing you can know about cryptography. Many people mistakenly think that cryptography is about absolute protection of data and are consequently upset to learn that someone has cracked a trusted cryptographic algorithm. While such news is certainly worth paying attention to, even easily compromised algorithms have uses in certain circumstances. The goal is to understand the needs and match those to the method that solves them for the least cost.
Secret keys
Secret key encryption uses keys to transform a message in such a way so as to render it unreadable to anyone without the proper key. Secret key cryptography is also known as symmetric cryptography (since the same key is used to encrypt and decrypt the message) or conventional cryptography .
Figure 6-1 shows a simple secret key transaction. Alice and Bob wish to share a message without divulging its contents to outside parties. Alice uses her secret key to put the plaintext message through a process that transforms it into an encrypted message. Alice can send the message to Bob without fear that an outsider will be able to read it, as long as the eavesdropper does not possess the secret key. Later Bob puts the encrypted message through another process, using the same key, to recreate the plaintext message.
One of the most important factors affecting the strength of a secret key encryption process is the length of the key. There are a significant number of secret key algorithms that differ in their key length, their efficiency for encryption and decryption, and their vulnerability to attack. Table 6-1 shows some common secret key algorithms and their key lengths. For most identity problems, the selection of a secret key algorithm is independent of other concerns, and consequently, they can be selected based on the requirements of the specific task at hand.
|
Algorithm name |
Key length (bits) |
|
Blowfish |
Variable, up to 448 |
|
DES |
56 |
|
IDEA |
128 |
|
RC2 |
Variable from 1 to 2048 |
|
RC4 |
Variable from 1 to 2048 |
|
RC5 |
Variable from 1 to 2048 |
|
Triple DES |
56 |
This process depicted in Figure 6-1 relies on Alice and Bob having agreed ahead of time on the secret key. One of them could choose the key and then transmit it to the other party using some other form of communication, or they could meet together to choose or exchange the key. The problem with both of these methods is that in both cases, an attacker has the opportunity to steal the key. Once the key is compromised, an attacker can decrypt and read any message encrypted with it.
To make matters worse, common attacks against cipher systems involve collecting large amounts of ciphertext that has been encrypted using the same key. To combat this attack, keys must be changed often, making key exchanges a frequent affair. The next section will discuss a concept that solves this problem.
Public key cryptography
The dilemma facing Alice and Bob is how to exchange keys. This is a big enough problem when just Alice and Bob are exchanging keys. Imagine the problems you’d have if you wanted to exchange encrypted messages with all the people in your organization and each subgroup. For example, if the development group wants to exchange messages in private, they need a key known to all of them that is different than any of the keys they use to exchange mail with each other. The management complexity of such a scheme is staggering. Fortunately, there’s a cryptographic technology that does away with the need to exchange, store, and use secret keys, called public-key cryptography .
Public-key cryptography makes use of two distinct keys, called the public key and the private key. The private key is kept secret by its owner and is never divulged. The public key can be freely shared with other parties. The public and private keys are mathematically related to each other and are called a key pair. The mathematical relationship that the keys share enables a message encrypted with one to be decrypted by the other. Yet, neither key can be used to decrypt what it has encrypted. Thus, a message that is encrypted with the public key can be decrypted only by using its corresponding private key, and a message that is encrypted with the private key can be decrypted only by using its corresponding public key. Because of this property, public-key cryptosystems are sometimes called asymmetric.
Figure 6-2 shows how Alice and Bob might use public-key cryptography to exchange a message. Because Bob’s public key can be freely shared, he has posted it on his web site. Alice downloads Bob’s public key and uses it to encrypt her message. She then sends the encrypted message to Bob. Bob uses his private key to decrypt Alice’s message. Only Bob’s private key, which he has kept secret, can decrypt messages encrypted with his public key, thus ensuring that Alice’s message has been kept confidential.
Now, suppose that instead of encrypting her message with Bob’s public key, Alice uses her private key to encrypt the message. Alice sends the encrypted message to Bob and Bob uses Alice’s public key, which he can get from her web site or in some other way, to decrypt her message and read it. Of course everyone else also has Alice’s public key. So Alice cannot use her private key to send confidential messages to Bob. To send a confidential message to Bob, Alice uses Bob’s public key to encrypt the message.
Encrypting something with a private key is, however, useful for two other important properties we need: integrity and non-repudiation. As long as Alice has kept her private key secret, anyone using Alice’s public key to decrypt her message knows two things:
The message has not been tampered with in transit.
The message is truly from Alice.
If the message has been changed, then Alice’s public key will no longer decrypt it. If the message is encrypted with any key other than Alice’s private key, her public key will not decrypt it. To impersonate Alice, Charlie must have access to her private key.
Using a private key to encrypt a message creates a digital signature. Using a public key to decrypt a message that has been encrypted with a private key is called signature verification .
A key system is called reversible if a private key can decrypt messages encrypted with its associated public key and a public key can decrypt message encrypted with its associated private key. Key systems where the private key can encrypt but cannot decrypt and the public key can decrypt but cannot encrypt are called irreversible. Reversible key systems can be used for confidentiality, integrity, and non-repudiation. Irreversible key systems can be used only for integrity and non-repudiation.
Hybrid key systems
Public-key cryptosystems are significantly more expensive from a computational standpoint than secret key algorithms. Public-key cryptosystems can take 100 to 1,000 times longer than secret key systems to encrypt or decrypt the same message. Consequently, public-key cryptosystems are rarely used to encrypt large amounts of data. Rather, they are used to negotiate a secret key between the parties in the initial phase of communication. This kind of cryptosystem is called a hybrid cryptosystem.
Key exchange algorithms allow two parties that know each other’s public keys to calculate a secret key using one party’s private key and the other’s public key. In our example, Alice and Bob have exchanged public keys. They also exchange a large prime number and another number smaller than the prime called the generator. Alice uses her private key, Bob’s public key, the prime number, and the generator to create a secret key. This process is commutative, and so when Bob uses his private key, Alice’s public key, the prime, and the generator, he calculates the same secret key that Alice did. Charlie can know both public keys, the prime, and the generator, and still not be able to calculate the shared secret, because he doesn’t have access to either private key.
Of course, if Charlie can somehow insert himself into the middle of the key exchange so that both Bob and Alice end up with his public key while thinking they’ve got the correct one, he can impersonate Bob to Alice and set up a shared secret with her and impersonate Alice to Bob and set up a shared secret with him. Afterward, he can sit in the middle of the conversation, reading the communication and forwarding the packets onto the other party. When Alice sends a message, it goes to Charlie who decrypts it, reads it, reencrypts it with the shared secret he negotiated with Bob, and sends it on. This kind of attack points out the need for trustworthy key exchanges, a topic we’ll visit later in this chapter when we talk about digital certificates.
The most commonly used hybrid key system is transport layer security (TLS ), most widely known as SSL (Secure Sockets Layer). SSL is the technology used to create secure web communications.
SSL creates an encrypted channel between two applications. An encrypted channel automatically encrypts all of the data being sent on the wire without any action by the user. SSL uses the public-key cryptosystem to negotiate a shared secret that is used to encrypt the communications. A different shared secret is negotiated for each session. Because SSL requires only one of the parties to have a key pair, the algorithm for negotiating the shared secret is different than that outlined above. SSL sits below the application protocol and thus can be used to secure HTTP communications, email transport, or any other application protocol on the Internet.
Public key cryptosystem algorithms
There are a number public-key cryptosystems . Table 6-2 lists four of the common public-key cryptosystem algorithms, their types, and how they can be used. The choice of which algorithm to use depends on the particular task, the level of security needed for the task, relative efficiencies, and so on. Public-key cryptography schemes can be subject to non-obvious attacks that render them transparent, so it is best to employ a cryptographic expert when choosing which algorithm or scheme to use for any particular task.
Message Digests and Hashes
Sometimes it is enough to be able to determine when a document or message has been changed, either maliciously or not, without suffering the computational overhead of encryption. A mathematical technique called a message digest (also called a hash) can be used to show integrity in such cases.
A message digest is a fixed-length string of bits that is produced from a variable-length message through a special mathematical transformation that has three important properties:
- Irreversible
Feeding the message digest into another transformation should not be able to produce the original document. This is a reasonable assumption of any algorithm that turns long strings into relatively short fixed-length strings, since there simply isn’t enough information capacity in the short bit-string to contain the longer one.
- Nonselectable
Finding a message that will produce a particular digest should be mathematically infeasible.
- Unique
Finding two documents that produce the same message digest should be mathematically infeasible.
Irreversibility ensures that we can communicate the message digest without worrying that the contents of the message will be divulged. As an example, a common usage for digest algorithms is storing passwords in computer systems. In this usage, the user’s password is passed through a message digest algorithm and then stored on the machine. When the user logs in and enters a password, it is passed through the same message digest algorithm, and then the two digests are compared. If they match, the entered password is correct. In this way, passwords are never stored in the clear but can be used to authenticate users. Obviously, this method wouldn’t be secure if the digest algorithm could be reversed.
Nonselectability and uniqueness ensure that a different message can’t be substituted for the one for which the message digest was created. This is important, because we’re relying on the digest to provide evidence of message integrity. If I can find a message that has a particular digest, I can substitute it for a message you have sent with that same digest and no one will be the wiser. As an example of how this could create a problem, consider a common usage of message digests: ensuring the integrity of code distributions. If I can insert malicious code into a code distribution (for example, a program that emails any user’s passwords to me) and then create the same message digest for the new distribution, you would download and install my version of the code and never know about the switch.
Table 6-3 shows some message digest algorithms, their digest size in bits, and the developer or owner of the algorithm. Ronald Rivest (the “R” in RSA) is the inventor of MD2, MD4, and MD5. MD2 was developed in 1989 and optimized for 8-bit machines. MD4 and MD5 are built for 32-bit machines. MD5 is computationally more expensive than MD4, but provides better security. MD5 is used in a number of applications from building hashes of passwords to integrity check-sums of code distribution.
SHA and SHA-1 were developed by the National Institute of Standards and Technology and specified in Federal Information Processing Standards (FIPS) 180 and 180-1. MD5 has some discovered theoretical weaknesses, and as a consequence, SHA-1 has been preferred over MD5 for some time. However, in October 2004, researchers also published preliminary reports of weaknesses in SHA-1.
These developments point out why it’s important to design identity systems so that the cryptographic functions can be easily changed out and why systems that use encryption as well as the policies that govern them should be reviewed periodically.
Digital Signatures
We’ve discussed how using a public-key cryptosystem in reverse can provide a sort of digital signature: if I encrypt a document with my private signature, anyone can decrypt it, but only with the matching public key. Provided I’ve kept my private key secure, this is strong evidence that I encrypted the document in question and can thus serve as a signature.
This methodology suffers from several disadvantages:
The signed document is rendered unintelligible unless it is decrypted with the public key. This is intrusive in an environment where one might only occasionally want to check signatures.
The signature and the document are inseparable. There’s no way to send a signature under separate cover.
We can overcome these disadvantages if we combine public-key cryptography and message digests . Figure 6-3 shows the methodology schematically. Since a message digest is unique to a particular document (within certain cryptographic constraints), we can create a message digest of the document or message to be signed and then sign the digest rather than the message. The message remains in plaintext, and the signature and message are separable.
To verify the signature, we use the public key of the sender to decrypt the message digest and then apply the same message digest algorithm to the signed message. If the two message digests match, the message is the same as the one that was signed by the sender.
Digital signatures, produced in this way, provide us with evidence of a document’s integrity, since changing the document, intentionally or not, would result in the receiver calculating a different message digest. The digital signature also provides us with non-repudiation, since it is clear that the person who created the original digest had access to the identical document, and as long as that person has maintained control of his private key, he’s the only one who could have produced the signature.
When used for digital signature purposes, the private key is sometimes called the signing key and the public key is called the verification key. Technically, these keys operate in the same way as standard public-key pairs; the terminology simply indicates clearly which key is used for what purpose.
Digital Certificates
Public-key cryptosystems provide technology for creating identity systems with confidentiality, integrity, and non-repudiation. As we’ve seen, however, they are subject to several serious limitations:
If you lose control of your private key, you can be impersonated and your confidential documents can be read.
If an enemy can convince me that her public key belongs to you, I’ll accept whatever she tells me as coming from you.
The first problem is an authentication and authorization problem. We’ll talk more about those in Chapter 7 and 8.
The second problem is mitigated by the use of digital certificates and what’s called the Public-Key Infrastructure.
A digital signature is a data structure that associates identifying information with a public key. As we’ve seen, a public key is just a very long, seemingly random number. There’s no way to look at a public key and tell who it belongs to. By combining a public key with other identifying information, such as a name and address, we can more easily identify the owner of the key and be sure that it’s the right key. Of course, we will want to ensure the integrity of this document by digitally signing it so that no one tampers with it and substitutes an alternate key.
A digital certificate need not be issued to a person. In fact, many are not. Digital certificates can be issued to a variety of entities including individuals, companies, groups, and even web servers. The entity whose identifying information is associated with the public key in the certificate is called the certificate subject.
When a certificate is created, the data structure is populated and then the issuer signs the certificate by creating a message digest of the information and then encrypting the digest with the issuer’s private key. By signing the certificate, the issuer is making a statement that the public key contained in the certificate and the identifying information in the certificate belong together. The digital signature ensures the integrity of the certificate.
Digital certificates are not human-readable documents, but rather data structures meant to be used by computer programs. However, with the aid of programs, like OpenSSL, we can view the contents of a certificate. Here are the contents of a sample digital certificate:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 163 (0xa3)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US, ST=California, L=San Francisco,
O=Pacific Distribution, Inc.,OU=Certification,
CN=PDI Certificate Authority/[email protected]
Validity
Not Before: Aug 19 17:31:59 2003 GMT
Not After : Aug 18 17:31:59 2004 GMT
Subject: C=US, ST=California, L=San Francisco,
O=www.California_distribution.com, OU=1885658,
CN=www.California_distribution.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (512 bit)
Modulus (512 bit):
00:a4:45:15:66:ca:4b:e9:4f:b2:85:32:df:73:63:
01:b6:a0:45:31:c4:db:67:7b:ed:29:7e:66:d9:30:
8f:0e:33:3c:cb:bc:2d:2b:a8:51:48:a2:e5:68:84:
82:aa:d1:07:f9:64:f2:fd:67:5d:cd:58:c6:c7:71:
3d:7e:d7:ec:63
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation,
Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
Netscape Comment:
OpenSSL Generated Certificate.
X509v3 Subject Key Identifier:
48:7E:92:A1:6E:B0:06:42:05:6C:FA:F3:47:81:85:4E:
3A:2D:05:BB
X509v3 Authority Key Identifier:
keyid:F8:F1:41:1C:D6:A2:C3:77:B1:A6:3D:CA:49:59:
E8:86:C0:0A:2B:4A
DirName:/C=US/ST=California/L=San Francisco
/O=Pacific Distribution, Inc.
/OU=Certification/CN=PDI Cert Authority
/[email protected]
serial:00
Signature Algorithm: md5WithRSAEncryption
75:a5:ca:a3:90:e3:03:a6:40:5c:95:a5:f8:a0:a1:b3:b3:e9:
e9:fb:e8:ce:d1:b4:f5:e1:ee:04:c1:e2:c7:ad:f4:a6:b2:5d:
59:d6:d9:81:34:ec:b7:30:0a:b3:49:0c:58:d2:70:a0:e7:c2:
71:bd:c8:de:33:e3:f1:5f:78:67:db:4c:84:70:ba:7b:d7:52:
cf:43:19:ab:4d:d4:7e:1a:2e:30:35:47:57:0d:6d:25:e7:a7:
13:a9:a8:57:63:9d:0e:54:ec:16:2d:a1:f6:e4:12:97:94:a5:
38:84:54:2f:7c:05:fc:9b:6b:3f:c8:86:56:df:89:c3:4f:8b:
4d:7cThere are several items in the certificate of interest to us. There are two main parts: the data block and the signature block. The data block tells us the certificate’s serial number, who the subject of the certificate is, what signature algorithm was used, and who issued the certificate. The data block also contains the actual public key (512 bits, in this case) and a list of extensions. The signature block contains the actual signed hash.
You probably noticed the string “X509” in several places in the data block. X.509 is part of the X.500 standard for directories, which we will discuss in Chapter 9. X.509 specifies the format of the data structure that holds the certificate information. Despite its origins as part of X.500, X.509 has taken on an independent life as a standard.
The X.509 specification defines ways to extend certificates to contain any data that the issuer deems important. Extensions take the form of key-value pairs. Each extension has an associated criticality flag that indicates to applications using the certificate whether they can safely ignore an extension that they don’t understand.
The certificate, being a data structure, is binary data. Many of the uses for certificates, however, require that they be transmitted over networks. To make this possible, the data structure is serialized using an encoding algorithm called the Distinguished Encoding Rules (DER) . In its serialized form, the certificate takes the form of a string of octets and is suitable for transmitting over network connections. When the certificate is to be included in email and other text documents, the octet string is base 64-encoded to create a stream of ASCII characters. Since it appears as a long, random-looking string of ASCII characters, many people confuse the encoded certificate with the public key itself. You can recognize base 64-encoded certificates because they are, by convention, set apart with a beginning string “--BEGIN CERTIFICATE--” that serves as the header and an ending string “--END CERTIFICATE--” that serves as the footer.
Certificate Authorities
As we’ve discovered, a digital certificate associates identity information with a public key in a trusted package. Since the certificate issuer signs the certificate, we can easily verify that the information in the certificate has not been tampered with or otherwise modified. But how can we be certain that the identity and public key are correctly associated?
While anyone can issue certificates using OpenSSL or some other certificate programming API, there are trusted issuers of certificates called certificate authorities (CAs). The certificate authority accepts and processes applications for certificates from entities, authenticates the information that the entities provide, issues certificates, and maintains a repository of information about certificate and their subjects.
Certificate authorities provide the following services:
- Certificate enrollment process
This is the process whereby entities apply for a digital certificate.
- Subject authentication
The certificate authority authenticates that enrollees are really who they say they are. The level to which authentication is done depends on the level of assurance the certificate authority is promising.
- Certificate generation
As we’ve seen, certificate generation is not a complicated process computationally. What makes this task difficult is the need to do it in a completely secure manner.
- Certificate distribution
Certificates and the private keys associated with them must be distributed to the enrollee.
- Certificate revocation
When there is a question about the integrity of a certificate that has been issued (e.g., the private key has been compromised), the certificate is added to a revocation list.
- Data repository
All of the information related to the enrollment and authentication, along with any other important information, must be kept, securely, for an agreed upon length of time (e.g., 10 years, 100 years, etc.) in case information about the certificate and its use is questioned.
The CA typically publishes policies and practices related to the above activities in a certification practice statement (CPS). These documents are typically understandable and not overly filled with legal jargon. Even so, they are lengthy; VeriSign’s CPS is nearly 90 pages long. Most users of digital certificates have never bothered to read the CPS.
A set of standard extensions was added to Version 3 of the X.509 specification to provide CAs more control over certificates. These include a basic constraints field that indicates whether the subject is a CA, a certificate policy field that contains a reference to the policy under which the CA issued the certificate, and a key usage field that restricts the purpose of the key contained in the certificate. Since the key usage field is typically marked “critical,” CAs can use it to limit the use of the general purpose keys they issue to specific tasks such as digital signing or non-repudiation. The key usage field keeps keys from being used for purposes for which their subjects did not intend. A cynic would also recognize that it also helps CAs sell more certificates.
Certificate Revocations Lists
The State of Utah uses digital certificates to control access to some of the systems used by the State police and other public safety officials around the state. Because a compromise to that system could result in the loss of sensitive data or worse, the designers used digital certificates for authentication. A natural question is, “What happens if a user loses a certificate or it is compromised in some other way?”
As we’ve seen, X.509 certificates have a period during which the certificate is valid. When the validity period passes, the certificate expires. Events can transpire, however, that make a certificate invalid before it expires. Examples include the disclosure of the private key associated with the certificate, a change in the identifying information contained in the certificate, or the compromise of the CA’s private key. The compromise of a CA’s private key would invalidate all of the certificates that have been signed using that private key—quite a catastrophe for the CA and its customers.
When a certificate is prematurely terminated, the certificate is said to have been revoked . Using a revoked certificate is usually in conflict with the CA’s policy and could be risky since you can no longer rely on its integrity.
When a certificate has been revoked, the CA places the certificate on a certificate revocation list (CRL). The CRL is a data structure that contains identifying information about the CA, a timestamp, and a list of serial numbers of all the certificates that have been revoked. The CA signs the CRL to assert its authenticity and protect it from tampering. Whenever a certificate is used, the user should obtain the most recent CRL from the CA who issued the certificate and check to see that the certificate’s serial number is not on the CRL. Of course, no one’s going to do this unless the process is automated, a practice that is spotty at best.
Certificate authorities provide CRLs on a predefined schedule. The frequency of issuance depends on the level of assurance guaranteed by the types of certificates that are included. CRLs for certificates issued for causal use are not updated as frequently as those certificates used for high-value transactions. The level of protection afforded by a particular class of certificate depends, in part, on the frequency of CRL issuance and how CRL status is to be obtained. There are three general ways that CRLs can be checked:
The application using the certificate can ask the CA for the latest CRL. This is known as polling. The advantage is that the CRL is transferred only when it is needed. The disadvantage is that frequent polling can cause significant overhead to systems.
The application can subscribe to a service from the CA that sends the CRL out on a predefined schedule. This ensures that the application always has the latest CRL, but an attacker may be able to block the CRL from reaching its destination and the application may be none the wiser.
The application could query an online service provided by the CA. The advantage of this approach is that the application always has the latest information, and only information relevant to the application is passed back (the status of a particular certificate). The disadvantage is that the CA must operate a secure, real-time infrastructure for this purpose.
Of course, all this is moot if the application does not check the CRL. Internet Explorer (IE Version 6.02), for example, has CRL-checking code built-in, but it is turned off by default. This means that the browser will indicate that it is securely connected to a site using SSL even if the certificate at that site has been compromised and revoked. If you turn it on, however, you’ll discover why it is turned off by default: IE can’t get CRL information at many sites and complains every time that happens.
Certificate revocation is one of the big holes in the use of digital certificates, because many applications do not support it and CAs often make it difficult, or at least expensive, to access CRLs. This is probably of minor concern for web browsers. It’s a greater concern when certificates are used in authentication schemes that control access to highly sensitive applications or protect sensitive data.
In the case of the Utah public-safety system I described at the beginning of this section, the system designers recognized that CRLs needed to be part of the system. Unfortunately, the online process offered by the CA was deemed too expensive. We found other, less-expensive means to check certificate revocations, but they were less than ideal. Ultimately, cost plays an important part in any identity system and the cost-risk trade-off can be difficult to quantify.
Public-Key Infrastructures
If digital certificates are to be widely used, there must be a supporting infrastructure that provides policies, rules, agreed upon standards, interoperability, and so on. This is called the public-key infrastructure (PKI). The PKI must have two characteristics: it must be secure and it must be scalable.
We’ve already discussed many of the standards and procedures that make up the public-key infrastructure, including algorithms, X.509 certificates, certification practice statements, and certificate revocation lists. If there were only one CA, then this would be enough and that CA would constitute the PKI. There are, however, dozens of CAs around the world, and we need methods of using and establishing the veracity of certificates from each of them.
Figure 6-4 shows the hierarchical relationship that exists among CAs. In this schematic, there are two independent hierarchies of digital certificates and certificate authorities. The root of one tree is CA1, and CA2 is the root of the other. Each of these root CAs has certified several subordinate CAs: CA3 and CA4, in the case of CA1. Consequently, the private key that CA3 uses to issue digital certificate DC2, for example, is associated with a digital certificate signed by CA1. The heavy bidirectional arrow in the figure is meant to indicate that CA1 and CA2 have cross-certified each other, signing each other’s digital certificates.
When we want to check the integrity and veracity of digital certificate DC3, we can use the digital certificate of CA3 to verify the signature on the certificate. We can further verify CA3 by checking to see that its digital certificate was signed by CA1, and we can check on CA1 by verifying its certificate was signed by CA2. The dotted line arrows in the diagram represent this check.
The series of checks represented by the dotted line is called a certification path . Whenever we are presented with a digital certificate, we can, in theory, discover its certification path as a way of checking its validity. In practice, discovering the certification path may be a complex problem. Solving it once might not be overly expensive, but checking each time the application uses the certificate probably is. As a result, most applications simply check that the certificate is signed by one of a large list of known CAs.
Browsers are a good example. Internet Explorer and Netscape both contain a list of certificate authorities that the browser knows. If the server you visit uses a digital certificate from one of these CAs, you’ll be securely connected. If the CA that issued the server certificate is not in the list of trusted CAs, you will be warned that the browser could not determine if the site is using a valid certificate and asked if you want to proceed. For performance reasons, browsers typically limit their certificate path discovery to one level. That is, if the certificate presented is not signed by one of the CAs trusted by the browser, the certificate is reported as untrusted.
Going Further
If you’d like to experiment with some of the concepts in this chapter, I recommend that you visit Thawte (http://www.thawte.com) and request an email certificate. Thawte will give you one for free, and you can use it with Firefox, Netscape, Mozilla, or Internet Explorer. You’ll go through an enrollment process and, once you’ve installed your newly minted certificate in your browser, be able to view the details of the data stored inside the certificate. Free certificates from Thawte are not very useful in establishing your identity, because Thawte doesn’t do anything to verify the identity of the requester. The certificate does, however, associate your email address with the public key contained in the certificate, and Thawte provides a process that you can use to verify your identity and have your name put into the certificate as well.
You can also use programs from the OpenSSL open source project to create, sign, and manipulate certificates. Using OpenSSL, you can create a certificate authority and use it to sign your own certificates. These certificates won’t be verifiable in many circumstances, because the certificate authority is not part of the trusted PKI, but they are useful in some circumstances. For example, I use a self-signed certificate to provide SSL connectivity to portions of my web site that I use. Since I issued the certificate, and only I and handful of other people who know me personally use the trusted features of the site, it provides sufficient security.
Conclusion
Integrity, non-repudiation, and confidentiality are important foundational properties in an identity management system. Almost every activity in identity management relies on one of more of these three concepts.
Public-key cryptography and the public-key infrastructure have suffered from over-hype—seen by some as the answer to every security problem that has surfaced over the years. For example, some have proposed the widespread adoption of digital certificates for authentication and authorization tasks. While the technology is theoretically up to the task, these schemes have usually collapsed under the weight of complexity, institutional policy, politics, and the sense that widespread adoption is too expensive or difficult to manage.
As an example, consider the task of using digital certificates to secure access to an online banking service. For a large bank, this means issuing millions of digital certificates and renewing them on a periodic basis. These certificates would need to be installed on client machines and then used and managed by the bank’s customers. Automating the process of installing and managing the certificate on the client’s machine opens significant holes in the security system, because this automated process could be exploited by attackers to install bogus certificates on unsuspecting customers’ machines.
For digital certificates to be effective in an identity infrastructure, users of digital certificate technology need be aware of the certificates at some level and actively participating in their installation and management. People have historically shown little tolerance for the subtle nuances and finicky installation procedures that accompany digital certificates today.
That’s not to say that public-key cryptography and digital certificates have no role. Indeed, SSL secures millions of web sessions every day in an effective manner with little thought by the many users. Digital certificates and the public-key infrastructure that supports them are a well-understood technology that can be used to provide support for identity management. To be effectively used, however, they must be used in conjunction with other technologies and protocols that we’ll discuss in coming chapters.