I am worried about a potential security loophole when using Truecrypt.
Basically, if I move a file into a Truecrypt volume, doesn’t the data still
exist in unencrypted form in its original location? The analogy I am thinking
of here is that deleting a file just deletes the file index but not the
data.
What do I need to do ensure that no unencrypted remnants are left behind
when I move a file into a Truecrypt volume?
You raise a very important point for the security minded among us. Moving a
file into a TrueCrypt volume almost certainly leaves behind the very thing
you’re trying to secure.
In fact, your analogy isn’t an analogy at all – it’s pretty much exactly how
the scenario plays out.
To understand why that is we need to examine the whole concept of “moving” a
file, how it works, and why it works the way it does.
And, of course, give you an extra step to keep your information secure.
]]>
A Move is a Move is a…
As it turns out there are two different ways that a file move might actually happen:
-
A simple directory listing update
-
A file copy followed by a delete
Let’s look at both, and dive into why the second one has to exist, and why it’s technically a security issue if not understood.
A Move On The Same Volume
If you move a file from one folder to another, and both folders exist on the same disk drive – specifically the same volume on the same disk drive – then Windows doesn’t need to touch the file’s data at all.
For example, let’s say you want to move the file c:\documents\example.doc to a different folder: c:\backup\saved_documents.
Since the actual data for the file would be on the same disk (C: in this example) before and after the move, there’s actually no need to move the data at all.
Instead, Windows simply updates the information in the c:\backup\saved_documents folder to say “the file example.doc is here”, and then removes that same information from the c:\documents folder.
It’s a very quick operation, since the data doesn’t move at all.
A Move from One Volume to Another
Now let’s say you want to move a file from one disk to another. Perhaps you want to move c:\documents\example.doc to d:\anotherfolder.
In this case the actual data associated with the file must be moved from one disk to another. The process is:
-
The file c:\documents\example.doc is copied to the folder d:\anotherfolder.
-
c:\documents\example.doc is then deleted (but only if that copy suceeded).
That’s why a move between drives often takes longer; it’s not enough to just update a couple of folder entries, the actual data in the file needs to be copied.
And therein lies the security concern.
A Delete is a Delete is a …
As you problably know by now, deleting a file doesn’t actually delete the data that the file contained. In fact all that really happens is the information in the folder that says “the file is here” is simply removed. The disk space occuipied by the file’s data is now considered “empty”, but the contents are not overwritten.
When a move operation is a copy followed by a delete that’s exactly what happens; the original file in its original location is deleted, but the data is not overwritten.
Until it is overwritten – typically by some other file being written to the same location on the hard disk – that data is potentially recoverable.
Truecrypt Volumes are Another Drive
Truecrypt mounts encrypted volumes as virtual drives. When you “mount” a Truecrypt volume for access by provided the appropriate passphrase, another drive appears on your system that you can then use to access the unencrypted files contained within the container.
It’s another drive.
Which means a move of a file from aother drive into the Truecrypt drive is implemented as a copy and delete.
Leaving the original unencrypted file potentially recoverable on the original drive.
Erasing Tracks
Fortunately the solution is actually pretty simple.
Wipe the free space on the original drive after moving your files around.
Wiping the free space does nothing more than write data to all the areas on the disk that are currently unused, and thus in the process would overwrite the space formerly occupied by your moved file(s).
There are several solutions, two of the simplest are SDelete, a free command line utility from Microsoft that includes a free space wiper, or CCleaner, a free disk cleaning tool that includes a free space wiper as well.
Security is Not Always Obvious
Deleted files are just the tip of a larger iceberg when it comes to possible unexpected exposure of sensitive data.
For example depending on what program you’re using simply editing a file on an encrypted drive could cause an unencrypted copy to be placed in a temporary file on a non-encrypted drive. Even when the temporary file is deleted is might still be recoverable like any other deleted file.
If security and/or secrecy are important then it’s equally important to understand not only how Windows works, as in the scenario that brought us here, but how your specific set of tools work as well.
Rather than wiping all the free space on the source drive, which could take a LONG time… just copy the file to the truecrypt volume and then do a secure delete on the original file… that way only the file has to be wiped, rather than (potentially) terabytes of mostly nothing.
Wow, I am so glad for this article. I’ve used TC for a long time, and then use a search to find the original file still in place and visible. Now I understand why.
phillip, what is a ‘secure delete’ compared to regular ‘delete’?
When I move a file from an unencrypted drive to an encrypted drive I copy the file to the encrypted drive and then securely wipe the original file with a file shredding utility.
Yes, my utilities suite (TuneUp) adds a secure delete command to a file’s context menu.
Presumably the file’s remains would be unlikely to survive a defrag, and doesn’t Windows 7 defrag continuously by default?
Incidentally, it’s curious that in Outlook Express (not sure about other email clients) deleting a message actually doubles the amount of space it occupies on the hard drive, as in effect it is copied to the deleted items folder. The space is only reclaimed (and the message completely eliminated) after its original folder is compacted and the deleted items folder is emptied.
15-Dec-2012
Thanks for the info re TrueCrypt. Really good to know — but it raises all sorts of related questions that I had ever considered before. May I assume that the processes you describe also apply to DropBox and BoxCrypt as they also are virtual drives? When I move a file into Dropox, it is deleted from the disk drive? When I encrypt a file by moving it into BoxCrypt, the origial file is deleted from the original disk? When a file in DropBox is opened from a remote device and is then worked on, there is a copy left on the remote device? And what about individual files that are encrypted but not ‘moved’ to another drive — such as a when I use Office to password protect an Excel file, is the data still in the clear some where? Or when I use AxCrypt to password protect an idividual file and work on it, is the data left on the disk drive somewhere?
15-Dec-2012
Re: AxCrypt @ DickW
I believe AxCrypt shreds the plain original on encryption. Therefore, it might even be used to encrypt a file first, then move it onto the TruCrypt mounted volume without leaving any traces behind.
Great article Leo and as simple as you could put it. Just one little question..Would Defraggler overwrite the original file (Especially if you defrag Freespace and allow fragmentation under advanced options), or would that not be secure enough ?. I myself do overwrite Freespace fairly often so am probably OK.
15-Dec-2012
Sorry Leo
Did overlook BAW30s post. I myself do delete the original file/folder to the recycle bin and then overwrite with CCleaner.
Hi Leo,
Thanks for uncovering the ‘dark secrets’ of Windows! Like any layman, I have been believing that once my file/data is deleted, I’m safe!
Mmm..! Not any more!
One “qucik & dirty” way to – erm – make things more difficult to retrieve, is to just do a “Copy”, and then fire up the original file (e.g. an Word or Excel file), delete everything in it, and then save it again under the same name, then delete that “new” file.So anyone retrieving that file would get an empty file…
However… when the program saves, it actually saves a NEW copy, before THEN deleting the old one… so I guess THAT old version is still there waiting to be recovered… Hmmm.
18-Dec-2012
Oh, And another thing…. S’pose I have a file that, when saved, is say half a cluster long. In the middle of that cluster is now an “EoF” marker. But what follows it ? When the new file is saved, is the rest of the cluster (after the EoF marker) filled with zeros; or is it left unchanged ?
And similarly… if the old version extended, say, to five clusters, and the new version is less than one cluster long, are the remaining four now-redundant clusters over-written, or are they left unchanged?
@Robin
That part of those clusters which remains unwritten is called slack space or cluster tips. Whether a program fills these with zeros or random data would be a function of each individual program. As far as I know, most programs probably don’t do this. There are utilities which wipe slack space, but not being that paranoid, I haven’t use any of them.
As for the second part of your question, neither. The old file really isn’t overwritten at all. A new version of the file is written, and the old one is simply deleted, and could be recovered by a file recovery utility.