FDRCAMS REPRO Control Statements

Encryption using IDCAMS REPRO

For encryption and decryption of sequential files written and read by IDCAMS REPRO, you use normal IDCAMS JCL and control statements, as defined in IBM manuals such as:

SC26-7394 z/OS DFSMS Access Method Services for Catalogs

Except that, you must make two changes to the IDCAMS step:

  • On the EXEC statement, change PGM=IDCAMS to PGM=FDRCAMS.
  • Add an FDRCRYPT DD statement pointing to FDRCRYPT control statements specifying encryption or decryption options.

All IDCAMS functions are accepted when executing FDRCAMS. FDRCAMS actually invokes IDCAMS internally, so all command parsing, functions, and most messages come from IDCAMS. All IDCAMS commands other than REPRO execute normally.

However, whenever a REPRO function is invoked, FDRCAMS uses IDCAMS REPRO I/O exits to optionally:

  • Encrypt sequential output files from a REPRO function.
  • Decrypt sequential input files to a REPRO function.

The input file for an encryption or the output file of a decryption can be anything supported by REPRO, including sequential data sets, VSAM clusters (keyed and non-keyed), and Innovation Access Method (IAM) files. However, the encrypted file must be sequential. Therefore, FDRCAMS can REPRO from any supported file type to an encrypted sequential data set, and can REPRO from an encrypted sequential data set to any supported file type.

Operands on the ENCRYPT or DECRYPT statements in the FDRCRYPT DD statement input specify which REPRO functions in the step invoke encryption or decryption, based on the input or output DD statement name of the REPRO, or the input or output file name of the REPRO.

Important

The IBM syntax for the IDCAMS REPRO statement includes an ENCIPHER and DECIPHER operand. These are not used with FDRCAMS and must not be specified.

Exchanging data with other sites

FDRCAMS is often used to encrypt data to be exchanged with other companies or government agencies. However, the receiving site may not be a user of FDRCRYPT, so they may not have FDRCAMS available to decrypt the data.

To handle this, BMC makes available a program, FDRDECRY, which is available to any z/OS site under a no-charge license. FDRDECRY is functionally equivalent to FDRCAMS, and accepts all the same control statements defined in this section, except that it can only decrypt a file that was encrypted by a fully-licensed copy of FDRCAMS, and it can encrypt files which can only be decrypted by FDRCAMS. So, FDRDECRY can be used by any z/OS site to exchange encrypted data with a site with a license for FDRCRYPT.

FDRDECRY can be downloaded from the BMC Support Center.

It is also in the FDRCRYPT load library, so that a licensed site can test FDRDECRY and can even share that single load module with another site.

FDRDECRY must be installed in an APF-authorized load library. It is invoked with PGM=FDRDECRY. Other than that, its operation is identical to FDRCAMS except that FDRDECRY defaults to not using the FDRCRYPT Encryption Keyfile.

FDRCRYPT DD statement

The FDRCRYPT DD statement is required for FDRCAMS. It contains KEYFILE, ENCRYPT and/or DECRYPT statements providing options for encryption. For RSA public key encryption, it also contains PUBLICKEY or PRIVATEKEY statements to identify the key labels.

Although the FDRCRYPT DD statement could be “DD *” (an in-stream data set), this means that the statements are a visible part of the job stream. If actual encryption keys or master keys are specified, this is not particularly secure and should be avoided.

For secure use when keys are specified, point FDRCRYPT to a sequential DASD data set or a member of a PDS. Use your security system to restrict access to that data set. UPDATE authority is required to update the data set and change the keys, and READ authority is required to read the file from FDRCRYPT. Remember that READ authority also allows users to display the data set and see the keys, so restrict it to the user IDs who run backups using that parameter file.

If you let FDRCRYPT generate the keys, and use a IBM RACF profile for the master key (if any), then no keys appear in the FDRCRYPT input and there is no security exposure, even if is an in-stream data set. This is also true for RSA encryption, since only the key labels are known to FDRCAMS.

 

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