The NIST defines key management as “the process of managing a key throughout its lifecycle, including its secure generation, storage, distribution, use, and destruction.” Key management encompasses all the work that goes into securely maintaining and using cryptographic keys within an organization.
Key management is a cornerstone of information security; if a key is compromised, it can result in data being stolen or lost forever. In this article, we’ll discuss types of keys, the key management lifecycle, security best practices, and more.
Types of Cryptographic Keys
There are dozens of subtypes of cryptographic keys, but they all fall into two broad categories: symmetric and asymmetric keys.
Under symmetric encryption, the same key encrypts and decrypts data.
For instance, a simple symmetric key might entail transposing the letters of a message five spaces in the alphabet. Under this system, you would encrypt ‘boy’ by moving each letters five letters forward, to produce the encrypted ‘gtd’. You would then decrypt this message by moving each letter five letters back, yielding the original message, ‘boy’. In this case, the same process is used to encrypt and decrypt the key; in this way, it is symmetric.
The Advanced Encryption Standard (AES) has been the gold standard algorithm for symmetric encryption since the National Institute of Standards and Technology (NIST) selected it in 2001. AES uses key sizes of 128, 192, and 256 bits to encrypt data. As a general rule, a longer key size makes for a stronger key. For added security, many symmetric encryption algorithms change keys frequently throughout the day.
Other symmetric ciphers include RC4, DES, and 3DES.
Under asymmetric encryption, two keys are used: a public key and a private key. There are multiple copies of the public key, and it is shared publicly, such as on a public certificate. But there is only one copy of the private key, and it is kept secret. Together, these two keys are called the key pair.
In some cases, data is encrypted with a public key and decrypted with the private key. This is how web traffic is encrypted via SSL: when a user goes to a website, they obtain the website’s public key from the site’s certificate. They then use that public key to encrypt data; this data can only be encrypted by the website’s private key.
Alternately, you might encrypt data with a private key. That data can then be decrypted by anyone with the public key. Because it was encrypted by that particular private key, you can be assured that there is only one possible source it could have come from.
Asymmetric keys fall into two additional subcategories: static and ephemeral. A static key is semi-permanent, and remains in use for some time. Ephemeral key pairs have a much shorter lifespan, and are created fresh for each session.
Asymmetric encryption algorithms include Rivest-Shamir-Adleman (RSA), which is the most widely used algorithm for public key encryption. Other common algorithms include the Digital Signature Algorithm (DSA) and the Diffie-Hellman protocol.
Key Exchanges & Session Keys
Asymmetric and symmetric cryptography are often used together in the form of a key exchange: asymmetric encryption is used to transfer a symmetric key, which is then used to decrypt the content itself for the duration of the session. This key is called the session key.
When you visit an HTTPS website, for instance, your browser obtains the website’s asymmetric public key from the website’s public certificate. Your browser then encrypts a symmetric session key using the website’s public key, and then sends it back to the website. The website uses its private key to decrypt and obtain the session key. Once both sides have the session key, they can then use symmetric encryption from there. This entire process is called an SSL handshake.
Key Lifecycle Management
Key management entails securing all stages of a key’s lifecycle: generation, distribution, storage, deactivation, and destruction. A key’s lifecycle might span years, or mere minutes – it all depends on how the key will be used.
The key lifecycle begins when a key is generated. At this stage, an encryption algorithm such as AES is used to create a key. The key’s size and lifespan both depend on how a key will be used.
Key generation typically relies on random number generators, which create pseudo-random numbers to use as the input to create unique keys. Some public key cryptography algorithms use elliptical curves to generate keys; this approach is called Elliptical Curve Cryptography, or ECC.
Keys can be created by hardware or software. The most secure way to generate keys is with a hardware security module (HSM) – essentially, a device designed to perform security tasks, such as creating and storing keys. You can also use a virtual key manager or a cloud service such as Microsoft Azure to create and store keys.
You can read more about key generation in NIST SP 800-133.
In key distribution, keys are securely transported from the key creator or owner to someone else who needs to use the key. Keys must be distributed with the utmost security, as you do not want unauthorized individuals to intercept a key and then exploit it against your organization.
Secret keys in transit should always be encrypted, and should never be transmitted in plaintext. Encrypting a key with another key is called key wrapping, whether used for storage or distribution. As a general rule, any key in storage or transit should be encrypted by a key of equal or greater cryptographic strength.
Public keys, on the other hand, are not kept secret. Instead, they are disseminated with the help of a public key infrastructure (PKI), which helps manage digital certificates. In this system, a certificate authority (CA) is a trusted company that issues and maintains the certificates, verifying the authenticity of public keys. These certificates are commonly distributed with software, such as web browsers and operating systems.
Key distribution can be manual or automated. For critical keys with long life cycles, it may make sense to manually oversee the distribution of keys. It makes less sense when distributing session keys at scale; if a website performs session handshakes with millions of users an hour, there’s no way the organization can manually create and distribute every session key.
The NIST provides more detailed recommendations for key distribution in Special Publication 800-57.
Cryptographic keys should also be stored securely. Just like when transmitting keys, stored keys should be encrypted by a key at least as strong as the key in question.
Keys should be stored in a cryptographic vault, such as on a hardware security module. Cloud services such as Microsoft Azure also provide key vaults for secure storage.
As a best practice, you should maintain a secure backup of any keys. If a key is lost, you lose access to any data the key is supposed to protect. Backing up keys is especially important for long-lifecycle keys used to store data-at-rest.
Cryptographic keys are often phased out in stages. A key’s ability to encrypt data may be deactivated, while the key still retains the ability to decrypt data. During this rollover period, data that the semi-deactivated key decrypts can only be reëncrypted by the new key that succeeds it.
An administrator might also revoke a key without destroying it just yet. That way, if it turns out the key is still needed to decrypt data, the administrator can reactivate it. This curtails the risk of losing data that can no longer be decrypted.
The NIST recommends that deactivated keys be kept in a secure archive. At all stages of the lifecycle, it remains imperative that keys be kept secure.
At a certain point, the time may come to destroy a key permanently. You’ll want to be as certain as possible that a key is no longer needed before you destroy it. Even then, it may be a good idea to retain a backup image, just in case the key is ever needed. Otherwise, any data encrypted by a destroyed key will be lost forever.
Best Practices for Cryptographic Key Security
Because keys are so vital to cybersecurity, it’s critical to keep them secure. As a starting point, strict access controls should limit access to keys based on the principle of least privilege. This means that no one should have access to a given key or key vault unless they need it to do their job. The fewer people have access to a key, the less risk there is that anyone will misuse it.
Separation of privileges can also bolster security; this means that related job duties are held by different people. The person who oversees key generation, for instance, ideally would not be the person that has to use those keys. You can even go a step further and split keys, dividing ownership of each part of the key. That means the two people who own each part of the split key would have to get together to use the key itself. This creates an added layer of security, as no one person acting alone can use the key.
You’ll also want to build accountability into your key management system. That means access to keys is tracked – so if someone generates, distributes, or uses a key, it all gets logged by the system. If anything goes wrong, the right accountability system will be able to trace the issue to its origin. And because any action involving a key is tracked, users cannot misuse a key without knowing that their actions could potentially be traced back to them.
Keys should be created and stored on hardware security modules (HSMs). These devices are specially made to keep keys secure throughout their lifecycle. Cloud services such as Microsoft Azure can be just as secure as your own HSM – as long as you trust the service provider, and make sure you follow their security policies closely.
Keys should not be made to last forever. As a general rule, the more frequently you rotate keys in and out of commission, the more secure the system will be. A key used to protect data-at-rest might have a lifespan of several months, or even a year or two. Keys used to protect data-in-transit should be rotated more regularly. In the case of session keys, a fresh key is generated for each session.
Finally, you’ll want to have a compromise recovery plan in place, just in case a key is compromised. This plan should include information on who to contact in event of a compromise, explicit policies concerning key revocation, and detailed recovery procedures such as the following:
- Assessing data that may have been impacted.
- Inspecting physical hardware.
- Revoking compromised keys.
- Securely creating and distributing replacement keys.
Certain compliance standards include requirements relevant to key management. In the payments industry, for instance, the PCI Data Security Standard regulates credit card transactions, requiring businesses to document cryptographic architecture, restrict access to cryptographic keys, and store these keys securely.
Other laws governing data security include the HIPAA HITECH act, which sets rules governing data security in the healthcare industry, as well as the Sarbanes-Oxley Act, which sets rules concerning corporate financial record keeping.
The National Institute of Standards and Technology (NIST) has published several pertinent documents, including their SP 800-57 series, which provides detailed recommendations and best practices pertaining to key management. These documents outline requirements U.S. federal agencies must follow, but they also include many general recommendations, useful to all kinds of organizations.
The Cloud Security Alliance, a non-profit organization that promotes secure cloud computing, publishes their own best practices document, titled Security Guidance for Critical Areas of Focus in Cloud Computing. On the subject of key management, the CSA emphasizes storing keys securely, limiting access to keys strictly on an as-needed basis, and maintaining backups of keys so that encrypted data is not lost if a key is compromised.