Large FDRCrypt Advert


Backup data is a potential security risk, especially if the backup tapes are held off-site and out of your control. Anyone who has a copy of the backup program can read those tapes and extract the data, which could be company confidential or maybe customer data that could lead to identity theft. Most countries have data protection laws that would be violated if those backup tapes were intercepted and read.

FDR backups can be protected using FDRCRYPT, a recently released product that interfaces with FDR, FDRDSF, FDRABR and FDRAPPL backup programs. FDRCRYPT makes the backup data unreadable, unless the reader possesses the key to decrypt that data.

You have several options for Key management; you can provide the encryption key yourself and make it consistent for a set of backups or you can use randomly generated keys. Randomly generated keys are different for each disk volser and backup time combination, so they are very secure. The keys are recorded in a key database, and if that key database is available then FDR and FDRABR will read it and automatically decrypt backups for recovery. This means you must have a process to independently store that key database, and retrieve it to your DR site when required. Finally, FDRCRYPT can use master keys that can be used to read encrypted backups if the normal keys are not available. Obviously, the master keys needs to be securely locked away for emergency use only.

Encryption Levels

Encryption will use CPU resources, and the 'harder' the encryption, the more CPU will be required. FDRCRYPT offers four different levels of encryption so you can get the right balance between security and resource utilisation. Top level encryption is expensive in terms of CPU and elapsed time, and so is not appropriate for all backups.

  • SUBSTITUTION combined with compression will protect from unsophisticated attacks, and has a relatively small CPU overhead. It uses a 128-bit encryption key to generate a 256-byte substitution table, where each byte value in the backup data block (after compression) is translated to a different unique byte value.
  • CIPHER requires a bit more resource than Substitution, but is very difficult to crack. It uses the same byte replacement as Substitution but then adds transposition, so every byte is relocated to a different place within a backup data block making it very difficult to detect patterns within the encrypted data.
  • AES is very resource intensive but there is no record of it every being cracked. It is the current standard for US Government encryption and should be used for critically sensitive data, or information that is specifically subject to an AES compliance requirement.
  • AESFAST requires 50-60% of the processing of the standard AES process. It does not meet the official AES specification, but is still believed to be very secure. It is appropriate for data that requires a very high level of security while not demanding AES compliance.

All of the encryption algorithms are implemented in software within FDRCRYPT modules and do not depend on any other installed encryption hardware or software; this ensures that your data can be decrypted at any disaster site.

FDRCRYPT will automatically use the AES-128 hardware encryption feature that comes with the IBM z9-109, and tapes created using hardware encryption are fully compatible with the FDRCRYPT AES-128 software encryption.

Invoking Encryption

To use encryption you specify the type of encryption required as a keyword on the dump statement


When the backup job runs the job output will indicate that encryption is required


Another option is to use the default CIPHER encryption as this will reduce CPU and elapsed time. This example uses an optional FDRCRYPT DD statement to specify that a master key will be used for all the encrypted backups created by this job. The value of this master key will be obtained from the RACF security profile facility FDRCRYPT.ABRBKUP, as directed by the MASTERKEYID keyword.


If you create duplicate backups using TAPEx and TAPExx DD statements you can encrypt one copy only by applying the encryption parameters to the relevant COPYx statement.
If you want to supply your own encryption/decryption key, you use an optional FDRCRYPT DD statement to code the extra parameters.

Innovation plans to add encryption algorithms to FDRSOS and FDR/UPSTREAM as chargeable options in future.

As a nice little extra, FDRCRYPT version 2 can interface with IBM's IDCAMS using an FDRCAMS module. This means you can encrypt the output from a REPRO command for secure external data shipment. The recipient will need the encryption key, and can download a free copy of FDRCAMS to decrypt the received files.

Be aware that encryption will interfere with tape hardware compression, and you can end up using a lot more tapes. Innovation try to help here by using software compression before encryption. This saves tapes and has the added benefit of making the encryption even harder to crack.

FDRTCOPY and FDRTSEL support encryption, so you can copy an encrypted tape and make an unencrypted copy (if you have the encryption key).