Encryption keys and

key management

Dwaine Snow
IBM Global Technical Leader - Cyber Resiliency
and Quantum-safe technology

In the coming years quantum computers will likely change the face of cyber security. Once quantum computers can
reliably factor products of large prime numbers (the basis of current cryptography), existing cyber defense mechanisms
will be rendered obsolete. While quantum computers are not strong enough (or stable enough) today to break into most
encrypted data files and systems using current encryption technologies, everyone expects that they will be in the not to
distant future. Updating current systems, solutions/software, and infrastructure to safeguard against these threats will
take time, so it is important that everyone start today to protect their current data and systems from the hackers who are
stealing data today with the intent of breaking into it tomorrow.

Quantum computing will enable great innovations in the future, but it will be accompanied by diverse risks. The potential
of quantum computers to break the current security of common activities in our daily lives could have severe
consequences. The quantum cybersecurity threat forebodes data breaches of sensitive health and financial personal
data, challenges to the integrity of digital assets, and breaking the fundamental cryptography underpinning
cryptocurrencies.

According to a Deloitte poll (https://www.slideshare.net/DeloitteUS/harvest -now-decrypt-later-attacks-pose-a-security-

concern-as-organizations-consider-implications-of-quantum -computing/DeloitteUS/harvest-now-decrypt-later-attacks-
pose-a-security-concern-as-organizations-consider-implications-of-quantum-computing), just over half of its surveyed
professionals (50.2%) believe that their organizations are at risk for "harvest now, decrypt later" (or HNDL) cybersecurity
attacks. This refers to an attack where threat actors collect encrypted data from target organizations today, fully
anticipating that data can be decrypted later when quantum computing reaches a maturity level capable of rendering
many publicly utilized cryptographic algorithms like Rivest –Shamir–Adleman (RSA) entirely obsolete. HNDL poses a risk
to enterprises, banks, intelligence agencies, and even military capabilities – nothing will be safe from sophisticated threat
actors equipped with advanced quantum computers.

Although the initial weight of resources required to conduct such an attack makes it unlikely to target your average
enterprise, accelerating advancements in technology and volumes of data being regularly transmitted under encryption
means we can anticipate them to become more likely in the future. In fact, it’s entirely possible such attacks have
already taken place, and the targeted organizations lack the sophisticated capabilities to detect them. Despite the risk,
nearly 20% of enterprises appear to be taking a “wait and see” approach.

Back in 1994, Peter Shor developed a theoretical quantum algorithm to find the prime factors of a large integer. While
important research, it was not considered an immediate risk, given the lack of the technology to implement quantum
computers. Implementation of a practical quantum computer will render most current asymmetric encryption methods
unsafe, such as RSA, Diffie-Hellman (DH), and Elliptic Curve Cryptography (ECC).

Now, however, quantum computing is much closer to becoming mainstream. In 2021, IDC estimated that by 2027, the
market for quantum computing may grow to $8.6 billion, a 50% compound annual growth rate since its value of $412
million in 2020. It poses a “Quantum Threat,” a match for the complicated math problems previously unbeatable by
classic computers. The world's data, currently protected by asymmetric cryptography algorithms such as RSA, DH and
ECC, will soon become readable – and subsequently, easy for cybercriminals to infiltrate and bring down global digital
security.

1
 Encryption Keys

This slide is just an introduction to the following slides that discuss encryption keys, this slide needs no speaker notes.

2
 Keys and key management

In most cases the encryption algorithm Key management is the complete set
is not secret, BUT the key is of operations necessary to create,
maintain, protect, and control the
Key s need to be kept safe and secure or use of cryptographic keys
the data can f all into the wrong hands
But, they also need to be available for
authorized users

Keys are a vital part of any security system. They do everything from data encryption and decryption to user
authentication. The compromise of any cryptographic key could lead to the collapse of an organization’s entire
security infrastructure, allowing the attacker to decrypt sensitive data, authenticate themselves as privileged users, or
give themselves access to other sources of classified information. Luckily, proper management of keys and their
related components can ensure the safety of confidential information. Key Management is the process of putting
certain standards in place to ensure the security of cryptographic keys in an organization. Key Management deal with
the creation, exchange, storage, deletion, and refreshing of keys. They also deal with the members access of the keys.

Key management forms the basis of all data security. Data is encrypted and decrypted via the use of encryption keys,
which means the loss or compromise of any encryption key would invalidate the data security measures put into
place. Keys also ensure the safe transmission of data across an Internet connection. With authentication methods, like
code signing, attackers could pretend to be a trusted service like IBM, while giving victim’s computers malware, if they
steal a poorly protected key. Keys provide compliance with certain standards and regulations to ensure companies are
using best practices when protecting cryptographic keys. Well protected keys are only accessible by users who need
them.

Modern cryptography is based on Kerckhoffs's principle (https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle)

which states that “A cryptosystem should be secure even if everything about the system, except the key, is public
knowledge. This is because with the knowledge that we have, this is really the only reasonable way to approach
serious, secure cryptosystem design.”

All encryption involves three aspects: the data to be protected, the algorithm or cipher that transforms the data so that
it’s unreadable, and the key, usually a random number. In most cases, the algorithm is not a secret, but the key
certainly is. Just as in the physical world, it’s the individual key in your pocket that makes your front door lock different
from your neighbor’s even if both locks operate in exactly the same way. Because the key is what
makes the encryption process unique, the key becomes the secret to making the process reversible.

With the right keys, any attacker can access the underlying data. Mismanagement and human error can result in keys
falling into the wrong hands. Conversely, organizations need to ensure that keys are always available to an authorized
user when required. For data retrieval or full-blown disaster recovery, organizations may find themselves relying
completely on rapidly accessing keys in order to unlock previously encrypted information.

3
 Key management
is crucial because of…

Security Compromised keys leads to compromised data

Usability Too much complexity in key management limits the usage of encryption

Availability Data must always be available for authorized users

Compatibility across applications and languages, storage types,

Heterogeneity
and all environments – on premises and on the cloud

Ensuring compliance with regulations such as

Governance
SOC 2, PCI DSS, and GDPR

The security of encryption keys is vital to the confidentiality of the data that they protect. A threat actor w ith access to keys can read sensitive data
and potentially even generate valid signatures for false or modified records. It’s not uncommon for enterprises to place their encryption keys at risk
by putting excessively restrictive permissions on employee access, which makes the data secure but inaccessible, or, more likely, storing encryption
keys in a w ay that makes them convenient and easy to access, which makes the system vulnerable to threat actors.

Usability: Managing keys in a secure way, is extremely complex, especially w hen doing so across dozens or hundreds of applications. In o rder to
minimize the impact to product schedules (and dev team’s anxiety levels), control over certain key management settings or req uirements is put in the
hands of the customers. But customers typically follow the path of least resistance and don’t alw ays understand how to securely create, store, and
access keys. This can lead to vulnerabilities that endanger the security of customer data w hen passwords and keys are reused, or keys are
insecurely stored and do not have robust access rules in place to enforce authorization and authentication.

Availability: Encryption is designed to make it impossible to access encrypted data without access to the associated encryption key. This means
that even the legitimate ow ner of the data needs the key to access it. As a result, key management needs to offer robust redundancy. Designing key
management systems that are accessible and secure is extremely difficult.

In order to have keys available w hen needed, developers may make choices that sacrifice security for the sake of convenience, such as using
embedded or hardcoded keys, setting w eak passwords or failing to follow industry standards for hardware security module (HSM) redundancy.

Heterogeneity: An enterprise’s network environment is likely composed of a variety of different systems, each with different encryption key
requirements and protocols. Additionally, each department w ithin an organization may have their ow n systems and processes for managing and
securing encryption keys. But the proper management of encryption keys for all of an organization’s systems is essential for security. Due to the
interconnectedness of these systems, a compromised key on one system could enable access to data from another, violating trus t boundaries and
security guarantees of data compartmentalization.

Governance: The regulatory landscape is quickly grow ing more complex. The implementation of the EU’s General Data Protection Regulation
spurred the creation of a number of national and state-level privacy law s like the California Consumer Privacy Act. These new regulations joined
existing law s like PCI DSS, HIPAA and SOX as w ell as the requirements set by an organization’s internal security policy.

Improper management of encryption keys is a common problem, and a poor key management system can have a number of negative ef fects,
including increased likelihood of data breach or loss, failure to meet compliance audit requirements and an encryption system that may be rendered
unusable or unmaintainable. All of these potential impacts carry costs to an organization in the form of regulatory penalties , reputational damage,
and the overhead of achieving recertification and the costs associated with lost productivity and repeated security reviews. For these reasons, it is
often more cost-effective to invest in getting an encryption key management system right the first time than paying the price w hen it fails. Effectively
managing keys requires a thorough know ledge of the risks and access to the correct tools.

The use of encryption has become ubiquitous in virtually all our digital interactions, w hether we’re logging into a banking app, making a purchase, or
checking email. While encryption is vital, it isn’t enough if underlying cryptographic keys are vulnerable to attackers. How e ver, too often, the
protection of cryptographic keys is overlooked, leaving sensitive assets and services exposed.

Encryption key management is administering the full lifecycle of cryptographic keys. This includes: generating, using, storin g, archiving, and deleting
of keys. Protection of the encryption keys includes limiting access to the keys physically, logically, and through user/role access.

4
 Key management lifecycle

Organizations tend to use several hundred or even thousands of encryption keys. Proper and secure storage of these keys can
become a massive problem, especially when you require access to such keys on an immediate basis. Hence is the need for a
centralized key management system.

The best practice for an organization would be to have an in-house key management service. However, oftentimes this may not be
possible and the use of third-party services may be adopted for a more sophisticated approach. Such keys are usually stored away
from encrypted data. This serves as an added advantage in the case of a data breach, as the encryption keys is unlikely to ge t
compromised.

The centralized process is also beneficial in terms of processing, as the encryption -decryption process happens locally, but the
storage, rotation, generation, etc. happens away from the actual location of the data.

Encryption key management refers to the administration and protection of the keys used to encrypt and decrypt data. This incl udes
the generation (creation and registration), storage, distribution, and replacement of encryption keys, as well as the procedu res for
using them.

The goal of encryption key management is to ensure the encrypted data’s confidentiality , integrity , and authenticity – minimizing the
risks associated with key loss, theft, or misuse. This requires careful planning, secure systems, and well -defined policies and
procedures, as the security of the encrypted data is directly dependent on the safety of the encryption keys.

The encryption key management lifecycle is the process of securely creating, storing, distributing, using, replacing, backing up,
monitoring, and destroying cryptographic keys. It includes the following stages:

• Key Creation: Creating/generating new encryption keys using secure methods, such as random number generators.
• Key Registration: Entering the key into the management system and establishing trust between entities that share keys.
• Key Storage: Securely storing encryption keys, typically using encrypted repositories such as hardware security modules (HSMs)
or encrypted databases.
• Key Distribution: Securely distributing encryption keys to authorized individuals or systems.
• Key Use: The process of using encryption keys to encrypt and decrypt data and to sign and verify digital signatures securely.
• Key Replacement: Regularly replacing encryption keys to reduce the risk of exposure.
• Key Backup: The process of regularly backing up encryption keys to ensure that they can be recovered in case of loss or
damage.
• Key Monitoring: The process of monitoring the use of encryption keys to detect and respond to potential security incidents.
• Key Destruction: Securely destroying encryption keys when no longer needed to reduce the risk of exposure.

Each of these stages is critical to the effective and secure management of cryptographic keys and must be carefully planned a nd
executed to ensure the security of the encrypted data. The encryption key management lifecycle provides a structured approach to
managing cryptographic keys and helps organizations ensure the protection and confidentiality of their sensitive data.

5
 Key management lifecycle

A new key life cycle always starts with key generation. The main challenge is to ensure that key generation produces
unpredictable keys via a reliable source of random numbers. If the key generation process isn’t truly random, a new key can b e
predicted from knowledge of previous keys or the key generation process itself. The ability to make predictions dramatically
reduces the number of combinations to test and makes cracking a key more likely.

Modern cryptographic systems include symmetric-key algorithms (such as DES and AES) and public-key algorithms (such as
RSA). Symmetric-key algorithms use a single shared key; keeping data secret requires keeping this key secret. Public -key
algorithms use a public key and a private key. The public key is made available to anyone (often by means of a digital certif icate).
A sender encrypts data with the receiver's public key; only the holder of the private key can decrypt this data.

Since public-key algorithms tend to be much slower than symmetric key algorithms, modern systems such as TLS and SSH use a
combination of the two: one party receives the other's public key and encrypts a small piece of data (either a symmetric key or
some data used to generate it). The remainder of the conversation uses a (typically faster) symmetric -key algorithm for
encryption.

Computer cryptography uses integers for keys. In some cases keys are randomly generated using a random number generator
(RNG) or pseudorandom number generator (PRNG). A PRNG is a computer algorithm that produces data that appears random
under analysis. PRNGs that use system entropy to seed data generally produce better results, since this makes the initial
conditions of the PRNG much more difficult for an attacker to guess. Another way to generate randomness is to utilize informa tion
outside the system. Many modern protocols are designed to have forward secrecy, which requires generating a fresh new shared
key for each session.

A key on its own is just a useless number. Before a key becomes useful, it must be registered or associated with a particular
user, system, application, or policy. Typically, the strength and nature of this association determines the value of the key. For
example, a key tied to an identity and used for the purposes of authentication or signing documents is often associated with a
definition of that identity in the form of a digital certificate. The mathematical link between the secret (private) key and the public
key contained with the digital certificate, combined with the trustworthiness of the authority that issued the certificate, d efines the
strength of that association.

Whether keys are in the pre-operational or operational state, they need to be stored securely and, ideally, nowhere near the data
that they protect. To do so would be like slapping a sticky note with your Amazon.com password on your monitor and labelling it
“My Amazon.com Password”. You just don’t do that.

Pre-operational keys can be stored in a physical safe, electronically on a memory device, on optical media, or even a paper
printout — all safe and all offline. Operational keys on the other hand need to be accessible in real time, online, and are ofte n
stored within live systems. To store these keys securely, they’re often encrypted by, you guessed it, more keys. This raises the
obvious question of how well protected are the key encryption keys (KEK) or wrapping keys. This cycle can go on for many leve ls
of protection, creating a hierarchy of keys. No matter how many layers of encryption are applied to protect operational keys, the
KEK must be stored somewhere safe and, ideally, that means in dedicated hardware.

You may be tempted to think it’s safe to hide a key, buried in the massive amount of data stored on a disk drive, memory chip , or
backup tape, but you’d be wrong. Unlike the rest of the data being stored on these devices, a key has one special property: I t’s a
perfectly random number. This very randomness can make it stand out like a beacon. If you use the right tool, you can easily
locate a key on a hard drive or in the contents of memory chip. You can attempt to obscure the key or break it into fragments , but
you’re really only delaying the inevitable. To be truly secure, you should store the key in a way that is inaccessible to mal icious
software and other scanning tools.

6
 To resolve this issue, you may wish to establish a safe cryptographic zone, independent of the host
computer or server and outside the scope of the operating system.

6
 Key management lifecycle

Any key management system must address the secure transmission of keys from their place of storage or generation to
the application or device requiring them. A secure link or process for sending the key is essential. The challenge is
validating the identity of the person or application requesting the key and approving the request. There’s little point in
safely storing a key if you are going to give it out to anyone that asks for it. Similarly, the risk of accepting keys from
untrusted sources is equally apparent.

The registration or enrollment problem — the task of establishing trust between entities that share keys — can become
one of the costliest aspects of key management, particularly in large-scale systems. Situations deserving serious
consideration include those where entities are dispersed geographically or where multi -factor authentication and/or
frequent renewal of authentication credentials is required.

If the same key is used over a long period, the risk of that key being compromised increases. Correspondingly, the
longer a key is used, the amount of data it’s protecting increases and there- fore, so does its value to an attacker. The
risks multiply as time goes by and the prize gets richer — the available window to crack any one key increases along
with the potential for leakage of critical information that helps the attackers with insider knowledge. Companies must
minimize these risks by periodically refreshing, or rotating, keys as often as their risk -management strategy and
operational constraints allow them. It’s a classic trade-off of risk mitigation versus cost.

As with any backup system, backing up keys protects both the user and the company in the event that a key is lost. To
safeguard against the loss or unintentional destruction of a key, certain keys must be replicated and stored offline or on
an offsite backup. Mechanisms for regular synchronization of any backups with the primary key store are important.
Rigorous controls must be in place to prevent misuse of the backup, but having a backup is vital.

In some cases, key backup may not be appropriate. For example, if keys are used to create digital signatures intended
to carry legal weight, it’s important that only the authorized signer have access to the signing key. The mere existence of
a copy of that key casts doubt on who really signed the document. Similarly, in the context of encryption, if the
destruction of a key is intended to serve as proof of the destruction of the original data, proving that all backups of the
key are destroyed becomes necessary; otherwise, asserting that the data really is unrecoverable becomes impossible.

7
 Key management lifecycle

Whenever keys are backed up or archived, there is the challenge of defining the key recovery policy — who can request
a recovery of the keying material and under what conditions the recovery process should be carried out. For example,
recovery may be required to happen in a physically secure, offline facility under specific supervision procedures. Often,
key recovery, like many recovery scenarios, is performed with some urgency because systems have gone down
following an emergency, or a forensic request requires timely delivery of information. Recovery approval procedures and
escalation policies need to be predefined and followed at a moment’s notice. Strong auditing functions need to be in
place to ensure the keying material is recovered only by pre-approved entities and that the appropriate procedures have
been followed.

Any compromised key — or even one suspected of compromise — must be revoked and replaced. The potential
damage resulting from a compromise can be widespread, and restoring security can be both complex and expensive,
particularly where keys are shared, where they affect many users, or where they’re tied to physical tokens that may now
need to be replaced. As a PKI-based example, the compromise of an offline root Certificate Authority or online issuing
Certificate Authority private key results in the need to re-create public/private key pairs and re-issue certificates to all the
users/devices that lie underneath these CAs in the issuing hierarchy. The challenge is communicating that a key has
been revoked and providing an escalation path when a key becomes unavailable and needs to be replaced, potentially
bringing business operations to a halt if many users or devices are affected.

When a key reaches the end of its defined operational life, it should be removed from service, potentially leading to the
destruction phase. However, in many cases, it may be necessary to suspend the key from use but not destroy it. For
example, following a key rotation, an expired key that no longer performs encryption may be required to decrypt data
that it previously encrypted unless that data has been entirely rekeyed.

A key should be destroyed when there’s no need to preserve the use of that key. In all cases, proving that the key has
been deleted, including backups, is important. This means you need to have had control of the keys since their creation
and sufficient audit trails to know explicitly when and where copies and backups were made — impossible to determine
in retrospect.

8
 Native key Localized key Centralized key
management tools management management

Utilize the basic key

platforms
management capabilities that
are inherent in the individual
encryption offering.

Most organizations adopt

Three main cryptography incrementally to

solve specific security
requirements, addressing
types of key individual points of risk,
external mandates, or access
management control requirements.
Common examples include:

• The us e of TLS/SSL on
ex ternally fac ing Web
s erv ers
• VPNs for remote ac c es s
• Data/file enc ry ption on
laptops or tape/dis k driv es
• Databas e enc ry ption
• Spec ialis t s ituations , s uc h
as POS or ATM network s

Many commercial products used in these situations require keys to be managed through at least some of the phases of
the key life cycle, and they include software functionality to handle some or all of those tasks. The emphasis, policies,
and general security properties of these key management utilities will differ enormously among products, and it’s fair to
say that some are not much more than an afterthought. A good analogy is the numerous remote controls in a home
theatre set-up. They all perform similar functions that skew toward the specific device they’re designed to control. The
result is a high level of inconsistency, which, in a home theatre set -up with multiple controllers, is nothing more than
frustrating, but in a corporate IT setting, drives up cost and complexity and, because we’re talking about security,
introduces risk.

9
 Native key Localized key Centralized key
management tools management management

Utilize the basic key

platforms
management capabilities that
All management aspects
are inherent in the individual
associated with the key life
encryption offering.
cycle should be performed on
Most organizations adopt a secure platform that
provides some level of
Three main cryptography incrementally to
solve specific security physical and logical
protection for the keys and
requirements, addressing
types of key individual points of risk,
the processes that utilize and
manage those keys. The
external mandates, or access
management control requirements.
Common examples include:
ability to create an isolated or
“trusted” zone for
cryptographic functions is
• The us e of TLS/SSL on best achieved with dedicated
ex ternally fac ing Web cryptographic hardware.
s erv ers
• VPNs for remote ac c es s
• Data/file enc ry ption on
laptops or tape/dis k driv es
• Databas e enc ry ption
• Spec ialis t s ituations , s uc h
as POS or ATM network s

Unlike native key management tools that are delivered as part of the softw are application itself, the use of a separate hardw are- based key
management platform overcomes the inherent w eak- nesses of softw are-based cryptography. Using an independent security platform for
key management also creates a pow erful separation betw een the tasks of managing the keys and managing the applications that use those
keys. The notion of “separation of duties” to mitigate the threat of a single super -user is a common best practice in defining key
management policies and is strongly recommended in security standards such as PCI DSS.

When deciding to utilize hardw are key management devices, you have different options available:

Hardw are Security Module (HSM): The use of HSMs is a w ell-established approach for protecting applications in a variety of envir onments.
Mandated in government and certain financial/payment markets for decades, and now used to protect a w ide range of applications including
cloud, IoT, blockchain, and more, HSMs provide the follow ing capabilities:

• Protect cryptographic keys and perform various cryptographic functions in a secure tamper-resistant hardw are environment.
• Overcome the threat of softw are-based attacks and provide robust tools to enforce key management policies across the life cycle.
• Provide a simple mechanism for introducing strong authentication for key management administrators.
• Establish and enforce pow erful dual controls and separation of duty schemes w here multiple administrators can mutually supervise key
management activities.
• Incorporate high-speed cryptographic processors to improve performance, remove processing bottlenecks, and increase system
capacity.

HSMs are marketed in a variety of form factors to suit different deployment needs. The most common examples are

• Netw ork attached appliances: These devices essentially provide a netw ork-based service that a number of applications can access in
order to have cryptographic operations performed on their behalf (for example, a shared signing or encryption service). There are a
number of advantages in taking this approach: Keys can be managed in one location rather than on disparate application servers,
yielding many of the benefits of centralized key management systems; HSM capacity can be shared across multiple application
instances, improving efficiency and resilience; and this service-oriented or abstracted model for deploying HSMs fits very w ell w ith
application virtualization and containers.
• Embedded plugin cards: Typically, these devices follow the PCIe interface and form factor definition, plugging directly into a peripherals
slot on the server mother- board. They are ideally suited to situations w here HSM resources need to be dedicated to a single ser ver
platform rather than shared over a netw ork. Typically, usage is driven by a need to maximize performance or to simplify deployment,
w here the HSM can be delivered to a remote location embedded w ithin a pre-configured system.
• Portable security devices: These devices are physically smaller and connect via a USB interface to the application host, w hich may be a
server, desktop, or laptop computer. They are ideally suited to offline situations w here the HSM is stored in a physical safew hen not in
use or w here the HSM is required to be portable, to be used by an individual performing occasional tasks, such as code signing,
application development, or remote system management and authorization.

Trusted Platform Module (TPM): Whereas an HSM is a dedicated security module aimed at server -based applications, a TPM is typically a
dedicated security chip that fits as a motherboard component inside a laptop or desktop computer, creating a “root of trust” similar to the
w ay that a SIM card w orks in a mobile phone. The TPM chip provides security services, such as key generation, encryption, dec ryption, and
secure key storage that can be exploited by applications running on the host device. TPMs have the potential to act as a standardized w ay
to securely protect keys on desktop and laptop machines in the event they are stolen or otherw ise compromised. Although most commercial
grade machines include this functionality, the actual adoption by end users and the organizations they w ork for has been limited.

Smart card: A smart card or chip card is a credit card–sized electronic device w ith a built-in microprocessor and memory that can act as a
dedicated system for storing keys and performing low -speed cryptographic processes. Smart cards can be accessed by applications w hen
inserted into a card reader, typically a USB connected peripheral. The small size of a smart card is ideally suited for situa tions w here keys
need to be protected w ithin a portable “w allet” (for example, keys used for user identification and encryption keys for data stored on PCs).

10
 Native key
management tools
Utilize the basic key
management capabilities that
are inherent in the individual
encryption offering.
Most organizations adopt
Three main cryptography incrementally to
solve specific security
requirements, addressing
types of key individual points of risk,
Localized key Centralized key
management management
platforms Two s ubtly different
approac hes ex is t to
All management aspects
c entraliz ed k ey management,
associated with the key life
the differenc e hinging on
cycle should be performed on
where authority really lies .
a secure platform that
provides some level of
physical and logical
protection for the keys and
In many c as es , this c omes
down to where the k ey life
the processes that utilize and
manage those keys. The
c y c le was initiated.

external mandates, or access

management control requirements.
Common examples include:
ability to create an isolated or
“trusted” zone for
cryptographic functions is
• The us e of TLS/SSL on best achieved with dedicated
ex ternally fac ing Web cryptographic hardware.
s erv ers
• VPNs for remote ac c es s
• Data/file enc ry ption on
laptops or tape/dis k driv es
• Databas e enc ry ption
• Spec ialis t s ituations , s uc h
as POS or ATM network s

As organizations deploy ever-increasing numbers of encryption solutions, they find themselves managing inconsistent policies,
different levels of protection, and experience escalating costs. When the pain gets sufficiently high, the best way through t he
maze is often to transition into a centralized key management model. In this case, and in contrast to the use of Hardware Sec urity
Modules (HSMs) described earlier, the key management system performs only key management tasks, acting on behalf of other
systems that perform cryptographic operations using those keys.

The end point driven approach: The simplest approach is when individual applications or end points retain responsibility for many
aspects of the key life cycle. Keys are generated locally by the application or end point that intends to use them. Contextua l
knowledge about what the key is used for and what policies apply to the key tends to remain at the end point. In this case, t he key
management system acts as a trusted repository or vault for keys, storing keys (and metadata) on behalf of the end points and
releasing the key to the end point on request.

The manager driven approach: In this more sophisticated case, the key management system assumes responsibility for the entire
life cycle and literally becomes the “key authority.” Keys and their associated policies are centrally generated (sometimes w ith the
use of an HSM as a source of certified random keys) and stored. Keys are distributed to suitably authenticated and authorized
applications or end points on request where keys are used but not retained. The management system is responsible for key
recovery, revocation, and destruction.

A number of significant benefits exist in using a centralized key management system. These include:

• Unified key management and encryption policies:

• Consistent policies can be established and uniformly updated without the need to train local administrators or worse still fl y
people around the world.
• System-wide key revocation: A central key management system is well placed to affect system -wide changes. For example, if
a key has been compromised — even suspected of compromise — the key must be revoked. A centralized key management
system, in theory, can enable system -wide revocation of all the instances where a given key has been in use. It’s never quite
that simple but it does mitigate the risk and cost of making changes region by region or even device by device.
• Single point to protect: In a centralized approach, you only have to protect one key repository. Although keys are still used at
the end points, they’re only retained on a temporary basis, alleviating concerns over large numbers of historic keys
accumulating at end points and potentially subject to misuse by local administrators.
• Automation to lower costs: As scale increases, the case for automation becomes overwhelming. Centralized key management
reduces the number of expert personnel needed to run disparate systems, freeing up resources to perform other tasks.
• Consolidated audit information: By providing a system - wide auditing capability, a centralized approach to key management
avoids the need to extract and consolidate audit logs across different end points, application silos, and key management
utilities.
• Single point of recovery: Key recovery tends to occur hurriedly — either the organization is in general disaster recovery mode,
or an urgent need for forensic analysis was requested (such as a request from law enforcement to review encrypted
information). In most cases, it’s easier to access and recover keys from a single repository than from geographically
distributed end points.
• Convenient separation of duty: Compliance and security policies increasingly require that a clear separation of duties exists in
critical applications — the need to ensure that no single administrator or privileged user can subvert the system. The process
of abstracting key management from the application or end point that uses the keys creates a natural separation and, by
centralizing the key management function, creates a “keeper of the keys.” Sensitive information can be read only by users or
applications granted access to the encrypted data by the application administrator and given access to the keys to unlock tha t
data by the key manager.
• Mobility of keys: As more sensitive information is encrypted, keys will increasingly be moved around the organization in orde r
to ensure that keys are available to systems or organizations that receive the information and need to decrypt it. A centrali zed
key management system can be used to tackle this challenge by acting as a broker of keys, linking different systems and
11
 organizational structures.

11
 Key use

Restrict keys to a single purpose

Keep key s in a separate, isolated
env ironment
Enf orce key policies the same as you
would to protect the keys themselves

When keys are in an operational state, in principle they can be used for many things. Good security practice is to restrict
the use of a single key to only one purpose, such as encryption, authentication, key wrapping, or creating digital
signatures. The use of the same key for two different cryptographic processes may weaken the security provided by one
or both processes. Key usage policies must consider whether certain uses of a key conflict with one another. For the
same reason that keys should be stored in an isolated or dedicated environment, it logically follows that they should be
used in a safe environment; otherwise, keys are exposed every time they’re used. Generally, access to a key should be
on a “need to know” basis or perhaps more appropriately, a “need to use” basis, in order to avoid the unnecessary
proliferation of keys.

Defining and enforcing policies affects every stage of the key management life cycle. Each key or group of keys needs
to be governed by an individual usage policy defining which device, group of devices, or types of application can request
it, and what operations that device or application can perform — for example, encrypt, decrypt, or sign. In addition,
policies may dictate additional requirements for higher levels of authorization to release a key after it has been
requested or to recover the key in case of loss.

Adopt the same level of security to the enforcement of key management policies as you would to protect the keys
themselves. In the end, if attackers can subvert the process that enforces the key management policy more easily than
attack the keys directly, they will likely take the path of least resistance. As with any security system, attackers look for a
weak link, and all phases of the key life cycle provide opportunities to expose a weakness. Enforcing a key management
policy is as much about establishing consistency as it is about focusing on the threats at any one stage in the life cycle.

12