Truecrypt containers revealing file properties in MFT after deletion

[onshen]

Using Windows 7 Home Premium

I have found that when i delete a Truecrypt container with data inside, its previously encrypted contents become listed in the Master File Table and can be browsed and partly recovered by using the Recuva piece of software. File names, file sizes, file locations, its all there. I just tested it twice by creating new containers and they spilled the content into the MFT both times, which i could view with Recuva. The data was definitely not listed in the MFT beforehand when viewing it with the Recuva tool.

So what is supposed to be sensitive data can therefore be accessed? Am I missing something because this would appear to be a massive security hole in Truecrypt. Apologies if this is a well known feature but i am new to these matters and have never heard anyone speak of this particular issue.

Many people put their faith in truecrypt but in my experience all an adversary would need to do is delete the TC container then run Recuva to see what was being hidden. To see a list of the file extensions, names and sizes may well be enough in some situations even if no items can be recovered intact. I know i can use software to wipe files that are marked for deletion in the MFT to prevent recovery but that measure becomes irrelevant if the adversary has access to the system or makes a duplicate of the TC container to take away, delete and examine.

How do i stop the contents of a TC container becoming entered in the MFT upon its deletion. Is this how TC is supposed to behave?

Thanks in advance

[dantz]

There are two MFT's in your scenario. Your NTFS-formatted partition has an MFT. If you create a file-hosted container inside a specific partition then that partition's MFT stores data about the name, size, location etc. of the newly created file, but it does NOT store any of the encrypted volume's contents such as encrypted folder and filenames. (Or at least, it's not supposed to and I've never heard of it happening except in the case of data leakage, and in that case the data is stored outside the TrueCrypt volume, e.g. temp files, paging file etc).

The TrueCrypt volume also contains an MFT (assuming it was formatted NTFS), although this is only accessible while the volume is mounted.

I don't see how TC could be leaving any of this sort of information behind in the partition's MFT. What is your exact procedure? Are you merely deleting the contents of the mounted volume and then exploring the volume's data remnants using Recuva or similar? Or are you actually dismounting the volume, deleting the container file and then exploring the partition's MFT? Also, are you rebooting at any time? If you would explain your procedure clearly and it makes sense then I'll be happy to attempt to duplicate your results.

Also, do you have "Previous versions" enabled for the files within the TrueCrypt volume? This feature is supported by either System Restore or Windows Backup, depending on how you've set things up. I've never tried it on a TrueCrypt volume before, so I'm not sure if it's possible, but if that's what you've done then I'll give it a shot.

[imseca]

I'm interested to this topic. It seems that many programmers are recently challenge to break Truecrypt. But honestly, if the file is critically for me I don't just delete it without using file shredder.

[Enigm]

RTFM !!

Journaling File Systems

When a file-hosted TrueCrypt container is stored in a journaling file system (such as NTFS), a copy of the TrueCrypt container (or of its fragment) may remain in the free space on the host volume. This may have various security implications. For example, if you change the volume password/keyfile(s) and an adversary finds the old copy or fragment (the old header) of the TrueCrypt volume, he might use it to mount the volume using an old compromised password (and/or using compromised keyfiles that were necessary to mount the volume before the volume header was re-encrypted). Some journaling file systems also internally record file access times and other potentially sensitive information. If you need plausible deniability, you must not store file-hosted TrueCrypt containers in journaling file systems. To prevent possible security issues related to journaling file systems, do one the following:

Use a partition/device-hosted TrueCrypt volume instead of file-hosted.
Store the container in a non-journaling file system (for example, FAT32).
http://www.truecrypt.org/docs/?s=jou...g-file-systems

I simply can not comprehend why people don't read the manual
for software like TC !

[onshen]

Thanks all and Enigm. Confess I'm not an IT person, when i set up my computer i had never heard the phrase journaling file system. When trying to digest the raft of technical info on the TC webpage, i obvously passed through this passage without understanding what its implications were and how they related to me.

I undertand the frustration of thinking people don't read the manual but in my defence i did spend hours reading their website. Problem is, when you've never heard of paging files or trim operations, digesting it all becomes more difficult and its easy to miss something. In my view, it wouldnt do any harm if they made a handful of such fundamental points more salient on their site.

Thanks again.

[TheWindBringeth]

I don't think the issue described in that snippet from the TC manual is consistent with what Onshen originally described. I think Onshen needed to respond to dantz.