If you are using encryption, somewhere you have encryption keys. Where you store them, and how they are managed and shared, are legitimate concerns. It is fashionable to store all keys in a single centralized key management server. Much as the name implies, this means storing all of your keys, of different types, for multiple use cases into a single key management server. Rich likes to call these ‘uber’ key manager, that handle any and all key functions; and are distinct from external key management servers that unify instances of single application, or provide key services across the disks in your storage array. Conceptually, a single product that handles all my key needs from a unified interface sounds great. But the real question is: why do you need it?

Central key management is not simplified key management. Central key management requires architectural and deployment changes. Consolidation of key storage and use policies does not ensure easier management, but does mean increased cost. Few people want or need centralized key management. Putting all your keys from every application or services into a single monolithic key management store offers few advantages, and creates a number of problems itself. The implication is that a central server will offer easier management, increased redundancy, and greater functionality; but these are often illusory benefits, based on solving a problem you did not have to begin with. In practice the internal and external key services that came with the products you already own are likely not only sufficient, but better. Here’s why:

  • No reason to share keys – Databases, disks, applications, file systems, and wherever else you encrypt seldom (if ever) need to share keys across these different services. Even if the encryption algorithm, key type, and key size are all consistent, there is no need to share keys between your tape drive and web application server. Using encryption to provide data integrity and privacy is a common goal, but the use cases and technical constraints are radically different.
  • Redundant – Why use it if it is already built into your application? Internal key management is built into most applications and cryptographic systems such as storage products and file-level encryption tools. External key management – for products that really need external support for good key security and proper separation of duties (SoD) – is provided by application libraries and database encryption products. Failover, backup, management interfaces, rotation, and cipher strength are all common features, so why centralize? Multiple services mean more interfaces to learn, but inherently provides SoD and focused policy management.
  • Cost – Central key management servers are standalone, dedicated products. They excel in areas such as key security, ease of use, key sharing, etc. But they are still an additional investment.
  • Policy Management – A single management console to manage the system sounds like a great convenience, but I don’t always want the same policies across dissimilar applications and use cases. In fact, I usually want different key lengths, different rotation schedules, and different ciphers, depending on the data I am protecting, and prefer the granularity to specify them at the level of an individual use case.
  • Single administration Console Having a single location to manage keys is conceptually useful. It may actually be useful if you have a very large number of users or must distribute keys and data across a large organization. Most of you reading this, however, work for small shops, and the one or two areas where you have deployed encryption do not require centralization. Few of you are at large enough organizations to worry about thousands of users each with hundreds of keys – and thus to need central key management to address data access issues across a dispersed environment.
  • Key rotation – Having a central key server to automate key management, especially the complexity of key rotation, is a common motivator for central services. Rotation, or key-cycling, is a common feature whereby key management products periodically issue new keys on the premise that with sufficient time and effort, someone will be able to discover the encryption keys in use. Theoretically you would issue a new key and then re-encrypt all data under the new key, but in practice it would take months of even years to re-encrypt everything, as the data sets are simply too large, and the media might even be off-line or off-site. In this scenario data is only re-encrypted under new keys opportunistically when it’s rewritten (perhaps also when it’s reread). But there is no guarantee that data will be re-encrypted. With every key rotation cycle, a new set of keys is generated, and the old ones must be retained to decrypt older data. Over time data will be encrypted under so many different keys that you must use a key manager just to keep track of what’s what. It’s a side effect of the encryption scheme, and for a modicum of extra security you get a bloated key server. Better to keep this compartmentalized than centralized.

Don’t go looking for central key management when external key management is all you need. Central key management is occasionally necessary – most often for existing systems with really bad built-in key management, geographically dispersed servers that require key sharing, or thousands of users each with multiple keys. A single point of management is veru much a secondary advantage, however, and should not drive your decisions. So why do you think you need it? What’s the advantage to you?

Share: