Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.
Full Disk Encryption: What It Can And Can't Do For Your Data
Protection depends on how implementation -- and user know-how
12 Min Read
There was a time, not all that long ago, when a fully-encrypted system disk was something only for people with money to burn. You bought a special disk controller which performed hardware-based encryption, and then trusted the hardware vendor to make sure everything was implemented properly -- e.g., that they were using a good algorithm, that the key size for the encryption wasn't laughably short, and so on.
Today, full-system encryption in software is both feasible and practical -- although how practical will depend on the workload involved. But it's not a security silver bullet, much as it might seem to be from the outside. It can, and does, add a layer of protection that greatly reduces the risk of data compromise in the event hardware is lost or stolen. But that protection depends entirely on how it's implemented, and whether or not the user's been educated in the way an encrypted system works.
How Disk Encryption Works
System-disk encryption, or full-disk encryption, involves encrypting the operating system partition on a computer and then booting and running with the system drive encrypted at all times. If the computer is stolen or lost, all the data on the drive -- including the OS itself -- is unreadable without that volume's key. The data on the system can be considered a write-off without the need to remotely wipe the device.
When you boot an encrypted system, you need to provide a decryption key at boot time. The key could be any number of different things -- a password; a USB flash drive with the decryption key; an RSA token-generating device; a fingerprint in conjunction with a Trusted Platform Module; or a combination of the above, in some variety of two-factor authentication. For the most part, the only thing that changes for the end user is the boot process, and then only minimally.
If the key itself is lost or stolen, most full-disk encryption systems provide some form of key escrow. This means a backup copy of the encryption key is held by the system administrator and can be used to recover the data on the system, and a new key can be generated without too much trouble. Professional-grade products typically allow the key to be held in a central repository such as an LDAP or Active Directory schema. (The lost key itself is useless without the data encrypted with it, so it can generally be written off if it goes missing.) The important thing to understand is that once the device is unlocked and booted, it is vulnerable. Locking the system re-instills a modicum of protection, as does sleep mode or total shutdown / hibernation, but while open and running, the system can be compromised. This makes it doubly important for the user to be mindful of the system while it's running, and not to think of system-disk encryption as a security panacea.
As you can imagine, full-system encryption is most useful when you're dealing with a machine that's being taken on the road. It's far less valuable for a computer that's in a fixed location, where physical access can be controlled. In such cases full-disk encryption adds overhead, but not much security.
There are two basic ways to perform full-system encryption. You can get it as part of your operating system, or you can add it after the fact.
OS-level Encryption
Windows, Linux, and BSD all sport some variety of full-disk system-level encryption. In Windows, it's BitLocker, tightly integrated into Vista and 7, although only available in the higher-end SKUs of that product. Many Linux distributions natively support full-disk encryption: Red Hat / Fedora allows you to create new system installations with encryption. Various BSD flavors also sport it: GBDE and GELI on FreeBSD, for instance.
Having the encryption subsystem as part of the OS itself is two-edged. On the one hand, it means you don't have to install anything to get started; everything you need is right there. On the other hand, it also means you're limited by whatever features the OS maker deigned to include, and expanding on their functionality may be difficult.
Linux's dm-crypt subsystem, for instance, is open source (like Linux itself) and can be expanded upon as long as you have some understanding of the code. Likewise, BitLocker has an API with some exposed functionality, but for the most part it's intended to be used in the manner directed by Microsoft.
Third-Party Solutions
The breadth of commercial solutions out there means you can add full-system encryption to pretty much any system after the fact. Keep in mind that most third-party solutions require that you dedicate to them some degree of server resources, for the sake of central management/.
PGP Whole Disk Encryption was originally developed as a free product, but has since been rolled into a for-pay offering, and is generally one of the first products mentioned when discussion turns to commercial-grade encryption. It supports a full gamut of professional features, including support for any smartcard that uses the PKCS-11 library, and allows for automated rollouts of encrypted systems -- something that's valuable if you're adding encryption after the fact to a whole fleet of existing notebooks. A server is mandatory, though. According to the Whole Disk Encryption product sheet, "PGP Whole Disk Encryption is centrally managed by PGP Universal Server which requires a dedicated hardware server." In the same vein is McAfee Endpoint Encryption, which includes not only whole disk encryption but sub-products for encrypting removable devices, individual files and folders, and mobile devices.
Jetico BestCrypt also boasts features like secure hibernation and encryption of crash dump files, and integration of encryption into disk-rescue functions -- handy if the encrypted systems in question are being used for software development and may be prone to crashing.
Also widely touted is Sophos Endpoint Security and Data Protection (which includes full-disk encryption as part of a package with antivirus, client firewall, and network access control features. It's aimed at those who want an entire solution rather than just disk encryption alone, so the free 30-day trial will come in handy to determine its fitness. (As a further nod toward its "total solution" status, it can automatically remove other security products when installed.)
Free Solutions
As in many other places, the encryption software market now features at least as many free / open source solutions as it does commercial ones. In many cases the open source offerings are just as good in terms of the quality of encryption and the end-user experience, although they don't typically have management functionality (something pretty essential in an organization where you're mandating encryption as a standard-issue item). To that end, free solutions are useful but if you're only dealing with one or a very small number of machines -- if, in effect, you are your own IT department.
TrueCrypt, nominally used for creating encrypted virtual volumes, added full-disk encryption for Windows not long ago. Aside from having multiple system partition encryption options and a "wipe mode" (which insures that the encrypted drive has no stray unencrypted data on it), it requires the user to create a password-protected, bootable rescue CD as a kind of personal key escrow system, and it even encrypts or decrypts the drive in the background as you work.
There are a few drawbacks to TrueCrypt in an enterprise setting:
TrueCrypt is free software, so there is no native, paid manufacturer support (as opposed to community support or consultants) available for it.
Keyfiles -- using a file as an adjunct to one's password -- are not supported in full-disk mode.
RSA tokens or the like cannot be directly integrated with TrueCrypt as it stands.
TrueCrypt does not support automatic key escrow -- a major problem when using it in a centrally-managed environment. The recovery DVD could be used, or automatic key escrow could be done by initially using the same generic password for each drive, backing up the drive header (where the actual encryption certificate is stored), having the user change the password, and then restoring the original drive header. That said, there's no native setup mechanism for this; the whole procedure would have to be implemented manually. One third-party key escrow solution does exist , but it has not been updated recently. DiskCryptor was devised as a more open alternative to TrueCrypt; its authors claim the code can be reworked and reused more freely than rival TrueCrypt. DiskCryptor has an equally impressive feature set: it can perform full-volume encryption in the background, can wipe as it encrypts, and so on. That said, it does not perform boot tests to ensure the encrypted volume is accessible, nor does it have a key escrow mechanism either. And finally, being free, it also has no support either. Both programs, then, are to be used entirely at one's own risk.
Performance Impact
One major issue that surfaces often when talking about full-system encryption: what impact does it have on performance? There's no one answer to this question, since the impact varies enormously based on workload and the available hardware.
Reduced Performance: This is obvious enough: the system is devoting more CPU muscle and context-switching to encrypting and decrypting everything, which leaves less power available for workaday tasks.
The more disk I/O there is, and the more I/O-bound your applications are, the greater the impact. Someone whose workload consists of little more than e-mail, word processing, and accessing the Internet won't experience anywhere near the performance hit that someone attempting to edit video or perform million-record database searches would.
To that end, assessing the performance impact of full-system encryption is something that needs to be done specific to the task at hand -- not just opening and saving a Word document, for instance, but gathering performance statistics over the course of one or more hours while doing tasks in parallel. A product such as XRatel Performance Suite is useful here.
Reduced Battery Life: Many notebooks can swap processor speed for battery life -- e.g., by capping the CPU speed as a power-saving and thermal-control measure. (Running the CPU fan less also means more power is saved.) But again, this only goes so far, so older notebooks with less flexible power management may be forced to use more power, period.
Security Limitations
Encryption makes it extremely difficult (I won't go so far as to say "impossible") for a casual attacker to retrieve data from the encrypted drive. Without the hardware key, PIN, or other token, it's unreadable. However, because security is a quality rather than an abstract quantity -- it's about how you do something, not what is done -- it's entirely possible to attack an encrypted system drive and compromise the data stored on it. Those attacks do not have to center around the data itself, either, but on user behavior.
Social Engineering: Of all the ways to get around system encryption, social engineering is by far the easiest and most successful. Any of a set of attacks on the weakest link in a computing system: the user can be considered social engineering. Tricking the user into revealing a password or overlooking some security step is far easier than most people admit. In other words, full-disk encryption -- like any other security measure -- is only as good as the person using it, and shouldn't be deployed without some degree of end-user training about its behavior.
Pre-boot Attacks: Much has been made recently of attacks on whole-disk encrypted systems that revolve around the pre-boot environment, where much of the initial decrypting is done. That said, most of these attacks (such as the "Stoned" bootkit attack can only be implemented if the user can be tricked into running a malicious program as administrator -- much more difficult in a managed environment where the end user cannot do such things casually. Nothing, however, precludes such an attack from using an existing software defect to gain privilege elevation, so this should be considered a pervasive if distant threat.
In-memory Attacks: More difficult, but still theoretically feasible, is recovering the encryption keys from DRAM after the power has been cut . Some encryption systems have at least partial ameliorations for this -- for instance, BitLocker has a policy setting to force the clearing of system memory at restart, which reduces the possibility of a key being recovered from RAM. This should be considered an unlikely method of attack, but at the same time it's worth making use of any countermeasures that might help stave it off -- the biggest being retaining physical control of the encrypted unit at all times!
Unencrypted, "Stray" Data: An encrypted system drive doesn't mean other drives in the same system are also encrypted, and it doesn't mean removable drives attached to the system are encrypted by default. This is something best controlled by other system policies -- for instance, by forbidding the use of removable drives, and not allowing other partitions to be created on the same system.
Disk Failure: The threat of disk failure poses a whole raft of problems all its own. If an encrypted system disk fails, the data on it is most likely forfeit; data recovery tools need to read directly from the disk, and are generally not aware of on-disk encryption. The odds of this happening are generally low, but with a large enough pool of devices it's guaranteed to happen sooner or later -- so have an encrypted data-backup plan in place, too.
Because system-disk encryption in software is still relatively new, it probably still has the flavor of something exotic and relatively untested. This isn't far from the truth, especially if you haven't given it a shakedown in your own organization due to questions about the implementation.
However it's put to use, one key truth should always be in mind: disk encryption is not security. Or, rather, disk encryption is not the sum total of security for a system; it's one of many things that can enhance security. Full-disk encryption works best when it's part of a total protocol for the care and handling of a piece of hardware constantly on the go.
About the Author
You May Also Like
More Insights
