▶ 7.4 File Encryption Software
A file encryption program transforms files between plaintext and ciphertext, using keys provided to it. Some operating systems, including versions of Microsoft Windows, include a file encryption feature. In practice, however, such capabilities don’t provide all the features of a separate file encryption application program.
People use file encryption in two distinct situations:
Protect a file while sending a copy to someone else.
Protect a file while it resides on the computer’s drive. This involves three separate risks:
Access by a Trojan horse
Access by a separately booted operating system
Access to low-level data written to the drive
In the first case, we might send an electronic file via email, or we might copy it onto a USB drive and deliver it physically. When going via email, someone might intercept a copy of the file as it traverses the internet. Effective encryption should discourage the eavesdropper from trying to read the file. If the file travels on a USB drive, we may carry it by hand or send it through the mail. If we leave it unattended or plug it into an untrustworthy computer, there is no way to know for certain if someone has examined it and copied its contents.
In the 1990s, the director of the U.S. Central Intelligence Agency (CIA) took some highly secret documents home on an early form of flash storage. He worked on them using the same computer his children used to surf the internet. An investigation by the CIA inspector general did not find any Trojan horse programs on the computer. However, the investigation could not conclusively determine whether the information had been captured by an attacker while it was outside of the CIA headquarters.
When protecting the file on the drive, we also have to ensure that an eavesdropper can’t retrieve the original document. This is challenging, because files leave information on the drive even after they are deleted.
There was a Trojan horse attack on Bob’s computer. Bob wants his sensitive files to remain protected even if he or his employees play computer games. Encryption will protect his files as long as Bob is careful. For example, Bob might need to work on the file, so he decrypts it and works on it for a while. Then he gets bored and decides to play a computer game for a while. His file will be vulnerable to copying unless he remembers to encrypt it before he plays the game.
7.4.1 Built-In File Encryption
Many people use Microsoft operating systems that include a file encryption feature (it usually is limited to “Windows Professional” editions and omitted from “Home” editions). Although Windows encryption provides some useful features, it is not a cure-all. There are distinct trade-offs between using built-in file encryption and using a separate application program.
Built-in encryption is convenient, because the operating system often handles the keys for the owner. In Microsoft Windows, the user can open and save an encrypted file just like any other file. The operating system handles the keys, encryption, and decryption automatically (FIGURE 7.14).
FIGURE 7.14 Enabling file encryption on Windows.
Used with permission from Microsoft.
For example, Bob keeps his own spreadsheet to track the income and expenses of Bob’s Bookkeeping. It contains a lot of information that he does not want to share with employees. Bob decided to protect it with the built-in Windows file encryption. To do this, he right-clicks on the file and selects “Properties” from the menu. At the bottom of the Properties window, he selects the “Advanced” button; then he checks the box marked “Encrypt contents to secure data.”
Now, whenever Bob clicks on the file, Windows will open it and decrypt it for him. When he closes the file, only the encrypted form remains visible on the drive. This protects the encrypted files from access if an attacker boots a different operating system and tries to read files off of the drive.
Windows handles the encryption key automatically. The key is stored in the file system along with the file. To prevent attackers from extracting this key from the file system, the key is itself encrypted using a separate public key (see Chapter 8). Windows makes this public key available to Bob whenever he logs in. If we click on the “Details” button shown in Figure 7.14, we see a list of users who can decrypt the file, each with their own copy of the encrypted key.
In security, we pay for convenience by suffering other shortcomings. In this case, the convenience reduces the security. If Bob can read the plaintext of the encrypted file simply by opening that file, then a Trojan horse can read the contents, too. Thus, the Microsoft file encryption will not protect against a Trojan horse.
However, neither can Bob share the encrypted file with people on other computers. He has no way of sharing the encryption key, so others can’t decrypt the file. In particular, Windows provides no easy way of sharing the keys required to decrypt the file on a destination computer, even if running the same Windows operating system.
A final shortcoming suggests that Windows file encryption provides very limited security. Many Windows systems do not erase the plaintext data after encrypting the file. The drive retains scraps of the plaintext data on the disk blocks that held the decrypted file. If an attacker boots a different operating system and searches the drive’s data blocks, she might be able to retrieve some or all of this secret data.
7.4.2 Encryption Application Programs
From the user’s point of view, an encryption application program protects a file with a memorized password. Normally, the file is unusable in its encrypted form. When the owner provides the password and the file to the encryption application, the program produces a usable copy of the plaintext file. When finished with the file, the owner must run the encryption program again to reencrypt the file.
The encryption program allows the user to select a file, provide a shared secret key, and then encrypt or decrypt the file. FIGURE 7.15 shows the elements of the file decryption process and the boundaries between them. The program begins as a process started by Bob. He talks to the program by way of his keyboard, which in turn talks to his file encryption process. If someone else also happens to be running the file encryption program on his computer at the same time, the program runs in a separate process that belongs to that other user. The separate process has its own RAM and is restricted by the other user’s access rights.
FIGURE 7.15 Security boundaries while decrypting a file.
To use an encryption program to protect his survey file, Bob does the following:
Start the encryption application program.
Select the file he wants to encrypt: the survey file.
Provide the key used to encrypt the file (usually in the form of a typed password or passphrase).
The program encrypts the file and saves the encrypted copy.
The program erases the plaintext version of the file.
When finished, the program erases the key from RAM and exits.
Once the application program is finished, no one will be able to read the file without decrypting it first, not even Bob. Decryption requires the secret key. The most convenient programs use memorized passwords or passphrases as keys to encrypt and decrypt files. Such keys are not the strongest or safest, but they are the easiest to handle and share.
Ensuring Secure File Encryption
The file encryption program must take several steps to ensure that it does its job effectively. Some steps involve file handling and some involve key handling.
First, the file encryption program itself must be protected from modification by arbitrary or malicious users. An easy way to bypass encryption is to either replace strong encryption with weak encryption or to disable it entirely. Few people actually examine encrypted data to ensure that it is in fact encrypted.
The program protects itself during installation. The installation program may have built-in integrity checks to test for changes made to it since it left the vendor. The installation program also sets up file permissions to prevent regular users from being able to modify the encryption program.
The program also must protect the file while in plaintext form. When it creates a plaintext version of the file, only the owner—Bob in this case—should have access to that file.
Protecting the Secret Key
From a software and computing point of view, we only control the elements inside Bob’s computer. The software can’t prevent an eavesdropper (a suitemate named “Eve,” for example) from shoulder surfing while Bob types his secret key. The software also can’t prevent Bob from writing the key on a sticky note and leaving it on his desk.
However, the program must do whatever it can to keep the key secret. Systems try to keep passwords secret by not displaying them through the GUI. The systems either fail to echo a typed password on the display, or they print a mask to obscure the text of the typed password. A file encryption program must take similar steps when collecting a secret key.
The encryption process must be very careful about handling the secret key in RAM. In particular, the key must reside only in its special location in RAM. It must not be stored anywhere else or displayed through the program’s graphical interface. The key must never be copied to RAM that other processes may see. The program must ensure also that the key is never written to the drive.
7.4.3 Erasing a Plaintext File
After the file encryption program encrypts the plaintext file, it should actively erase the plaintext file’s contents. If we delete the file, the operating system “loses” it and can’t retrieve it for us. However, the actual data we wrote in the file remains on the drive. The disk space containing it will eventually be overwritten by new files, but the data remains undisturbed until then.
Forensic and file recovery programs often can recover deleted files. These programs look inside the file system and track down the deleted file information. If the file’s space on the drive hasn’t been reused, the undelete program may be able to retrieve the deleted file. Section 5.5.3 described how to retrieve a deleted file on a FAT device.
To protect against undelete programs, the easiest solution is to overwrite the file’s contents. To do this, the program writes zeros or any other data pattern over the file’s contents on the drive. An undelete program can’t possibly recover a file after we overwrite it.
Risks That Demand Overwriting
There are three risks related to overwriting: a Trojan horse, a reboot to a different operating system, or access to low-level signals written to the drive.
If we want encryption primarily to protect against Trojan horse attacks, then the encryption application doesn’t need to wipe the file. A program that undeletes files requires full, unimpeded access to the drive. Such programs are run only by administrators. If the attacker can run such a program, then we can’t protect the file with file encryption. If we apply Transitive Trust, we see that the attacker with administrative rights can modify the file encryption program so that it passes data to the attacker (the encryption keys, the plaintext files, or both).
This is a difference between the encryption application and the Windows built-in file encryption. Windows does not protect against a Trojan horse attack. When an application opens an encrypted file, Windows decrypts the file automatically and provides the plaintext to the program. This allows a Trojan horse to read the user’s encrypted files. We must use a separate encryption application program to protect against a Trojan horse.
If we want to protect against an attacker booting a different operating system to access the drive, then we need to overwrite the file before we delete it. Otherwise, the attacker could boot another operating system and use it to undelete the plaintext file.
Some users store incredibly sensitive data on their computers. They do not want to take any risk of others recovering that sensitive data. If we need to protect against that, we need to work even harder at erasing the data from the drive.
Preventing Low-Level Data Recovery on a Hard Drive
If we rely exclusively on a hard drive’s built-in circuitry to read and write data, then it is easy to wipe the data in a file. We write new data over the old data, zeros, ones, or a mixture, and the hard drive sees the newly written data. However, the hard drive retains subtle indicators of the drive’s earlier contents.
Data recovery experts can produce high-resolution maps of the magnetic fields on a disk’s surface. If the disk heads on a hard drive are not positioned exactly over a sector when writing new data, the sector’s previous data may remain visible, especially in older hard drives. To counteract this, security software would try to erase the data thoroughly by rewriting each sector several times, writing a different bit pattern each time.
Modern drives, however, do not suffer from this problem. Hard drives that contain over 15 GB of storage pack their bits much more closely together. While many data recovery experts could retrieve overwritten data from older and smaller hard drives, there are no well-known techniques to retrieve overwritten data from newer drives.
Despite this, no computer program can reliably remove all sensitive data from a hard drive. A drive may move data from a failing section of the drive to a different section. (See Section 5.3.1.) The drive marks the old section as “bad” so it isn’t used for new data. From then on, there is no way to access the bad section of the drive. Low-level analysis may be able to retrieve sensitive data from the bad section. This does not pose a risk for most user communities, but it shows how persistent digital data can be.
Erasing Flash Storage
Modern flash drives pose a greater challenge. The internal architecture of modern flash drives is radically different from that of traditional hard drives. A hard drive typically uses the same media surface to read and write data at a specific block address, but flash memories usually write updated blocks to new locations. The drive maintains a map to show where the data belonging to a particular block address is stored. The drive interface provides no way to directly overwrite a data block’s previous storage location. A motivated attacker could disassemble a flash drive and extract data that should have been erased.
Some vendors provide a specific function for clearing a drive’s contents. If the flash drive uses the ATA or SATA interface, there is a “Secure Erase” command. Some flash vendors implement this command by directly erasing every physical block in the device. If done correctly, this eliminates all stored data. Unfortunately, research has shown that not all vendors implement Secure Erase correctly. Moreover, Secure Erase is not part of the USB standard, so portable USB drives are less likely to provide a Secure Erase function.
Erasing Optical Media
Optical disks, including, Blu-ray, DVDs, and CDs, provide an easy way to share a lot of data. They all pose a problem when we want to rid ourselves of sensitive data. The problem is more or less the same for commercially manufactured disks and for formats writable on personal computers.
All of these optical devices work by reflecting a laser off of the disk’s surface. Individual bits are distinguished by whether the laser detects a light or dark reflection. When we write on a recordable disk, the writing actually modifies a dye in the disk. When we write on a rewritable disk, we modify a special material that allows itself to be switched on and off.
The most practical way to render optical disk contents unusable is to physically destroy the disk’s surface. Commercial optical disk erasers cover the surface with pits, which renders enough of the surface unusable so that a computer can’t mount the disk. Certain types of heavy-duty paper shredders also accept optical disks and chop them into unreadable pieces.
It also should be possible—at least in theory—to write over either a recordable or a rewritable disk. In fact, there has been very little research on the effectiveness of such techniques. Microscopic analysis might be able to distinguish between recent and less- recent cycles. In the absence of known research results, it is best to simply destroy CDs or DVDs.
7.4.4 Choosing a File Encryption Program
If we type the term file encryption into an internet search engine, we find a lot of candidates. Some entries may refer to built-in Windows encryption or to whole-disk encryption (PGPDisk, for example), which we will examine in Chapter 9. There are countless programs that perform file encryption.
In 1989, a programmer named Phil Katz released a computer program named PKZIP, which introduced the now-popular “zip” file compression format. People typically use zip format to combine one or more files into a single, compact file for sharing with other people. In addition, PKZIP included a password-based encryption mechanism.
Unfortunately, the early versions of PKZIP did not use a modern, high-quality encryption algorithm. In 1994, researchers Biham and Kocher published a paper describing weaknesses in the encryption. Soon, others developed cracking programs that could analyze an encrypted PKZIP file and guess its password. Fortunately, the recent versions of PKZIP can support strong, modern cryptographic algorithms, as do many other programs supporting the zip format.
Cracking programs also crop up for other applications that incorporate relatively weak password protection schemes. This includes most Microsoft Office applications, which do not all use encryption when password-protecting a file.
Another program that often appears is PGP, which stands for “Pretty Good Privacy.” Phil Zimmerman, the original developer, created it to exchange encrypted files using email. The program was released in 1991 in response to the fear that the U.S. Congress would pass laws forbidding the use of strong cryptography by U.S. citizens.
Originally, PGP software was free, but since then, PGP has become a commercial product. Following this freeware tradition, the PGP Corporation provides a free, limited-capability version of their software for personal, noncommercial use. PGP includes the ability to encrypt a file using a shared password or passphrase, though it also supports more sophisticated key-sharing techniques based on public keys.
Many companies that offer file and system utilities, like Norton or McAfee, also offer file encryption programs. There are also numerous freeware and shareware applications that perform file encryption.
Given all these choices, we need a way to compare the different benefits provided by the different applications. To do this, we consider a list of requirements that the file encryption program might fulfill. We use this list to produce a security checklist for the file encryption program.
Software Security Checklist
Before we look specifically at file encryption, let us look at some basic, even obvious software considerations:
■ Cost. Can we afford the software in terms of purchase cost?
■ Compatibility. Does the software run in our computing environment? This is challenging if we run multiple systems, like Windows, Linux, and Macintosh. We should be able to encrypt or decrypt the files on any of our systems.
■ Installation. Did we install a genuine copy of the software? Is it protected from subversion by other users on the computer? Only the administrator should have write access to the file encryption application.
■ Usability. Will the application fit our working style? This decision involves both the behavior of the application and the challenge of keeping the software supported and up to date.
■ Trust. Do we trust the vendor? Some people are more inclined to trust commercial organizations. People familiar with the open-source community may be more inclined to trust open-source products if they are sure they have downloaded the correct software.
File Encryption Security Checklist
This checklist provides a list of requirements that should be met by a file encryption program.
The program shall use an encryption algorithm that is respected and accepted by the crypto community. Here is a list of common algorithms:
When the program decrypts a file and saves the result in a new plaintext file, the program shall grant access rights to the new file exclusively to the file’s creator.
After creating an encrypted copy of a file, the program shall erase the contents of the original, plaintext file by overwriting the storage space on the drive. Then the program shall delete the erased file.
The program shall handle keys in a safe manner. We examine this problem in Chapter 8.
Ideally, the program shall have completed a cryptographic product evaluation by a recognized authority.
Although there are ways to make DES stronger, it is no longer recommended for use. Some vendors have tried to stretch its useful life by using “Triple DES” (3DES) in which the algorithm is applied 3 times with up to 3 different keys. Although this can increase the key size to 112 or 168 bits, the resulting cipher is still weaker than 128-bit AES.
Cryptographic Product Evaluation
When we purchase other products, especially expensive or important things, we often search for expert opinions that compare alternative products. With crypto products, this comparison is especially challenging. These products can fail in many ways that weaken or eliminate the protections we require. It takes a sophisticated review process to produce an informed opinion on the quality of an encryption program.
Fortunately, there are processes and techniques for performing such evaluations. These often are established by national governments: In the United States, the recognized evaluation is a federal information processing standard, called FIPS 140-3, and administered by the NIST. Such evaluations are mandatory when the encryption is used in certain high-security environments, such as financial institutions and U.S. government organizations.
We prefer software that has completed a cryptographic evaluation because these evaluations will do some of the decision making for us. The evaluation will check the product for well-known security mistakes and weaknesses. This yields a more thorough assessment than we can make as consumers.