Separating Encryption and Key Management

In our previous blog posting, we explored the shortcomings of software-based full disk encryption (FDE) and made the case for switching to self-encrypting drives (SED) in the long run. One of the fundamental principles of FDE, whether it is hardware or software-based, is to separate the FDE operations from the encryption key management functions. In fact, this same principle also applies to other forms of storage encryption, such as cloud-based encryption. Increasingly this principle is being treated as a generally recommended practice for today and not just an ideal to aspire to in the future. For more insights on the standards-based work being done on separating key management and associated authentication from encryption functions, read our blog “Common Criteria collaborative Protection Profiles for FDE”.

The Motivation For Separation

The primary motivation for separating storage encryption and key management functions is twofold:

  • It enables the use of a single key manager for all platforms.
  • It allows individual encryption solutions to be selected and used for each case where storage encryption is needed.

Let’s examine these in turn.

By default, most forms of storage encryption have their own integrated key management functionality. Because this functionality is truly part of the storage encryption solution, it generally means that the storage encryption key can’t be used for any other enterprise encryption needs. So enterprises have yet more encryption keys to manage, and users have yet another authentication instance to deal with.

If the key management functionality is separate from the storage encryption, then that key management can be used for purposes other than storage encryption. Ideally the key management function can be used to manage all of a user’s encryption keys throughout an enterprise, regardless of platform. This would include keys for local storage (e.g., software-based FDE, SED, removable media), network storage (e.g., enterprise file servers, and files and folders on those servers), and cloud storage, or even a single key leveraged for multiple purposes. By consolidating key management functions throughout the enterprise and reducing the number of keys to be managed, overall system usability is increased and management costs are decreased.

The second aspect of the primary motivation for separating storage encryption and key management functions is being able to select individual encryption solutions for each storage encryption case. In other words, instead of having to select a single product to handle both storage encryption and key management, an organization is free to select separate products that each specialize in these respective functions. For example, when FDE is handled by the drive (in hardware) or the operating system (in software), it can be beneficial to have something else dealing with key management. Drive manufacturers and operating system vendors are unlikely to be experts in key management because it’s not core to what they do.

There is a secondary reason for separating storage encryption and key management: avoiding a single point of compromise. If encryption and key management are happening together, then a single compromise or a malicious insider could easily grant someone unauthorized access to both the encrypted data and the corresponding key. This, in turn, would allow that party to apply the key to the data and access the decrypted contents. Separating encryption and key management helps mitigate this risk.

Having a single point of compromise is particularly concerning to many organizations that have migrated sensitive data to the cloud. If the key management functions, particularly key storage, are happening within the cloud alongside the storage encryption functions themselves, then it may be trivial for a malicious insider, such as a system administrator from the cloud services provider, to gain unauthorized access to encryption keys and decrypt sensitive data. To prevent such incidents in cloud environments, it is strongly recommended that private or secret shared keys for cloud encryption functions be stored and managed locally – within the enterprise’s own facilities – and not within the cloud itself. This is only possible if encryption functionality and key management are separated.

Authentication on the Endpoint

Separating storage encryption and key management functions means that the authentication for storage encryption is separated from the encryption function as well. Many people don’t realize how closely related authentication and encryption keys are. When a user provides authentication credentials, such as a password, those credentials are being used to gain access to the user’s private or secret shared encryption key.

Just as it’s important to separate key management from encryption functions, it’s equally important to separate authentication from encryption functions. This is particularly true for remote environments, such as servers within the organization’s facilities and cloud-based applications. Authentication (and key management in general) should be occurring on the user’s endpoint, such as a desktop, laptop, or mobile device, and not the remote system where the encryption itself is happening. Other reasons for separating authentication from encryption functions include the following:

  • Provides a uniform user experience across platforms and encryption types
  • Allows the user to only authenticate once, yet get the keys to access authorized data wherever it is stored
  • Supports more sophisticated and usable authentication methods (such as smartcards) than what the encryption supplier happens to support

Consider the cloud-based example discussed earlier. If authentication is happening within the cloud, for example, then it’s much easier for a malicious insider to take advantage of the situation and grab the credentials and/or the associated encryption key. If authentication is happening within the user’s endpoint device, then an attacker would have to compromise both that device and the cloud-based application in order to gain unauthorized access to the encrypted data.


Storage encryption and associated key management functions should be separated. This allows a single key management solution to be used for all of the organization’s platforms. At the same time, it also enables the organization to select best-of-breed storage encryption solutions and key management solutions instead of compromising by selecting one product that provides both. Because key management and authentication are so closely related, authentication should also be performed separately from storage encryption, particularly for remote architectures, such as traditional servers or cloud instances. This reduces the likelihood that a single compromise, especially from a malicious insider, can lead to unauthorized access to sensitive data protected by storage encryption technologies.


Karen Scarfone
Karen Scarfone is the co-author of this blog. She is a former senior computer scientist for the National Institute of Standards and Technology (NIST), and has over 15 years of experience across a wide variety of security domains.
Previous Post
5 Myths About Data Encryption and Decryption
Next Post
The Worst Compliance & Data Protection Advice You’re Getting

Related Posts

Computer Forensics and Self-Encrypting Drives

In my last blog on computer forensics I addressed the question: does software Full Disk Encryption (FDE) Thwart Computer Forensics?   To recap, a software encrypted drive could prevent effective forensics. However, if you have enterprise key management and forensics software…

Improving Forensic Recovery for SEDs

This week WinMagic announced that SecureDoc offers new interoperability with Guidance Software’s EnCase Forensic product – specifically – forensic data recovery on self-encrypting drives (SEDs). (more…)
Read more

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

Contact Us

This will close in 0 seconds