FDRCRYPT Techniques and Procedures

FDRCRYPT supports different encryption algorithms. Any of the algorithms can be used for any given encrypted file.

For FDR and FDRABR backups, the encryption algorithms are used to encrypt and decrypt every block in the FDR backup that contains images of data tracks from the DASD (FDR meta-data, such as VTOC and VVDS information, is not encrypted). The algorithms are all symmetric encryption, meaning that the encryption key that was used to encrypt the data during a backup must also be used to decrypt the data during a restore.

For FDRCAMS REPRO, the encryption algorithms are used to encrypt all data in the sequential output file. A small amount of encryption control information is written to the beginning and end of the file.

The algorithms provide varying levels of security, with varying costs. Each algorithm is more secure than the preceding one, but the CPU time and elapsed time necessary for the backup and restore also rise. You must choose the appropriate algorithm (and its attendant overhead) for each DASD volume or file, depending on the sensitivity of the data. For some backups, you may choose no encryption (such as system volumes).

During backups and REPRO to an encrypted file, you can choose the encryption algorithm (or no encryption) to be used for each DASD volume or file. During restore or REPRO from an encrypted file, FDRCRYPT detects that the file is encrypted and determines the algorithm used.

CIPHER block chaining

All the algorithms use a variation of “cipher block chaining”, a technique where the encryption of each section of data within an encrypted block uses the results of the encryption of the previous section as part of its encryption algorithm. This increases the strength of all the algorithms.

Because of cipher block chaining, an attacker must find the beginning of a cipher block chain before attempt a brute force attack on the encryption. This reduces the likelihood of recognizable plain text appearing when applying a key during such an attack.

Compression

FDRCRYPT normally compresses the backup data before it is encrypted, using BMC’s proprietary compression algorithm; unlike some compression algorithms, it does not save any dictionary of known data strings that might help decrypt the data (FDRCAMS does not compress data before encryption).

Encryption defeats the hardware compression used on most tape drives, since the encrypted data is usually not compressible. This means that encrypted tape backups could take 2-3 times as much tape as unencrypted backups. FDR software compression before encryption reduces the amount of backup data and saves tape but the result usually uses more tape than an unencrypted backup compressed by the tape hardware. FDRCRYPT turns off tape hardware compression for an encrypted backup to tape, since that compression may actually increase the backup size.

Compression also reduces the amount of data that must be encrypted (to reduce encryption CPU overhead) and it increases the variety of byte values in the data, which enhances the strength of the encryption.

Compression adds its own CPU overhead, which is the same for all encryption algorithms. The CPU overhead is dependent on how well the data compresses (incompressible data needs more CPU time).

FDR compression can be bypassed by coding COMPRESS=BYPASS on an ENCRYPT statement. This is not recommended unless you know the data is already highly compressed or is naturally not very compressible, since the overhead of FDR compression raises with incompressible data.

Encryption algorithms

The following encryption algorithms (AES, and TDES) are known as “symmetric”, meaning that the same key is used to encrypt and decrypt the data. The key must be available to the sending site as well as the receiving site.

AES

AES stands for Advanced Encryption Standard. AES was adopted by the National Institute of Standards and Technology (NIST, a division of the US Commerce Department) in 2002, after an international competition among proposed algorithms. AES is also known as “Rijndael” after its two inventors. The AES algorithm is described in US government publication FIPS 197. AES is now the official US government standard for encryption, replacing the previous DES (DES was officially decertified for US government encryption in May 2005; use of TDES (triple DES) was also discouraged).

FDRCRYPT supports AES-128 (128-bit key), AES-192 (192-bit key), and AES-256 (256-bit key).

AES is an extremely secure, mathematically-based, encryption algorithm. It performs repetitive transformations of the data (called “rounds”) using various applications of the key and other manipulations (including forms of substitution and transposition), to produce an encrypted version of the data that is almost impossible to decipher without the key. The algorithm is coded entirely within FDRCRYPT modules.

The number of rounds varies by the key length:

The CPU overhead increases in proportion to the number of rounds.

AES-128 has considerable CPU overhead, 3 to 5 times more CPU than compression alone, because it performs many transformation rounds on the data. AES-192 has 20-25% more CPU and AES-256 has 40-50% more CPU than AES-128. BMC has made every effort to make the AES code as efficient as possible, and we believe that we are faster than most AES implementations.

IBM introduced a hardware assist (CPACF) for AES-128 on the z9 processor (and its successors). If this assist is enabled, FDRCRYPT uses it for encryption and decryption when ENCRYPTTYPE=AES or AES128 is specified (the assist does not support AES-192 or AES-256, which are implemented only in FDRCRYPT software). The AES-128 results produced by the FDRCRYPT software and the assist are identical, so you can encrypt with the hardware assist and restore on a system without the assist, and vice versa. The assist takes less CPU time than the software implementation.

We recommend that if you use a master key with AES encryption, you let FDRCRYPT randomly generate the AES encryption key.

Strength

AES is a very strong form of encryption with no weak or semi-weak keys. Use AES-128 when AES is needed unless regulations require that you use AES-192 or AES-256 (such as Secret or Top Secret requirements), because of the significant CPU overhead of the longer keys.

The nature of AES provides that any key value is as secure as any other (in fact, changing just 1 bit in the key can produce an encrypted result that is significantly different). However, if you specify your own AES encryption keys, we recommend that you avoid repetitive characters and strings that are easily recognizable.

TDES

TDES stands for Triple Data Encryption Standard (also called 3DES). DES, the Data Encryption Standard, was adopted by the US Government in 1976, but today is considered easy to break and is no longer authorized for US Government use. Triple DES, where the data is encrypted three times, with three 64-bit keys (192 bits total), is considered much stronger and is still authorized by the US Commerce Department (although its use is discouraged).

TDES is supported by FDRCRYPT. Although the DES algorithm is implemented in FDRCRYPT code, it is a very high-CPU algorithm and its use is discouraged if you must use software encryption or decryption.

However, the IBM z890, z990, z9, z10, z114, and z196 processors (and their successors) include cryptographic assists (CPACF) that process TDES with much lower overhead. If those assists are enabled, FDRCRYPT automatically uses them for TDES encryption and decryption. If you have a z9 processor at both the encryption and decryption site, AES is recommended over TDES.

Encryption procedures

As you see in the control statement descriptions (DUMP-COPY-Operands-for-Encryption and FDRCRYPT-Dump-Examples), you can choose the encryption technique to be used with the backup of each DASD volume in an FDR dump step or REPRO output file in an FDRCAMS step. You can also specify the encryption keys to be used for each DASD or file (or allow FDRCRYPT to generate random keys). FDRCRYPT-Key-Management has more information on key usage and management.

Although it may be tempting to simply encrypt all backups with AES (the strongest of the encryption techniques supported), this may not be the best solution for most customers. Encryption has an additional cost in CPU time and elapsed time, although this overhead varies depending on your system configuration. Encryption may require longer backup windows or an upgrade of CPU power. In order to meet your security needs while constraining overhead, consider these points:

• You may want to use encryption only for backups that are sent off-site and are exposed to theft and attack. FDRCRYPT can create one encrypted backup and one non-encrypted backup of the same data at the same time, one for off-site and one for on-site; however, the CPU overhead is the same whether one or both copies are encrypted.
• You may want to bypass encryption for system volumes that do not contain sensitive application data, in order to speed up recovery of the system environment.

Master keys

FDRCRYPT supports optional master keys with the symmetric algorithms. A master key is a 128-bit AES key that provides a way to restore an encrypted file even if its actual encryption key or the FDRCRYPT Encryption Keyfile is not available.

If a master key is provided for a backup of a given DASD or an FDRCAMS REPRO, that key is used to create an encrypted copy of the actual key (AES or TDES) used to encrypt the data. This AES-encrypted key is saved on the file itself.

During restore, if the master key is provided, it is used to decrypt the actual key stored in the file, which is then used to decrypt the data. This allows you to decrypt any file created using that master key, in case the actual key or the Encryption Keyfile is not available or not current.

Obviously, the master keys are “the keys to the kingdom” and must be kept extremely secure and secret, known only to a few trusted individuals.

Although the master keys for encryption can be specified on FDRCRYPT control statements, we recommend the more secure technique of storing the master keys in a special profile in your security system, so that only authorized individuals can view or update the master keys. The details are in FDRCRYPT-Key-Management.

It is extremely important that you realize that an encrypted file can be read only if its actual key or its master key (if used) is known. If the actual keys (such as the Encryption Keyfile described in the next section) are not available, and no master key was used or the master key is not known, then there is no way to restore an encrypted backup or read an encrypted file. For FDRCAMS, also see the RSA description following.

RSA Public/Private key encryption

FDRCAMS supports the RSA encryption algorithm, as a second form of master key. RSA is a PKA (public key algorithm).

RSA is asymmetric, meaning that a different key is used for the encryption (the “public key”) and the decryption (the “private key”). The idea is that the receiver of an encrypted file generates a public/private key pair and provide the public key to the sender, who uses it to encrypt the data and transmit it to the receiver. The receiver then uses the matching private key to decrypt the data. The public key can be freely published since it can be used only for encryption. The private key is kept secure by the receiver and used only for decrypting files encrypted with the matching public key.

With RSA, one of the normal symmetric encryption algorithms is used to encrypt the data, and FDRCAMS uses the RSA public key to encrypt the actual key used to encrypt the data file and store it in the encrypted file. At the receiving site, the RSA private key is used to decrypt the actual key, which is then used to decrypt the data.

FDRCAMS support for RSA requires the use of ICSF services. ICSF is the IBM Integrated Cryptographic Service Facility, a part of z/OS. ICSF must be configured and active for RSA encryption to work; see IBM ICSF manuals for details.

You must also have optional cryptographic hardware installed on your system to use RSA. This hardware is available on IBM z990, z9, z10, z114, and z196 systems (and their successors). Depending on the processor, the optional hardware may be called CCF, PCICC, PCIXCC, or CEX2C. IBM supports RSA keys with a length of up to 2048 bits (1024 bits on some of the optional hardware); you must be sure that your partner site uses a key length that is supported by your hardware. Consult IBM for details.

With RSA, the public key (for the sender) and the private key (for the receiver) are stored in ICSF, in a data set called the PKDS (Public Key Data Set). Each key has a name, called a label, up to 64 characters in length. If you have certain optional cryptographic hardware installed on your system (PCICC, PCIXCC or CEX2C), then the keys are actually securely stored in that hardware and they never appear in processor storage. If you do not have one of them, then the keys are stored in the PKDS in an encrypted format. In either case, the label of the key is stored in the PKDS.

When you invoke RSA encryption with FDRCAMS, you provide the label of the key to be used. FDRCAMS then interfaces with ICSF to encrypt or decrypt the actual key using that RSA key.

Although ICSF does have facilities for defining or importing RSA keys, the most convenient way of doing so is by using IBM RACF in conjunction with ICSF. RSA keys (public and/or private) can be stored in digital certificates. IBM RACF has facilities for defining and importing such digital certificates (the RACDCERT function). It can also interface with ICSF to store the RSA key in the PKDS. This does require z/OS 1.4 or above plus IBM RACF APAR OA13030.

IBM RACF and ICSF documentation describe the process of managing certificates and RSA keys in more detail. For other security systems (such as CA ACF2 and CA TOP SECRET), consult the vendor documentation for the equivalent facilities.

Alternately, a TKE (Trusted Key Entry workstation, an optional feature of your IBM processor) can be used to securely enter keys into ICSF.

RSA public keys may be used in place of FDRCRYPT master keys, or you may use both a RSA and master key on the same FDRCAMS encrypted file. Either the RSA private key or the master key can be used to decrypt the file (the actual key, as recorded by the sending site, can also be used, but that is not normally shared when RSA is used).

Encryption specification

Encryption is requested in an FDR, FDRDSF, or FDRABR backup step by adding the ENCRYPT= operand to the DUMP statement. You can also select the default encryption algorithm with the ENCRYPTTYPE= operand.

When encryption is requested, an optional FDRCRYPT DD statement may be provided pointing to a set of ENCRYPT statements giving more encryption options. The ENCRYPT statements provide specific options based on the volume serials of the DASD volumes being backed up. For certain DASD volumes or DASD prefixes, you can provide the encryption keys and override the encryption algorithm to be used. You can also provide optional master keys.

In an FDR restore step, encrypted backups are automatically recognized; no special operands are required on the RESTORE statement. If the encryption keys are available in the default Encryption Keyfile, then no FDRCRYPT DD statement is required. However, you may provide an FDRCRYPT DD statement containing DECRYPT statements with actual keys or master keys to be used for various volumes.

All of these operands and statements are described in DUMP-COPY-Operands-for-Encryption through DECRYPT-Statement.

FDRCAMS encryption is requested by changing the PGM= in a REPRO step from IDCAMS to FDRCAMS, and adding an FDRCRYPT DD statement to the step to specify encryption options. The IDCAMS statements in SYSIN are not changed. Other IDCAMS statements in the step, such as DEFINE and DELETE, are executed normally. FDRCAMS execution is described in FDRCAMS-REPRO-Control-Statements.