The fundamentals of FDE: Procuring full-disk encryption software

How is the FDE software deployed to end-user devices?

Most FDE products are from third parties, meaning they have a software component that needs to be installed on each device to be protected. However, some FDE products are built into operating systems or provided as part of an existing security product suite. In these cases, client installation may not be necessary.

Client installation is only a small part of the FDE deployment process, however. It is generally recommended to perform a full backup of any device before activating FDE so the data on the system is not lost if deployment fails.

The conversion of a hard drive from unencrypted to encrypted can take several hours and, in some cases, the device may be unusable while this is taking place. Between the time it takes for software installation and configuration, device backup and hard drive conversion, FDE deployment can mean considerable downtime for users.

Businesses should evaluate hard drive conversion features of FDE products to determine how long users will be affected, and see if the conversion can happen in the background (and if so, how performance may be impacted).

How usable and robust are the FDE product's management features?

Centralized management is key to a successful enterprise FDE deployment.

FDE capabilities built into OSes may have little or no centralized management, limiting their appeal. For those FDE products that do offer centralized management, scalability is critically important, especially for larger enterprises. Equally important is the ability for administrators to set FDE configuration options and ensure users cannot alter those options or disable or uninstall FDE software.

Credential management is another important, yet often overlooked, aspect of FDE management. Evaluators should test features such as cryptographic key rotation and password changes for devices (for both users and administrators), centralized patch and upgrade capabilities, and the effect of changes to encryption algorithms and key sizes.

Is the FDE product compatible with existing OSes and applications?

In some cases, there may be incompatibilities between the existing environment and the FDE software. A common side effect of incompatibility is the failure of FDE to protect devices that are in a hibernation or standby mode. Another common example is when FDE conflicts with applications that access the hard drive directly, such as disk utilities and certain asset management software.

Can the FDE software readily integrate with existing authentication services?

To perform pre-boot authentication (PBA) for FDE, it is often desirable to leverage existing authentication services, such as Active Directory or PKI-based products.

Administrators also need an authentication mechanism for FDE configuration and management. It is generally recommended to use multifactor authentication for FDE, so it is important that the FDE solution support the desired multifactor authentication technologies. Regardless of what authentication technologies are chosen, it's important that the FDE software be readily integrated with them.

What are the options for cryptographic key recovery?

Without a robust cryptographic key recovery capability, access to FDE-protected devices and the data they hold could be lost for many users. Key recovery is needed in case a user forgets authentication credentials, leaves the organization unexpectedly, or otherwise is not able to log in as usual.

Some organizations choose to have administrators perform all key recovery activities, while others prefer to emphasize self-service recovery. Be warned, however, that self-service recovery may be abused to allow attackers to gain unauthorized access by circumventing FDE protections. So it is important for FDE evaluators to consider not only what key recovery options are available, but the relative security and usability of each of those options.

Another important consideration for key recovery is the use of multifactor authentication.

Suppose a user who is away on business loses a cryptographic token, and therefore cannot boot their laptop. There are some FDE products that will allow a user in such a situation to temporarily use single-factor, password-based authentication; however, this violates security policies for many organizations. So admins would want this FDE feature disabled. Organizations evaluating FDE software or products should therefore pay particular attention to single-factor configurability.

How does the FDE product mitigate against brute-force password attacks?

Some attackers will try to guess FDE passwords -- for example, if they've stolen a cryptographic token but do not know its corresponding PIN.

In such instances, some, but not all, FDE products can respond appropriately when too many login attempts happen -- either by suspending FDE authentication attempts for a time period (e.g., 15 minutes) or by having an increasing delay between attempts. These approaches make brute-force attacks extremely difficult while supporting overall usability for users who inadvertently make a few authentication mistakes.

Another option, typically used in higher-security environments, is to wipe a device after a certain number of consecutive failed authentication attempts (e.g., 10). This prevents an attacker with virtually unlimited time from performing a brute-force attack.

However, while this protects data from being exposed, it can also negatively impact a user who is having trouble remembering their password. Also, a malicious party could wipe a device simply by issuing several failed authentication attempts. So while a hacker may not be able to access a user's device, they can certainly make life difficult for that user.

How robust is the FDE product's cryptography?

An FDE product is only as strong as the cryptography built into it. Any FDE product should use an industry-accepted standardized cryptographic algorithm, such as AES, and preferably a tested and validated implementation of that algorithm. Also, key length should, at a minimum, correspond to current industry recommendations.

Many organizations, such as federal government agencies, have mandated cryptography requirements for encryption and integrity-checking algorithms, key lengths, and other areas, so be sure to consult such requirements when evaluating FDE products.

It is also important to ensure the FDE's cryptographic keys -- private or secret -- are sufficiently secured if they are stored locally. Options include the local hard drive, cryptographic token and Trusted Platform Module (TPM) chip.

For some FDE products, keys can be stored centrally instead of locally, and retrieved automatically from that centralized storage after successful authentication.

Do your homework

Evaluating FDE products for enterprise use can be intimidating, but with some basic criteria to consider, products can be readily distinguished from each other. Every organization has a different environment and different needs, not to mention different threats against it, so it is important each one does its own FDE evaluation and doesn't rely solely on existing evaluations in the public domain.

The criteria presented in this article are not intended to be all-inclusive, but rather a solid starting point for performing an FDE evaluation. Other important requirements to consider are the organization's own policies, procedures and general practices.