83
Cryptographic Key
Management Concepts
Ralph Spencer Poore
83.1 Cryptographic Security ... 1067
A Brief History † Cryptography and Computers †
An Encryption Standard
83.2 Key Management Myths ... 1070
Myth 1: A Key Qualifies as “Randomly Generated” If One or More Persons Create the Key Components from Their Imagination † Myth 2: An “Authorized”
Person Can Create or Enter Cryptographic Keys without Compromising a Key† Myth 3: Requiring a
Second Person to Supervise or Observe the Key Entry Process Is Dual Control † Myth 4: “Split Knowledge”
and “Dual Control” Are the Same Thing † Summary:
“Sergeant Schultz” and “Cannot”
83.3 Key Management: An Overview... 1072
Three Rules of Key Management † Automated Key
Management
83.4 Cryptographic Security Issues in Open
Networks... 1073
Issues beyond Key Exchange † Key Escrow
83.5 Advances in Cryptographic Key Management... 1075
A Plethora of Key Management Techniques †
Quantum Cryptography
83.6 Summary ... 1077
83.1 Cryptographic Security
83.1.1 A Brief History
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 for 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. There are examples of simple alphabetic substitution ciphers dating back to the time of Julius Caesar. Julius Caesar is honored today by our naming an entire class of mono-alphabetic substitution ciphers after him. The following (translated into our modern alphabet) is an example of a cipher he is believed to have used:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z D E F G H I J K L M N O P Q R S T U V W X Y Z A B C
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 underneath from the second alphabet, one can generate the ciphertext. By finding each letter of the ciphertext in the lower alphabet and substituting the letter directly above it, one can translate the ciphertext back to its plaintext. In general, one refers to any rotation of an alphabet as a Caesar alphabet.
An improvement on the Caesar alphabet is the keyed mono-alphabetic substitution cipher. It uses a key word or phrase as follows:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z S H A Z M B C D E F G I J K L N O P Q R T U V W X Y
where “SHAZAM” is the key word from which any duplicate letters (in this case the second “A”) are removed, giving “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” in order to create the keyed cipher alphabet. 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 mono-alphabetic substitutions, however, are easily solved if enough ciphertext is available for frequency analysis and trial-and-error substitutions. Mono-alphabetic ciphers today are relegated to the entertain-ment section of the newspaper and no longer serve as protectors of secrecy.
Poly-alphabetic systems, however, still pose a challenge. In these systems, each letter comes from a cipher alphabet different from the previously enciphered letter. As shown in Exhibit 83.1, for example, a
EXHIBIT 83.1 Rotating Among Four Cipher Alphabets
1 2 3 4 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
system rotating among four cipher alphabets would mean that each possible plaintext letter could be represented by any of four different ciphertext letters.
The cipher alphabets are labeled 1, 2, 3, and 4, respectively. Notice that the plaintext letter “A” can be represented by “H,” “B,” “J,” or “K.” The use of multiple alphabets complicates frequency analysis. On short messages such as “LAUNCH MISSILE NOW,” the resulting ciphertext, “DBCMZC 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, one needed the wheels, their respective order and starting positions, and the algorithm by which they were advanced.
83.1.2 Cryptography and Computers
With the advent of computers, cryptography really came of age. Computers could quickly execute complex algorithms and convert plaintext to ciphertext (encrypt) and ciphertext back to plaintext (decrypt) rapidly. Up 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), the algorithm for which is known as the Data Encryption Algorithm (DEA) as codified in American National Standard X3.92.
83.1.3 An Encryption Standard
For dependable commercial use, secret or proprietary cryptographic algorithms are problematic. Secret/proprietary algorithms are, by definition, not interoperable. Each requires its own implemen-tation, forcing companies into multiple, bilateral relationships and preventing 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 (i.e., proves that it has no 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 a foreign intelligence service certified to a U.S. firm that a secret algorithm was very strong and should be used to protect all of the firm’s trade secrets, would the U.S. firm be wise in trusting the algorithm? Such an agency might have the expertise, but can one trust any organization with a vested interest in intelligence gathering to tell you 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 entitled Elements of Cryptanalysis) attempt to break new algorithms. When an algorithm is available to a large population of cryptographic experts (i.e., when it is made public), weaknesses, if any, are more likely to be found and published. With secret algorithms, weaknesses found are more likely to remain secret and secretly exploited. However, a secret algorithm is not without merit. If you know the algorithm, analysis of the algorithm and brute-force attacks using the algorithm are easier. Also, a standard algorithm in widespread use will attract cryptanalysis. This is one of the reasons why DES is now obsolete and a new standard (the Advanced Encryption Standard [AES]) was created. In issues of national security, secret algorithms remain appropriate.
A publicly available algorithm is not the same as an algorithm codified in a standard. One might find the source code or mathematical description of an algorithm in a published book or on the Internet. Some algorithms (e.g., IDEATM’ [International Data Encryption Algorithm] invented in 1991 by James Massey and Xuejia Lai of ETH Zurich in Switzerland) used in PGP (Pretty Good Privacy authored by Phil Zimmermann) to package a public key cryptographic algorithm, may prove to be quite strong, while others thought to be strong (e.g., FEAL [Fast Encryption Algorithm invented by Akihiro Shimizu and Shoji Miyaguchi of NTT Japan]) 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 DEA is a symmetric algorithm (as is the algorithm used for AES1). If the key used to decrypt is not the same as the key used to encrypt, the algorithm is asymmetric. Public key algorithms (e.g., the RSA 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,2but always have at least one “private” key. The “private” key must remain secret.
83.2 Key Management Myths
Cryptographic security using a standard, publicly available algorithm (e.g., the Federal Information Processing Standard (FIPS) 197, Advanced Encryption Standard) 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. This author’s experience in evaluating implementations has revealed some common misunder-standings about managing cryptographic keys. This chapter identifies these misundermisunder-standings (referred to as “myths”), explains why they are wrong, and describes correct procedures. The examples used are taken from experience with automated teller machine (ATM) and point-of-sale (POS) implementations that depended on DEA (and now depend on Triple DES,3a backward-compatible implementation that allows for longer effective key lengths through multiple applications of DEA) for personal identification number (PIN) privacy. The concepts, however, apply to most implementations of cryptography where 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.
83.2.1 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 cannot make up numbers that will meet this requirement. Concatenating the non-random 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 containing a pattern they recognize. This is but one simple example of how people bias their selections.
If a person wants to create a random hexadecimal number, that person could number identical balls from 0 through 9 and A through F; place them in a large bowl; mix them; select and remove (without looking) a ball; record its value; place the ball back into the bowl; and repeat the process 16 times for each key component. Another alternative is to use 64 coins of equal size (e.g., all pennies); toss them on to a
1AES uses the Rijndael algorithm; refer to FIPS 157 for details.
2While not widely used, public key systems exist that require “n” of “m” keys to encrypt or decrypt. Depending on the
purpose of the cryptography (e.g., confidentiality or authentication), the multiple keys might be the public ones or the private ones (or both).
flat surface; and using a large straightedge (e.g., a yardstick), sweep them into a straight line. Starting from the left, record a “1” for each head and a “0” for each tail. The 64 bits can them 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. (You will see documentation refer to “pseudo random” numbers. These are numbers generated by a repeatable, algorithmic process but exhibit properties ascribed to randomly generated numbers. I refer to these as ersatz random numbers here because “pseudo” means “false” [so even a sequence that did not meet statistical requirements for randomness would meet this definition] where “ersatz” means “imitation or artificial” and more accurately describes the nature of these numbers. However, the term “pseudo random” is well established. A newer term—“deterministic random bit generators”—has also entered the literature, a term that better addresses this author’s linguistic concerns.)4
83.2.2 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 (by definition). This is why “split knowledge” controls are required. No human should ever know an active key.
Allowing a person to know an active key places the person at risk (e.g., extortion), places the organization at risk (e.g., potential misuse or disclosure by that person), and creates the potential for accidental disclosure of the key through human error.
83.2.3 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 essential steps to happen without the need for at least one additional person, then dual control is not achieved. Because observation and supervision are passive activities, the absence of which would not prevent the process, a person acting in such capacities is not acting as part of a dual control process.
If party “A” has the combination to the vault within an ATM and party “B” has the key to the ATM’s locked door such that both parties “A” and “B” must participate in order to gain access to the cryptographic device within the ATM, then dual control exists. However, if party “B” learns the combination or party “A” gains access to the ATM’s door key, then dual control ceases to exist.
83.2.4 Myth 4: “Split Knowledge” and “Dual Control” Are the Same Thing
The concept of “split knowledge” as used in cryptography means that two or more parties are needed, each with independent knowledge of a cryptographic key component, such that together they can 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” can ever see the Team “B” key components, and vice versa. One member of each team is then needed to load a key.
Note that the use of key halves (once 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.
4For a more in-depth discussion of a pseudo random number generator (PRNG), refer to ANS X9.82 (Random Number
Generation) or NIST Special Publication 800-22 (A Statistical Test Suite for the Validation of Random Number Generators and Pseudo Random Number Generators for Cryptographic Applications).
83.2.5 Summary: “Sergeant Schultz” and “Cannot”
I call the split knowledge requirement the “Sergeant Schultz principle,” from the Hogan’s Heroes television program where Sergeant Schultz would say, “I know nothing, nothing!” Properly implemented, every key component holder should always be able to affirm that they know nothing about the resulting live key.
This author’s 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, then dual control exists. If any one person can accomplish all of the steps without anyone else, then dual control does not exist.
These are two easily remembered principles that are essential to effective key management.
83.3 Key Management: An Overview
Whether or not an algorithm is kept secret, the cryptographic key or keys needed to decipher a message must remain secret if we want to keep the communication private. Knowing the keys and any plaintext encrypted under those keys makes discernment of even a secret algorithm likely. Knowing 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.
83.3.1 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. Benjamin Franklin wrote that “three can keep a secret if two of them are dead.”5In cryptography, one might recast this as “three can keep a secret if all of them are dead.”
Second, whenever keys must be distributed and entered manually, one uses full-length key components to facilitate split knowledge. By requiring that two (or more) full-length key components be entered, each by a separate individual who never sees any other component, one can keep any one person from knowing the resulting key. This technique, known as “split knowledge,” is actually a zero knowledge process for each individual. Each key component (CnK, where nZ1, 2, .) conveys by itself no knowledge of the ultimate key. This is accomplished by implementing a function 4 such that C1K4C2K 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 DEA, TDES, or AES with C1K as the data and C2K as the key is another example.
Third, use keys only for a single purpose. If a key was intended to protect other keys, never use it to protect non-key data. If the key was intended to authenticate messages, do not use it 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.
83.3.2 Automated Key Management
Systems of key generation do exist that require no human intervention or initial manual key distribution. Because some of these systems use proprietary approaches to key management, the buyer should exercise great care. For example, a vendor might 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 (modulo 2 addition without carry) the result to the cleartext, 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. Exhibit 83.2 shows an example of how this might happen.
Many different automated schemes for key exchange exist—and 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 to you, proving its security may require a cryptanalyst’s expertise. So when a vendor describes what appears to be magic, remember that even David Copperfield relies on illusion. Best practice is to require compliance with a recognized standard for example, ANS X9.42-2003 (Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography) or ANS X9.63-2001 (Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Management Using Elliptic Curve Cryptography).
83.4 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
Alice Intended path Bob Active interloper Actual path Actual path
because arbitrary parties will not have preexisting keying relationships. Two different approaches have evolved to answer the challenge: (1) the use of a hierarchy of trusted agents and (2) the use of key-exchange protocols. In one implementation of a hierarchy of trusted agents, we refer to an agent as a certificate authority (CA) because the agent issues a cryptographic certificate that binds a key representing one party to a chain of certificates from other CAs until a CA common to the parties who wish to securely communicate is reached. For example, Edward of Pan Omni Mega Corp. (POMC) wishes to send a secure message to Darwin of Central Middle Obaeratus 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 United States 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 access to CA locations is limited, then Edward may have a long wait. But manual key distribution would usually force a longer wait.
If both Edward and Darwin have cryptographic facilities supporting 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, one 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. We trust properly vetted algorithms or protocols; otherwise, caveat emptor!) Best practice is to use standardized techniques whenever feasible, for example, ANS X9.24-2004 (Retail Financial Services, Symmetric Key Management, Part 1: Using Symmetric Techniques), ANS X9.42-2003 (Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography), ANS X9.44 (Key Agreement and Key Transport using Factoring Based Cryptography), and ANS X9.63 (Key Agreement and Key Transport using Elliptic Curve Cryptography [ECC]).
83.4.1 Issues beyond Key Exchange
Properly implemented, cryptographic security measures work. As a consequence of their effectiveness, governments have attempted to regulate their use and to control their availability. The United States historically took a two-pronged approach: restricted export and key escrow. Political pressure, however, led the United States to ease the export restrictions and, effectively, to abandon the key escrow approach. The U.S. Government treats cryptographic security implementations as if they were war munitions. However, not all nations have adopted this approach. Companies should have their legal counsels carefully examine the laws associated with encryption technology in each jurisdiction in which they plan its use.
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 keyspaces of 40 bits (i.e., having 240possible keys) or less is not a problem for the United States. Because of advances in computational power (i.e., Moore’s law),
even systems with much larger keyspaces (e.g., 60 bits) seem to pose no export problem. One of the selection criteria used in the development of an algorithm for the AES was that a 128-bit version would exist that would be exportable. Where very strong encryption is desired (e.g., O128 bits for a symmetric key), some authorities may permit it only if key escrow is used.
83.4.2 Key Escrow
Key escrow is a process through which you entrust your cryptographic keys to a third party who holds them securely until and unless forced to disclose them by legal process (e.g., a court order). This process is most controversial when that escrow agent is one or more elements of a national government. Key escrow has two serious types of errors: (1) Type I error, in which the key is disclosed without authorization; and (2) Type II error, in which the key becomes unavailable (corrupted, destroyed, 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 (and may place the company in jeopardy of legal action). Because zeroization6of 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. One is not permitted to prevent a Type I failure by causing a Type II failure; nor is one permitted to protect against a Type II failure by increasing the risk of a Type I failure. In a project directed by Dr. Miles Smid, the National Institute of Standards and Technology (NIST) developed protocols for handling key escrow within the constraints of this delicate balance. For additional information, see FIPS 185 (Escrowed Encryption Standard).
In the United States, key escrow receives less attention today in the context of key management for export considerations than it does for business continuity planning where it remains an important technology.7
83.5 Advances in Cryptographic Key Management
The field of cryptography is experiencing rapid advancement. While many of the advances are more theoretical than currently useful, the auditor and security practitioner should have at least a rudimentary understanding of what is likely in the near future. Several key management techniques that are already technically available (or “bleeding edge”), but where standards may not have caught up, include:
† Diffie-Hellman key exchange using polynomials of base p (where ps2)8 † Elliptic Curve Menezes-Qu-Vanstone (ECMQV)9
† Efficient Probabilistic Public-Key Encryption (EPOC) and a variant EPOC-310
For use further into the future, one of the most promising advances is with quantum cryptography.
83.5.1 A Plethora of Key Management Techniques
With rapid advances in mathematics, almost every conceivable hard problem is potentially a cryptographic algorithm or basis for key agreement or transport. In general, if it is feasible (and preferably efficient and easy) to calculate a value from known values in one direction but extremely
6“Zeroization” is the technical term for destroying the keys by causing the storage medium to reset to all zeroes. 7See also Menezes, Alfred J., Paul C. van Oorschot, and Scott A. Vanstone. Handbook of Applied Cryptography. CRC Press,
Boca Raton, FL, 1997. Chapter 13, especially §13.8.3. The Handbook (affectionately known as the “HAC”) is an excellent— although much more technical and mathematical treatment—of cryptography.
8Rosing, Michael. 1999. Implementing Elliptic Curve Cryptography. p.299. Manning Publishing Co., Greenwich, CT. 9IEEE 1363–2000.
10Tatsuaki Okamoto and David Pointcheval. NTT Labs, Japan; paper submitted to IEEE P1363a Working Group,
difficult (and preferably computationally infeasible) to work backward from the result without the benefit of secret values (i.e., cryptographic keys), there is the potential for a cryptosystem. One other promising area is the use of hyperelliptic curves. While these are no more hyperelliptic in the geometry sense than elliptic curves are ellipses, they form a class of mathematical curves, an example of which is described by the following formula:
y2Z xmCaxmK1C. Cz
where m is assumed to be odd and greater than 3.11
However, the road from theory to practical implementation is a rough one. Some protocols have jumped prematurely to an implementation that was not secure. For example, the widely used Wired Equivalent Privacy (WEP)12protocol was found to contain exploitable flaws.13The ECMQV protocol may also have exploitable weaknesses under special circumstances. At the time of this writing, the practical implications of those weaknesses are unclear. Best practice will always be to follow well-vetted standards and to keep up with the literature as we practice a rapidly evolving field.
83.5.2 Quantum Cryptography
Quantum cryptography is a key agreement method for establishing a shared secret. It assumes that two users have a common communication channel over which they can send polarized photons. Photons can be polarized vertically or horizontally, circularly (clockwise or counterclockwise), or diagonally. Each of these can be viewed as having two states and assigned a binary representation (i.e., 0 or 1). By randomly choosing which measurement will be made for each pulse, two independent observers can compare observations and, following an interactive protocol, can agree on a resulting bit string without ever transmitting that string. Quantum cryptography has an advantage over traditional key exchange methods because it is based on the laws of physics instead of assumptions about the intractability of certain mathematical problems. The laws of physics guarantee (probabilistically) that the secret key exchange will be secure, even when assuming hypothetical eavesdroppers with unlimited computing power. However, a clear, practical disadvantage is the necessity of a communication channel over which the parties can send polarized photons.
Stephen Weisner is credited with the initial proposal14(circa 1970) on which quantum cryptography is based. He called it “Conjugate Coding,” and eventually published it in 1983 in Sigact News. Charles H. Bennett and Gilles Brassard,15 who were familiar with Weisner’s ideas, published their own ideas shortly thereafter. They produced the first quantum cryptography protocol in 1984, which they named BB84.16It was not until 1991, however, that the first experimental prototype based on this protocol was made operable (over a distance of 32 centimeters). An online demonstration of this protocol is available at http://monet.mercersburg.edu/henle/bb84/. More recently, systems have been tested successfully on fiber optic cable over distances in the kilometers range.17
11Rosing, Michael. 1999. Implementing Elliptic Curve Cryptography. pp. 299–300. Manning Publishing Co., Greenwich,
CT.
12IEEE 802.11 (including 802.11b).
13For more information on this weakness, refer to work performed jointly by Nikita Borisov, Ian Goldberg, and David
Wagner described at the following Berkeley Web site: http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html.
14Weisner, Stephen. 1983. “Conjugate Coding,” Sigact News, Vol. 15. No. 1, pp. 78–88, manuscript written circa 1970, but
remained unpublished until it appeared in Sigact News.
15Bennett, Charles H. and Brassard, G. 1984. “Quantum Cryptography: Public Key Distribution and Coin Tossing,”
International Conference on Computers, Systems & Signal Processing, December 10–12, pp. 175–179. Bangalore, India.
16Bennett, Charles H., Bessette, F., Brassard, G., Salvail, L., and Smolin, J. 1992. Experimental quantum cryptography.
Journal of Cryptology, Vol. 5, 3–28.
17Stucky, Damien, Gisin, N., Guinnard, O., Ribordy, G., and Zbinden, H. 2002. Quantum key distribution over 67 km
While this scheme may eventually replace more traditional methods (e.g., Diffie-Hellman) and has excellent potential in outer space where point-to-point laser might be feasible for long distances, current implementations impose both speed and distance limits (under 100 kilometers as of this writing) and expense that will make commercial implementations an issue for the future generation of information security professionals.18
83.6 Summary
Cryptology, which embraces both the creation of cipher systems (cryptography) and the breaking of those systems (cryptanalysis), has a long history. While this history is one of secrecy and intrigue and one of centuries of evolution, it was a history of little practical interest to business until only the past three decades. With the explosive proliferation of computers and networks, both cryptography and cryptanalysis have come to center stage. Our open network environments present security problems only cryptography can solve. As cryptography becomes universal, so will cryptanalysis. John Herbert Dillinger is alleged to have answered when asked why he robbed banks: “Because that’s where the money is.” The information security professional who knows little of cryptography will know little of security, for user authentication and access control, privacy protection and message integrity, audit trail assurance and non-repudiation, and automatic records retention will all depend on elements of cryptography. Understanding cryptographic key management and cryptographic implementations will permit us to manage securely the information assets of our enterprises.
18For a very readable, technical explanation of quantum cryptography, see Gisin, Nicolas, G. Ribordy, W. Tittel, and