CHAPTER 14 CRYPTOGR AND NETWORK SECURITY

Editor's Notes

• #1: Lecture slides by Lawrie Brown for “Cryptography and Network Security”, 5/e, by William Stallings, Chapter 14 – “Key Management and Distribution”.
• #2: Opening quote.
• #3: The topics of cryptographic key management and cryptographic key distribution are complex, involving cryptographic, protocol, and management considerations. The purpose of this chapter is to give the reader a feel for the issues involved and a broad survey of the various aspects of key management and distribution.
• #4: For symmetric encryption to work, the two parties to an exchange must share the same key, and that key must be protected from access by others. Furthermore, frequent key changes are usually desirable to limit the amount of data compromised if an attacker learns the key. This is one of the most critical areas in security systems - on many occasions systems have been broken, not because of a poor encryption algorithm, but because of poor key selection or management. It is absolutely critical to get this right!
• #5: The strength of any cryptographic system thus depends on the key distribution technique. For two parties A and B, key distribution can be achieved in a number of ways: Physical delivery (1 & 2) is simplest - but only applicable when there is personal contact between recipient and key issuer. This is fine for link encryption where devices & keys occur in pairs, but does not scale as number of parties who wish to communicate grows (see next slide). 3 is mostly based on 1 or 2 occurring first, and also suffers that if an attacker ever succeeds in gaining access to one key, then all subsequent keys will be revealed. A third party, whom all parties trust, can be used as a trusted intermediary to mediate the establishment of secure communications between them (4). Must trust intermediary not to abuse the knowledge of all session keys. As number of parties grow, some variant of 4 is only practical solution to the huge growth in number of keys potentially needed.
• #6: The scale of the problem depends on the number of communicating pairs that must be supported. If end-to-end encryption is done at a network or IP level, then a key is needed for each pair of hosts on the network that wish to communicate. Thus, if there are N hosts, the number of required keys is [N(N – 1)]/2. If encryption is done at the application level, then a key is needed for every pair of users or processes that require communication. Thus, a network may have hundreds of hosts but thousands of users and processes. Stallings Figure 14.1 illustrates the magnitude of the key distribution task for end-to-end encryption. A network using node-level encryption with 1000 nodes would conceivably need to distribute as many as half a million keys. If that same network supported 10,000 applications, then as many as 50 million keys may be required for application-level encryption.
• #7: For end-to-end encryption, some variation on option 4 has been widely adopted. In this scheme, a key distribution center is responsible for distributing keys to pairs of users (hosts, processes, applications) as needed. Each user must share a unique key with the key distribution center for purposes of key distribution. The use of a key distribution center is based on the use of a hierarchy of keys. At a minimum, two levels of keys are used: a session key, used for the duration of a logical connection; and a master key shared by the key distribution center and an end system or user and used to encrypt the session key.
• #8: The use of a key distribution center is based on the use of a hierarchy of key, as shown in Stallings Figure 14.2. Communication between end systems is encrypted using a temporary key, often referred to as a session key. Typically, the session key is used for the duration of a logical connection, such as a frame relay connection or transport connection, and then discarded. Each session key is obtained from the key distribution center over the same networking facilities used for end-user communication. Accordingly, session keys are transmitted in encrypted form, using a master key that is shared by the key distribution center and an end system or user. For each end system or user, there is a unique master key that it shares with the key distribution center. Of course, these master keys must be distributed in some fashion. However, the scale of the problem is vastly reduced, as only N master keys are required, one for each entity. Thus, master keys can be distributed in some non-cryptographic way, such as physical delivery.
• #9: The key distribution concept can be deployed in a number of ways. A typical scenario is illustrated in Stallings Figure 14.3 above, which has a “Key Distribution Center” (KDC) which shares a unique key with each party (user). The text in section 14.1 details the steps needed, which are briefly: 1. A requests from the KDC a session key to protect a logical connection to B. The message includes the identity of A and B and a unique nonce N1. 2. The KDC responds with a message encrypted using Ka that includes a one-time session key Ks to be used for the session, the original request message to enable A to match response with appropriate request, and info for B 3. A stores the session key for use in the upcoming session and forwards to B the information from the KDC for B, namely, E(Kb, [Ks || IDA]). Because this information is encrypted with Kb, it is protected from eavesdropping. At this point, a session key has been securely delivered to A and B, and they may begin their protected exchange. Two additional steps are desirable: 4. Using the new session key for encryption B sends a nonce N2 to A. 5. Also using Ks, A responds with f(N2), where f is a function that performs some transformation on N2 (eg. adding one). These steps assure B that the original message it received (step 3) was not a replay. Note that the actual key distribution involves only steps 1 through 3 but that steps 4 and 5, as well as 3, perform an authentication function.
• #10: Briefly note here some of the major issues associated with the use of Key Distribution Centers (KDC’s). For very large networks, a hierarchy of KDCs can be established. For communication among entities within the same local domain, the local KDC is responsible for key distribution. If two entities in different domains desire a shared key, then the corresponding local KDCs can communicate through a (hierarchy of) global KDC(s) To balance security & effort, a new session key should be used for each new connection-oriented session. For a connectionless protocol, a new session key is used for a certain fixed period only or for a certain number of transactions. An automated key distribution approach provides the flexibility and dynamic characteristics needed to allow a number of terminal users to access a number of hosts and for the hosts to exchange data with each other, provided they trust the system to act on their behalf. The use of a key distribution center imposes the requirement that the KDC be trusted and be protected from subversion. This requirement can be avoided if key distribution is fully decentralized. In addition to separating master keys from session keys, may wish to define different types of session keys on the basis of use. These issues are discussed in more detail in the text Stallings section 14.1.
• #11: Because of the inefficiency of public key cryptosystems, they are almost never used for the direct encryption of sizable block of data, but are limited to relatively small blocks. One of the most important uses of a public key cryptosystem is to encrypt secret keys for distribution. We see many specific examples of this later in the text.
• #12: An extremely simple scheme was put forward by Merkle from Stallings Figure 14.7. If A wishes to communicate with B, the following procedure is employed: A generates a public/private key pair {PUa, PRa} and transmits a message to B consisting of PUa and an identifier of A, IDA. B generates a secret key, Ks, and transmits it to A, encrypted with A's public key. A computes D(PRa, E(PUa, Ks)) to recover the secret key. Because only A can decrypt the message, only A and B will know the identity of Ks. A discards PUa and PRa and B discards PUa. A and B can now securely communicate using conventional encryption and the session key Ks. At the completion of the exchange, both A and B discard Ks. Despite its simplicity, this is an attractive protocol. No keys exist before the start of the communication and none exist after the completion of communication. Thus, the risk of compromise of the keys is minimal. At the same time, the communication is secure from eavesdropping.
• #13: The protocol depicted in Figure 14.7 is insecure against an adversary who can intercept messages and then either relay the intercepted message or substitute another message (see Stallings Figure 1.3c). Such an attack is known as a man-in-the-middle attack. In this case, if an adversary, E, has control of the intervening communication channel, then E can compromise the communication in the following fashion without being detected: A generates a public/private key pair {PUa, PRa} and transmits a message intended for B consisting of PUa and an identifier of A, IDA. E intercepts the message, creates its own public/private key pair {PUe, PRe} and transmits PUe || IDA to B. B generates a secret key, Ks, and transmits E(PUe, Ks). E intercepts the message and learns Ks by computing D(PRe, E(PUe, Ks)). E transmits E(PUa, Ks) to A. The result is that both A and B know Ks and are unaware that Ks has also been revealed to E. A and B can now exchange messages using Ks. E no longer actively interferes with the communications channel but simply eavesdrops. Knowing Ks, E can decrypt all messages, and both A and B are unaware of the problem. Thus, this simple protocol is only useful in an environment where the only threat is eavesdropping.
• #14: Stallings Figure 14.8, based on an approach suggested in [NEED78], provides protection against both active and passive attacks. Assuming A and B have exchanged public keys by one of the schemes described subsequently in this chapter, then the following steps occur: A uses B's public key to encrypt a message to B containing an identifier of A (IA) and a nonce (N1), which is used to identify this transaction uniquely. B sends a message to A encrypted with PUa and containing A's nonce (N1) as well as a new nonce generated by B (N2). Because only B could have decrypted message (1), the presence of N1 in message (2) assures A that the correspondent is B. A returns N2, encrypted using B's public key, to assure B that its correspondent is A. A selects a secret key Ks and sends M = E(PUb, E(PRa, Ks)) to B. Encryption with B's public key ensures that only B can read it; encryption with A's private key ensures that only A could have sent it. B computes D(PUa, D(PRb, M)) to recover the secret key. The result is that this scheme ensures both confidentiality and authentication in the exchange of a secret key.
• #15: Yet another way to use public-key encryption to distribute secret keys is a hybrid approach in use on IBM mainframes [LE93]. This scheme retains the use of a key distribution center (KDC) that shares a secret master key with each user and distributes secret session keys encrypted with the master key. A public key scheme is used to distribute the master keys. The addition of a public-key layer provides a secure, efficient means of distributing master keys. This is an advantage in a configuration in which a single KDC serves a widely distributed set of users.
• #16: Several techniques have been proposed for the distribution of public keys, which can mostly be grouped into the categories shown.
• #17: The point of public-key encryption is that the public key is public, hence any participant can send his or her public key to any other participant, or broadcast the key to the community at large. Its major weakness is forgery, anyone can create a key claiming to be someone else and broadcast it, and until the forgery is discovered they can masquerade as the claimed user.
• #18: A greater degree of security can be achieved by maintaining a publicly available dynamic directory of public keys. Maintenance and distribution of the public directory would have to be the responsibility of some trusted entity or organization. This scheme is clearly more secure than individual public announcements but still has vulnerabilities to tampering or forgery.
• #19: Stronger security for public-key distribution can be achieved by providing tighter control over the distribution of public keys from the directory. It requires users to know the public key for the directory, and that they interact with directory in real-time to obtain any desired public key securely. This scenario is attractive, yet it has some drawbacks. The public-key authority could be somewhat of a bottleneck in the system, for a user must appeal to the authority for a public key for every other user that it wishes to contact. As before, the directory of names and public keys maintained by the authority is vulnerable to tampering.
• #20: Stallings Figure 14.11 “Public-Key Authority” illustrates a typical protocol interaction. As before, the scenario assumes that a central authority maintains a dynamic directory of public keys of all participants. In addition, each participant reliably knows a public key for the authority, with only the authority knowing the corresponding private key. See text for details of steps in protocol. A total of seven messages are required. However, the initial four messages need be used only infrequently because both A and B can save the other's public key for future use, a technique known as caching. Periodically, a user should request fresh copies of the public keys of its correspondents to ensure currency.
• #21: An further improvement, first suggested by Kohnfelder, is to use certificates, which can be used to exchange keys without contacting a public-key authority, in a way that is as reliable as if the keys were obtained directly from a public-key authority. A certificate binds an identity to public key, with all contents signed by a trusted Public-Key or Certificate Authority (CA). A user can present his or her public key to the authority in a secure manner, and obtain a certificate. The user can then publish the certificate. Anyone needing this user's public key can obtain the certificate and verify that it is valid by way of the attached trusted signature. A participant can also convey its key information to another by transmitting its certificate. Other participants can verify that the certificate was created by the authority, provided they know its public key. One scheme has become universally accepted for formatting public-key certificates: the X.509 standard. X.509 certificates are used in most network security applications, including IP security, secure sockets layer (SSL), secure electronic transactions (SET), and S/MIME. Will discuss it in much more detail later.
• #22: A certificate scheme is illustrated in Stallings Figure 14.12. Each participant applies to the certificate authority, supplying a public key and requesting a certificate. Application must be in person or by some form of secure authenticated communication. For participant A, the authority provides a certificate CA. A may then pass this certificate on to any other participant, who can read and verify the certificate by verifying the signature from the certificate authority. Because the certificate is readable only using the authority's public key, this verifies that the certificate came from the certificate authority. The timestamp counters the following scenario. A's private key is learned by an adversary. A generates a new private/public key pair and applies to the certificate authority for a new certificate. Meanwhile, the adversary replays the old certificate to B. If B then encrypts messages using the compromised old public key, the adversary can read those messages. In this context, the compromise of a private key is comparable to the loss of a credit card. The owner cancels the credit card number but is at risk until all possible communicants are aware that the old credit card is obsolete. Thus, the timestamp serves as something like an expiration date. If a certificate is sufficiently old, it is assumed to be expired. One scheme has become universally accepted for formatting public-key certificates: the X.509 standard.
• #23: X.509 is part of the X.500 series of recommendations that define a directory service, being a server or distributed set of servers that maintains a database of information about users. X.509 defines a framework for the provision of authentication services by the X.500 directory to its users. The directory may serve as a repository of public-key certificates. In addition, X.509 defines alternative authentication protocols based on the use of public-key certificates. X.509 is based on the use of public-key cryptography and digital signatures. The standard does not dictate the use of a specific algorithm but recommends RSA. The X.509 certificate format is widely used, in for example S/MIME, IP Security and SSL/TLS and SET. X.509 was initially issued in 1988. The standard was subsequently revised to address some of the security concerns; a revised recommendation was issued in 1993. A third version was issued in 1995 and revised in 2000.
• #24: X.509 is based on the use of public-key cryptography and digital signatures. The standard does not dictate the use of a specific algorithm but recommends RSA. The digital signature scheme is assumed to require the use of a hash function. Again, the standard does not dictate a specific hash algorithm. The 1988 recommendation included the description of a recommended hash algorithm; this algorithm has since been shown to be insecure and was dropped from the 1993 recommendation. Stallings Figure 14.13 illustrates the generation of a public-key certificate.
• #25: The heart of the X.509 scheme is the public-key certificate associated with each user. There are 3 versions, with successively more info in the certificate - must be v2 if either unique identifier field exists, must be v3 if any extensions are used. These user certificates are assumed to be created by some trusted certification authority (CA) and placed in the directory by the CA or by the user. The directory server itself is not responsible for the creation of public keys or for the certification function; it merely provides an easily accessible location for users to obtain certificates. The certificate includes the elements shown, see text for further details. The standard uses the notation for a certificate of: CA<<A>> where the CA signs the certificate for user A with its private key. In more detail CA<<A>> = CA {V, SN, AI, CA, UCA, A, UA, Ap, TA}. If the corresponding public key is known to a user, then that user can verify that a certificate signed by the CA is valid. This is the typical digital signature approach illustrated in Stallings Figure 13.2.
• #26: Stallings Figure 14.4 shows the format of an X.509 certificate and CRL (see later).
• #27: User certificates generated by a CA have the characteristics that any user with access to the public key of the CA can verify the user public key that was certified, and no party other than the certification authority can modify the certificate without this being detected. Because certificates are unforgeable, they can be placed in a directory without the need for the directory to make special efforts to protect them.
• #28: If both parties use the same CA, they know its public key and can verify others certificates. If there is a large community of users, it may not be practical for all users to subscribe to the same CA. With many users, it may be more practical for there to be a number of CAs, each of which securely provides its public key to some fraction of the users. Hence there has to be some means to form a chain of certifications between the CA's used by the two parties, by the use of client and parent certificates. All these certificates of CAs by CAs need to appear in the directory, and the user needs to know how they are linked to follow a path to another user's public-key certificate. X.509 suggests that CAs be arranged in a hierarchy so that navigation is straightforward. It is assumed that each client trusts its parents certificates.
• #29: Stallings Figure 14.15 illustrates the use of an X.509 hierarchy to mutually verify clients certificates. The connected circles indicate the hierarchical relationship among the CAs; the associated boxes indicate certificates maintained in the directory for each CA entry. The directory entry for each CA includes two types of certificates: Forward certificates: Certificates of X generated by other CAs, and Reverse certificates: Certificates generated by X that are the certificates of other CAs. In this example, we can track chains of certificates as follows: A acquires B certificate using chain: X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>> B acquires A certificate using chain: Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>
• #30: A certificate includes a period of validity. Typically a new certificate is issued just before the expiration of the old one. In addition, it may be desirable on occasion to revoke a certificate before it expires, for one of a range of reasons, such as those shown above. To support this, each CA must maintain a list consisting of all revoked but not expired certificates issued by that CA, known as the certificate revocation list (CRL). Each certificate revocation list (CRL) posted to the directory is signed by the issuer and includes (as shown in Stallings Figure 14.14b previously) the issuer's name, the date the list was created, the date the next CRL is scheduled to be issued, and an entry for each revoked certificate. Each entry consists of the serial number of a certificate and revocation date for that certificate. Because serial numbers are unique within a CA, the serial number is sufficient to identify the certificate. When a user receives a certificate in a message, the user must determine whether the certificate has been revoked, by checking the directory CRL each time a certificate is received, this often does not happen in practice.
• #31: The X.509 version 2 format does not convey all of the information that recent design and implementation experience has shown to be needed. Rather than continue to add fields to a fixed format, standards developers felt that a more flexible approach was needed. X.509 version 3 includes a number of optional extensions that may be added to the version 2 format. Each extension consists of an extension identifier, a criticality indicator, and an extension value. The criticality indicator indicates whether an extension can be safely ignored or not (in which case if unknown the certificate is invalid).
• #32: The certificate extensions fall into three main categories: key and policy information - convey additional information about the subject and issuer keys, plus indicators of certificate policy. A certificate policy is a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. subject and issuer attributes - support alternative names, in alternative formats, for a certificate subject or certificate issuer and can convey additional information about the certificate subject; eg. postal address, email address, or picture image certification path constraints - allow constraint specifications to be included in certificates issued for CA’s by other CA’s that may restrict the types of certificates that can be issued by the subject CA or that may occur subsequently in a certification chain.
• #33: RFC 2822 (Internet Security Glossary) defines public-key infrastructure (PKI) as the set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates based on asymmetric cryptography. Its principal is to enable secure, convenient, and efficient acquisition of public keys. The IETF Public Key Infrastructure X.509 (PKIX) working group has setup a formal (and generic) model based on X.509 that is suitable for deploying a certificate-based architecture on the Internet. Stallings Figure 14.16 shows interrelationships among some key elements: • End entity: A generic term used to denote end users, devices (e.g., servers, routers), or any other entity that can be identified in the subject field of a public key certificate. End entities canconsume and/or support PKI-related services. • Certification authority (CA): The issuer of certificates and (usually) certificate revocation lists (CRLs). It may also support a variety of administrative functions, although these are often delegated to Registration Authorities. • Registration authority (RA): An optional component that can assume a number of administrative functions from the CA. The RA is often associated with the End Entity registration process, but can assist in a number of other areas as well. • CRL issuer: An optional component that a CA can delegate to publish CRLs. • Repository: A generic term used to denote any method for storing certificates and CRLs so that they can be retrieved by End Entities.
• #34: PKIX identifies a number of management functions that potentially need to be supported by management protocols, as shown in Figure 14.16: • Registration: whereby a user first makes itself known to a CA, prior to issue of a certificate(s) for that user. It usually involves some off-line or online procedure for mutual authentication. • Initialization: to install key materials that have the appropriate relationship with keys stored elsewhere in the infrastructure. • Certification: process where a CA issues a certificate for a user's public key, and returns it to the user's client system and/or posts it in a repository. • Key pair recovery: a mechanism to recover the necessary decryption keys when normal access to the keying material is no longer possible. • Key pair update: key pairs need to be updated and new certificates issued. • Revocation request: when authorized person advises need for certificate revocation, e.g. private key compromise, affiliation change, name change. • Cross certification: when two CAs exchange information used in establishing a cross-certificate, issued by one CA to another CA that contains a CA signature key used for issuing certificates. The PKIX working group has defines two alternative management protocols between PKIX entities. RFC 2510 defines the certificate management protocols (CMP), which is a flexible protocol able to accommodate a variety of technical, operational, and business models. RFC 2797 defines certificate management messages over CMS (RFC 2630) called CMC. This is built on earlier work to leverage existing code.
• #35: Chapter 14 summary.