In our last post 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 differences 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-fledged 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 interacts with the key 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 more flexibility and security. It does not require you to move to 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 files, key backup and recovery, and many more choices.
The four key management strategies
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 certificates, 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.
Silo key management
This refers to separating the keys a the local system and managing them within a multi-system 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 configuration and keys for all encrypted laptops and desktops. 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 file/folder encryption). All important key management functions, including administrative and recovery keys, rotation, backup/restore, and audit, are built into the silo key manager.
Other typical uses include email encryption, some backup encryption tools, and even enterprise Digital Rights Management – DRM is implemented through cryptography.
Silo 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 – typified by encryption products bolted onto exiting backup systems.
Key management services
So far the two strategies we have discussed keep the keys within a single system or application stack. The next couple strategies introduce a new component: a dedicated key management system.
When local or silo key management is inadequate, it’s time to bring in a tool specifically to address the problem. Move keys outside the silo and integrate dedicated key management with one or more applications. This used to be incredibly difficult, but more and more products (both commercial and free software / Open Source) now support key management standards that make it much easier to use external management. Before standards we had to either rely on the vendor to provide proprietary hooks, or reverse engineer the entire thing.
A variety of dedicated key management options are available – including hardened hardware appliances, 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 suffice it to say they tend to have far more robust capabilities (and often stronger security) than all but the best silo tools. Aside from all the added functionality of an external service, the external service can manage keys for multiple different silos. This can be important for unifying auditing/reporting and meeting other compliance requirements.
Key management services also reduce the overhead and complexity of encryption operations – especially for application and database encryption, where silo 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 benefiting 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.
Not to give away the next section, but if a data encryption feature or software doesn’t include centralized key management, or you silo 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.
Enterprise key management
Building on the key management service, 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 certificate 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, 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.
To recap, the four key management strategies are:
- Manage keys locally
- Manage keys within a silo, which is typically a single application stack with a built-in key management feature
- Manage keys 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.
Reader interactions
One Reply to “The Four Enterprise Key Management Strategies”
Rich is right on when he says that local key management with weak native tools in a compliance driven or high sensitivity setting is asking for trouble – this is why HSMs were invented. Although this blog is more focused on pure key management solutions I do think that HSMs are relevant in the discussion. Although the primary focus of an HSM is on creating a trustworthy environment in which to perform crypto functions, they also perform a valuable role in protecting and managing the keys associated with those crypto operations. For example, high value or regulated applications such as a certificate authority, an instance of TDE, DNSSEC, even an SSL enabled web server might be deployed with an HSM to overcome the sometimes lacking key management capabilities of the native app (e.g. to establish dual controls or strong authentication for admins) and to overcome the frailties of software based keys. Furthermore they help establish formal security benchmarks through independent certification such as FIPS 140-2. HSMs tend to come in one of two form factors – a plug-in cards that drop into a server or a network attached appliance to be shared by multiple clients. So in the language of this blog, it would seem to me that embedded, card based HSMs would qualify as high assurance ‘local’ key management systems and appliance based HSMs would fit the ‘silo’ description.