Encryption is the process of scrambling data to make it unreadable to anyone who does not possess the proper key to unscramble it. This can be a powerful tool for enhancing data security but it has limitations and you need to decide among some trade-offs in how it is applied.  

This content covers the use of encryption to protect data at rest on hard disks, external drives, thumb drives, and the like. Technologies like SSL or IPSec that are intended to protect data in transmission over the network are not included. 

A summary of Cornell IT Policy regarding the use of encryption is in University Policy 5.10, Information Security.

The Granularity Trade-Off

• Greater granularity: Encrypting each file individually provides good protection against data loss due to theft but requires the most attention to how one handles files.
• Lesser granularity: Encrypting the entire device at once provides good protection against data loss due to theft and requires less attention to how one handles files.

The Three Types of Encryption

• Full-Disk Encryption (FDE): When the entire drive is encrypted, you have good defense against data loss due to theft since you don’t need to worry about whether or not a given file is encrypted. On the other hand, when a system with FDE is in active use, i.e. when one is logged in, the entire contents of the disk are exposed to theft of data via malware.
• Volume-Level Encryption: Here one creates a “container” – a virtual directory space – whose contents are always encrypted. By only mounting the encrypted volume when you need to work with the sensitive material it contains, you reduce the risk of data loss due to malware, as well as enjoy good protection if the computer is stolen. On the other hand, you need to take care that sensitive data is always kept in an encrypted volume.  
• File-Level Encryption: Encryption at the level of individual files affords a good level of protection against data loss due to theft. On the other hand, this is where you need to invest the most effort in file management. (Note that there are two flavors of file-level encryption: (1) When the file is decrypted only when it is in use, typically the case with application-based encryption. (2) When the file is not automatically re-encrypted when one is done viewing or editing it, as it the case with stand-along encryption utilities.) 

Full Disk Encryption in More Detail  

The first type, full disk encryption protects an entire drive. It can be implemented by a software package such as BitLocker or FileVault (both used at Cornell), Truecrypt, PGP, etc., or by specialty hard disks such as those offered by Seagate or Hitachi.

Full disk encryption has the advantage of protecting all software applications, data, log files, and anything else stored on the disk. It is generally transparent to the operating system and to backup software such as EZ-Backup. Full disk encryption is at its best when the system using it is powered off. That is, it offers very high defense against theft or loss of the computer or drive, but offers no defense against disclosure to malware, viruses, or unauthorized use.  

Full disk encryption does exact a small performance penalty, which ranges from imperceptible to a few percent, depending on CPU performance. Drive-based encryption technologies, like those offered on certain Seagate or Hitachi 2.5-inch notebook drives, show no detectable performance penalty.  

Some software full disk encryption cannot be used to encrypt the drive from which the operating system starts. Because of the risk of sensitive data being inadvertently stored on the unprotected drive or volume, these technologies share many of the weaknesses inherent with volume level encryption, below. Where this restriction is the case, it will be noted in application descriptions.  

Volume Level Encryption in More Detail  

Volume encryption protects a smaller subset of a drive, possibly down to the level of individual folders. Common volume encryption software includes BitLocker or FileVault (both used at Cornell), Truecrypt, or PGP.

Volume encryption works either by encrypting an entire hard disk partition (C:, D:, etc) or by creating an encrypted container file. This container, often several gigabytes in size, is internally encrypted by a piece of software that also makes the container appear as a drive letter or folder. Files saved in that special location are automatically encrypted and added to the container.  

Volume encryption protects very well when either the system is powered off or the protected volume is not actively available for use (i.e., not mounted). Its defense against disclosure to malware or unauthorized use is highly circumstantial; if the volume is available the contents are defenseless. For that reason, many volume encryption applications offer the ability to unmount the protected area when the machine is idle, if the screen saver starts, or if the machine enters a power saving mode. While this reduces the opportunities for data exposure, it comes at the expense of more cumbersome operation, as a password must be entered each time the volume is mounted.  

In many implementations, volume encryption also requires that the user pay considerable attention to data confidentiality and storage location. Only data stored in the protected space offered by the encryption software is safe. Temporary files, browser caches, and other areas where sensitive data may lurk are often exposed outside the protected space.

Lastly, volume encryption can present difficulties for backup software such as EZ-Backup. Unless configured to ignore the large container file, backup systems will attempt to back up the entire container, regardless of size, after even the slightest modification of its contents. This can be very wasteful of network bandwidth and backup system resources. Also, some container encryption technologies may be backed up only once and never again, complicating recovery.

Folder level encryption, such as that provided by EFS, shares many of the same characteristics of protection and workflow as volume encryption. The particular strengths and weaknesses of EFS apart from these similarities will be addressed in its own section.

Risk of Implementation Flaws  

Encryption is hard to do well and implementation flaws are hard to analyze. Generally, strong encryption relies on a sound algorithm (3DES, AES, Twofish), properly implemented, used with strong passwords or keys. Most encryption failures stem from either poor implementations or poorly chosen passwords. Poor implementations include designs that store the key, disclose it in some manner, allow sensitive data to be left unencrypted, or do not properly implement the encryption algorithm. Poor key selection is typically a matter of passwords that are not complex or not long enough. 

Complications for Backup Technologies

• Most backup systems rely on changes in file time stamps or file size to determine the need to preserve a copy of the file.
• Volume encryption software presents difficulties for backup technologies:
  • If the date/size attributes of the container do not change, it may not be backed up frequently enough to recover from disaster.
  • If the date/size attributes change for every file within the container, the entire container may be recorded and backed up.
  • Mounted volumes frequently lock the container file, preventing access by the backup system.
• In general, it’s best to back up the contents of a mounted volume and ignore the container itself. This presents the best combination of backup efficiency and the ability to recovery from small errors.
• The above considerations do not, in general, affect full disk encryption technologies. Most backup applications see the data just as they would if encryption were not in use.

Policy Considerations

• A summary of Cornell IT Policy regarding the use of encryption is in University Policy 5.10, Information Security.
• University Policy 5.3, Use of Escrowed Encryption Keys, states: “Custodians or users of institutional administrative data who deploy software or algorithmic programs for encryption must establish procedures ensuring that the university has access to all such records and data.” Essentially, this means that encryption keys must be safely stored according to unit-specific process so that university data can be recovered in a contingency situation.