Secure sync of TrueCrypt containers

Question

Need to sync arbitrary files within two TrueCrypt containers; one container is a backup, the other the one actively used by me, both are local during the transaction.

Current concern security wise is that there would be "data leaks" that would result from the sync tool being used; for example, the sync tool producing indexes that when be stored unencrypted on disk.

Any suggestions, or insights into the possible attack vectors that might result from using a sync tool as described?

UPDATE: I've removed the reference to "on Windows", since while the answers, and question they addressed deal with Windows, these answers (putting aside the sync tools used) apply to Windows, Linux, OSX, etc -- and I would not want the person reading the title of the question to believe the question only applies to Windows, since it does not, and given the importance of securely executing backups of encrypted data, I thought it best to make the question as accessible as possible.

Answer 1

Current concern security wise is that there would be "data leaks" that would result from the sync tool being used; for example, the sync tool producing indexes that when be stored unencrypted on disk.

You are correct to believe there is a risk of data leaking as a result of indexes. How much of a risk that is depends on what exactly is indexed.

A while ago, I lead a project to build something a little like dropbox. To compare directories across runs, we used the path name, a sha256 hash of the contents if not already computed, various timestamp information etc.

Clearly, if a sync tool were to store this information about files stored in an encrypted container, the attacker would also have access to them. The exact risk of that really depends on your given scenario.

I suspect, however, there are bigger risks in play than you think. Let's assume, for example, that on opening a file, your innocent piece of software creates a copy so as to not corrupt the individual - however, you've mounted the file system read-only, so it handily creates a copy of the file in your temp folder. Great, except - it just copied your data from an encrypted partition to an unencrypted one, thereby leaking it.

The same could be true of sync tools. This would be a fairly bad way to build one - but it is conceivable the tool could copy files to a temporary location in progress. Again, you have a leak problem.

To be a bit more realistic - let's assume the sync tool copies the files in memory by mmaping them and copying between them. What if you experience a system crash during this update and your app happens to be core dumped? Heck, what happens if the truecrypt drivers' memory is core dumped too? It might well contain unencrypted file data.

The fact of the matter is you're unlikely to be able to deduce the contents of entire files from any of these scenarios - but like getting damp in your house, something will leak, somewhere. The only way to be totally sure you have everything wrapped up is to do the obvious: encrypt the whole lot. Swap, disk, everything.

So to answer the question you asked: an attacker can clean whatever the sync tool stores. Have a look. Grab Process Monitor, see where it is storing data and then look at what's in it. That'll tell you exactly what data is being leaked.

To answer the question you didn't ask: there's no way to be absolutely certain you are not going to leak something using a truecrypt container on an unencrypted system.

Answer 2

The question is now "how can I do file level synchronization between two open TrueCrypt containers on a single host without any local leakage of data from the sync tool?".

The answer is you probably can't - certainly none of the well established file sync tools (unison, rsync, SyncToy, etc.) promise not to have such leaks. Their focus is purely on being efficient and reliable.

This is presumably because doing so would involve a lot of very hard work to support an obscure use case. Firstly, if someone can get close enough to your machine to take advantage of this sort of leakage, then you have worse problems. And secondly, if you really need to control for this vulnerability, then there are a couple of steps you can take that work regardless of the sync tool used:

• use full disk encryption so any leaks are also encrypted.
• sync closed volumes, eliminating all sync tool leakage at the cost of performance.

Note: I specify sync-tool leakage here since there are other sorts of leaks: differential analysis of the containers, or leaks from the tools you use to manipulate the contents of container once open. But again, if the attacker has compromised the machine enough to perform these attacks, then you have worse problems. Why do a difficult differential analysis of container changes when you can just replace the TrueCrypt binary with something that emails the contents of the container to you?

(One last point: there are many good open source tools for file syncing, so a third alternative is to fork them into your own super-secure version.)

Answer 3

IMO the easiest and fastest way to sync is mounting two containers and using your favorite tool to sync them (i kind of like robocopy). When you have a backup use a DIFFERENT container. If one container is a copy of another than someone who gets access to both can look at the sectors that change and use that information.

If you make two containers than that wont be an issue because everything would be different regardless if the same files in the same places are in there.

I don't know which 'sync tool' you may use but if it isn't storing temporary information (say your local temp area) while syncing you should be fine. Some people think you should disable virtual memory when using encryption but IMO that isn't required and just paranoia.

-edit- If your backup can be accessed by someone repeatedly (instead of just the current and backup the above assumes) you may consider making a new container each time and copying all the data as recommended by truecrypt http://www.truecrypt.org/docs/?s=how-to-back-up-securely

-edit2- It now appears you are asking about leaks when using tools. You didn't mention any tools so i can't comment much. As long as the tool doesn't make temporary files when copying or has a db/information outside of the container (sometime it is in the users app data directory) than you should be fine. As i mention above i like robocopy which is simply an advance command like file copy program. See http://ss64.com/nt/robocopy.html I personally don't copy attibute data nor want files deleted in the remote volume. I think i normally use robocopy srcDriveOrFolder dst /S /W:1 /R:1