«Version 1.0 Released: September 13, 2012 Securosis, L.L.C. Securosis, L.L.C. Author’s Note The content in this report was ...»
Additionally, backup and storage systems themselves might place the encryption engine in any of a wide variety of locations – from individual disk and tape drives, to backup controllers, to server software, to inline proxies.
Some systems store the key with the data – sometimes in special hardware added to the tape or drive – while others place it with the engine, and still others keep it in an external key management server.
Between all this complexity and poor implementations by storage vendors, I tend to see external key management used for backup and storage more than for just about any other data encryption usage.
Application encryption Our last example is application encryption. One of the more secure ways to encrypt application data is to collect it in the application, send it to an encryption server or appliance (or embed it in the application code), and then store the encrypted data in a separate database. The keys themselves might be on the encryption server, or could even be stored in yet another system. The separate key store offers greater security, simpliﬁes management for multiple encryption appliances, and helps keep keys safe for data movement – backup, restore, and migration/synchronization to other data centers.
In each of these examples we see multiple options for where to place the components – with the corresponding tradeoffs in security, manageability, and other aspects. This list isn’t comprehensive but should give you a taste of the different ways these bits and pieces can be mixed and matched for different data encryption systems.
Next we will build on this to deﬁne the four major key management strategies, followed by recommendations for how to pick the right options to suit our needs.
The Four Key Management Strategies In the last section we covered the components of data encryption systems and ran through some common examples.
Now it’s time to move on to key management itself, and dig into the four different key management strategies.
We need to start with a discussion of the differences between encryption operations and key management; then we will detail the different enterprise-level strategies.
The diﬀerences between key management and encryption operations As we focus on data encryption across the organization rather than isolated applications of basic encryption, it is time to spend a moment on what we mean when we discuss key management vs. encryption operations.
Every data encryption operation involves a key, so there is always a key to manage, but a full-ﬂedged management system is the most important aspect of building a multipart encryption system.
Many data encryption systems don’t bother with “real” key management – they only store keys locally, and users never interact with the keys directly. For example, if you encrypt data with a passphrase using one of the many common command-line tools available, the odds are good that you don’t do anything with the key beyond choosing an encryption algorithm and key length. Super-simple implementations don’t bother to store the key at all – it is generated as needed from the passphrase. In slightly more complex (but still relatively simple) cases the key is actually stored with the data, protected by a series of other keys which are still generated from passphrases.
There is a clear division between this and the enterprise model, where you actively manage keys. Key management involves separating keys from data for increased ﬂexibility and security. It does not require you to move keys to an external system, but that is one of the more important options. You can have multiple keys for the same data, the same key for multiple ﬁles, key backup and recovery, and many more choices.
There are four main approaches to managing data encryption keys within an organization. These apply to individual cryptosystems, to various different kinds of applications, and to larger and more complicated cryptography systems.
Many of them also apply to other kinds of encryption operations, such as digital signatures and certiﬁcates, but we aren’t concerned with those for this paper.
Local key management This option is the closest to doing nothing at all for key management. Keys are all managed locally (on a single system or a cluster of systems), with all key functions handled within a single application.
Local key management is actually quite common, even though it isn’t always the best idea. Common examples include:
• Full disk encryption managed by a single user (e.g., Bitlocker or FileVault without tying into a key management server)
• Transparent database encryption
• Building encryption into an application server
• Basic backup encryption
• File server or SAN/NAS encryption In each of these cases all keys can be managed locally – in which case any key rotation, backup/restore, or auditing also must be built into the local system, but more often these capabilities are simply nonexistent.
Local key management isn’t necessarily bad, in particular isolated scenarios. For example, if you back up your data unencrypted, or with a system that uses its own keys, there may be no reason to worry about managing local keys. But for anything serious – including anything with compliance requirements – relying on local key management is asking for trouble.
Application stack key management This refers to separating the keys from the local system and managing them within a multi-instance application. Whatever software stack/system you run manages its own keys for its own client software.
Full disk encryption is one of the most common enterprise examples. A central management server handles conﬁguration and keys for all encrypted laptops and desktops that use that vendor’s software. This key management system is never used for anything else, such as databases, but may manage other data encryption features supported by the product
(including ﬁle/folder encryption). All important key management functions, including administrative and recovery keys, rotation, backup/restore, and audit, are built into the application stack’s key manager.
Application stacks are closed, proprietary systems that may involve distributed instances. They implement encryption within their own software components, and aren’t designed to manage it externally. That said, many support use of external key management.
Other typical uses include email encryption, some backup encryption tools, and even enterprise Digital Rights Management – DRM is implemented through cryptography.
Application stack key management is totally suitable when it meets the particular requirements of the situation. When encryption is the key function of a product, as with full disk encryption, this approach often works perfectly – with no need for additional key management. On the other hand, when encryption is merely a feature of an existing product, key management is often minimal at best – typiﬁed by encryption products bolted onto existing backup systems.
We call this “silo” key management since a key manager is typically used for one or more applications managed within a single organizational silo. For example, you might have one silo to manage full disk encryption keys, another for database and application keys, and another for storage keys. Each of these silos is managed independently, on different hardware/ software.
A variety of dedicated key management options are available – including hardened hardware appliances (Hardware Security Modules, HSMs), software, virtual appliances, and even Software as a Service (SaaS). We are focusing on key management strategies rather than products, so we won’t go into all the various features and functions, but sufﬁce it to say they tend to have far more robust capabilities (and often stronger security) than all but the best application stack tools. Aside from all the added functionality of an external service, the external service can manage keys for multiple different application stacks. This can be important for unifying auditing/reporting and meeting other compliance requirements.
Key management tools also reduce the overhead and complexity of encryption operations – especially for application and database encryption, where application stack management often isn’t available. Using APIs and plugins, your developers and DBAs don’t need to reinvent the wheel; something very few people – including crypto experts – manage to do securely. This approach also removes keys from the systems involved when they aren’t needed, further beneﬁting security. Hardened encryption engines that link up with external key managers offer high-security modes, where they do things like pull the key down for a single operation, use it, and then overwrite the key’s memory addresses to completely eliminate it from the system.
Pragmatic Key Management for Encryption 10 Securosis, L.L.C.
Not to give away the next section, but if a data encryption feature or software doesn’t include centralized key management, or your application stack key management software doesn’t provide all the functions you need, it’s time to move up to a dedicated key management service. The most common places we see these are backup and storage encryption, application and database encryption, and data encryption for cloud services. But at this level we are still dealing with a somewhat-isolated silo versus an enterprise strategy.
Enterprise key management Building on silo key management, enterprise key management adds a “manager of managers” to centralize most or all key management within the organization. We are focused on data encryption key management, but this may also encompass keys for other operations such as certiﬁcate management. The manager adds features to broaden its scope;
such as improved separation of duties; integration and management of other dedicated key managers; the ability to segregate keys and users based on role, use, etc.
While an organization might have a collection of different key management services in different silos, enterprise key management ties them all together with central administration and management. Practically speaking there will probably still be some silos, but this strategy embraces and manages keys for at least most encrypted data.
Although enterprise key management has been discussed for years, it is more of a vision organizations strive towards and used by relatively few enterprises. We predominantly see it within ﬁnancial services, retail, and other companies with need for distributed encryption operations across application silos. In some cases, we even see it used to exchange keys between organizations.
Enterprise key management can also play a key role in use cases beyond data encryption- especially certiﬁcate, identiﬁcation, and signing functions where keys and certiﬁcates need to work across different systems, applications, or even functions. We’ll go into more selection details in the next section, but organizations should take a look at enterprise key management if they anticipate ever needing cross-domain/silo keys, such as those used to encrypt data in an application, but then decrypt or use it in other applications, databases, or analysis tools.
To recap, the four key management strategies are:
• Manage keys locally
• Manage keys within an single application stack with a built-in key management feature
• Manage keys for a silo using an external key management service/server/appliance, separate from the data and application stacks
• Coordinate management of (most or all) keys across the enterprise with a centralized key management tool Next we will talk about how to choose your strategy, and when to switch between these options.
Choosing Your Key Management Strategy In our last section we covered the four enterprise key management strategies. Here’s how to pick the right strategy for your organization.
To recap, there are four key management strategies:
• Local management
• Application stack management
• Silo management
• Enterprise key management
As much as I would like to drag this out into a long and complex assessment process, it’s actually fairly simple: