FDRCRYPT Key Management

The “key” to secure encryption is the security of the encryption keys used. Since five of the FDRCRYPT encryption algorithms are symmetric, meaning that the same key is used for both encryption and decryption, it is essential that the keys be kept securely, so that no unauthorized person who accesses your encrypted files also has the keys to decrypt them. FDRCRYPT uses a variety of methods to ensure key security.

Key generation

FDRCRYPT has code to randomly generate encryption keys. This code is driven by the system hardware TOD clock and other system variables, using a BMC-written algorithm that provides truly random keys. When random keys are requested, a different key is generated for each DASD being backed up or FDRCAMS REPRO, which makes it that much more difficult for an unauthorized person to access your data. Even if the key of one file can be determined by some attack, the attack must be repeated for the next file, and the next, and so on.

Alternatively, you can specify the key to be used for each REPRO or DASD volume (or multiple DASD volumes).

For the TDES and AES encryption algorithms, because of their strength against attack, you can specify the key to be used for each encrypted file (the same key can be used for one or more DASD volumes or files), or you can let FDRCRYPT randomly generate a key for each DASD volume or file. We recommend that you let FDRCRYPT randomly generate keys if a master key is used.

Important

FDRCRYPT does not use “pseudo” random number generators, since the “seed” used to start the sequence (often only 4 bytes) does not provide sufficient unique combinations for our needs, especially for AES keys. For example, a 4-byte seed can only generate 4.2 billion sequences, where a 16-byte generated key can have 25616(3.4 times 1038) values.

Key validation

FDRCRYPT stores a value derived from the actual key used to encrypt a file (similar to a checksum), in the file itself, for validation. This value is encrypted using the actual key as an AES key. At the beginning of a restore or REPRO decryption, FDRCRYPT decrypts this value using the decryption key and fails the restore if the decrypted value is not as expected. Although this test is not infallible, it usually detects a restore with an improper actual or master key. The actual decryption key cannot be derived from this value.

Encryption Keyfile

Since many different encryption keys may be used for various FDR backups and FDRCAMS REPROs (either randomly generated or chosen by you), it is not practical to require you to constantly enter the key to read an encrypted file. FDRCRYPT solves this by storing the encryption keys in an “Encryption Keyfile”.

An Encryption Keyfile is a DASD data set that has been initialized by the FDRCRYPT utility, FDRCRYFM (FDRCRYFM-Utility). The Encryption Keyfile must be protected by a data set profile in your security system; otherwise, you can not display keys from the Encryption Keyfile with FDRCRYFM or FDREPORT, although you are able to use it to record encrypted backups.

Whenever an encrypted backup is created by an FDR, FDRDSF, or FDRABR DUMP, or an FDRCAMS REPRO, a record describing the encrypted file is written to the Encryption Keyfile. This record includes the ID of the file (such as the DASD volume serial for a backup), the time/date of creation, the first volume of the backup or output data set and the encryption key. The data is not stored in the clear, so a simple browse or print of the Encryption Keyfile does not disclose any encryption keys.

An Encryption Keyfile must always be provided when creating encrypted files. You may have multiple Encryption Keyfiles if you have a need to segregate different types of backups or files. All encrypted files created in a given FDRCRYPT step are recorded in the same Encryption Keyfile.

When an encrypted backup is restored or FDRCAMS REPRO reads an encrypted file, the Encryption Keyfile is read to get the encryption key that is needed to decrypt the file.

Important

If you provide the actual key or the master key on a DECRYPT statement, the Encryption Keyfile is opened but not read.

The data set name of the Encryption Keyfile can be provided on an FDRCRYPT KEYFILE statement (see KEYFILE-Statement and FDRCAMS-KEYFILE-Statement). A default Encryption Keyfile name can be stored in the FDR Global Options on ISPF panel A.I.4.13 or by executing FDRZAPOP (Executing-FDRZAPOP) with the statement: ZAP KEYFILE=dsname

In your security system, only those user IDs that have a need to create, back up, restore, or produce reports from a Encryption Keyfile should have authority to the data set. READ authority is required to back up the Encryption Keyfile, UPDATE is required to restore it, and ALTER is required to create it or to produce reports that show the actual keys. All other users should have no authority to the Encryption Keyfile.

Under IBM RACF, FDRCRYPT itself does not require security access authority to the Encryption Keyfile. It is always able to read and write the Encryption Keyfiles. Therefore, any user who can create or restore from an encrypted backup can use the Encryption Keyfile, but only under FDRCRYPT. They are not be able to browse, update, or copy the Encryption Keyfile. Under other security systems, FDRCRYPT users may need to have UPDATE authority to the Encryption Keyfile for encryption and READ for decryption.

The contents of the Encryption Keyfile can be reported with the REPORT command of program FDRCRYPT, or with program FDREPORT using DATATYPE=ENCRYPT.

As described in FDRCRYPT-Off-Site-Recovery, you need to securely transmit a copy of the Encryption Keyfile to your off-site recovery location, such as a disaster site, in order to restore the encrypted backups. Alternatively, if you use master keys for the backups, you can restore the encrypted backups off-site using only the master keys. In either case, the Encryption Keyfile or master keys must be transported separately from the backups themselves, to thwart unauthorized access.

If you choose to encrypt FDRABR Archive backups, and you intend to allow auto-recall of those archives, then the encryption keys must be stored in the default Encryption Keyfile whose name is in the FDR Global Options, since only that Encryption Keyfile is read during auto-recall.

Master keys

Master keys are optional but if used they do provide a way to restore an encrypted file if the actual keys and the Encryption Keyfile are not available or not current. Master keys are 128-bit AES keys consisting of exactly 32 hex digits, 0-9, A-F.

The most secure way to specify a master key for backups is to store it in a FACILITY class profile in IBM RACF (or the equivalent in your security system). The profile must be created with:

  1. Class FACILITY.
  2. Profile name “FDRCRYPT.keyname” (“keyname” is a 1-8 character name of your choice). If you need for multiple master keys, you can create multiple profiles.
  3. Set Universal Access to NONE so that no one can display the master key.
  4. Only those individuals who need to know or update the master keys should have authority to these profiles.
  5. In the “Application Data” field of the profile, enter “MASTERKEY=keyvalue”.
    In IBM RACF, you can define this profile with the IBM RACF ISPF dialog, or you can issue the RACF command such as:
    RDEFINE FACILITY FDRCRYPT.keyname UACC(NONE) APPLDATA('MASTERKEY=keyvalue')
  6. “keyvalue” must be a valid FDRCRYPT 16-byte AES128 master key, consisting of exactly 32 hexadecimal digits (0-9, A-F).

Important

(For CA ACF2 and CA TOP SECRET Users.) The procedure for defining the FDRCRYPT.keyvalue profile is different and you may need assistance or a usermod from Broadcom. Contact Broadcom (formally CA Technologies) for information. For CA ACF2 mention user mod 14467705.

During the backup, if you specify an ENCRYPT statement with MASTERKEYID=keyname, FDRCRYPT extracts the master key from the profile. For IBM RACF, the FDRCRYPT users do not need to be authorized to the profile but in other security systems; they may need to have READ authority to the profile name.

If you wish master keys to be used for all backups, you can store a default MASTERKEYID= value in the FDR Global Options. This default profile name is used for all encrypted backups unless overridden on an ENCRYPT statement. The default can be set on ISPF panel A.I.4.13, or execute the FDRZAPOP utility (Section 91.1 “Executing FDRZAPOP”) with the statement: ZAP MASTERKEYID=keyname

For restores, the MASTERKEY= must be specified on a DECRYPT statement if you want it to be used; MASTERKEYID= is not supported for restores.

Warning

The master keys must be kept extremely secure and secret:

  • Avoid easily remembered keys as well as keys with repetitive strings and duplicated characters (this is also true for other user-specified encryption keys).
  • Limit access to the master keys, either in printed form or from the FACILITY profile, to a small number of trusted individuals.
  • Store the printed copies of master keys securely, such as in a bank safe-deposit box.

To enhance security, you may wish to periodically change master keys, for example, once a month or once a quarter. However, if you do, remember that backups created before the master key change requires the previous master key if you need to restore using a master key. So previous master keys and the dates the keys were changed must be retained as long as the associated backups are retained.

Note

Since an FDRABR or FDRDRP full-volume restore may read incremental backups and a full-volume backup while restoring each DASD volume, it is necessary that all of those backups are done using the same master key, in case the master key is needed to do the restore. Although master keys can be changed at any time, for ABR volume backups it is important that they change only when full-volume backups are taken (the beginning of a new generation).

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*