Cryptographic Key Management Concepts Ralph Spencer Poore Payoff

Transcription

1 Cryptographic Key Management Concepts Ralph Spencer Poore Payoff Cryptology, which embraces both the creation of cipher systems (i.e., cryptography)and the breaking of those systems (i.e., cryptanalysis), has a long history. However, until the last two decades, it held little practical interest for business. Today's proliferation of computers and networks has brought cryptography and cryptanalysis to center stage, because open network environments present security problems that only cryptography can solve. This article provides a broad overview of cryptography and key management principles that will aid IS security professionals to manage and protect information assets. Introduction Cryptography, the art of secret writing, has existed for almost as long as writing itself. Originally, the use of symbols to represent letters or words in phrases was a skill reserved to the scribes or learned clerics. However, for a scribe's work to be truly useful, others needed the ability to read the scribe's work. As standardized writing and reading skills became more widespread, the risk of unauthorized reading increased. Primarily for purposes of political intrigue and military secrecy, practical applications of secret writing evolved. Examples of simple alphabetic substitution ciphers date back to the time of Julius Caesar. Caesar is honored today by the naming of an entire class of monoalphabetic substitution ciphers after him. Exhibit 1, translated into the modern alphabet, is a representation of a cipher Julius Caesar is believed to have used. Caesar Alphabet ABCDEFGHIJKLMNOPQRSTUVWXYZ DEFGHIJKLMNOPQRSTUVWXYZABC ABCDEFGHIJKLMNOPQRSTUVWXYZ DEFGHIJKLMNOPQRSTUVWXYZABC The rotation of the alphabet by three places is enough to transform a simple plaintext message from we attack to the north at dawn into ZH DWWDFN WR WKH QRUWK DW GDZQ. By finding each letter of plaintext in the first alphabet and substituting the letter from the second alphabet, a ciphertext is generated. By finding each letter of the ciphertext in the lower alphabet and substituting the letter directly above it, the ciphertext is translated back into its plaintext. In general, any rotation of an alphabet is referred to as a Caesar alphabet. An improvement on the Caesar alphabet is the keyed monoalphabetic substitution cipher. Exhibit 2 illustrates the use of a key word or phrase. In this example, SHAZAM is the key word from which any duplicate letters (in this case the second A ) are removed, yielding SHAZM. The key word is then used for the first letters of the cipher alphabet with the unused letters following in order. The recipient of a coded message only needs to know the word SHAZAM to create the keyed cipher alphabet. Monoalphabetic Substitution Cipher

2 ABCDEFGHIJKLMNOPQRSTUVWXYZ SHAZMBCDEFGIJKLNOPQRTUVWXY ABCDEFGHIJKLMNOPQRSTUVWXYZ SHAZMBCDEFGIJKLNOPQRTUVWXY A further improvement, but one that requires the entire cipher alphabet to act as the key, is the use of a randomly generated cipher alphabet. All such monoalphabetic substitutions, however, are easily solved if enough ciphertext is available for frequency analysis and trialand-error substitutions. Monoalphabetic ciphers today are relegated to the entertainment section of the newspaper and no longer serve as protectors of secrecy. Polyalphabetic systems, however, still pose a challenge. In these systems, each letter comes from a cipher alphabet different from the previously enciphered letter. For example, a system rotating among four cipher alphabets would mean that each possible plaintext letter could be represented by any of four different ciphertext letters. Exhibit 3 provides an illustration. The cipher alphabets are labeled 1, 2, 3, and 4 respectively. The plaintext letter A could be represented by H, B, J, or K. The use of multiple alphabets complicates frequency analysis. On short messages, for example LAUNCH MISSILE NOW, the resulting ciphertext, DBCNZC LEYHDHL VXN, contains no matching letters that have the same plaintext meaning. The letter D, for example, is in the ciphertext twice, but the first time it decodes to the letter L, and the second time it decodes to the letter I. Similarly, the letter C decodes first to the letter U and then to the letter H. Very difficult ciphers used in World War II (e.g., ENIGMA) relied on more complex variations of this class of ciphers. They used multiple wheels where each wheel was a cipher alphabet. The wheels would advance some distance after each use. To decode, the wheels were needed, as well as their respective order and starting positions and the algorithm by which they were advanced. Polyalphabetic Cipher A H B J K B T I E A C Z D V T D X M O G E L X N O F P Q R S G V U T W H A C Z Y I B G D E J F E A U K W Y B C L D F G H M J K L R N S V Q M O N R X Z P R P M F Q K I Y X R C A W D S Y H U L T O Q S I U E L C B

3 V T N F J W M O I N X I S H P Y G J K Q Z Q T P V A H B J K B T I E A C Z D V T D X M O G E L X N O F P Q R S G V U T W H A C Z Y I B G D E J F E A U K W Y B C L D F G H M J K L R N S V Q M O N R X Z P R P M F Q K I Y X R C A W D S Y H U L T O Q S I U E L C B V T N F J W M O I N X I S H P Y G J K Q Z Q T P V Cryptography and Computers With the advent of computers, cryptography came of age. Computers could quickly execute complex algorithms and convert plaintext to ciphertext(i.e., encrypt) and ciphertext back to plaintext (i.e., decrypt) rapidly. Until the 1960s, however, cryptography was almost exclusively the property of governments. A prototype for commercial applications, IBM's Lucifer system was a hardware implementation of a 128-bit key system. This system became the basis for the Data Encryption Standard(DES), a 64-bit key system (8-bits of which were for parity leaving an effective key length of 56 bits), also known as the Data encryption algorithm (DEA) as codified in American National Standard X3.92. An Encryption Standard For dependable commercial use, secret or proprietary cryptographic algorithms are problematic. Secret or proprietary algorithms are, by definition, not interoperable. Each requires its own implementation, forcing companies into multiple, bilateral relationships that prevent vendors from obtaining economies of scale. As a practical matter, cryptographic security was cost-prohibitive for business use until DEA. With a standard algorithm, interoperability became feasible. High-quality cryptographic security became commercially viable. Auditors and security professionals should also understand two other important problems with secret algorithms. First, who vets the algorithm, or proves that it has no

4 weaknesses or trapdoors that permit solving of the encrypted text without the cryptographic key? This is both an issue of trust and an issue of competence. If the cryptographic section of the KGB certified to a US firm that a secret algorithm was very strong and should be used to protect all of the firm's trade secrets, would the US firm be wise in trusting the algorithm? The KGB certainly has the expertise, but could anyone trust an organization with a vested interest in intelligence-gathering to tell if a security weakness existed in the algorithm? Vetting cryptographic algorithms is not an exact science. Cryptographers design and cryptanalysts (first coined by W. F. Friedman in 1920 in his book Elements of Cryptanalysis) attempt to break new algorithms. When an algorithm is available to a large population of cryptographic experts (e.g., when it is made public), weaknesses, if any, are more likely to be found and published. With secret algorithms, weaknesses that are found are more likely to remain secret and secretly exploited. However, a secret algorithm is not without merit. If the algorithm is known, analysis of the algorithm and brute force attacks that use the algorithm are easier. In addition, a standard algorithm in widespread use will attract cryptanalysis. In issues of national security, secret algorithms remain appropriate. A publicly available algorithm is not the same as an algorithm codified in a standard. The source code or mathematical description of an algorithm may be found in a published book or on the Internet. Some algorithms, such as IDEA (International Data Encryption Algorithm)which is used in Pretty Good Privacy (PGP)to package a public key cryptographic algorithm, may prove to be quite strong, and others thought to be strong, such as Fast encryption algorithm (FEAL), may prove breakable. When an algorithm is publicly available, security rests solely with the secrecy of the cryptographic keys. This is true both in symmetric and asymmetric algorithms. Algorithms using the same key to decrypt as was used to encrypt are known as symmetric algorithms. The Data Encryption Algorithm (DEA) is a symmetric algorithm. If the key used to decrypt is not the same as the key used to encrypt, the algorithm is asymmetric. Public key algorithms, such as the Rivest_Shamir-Adleman Data Security algorithm, are asymmetric. Symmetric algorithms are sometimes called secret key algorithms, because the one key used for both encryption and decryption must remain secret. Asymmetric algorithms may have one or more public keys, but always have at least one private key. The private key must remain secret. Key Management Myths Cryptographic security that uses a standard, publicly available algorithm, such as the ANS X3.92 Data encryption algorithm (DEA), depends on the secrecy of the cryptographic key. Even with secret algorithms that use keys, the secrecy of at least one key (e.g., the private key used in public key cryptography) remains critical to the security of the cryptographic process. There are many common misunderstandings about managing cryptographic keys. These misunderstandings may be thought of as myths, and the following sections explain why they are wrong and describe correct procedures. The examples used discuss automated teller machine (ATM) and point-of-sale (POS) implementations that depend on DEA for personal identification number (PIN) privacy. The concepts, however, apply to most implementations of cryptography in which the objective is either message privacy or integrity. Some implementations may rely on fully automated key management processes. Even these may not be immune to key management fallacies.

5 Myth 1: A Key Qualifies as Randomly Generated if One or More Persons Create the Key Components from Their Imagination To meet the statistical test for randomly generated, each possible key in the key space must be equally likely. No matter how hard a person tries, he or she cannot make up numbers that will meet this requirement. Concatenating the nonrandom number choices of several persons does not result in a random number either. When people are asked to select a number at random, they automatically attempt to avoid a number that contains a pattern that they recognize. This is only one simple example of how people bias their selections. If a person wishes to create a random hexadecimal number, the person could number identical balls from 0 through 9 and A through F; place them in a large bowl; mix them; and select and remove a ball without looking. The person then records its value and places the ball back into the bowl. The process is repeated 16 times for each key component. Another alternative is the use of 64 coins of equal size (e.g., all pennies) and to toss them on to a flat surface. Then, by using a large straightedge (e.g., a yardstick), they are swept into a straight line. Starting from the left, the person records a 1 for each head and a 0 for each tail. The 64 bits can then be translated in blocks of four to form a 16, hexadecimal-character key. Most organizations, however, will simply have their cryptographic device generate an ersatz random number. It is common to see documentation refer to pseudo random numbers. These are numbers generated by a repeatable, algorithmic process but that exhibit properties ascribed to randomly generated numbers. These are referred to as ersatz random numbers here because pseudo means false, so that even a sequence that did not meet statistical requirements for randomness would meet the definition for pseudo. Ersatz means imitation : or artificial, and it more accurately describes the nature of these numbers. However, the term, pseudo random is well established, any linguistic concerns notwithstanding. Myth 2: An Authorized Person Can Create or Enter Cryptographic Keys Without Compromising a Key When a cryptographic key becomes known to anyone, it is compromised. For this reason, split knowledge controls are required. No individual should ever know an active key. To allow a person to know an active key places that person at risk (e.g., of extortion), places the organization at risk (e.g., for potential misuse or disclosure by that person), and creates the potential for accidental disclosure of the key through human error. Myth 3: Requiring a Second Person to Supervise or Observe the Key Entry Process Is Dual Control To qualify as a dual control process, it must be infeasible for any one person to perform the entire process alone. If one person can cause all of the essential steps to happen without the need for at least one additional person, dual control is not achieved. Because observation and supervision are passive activities, the absence of these would not prevent the process. If party A has the combination to the vault within an Asynchronous Transfer Mode and party B has the key to the ATM's locked door such that both parties must participate to gain access to the cryptographic device within the ATM, dual control exists. However, if party B learns the combination or party A gains access to the ATM's door key, dual control does not exist.

6 Myth 4: Split Knowledge and Dual Control Are Synonymous The concept of split knowledge means that two or more parties, each with independent knowledge of a cryptographic key component, are required jointly to create a cryptographic key of which each has no knowledge. Split knowledge meets the requirements for dual control, but not vice versa. The usual way of doing this is to create two teams of key entry persons. Team A will generate a full-length key component and record it. Team B will do the same. No member of Team A may ever see the Team B key components and vice versa. One member of each team is then needed to load a key. The use of key halves, which is common in the ATM/POS industry, does not qualify as split knowledge, because each person has knowledge of at least half of the actual key. True split knowledge requires that no one have any knowledge of the resulting key. The split knowledge requirement might be called the Sergeant Schultz principle from the Hogan's Heroes television program, in which Sergeant Schultz would say I know nothing, nothing!. Properly implemented, each key component holder should always be able to affirm that they know nothing about the resulting live key. An equally short name for dual control is the cannot principle. If one person cannot perform a function because the function can only be accomplished with the collective efforts of two or more persons, dual control exists. If any one person can accomplish all of the steps without anyone else, dual control does not exist. These two principles are essential to effective key management. An Overview of Key Management Whether an algorithm is kept secret or not, the cryptographic key or keys needed to decipher a message must remain secret to keep the communication private. Knowledge of the keys and any plaintext encrypted under those keys makes discernment of even a secret algorithm likely. Further, knowledge of the keys and the algorithm makes decryption of messages encrypted under those keys straightforward. The objective of key management is to prevent unauthorized disclosure of keying materials. When key management fails, cryptographic security fails. Three Rules of Key Management Three rules of key management must be followed if cryptographic keys are to remain secret. First, no human being should ever have access to active, cleartext keys. The old saw that two can keep a secret if one of them is dead could be recast for cryptography as two can keep a secret if both of them are dead. Second, whenever keys must be distributed and entered manually, only full-length key components should be used to facilitate split knowledge. Requiring that two (or more) full-length key components be entered, each by a separate individual who never sees any other component, can keep any one person from knowing the resulting key. The technique, known as split knowledge, is actually a zero knowledge process for each individual. Each key component (CnK, where n=1,2,...) conveys by itself no knowledge of the ultimate key. This is accomplished by implementing a function, such that C1K C2K results in a key dependent on every bit in both components. modulo 2 arithmetic without carry (or logical exclusive OR) is one example of such a function. Using the DEA itself with C1K as the data and C2K as the key is another example. Third, keys should be used only for a single purpose. If a key was intended to protect other keys, it should never be used to protect nonkey data. If the key was intended to authenticate messages, it should not be used to encrypt a message. Using the same key for more than one purpose may give a cryptanalyst a better opportunity to solve for the key. More significantly, it makes a key compromise more painful and less easily investigated when the key was used for multiple purposes.

7 Automated Key Management Systems of key generation do exist that require no human intervention or initial manual key distribution. Because such systems use proprietary approaches to key management, the buyer should exercise care. For example, a vendor may deliver each device with a fixed private key of a public key/private key pair. Each device would transmit its public key, resulting in an exchange of public keys. Each device could then encrypt a random value under the other party's public key and transmit this cryptogram of the random value. The receiving device could then decrypt the cryptogram using its private key and add (i.e., Modulo 2 addition without carry) the result to the cleartext, a randomly chosen value it had encrypted and sent, thereby creating a unique session key between the two devices. However, an interloper could intercept both public keys and spoof both sides by substituting public keys for which the interloper knew the private keys. Many different automated schemes for key exchange exist: some are known to be secure, some are probably secure, some are probably not secure, and some are not secure. Because many of the techniques are proprietary (i.e., trade secrets), evaluating them is difficult. Even when a vendor has patented a technique and is willing to fully disclose it, proving its security may require a cryptanalyst's expertise. Therefore, if a vendor describes what appears to be magic, remember that even David Copperfield relies on illusion. Cryptographic Security Issues In Open Networks The underlying assumption to open networks is the ability to establish arbitrary connections without previously having established a relationship. This poses a challenge for cryptographic key management, because arbitrary parties will not have preexisting keying relationships. Two different approaches have evolved to answer the challenge: the use of a hierarchy of trusted agents, and the use of key-exchange protocols. In one implementation of an hierarchy of trusted agents, an agent is referred to as a certificate authority (CA). This agent issues a cryptographic certificate that binds a key that represents one party to a chain of certificates from other CAs until a CA common to the parties that wish to communicate securely is reached. For example, Edward of Pan Omni Mega Corp. (POMC) wishes to send a secure message to Darwin of Central Middle Obcordate Partners (CMOP);however, Edward and Darwin have never before communicated. POMC subscribes to AT&T's Certificate Authority (ATT CA). CMOP subscribes to General Services Certificate Authority (GS CA) that, in turn, subscribes to MCI's Certificate Authority (MCI CA). AT&T and MCI have mutual keying relationships with the US Postal Service Certificate Authority (USPS CA). POMC's CA chain becomes POMC/ATT/USPS and CMOP's becomes CMOP/GS/MCI/USPS. By exchanging authenticated certificates of authority, POMC can establish a trusted keying relationship with CMOP without worrying about key substitution. If the chains are long, if transmission speed is slow, or if access to CA locations is limited, Edward may have a long wait. However, it will not be as long of a wait as a manual key distribution would force. If both Edward and Darwin have cryptographic facilities that support a common key exchange protocol, they may be able to establish, directly and securely, a cryptographic session key. As described in the previous section, however, a potential user may be unable to vet the vendor's techniques. (The term vet as used in cryptography means to investigate, examine, evaluate, or prove in a thorough or expert way. An enterprise should rely only on properly vetted algorithms or protocols; otherwise caveat emptor.) Issues Beyond Key Exchange Properly implemented, cryptographic security measures work. As a consequence of their effectiveness, governments have chosen to regulate their use and to attempt to control their availability. The US has taken a two-pronged approach: restricted export and key

8 escrow. The government treats cryptographic security implementations as if they were war munitions. Proliferation of strong cryptography may interfere with a government's intelligence operations. As long as the US can acquire and analyze the plans of other governments, the US can avoid(at least in theory) being caught unaware of hostile intentions. Although export controls over cryptography remain controversial, they are likely to remain in one form or another. Import controls reflect a nation's concern for its own exercise of sovereignty. Do secret messages contain government secrets? Do secret messages hide unlawful transactions? Are people evading taxes by electronic smuggling of software?import controls will remain an issue for many nations. For both import and export, governments generally base their restrictions on how effective the cryptography (including key management) is. Cryptographic effectiveness has at least three major components: The size of the cryptographic key space (i.e., how many possible keys there are). Whether the algorithm permits shortcuts in solving for the key. Whether the key management functions introduce weaknesses. (e.g., an early release of Netscape relied on a key generation process that was weaker than the resulting key space, making it possible to attack the key generation process to gain the key much faster than by attacking the key space.) Exporting cryptographic systems based on key spaces of 40-bits (i.e., those having 240 possible keys) or less no longer seems to be a problem for the US. However, to export more robust systems, the United States wants the parties to use key escrow. Key escrow is a process through which the cryptographic keys are entrusted to a third party who holds them securely until and unless forced to disclose them by a court order. This process is most controversial when that escrow agent is one or more elements of the government. Key escrow has two serious types of errors. The Type I error is if the key is disclosed without authorization. The Type II error is if the key becomes unavailable (i.e., corrupted, destroyed, or inaccessible) and cannot be disclosed when lawfully demanded. A Type I compromise places the information assets at risk. A Type II compromise places law enforcement at risk. Because zeroization of keys is a countermeasure used to prevent Type I failures (i.e., any attempt to tamper with the cryptographic equipment causes the keys to be set to zeroes), and because having backup copies of keying materials is a countermeasure for Type II failures, preventing both Type I and II failures is a difficult balancing act. It is not permitted to prevent a Type I failure by causing a Type II failure. Nor is it permitted to protect against a Type II failure by increasing the risk of a Type I failure. The National Institute of Standards and Technology (NIST),in a project directed by Dr. Miles Smid, developed protocols for handling key escrow within the constraints of this delicate balance. For additional information see Federal Information Processing Standard (FIPS)185, Escrowed Encryption Standard. Conclusion As cryptography becomes universal, so will cryptanalysis. The information security professional who knows little of cryptography knows little of security, because user authentication and access control; privacy protection and message integrity; audit trail assurance and nonrepudiation; and automatic records retention all depend on elements of cryptography. Understanding cryptographic key management and cryptographic implementations permits the secure management of the information assets of enterprises.

9 Author Biographies Ralph Spencer Poore Ralph Spencer Poore is Director of Information Security Services for the Dallas office of Coopers & Lybrand. As a member of the board of directors for the International Information Systems Security Certification Consortium and Chairperson of its Test Development Committee, he actively promotes information security as a profession.