In large enterprises, multiple, separate, and possibly even incompatible encryption tools can be used unwittingly. The result can be thousands of encryption keys which all must be securely and reliably stored, protected, and retrieved. Sensitive data resides in multiple storage and device locations throughout an organization. This means keys must be managed in a practical, automated, and risk-mitigated way throughout their lifecycle, with only credentialed entities accessing them.
Download this free ebook to learn more about:
- Why encryption key management is the cornerstone of any enterprise encryption solution
- How to bundle encryption and key management to solve identity and access related workflows
- Using, sharing, and storing data in a variety of places controlled by the organization’s security policy
Why Key Management Is the Hard Part of Encryption
Encryption is well understood. Managing the keys is where enterprise programs come apart, because a key has to be generated, distributed, stored, rotated, retrieved and eventually retired, and every one of those steps is a place where access can be lost or granted to the wrong person.
The National Institute of Standards and Technology set out the expectations in NIST SP 800-57 Part 1, and federal and industry standards treat them as the baseline for any serious key management design.
The Three Principles NIST Asks For
Dual control means no single person can manage another person’s keys. Creating a key, distributing it and defining who may use it should require at least two people.
Separation of duties means different people control different parts of the process. Whoever creates and manages keys should not have access to the data those keys protect, and whoever can read the protected data should not be able to manage the keys.
Split knowledge applies wherever a key exists in the clear, usually during manual generation. More than one person should be needed to assemble or reassemble it.
Why This Requires an External Key Manager
None of the three can be achieved if keys are stored alongside the data they protect, and that is also what PCI DSS Section 3 rules out. Storing keys separately, under their own controls, is what makes dual control and separation of duties possible rather than notional.
Where Key Management Breaks Down at Scale
Large organizations rarely choose one encryption tool. They accumulate several, often without meaning to, and each one generates keys that have to be stored and retrieved reliably. Thousands of keys held in incompatible systems is the ordinary result.
Every implementation also expects a shared key to be agreed in advance, sensitive data sits across many devices and repositories at once, and key volume grows as the data lifecycle turns. Without a unified approach, overhead grows faster than coverage does.
What Seamless Key Management Looks Like
The practical test is whether users ever touch a key. A well-designed system keeps people away from keys, key rings and public or private key files entirely, and authorizes encryption at the owner or recipient level instead, which removes the key-sharing problem that traditional PKI deployments run into.
Underneath that, keys are held in each platform’s own secure storage, synchronized automatically between authenticated systems, issued and withdrawn through the directory the organization already uses for identity, and logged in a form that satisfies audit. Smartkey technology replaces passwords and PKI with long, unique symmetric keys that no user has to handle.
Audit is the quiet requirement underneath all of this. Encryption that cannot show who held which key, and when, satisfies the cryptography and fails the assessment. Reporting built for regulatory compliance, and integration with the SIEM tooling already in place, are what turn a key management design into evidence somebody else can check.