Feature request: include all backup files into a single tar
IPCop's backup process is too rigid, inconsistent in several ways, and doesn't lend itself to
user intuition or control. IPCop is in control, and allows no deviation, misunderstanding, or user
error.
inconsistent: must strip date/time from INSTALL restore, but need to keep date/time for commandline restore, mounting USB, and (to some extent) importing. .KEY file MUST be exported, but
although you can backup to a mounted USB, you can't export to a mounted USB.
common user errors: Failing to do disaster recovery restores during the install phase, but attempting
from the “more comfortable” GUI instead. Improperly renaming files. User expects the same
renaming requirements for backup, (and .KEY file import) to be implemented in mounted USB
restore.
Including all three of the backup elements (.dat, .time, .key) into a single file can lead to eliminating
many of these problems.
From a security standpoint it adds a very tiny risk – someone with access to the internal web
interface and has web administrator access can download both a key and an encrypted document
and use brute-force to find the password. I don't see this as a legitimate concern. Secondly, it
makes it difficult for the security paranoid to store the encrypted key separately from the backup
files. However, it is not impossible – those whose security practices are super high will understand
these details, and can simply remove the key from the tar file and store it separately. The burden of
knowledge will be on the high end user, instead of the low end user.
So in summary, the request is to include an encrypted.key of the backup.key in /var/ipcop/backup,
and to modify the backup file to be a tar of the encrypted .DAT, the encrypted.key, and the .TIME
comment file.
Implementation feature A: (re)create encrypted key file with password change.
 during installation (when you are handed the backup password), create backup.key, and the
encrypted hostname.domainname.backup.key file.
 during /bin/setup – change backup password: replace the encrypted key file. touch
backup.key so date is identical.
 user MAY change password using linux passwd function – which would be harder to
intercept. Probably can safely ignore this case, since the backup account is really ONLY
used as a way to “validate” the password during export. The linux user account technically
has no vital connection to encrypting or decrypting backups.
Implementation feature B: during a backup, do some sanity checks. check for presence / sync'd
timestamp of backup.key and encrypted key. These checks COULD be skipped, since they should
only occur with fairly blatant user driven error.
 backup.key may have been replaced by hand without updating encrypted key. Invoke a
“wizard” process to “fix” the backup system. If wizard fails, then ?delete? the outdated
encryption key and continue with backup.
◦ ask for backup password – confirm correct, re-create encryption key and touch
timestamps.
◦ if mounted=harddrive, test if existing backups were “broken” by the backup.key. If not
a tar file when decrypted (aka backup.key has changed), then offer to delete them.
◦ if mounted=usb, then don't test backups? Only test hostname.domainname backups?
Implementation feature C: rework ipcopbkcfg and ipcoprestore to work with a single .tar backup
file.
if backup
 sanity check keys (exist backup.key, exist encrypted.key, time-sync'd keys)
◦ if not exist backup.key (nasty user error condition – user has deleted a critical file)
▪ if exist encrypted key, we can rescue the backup.key,
 run fix wizard (ask password, restore backup key, IF HARD DISK MOUNTED,
check existing DAT files for validity, and urge to delete if invalid)
▪ else if exist .DAT files, we can rescue the backup.key from one of them
 run fix wizard (ask password, restore backup key, IF HARD DISK MOUNTED,
check existing DAT files for validity, and urge to delete if invalid)
▪ else create random backup.key
 run fix wizard (ask password, create encrypted key, IF HARD DISK
MOUNTED, urge to delete existing DAT files (exist, but no encrypted.keys
apparently).
◦ if timestamp is different (user manually replaced backup.key)
▪ run fix wizard (ask password, create encrypted key, IF HARD DISK MOUNTED,
check existing DAT files for validity, and urge to delete if invalid)
◦ if not exist encrypted key,
▪ run fix wizard (ask password, create encrypted key, IF HARD DISK MOUNTED,
check existing DAT files for validity, and urge to delete if invalid).
◦ [At this point everything should be fixed. Potentially there is no encrypted KEY file (if
the user failed to supply the correct backup password. Sanity checks are over – begin
the backup process]
 create backup.DAT
 tar .DAT, .TIME (comment) and encrypted.key (if available)
if import / list
 just try existing backup.key (covers case of no embedded key, and speeds things up in the
most common case...).
 if existing didn't work, extract encrypted key. md5 compare to existing (well, no need to
compare really, since if it WAS the same, it would have decrypted in the first step...)
◦ if different, warn wizard
▪ ask for backup password
▪ unencrypt to temporary location, compare with backup.key (of course it is different
– otherwise step1 would have worked....)
 if different, warn about importing – only to be used for disaster recovery. Ask for
“I agree”. Re-encrypt with current backup.key.
 if embedded key exists, replace encrypted key with current one (so downloading it uses
uptodate password). They are, afterall, IMPORTING. Perhaps report that the password they
just used has been replaced with the current password. (placed at the end to cover the case if
the first step succeeds, and we haven't checked yet if the encrypted.key matches).
if restore
 just try existing backup.key (covers case of no embedded key, and speeds things up in the

most common case...).
if existing didn't work, extract encrypted key. md5 compare to existing (well, no need to
compare really, since if it WAS the same, it would have decrypted in the first step...)
◦ if different, warn wizard
▪ ask for backup key
▪ unencypt to temp location, compare with backup.key (of course it is different,
otherwise step1 would have worked...)
 if different, warn about restoring – only for disaster recovery. ask for “I agree”.
Probably with the restore, replace existing backup.key/encrypted.key with this
“new” one. Vital to restore backup.key/encrypted.key during INSTALL restore –
where currently these files don't exist yet. If backup.key already exists, then we
have a decision to make. Current situation forces a restore in this case, so that
would be the best bet – at this point ALWAYS restore both .key files.
Alternative to a single .tar backup, with many of the same internal requirements..
Feature/bug request: change the export key name to
hostname.domainname.backup.key
-users have no idea that the “behind the scenes” name is backup.key. They may very well
want to have the name sorted together in the backup folder. I know that my immediate inclination
is to rename the file. Also, when told to “strip out the date” from the dat file, and “make the
hostname and domainname exact”, a user tends to want to strip off the backup prefix also, so that
the filenames look identical except for .dat and .key. (Yes, I know that is not stated in the
instructions, but I want to do that, and I've seen other users do that in the forums with their
questions)
-good time to change would be at a new version level – when backups from one are not
compatible for being restored to the other. However, I would leave in “backup compatibility” in the
form of *.key as well, in case someone is following older instructions etc.
Feature request: when restoring, look for *.key files.
Prefer hostname.domainname.backup.key. second preference is backup.hostname.domainname.key.
Third preference is hostname.domainname.key. Finally, attempt to decrypt with any .key file
present (why not?) If none produce a valid tar file, then inform user of failure.
Feature request: export key with backup when USB mounted
Implementation summary: A backup is useless for disaster recovery without the export key, so it
should not be possible to create a backup without the exported key being present.
 if not exist hostname.domainname.backup.key, then export encryption key along with the
backup.
 if exist and different MD5sum, and other .DAT exist (possibly because: 1.) backup password
changed – same “contents”, different md5 2.) different computer, same domain/hostname –
in this case you “break” the other backups, or 3.) complete user stupidity), then rename the
old key to H.D.backup.oldpassword1.key and export the key. If no other DAT files exist, I
would assume it is safe to overwrite the DAT.
Implementation considerations:
1. this change involves the backup password. I don't think we want to prompt the user for the
backup password in order to CREATE a backup-although that might not be the worst thing
in the world (though somehow inform them how to change the password if it isn't correct).
I'm thinking that an encrypted key file would sit beside backup.key in /var/ipcop/backup,
and you just copy that. This means that logic is needed to ensure that backup.key doesn't
change without the encrypted key changing in sync.
2. The security implication is that someone can get a copy of our encrypted key without
knowing the password. That's probably not really a problem. They have to have access to
the ipcop device to insert a USB key, and have admin web access in order to mount it and
request a backup. Having it exist on the IPCop box beside the unencrypted file is obviously
not a problem.
3. A side effect is that we can “offer” to export the key without ever asking for a password. I
think that would be a good benefit, since I find the password confusing. Again, the person
already has admin rights to the console, and an encrypted file is supposed to be safe. (Yes,
preventing access to the key adds one more tiny step in preventing a brute force attack – I'd
consider that inconsequential in this case.)
Implementation feature A: (re)create encrypted key file with password change.
 during installation (when you are handed the backup key), create backup.key, and the
encrypted hostname.domainname.backup.key file.
 during /bin/setup – change backup password: replace the encrypted key file. touch
backup.key so date is identical.
 user MAY change using linux passwd function. Probably can safely ignore this case, since
the backup account is really ONLY used as a way to “validate” the password during export.
The linux user account technically has no vital connection to encrypting or decrypting
backups.
Implementation feature B: during a backup, check for sync'd timestamp of backup.key and
encrypted key
 backup.key may have been replaced by hand without updating encrypted key. Invoke a
“wizard” process to “fix” the backup system. If wizard fails, then ?delete? the outdated
encryption key and continue with backup.
◦ ask for backup password – confirm correct, re-create encryption key and touch
timestamp.
◦ if mounted=harddrive, test if existing backups were “broken” by the backup.key. If not
a tar file when decrypted (aka backup.key has changed), then offer to delete them.
◦ if mounted=usb, then don't test backups? Only test hostname.domainname backups?
Implementation feature C: during a restore, use any .KEY file present.
 test if backup.key decrypts the .DAT file with existing backup.key. If not, then look for an
encrypted *.KEY file and run “fix” wizard.
◦ ask for backup password
◦ unencypt to temp location, compare with backup.key
▪ if same, restore
▪ if different, warn about restoring – only for disaster recovery. ask for “I agree”.
Implementation feature D: during an import, use any .KEY file present and re-encrypt
 test if backup.key decrypts the .DAT file with existing backup.key. If not, then look for an
encrypted *.KEY file and run “fix” wizard.
◦ ask for backup password
◦ unencypt to temp location, compare with backup.key
▪ if same, import
▪ if different, warn about importing – only to be used for disaster recovery. Ask for “I
agree”. decrypt and re-encrypt with current key, import.
backup
-if not exist backup.key (nasty user error condition – user has deleted a critical file)
-if exist encrypted key,
-run fix wizard (ask password, restore backup key, IF HARD DISK MOUNTED,
check existing DAT files for validity, and urge to delete if invalid)
-else create random
-run fix wizard (ask password, create encrypted key, IF HARD DISK MOUNTED,
check existing DAT files for validity, and urge to delete if invalid)
-if timestamp is different (manual replaced backup.key)
-run fix wizard (ask password, create encrypted key, IF HARD DISK MOUNTED, check
existing DAT files for validity, and urge to delete if invalid)
-if not exist encrypted key,
-run fix wizard (ask password, create encrypted key, IF HARD DISK MOUNTED, check
existing DAT files for validity, and urge to delete if invalid). Allow backup without worrying about
.key if password fails (same situation as present day).
[At this point everything should be fixed. Potentially there is no encrypted KEY file (if the user
failed to supply the correct backup password. Sanity checks are over – begin the backup process]
-if harddisk
-backup without worrying about .key. We don't need the encrypted key on the HD.
(Actually, since this is implemented by “ipcopbkcfg” which doesn't know what is mounted, it can
follow the same logic as the USB – it just isn't necessary, but it wouldn't hurt either...)
-if usb
-if not exist encrypted key (in IPCOP)
-write backup and ignore existing keys (user created error condition – same effect as
today)
-if exist encrypted key (IN IPCOP)
-if not exist hostname.domainname.backup.key
-write backup and export key
-if exist hostname.domainname.backup.key
-if same md5, backup silently – no error here.
-if different md5, rename to oldpassword1.key, write backup and export key.
-if exist other DATs, they might not work anymore with the new
export key. LOTS of trouble to try and test this... However, if we try to restore with the “*.key”
approach, it should work anyway.
-if download (backup to harddrive, save/download to web admin's computer)
-can't do anything. If we could “check the directory they saved the file to” for the existence
of a named file, we could offer the key file. I'm sure that is not possible.