15.3. Related Work: Sanitization Standards, Software, and PracticesConfidential information that is stored on a computer system can be protected by numerous mechanisms, including operating system mechanisms, physical isolation of the computer system itself, and even the use of cryptography. The first two of these techniques fail when media is physically discarded: discarded media is, by definition, no longer contained within a protected perimeter. And once a disk or tape drive is removed from the computer on which it was created and is taken elsewhere, other operating systems are free to honor or ignore meta information such as file protection attributes. Only cryptographic measures survive when a disk is discarded. Yet experience has shown that many kinds of confidential information are not stored with encryption. Interestingly, the risk that confidential information could be released inadvertently on discarded media has been recognized since the 1960s.[13]
15.3.1. DoD 5220.22-MIn the 1970s, each of the armed services adopted their own standards for sanitizing discarded media. These were combined into the unified Department of Defense standard 5220.22-M.[14] According to the standard, nonremovable rigid disks may be "cleared" simply by "overwrit[ing] all addressable locations with a single character," which is generally taken to mean writing an ASCII NUL onto all user-addressable locations. Sanitizing requires that the media be degaussed with a Type I or Type II degausser, that a three-pass sanitization process be implemented, or that the disk be physically destroyed"disintegrate, incinerate, pulverize, shred, or melt."
DoD's three-pass procedure has been the subject of some debate. According to the standard, the procedure is: "Overwrite all locations with a character, its complement, then a random character and verify. THIS METHOD IS NOT APPROVED FOR SANITIZING MEDIA THAT CONTAINS TOP SECRET INFORMATION." [Emphasis in original.] This is normally implemented with the following algorithm:
This process is designed to guard against a hard-disk drive that claims to be accepting write commands but that does not actually write data onto the disk. There has been much debate as to why the standard's authors have taken such great pains to specify that this standard is not approved for sanitizing media that contains "top secret" information. The implication is that organizations such as the National Security Agency have capabilities for recovering information that has been overwritten using this procedure. An alternative explanation is that the NSA does not possess this capability, and that the NSA doesn't want the targets of its collection efforts to employ 5220-22-M to sanitize their media! Peter Gutmann explored the issue of recovering overwritten information in his 1996 USENIX paper, "Secure Deletion of Data from Magnetic and Solid-State Memory." Gutmann notes that it should be possible to recover information that has been overwritten once or twiceor possibly even more timesdepending on the particular recording technology in question. For example, when a 1 is written over a 0, the resulting magnetic field sensed by the read head is going to be different from when a 1 is written over a 1. Gutmann then presents a variety of patterns for overwriting data that are designed to interact with various recording schemes used by different generations of disk drives. In total, 35 different patterns are presented, covering several generations of disk-drive technology. Surprisingly, a few developers of sanitization tools have adopted all 35 patterns, writing one after the other. Gutmann sneered at this misreading of his paper, and added this postscript to the online version: It is readily apparent that overwriting provides sufficient sanitization for the vast majority of computer users. Yet overwriting has not been built into operating systems until very recently, and even current operating systems do not implement it in a uniform or even consistent manner. This creates profound usability problems: not only does the computer user need to understand that the deleted files aren't actually deleted, but also the user must obtain and use specially written software to properly sanitize his media if he wishes to discard it without risk. The remainder of this section discusses a variety of techniques that have been developed to allow end users to overwrite dataeither selectively or across an entire drive.
15.3.2. Add-On SoftwareAlthough sanitization has not been built into operating systems until recently, third-party and add-on programs to perform some kind of overwriting have been available for personal computers for more than two decades. Programs have emerged to target all manner of data on a hard drive:
Add-on programs are not without their risks: a poorly written program that reads and writes directly to the disk without going through the operating system risks corrupting the entire volume. Programs that go through the operating system run the risk that there may be a mismatch between the primitives that the operating system offers to programs and the way those abstractions are implemented on the actual disk surface. For example, a user who types pgp -w filename to erase the contents of filename on a journaling filesystem may be surprised to learn that data that "overwrites" may actually be written to another location of the disk. That's because journaling systems write modifications to an expanding journal, instead of modifying data that is stored in place, to protect the filesystem against inadvertent corruption that might occur if the computer fails during a disk write. Another risk of add-on programs is that they may not actually perform the way that they claim to. Although users would certainly notice and complain about a program that was advertised to sanitize slack space but that actually overwrote Level 0 files, a program that overwrote only the first few bytes of a file being "wiped" would not be so easy to detect. Indeed, for several years, the Linux wipe command did just that. But the biggest risk of relying on add-on programs, quite simply, is that users do not know that they exist. Driving this point home, a proactive white paper written by Guidance Software, evaluating the Windows CIPHER.EXE program, concludes: Once again, usability is compromised because of an underlying failure in the operating system: not only does the user need to know that he must obtain a special sanitization program, but he also needs to be sure that the program works as advertised. Unlike a word processor or a spreadsheet, it is remarkably difficult for a user to test a sanitization program to determine if it is functioning properly. 15.3.3. Operating System ModificationsAn alternative to third-party sanitization tools is to have sanitization technology embedded directly into the computer's applications and operating system. Arguably this is where they belong, on the grounds of both usability and correctness. Certainly usability is enhanced when the operating system provides for proper sanitization of media that potentially has confidential information. Correctness is also furthered, because an implementation of sanitization within the operating system should take into account any implementation peculiarities (such as journaling filesystems) that might be hidden to the application program but that are relevant to the sanitization process. For example, version 0.4 of the Linux ext2fs filesystem introduced the concept of the per-file s attribute. Set with the chattr command, any file with the s attribute set was overwritten with ASCII NULs when the file was unlinked. Remy Card's implementation was quite simpleonly four places in the ext2fs source code needed to be modified to handle the secure deletion attribution.[17]
Card's implementation was certainly open to criticism: blocks were overwritten only once, not three times or more. And because the write was only scheduled, there was a chance that a block queued for being overwritten might not actually get overwritten at all the system might crash, or the blocks might be reallocated to another file and the confidential information might end up in the slack space at the end of a file. In any event, the code for "secure deletion" was removed from ext2fs in the Linux 2.2 kernel, apparently for performance reasons. It's interesting to note that even though the Linux 2.2 kernel dropped the actual secure deletion, the s attribute can still be set by the chattr command. Doing so, however, no longer does anything! Adding to the confusion is the fact that the chattr command's documentation still discusses the s, c (automatic compression), and u (allow undeletion) attributes, but notes at the bottom: BUGS AND LIMITATIONS As of Linux 2.2, the 'c', 's', and 'u' attribute are not honored by the kernel filesystem code. These attributes will be implemented in a future ext2 fs version. Here, then, is another example of the disconnect between usability and security caused by poor programming and visibility, rather than an inherent disconnect between the two. Does the phrase "not honored by the kernel filesystem code" mean that secure deletion happens somewhere else, or that it doesn't happen at all? The only way for an expert user to know is to inspect both the source code and a running system. The only way for a novice user to know is to ask an expert. Others have reimplemented secure deletion for Linux, but these modifications have not been incorporated into the mainstream Linux kernel. Bauer and Priyantha[18] describe a modification to the Linux operating system to support secure deletion using the very same attribute bits developed by Card. Instead of implementing secure deletion directly in the unlink( ) system call, the implementation uses a scheduled kernel process. Unfortunately, this code was not integrated into the mainstream Linux kernel, and it can no longer be integrated because the Linux kernel has continued to evolve.
Following the publication of the "Remembrance of Data Passed" paper, Apple Computer added a Secure Empty Trash function to the Finder component of its Mac OS. According to interviews conducted with Apple's security group on January 12, 2003, the security group had long wanted to put a secure delete-file function in the operating system's interface: such efforts had been deemed by Apple's management to be not a priority until the "Remembrance" paper was published. Like the Windows Recycle Bin, the Macintosh Trash is actually a special directory that is managed by the graphical file manager (which Apple calls the Finger). Dragging a file to the Trash moves the file to this special directory. Emptying the Trash causes all of the files in the directory to be unlinked with the unlink( ) system call. Choosing the Secure Empty Trash feature, added by Apple in Mac OS 10.3, causes the contents of the files to be overwritten before they are unlinked. The Mac OS 10.3 interface is subtle in the way that it informs the user of the difference between Empty Trash and Secure Empty Trash. Choosing either option from the Finder menu causes an alert panel asking for confirmation to appear. The wording on the Empty Trash panel states: Are you sure you want to remove the items in the Trash permanently? You cannot undo this action. In contrast, the wording on the Secure Empty Trash panel states: Are you sure you want to remove the items in the Trash permanently using Secure Empty Trash? If you choose Secure Empty Trash, you cannot recover the files. What is the difference between an operation that cannot be undone and one that cannot be recovered from? The answer is found in the Finder's Help system when one types in Secure Empty Trash.
Although this author finds it personally rewarding that a paper published in January 2003 would result in a significant modification to an operating system used by tens of millions of people in less than a year's time, there is much to critique in Apple's initial implementation of Secure Empty Trash from a usability perspective:
Figure 15-1. This pop-up window is displayed when an existing file is specified using the Save As? command; Mac OS 10.3 promises that the new file will "overwrite [the] current contents" of the file being replaced; in fact, Mac OS does not overwrite the file: it saves the new file to a temporary location, renames the original file to a temporary filename, renames the new file to the orginal filename, and then uses the unlink() system call to delete the original file
Apple's implementation of Secure Empty Trash has the look of a quick hackit adds functionality without properly integrating that functionality into the user experience. Indeed, the very user interface is inconsistent: the menu item Empty Trash... appears with a trailing ellipsis, indicating that choosing the command will bring up another window, while the menu item Secure Empty Trash appears without an ellipsis. Meanwhile, the context-sensitive menu on the Trash Can icon was not modified between Mac OS 10.2 and Mac OS 10.3 to reflect the new functionality: a user who only empties the trash by using the context-sensitive menu might miss the new functionality in the operating system. Both of these user interface errors are shown in Figure 15-2. Figure 15-2. Modifications to the Mac OS 10.3 user interface to support the Secure Empty Trash command were inconsistent and applied haphazardlyWhile Apple should be commended for making an attempt to address the issue of file-by-file sanitization, the company has not lived up to its reputation of interface thoughtfulness, consistency, and user experience. Apple needs to rethink its implementation of file sanitization and come up with a new interface that both is easier to use and promotes improved security. Thoughts on such an interface are presented in the next section. |