Backup and restore

It is important to properly manage the archiving or backup of the keystores associated with the archived EFS files. You must also manage and maintain the keystore passwords associated with the archived or backup keystores. Failure to do either of these tasks may result in data loss.

When backing up EFS encrypted files, you can use the –Z option with the backup command to back up the encrypted form of the file, along with the file’s cryptographic meta-data. Both the file data and meta-data are protected with strong encryption. This has the security advantage of protecting the backed-up file through strong encryption. It is necessary to back up the keystore of the file owner and group associated with the file that is being backed up. These key stores are located in the following files:
users keystores
/var/efs/users/user_login/*
group keystore
/var/efs/groups//keystore
efsadmin keystore
/var/efs/efs_admin/keystore

Use the restore command to restore an EFS backup (made with the backup command and –Z option). The restore command ensures that the crypto-meta data is also restored. During the restore process, it is not necessary to restore the backed-up keystores if the user has not changed the keys in their individual keystore. When a user changes their password to open their keystore, their keystore internal key is not changed. Use the efskeymgr command to change the keystore internal keys.

If the user’s internal, keystore key remains the same, the user can immediately open and decrypt the restored file using their current keystore. However, if the key internal to the user’s keystore has changed, the user must open the keystore that was backed up in association with the backed-up file. This keystore can be opened with the efskeymgr –o command. The efskeymgr command prompts the user for a password to open the keystore. This password is the one used in association with the keystore at time of the backup.

For example, assume that the user Bob’s keystore was protected with the password foo (the password ‘foo’ is not a secure password and only used in this example for simplicities sake) and a backup of Bob’s encrypted files was performed in January along with Bob’s keystore. In this example, Bob also uses foo for his AIX login password. In February, Bob changed his password to bar, which also had the effect of changing his keystore access password to bar. If, in March, Bob’s EFS files were restored, then Bob would be able to open and view these files with his current key store and password, because he did not change the keystore's internal key.

If however, it was necessary to change Bob’s keystore’s internal key (with the efskeymgr command), then by default the old keystore internal key is deprecated and left in Bob's keystore. When the user accesses the file, EFS will automatically recognize that the restored file used the old internal key, and EFS will then use the deprecated key to decrypt it. During this same access instance, EFS will convert the file over to using the new internal key. There is not a significant performance impact in the process, because it is all handled via the key store and file's crypto meta-data, and does not require that the file data is re-encrypted.

If the deprecated internal key is removed through efskeymgr, then the old keystore containing the old internal key must be restored and used in conjunction with the files encrypted with this internal key.

This raises the question of how to securely maintain and archive old passwords. There are methods and tools to archive passwords. Generally, these methods involve having a file which contains a list of all old passwords, and then encrypting this file and protecting it with the current keystore, which in turn is protected by the current passwords. However, IT environments and security policies vary from organization to organization, and consideration and thought should be given to the specific security needs of your organization to develop security policy and practices that are best suited to your environment.