Our last post covered two of the main technical features of an enterprise key manager: deployment and client access options. Today we will finish up with the rest of the technical features – including physical security, standards support, and a discussion of Hardware Security Modules (HSMs).

Key Generation, Encryption, and Cryptographic Functions

Due to their history, some key managers also offer cryptographic functions, such as:

• Key generation
• Encryption and decryption
• Key rotation
• Digital signing

Key generation and rotation options are fairly common because they are important parts of the key management lifecycle; encryption and decryption are less common.

If you are considering key managers that also perform cryptographic functions, you need to consider additional requirements, such as:

• How are keys generated and seeded?
• What kinds of keys and cryptographic functions are supported? (Take a look at the standards section a bit later).
• Performance: How many cryptographic operations of different types can be performed per second?

But key generation isn’t necessarily required – assuming you only plan to use the tool to manage existing keys – perhaps in combination with separate HSMs.

Physical Security and Hardening

Key managers deployed as hardware appliances tend to include extensive physical security, hardening, and tamper resistance. Many of these are designed to meet government and financial industry standards.

The products come in sealed enclosures designed detect attempts to open or modify them. They only include the external ports needed for core functions, without (for example) USB ports that could be used to insert malware.

Most include one or more smart card ports to insert physical keys for certain administrative functions. For example, they could require two or three administrator keys to allow access to more-secure parts of the system (and yes, this means physically walking up to the key manager and inserting cards, even if the rest of administration is through a remote interface).

All of these features combine to ensure that the key manager isn’t tampered with, and that data is still secure, even if the manager is physically stolen.

But physical hardening isn’t always necessary – or we wouldn’t have software and virtual machine options. Those options are still very secure, and the choice all comes down to the deployment scenarios you need to support. The software and virtual appliances also include extensive security features – just nothing tied to the hardware enclosure or other specialized hardware.

Anyone claiming physical security of an appliance should meet the FIPS 140-2 standard specified by the United States National Institute of Standards and Technology (NIST), or the regional equivalent. This includes requirements for both the software and hardware security of encryption tools.

Encryption Standards and Platform Support

As the saying goes, the wonderful thing about standards is there are so many to choose from. This is especially true in the world of encryption, which lives and breathes based on a wide array of standards.

An enterprise key manager needs to handle keys from every major encryption algorithm, plus all the communications and exchange standards (and proprietary methods) to actually manage keys outside the system or service where they are stored. As a database, technically storing the keys for different standards is easy. On the other hand, supporting all the various ways of managing keys externally, for both open and proprietary products, is far more complex. And when you add in requirements to generate, rotate, or change keys, life gets even harder.

Here are some of feature options for standards and platform support:

• Support for storing keys for all major cryptographic standards.
• Support for key communications standards and platforms to exchange keys, which may include a mix of proprietary implementations (e.g., a specific database platform) and open standards (e.g., the evolving Key Management Interoperability Protocol (KMIP)).
• Support for generating keys for common cryptographic standards.
• Support for rotating keys in common applications.

It all comes down to having a key manager that supports the kinds of keys you need, on the types of systems that use them.

System Maintenance and Deployment Features

As enterprise tools, key managers need to support a basic set of core maintenance features and configuration options:

Backup and Restore

Losing an encryption key is worse than losing the data. When you lose the key, you effectively lose access to every version of that data that has ever been protected. And we try to avoid unencrypted copies of encrypted data, so you are likely to lose every version of the data, forever.

Enterprise key managers need to handle backups and restores in an extremely secure manner. Usually this means encrypting the entire key database (including all access control & authorization rules) in backup. Additionally, backups are usually all encrypted with multiple or split keys which require more than one administrator to access or restore. Various products use different implementation strategies to handle secure incremental backups so you can back up the system regularly without destroying system performance.

High Availability and Load Balancing

Some key managers might only be deployed in a limited fashion, but generally these tools need to be available all the time, every time, sometimes to large volumes of traffic.

Enterprise key managers should support both high availability and load balancing options to ensure they can meet demand.

Another important high-availability option is key replication. This is the process of synchronizing keys across multiple key managers, sometimes in geographically separated data centers. Replication is always tricky and needs to scale effectively to avoid either loss of a key, or conflicts in case of a breakdown during rekeying or new key issuance.

Hierarchical Deployments

There are many situations in which you might use multiple key managers to handle keys for different application stacks or business-unit silos. Hierarchical deployment support enables you to create a “manager of managers” to enforce consistent policies across these individual-system boundaries and throughout distributed environments.

For example, you might use multiple key managers in multiple data centers to generate new keys, but have those managers report back to a central master manager for auditing and reporting.

Tokenization

Tokenization is an encryption alternative that replaces a sensitive value with a random one, known as a token. The tokenization tool tracks which tokens match which sensitive values and, when the right conditions are met, can use that to recover the protected data.

The key difference between tokenization and encryption is that an encrypted value can always be decrypted with the key, whereas a token can only be converted to the original data by the tokenization tool itself. Additionally, tokens can be created to match the format of the original data, making them easier to substitute in legacy systems.

We cover tokenization products in depth in Understanding and Selecting a Tokenization Solution. Some key managers also include tokenization features, while some tokenization products include key management. If you are interested in tokenization we suggest you read that paper.

The role of HSMs in key management

All Hardware Security Modules – HSMs for short – supports a wide range of cryptographic functions such as key generation, signing operations, certificate management, key storage, and root certificate security. HSMs are comprised of specialized hardware that provides fast and efficient cryptographic operations and protection from physical attacks. The hardware is deployed as a network appliance, or a special card within a server, to offload these computationally expensive operations.

As we mentioned, many key managers started their lives as HSMs, and many current HSMs support most or all needed key management functions. All HSMs include some level of key management, as well as additional features. Despite this, not all HSMs are intended for use as enterprise key managers – some are only designed to manage their own keys. Some HSMs don’t store keys at all – they create and use keys stored elsewhere to perform encryption services.

An enterprise key manager is focused primarily on managing encryption keys. Additional cryptographic functions aren’t required for these products.

As you can see, there is considerable overlap, and many different choices depending on what you need. We will focus on key management features and functions, but keep in mind that they may show up in a single-purpose enterprise key management tool, an HSM, or in other encryption tools with expanded key management support.