Encrypting backups using Versions 5.5 (and later) of the TSM Client

1. Introduction

This is not a How To document on encrypting your TSM backups to the HFS but a consideration of the methods of encryption key handling and their implications. For instructions on how to encrypt your data backups to HFS, please review our page on how to encrypt files for backup.

Prior to TSM client Version 5.5, TSM offered two methods of managing keys used for encrypting backups, controlled by the setting of the encryptkey option in the TSM options file:

  • Encryptkey prompt If you set the encryptkey option to prompt, TSM prompts for the encryption password for each backup, archive, and restore session. The key is not saved anywhere on the local client machine or on the server. Thus, if the key is lost, the data cannot be decrypted.
  • Encryptkey save If you set the encryptkey option to save, you are only prompted the first time you perform a backup or archive operation. The password is stored (in encrypted form itself) in the TSM password file (Mac, Linux, Solaris) or the registry (Windows). Thereafter, TSM does not prompt for the password, but continues to use this key to encrypt data that qualifies for the encryption process. If the encryption key (in the password file/registry) is lost or overwritten then the user will be prompted for the encryption key when next attempting a backup, archive or restore of data qualifying for encryption. If you cannot recall this key, the data cannot be decrypted.

With TSM Client version 5.5 and later, TSM now offers the encryptkey generate option. This is now the default option for Windows, Mac, Linux, and Solaris TSM installations. It specifies that the key is automatically generated when the client begins a backup or archive and is used to encrypt files meeting the encryption criteria. The key is stored in encrypted form on the TSM server and is used to automatically decrypt files on restore or retrieval operations. Thus, the key is handled 'transparently' to the user and cannot be lost.

2. Moving from a Prompted or Saved key to a Generated key

If the TSM client is now using the encryptkey generate setting, what happens when restoring a file encrypted by a saved key?

If the TSM password file/registry entry exists, it appears that the TSM client will restore and decrypt the file OK (regardless of whether the encryptkey option is set to generate or save). If the TSM password file/registry entry has been lost (or passwordaccess is set to prompt) then the client will prompt for the key.

If the client is now using the encryptkey generate setting, what happens when restoring a file encrypted by a prompted key?

The TSM client prompts for the key. Where a file has been saved with two different keys, use the latest key to restore the latest version.

If you are restoring the earliest (a.k.a. inactive) version of an encrypted file, encrypted using two different keys, you need to use the first key. However, this only works with the encryptkey option set to prompt. If the option is set to generate, the client appears to only be able to prompt and restore the latest version of the file.

Written by IT Services. Latest revision 2 June 2017