ciphering backups

[Carlos Fernandez Riera]

I have been requested to cipher the backups on tape to ensure that data is save of ???ugly people???.

Data is saved using standard UNIX commands like tar , cpio, and dd.

I have several doubts about:
- how to accomplish this, rewriting dd and tar ? Are there any software ( free preferred) ?
-how to store the used keys ?
- What troubles will I find ?

I know this is a very wide question, and any response or experience will be of help for me.

Carlos.

[Patrick Wallek]

Here are some links I found by just searching Yahoo! with the keywords "encrypt backup unix".

I don't envy you in your task here. This sounds rather painful. Good luck.

http://www.crypto.com/papers/cfs.pdf

http://www.orbitsw.com/USA/body_tar_main.html
http://www.orbitsw.com/USA/uniback.html

[Rodney Hills]

Would it be possible to encrypt the "sensitive files" only on your system prior to a backup.

If it has to be the whole tape, then you might have to write your own.

Recommend you only use tar or cpio in that case since fbackup has a "special" format it writes to tape.

-- Rod Hills

[A. Clay Stephenson]

Actually this is not too difficult. The basic idea behind this is to create a filter that uses a random number generator. Each byte of the input is xor'ed with the 1 byte of RNG output. The xor'ed result becomes 1 byte of encrypted data.

If the RNG is restarted with the same seed then each byte of encrypted data is xor'ed with a byte of the RNG output to reproduce the plaintext. This is the wonderful feature of exclusive OR's and it constitutes the heart of an encryption scheme. All of this is only a few tens of line of C. The encrypt/decrypt engine simply becomes a filter. You could also use the crypt command.

As a simple example try this:

1) cd to some desired directory:
2) tar cvf - . | crypt "topsecret" > /tmp/secret

/tmp/secret now contains encrypted data.

To restore the data:
1) cat /tmp/secret | crypt "topsecret" | tar xvf -

By the way, commercial backup packages like OmniBack include an encrytion option (though it is really not terribly robust).

[A. Clay Stephenson]

Hi again Carlos:

I had a few minutes to spare so I threw together an encipher/decipher filter for you in less than 5 minutes. You can modify to suit your needs. If supplied with no key, it will still function but produce a fixed encode/decode sequence. This simply becomes a filter placed between your tar,cpio,dd commands and your tape device.

Compile it like this:

cc -Aa encode.c -o encode
If you don't have an ANSI/C compiler, simply convert the functions to K & R style and use the bundled C compiler.

You can test it like this:

echo "Test Stuff" | encode "Top Secret" | encode "Top Secret"
You should see "Test Stuff" output. Note that "Top Secret" is used as the key for both the encipher and decipher operations. All you have to do to make this as secure as you like is to add a more robust RNG although this silly version will probably be adequate for the vast majority of cases.

Regards, Clay

[Carlos Fernandez Riera]

Patrick: I have took a look to links... the fist seems to be very interesting ( i have to read it carefully.

Rod: It could be posible, but in the otehr hand i would make further modifications on my scripts...:-((. Thanks anyway


Clay: Yes, this another way I tought. The problem here is that adding pipes should be a performance issue, and time to backup is always a limit ( and a pain). Also tapes drivers needs to be feeded at a high speed, so the filter should work at a high speed. Thanks for the draft.

Well... anybody more can help?

[Esa-Matti Mayfield_1]

tar cf - ./data |openssl -aes-128-cbc > /dev/rmt/2m

It will prompt for password.

To restore:

openssl aes-128-cbc -d -in /dev/rmt/2m| tar xf -

It will prompt for password

[Bill Hassell]

This could be a very risky proposition when the need to encrypt the tapes could be replaced by a proper procedure. Backup tapes are crucial to survival of the data....a single rm -r * command could destroy everything just as easily as a fire. The biggest problems will be loss of the key to decode the tapes and the performance penalty due to encrypting all the data going to the tape.

For problem #1, there has to be a failsafe method to store the key without telling multiple people (which is like telling everyone the root password). And eventually, like any password, it must be changed for new tapes and now you'll need to record which tapes have which password.

For the second problem, as long as you have low performance tape drives or a very fast CPU, you shouldn't see much of a problem. But new drives such as DDS-4, DLT and Ultrium are so fast that encryption may not be fast enough to keep the drives busy, causing massive repositioning and a huge increase in backup time as well as wear on the drive.