There are more systems in more locations and these are often spread across the world. Many, if not most, IT organizations today, are running lights-out data center operations. There are no management information system (MIS) personnel to oversee the security of the information in those data centers. Many organizations have systems running in remote locations that are not readily accessible to MIS personnel. Some systems may even be running in locations that are under someone else's control - leased space, partner sites, customer sites, etc.
Remote storage technologies (e.g. storage area networks) place sensitive, even critical company information, at a vendor's site on vendors' systems where access is controlled by the vendor. Use of "untrusted" networks is the norm. Connections to potentially hostile networks like the Internet are commonplace. Vendors, partners, regulatory agencies and even customers now routinely need access to information that is stored deep within what used to be the security perimeter of the organization. In fact, the need for information to be readily available to those who need it, when they need it, has made the concept of a "secure perimeter" a misnomer. There is no such thing as a truly secure perimeter in today's business environment because sensitive information flows across those boundaries constantly.
As a consequence, highly sensitive data is everywhere. It is in the communications channels that are used to share information with customers, partners, vendors, remote employees and others; in web servers that act as portals to information inside and outside the organization; in application servers that process and manipulate information for use; and, in databases that store sensitive information. Each location where sensitive information could be exposed is another point of risk that must be secured. Protecting sensitive information effectively at each of these points of risk requires cryptographic keys.
Protecting this information effectively requires the use of products that are capable of securing sensitive data wherever it resides within your organization. While firewalls, anti-virus tools, intrusion detection and other security technologies are essential components in any information security program, they cannot effectively protect data in all these locations. For many organizations seeking to ensure confidentiality and integrity, even within their traditional boundaries, the use of cryptography is increasingly compelling. This is true also with the adoption of security applications that employ cryptography to issue personal credentials, encrypt information or electronically sign transactions.
Key management is emerging as one of the most difficult challenges, as enterprises increase their use of cryptography to protect their business. Although designing secure cryptographic algorithms and protocols is not easy, there is a large body of academic research to rely on. Managing the keys effectively and keeping them secret is much harder. Since compromise of the keys compromises the entire security model, assuring the security of the keys is essential.
Key management is concerned with the secure generation, storage, distribution, destruction and (optionally) the secure backup and recovery of cryptographic keys. It is essential to generate cryptographically strong keys, to store them securely, to have a mechanism to distribute them securely and efficiently and to ensure that they can be (and are) destroyed when necessary.
In many implementations, it is also necessary to securely backup and be able to efficiently restore cryptographic keys. In the financial services sector for example, there are significant legal and regulatory requirements for the retention of data. If that data includes information that has been encrypted, it is necessary to be able to securely back up and recover not only the data, but the keys that were used to encrypt it - sometimes many years later.
In today's highly distributed and often unattended computing environments, secure storage and distribution of keys are two major concerns.
Secure Key Storage
With software-based cryptography, all of the cryptographic components (i.e., algorithm, key, clear text, cipher text) reside in the unprotected memory of generic server platforms running commercial operating systems, where they are susceptible to duplication, modification or substitution. Even in situations where the keys themselves are "hidden" (obfuscated) in the software they are still vulnerable to relatively straightforward attacks. Leaving the keys in software can be likened to locking the front door and leaving the key under the doormat. If the key is compromised, the entire security model is broken. A duplicated private key allows an attacker to recover all encrypted data. A duplicated asymmetric private key allows an adversary to falsely generate digital signatures that could be attributed to the owner. Worse, if theft of the key(s) is undetected (which is quite possible) - an attacker can continue to decrypt or sign data for an extended period of time, without the owner being aware that his or her data is no longer secure, or that an electronic identify is being used fraudulently.
In hardware-based cryptography, physical and logical barriers allow data to pass, while the encryption algorithm and key are kept secure in the protected memory of a tamper-resistant hardware security module (HSM.) Thus, hardware-based cryptography ensures the confidentiality, integrity and authenticity of cryptographic keys. Further, hardware-based cryptography provides assurance regarding the integrity and authenticity of the cryptographic algorithm itself to reinforce the overall level of security. For these reasons, most organizations resolve the key storage problem with the use of cryptographic HSMs.
There are standards for cryptographic hardware. The most widely accepted standard (internationally) is the U.S. Federal Information Processing Standard (FIPS) 140-1. This standard contains four different security levels, applicable to different needs and different products. For most business security purposes, Level 3 is recommended, requiring that HSMs be tamper-resistant and tamper-evident. "FIPS 3" as it is often referred to has become a de facto standard in the financial services industry - the largest users of cryptography today.
Secure Key Distribution
We can securely generate, store and use cryptographic keys inside the HSM. But we still need a mechanism to distribute keys securely to all those remote or unattended locations that are now an integral part of the computing environment. New keys will be needed as new and existing applications add the use of cryptography to meet privacy and security requirements. Best practices also dictate that keys be changed periodically. Keys should also be changed immediately if a compromise is suspected. Having the ability to quickly, yet securely, distribute keys is essential.
Some HSMs adopt an intuitively simple approach to key management and retain the keys in hardware at all times. The only way to transfer keys to another HSM in this model is to bring two HSMs into physical contact with each other. If you need to distribute keys to multiple locations around the world, this clearly presents a problem. If you need to do it quickly, it presents a significant problem. Happily, there are HSMs that provide an alternative. These HSMs create a key encrypting key (KEK) when they are first activated. This KEK never leaves the HSM. It is used to wrap or "blob" other (application) keys. These "key blobs" consist of random data that can be reconstructed as key material only within an HSM that contains the correct KEK.
This approach means that application keys can be safely stored outside the HSM - e.g. on the hard drive of the server. It also means there is no restriction to the number of keys that can be stored and ensures that the process of loading application keys into new HSMs or sharing keys across multiple servers and multiple locations is significantly easier than with other approaches
This approach allows the following:
- Application keys are encrypted and signed using a triple-DES wrapper key. Triple-DES is functionally unbreakable with any current or foreseeable technology. This key management control is FIPS 140-1 Level 3 validated and complies with ISO standard 11568 part 2 (clause 4.1.3) that states "a secure cryptographic device may be required to manage keys of several types. Cryptographic keys used in such a system may be held securely outside of the cryptographic device by being stored in an enciphered form by using KEKs (key encryption keys) which either exist only within the cryptographic device, or are enciphered under a higher level KEK."
- The wrapper key (KEK) is the only key permanently stored in the module. The wrapper key is backed up securely across multiple smartcards, using a "k of n" secret sharing scheme. This protects it from compromise by any single person. In order to provide a strong level of protection for this critical key, it is effectively split into a number (n) of shares. Each share is stored on a smartcard. A minimum number of shares (k) is required to recreate the KEK. This number (k) should be greater than n divided by 2 (3 of 5, 4 of 7, etc.) Each card can then be given to a different person so that 3 of 5 administrators (for example) are required to recreate this "master" key.
- Adding new modules or sharing keys across multiple servers is straightforward. An application key can be loaded into any HSM that shares the same 'wrapper' key (KEK). This makes this key management framework particularly suitable for installations with multiple servers or for geographically dispersed enterprises
- Copying a key to another HSM is achieved without having to physically bring two devices together. This is essential for the modern e-business where unattended operation in remote areas of the world is increasingly common.
- This model allows HSMs to be replaced without fear of losing keys and allows additional HSMs to be added to the system without exposing the existing keys. This is vital given the amount of historic data that may have been encrypted using a specific key that might otherwise be lost or compromised
- This framework is also designed to ensure that there is no single point of failure. If a module fails (or is stolen), keys can be recovered by initializing a new HSM, reconstituting the specific KEK 'wrapper' key (by bringing together the correct number of administrator smartcards) and loading and 'unwrapping' the required application keys inside the HSM.
- Backup of application keys takes place as part of the normal backup procedure. Since the key blobs are only useful inside an HSM that contains the required KEK, encrypted application keys can safely be backed up with the data they are protecting - greatly facilitating recovery of information and enormously simplifying archiving.
Using encryption effectively to secure points of risk across an enterprise requires the ability to securely distribute keys to multiple points across the enterprise. Using this model allows you to distribute keys where you need them, when you need them, to store as many keys as you require and to take advantage of the protections of cryptographic hardware - while assuring the security of the keys and your encryption solution.
David Cullinane, CPP, CISSP, is senior consultant for nCipher, Inc. (www.ncipher.com).