Cloud computing creates security problems that most organizations have not yet had to face on a large scale: protecting data when the location of the data is generally unknown. Encryption is a useful tool for solving this problem, but using it in the cloud is hard because of the key management problems that this causes. Fully federated key management can provide the basis for protecting sensitive data in the cloud, and it's probably the basis for how we'll eventually protect such data. Let's look at exactly what this means and how it will probably work.
Key management
A cryptographic key is much like the combination to a safe: if you have the right combination, it's easy to open a safe, but it's hard to open one without the right combination. Similarly, if you have the right key, decrypting encrypted data is easy, but decrypting it is impractical without this key.
If you're careless with the combination to your safe, someone else can easily use it to open your safe, and the protection provided by the safe is compromised. Similarly, the cryptographic keys that you use to encrypt data need to be handled carefully. If you're careless with them then the protection provided by encryption can be essentially eliminated.
Key management covers all the details of how to handle keys carefully enough to ensure this does not happen. It ensures that you don't do the cryptographic equivalent of writing the combination to your safe on a Post-it note and sticking it to the wall next to your desk.
Encryption only involves complicated mathematics that's incomprehensible to most people. Key management involves technology, people and processes, so it's even more difficult. Encryption provides an extremely high level of protection. Even with the world's most powerful supercomputers, hackers would need billions of years to beat modern encryption. Key management is nowhere near as robust. It's usually the weak link that limits how much protection data really gets, so it's important to get it right if you're serious about protecting sensitive data.
Federation
Federation describes how different computer systems can work together. In the context of key management, federation includes how different applications can get keys from the same key server. This is an important aspect of key management that needs to be addressed before encryption can be used to protect sensitive data in the cloud, and the lack of the ability to do federation dramatically limits the usefulness of many encryption and key management products today.
Encrypting a backup tape in a data center and decrypting it in an off-site disaster recovery site is a very simple example of federation. In this case, two different tape drives need to work with the same key server to get the key that's needed to encrypt or decrypt the backed-up data. But even extremely simple cases of federated key management can create problems that are hard to solve in practice.
The 2009 Encryption and Key Management Industry Benchmark Report from industry analyst firm Trust Catalyst estimates that only 41 percent of businesses encrypt backup tapes, and that issues relating to key management are the most common reason for not doing so. If the simple cases are that hard, it's not hard to understand why there's no solution for the harder cases yet, but that's what we need to protect data in the cloud.
Cloud computing needs fully federated key management
In cloud computing, we have sensitive data that could be anywhere, and we need the ability for any application that needs access to this data to be able to decrypt it. To do this, we need a way for any application to be able to get the keys that it needs to decrypt data that it gets from the cloud and to use these keys in a careful way that keeps the data protected. More concisely, that's fully federated key management.
Federated key management for cloud computing
If today's systems can't implement fully federated key management, what are the missing pieces? If we look more closely at how cryptographic keys are handled today, we can probably get a good idea of what's needed in the more general case.
A cryptographic key always has additional information associated with it that uniquely identifies it. When a tape drive gets a key to use to encrypt stored data, for example, it also gets a unique key identifier which it stores with the encrypted data. To decrypt the encrypted data, the tape drive requests the key that corresponds to the key identifier that it finds with the encrypted data.
It's possible to extend the idea of a key identifier to include information about the key server where the right key can be obtained. Instead of having a key identifier like this:
we might have one like this:
where the additional information indicates the URL of the key server where the key can be obtained. If all applications understand how to handle such information when it's included in a key identifier, then they can easily use this information as the basis for federated key management.
How it's used today
This approach has already been used with great success in existing key management technologies. Systems that use Identity-Based Encryption (IBE), for example, already use more general key identifiers. In these systems, the identity of a user plus other policy information functions as the key identifier. In the case of using IBE to encrypt an email message, such an identifier might look like this:
which indicates the email address of the recipient of the encrypted message, the time after which the private key can be downloaded from the key server, and the URL where the recipient can get the private key that he needs to decrypt the message. Any recipient that can interpret this type of key identifier can then contact the key server and request the IBE key needed to decrypt this message.
This approach hasn't quite made it to other encryption technologies yet, although it probably will soon. The most recent draft of the IEEE P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data uses this approach to define unique identifiers for keys from which it's easy to find the URL of the key server where the key can be obtained. Once that standard is implemented, key management for encrypting backup tapes will certainly get much easier.
Once this idea is extended to other technologies, we'll have the fully federated key management that we need to protect sensitive data in the cloud. This sounds simple enough, but actually writing a standard that will be the basis for doing this in an interoperable way isn't easy. Using technologies like IBE may be as close as we can come to fully federated key management until the necessary standards are completed.
Key management
A cryptographic key is much like the combination to a safe: if you have the right combination, it's easy to open a safe, but it's hard to open one without the right combination. Similarly, if you have the right key, decrypting encrypted data is easy, but decrypting it is impractical without this key.
If you're careless with the combination to your safe, someone else can easily use it to open your safe, and the protection provided by the safe is compromised. Similarly, the cryptographic keys that you use to encrypt data need to be handled carefully. If you're careless with them then the protection provided by encryption can be essentially eliminated.
Key management covers all the details of how to handle keys carefully enough to ensure this does not happen. It ensures that you don't do the cryptographic equivalent of writing the combination to your safe on a Post-it note and sticking it to the wall next to your desk.
Encryption only involves complicated mathematics that's incomprehensible to most people. Key management involves technology, people and processes, so it's even more difficult. Encryption provides an extremely high level of protection. Even with the world's most powerful supercomputers, hackers would need billions of years to beat modern encryption. Key management is nowhere near as robust. It's usually the weak link that limits how much protection data really gets, so it's important to get it right if you're serious about protecting sensitive data.
Federation
Federation describes how different computer systems can work together. In the context of key management, federation includes how different applications can get keys from the same key server. This is an important aspect of key management that needs to be addressed before encryption can be used to protect sensitive data in the cloud, and the lack of the ability to do federation dramatically limits the usefulness of many encryption and key management products today.
Encrypting a backup tape in a data center and decrypting it in an off-site disaster recovery site is a very simple example of federation. In this case, two different tape drives need to work with the same key server to get the key that's needed to encrypt or decrypt the backed-up data. But even extremely simple cases of federated key management can create problems that are hard to solve in practice.
The 2009 Encryption and Key Management Industry Benchmark Report from industry analyst firm Trust Catalyst estimates that only 41 percent of businesses encrypt backup tapes, and that issues relating to key management are the most common reason for not doing so. If the simple cases are that hard, it's not hard to understand why there's no solution for the harder cases yet, but that's what we need to protect data in the cloud.
Cloud computing needs fully federated key management
In cloud computing, we have sensitive data that could be anywhere, and we need the ability for any application that needs access to this data to be able to decrypt it. To do this, we need a way for any application to be able to get the keys that it needs to decrypt data that it gets from the cloud and to use these keys in a careful way that keeps the data protected. More concisely, that's fully federated key management.
Federated key management for cloud computing
If today's systems can't implement fully federated key management, what are the missing pieces? If we look more closely at how cryptographic keys are handled today, we can probably get a good idea of what's needed in the more general case.
A cryptographic key always has additional information associated with it that uniquely identifies it. When a tape drive gets a key to use to encrypt stored data, for example, it also gets a unique key identifier which it stores with the encrypted data. To decrypt the encrypted data, the tape drive requests the key that corresponds to the key identifier that it finds with the encrypted data.
It's possible to extend the idea of a key identifier to include information about the key server where the right key can be obtained. Instead of having a key identifier like this:
we might have one like this:
where the additional information indicates the URL of the key server where the key can be obtained. If all applications understand how to handle such information when it's included in a key identifier, then they can easily use this information as the basis for federated key management.
How it's used today
This approach has already been used with great success in existing key management technologies. Systems that use Identity-Based Encryption (IBE), for example, already use more general key identifiers. In these systems, the identity of a user plus other policy information functions as the key identifier. In the case of using IBE to encrypt an email message, such an identifier might look like this:
which indicates the email address of the recipient of the encrypted message, the time after which the private key can be downloaded from the key server, and the URL where the recipient can get the private key that he needs to decrypt the message. Any recipient that can interpret this type of key identifier can then contact the key server and request the IBE key needed to decrypt this message.
This approach hasn't quite made it to other encryption technologies yet, although it probably will soon. The most recent draft of the IEEE P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data uses this approach to define unique identifiers for keys from which it's easy to find the URL of the key server where the key can be obtained. Once that standard is implemented, key management for encrypting backup tapes will certainly get much easier.
Once this idea is extended to other technologies, we'll have the fully federated key management that we need to protect sensitive data in the cloud. This sounds simple enough, but actually writing a standard that will be the basis for doing this in an interoperable way isn't easy. Using technologies like IBE may be as close as we can come to fully federated key management until the necessary standards are completed.
