There is a lot of talk in certain circles at the moment about key management in distributed on-demand computing environments (aka ‘the cloud’), but much of this seems too deeply product- or technology-oriented.
All this ‘solution-first’ talk approaches the problem in the wrong way. We need to return to our roots, look at why key management has become important and revalidate the use of cryptography to solve cloud security issues.
There is no doubt that cryptography and key management are vital tools in the cloud information security battle, and companies with long experience in crypto and key management have much to offer this immature space. But we must re-examine the way we employ these tools in this new context and make sure that the technology is solving the problems, not defining them.
In any walk of life, people tend to focus on their area expertise. To a man with a hammer, every problem is a nail. Those in cryptography and key management are no different. When cloud computing became big news, everyone looked at their tool bag and applied existing policies, processes and products to the new environment.
Let’s take a step back. Why do people need key management? Why has the field grown so much over the past few years, and why have best practices and standards of due care developed the way they have? This much is obvious: more people are using more cryptographic keys than ever before, and cryptography is meaningless without strong key management.
And why the increase in cryptography uptake? Because in today’s information society, there is ever more information in need of ever more protection.
We don’t practice key management for its own sake: we do it to make cryptography useful. And we don’t use cryptography for its own sake either: we use it to support our businesses, to protect the information that is the lifeblood of the modern economy. Each key, each use of cryptography means something. It’s a proxy to some promise made to underpin our electronic business and personal transactions. A signature means “Alice really made this”. Encryption means “Only Bob can read this”.
And this is the way we need to think about key management in the cloud. It’s all about information-centric protection, not the technology. We should be asking: ‘How do I use cryptography and key management to uphold my promises?’
By approaching the problem in this way we can reduce the legion of bamboozling issues around the familiar concept of trust, and start formulating a primary approach to cloud key management and security without worrying specifically about the technologies we will be using.
Firstly, there’s the Trust Everyone Strategy, where existing applications, keys and management tasks are fork-lifted from the data center into the service provider. No special steps are taken to address the control challenges introduced by the cloud. However, no matter what else you outsource, you can’t outsource your responsibility, so this strategy is not really an option. I’m all for SLAs bridging the gap between business desires and technical reality, but wholesale handover of sensitive operations is probably a bridge too far.
At the other end of the scale is the Trust No-one Strategy, where no important cryptographic infrastructure is moved out to the cloud. While very safe, and a good first step for hybrid deployment, this approach does not enable exploitation of all the cloud has to offer.
The Trust Someone Strategy is the first step in a genuine risk-based approach to moving keys into the cloud. Given some visibility of service provider operations, you can make an informed choice about how much you release to their control, much like traditional outsourcing. Here you accept that a group of administrators and security personnel can affect your security but, given sight of hiring policies, systems management processes and internal physical security, that may be acceptable.
Be on the lookout, however, for issues of multi-tenancy, the constancy of personnel management at the provider, and the economics of providing strong separation between personnel and management systems. Also be sure you can find proof of whatever you’re relying on. What systems and processes give you independent proof that procedures are being followed and promises kept?
Then there’s the Just In Time Strategy, where keys and sensitive materials are stored on premise, only being released into the cloud for a short time when needed. Quite a few companies are starting to offer such solutions, with a large on-premise management system and a small software plug-in for cloud applications that can fetch and use keys when needed.
This is a promising model but in it’s early days: watch out for highly proprietary systems, vendor lock-in and the need to modify applications directly to take advantage of the solution. And remember – the keys have still been exposed to the cloud, no matter how briefly.
Next we have what I call the Mole Strategy, because you use tunnels. This is the logical conclusion of hybrid systems and provides a solution to the exposure issues of Just in Time. With a hardware root-of-trust or suitable access to a user-controlled secure element in the cloud, you can assert some control over key management by connecting to a trusted island in a whole sky of cloud. This is not yet a reality, but for security-conscious users it would be a real boon.
Finally, we have the Big Brother Strategy. Sometimes overlooked, the deterrent effect of strong auditing and oversight should not be underestimated. The use of hardware devices, cryptographic signatures and independent access control for audit keeping can vastly improve the trustworthiness and reliability of a log and provide an added deterrent. While this approach cannot prevent an event from happening, it does provide excellent visibility that enables the organization to make informed risk decisions about what data they can trust in the cloud.
Whichever strategy you choose for your move to the cloud, remember that your cryptographic keys are more than data, they are your promises. Keep them well.
Jon Geater has more than 10 years of technical experience as a software architect and chief architect in the information security industry and has helped define many real-world security products and systems. As director of technical strategy at Thales, Geater is a technical evangelist for the company’s information technology security activities. He serves as the technical voice of the Thales strategy group and ensures that the product portfolio meets the needs of both the company and the market. Geater represents Thales at academic conferences and on standards bodies, and is a co-founder of the OASIS KMIP key management group. He holds a BSc (Hons) in computer science.