Figure 4. Decay of file system blocks over time, files are deleted when free space is less than 20%.

In Figure 4, every time the free space drops below 20% we delete files until it is above 20% again, and then proceed with the simulation. Although this is not completely realistic, it is a reasonable model for normal usage of a pen drive. You can see a fast initial decay of the number of original blocks, which slows considerably as it nears the 20% mark. It then declines more gradually, with occasional downward steps. Worryingly, we can expect normal hard disk or pen drive usage to be more like Figure 4 - copying and deleting files while maintaining a certain amount of headroom.

Countermeasures

The best thing to do is use disk or file encryption software. For example, using Truecrypt, you can allocate the space on your pen drive to a truecrypt encrypted volume. It can then be mounted on each computer you need to use it on, and decrypted on the fly. There is still the potential for some data to be stored in unencrypted form on the computer, such as in swap space (the page file), or in caches but the problem is greatly reduced. If you don't want to use truecrypt, there are alternatives, but please choose something that uses peer-reviewed algorithms such as AES for encryption, HMAC/SHA-1 for message integrity, etc. and not Acme Proprietary WonderCrypt-128(TM). Remember also that a secure encryption algorithm is useless if you use it with an insecure key.

If you can't use disk or file encryption software, or your drives are always within a secure facility, you still need to take some action before disposal, or re-assignment. In this case it is probably best to securely erase every hard disk, whether it strictly requires it or not. For individual files, there are tools such as SDelete for Windows or wipe for Linux. These will overwrite a file with zeros, or ones or bit patterns to ensure that the data is certainly not going to be readable by a casual attacker. Wipe will also securely erase whole partitions, for example:

wipe -k /dev/hda1

will securely erase the first partition of your first IDE disk. This latter method is probably the best if you need to deal with journal-ling filesystems such as ReiserFS and ext3 as you cannot guarantee that information about the file is not held within the journal. To erase a whole disk, there are various bootable floppy or CD images available, such as Darik's Boot and Nuke. These will obviously erase Windows and DOS partitions equally well as UNIX.

Of course the hard disk may have remapped some bad sectors and there may be bits of data available in these. An attacker who can perform a surface scan of the disk may be able to recover some confidential information. This is a good argument for either using disk encryption from the start, or destroying the data by other means; however disk encryption is generally easier than degaussing or heating your media to 1500 Kelvin.

For more information on securely erasing media, see Peter Gutmann's fascinating paper Secure Deletion of Data from Magnetic and Solid-State Memory. Farmer and Venema's excellent book Forensic Discovery also deals with the topic of persistence of data on disk and in memory, as well as many other important matters.

Summary

A relatively large amount of data can persist in slack space for long periods. Whether this is an issue for you will depend on the sensitivity of your data - for example, the text of your upcoming financial results is very important to keep confidential, where as an audit of your buildings waste water systems is less likely to cause problems were it to be made public. Another factor is locality; if your data consists of records of customers, then a single record could quite easily be recovered from each block of slack space. Compare this to the secret source code for your new application - unless your competitor recovers a substantial amount of contiguous source code, they are probably better off writing their own version. Finally, your industry may also be subject to general or specific data protection and privacy laws and guidelines. All of these factors need to be taken into consideration when doing a risk assessment on the possibility of leaking confidential or secret data.

About the author

James Riden is currently writing embedded software in Bristol, UK. He is a member of the UK Honeynet Project and holds a CISSP.

Reprints or translations

Reprint or translation requests require prior approval from SecurityFocus.

© 2007 SecurityFocus

Comments?

Public comments for Infocus technical articles, as shown below, require technical merit to be published. General comments, article suggestions and feedback are encouraged but should be sent to the editorial team instead.