5

Given a (TrueCrypt) encrypted volume on one device A, what is the more secure way to back it up via a VPN connection to the physically far away device B?

  • Backup the data: Requires the volume to be mounted on both devices, which a physical intruder could abuse to obtain one of them while the container is open, thus rendering the encryption useless. On the other hand, an incremental backup is easy. The transmission itself should of course still be secured...
  • Backup the container: No device requires the containers to remain open. However, unless small file changes only change small portions of the container and these changes are tracked, this quickly involves a lot of unnecessary data traffic
  • Backup individually encrypted files instead (not using TrueCrypt but e.g. encFs): Seems to eliminate the disadvantages of the other two methods. But since the encryption should be bound to one single passphrase/keyfile/... this increases the risk of a known-plaintext attack, should too many trivial files happen to be encrypted.

So, is there the secure backup solution?

Tobias Kienzler
  • 7,578
  • 10
  • 43
  • 66
  • All of these can be equally secure - which you choose will not depend on security functionality. What are the constraints you are working within? If the constraint is lowest traffic volume can you update the question accordingly? – Rory Alsop Oct 03 '12 at 13:00
  • @RoryAlsop I wouldn't say traffic volume is a constraint, but (before [Polynomial's answer](http://security.stackexchange.com/a/21023/3272)) a non-diff-based 500GB TrueCrypt container would have been too much... The only "constraint" is that currently our single NAS uses a TrueCrypt container, but that could be changed. – Tobias Kienzler Oct 03 '12 at 13:19

2 Answers2

4

Back it up using diff-based copying of the encrypted volume image. TrueCrypt uses XTS as its mode of operation, which means at most you'll alter two encrypted sectors (sector n and sector n+1) per unencrypted sector you modify. Every time you modify a sector (or file) on the disk, it'll just have to upload that sector and the next sector.

Sectors are 4096 bytes by default on NTFS, which means you'll transfer 8kB minimum each time you make a change. However, in most cases writes will be to adjacent sectors, which means that if you write 1MB to disk, you'll actually only have to back up 1MB + 4kB, since the cascading effect means that only one extra sector is altered.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • Thanks for this information. Since @SeanMadden [mentioned it](http://security.stackexchange.com/a/21031/3272), what will happen if I try and backup an _unmounted_ container? Can this yield an inconsitent state corrupting the entire container? – Tobias Kienzler Oct 03 '12 at 13:57
  • It shouldn't make a difference as to whether the container is mounted or unmounted when you make the backup. The resulting backup should be in exactly the same state as the real original. – Polynomial Oct 03 '12 at 14:09
  • My comment should actually have been "... backup an _mounted_ container...". What does `rsync` do when the file it's currently backing up is being changed? And what does this mean for the TrueCrypt volume / the included ext3 filesystem? – Tobias Kienzler Oct 09 '12 at 14:40
  • 1
    I'm not sure _exactly_ how `rsync` works internally, but the way I understand it is that a transactional diff is generated on both systems, so the diff on system A is generated, uploaded to system B, then applied. To improve performance, they *usually* limit the timing on diff generation, so 7 distinct modifications inside a 10 second block will get rolled into a single diff. This helps increase network performance and ensure solid copies. I wouldn't recommend having it open on both sides at the same time, though. – Polynomial Oct 11 '12 at 18:17
3

To expand on @polynomial's answer, the binary-diff method is the correct method to use for an unmounted encrypted container (TrueCrypt, DMCrypt/LUKS, or otherwise).

The fastest (and most efficient) method I've found is to use the 'rsync' command. I'll point you at the wikipedia page that describes the algorithm in detail, suffice to say that it is optimized to handle binary data in almost precisely the way that @polynomial describes.

Cheers.

Sean Madden
  • 317
  • 3
  • 7