Recovery of encrypted copies
The use of encryption protects sensitive company information and prevents security failures.
NGT Recover support for encryption allows you to recover using image copies that are protected from unauthorized access to the sensitive information. For the recovery, NGT Recover uses full and incremental encrypted copies made by NGT Copy. For information about making encrypted copies, see the .
Encryption is a feature of the BMC Recovery Management for DB2 solution and requires a valid Recovery Management solution password.
Encryption is based on standard secret key encryption algorithms. In NGT Copy, you select encryption based on one of three following standard algorithms:
The ANSI Data Encryption Algorithm (DEA) with a 64-bit key
This is the default algorithm. This algorithm is also known as the U.S. National Institute of Science and Technology Data Encryption Standard (DES).
The Triple Data Encryption Standard (TDES) with a 128-bit key
The Advanced Encryption Standard (AES) with a 128-bit key
NGT Copy supports encryption of plaintext image copies or decryption of cipher text image copies. Plaintext or clear text is data in normal, readable form. (NGT Copy standard image copies are plaintext.)Encrypted text or cipher text is data that has been converted to mask its meaning from an unauthorized recipient.
Requirements for encryption
To specify that you want to recover by using encrypted copies made by NGT Copy, you must:
Run NGT Recover on a processor that supports encryption
For a non-registered encrypted image copy, use the ENCRYPTED option and TIMESTAMP option in the INCOPY specification of the RECOVER command (INCOPY specification)
NGT Recover finds encrypted copies registered in BMCXCOPY without the use of the syntax options.
Use the KEYDSNAM installation option to specify your key data set name (KEYDSNAM= keyDataSetName)
Create and maintain the key data set (Key data set)
Have the Recovery Management for DB2 solution and use a valid Recovery Management password
Key data set
Support for encryption in NGT Recover relies on a user-created and maintained data set, called the key data set.
The key data set contains essential encryption key information. NGT Copy requires the key data set to make encrypted copies. NGT Recover requires the same or an identical key data set used by NGT Copy to recover by using encrypted copies.
Key data set requirements
You must perform the following tasks for the key data set:
Create the key data set.
NGT Recover requires that the key data set be a fixed or fixed block physical sequential data set with a logical record size (LRECL) of 80. NGT Recover requirements for the contents of the data set are specified in Key data set contents. Any variation from these requirements could prevent NGT Recover from recovering the encrypted image copy.
BMC recommends that you use the same key data set that NGT Copy used to encrypt the image copy or a duplicate of that NGT Copy key data set. A duplicate data set is required if you are migrating data from one system to another, and the key data set is not shared between the systems or you are recovering data at a remote site.
Identify the key data set to NGT Recover.
The KEYDSNAM installation option (KEYDSNAM= keyDataSetName) specifies the key data set name. After you specify the key data set name, NGT Recover dynamically allocates the data set when it is needed.
If NGT Recover attempts to recover an encrypted image copy and you have not specified the key data set name in the installation options, NGT Recover issues the following message:
BMC40020I ENCRYPTION KEY DATA SET NOT SPECIFIED IN OPTIONS MODULE
If NGT Recover attempts to recover an encrypted image copy and the key data set is not cataloged, NGT Recover issues the following message:
BMC40020I ENCRYPTION KEY DATA SET NOT CATALOGED
Maintain the key data set.
Periodically, you may want to change encryption keys. You cannot edit the key data set while any utility that is using the key data set is inflight. You need to schedule time to maintain the data set. You must take care when you maintain the data set because incorrect entries in the data set might prevent NGT Copy from encrypting your image copies or prevent NGT Recover from recovering from a previously encrypted image copy.
Provide appropriate security for the key data set to protect it from unauthorized access.
If a non-registered encrypted image copy is used in the INCOPY clause and the registration timestamp is not known, a timestamp with a value greater than the timestamp of the desired encryption key, but less than subsequent encryption keys can be used in place of the registration timestamp. Due to security, the administrator of the key data set will need to determine this value.
Maintain backups of your key data set either with DFSMShsm or some other facility.
Key data set contents
The key data set contains one or more rows of 80 characters per row.
NGT Recover ignores any characters in columns 72 through 80.
Each row contains:
One encryption key
A corresponding timestamp
An optional encryption algorithm identifier
An optional comment
These fields are separated by one or more blank characters. The first character of the comment is an asterisk. Rows are ordered in the data set by timestamp with the most recent timestamp first. The current key is the key in the first row. The format of the key data set row is:
Key value Timestamp Encryption algorithm ID Comment
An example of the contents of a key data set follows:
X'0ABCDEF123456789FEDCBA000111111' 2012-11-23-12-00 *128 bit DES encryption X'123456789ABCDEF1' 2012-08-23-11-10 X'723DE6789000DEF1' 2011-12-12-16-40 DES *64 bit DES encryption X'723DE6789000DEF1723DE6789000DEF1' 2011-12-12-14-00 AES *128 bit AES encrypt X'F1F2F3F4F5F6F7F8' 2011-01-01-12-00
NGT Recover uses the contents of the key data set to determine a key value for decryption of image copies. NGT Recover uses either the first key whose timestamp is less than the timestamp in BMCXCOPY or the timestamp specified in the INCOPY specification.
Encrypted image copies are registered in BMCXCOPY. As with SYSCOPY registration, BMCXCOPY registration includes a timestamp specifying when the copy was registered. NGT Recover uses this timestamp to find the correct key value in the key data set. For more information about the registration of encrypted copies, see Registration for plaintext image copies.
For example, if NGT Recover selected an image copy for a recovery from BMCXCOPY with a timestamp of 2011-02-12-10.00, the encryption key and DES algorithm in the third row in the example key data set above is selected.
NGT Recover supports both 64-bit and 128-bit keys. The key data set can contain either or both key sizes. The key value is a clear key represented in the key data set as a string of 16 or 32 hexadecimal digits in the following format:
The X and the quotes are required. The X must occur in the first column and be upper case.
The date, hour, and minute string uses following formats:
The values are decimal numbers and are padded on the left with a zero if necessary. The timestamp must be separated from the key value by at least one blank space.
Encryption algorithm identifier
An encryption algorithm identifier is optional in the key data set. The encryption algorithm identifiers supported are
DES for Data Encryption Standard (for 64-bit keys)
DES for Triple Data Encryption Standard (for 128-bit keys)
AES for Advanced Encryption Standard (requires 128-bit keys)
The encryption algorithm identifier defaults to DES if no identifier is provided. If you provide an identifier, you must separate it from the timestamp by at least one blank. NGT Recover distinguishes between the two varieties of DES based on the length of the key (64-bit or 128-bit).
Comments are optional in the key data set. A comment begins with an asterisk that is separated from the preceding field by at least one blank.
Key data set management
The security of the encrypted NGT Copy image copies and the ability of authorized individuals to use NGT Recover to recover DB2 spaces using these image copies depends on the careful management of the key data set.
BMC recommends that you develop a simple and well-documented mechanism to manage key data sets.
BMC recommends that you maintain one key data set shared by all systems with access to the data set. Multiple distinct key data sets create difficulty with key data set management because you must ensure that the key data set that is used to encrypt an image copy is also used for recovery with that encrypted image copy.
Consider all of the following items as you manage your key data set:
Protect the key data set on the local system and duplicates on remote systems against unauthorized access.
Most attempts to access encrypted data occur as unauthorized access to the key data set. You should protect the key data set against unauthorized access during shipping with either a secret key or public key encryption. If key data set is not encrypted during shipping, it should never be shipped under the same cover as the encrypted image copies.
If you plan to use encrypted image copies at your disaster recovery site, be sure that the processor at the site supports encryption.
Remote disaster recovery sites may require a duplicate key data set for recovery purposes.
Because the timestamps that are used for recovery are taken from the BMCXCOPY table, a change in time zones between the site where NGT Copy made the encrypted image copies and the disaster recovery site will not affect recovery.
The possibility exists, however, that a time zone change might invalidate a key data set for creating image copies at the remote site. If this is the case, you will need a new key data set with local times for generating encrypted image copies at the remote site.
Limit updating of the key data set to authorized individuals.
Generating a new current key by inserting a new first row in the key data set limits the amount of data exposed if the current key is compromised. Do not modify existing rows in the key data set because image copies may exist that will require the keys for recovery. It is important that duplicate key data sets on remote systems also contain this new row, and that backups of the key data set be immediately created on all systems.
Once image copies encrypted by a key are no longer referenced in the local and remote BMCXCOPY tables and will not be used by NGT Recover for recovery as a non-registered image copy, the key is no longer needed by NGT Copy, NGT Recover, or Log Master and you can eliminate the key.
Key destruction steps are:
Delete backups of the current key data set on both the local and remote systems.
Remove the row containing the key from the local key data set and duplicate key data sets on remote systems.
Never remove a row from the key data set unless it is the last row in the data set.
Create backups of the new key data set on the local and remote systems.
If a key data set is lost or corrupted and not recoverable, you can gain emergency access to the current key data set with a technique called key escrow. Once you have created or updated a key data set, the contents are divided into two or more partial key data sets so that no one data set is sufficient to decrypt an image copy. Each partial key data set is sent to different trusted agent. In the event of an emergency, you can retrieve and reassemble the partial data sets.
Registration of copies
The topic describes the registration of encrypted copies.
Registration for encrypted image copies
Because the encrypted image copies produced by NGT Copy are non-standard, encrypted image copies are registered in the BMCXCOPY table.
An STYPE value of e indicates that the image copy is encrypted. In a recovery that uses these encrypted image copies that are registered in BMCXCOPY, you must use NGT Recover.
Registration for plaintext image copies
Plaintext full image copies are registered in SYSCOPY.
Instant Snapshot copies and certain index space copies are exceptions and are registered according to the rules for BMCXCOPY. (For more information, see .)
A plaintext incremental is registered in SYSCOPY if the most recent primary full copy of the same site type is also plaintext. If the most recent primary full copy of the same site type is encrypted, the incremental is registered in BMCXCOPY.
You can use NGT Recover or the DB2 RECOVER utility to recover using plaintext copies that are registered in SYSCOPY. But you must use NGT Recover for recovery if the plaintext image copies are registered in BMCXCOPY.