Auerbach Publications
© 1999 CRC Press LLC 06/98
DATA SECURITY MANAGEMENT
P
RINCIPLES
AND
A
PPLICATIONS
OF
K
EY
M
ANAGEMENT
William H. Murray
I N S I D E
Key Management Defined, Modern Key Management, Principles of Key Management, Asymmetric Key Cryptography, Implementations, Public Key Certificates,
Recommendations for Key Management
CONTEXT
Cryptography is the use of secret codes to hide data and to authenticate its origin and content. While public codes could be used to authenticate content, secret codes are necessary to authenticate origin. This latter use of cryptography has emerged only in the latter half of this century and has been surprising to all but a few.
Of all security mechanisms, cryptography is the one most suited to open and hostile environments, environments where control is otherwise limited, environments like the modern, open, flat, broadcast, packet-switched, heterogeneous networks.
Cryptography is broadly applicable. In the presence of cheap computing power, its uses are limited only by our imaginations. Given that most of the power of our computers goes unused, we could use secret codes by de-fault, converting to public codes only for use. Indeed, the modern distrib-uted computing systems and applications would be impossible without it.
It is portable: the necessary software to encode or decode the infor-mation can be distributed at or near
the time of use in the same package and channel. Within minor limits, it is composable. Different functions and algorithms can be put together with-out losing any strength. One can put together mechanisms to emulate any environmental or media-based con-trol.
P A Y O F F I D E A
The least appreciated of the modern cryptogra-phy inventions is automated key management. This powerful mechanism enables us to over-come the lack of rigor and discipline that leads to the inevitable compromise of crypto systems. By permitting us to change keys frequently and safe-ly, it overcomes the fundamental limitations of the algorithms that we choose. It enables us to com-pensate for such human limitations as the inability to remember or transcribe long random numbers. 83-10-50
Not only is cryptography effective, it is efficient. That is to say, it is usually the cheapest way to achieve a specified degree of protection. The cost of cryptography is low. Not only is it low in absolute terms, but also in terms of the security value that it delivers. It is low when compared to the value of the data that it protects. It is low when compared to the al-ternative ways of achieving the same degree of security by such alterna-tive means as custody, supervision, or automated access control.
The low cost of cryptography is the result, in part, of the low cost of the modern computer and is falling along with the cost of computing. The cost of a single cryptographic operation today is one ten-thousandth of what it was as recently as 20 years ago and can be expected to con-tinue to fall.
Another way of looking at it is that its relative strength is rising when cost is held constant, and the cost to the user is falling relative to the cost to the attacker. As we will see, automated key management is one mech-anism that permits us to trade the increasing power of computing for in-creased security.
Modern cryptography is arbitrarily strong; that is, it is as strong as needed. If one knows what data he wishes to protect, for how long, and from whom, then it is possible to use modern cryptography to achieve the desired protection. There are limitations; if one wanted to encrypt tens of gigabytes of data for centuries, it is hard to know how to achieve that. However, this is a theoretical rather than a practical problem. In practice, there are no such applications or problems.
Cryptography is significantly stronger than other security mechanisms and will rarely, if ever, be the weak link in the security chain. However, in practice, its strength is limited by the other links in the chain, for ex-ample, key management. As it is not efficient to make one link in a chain significantly stronger than another, so it is not necessary for cryptography to be more than a few hundred times stronger than the other mecha-nisms on which the safety of the data depends.
The cryptography component of a security solution is robust and re-silient — not likely to break. Although history suggests that advances in technology may lower the cost of attack against a particular cryptograph-ic mechanism, it also suggests that cost does not drop suddenly or pre-cipitously. It is unlikely to collapse. Given the relative effectiveness and efficiency of cryptography relative to other security measures, changes in the cost of attack against cryptography are unlikely to put security at risk. The impact is obvious and there is sufficient opportunity to compensate. Changes in technology reduce the cost to both the user of cryptography and the attacker. Because the attacker enjoys economies of scale, advanc-es such as the computer historically have favored him first and the user second. However, that probably changed forever when both the scale and the cost of the computer fell to within the discretion of an individual. Fur-ther advances in technology are likely to favor the cryptographer.
As we will see, as the cost of attack falls, the user will spend a little money to compensate. However, it is in the nature of cryptography that as costs to the user rise linearly, the costs to the attacker rise exponen-tially. For example, the cost of attack against the data encryption stan-dard (DES) has fallen to roughly a million mips years. While this is still adequate for most applications, some users have begun to use Triple DES-112. This may quadruple their cost but increase the cost of a brute force attack by 255.
One way of looking at cryptography is that it changes the problem of maintaining the secrecy of the message to one of maintaining the secrecy of the keys. How we do that is called key management.
KEY MANAGEMENT DEFINED
Key management can be defined as the generation, recording, tran-scription, distribution, installation, storage, change, disposition, and control of cryptographic keys. History suggests that key management is very important: each of these steps is an opportunity to compromise the cryptographic system. Further, it suggests that attacks against keys and key management are far more likely and efficient than attacks against algorithms.
Key management is not obvious or intuitive. It is very easy to get wrong. For example, students found that a recent release of Netscape’s SSL implementation chose the key from a recognizable subspace of the total key space. While the total space would have been prohibitively ex-pensive to exhaust, the subspace was quite easy. Key management pro-vides all kinds of opportunities for these kinds of errors.
As a consequence, key management must be rigorous and disci-plined. History tells us that is extremely difficult to accomplish. The most productive cryptanalytic attacks in history, such as ULTRA, have exploited poor key management. Modern automated key management attempts to use the computer to provide the necessary rigor and disci-pline. Moreover, it can be used to compensate for the inherent limita-tions in algorithms.
MODERN KEY MANAGEMENT
Modern key management was invented by an IBM team in the 1970s.1 It
was described in the IBM Systems Journal2 at the same time as the
pub-lication of the DES. However, while the DES has inspired great notice, comment, and research, key management has not received the recogni-tion it deserves. While commentators were complaining about the length of the DES key, IBM was treating it as a solved problem; they always knew how to compensate for fixed key length and believed that they had told the world.
Modern key management is fully automated; manual steps are neither required nor permitted. Users do not select, communicate, or transcribe keys. Not only would such steps require the user to know the key and permit him to disclose it accidentally or deliberately the steps also would be very error prone.
Modern key management permits and facilitates frequent key chang-es. For example, most modern systems provide that a different key will be used for each object, e.g., file, session, message, or transaction, to be encrypted.
Manual systems of key management were always in a difficult bind: the more often the key was changed, the greater the opportunity for error and compromise. On the other hand, the more data that was encrypted under a single key, the easier the key was to attack and the more data was com-promised with that key. To change or not to change: how to decide?
Automating the system changes the balance. It permits frequent se-cure key changes that raise the cost of attack to the cryptanalyst. The more keys used for a given amount of data, the higher the cost of attack, more keys to be found, and the lower the value of success, the less data for each key. All other things equal, as the number of keys increases, the cost of attack approaches infinity and the value of success approaches zero. The cost of changing keys increases the cost of encryption linearly but it increases the cost of attack exponentially. All other things equal, changing keys increases the effective key length of an algorithm.
Because many algorithms employ a fixed-length key, because one can almost always find the key in use by exhausting the finite set of keys, and because the falling cost and increasing speed of computers is always lowering the cost and elapsed time for such an attack, the finite length of the key might be a serious limitation on the effectiveness of the algo-rithm. In the world of the Internet, in which thousands of computers have been used simultaneously to find one key, it is at least conceivable that one might find the key within its useful life. Automatic key change compensates for this limit.
A recent challenge key3 was found using more than 10,000 computers
for months at the rate of billions of keys per second and a million MIPs years per key. The value of success was only $10,000. By definition, the life of a challenge key is equal to the duration of attack. Automated key management enables us to keep the life of most keys to minutes to days rather than days to months.
However, modern key management has other advantages in addition to greater effective key length and shorter life. It can be used to ensure the involvement of multiple people in sensitive duties. For example, the Visa master key is stored in San Francisco inside a box called the BBN SafeKeyper. It was created inside that box and no one knows what it is. Beneficial use of the key requires possession of the box and its three physical keys. Because it is at least conceivable that the box could be
de-stroyed, it has exported information about the key. Five trustees share that information in such a way that any three of them, using another SafeKeyper box, could reconstruct the key.
Key management can also be used to reduce the risk associated with a lost or damaged key. While in a communication application there is no need to worry about lost keys, in a file encryption application, a lost key might be the equivalent of loss of the data. Key management can protect against that. For example, one of my colleagues has information about one of my keys that would enable him to recover it if anything should happen to me. In this case, he can recover the key, but the implementa-tion that we are using permits me to specify how many people must par-ticipate in recovering the key.
Key management may be a stand-alone computer application or it can be integrated into another application. IBM markets a product that banks can use to manage keys across banks and applications. The NetScape Navigator and Lotus Notes have key management built in.
Key management provides the protection for keys in storage and dur-ing exchange. Smart cards may be used to accomplish this. For example, if one wishes to exchange a key with another, one can put it in a smart-card and mail it.
PRINCIPLES OF KEY MANAGEMENT
A number of principles guide the use and implementation of key man-agement. These principles are necessary, but may not be sufficient for safe implementation. That is, even implementations that adhere to these principles may be weak, but all implementations that do not adhere to these principles are weak.
First, key management must be fully automated. There may not be any manual operations. This principle is necessary both for discipline and for the secrecy of the keys.
Second, no key may ever appear in the clear outside a cryptographic device. This principle is necessary for the secrecy of the keys. It also re-sists known-plain-text attacks against keys.
Keys Must Be Randomly Chosen from the Entire Key Space
If there is any pattern to the manner in which keys are chosen, this pat-tern can be exploited by an attacker to reduce his work. If the keys are drawn in such a way that all possible keys do not have an equal oppor-tunity to be drawn, then the work of the attacker is reduced. For exam-ple, if keys are chosen so as to correspond to natural language words, then only keys that have such a correspondence, rather than the whole space, must be searched.
Key-Encrypting Keys Must Be Separate from Data Keys
Keys used to encrypt other keys must not be used to encrypt data and vice-versa. Nothing that has ever appeared in the clear can be encrypted under a key encrypting key. If keys are truly chosen randomly and are never used to encrypt anything that has appeared in the clear, then they are not vulnerable to an exhaustive or brute force attack. To understand this, it is necessary to understand how a brute force attack works.
In a brute force attack, keys are tried one after another until the key in use is found. The problem that the attacker has is that he must be able to recognize the correct key when he tries it. There are two ways to do this, corresponding clear and cipher text attacks, and cipher text–only at-tacks. In the former, the attacker keeps trying keys on the cipher text un-til he finds the one that produces the expected clear text.
At a minimum, the attacker must have a copy of the algorithm and a copy of the cryptogram. In modern cryptography, the algorithm is as-sumed to be public. Encrypted keys will sometimes appear in the envi-ronment and encrypted data — cipher text — is expected to appear there. For the first attack, the attacker must have corresponding clear and ci-pher text. In historical cryptography, when keys were used widely or for an extended period of time, the attacker could get corresponding clear and cipher text by duping the cryptographer into encrypting a message that he already knew. In modern cryptography, where a key is used only once and then discarded, this is much more difficult.
In the cipher text–only attack, the attacker tries a key on the cipher text until it produces recognizable clear text. Clear text may be recog-nized because it is not random. In the recent RSA DES Key Challenge, the correct clear text message could be recognized because the message was known to begin with the words “The correct message is ….” However, even if this was not the case, the message would have been recognizable because it was encoded in ASCII.
To resist cipher text–only attacks, good practice requires that all such patterns as format, e.g., file or E-mail message, language (e.g., English), alphabet (e.g., Roman), and public code (e.g., ASCII or EBCDIC) in the clear-text object must be disguised before the object is encrypted.
Note that neither attack will work on a key-encrypting key if the prin-ciples of key management are used. The first attack cannot succeed be-cause the crypto engine cannot be duped into encrypting a known value under a key-encrypting key. It will only encrypt a random value, which it produced inside itself, under a key-encrypting key. The cipher text–only attack cannot be made to work because there is no information in the clear-text key that will be recognized by the attacker. That is, the clear-text key is, by definition, totally random, without recognizable pat-tern, information, or entropy.
Keys With a Long Life Must Be Sparsely Used
There are keys, such as the Visa master key mentioned earlier, whose application is such that a very long life is desirable. As we have already noted, the more that a key is used, the more likely a successful attack and the greater the consequences of its compromise. Therefore, we compensate by using this key very sparsely and only for a few other keys. There is so little data encrypted under this key and that data so nar-rowly held, that a successful attack is unlikely. Because only this limited number of keys is encrypted under this key, changing it is not prohibi-tively expensive.
ASYMMETRIC KEY CRYPTOGRAPHY
Perhaps the most novel and unexpected cryptographic invention of mod-ern cryptography is asymmetric key cryptography. In this kind of cryp-tography the key has two parts: the parts are mathematically related to each other in such a way that what is encrypted with one part can only be decrypted by the other. Only one part, called the private key, is secret. The other part, the public key, is published to the world. Anyone can use the public key to encrypt a message that can only be decrypted and read by the owner of the private key. Conversely, anyone can read a message encrypted with the private key, but only the person with beneficial use of that key could have encrypted it.
For example, if A and B share a symmetric key, then either knows that a message encrypted under that key originated with the other. A change in as little as one bit of the message will cause it to decrypt to garbage and therefore the receiver knows if the message has been tampered with. However, because each has beneficial use of the key and could have cre-ated the cryptogram, they cannot demonstrate that it origincre-ated with the other. In asymmetric key cryptography, only the possessor of the private key could have created the cryptogram. Any message that will decrypt with the public key therefore is known to have originated with the per-son who published it. This mechanism provides us with a digital signa-ture capability that is independent of medium and far more resistant to forgery than marks on paper.
While key management can be accomplished using only symmetric key cryptography, it requires secret key exchange, a closed population, some prearrangement, and benefits greatly from trusted hardware. Asym-metric key cryptography enables key management without secret key ex-change in an open population with a minimum of prearrangement. It reduces the need for trusted hardware for key distribution, although it is still desirable for key storage and transcription.
However, when otherwise compared to symmetric key cryptography, asymmetric key cryptography comes up short. It requires much longer keys to achieve the same computational resistance to attack (i.e., to
achieve the same security). It takes much longer to generate a key. It is much slower and its performance is not linear with the length of the ob-ject to be encrypted. However, for keys that are to be used for a long pe-riod of time, the time required to generate a key is not an issue. For short objects to be encrypted, performance is not an issue. Therefore, asym-metric key cryptography is well suited to key management applications and in practice its use is limited to that role. Most products use symmetric key cryptography to encrypt files, messages, sessions, and other objects but use asymmetric key cryptography to exchange and protect keys.
IMPLEMENTATIONS
This section will discuss a number of products that will illustrate the power, use, and limitations of modern key management. The purpose of this discussion is to make points about key management, and will not provide a complete discussion of any of the products. The products are used only for their value as examples. The order of presentation is cho-sen for illustrative purposes rather than to imply importance.
Kerberos Key Distribution Center
The Kerberos key distribution center (KDC) is a trusted server to permit any two processes that it knows about to obtain copies of a session key. Kerberos shares a secret with every process or principal in the popula-tion. When A wants to talk to B, it requests a key from the KDC. The KDC takes a random number and encrypts it under the secret that it shares with B, appends a second copy of the key, and encrypts the result under the secret that it shares with A. It broadcasts the result into the net-work addressed to A.
A uses the secret that it shares with the KDC to recover its copy of the key and B’s copy (encrypted under the secret that B shares with the KDC). It broadcasts B’s copy into the network, addressed to B. While ev-eryone in the network can see the messages, only A and B can use them. B uses its secret to recover its copy of the key. Now A and B share a key that they can use to talk securely to each other.
This process requires that the KDC be fully trusted to vouch for the identity of A and B, but not to divulge the secrets or the key to other pro-cesses or even to use it itself. If the KDC is compromised, all of the se-crets will have to be changed, i.e., the principals must all be reenrolled. These limitations could be reduced if, instead of keeping a copy of the secret shared with the principals, the KDC kept only their public key. Then whatever other remedies might be necessary if the KDC were com-promised, there would be no necessity to change the secrets.
PGP
PGP stands for Phil’s Pretty Good Privacy. Phil Zimmerman, its author, has received honors and awards for this product, not so much because of its elegant design and implementation as for the power of encryption that it gave to the masses. It is the encryption mechanism of choice for confidential communication among individuals.
PGP is implemented exclusively in software. It is available in source code and implementations are available for all popular personal com-puters. It is available for download from servers all over the world and is free for private use. It is used to encrypt files for protection on the storage of the local system and to encrypt messages to be sent across a distance.
It uses a block cipher, IDEA, with a 128-bit key to encrypt files or mes-sages. It automatically generates a new block cipher key for each file or message to be encrypted. It uses an asymmetric key algorithm, Rivest-Shamir-Adelman (RSA), to safely exchange this key with the intended re-cipient by encrypting it using the rere-cipients public key. Only the intend-ed recipient, by definition the person who has beneficial use of the mathematically corresponding private key, can recover the block cipher key and the message.
The principles of key management require that the user’s private key not be stored in the clear, and therefore it is stored encrypted under the block cipher. The key for this step is not stored but is generated every time it is needed by compressing to 128 bits an arbitrarily long pass-phrase chosen by the owner of the private key. Thus, beneficial use of the private key requires both a copy of the encrypted key and knowl-edge of the pass-phrase.
Although PGP does not require secret exchange of a key in advance, it does require that the public key be securely acquired. That is, it must be obtained in a manner that preserves confidence that it is the key of the intended recipient. The easiest way to do this is to obtain it directly, hand-to-hand, from that recipient. However, PGP has features to pre-serve confidence while passing the public key via E-mail, public pre-servers, or third parties.
Note that if the pass-phrase is forgotten, the legitimate owner will have lost beneficial use of the private key and all message or file keys hidden using the public key. For communication encryption, the remedy is simply to generate a new key-pair, publish the new public key, and have the originator resend the message using the new key. However, for file encryption, access to the file is lost. As we will see, commercial prod-ucts use key management to provide a remedy for this contingency.
ViaCrypt PGP, Business Edition
ViaCrypt PGP, Business Edition, is licensed for business or commercial use and includes emergency key recovery features to address some of the limitations of PGP previously noted. Instead of encrypting the private key under a key generated on the fly from the pass-phrase, it introduces another level of key. This key will be used to encrypt the private key and will itself be hidden using the pass-phrases of the owners of the private key. This may be the sole user or it may be an employee and managers representing his employer. Should one pass phrase be forgotten, the oth-er can be used to recovoth-er the private key and the files. The employee is protected from management abuse of the private key by the fact that he has possession of it while management only has possession of a copy of the key used to hide it. However, both employees and management are protected from the consequences of loss of a single pass-phrase.
RSA SecurePC
RSA Secure PC is an add-in to the Windows file manager that is used for file encryption. It has features that extend the ideas in PGP BE and illus-trate some other uses of key management. It encrypts specified files, di-rectories, or folders, on command by marking and clicking, or by default by marking a file or directory and indicating that everything in it is al-ways to be encrypted. Marking the root of a drive would result in all files on the drive, except executables, always being stored in encrypted form. The object of encryption is always the individual file rather than the drive or the directory. When a file is initially encrypted, the system gen-erates a 64-bit block cipher key to be used to encrypt the file. This file key is then encrypted using the public key of the system and is stored with the file.
The private key for the system is stored encrypted using a two-level key system and pass-phrase as in PGP BE. For a user to read an encrypt-ed file, he must have the file key in the clear. To get that, he must have the private key in the clear. Therefore, when he opens a file, the system looks to see if the private key is in the clear in its memory. If not, then the user is prompted for his pass-phrase so that the private key can be recovered. At the time of this prompt, the user is asked to confirm or set the length of time that the private key is to be kept in the clear in system memory. The default is 5 minutes. Setting it to zero means that the user will be prompted for a second use. The maximum is 8 hours. The lower the user sets the time that the key may remain in memory, the more se-cure; the higher he sets it, the less often he will be prompted for the pass-phrase.
RSA SecurePC also implements emergency key recovery features. These features go beyond those described: management may specify that multiple parties must be involved in recovering the private key. These
features not only permit management to specify the minimum number of parties that must be involved, but also permit them to specify a larger set from which the minimum may be chosen. Multiparty emergency key re-covery provides both the user and management with greater protection against abuse.
BBN SafeKeyper
BBN SafeKeyper is book-size hardware box for generating and protect-ing private keys. It generates a private key/public key pair. The private key cannot be removed from the box. Beneficial use of the key requires possession of the box and its three physical keys. SafeKeyper is intended for the root key for institutions.
The box has a unique identity and a public key belonging to BBN. Af-ter it generates its key pair, it encrypts its public key and its identity un-der the public key of BBN and broadcasts it into the network addressed to BBN. When BBN recovers the key, it uses its own private key to create a certificate for the SafeKeyper that vouches for the bind between the public key and the identity of the person or institution to whom BBN sold the box.
Although the SafeKeyper box is very robust, it is still conceivable that it could be destroyed and its key lost. Therefore, it implements emergen-cy key recovery. While it is not possible to make an arbitrary copy of its key, it will publish sufficient information about its key to enable another SafeKeyper box to recreate it. For example, information about the Visa masterkey is held by five people. Any three of them acting in concert can reproduce this key.
We will defer the discussion of one more implementations, SSL, until after the following discussion of public key certificates.
Public Key Certificates
By definition, public keys do not need to be kept secret. However, it is necessary to ensure that one is using the correct public key. One must obtain the key in a way that preserves confidence that it is the right key. As already noted, the best way is to obtain the key directly from the par-ty. However, in practice, we will get public keys at the time of use and in the most expeditious manner.
As we do with traditional signatures, we will rely on a trusted third party to vouch for the association between a particular key and a partic-ular person or institution. For example, the state issues credentials that vouch for the bind between a photo, name and address, and a signature. This may be a driver’s license or a passport. Similar credentials, called public key certificates, will be issued for public keys by the same kinds of institutions that issue credentials today: employers, banks, credit card
companies, telephone companies, state departments of motor vehicles, health insurers, and nation states.
A public key certificate is a credential that vouches for the bind or join between a legal person and a public key/private key pair. It contains the identifiers of the key pair owner and the public half of the key pair. It is signed by the private key of the issuing authority and can be checked us-ing the authority’s public key. In addition to the identifiers of the owner and the key, it may also contain start and end dates, and its intended pur-pose, use, and limitations. Like other credentials, it is revocable at the discretion of the issuer and used at the discretion of the owner. Like oth-er credentials, it is likely to be one of sevoth-eral and may be used in com-bination with others.
Credential issuers or certification authorities (CAs) are legal persons trusted by others to vouch for the bind, join, or association between a public key and another person or entity. The CA may be a principal, such as the management of a company, a bank, or a credit card company. It may be the secretary of a club or other voluntary association such as a bank clearing house. It may be a government agency or designee such as the post office or a notary public. It may be an independent third party operating as a fiduciary and for a profit. The principal requirement for a certification authority is that it must be trusted by those who will use the certificate and for the purpose for which the certificate is intended. The necessary trust may come from its role, independence, affinity, reputa-tion, contract, or other legal obligation.
Secure Socket Layer (SSL)
SSL is both an application programming interface (API) and a protocol intended for end-to-end encryption in client/server applications across an arbitrary network. The protocol was developed by Netscape and the Navigator browser is its reference implementation. It uses public key cer-tificates to authenticate the server to the client and, optionally, the client to the server.
When the browser connects to the secure server, the server sends its public key along with a certificate issued by a public certification author-ity. The browser automatically uses the issuers public key to check the certificate and manifests this by setting the URL to that of the server. It then uses the server’s public key to negotiate a session key to be used for the session. It manifests this by setting a solid key icon in the lower left hand corner of the screen. Optionally, the client can send its public and a certificate for that key issued by the management of the server or a certification authority trusted by the management.
RECOMMENDATIONS FOR KEY MANAGEMENT
• To ensure rigor and discipline, automate all encryption, particularly including key management; hide all encryption from users.
• To resist disclosure or arbitrary copies of a key, prefer trusted hard-ware for key storage. Prefer evaluated FIPS-1404 hardware, dedicated
single-application-only machines (such as those from Atalla, BBN, Cylink, and Zergo), smart-cards, PCMCIA cards, laptops, diskettes, and trusted desktops, in that order. As a general rule, one should dis-courage the use of multiuser systems for key storage except for keys that are the property of the system owner or manager (e.g., payroll manager key).
• Prefer one copy of a key. Avoid strategies that require multiple cop-ies of a key. Every copy of a key increases the potential for disclo-sure. For example, rather than replicating a single key across multiple servers, use different keys on each server with a certificate from a common source.
• Change keys for each file, message, session or other object.
• Prefer one key per use or application rather than sharing a key across multiple uses. The more data that is encrypted under a single key, the greater the potential for successful cryptanalysis and the more damaging the consequences. With modern key management, keys are cheap.
• To reduce the consequences of forgotten pass-phrases, use cy key recovery for file encryption applications. Do not use emergen-cy key recovery for communication encryption; change the key and resend the message.
• Employ multiparty control for emergency key recovery; this reduces the potential for abuse, improves accountability, and increases trust all around. Consider requiring that the parties come from different levels of management and from different business or staff functions. • Prefer closed and trusted processes for key generation to ensure that keys are randomly selected from the entire key space. Avoid any manual operations in key selection.
• Prefer encryption and key management that are integrated into the application. The easiest way to hide encryption from the user and to avoid errors is to integrate the encryption into the application. • Prefer applications with integrated encryption and key management.
No serious business applications can be done in the modern network environment without encryption. Integrated encryption is a mark of good design.
NOTES
Notes
1. Dr. Dorothy Denning has told me privately that key management was invented by the National Security Agency prior to IBM. Whether or not that is true is classified. In the absence of contemporaneous publica-tion, it is unknowable. However, even if it is true, their invention did not ever make a difference; as far as we know, it never appeared in a system or an implementation, while the IBM team implemented theirs and it has made a huge difference.
2. Elander et al. Systems Journal, IBM pub G321-5066: “A Cryptographic Key Management Scheme,” 1977. 3. RSA $10,000 Challenge. http://www.frii.com/~rcv/deschall.htm.
