- 1 Secure Backup
- 2 Physical Security
- 3 Backup over a Network
- 4 Key Granularity
- 5 Backup Products
- 6 Deleting Backups
- 7 Case Study
- 8 Further Reading
This chapter is from the book
This chapter is from the book
This chapter is from the book
6.3 Backup over a Network
Backup data is vulnerable to attack at several points. If you are backing up your data onto a physical device such as a Jaz drive, then you do not need to worry about somebody sniffing on the physical connection between your computer and the drive. However, most backup techniques today involve transferring data over a network. It doesn't make sense to use strong encryption in your backups and good key recovery mechanisms, if you transfer files to a remote backup server in the clear.
The right way to back up files remotely is to perform all of the compression and encryption (in that order!) locally, and then to transfer the backups to the remote site for storage. The reason to compress before encrypting is that encrypted data contains very little redundancy, and so compression of ciphertext is not very effective. Many remote storage facilities further encrypt the data. While the encryption of the data on your local machine protects you against network attacks and from the storage server, the further encryption at the remote server is intended to protect your data from compromise of the server in the case where you have a poorly chosen passphrase. The super-encryption (encrypting encrypted data) at the remote site is a great marketing gimmick by many of the backup storage vendors, but it doesn't really buy you much because you should protect it with good keys in the first place. Furthermore, you are now running the risk of not only the loss of your passphrase, but loss of the key used by the backup server.
Another issue in the remote backup process is user authentication. If you back up your files over a network to a centralized server, make sure that the server does proper user authentication. If it does not, then even though the information on that server is unreadable, assuming it is properly encrypted, there may be nothing preventing another user from corrupting or destroying your backups.
Many remote backup facilities allow for an automatic unattended backup to be scheduled. That means that users can tell the system to make a backup in the middle of the night of files that have changed. Of course, the whole purpose of this is to perform a backup while the user is sleeping. It is unlikely that the user will want to wake up each night and enter the passphrase to derive the key for the backup. So, these systems require that the key be available to the program whenever it needs it. To accomplish this, the key must be in memory on the computer. In practice, many vendors keep the user key on disk somewhere. In either case, the key is vulnerable. The most secure systems require a passphrase to be entered whenever a backup or restore is about to take place, and they erase the key from disk and memory as soon as the work is done. Unfortunately, this is rarely the way these products operate.
Another common "feature" of many remote backup products is that they give the user a choice of key lengths and algorithms. In several cases, products offer 40-bit DES, 56-bit DES, 3-DES, and Blowfish or CAST. Average users are about as qualified to pick the bit size of their keys as they are to set the correct refresh rate on their computer monitor. The difference is that when setting the refresh rate on a monitor, you get some feedback if you select stupid settings. With crypto, you just get an insecure system. When questioned, one vendor replied that 3-DES is too slow for some users and that 40-bit is included in the product for export reasons. Huh?!? I asked him if the 40-bit version and the 3-DES version shipped as different products, and he said no. Apparently, there are companies out there that think their product is exportable if they add weak crypto to it, in addition to the strong crypto.