Core PKI Services: Authentication, Integrity, and Confidentiality

By Carlisle Adams and Steve Lloyd

On This Page

Definitions
Mechanisms
Operational Considerations
Summary
References
About the Authors

Chapter 4 from Understanding Public Key Infrastructure, published by MacMillan Technical Publishing

The previous chapter looked at the concept of a security infrastructure and gave a definition of a comprehensive PKI. Now, consider the services a PKI offers an organization. This chapter examines the fundamental, or core, security services associated with a PKI; the next chapter examines a number of additional services a PKI can enable for various business purposes.

Definitions

A PKI is generally considered to be associated with three primary services:

• Authentication—The assurance to one entity that another entity is who he/she/it claims to be.

• Integrity—The assurance to an entity that data has not been altered (intentionally or unintentionally) between "there" and "here," or between "then" and "now."

• Confidentiality—The assurance to an entity that no one can read a particular piece of data except the receiver(s) explicitly intended.

The following subsections explore these brief definitions in greater detail.

Authentication

Authentication, the assurance that an entity is who he/she/it claims to be, typically finds application in two primary contexts.

Entity identification, by itself, serves simply to identify the specific entity involved, essentially in isolation from any other activity that the entity might want to perform. Clearly this is of limited value (because the entity will typically want to perform other activities on the basis of its identity). Therefore, in practice, entity identification generally produces a concrete result that is then used to enable other activities or communications. For example, the process of entity identification may result in (or unlock) a symmetric key that can subsequently be used to decrypt a file for reading or modification, or to establish a secure communications channel with another entity. The identity itself, once authenticated, may also be associated with a set of privileges on an Access Control List for the purpose of making access control decisions.

Data origin identification identifies a specific entity as the source or origin of a given piece of data. This is not entity identification in isolation, nor is it entity identification for the explicit purpose of enabling some other activity. Rather, this is identification with the intent of statically and irrevocably binding the identified entity to some particular data, regardless of any subsequent activities in which the entity might engage. Such a process can provide support for a non-repudiation service (see Chapter 5, "PKI-Enabled Services," for a discussion on non-repudiation).

Entity Identification: Local Versus Remote

The area of authentication known as entity identification can be divided into two categories:

• Initial entity identification to the local environment (that is, to the entity's personal, physically proximate device with no communications to other devices on the network)

• Entity identification to a remote device, entity, or environment

Local authentication—initial authentication of an entity to the local environment—almost always involves the user directly and explicitly (a password or PIN must be entered; a thumbprint scan must be taken). By contrast, remote authentication—authentication of an entity to some remote environment—may or may not involve the user directly. In fact, the more sophisticated remote authentication systems do not explicitly involve the user for two reasons:

• It is hard to defend an authentication system that takes sensitive authenticating information, such as a password or thumbprint, and passes it over insecure lines (where it may be copied for later reuse by an unscrupulous party) to a remote location.

• It is inconvenient for users to have to re-enter authenticating information each time that they want to make a remote network connection.

Thus, a preferable solution is for the result, or the effect, of the local authentication process to be conveyed to the remote location without passing the actual authenticating value itself. For example, when the entity needs to access a remote environment, a secure communications session could be established between the two environments so that the local environment can essentially say, "Here is the identity; I have already ensured it is correct." Therefore, the password, PIN, or thumbprint does not need to be sent to the remote environment. Note that such a solution can also be used for subsequent authentication (that is, after a successful initial authentication) to other applications within the local environment to achieve secure single sign-on; see Chapter 3, "The Concept of an Infrastructure."

Entity Identification: Single-Factor Versus Multi-Factor

There are many ways of proving an identity. These can be divided into four categories:

• Something you have (such as a smart card or a hardware token)

• Something you know (such as a password or a PIN)

• Something you are, or something intrinsic to your body (such as a thumbprint or a retinal scan)

• Something you do (such as your typing characteristics or handwriting style)

The concept of single-factor authentication is that only a single method among the preceding options is used. Multi-factor authentication uses more than one of the options simultaneously during the authentication process (two-factor uses two, three-factor uses three, and so on). A familiar example of two-factor authentication is the "sign-on" process at a banking machine where the user presents a magnetic-stripe card ("something you have") and enters a PIN ("something you know") to gain access to his/her bank account. Clearly, multi-factor systems are more burdensome for the user (more tasks need to be completed before the authentication process is finished). However, the security benefit is that impersonation attacks become much more difficult (the would-be impersonator needs, for example, to know your password, imitate your typing style, and borrow your thumb without you knowing about it—all at the same time!).

Authentication as a PKI Service

One reason to distinguish between local and remote authentication (and between initial and subsequent authentication) is to distinguish between where a PKI can be helpful and where it cannot. Specifically, a PKI would rarely, if ever (one might go so far as to say "never"), be used for initial authentication of a human entity to the local environment. This is because a user is unlikely to know a private key (due to its length) and, even if it were known, the user would be highly unlikely to be able to do cryptographic calculations with it.

Also, nothing intrinsic to the user (such as a thumbprint or retinal scan) could be said to be the private key of a signing key pair. Similarly, nothing the user does (such as typing characteristics or handwriting style) is deterministic enough (in a strict sense) to be usable for generating a key pair. Finally, although the user may have something that contains a key pair and is able to do cryptographic calculations (such as a smart card), such devices are so easily lost or stolen that they are almost never allowed to function without the user entering a password or a PIN.

Thus, initial authentication to the local environment, whether single-factor or multi-factor, does not use the services of a PKI. Authentication to a remote environment (or subsequent authentication within the local environment), on the other hand, can. When remote authentication does not use a PKI, there are two possibilities:

• The user must authenticate explicitly to the remote environment.

• The proof of authentication from the local environment must somehow be conveyed to the remote environment.

In either case, the communication between the local and remote environments must be properly protected; otherwise, an eavesdropper can simply copy the relevant data and later replay it, thereby successfully masquerading as the original, legitimate entity. Properly protecting the communications may mean employing mechanisms that are difficult to administer or that do not scale well to large environments, such as pre-establishing shared symmetric keys between the respective communicating processes (see Chapter 6, "Certificates and Certification," for a discussion on scalability issues).

For these reasons, the benefits in using a PKI for remote authentication can be attractive. The complexity of pre-establishing shared keys between processes is eliminated, as is the security risk of transmitting sensitive authenticating information (such as a password or a thumbprint) over a network. Rather, public-key technology is used to achieve the authentication using sophisticated challenge-response protocols and signed messages.

The distinct advantage of public-key-based remote authentication over mechanisms that mimic authentication to the local environment is that sensitive authenticating information, such as a password, is never sent over the network. If server Alice holds a copy of client Bob's password or thumbprint, Bob must authenticate himself by proving that he knows or has this information; this is typically accomplished by Bob conveying this information to Alice upon sign-on (see Figure 4.1).

Figure 4.1: Bob authenticates to Alice using an ID/password pair.

By contrast, if Alice holds a copy of Bob's verification public key, she can ask Bob to sign a one-time challenge message with the corresponding signing private key (which only Bob knows); if the signed response is returned, Bob has authenticated himself without having to reveal any sensitive information (see Figure 4.2). Nothing travels over the network that can be used by an eavesdropper to later impersonate Bob. Furthermore, Alice and Bob do not need to engage in a costly and inconvenient process to pre-establish shared secret information (for example, to pre-load Alice with a copy of Bob's password or thumbprint). Alice may simply retrieve a copy of Bob's public key from his verification certificate, which, for example, may be stored in a publicly known and publicly accessible repository or may have been sent directly to Alice from Bob (see Chapter 6 for a discussion on certificates).

Figure 4.2: Bob authenticates to Alice using public-key-based remote authentication.

One very appealing benefit of the authentication service associated with the PKI is the possibility of single sign-on to PKI-enabled devices (and perhaps, through gateway servers, to other types of devices as well). Specifically, a user may sign-on initially to the local environment (using single-factor or multi-factor authentication, as appropriate). This process results in the user gaining local access to his/her private key(s). The signing private key can then be used to authenticate the user automatically and transparently to other servers and devices around the network whenever he/she wants to establish a connection with them. The user may freely roam both the local and remote environments without the need to enter a password, or place a thumb on the biometric print scanner, again (see Chapter 3 for a discussion on secure single sign-on).

The PKI, therefore, offers an authentication service with a number of definite advantages over non-PKI-based authentication mechanisms. Entity identification is possible with PKI authentication, in which case the entity's signing private key is used to authenticate the entity to other entities in the local or remote environment. It also can be used for data origin authentication. In this case, the entity's signing private key is used to bind the entity to a particular piece of data (perhaps as non-repudiable evidence that can be used subsequently to prove to a third party that this entity did originate—or at least possess—this data).

Integrity

Data integrity is the assurance of non-alteration: The data (either in transit or in storage) has not been undetectably altered. Clearly, such assurance is essential in any kind of business or electronic commerce environment, but it is desirable in many other environments as well. A level of data integrity can be achieved by mechanisms such as parity bits and Cyclic Redundancy Codes (CRCs). Such techniques, however, are designed only to detect some proportion of accidental bit errors; they are powerless to thwart deliberate data manipulation by a determined adversary whose goal is to modify the content of the data for his or her own gain.

To protect data against this sort of attack, cryptographic techniques are required. Thus, appropriate algorithms and keys must be employed and commonly understood between the entity wanting to provide data integrity and the entity wanting to be assured of data integrity. The PKI service of integrity can be extremely useful in meeting the needs of both entities because it is the framework through which algorithm selection and key agreement can take place. Furthermore, such negotiations can occur in a way that is completely transparent to the entities involved so that integrity can be assumed in all PKI-related data transactions. (This situation changes only when integrity verification fails for some specific piece of data, in which case the user must be notified so that appropriate action can be taken.)

Confidentiality

Confidentiality is the assurance of data privacy: No one may read the data except for the specific entity (or entities) intended. Confidentiality is a requirement

• When data is stored on a medium (such as a computer hard drive) that can be read by an unauthorized individual.

• When data is backed up onto a device (such as a tape) that can fall into the hands of an unauthorized individual.

• When data is transmitted over unprotected networks.

Furthermore, given the sophistication and power of determined adversaries today, cryptographic techniques for providing confidentiality must be employed for all sensitive data. As with integrity, this necessitates a common understanding between entities of appropriate algorithms and keys. The PKI confidentiality service is the framework through which such a common understanding can be reached in a way that is transparent to the actual entities involved. Other non-PKI-based confidentiality services require explicit entity interaction at some level and, therefore, are more error prone and more cumbersome to use.

Mechanisms

This section gives a brief overview of the cryptographic mechanisms used to enable the PKI services of authenticity, integrity, and confidentiality. See the Handbook of Applied Cryptography [MvOV97] for further discussion.

Authentication

The PKI service of authentication (as opposed to the non-PKI operation of initial authentication to the local environment, which may involve single- or multi-factor authentication including passwords or biometric devices) employs the cryptographic technique of a digital signature. The signature may be computed over the hash of one of the following three values:

• Some data to be authenticated

• Some request that the user intends to send to a remote device

• A random challenge issued by a remote device

The first issue supports the PKI service of data origin authentication; the latter two support the PKI service of entity authentication.

Note: Whether entity authentication is done through a signature on a user request or through a signature on a random challenge depends upon the operational characteristics and requirements of a particular environment. Typically, environments in which entities have access to a common, trusted source of time will use the first alternative, whereas environments in which nonce values will be used (instead of time stamps) to provide replay protection will use the second alternative.

A good cryptographic hash function is required to reduce the data or the request message to a size suitable for a single computation of the signature function. It is also helpful in preventing an attacker from getting the decryption of a random-looking value (in certain signature algorithms such as RSA [RSA78]), which may yield valuable information in some circumstances [KR95]. Digital signatures and hash functions are introduced in Chapter 2, "Public-Key Cryptography."

Integrity

The PKI service of integrity may employ one of two techniques. First, a digital signature, while it serves the purpose of providing authenticity (that is, entity authentication), simultaneously provides integrity over the signed data. This is a consequence of a necessary property of cryptographic hash algorithms and signature algorithms; any change in the input data leads to a large, unpredictable change in the output with very high probability. In other words, if the data has changed (either by accident, or by deliberate manipulation) between "there" and "here" or between "then" and "now," the signature will fail to verify, and the loss of integrity will be obvious to the recipient. If, on the other hand, the signature verifies, the recipient is very likely to be in possession of the original (that is, unaltered) data.

The second technique that can be employed for integrity is a Message Authentication Code, or MAC. This technique typically uses a symmetric block cipher (for example, DES-CBC-MAC [FIPS113]) or a cryptographic hash function (for example, HMAC-SHA-1 [RFC2104]); see Chapter 2 for a discussion of ciphers and hash functions. Although these are both symmetric solutions (as opposed to public-key solutions), it is important to note that they are both keyed mechanisms; in particular, they depend on a key that must be shared between the sender of the integrity-protected data and the "consumer" (for example, receiver) of the integrity-protected data. In some environments, the shared key can be derived from a PKI (see IPsec [RFC2401, RFC2411] for example).

The PKI service of integrity for this second technique, then, is that of putting in place the mechanisms to achieve this key sharing when necessary. If Alice wants to send to Bob some integrity-protected data and Bob has an encryption public key, Alice can employ the following sequence of steps:

1. Generate a fresh symmetric key.

2. Use the symmetric key to generate a MAC for the data.

3. Encrypt the symmetric key for Bob using his encryption public key.

4. Send the data to Bob along with the encrypted key.

Alternatively, if Bob has a key exchange public key (such as a Diffie-Hellman public key—see Chapter 2), Alice can instead use the following procedure:

1. Use Bob's key-exchange public key in combination with her key-exchange private key to generate a symmetric key.

2. MAC the data using that symmetric key.

3. Send the data to Bob along with her public key certificate.

Bob can then regenerate the symmetric key using Alice's public key and his own private key to verify the integrity of the data.

If a digital signature is not used to provide data integrity, a good cryptographic MAC function is required. Digital signatures and MAC functions are introduced in Chapter 2.

Confidentiality

The PKI service of confidentiality uses a mechanism similar to one of the alternatives of the integrity service. That is:

• Alice generates a symmetric key (perhaps by using her key-exchange private key in combination with Bob's key-exchange public key).

• The symmetric key is used to encrypt the data (using a symmetric block cipher such as CAST-128 [RFC2144]).

• The encrypted data is sent to Bob either along with Alice's key exchange public key, or with a copy of the symmetric key encrypted with Bob's encryption public key.

Chapter 2 introduces key exchange and key transfer mechanisms to establish a symmetric key between the entities, Alice and Bob.

Operational Considerations

A number of operational considerations must be taken into account when a PKI is associated with its core services of authentication, integrity, and confidentiality. These include the following:

• Performance

• On-line versus off-line operation

• Commonality of underlying algorithms

• Entity naming

Each of these is described further in the following subsections.

Performance

Public-key operations are significantly slower than symmetric key operations. Thus, although an encryption public key theoretically can be used to encrypt large quantities of data, in a practical system it is virtually never used for this purpose. Rather, the data is encrypted using a symmetric key, and that key is encrypted in a single operation using an encryption public key. Similarly, a symmetric-key-based MAC will typically be a preferred data integrity mechanism unless a digital signature is already required for the purpose of data origin authentication.

The PKI services of integrity and confidentiality, therefore, consist of the less- performance-intensive key sharing (or key establishment) aspects, rather than the more-performance-intensive signature (or data encryption) aspects. This combination of public key and symmetric key mechanisms provides the required services at a performance cost that is acceptable for many environments.

On-Line Versus Off-Line Operation

One of the significant advantages of a PKI over a purely symmetric-key-based infrastructure is the possibility of off-line operation. That is, Alice can sign data, integrity-protect data, or encrypt data for Bob, or she can verify Bob's signature on data, verify Bob's integrity-protection on data, or decrypt data from Bob, all while she is working off-line (for example, on her laptop, which is not connected to the network). Alice will not have access to the most current revocation status information (see Chapter 8, "Certificate Revocation") when she works in this mode, but in some circumstances and for some types of communication this may be acceptable.

The desire for off-line operation may determine the key establishment mechanisms available for use. For example, real-time, peer-to-peer key exchange using an algorithm such as ephemeral-ephemeral Diffie-Hellman (DH) would not be possible. However, non-real-time key exchange using ephemeral-static DH or static-static DH is entirely possible, as well as key exchange using an algorithm such as Rivest-Shamir-Adleman (RSA). Thus, although every mechanism choice may not be available, the core PKI services are available and operational during off-line mode.

DH Communication Configurations

In ephemeral-ephemeral DH, each party in the key establishment protocol generates an ephemeral key pair (that is, one that has never been used before and is never to be used again) solely for the purposes of this protocol. In ephemeral-static DH, one of the parties, Bob for example, generates an ephemeral key pair for this protocol, and the other party, Alice, uses a pre-existing key pair. In particular, Alice's pre-existing public key can be contained in a certificate that Bob can hold locally or obtain from a public repository prior to engaging in the protocol. In static-static DH, both Alice and Bob use pre- existing key pairs.

Commonality of Underlying Algorithms

A fundamental requirement for the PKI to operate is that a common understanding of algorithms can be achieved between PKI entities. This understanding may be limited and rigid in that a fixed, single algorithm for providing each PKI service is hard-coded into each entity upon start-up (that is, a digital signature algorithm, a hash algorithm, a key transfer algorithm, a key exchange algorithm, a MAC algorithm, and a symmetric cipher algorithm).

Much more often, however, this understanding is fluid and dynamic in that an entity, Alice, will "discover" the algorithm(s) acceptable to Bob at the time she needs to communicate with Bob. Alice will, therefore, use the algorithm appropriate for both the circumstances of the communication and the intended recipient(s) of the communication. Algorithm discovery can be accomplished through the use of certificates (that is, Bob's preferred algorithms are encoded within his public-key certificate; see Chapter 6 for a discussion on certificates).

Alternatively, algorithm discovery can be accomplished through the use of authenticated negotiation ("hand shaking") protocols (such as IKE [RFC2409], for example), out-of-band communications, or some other means. Whatever the mechanism, a commonality of underlying algorithms must be achieved so that communication between PKI entities and, therefore, the set of security services offered by the PKI can occur.

Entity Naming

An assumption implicit in much of the preceding discussion is that entity Bob has an identity that is known to and understood by entity Alice. Alice somehow knows, prior to sending data to Bob, that this is the particular Bob to whom she wants to send this data. This problem is typically known as the entity naming problem: How can names be assigned to entities in a way that is unique and meaningful to other relevant entities?

Many, varied techniques exist for solving this problem, and they include the extreme suggestion that there is no solution and that the use of entity naming should be avoided entirely. This topic is discussed in more detail in Chapter 9, "Trust Models"; for the time being, note that Alice must have some way of knowing with whom she is communicating for that communication to be meaningful and relevant.

Summary

Authentication (both entity authentication and data origin authentication), integrity, and confidentiality are the core security services provided by a PKI. These services enable entities to prove that they are who they claim to be, to be assured that important data has not been altered in any way, and to be convinced that data sent to another entity can be read only by that entity. Organizations can derive tremendous benefits from these services by using them to ensure, for example, that highly sensitive information only gets into the hands of those with an explicit "need-to-know."

Two needs must be addressed to make these core security services fully available to PKI entities. First, it must be possible for entity Alice to associate a public key unambiguously and correctly with Bob, the entity with whom she wants to communicate. This is the fundamental purpose for the concept of a certificate; this topic is discussed in Chapter 6. Second, to deal with the relatively common situation in which Alice does not already have Bob's certificate, Alice must have the capability to retrieve that certificate from a public repository. In this way, she can communicate securely with him. (Recall that the underlying premise of public-key cryptography is that secure communication between strangers can be achieved precisely through the use of such public repository concepts.) The description and use of public repositories for certificate information is the topic of Chapter 11, "PKI Information Dissemination: Repositories and Other Techniques."

References

[FIPS113] Federal Information Processing Standards Publication 113. "Computer Data Authentication." U.S. Department of Commerce, National Bureau of Standards, National Technical Information Service. Springfield, Virginia, 1985.

[KR95] Kaliski, B. and M. Robshaw. "The Secure Use of RSA." RSA Laboratories' CryptoBytes 1, no. 3 (Autumn 1995).

[MvOV97] Menezes, A., P. van Oorschot, and S. Vanstone. Handbook of Applied Cryptography. Boca Raton: CRC Press, 1997.

[RFC2104] Krawczyk, H., M. Bellare, and R. Canetti. "HMAC: Keyed Hashing for Message Authentication." Internet Request for Comments 2104. (February 1997).

[RFC2144] Adams, C. "The CAST-128 Encryption Algorithm." Internet Request for Comments 2144. (May 1997).

[RFC2401] Kent, S. and R. Atkinson. "Security Architecture for the Internet Protocol." Internet Request for Comments 2401. (November 1998).

[RFC2409] Harkins, D. and D. Carrel. "The Internet Key Exchange (IKE)." Internet Request for Comments 2409. (November 1998).

[RFC2411] Thayer, R., N. Doraswamy, and R. Glenn. "IP Security Document Roadmap." Internet Request for Comments 2411. (November 1998).

[RSA78] Rivest, R., A. Shamir, and L. Adleman. "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems." Communications of the ACM. 21 (1978): 120–126.

About the Authors

Carlisle Adams is currently Senior Cryptographer and Senior Manager—Standards Program at Entrust Technologies.

Steve Lloyd is a Senior Consultant with the Advanced Security Technology Group at Entrust Technologies.

Copyright © 1999 by MacMillan Technical Publishing

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice. International rights = English only.

International rights = English only.

Click to order