BackupEDGE 2.1

By Tony Lawrence
2005-05-03

Encryption

Encryption always makes my head hurt. I can understand public/private key encryption only while I'm thinking about that and nothing else. I have to keep my head down and concentrate, and if anything else distracts me, well, I lose it and get confused. So when I read :

During RSA key generation, one public and two types of private keys

are created. Standard Private Keys are protected by UNIX/Linux

system privileges. Protected Private Keys are additionally encrypted

with a passphrase. After creating and archiving the private keys,

the administrator may choose to remove those keys from the system

with the following effects during restore:



 - If a Standard Private Key exists for the archive in question, files

   are decrypted and restored automatically and transparently.

    

 - If only the Protected Private Key exists, the administrator will

    be prompted for the pass phrase before the files may be decrypted.

 

 - If neither private key exists, the user will be prompted to insert

   the appropriate Key Archive before the files may be decrypted.

.. well, my eyes glazed over. I decide that I'd trust this:

BackupEDGE uses a powerful combination of symmetric and

asymmetric algorithms to encrypt and decrypt data. It is completely

standards-based, and the methodology will be published on our web

site to assure users that standards are being followed and that no back

doors or other security holes are in place.

Somebody with a less worn-out brain can watch 'em - I'll just use the darn thing and trust it.

The first step for encryption is to turn it on. Well, no, the first step is to license it. Not everyone needs encryption, so it's an extra cost ($150.00 list) add-on. You'd then choose "Set up Encryption" form the Setup menu. You provide a passphrase (which can be stored on the hard drive for convenience), and the keys will be generated. If this is a single user machine, you'll need to help the process along so that it can generate good random numbers: I just logged into another session and did an "ls -lR /".

If a bell went off when I said "convenience", you aren't thinking about what this encryption is for. It's to encrypt files on backup media. It is to protect that data should the media fall into the wrong hands. If someone has root access to your machine and can read the passphrase stored there, you already have problems. Still, if you prefer to supply the passphrase for restores, you can elect NOT to store it locally.

You aren't going to encrypt the whole archive. That would be dangerous and pointless, and perhaps even counterproductive. As Microlite's white paper explains

Simply encapsulating an entire archive with an encryption filter
can be disastrous. For instance, if we had decided to do that in
order add encryption to our previous product to get it to market
faster, then...

1. Read-error recovery would be lost. Single byte errors could render an entire archive unrecoverable. There would be no easy way to sync back up with the encryption stream.
2. Quick File Access / Instant File Access would have been lost.
3. Standard file restore times would have increased dramatically, as the entire archive would have to be decrypted from beginning all the way to the last file to be restored.
4. CD/DVD/REV backups couldn't be bootable (the boot tracks would be encrypted).
5. System performance would suffer greatly as encryption took place. Backup and verification time windows would greatly expand.
- BackupEDGE integrated encryption encrypts only the data you specify, and avoids all of these problems!
6. Standard, hardware compressing tape drives would suffer from greatly reduced performance and capacity (unless we also chose to wrap the entire archive in a compressor such as bzip or gzip and disable hardware compression, which would take even more time and make error recovery even less likely).
7. The archive would actually be less secure! Because much of the data in backup archives is repetitive, dictionary-based attacks are possible even with access only to a single archive. Access to two or more encrypted archives could further enhance the feasibility of this attack.
- BackupEDGE first compresses data, then inserts random bytes, before encrypting it. Every backup has a new symmetric key that is created by a cryptographically strong random number generator. These features enhance archive security while shrinking the space needed to perform a backup.

So, you'll create a list of the files (wildcards are fine) that you need encrypted. That list is associated with a Domain (a domain is the list of things you want to back up) - each domain can have its own encryption list or none at all. This association also means that encryption lists are NOT applied to manual backups. Only scheduled backups (or backups done with Run Scheduled) pay attention to encryption lists. Again, if that bothers you, consider that anyone with physical access and the root password already has access to the data - this protection is for backup media. Further, anyone with such access could just change the encryption list to avoid using it. Just remember WHY we're encrypting here.

After all this, you'll be asked to create a "Decryption Key Backup". I ran into a slight problem with that: if I made it to a DVD or REV drive, I could use the "Load Decryption Keys" to restore them. But if I used a FS or URL resource (see below), the restore would not work. Microlite Tech support acknowledged that problem, but added:

It seems that Restore Key Backup doesn't deal with URLs well.

Use Restore:Restore Entire Archive instead, and select the key
backup. It will do the same thing.

Tutorial Pages:
» BackupEDGE 2.1
» New Features
» Encryption
» How do I know it's Really Encrypted?
» URL's and Filesystem Resources
» Dislikes

© Copyright 2005 A.P. Lawrence

Related Tutorials:
» How to Install PHP 5 on Linux
» How to Install Apache 2 on Linux
» How to Install MySQL 5.0 on Linux
» SMB Caching
» Mound --Bind
» Tar Wild Card Interpretation