Section 15.3. Related Work: Sanitization Standards, Software, and Practices


15.3. Related Work: Sanitization Standards, Software, and Practices

Confidential 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]

[13] National Computer Security Center, A Guide to Understanding Data Remanence in Automated Information Systems (1991), NCSC-TG-025; http://www.secinf.net/rainbow_series/NCSCTG025_Green_book_.html.

15.3.1. DoD 5220.22-M

In 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."

[14] U.S. Department of Defense, "Cleaning and Sanitization Matrix" (1995), DOS 5220-22-M; http://www.dss.mil/isec/nispom_0195.htm.

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:

  1. Seed a cryptographically secure random number generator with a random seed R1.

  2. Write the output of the generator to the entire disk.

  3. Reseed the random number generator with the same seed R1.

  4. Write the complement[15] of the generator's output to the entire disk.

    [15] That is, for each output byte d, write the byte 255-d.

  5. Seed the generator with a new random seed R2.

  6. Write the generator's output to the entire disk.

  7. Reseed the random number generator with the seed R2.

  8. Read the contents of the entire disk, verifying that the contents of each block match the output of the random number generator.

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.

CRYPTOGRAPHIC APPROACHES

Cryptography provides one of the simplest and possibly the best way to handle the problem of data passed. If information is simply encrypted when it is written to a disk and decrypted when it is read back from the disk, then a disk can be sanitized simply by throwing away the cryptographic key in question.

One of the simplest ways to encrypt data on a disk is to use a cryptographic filesystem. Such filesystems can operate on a file-by-file basis, as is the case with Matt Blaze's Cryptographic File System[a] and Microsoft's Encrypted File System, or they can operate on individual blocks, as is the case with PGP:Disk.

Another approach is to use an active hardware device that sits between the computer and the hard disk. Such devices have been made by a variety of manufacturers for both tape drives and disk drives.

The cryptographic approach has also been applied to the problem of email sanitization. The system, developed in the 1990s by a company that was coyly known as Disappearing Ink , turned ordinary HTML email into JavaScript-enabled email that contained a small decryption engine and a block of encrypted data. Each message would have a certain date, D, after which it could not be read. When the engine was run by the receiving mail client, the engine would download the decryption key for day D from the Internet and, if the key was still available, decrypt the message. Disappearing Ink promised that on day D +1, it would delete the key for day D. The Disappearing Ink system couldn't protect against printouts or malicious pastings of the message text into an ordinary word processor, but it did provide a system whereby cooperating email partners could assure that all copies of messages in their control (including copies on backup tapes) would be deleted after a certain date.

All of the schemes discussed in this section rely on the ability to delete a key properly. Deleting keys may be difficult in practice, a problem discussed by both Crescenzo et al.[b] and Gutmann.[c]


[a] Matt Blaze, "A Cryptographic File System for Unix," 1st ACM Conference on Communications and Computing Security (Nov. 1993), 916.

[b] Giovanni Di Crescenzo, Niels Fergurson, Russell Impagliazzo, and Markus Jakobsson, "How to Forget a Secret," 16th International Symposium on Theoretical Aspects of Computer Science (STACS '99) (Springer Verlag, 1999), 500509; http://www.macfergus.com/niels/pubs/forget.html.

[c] Peter Gutmann, "Secure Deletion of Data from Magnetic and Solid-State Memory," Sixth USENIX Security Symposium Proceedings (1996); http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html.

15.3.2. Add-On Software

Although 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:


Existing files (Level 0 and Level 1 data)

Programs such as Norton Disk Doctor, PGP, and the Linux shred command have the ability to delete specific files securely. These features typically are implemented by opening the disk file through the operating system, seeking to the beginning of the file, and repeatedly issuing the write( ) system call.


Free blocks (Level 2 and Level 3 data)

A program can sanitize the contents of blocks on the free list using two approaches. The easiest technique is for the program to open a file for writing and write to the file until the file fills the entire disk. The operating system necessarily allocates most or all of the disk's available free space to the new file. A problem with this approach is that the computer necessarily spends some time with no free disk space available; this can impact normal operations. A second problem is that it does not overwrite files that are small enough to be stored in the Windows MFT or in the Unix inode. Nevertheless, Microsoft's CIPHER.EXE, distributed with the Windows operating system, uses this technique to sanitize blocks on the free list.

A second technique is to have a program that understands the computer's filesystem open the raw disk device, interrogate the list of free blocks, and systematically overwrite the contents of each block on the free list. The advantage of this technique is that it does not compromise the computer's "free space," but this technique requires much closer integration with the computer's operating system. This approach should not be employed on a disk that is actually in use by the filesystem.


Slack space (Level 3 data)

Although disk drives typically write data in 512-byte blocks, many operating systems allocate storage in clusters that consist of two, four, eight, or more blocks. If a file consists of only a few bytes, it is not uncommon for an operating system to write only the first block of the cluster and leave the rest with their previous contents: this is both a performance optimization, because it takes less time to write one block than four, and a memory optimization, because the data written to the disk needs to come from somewhere. The unused blocks at the end of the cluster are frequently referred to as slack space. They can contain the contents of older files that have long since been deleted.


The entire disk (Level 1, 2, and 3)

A number of programs simply overwrite the contents of the entire disk. These programs typically are run from bootable floppy disks or CD-ROMs and are typified by DBAN (Dirk's Boot and Nuke).

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 Modifications

An 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]

[17] Remy Card, "Announce 0.4" (Oct. 7, 1996); http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/packages/ext2fs/old/announce.0.4.

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.

[18] Steven Bauer and Nissanka B. Priyantha, "Secure Data Deletion for Linux File Systems," Proceedings of the 10th USENIX Security Symposium (2001), 153164.

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.

Even after emptying the trash, deleted files may still be recovered using special data-recovery software. To delete files so that they cannot be recovered, choose Finder Secure Empty Trash. Files deleted in this way are overwritten completely by meaningless data. This may take some time, depending on the size of the file. You may want to use Secure Empty Trash if you sell or give away your computer.

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:

  • Because Secure Empty Trash is such a slow procedure, it seems that it would be advantageous to be able to specify files to be erased securely on a file-by-file basis. However, there is no way to make such distinctions.

  • Likewise, there is no way to securely erase a specific file but leave the other files in the Trash untouched. This poses an inconvenience to users who habitually keep hundreds or thousands of files in their Trash directories and who wish to securely delete a single file from time to time. (There is a rather straightforward, albeit annoying, workaround for this problem: simply move all of the files that are in the Trash into a second, temporary directory, leaving behind the files to be sanitized. Choose Secure Empty Trash. Finally, move the files from the temporary directory back into the Trash.)

  • If the user inadvertently chooses Empty Trash... rather than Secure Empty Trash, there is no way to go back and securely overwrite the disk blocks once the files have been unlinked from the Trash directory.

  • Implementing Secure Empty Trash in the Finder, rather than in the operating system's kernel, means that there is no way to securely delete files that are deleted by programs other than the Finder (e.g., using rm or Emacs). Likewise, the contents of temporary files that are created and then deleted will not be sanitized.

  • There is no way to remove from a disk the information that was contained in files that have been "overwritten" using the Save As... feature of many document-based applications. That's because Save As is implemented by a four-step process that involves saving the requested file to a temporary file, renaming the file to be overwritten to a temporary name, renaming the new file to the final destination filename, and finally unlinking the file being "overwritten." In this way, no data is lost if the computer fails during the procedure. Unfortunately, the interface promises that the new file will "overwrite" the original file, as demonstrated in Figure 15-1.

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


  • Finally, by the time you are thinking of selling or giving away your computer, it's too late! The files have already been unlinked and can no longer be "securely emptied!"

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 haphazardly


While 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.



Security and Usability. Designing Secure Systems that People Can Use
Security and Usability: Designing Secure Systems That People Can Use
ISBN: 0596008279
EAN: 2147483647
Year: 2004
Pages: 295

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net