Data set encryption

Introduction

With z/OS data set encryption, you can encrypt data without requiring application changes. z/OS data set encryption, through SAF controls and RACF® or equivalent function along with SMS policies, allows you to identify new data sets or groups of data sets to be encrypted. You can specify encryption key labels to identify encryption keys to be used to encrypt selected data sets. The specified key label and encryption key must exist in the ICSF key repository (CKDS). With data set encryption, you are able to protect data residing on disk from being viewed by unauthorized users in the clear. Authorization is based on access to the key label that is associated with the data set and used by the access methods to encrypt and decrypt the data.

z/OS® data set encryption provides the ability to encrypt the following types of data sets:

Sequential extended format data sets, which are accessed through BSAM and QSAM
VSAM extended format data sets (KSDS, ESDS, RRDS, VRRDS, LDS), accessed through base VSAM and VSAM RLS
Sequential basic format data sets, accessed through BSAM, QSAM and EXCP. (Note: EXCP access does require application changes.)
Sequential large format data sets, accessed through BSAM, QSAM and EXCP. (Note: EXCP access does require application changes.)

Encrypted data sets must be SMS-managed. Start of change Encrypted End of change extended format data sets can also be compressed format.

Importance of host-based compression
It is recommended that clients using host-based encryption also exploit host-based compression prior to the encryption of the data. If the data is not compressed prior to the encryption there can be consequences to other parts of the client infrastructure. For example, replicated data that is being compressed in the SAN infrastructure by DWDM technology will no longer be effective trying to compress encrypted data. Without compressing prior to the encryption of the data, additional bandwidth might be required. Another example might be that tape systems can require additional capacity in terms of disk space, in the case of virtual tape, or tape cartridges. If deduplication of data is supported, host encryption can prevent deduplication from working. Therefore, where possible, use compressed format data sets. With encrypted compressed format data sets, the access methods perform compression before encryption. See Considerations when planning for data set encryption for more information.

Importance of host-based compression

It is recommended that clients using host-based encryption also exploit host-based compression prior to the encryption of the data. If the data is not compressed prior to the encryption there can be consequences to other parts of the client infrastructure. For example, replicated data that is being compressed in the SAN infrastructure by DWDM technology will no longer be effective trying to compress encrypted data. Without compressing prior to the encryption of the data, additional bandwidth might be required.

Another example might be that tape systems can require additional capacity in terms of disk space, in the case of virtual tape, or tape cartridges. If deduplication of data is supported, host encryption can prevent deduplication from working. Therefore, where possible, use compressed format data sets. With encrypted compressed format data sets, the access methods perform compression before encryption.

See Considerations when planning for data set encryption for more information.

To create an encrypted data set, a key label must be supplied on new data set allocation. The key label must point to an AES-256 bit encryption DATA key within the ICSF key repository (CKDS) to be used to encrypt or decrypt the data. For each encrypted data set, its key label is stored in the catalog. The key label is not sensitive information; it identifies the encryption key, which is sensitive; therefore, IBM recommends only using secure keys. For more information, see z/OS Cryptographic Services ICSF System Programmer's Guide.

Hardware requirements

Exploitation of this function requires IBM® Enterprise z196 or later. It also requires the following cryptographic hardware features:

Crypto Express3 Coprocessor or later
Feature 3863, CP Assist for Cryptographic Functions (CPACF)

Operating System requirements

ICSF is installed and configured with a CKDS and AES master key loaded. See Considerations regarding ICSF startup and shutdown for more information.

Coexistence requirements

On a z/OS V2R3 or z/OS V2R4 system with OA56622, or on a later system, you can create and access encrypted basic and large format data sets.
On a z/OS V2R2 system with OA50569, you can create encrypted extended format data sets as well as access encrypted extended format data sets created on a z/OS V2R2 (with OA50569) or later system.
On a z/OS V2R1 system with OA50569, you cannot create encrypted extended format data sets. However, you can access encrypted extended format data sets created on a z/OS V2R2 (with OA50569) or later system.

Note: The minimum software release that can support encrypted Start of change

extended format End of change

data sets is z/OS V2R1 with OA50569. An attempt to access an encrypted Start of change

extended format End of change

data set on a lower release will result in loss of access to the data. Ensure that all systems are at the minimum hardware and software levels before encrypting any data sets.

Note: The minimum software release that can support encrypted basic and large format data sets is z/OS V2R3 with OA56622. An attempt to access an encrypted basic or large format data set on a z/OS V2R2 system without OA60160 or a lower system, will have unpredictable results. With OA60160 on a z/OS V2R2 system, an attempt to access an encrypted basic or large format data set will result in an expected ABEND0C1. Ensure that all systems are at the minimum hardware and software levels before encrypting any data sets.

Before enabling this function

Because data set encryption has both hardware and software requirements, you must consider all systems that share data with a system on which you plan to enable data set encryption before creating an encrypted data set. This includes backout software levels, backup systems, read-only systems, replication target systems and disaster recovery systems. Before encrypting data sets other than those used for testing, be sure that all the systems that must access encrypted data sets are capable of doing so by meeting the required hardware and software requirements. In addition to the hardware and software requirements that must be available on every system that will access the encrypted data sets, all key labels and encryption keys that are associated with the encrypted data sets must also be available.

Take the following steps to make data set encryption unavailable to users who are not explicitly authorized to use it:

Define the STGADMIN.SMS.ALLOW.DATASET.ENCRYPT profile in the FACILITY class, and set the universal access to NONE:
```
RDEFINE FACILITY STGADMIN.SMS.ALLOW.DATASET.ENCRYPT UACC(NONE)
```
If the FIELD class is active, check for any profile that would allow any user without SPECIAL attribute access to the DATASET.DFP.DATAKEY. If there are none, no additional action is needed. If there is any profile that would allow access to DATASET.DFP.DATAKEY, create a DATASET.DFP.DATAKEY profile in the FIELD class with a UACC of NONE:
```
RDEFINE FIELD DATASET.DFP.DATAKEY UACC(NONE)
```

Taking the above steps is intended to assure that only authorized users are allowed to use data set encryption. Such users should be made aware that until the decryption functions are available on all sharing systems, backup systems, and disaster recovery systems, access to encrypted data can be lost at any time.

Tasks for setting up data set encryption

Performing the following tasks is necessary to begin using data set encryption.

Create key labels and encryption keys

To create an encrypted data set, a key label must be assigned to the data set. The key label and its associated AES-256 bit encryption key must exist in the CKDS by the time the data set is opened. To create keys in the CKDS, refer to z/OS Cryptographic Services ICSF System Programmer's Guide. IBM recommends the use of secure keys.

Set up CSFKEYS

To control which users can use which keys, protect resources CSFKEYS class. The CSFKEYS class controls access to cryptographic keys identified by the key label.

To enable the use of ICSF keys:

Grant the user READ authority to the resource key-label in the CSFKEYS class. This authority can be granted for all uses of the key-label or only when the use of the key-label is permitted when using a CRITERIA value of DSENCRYPTION for SMS.
- if the class has not already been enabled for generics
```
SETROPTS GENERIC(CSFKEYS)
```
- Define profiles in the CSFKEYS class to protect key labels
```
RDEFINE    CSFKEYS  profile-name UACC(NONE) 
           ICSF(SYMCPACFWRAP(YES)   SYMCPACFRET(YES))
```
- Give the users (preferably groups) access to the profiles
```
PERMIT profile-name CLASS(CSFKEYS) 
       ID(name)    ACCESS(READ)
```
or
```
PERMIT profile-name CLASS(CSFKEYS) 
       ID(name)    ACCESS(READ) 
       WHEN(CRITERIA(SMS(DSENCRYPTION)))
```
Define the ICSF information for the key with SYMCPACFWRAP(YES) and SYMCPACFRET(YES), if it was not specified on the DEFINE
```
RALTER CSFKEYS profile-name 
       ICSF(SYMCPACFWRAP(YES)   SYMCPACFRET(YES))
```
Set RACF options
- if the CSFKEYS class is not already active
```
SETROPTS CLASSACT(CSFKEYS)
```
- if the CSFKEYS class has not already been RACLISTed
```
SETROPTS RACLIST(CSFKEYS)
```
- or if the CSFKEYS class has already been RACLISTed
```
SETROPTS RACLIST(CSFKEYS) REFRESH
```

Set up CSFSERV

Important: The following setup is required only if CHECKAUTH(YES) is specified on the ICSF installation options data set. CHECKAUTH(NO) is the default.

Protect the resources CSFSERV class. ICSF controls access to cryptographic services through the CSFSERV resource class. For more information, see z/OS Cryptographic Services ICSF Administrator's Guide.

The following table summarizes the CSFSERV resource that is required for processing encrypted data sets.

Table 1. CSFSERV resource required for data set encryption
Function	ICSF callable service	Resource
CKDS Key Record Read2	CSNBKRR2	CSFKRR2

If the user does not have sufficient access, open processing will fail. An informational message ICH408I (which indicates insufficient authorization) might be issued.

Grant the user READ authority to the resource CSFSERV class:
- if the class has not already been enabled for generics
```
SETROPTS GENERIC(CSFSERV)
```
- Define profiles in the CSFSERV class to protect key labels
```
RDEFINE CSFSERV * UACC(NONE)
```
- Define profile CSFKRR2 if it does not exist
```
RDEFINE CSFSERV CSFKRR2 UACC(NONE)
```
- Give the users (preferably groups) access
```
PERMIT CSFKRR2 CLASS(CSFSERV) ID(groupid) ACCESS(READ)
```
Set RACF options:
- if the CSFSERV class is not already active
```
SETROPTS CLASSACT(CSFSERV)
```
- if the CSFSERV class has not already been RACLISTed
```
SETROPTS RACLIST(CSFSERV)
```
- or if the CSFSERV class has already been RACLISTed
```
SETROPTS RACLIST(CSFSERV) REFRESH 
```

Create an encrypted data set

To create an encrypted data set, you must assign a key label to the data set when it is newly allocated (data set create). A key label can be specified through any of the following methods:

RACF® data set profile
JCL, dynamic allocation, TSO ALLOCATE, IDCAMS DEFINE
SMS data class

Start of change To specify a key label using the DFP segment in the RACF data set profile, use keyword DATAKEY(Key-Label). The system will use this key label for data sets that are created after DATAKEY is added to the data set profile. Use keyword NODATAKEY to remove a key label, if defined, from the RACF DFP segment. The key label is ignored for a data set that is not a DASD data set. End of change

To specify a key label using JCL, dynamic allocation, or TSO allocate, use JCL keyword DSKEYLBL='key-label', dynamic allocation text unit DALDKYL, or TSO allocate DSKEYLBL(key-label). DSKEYLBL parameter is effective only if the new data set is on DASD. The key label is ignored for a data set that is not a DASD data set.

See details about the DSKEYLBL parameter(key-label) keyword on the JCL DD statement in z/OS MVS JCL Reference.

Start of change To specify a key label using SMS data class, use the Data Set Key Label field on the ISMF DEFINE/ALTER panel. The system will use this key label for data sets that are created after the data set key label is added to the data class. The key label is ignored for a data set that is not a DASD data set. End of change

See details on using the new Data Set Key Label field in the ISMF panels in z/OS DFSMS Using the Interactive Storage Management Facility.

To specify a key label using the DEFINE CLUSTER command for a VSAM CLUSTER, use the KEYLABEL parameter; for example, KEYLABEL(MYLABEL). Any alternate index associated with the CLUSTER will also be encrypted and use the same key label as specified for the CLUSTER. The key label is ignored for a data set that is not a DASD data set.

For more information on using the DEFINE CLUSTER command for a VSAM CLUSTER, see z/OS DFSMS Access Method Services Commands.

When a key label is specified on more than one source, the key label is derived from one of the above sources only on the initial data set allocation (on data set create). The key label is derived in the following order of precedence:

From the DFP segment in the RACF data set profile.
Explicitly specified on the DD statement, dynamic allocation text unit, TSO ALLOCATE command, or DEFINE CLUSTER control statement.
From the data class that applies to the current DD statement.
Note: The REFDD and LIKE JCL DD statement keywords do not cause a key label from the data set referred to be used when allocating a new data set.

On successful allocation of an encrypted data set, the following message is issued:

IGD17150I DATA SET dsname IS ELIGIBLE FOR ACCESS METHOD ENCRYPTION
KEY LABEL IS (key_label)

Specifying a key label for a non-extended format data set

If an encryption key label is specified for a DASD data set that is not extended format Start of change and the FACILITY class resource STGADMIN.SMS.ALLOW.DATASET.SEQ.ENCRYPT is not defined End of change , the key label is ignored and the data set is successfully created as non-encrypted non-extended format data set. In addition, SMS message IGD17156I is issued (or if using IDCAMS DEFINE and data set is non-SMS managed, message IDC3040I is issued) indicating that the key label is ignored. Instead to have the system fail the allocation, the user must have at least READ authority to the resource in the FACILITY class: STGADMIN.SMS.FAIL.INVALID.DSNTYPE.ENC

If this facility class resource exists and the user has at least read authority, SMS will fail the allocation and issue message IGD17151I (or if using IDCAMS DEFINE and non-SMS managed data set request, message IDC3039I is issued).

Start of change Encrypted data sets must be SMS-managed. Encrypted extended format data sets can also be compressed format. End of change

Specifying a key label for a basic or large format data set

With z/OS V2R3 and z/OS V2R4 systems (with OA56622) or higher levels, data set encryption supports basic and large format data sets. To indicate that the specification of a key label should result in the creation of an encrypted basic or large format data set (that is, indicate if the basic and large format data sets type should be regarded as a supported data set type for data set encryption), the data set must be SMS-managed and the following resource in the RACF FACILITY class must be defined: STGADMIN.SMS.ALLOW.DATASET.SEQ.ENCRYPT.

The system checks whether this resource is fully defined when the data set is first allocated (created). The system does not require any authorization to be specified for this resource in order for it to take affect. Therefore, the resource must not be defined until basic and large format data sets are to be created as encrypted.

Note: Restrictions and considerations must be evaluated before enabling encryption of basic and large format data sets.

The physical format of an encrypted basic or large format data set is enhanced with block prefixes that are transparent to BSAM and QSAM programs. The access method adds an 8-byte prefix to each physical block of the data set on output. Each block prefix will contain a value that uniquely identifies the block. The content of this prefix is relevant only to application programs that use EXCP. The prefix will not be included in the physical block size of the data set stored in the block size fields in the DSCB, DCB, DCOLLECT and SMF records. You must take the length of the block prefixes into consideration when requesting DASD space.

The prefix will not be allowed on WRITE or PUT requests, nor returned on READ and GET requests.
The system-determined block size algorithm will take the block prefix length into consideration.

Note: In rare cases, there may be encrypted basic and large format data sets which are created without a block prefix. Such a data set can only be opened for EXCP. A flag in the catalog encryption cell will indicate whether the data set has prefixes. After open, the ISITMGD macro can be used to determine the length of the prefix.

Applications using standard BSAM and QSAM APIs require no, or minimal changes, to access encrypted basic and large format data sets. Minimal change may be required if the application performs DASD space calculations that must take into account the block prefix. Applications using EXCP require changes to access encrypted basic and large format data sets by performing encryption and decryption of data. The IGGENC macro can be used to simplify encryption and decryption of data while ensuring compatibility with the access methods. (Note: All references to EXCP apply equally to the EXCPVR and XDAP macros, unless otherwise stated.)

The restrictions identified under Restrictions for encrypted data sets also apply to encrypted basic and large format data sets. Additional restrictions associated with encrypted basic and large format data sets are identified in Additional restrictions for basic and large format encrypted data sets.

Candidates for encrypted basic and large format data sets

SMF records can be used to view activity over a period of time. This information can be valuable when evaluating which basic and large format data sets may be eligible for converting to encrypted basic and large format data sets. DCOLLECT records may also be used for some of this determination. This section describes fields within SMF Type 14, SMF Type 15, and SMF Type 42-6 records that can help you identify whether your data sets would be candidates for data set encryption based on the list of restrictions for encrypted basic and large format data sets.

SMF Type 14 and SMF Type 15 records are mapped by macro IFGSMF14.
SMF Type 42-6 records are mapped by macro IGWSMF.

You must determine that the data set is a basic or large format data set. You can do this by testing a field in the JFCB which is found in SMFJFCB1. Test JFCDSORG for bit JFCORGPS being on and test for bit SMF14STR being off. This combination indicates the data set is a sequential data set but not extended format.

To determine the application that accesses the data set, you can use these fields in the SMF 14 and 15 records:

SMF14JBN for the jobname
SMFJOBID for the job identifier
SMF14SPN for the step name
SMF14PGN for the program name

To determine the application that accesses the data set, you can use these fields in the SMF 42-6 records:

S42JDJNM for the jobname

To determine if your data set is processed by EXCP:

Scan your programs for use of EXCP, EXCPVR or XDAP macros
Review SMF Type 14 and SMF Type 15 records:
- You can use SMFDCBMF to identify data sets opened with EXCP. This is a 2 byte field which is a copy of DCBMACRF, where the high order bit indicates MACRF=E. You can find DCBMACRF in the DCBD mapping macro.
- You can then also use SMF14EXCPBAM bit to identify data sets opened with BSAM or QSAM, but then accessed via EXCP.
Review SMF 42-6 records:
- You can use S42DSEXC to identify data sets opened with EXCP.
Note: Use the z Batch Network Analyzer tool to identify data sets accessed by EXCP, as it uses the SMF records to make this determination.
To determine if your data set is accessed by an EXCP application that can support encrypted data sets:
- You can use flag SMF14DSENCRYPTOK to identify whether the application program used EXCP and the program is enabled to handle data set encryption for basic and large format data sets. This does not imply that the data set is DASD.
  Note: The system detects this condition by testing DCBE DSENCRYPT=OK is specified regardless of the data set type.

Determine if your data sets meet the restrictions for encrypted basic/large format data sets

To determine if your data set meets the minimum block size requirement:

You can use the SMFJFCB1 field to find the block size of the data set. Using the JFCB mapping macro, IEFJFCBN, test field JFCBLKSI to determine if the block size is at least the minimum required for encryption, which is 16 bytes.
You can use S42DSBSZ in SMF 42-6 for block size.

To determine if your data set meets the minimum record length requirement:

You can use the SMFJFCB1 field to find the record length of the data set. Using the JFCB mapping macro, IEFJFCBN, test field JFCLRECL to determine if the record length is at least the minimum required for encryption, which is 16 bytes for record format F(B(S)) and 12 bytes for record format V(B(S)). Use SMFDCBRF to determine the record format, which is mapped the same as DCBRECFM.
You can also use the following to view the record format, block size and record length:
- TSO LISTDSI command for REXX
- IEHLIST LISTVTOC
- ISPF option 3.2

To determine if your data set uses hardware keys (DCBKEYLE):

You can use the SMFJFCB1 field to determine if hardware keys are used with the data set. Using the JFCB mapping macro, IEFJFCBN, test field JFCKEYLE for zeros to ensure no hardware keys are in use.

To determine if your data set is accessed by BDAM:

You can use the SMF14DDA bit to determine if BDAM has been used to access the data set. If the flag is on, this data set is not a candidate for encryption.

The SMF records indicate processing based on a span of time. You can use the IDCAMS DCOLLECT command to create records for data sets that might not have been accessed recently. These records help with analysis of the attributes of data sets, but do not show how the data sets were used. The mapping macro for DCOLLECT records is IDCDOUT.

To determine the block size, you can use DCDBKLNG.
To determine the record length, you can use DCDLRECL.
To determine the record format, you can use DCDRECRD. This is a copy of DCBRECFM.
To determine the data set organization, you can use DCDDSORG.

Enable data set encryption

An enablement action is required to allow the creation of encrypted data sets when the key label is specified through a method outside of the DFP segment in the RACF data set profile.

To allow the system to create encrypted data sets using a key label specified through a method other than through the DFP segment in the RACF data set profile, the user must have at least READ authority to the following resource in the FACILITY class:

STGADMIN.SMS.ALLOW.DATASET.ENCRYPT

Note: IBM recommends that you define STGADMIN.* with UACC(NONE).

The system checks the user's authority to access this resource when a data set to be encrypted is first allocated (that is, created). It is not checked again before encrypting a data set.

Allocation processing

SMS allocation processing determines if a data set can be allocated as an encrypted data set. Under certain conditions, you can specify how the allocation should proceed. The following tables summarize the system behavior during SMS allocation processing for a new data set based on specific FACILITY class resources and the user's authorization to the resource.

On a z/OS V2R2 system (with OA50569) and later, the following table describes the result of an allocation request for an extended format data set when a key label has been specified. On a successful allocation, the resulting data set will be an encrypted extended format data set. Other factors not described in this table (such as lack of space) might cause the allocation to fail.

Start of change Encrypted data sets must be SMS-managed. Encrypted extended format data sets can also be compressed format. End of change

Table 2. SMS allocation processing based on system levels and allocation request (z/OS V2R2 with OA50569)
FACILITY class resource	STGADMIN.SMS.ALLOW.DATASET.ENCRYPT
Access	Not defined OR not authorized		At least authorized for READ
Allocation type	JCL	IDCAMS DEFINE	JCL	IDCAMS DEFINE
Key label from DFP segment of RACF DS profile	Allocation continues with IGD17150I	Allocation continues with IGD17150I	Allocation continues with IGD17150I	Allocation continues with IGD17150I
Key label from a source other than DFP segment of RACF DS profile	Allocation fails with IGD17155I	Allocation fails with IDC3038I	Allocation continues with IGD17150I	Allocation continues with IGD17150I

On a z/OS V2R2 system (with OA50569) and above, the following table describes the result of an allocation request for a DASD non-extended format data set when a key label has been specified from any source. On a successful allocation, the resulting data set will be a non-encrypted non-extended format data set. Other factors not described in this table (such as lack of space) might cause the allocation to fail.

Table 3. SMS allocation processing based on system levels and allocation request (z/OS V2R2 with OA50569)
FACILITY class resource	STGADMIN.SMS.FAIL.INVALID.DSNTYPE.ENC
Access	Not defined OR not authorized		At least authorized for READ
Allocation type	JCL	IDCAMS DEFINE	JCL	IDCAMS DEFINE
SMS mgd	Allocation continues with IGD17156I	Allocation continues with IGD17156I	Allocation fails with IGD17151I	Allocation fails with IGD17151I
non-SMS mgd	Allocation fails with IGD17156I	Allocation fails with IDC3040I	Allocation fails with IGD17151I	Allocation fails with IDC3039I

On a z/OS V2R1 system (with OA50569), the following table describes the result of an allocation request for a DASD data set (extended format and non-extended format) when a key label has been specified from any source. On a successful allocation, the resulting data set will be a non-encrypted data set since you cannot create new encrypted data sets on a z/OS V2R1 system. Other factors not described in this table (such as lack of space) might cause the allocation to fail.

Table 4. SMS allocation processing based on system levels and allocation request (z/OS V2R1 with OA50569)
FACILITY class resource	STGADMIN.SMS.FAIL.INVALID.DSNTYPE.ENC
Access	Not defined OR not authorized		At least authorized for READ
Allocation type	JCL	IDCAMS DEFINE	JCL	IDCAMS DEFINE
Key label specified on JCL (DSKEYLBL)	Job fails with IEFC630I	N/A	Job fails with IEFC630I	N/A
Key label specified on IDCAMS DEFINE (KEYLABEL)	N/A	Allocation fails with IDC3211I	N/A	Allocation fails with IDC3211I
Key label from DFP segment of RACF DS profile or from data class)	Refer to the following two rows
SMS mgd	Allocation continues with IGD17156I	Allocation continues with IDC3040I	Allocation fails with IGD17154I	Allocation fails with IDC0017I
non-SMS mgd	Allocation continues with IGD17156I	Allocation continues with IDC3040I	Allocation fails with IGD17154I	Allocation fails with IDC0017I

Accessing encrypted data sets

Applications that use standard BSAM, QSAM, and VSAM APIs do not require changes to access encrypted data sets. The user data transferred between the application and the access methods is in the unencrypted form. The access method encrypts the data when writing to DASD and decrypts the data when reading from DASD. For encrypted compressed format data sets, the access method compresses the data before encrypting it on output. On input, the access method decrypts the data before decompressing it.

Considerations regarding ICSF startup and shutdown

If you plan to encrypt SMF data sets or other data sets used during z/OS initialization, you must ensure that ICSF is started early in the IPL process to avoid delays in z/OS initialization and termination. As such, it is highly recommended the command S CSF,SUB=MSTR is placed early in the COMMNDxx member to ensure that there is minimum delay in z/OS initialization. Specifying SUB=MSTR is necessary to allow ICSF to start before JES.

Furthermore, during z/OS system shutdown, ICSF must be one of the last features to stop so that dependent functions are not impacted. It is highly recommended that you shut down ICSF after terminating the JES address space and after initiating SMF halt processing. Note when ICSF is stopped after SMF is halted, that there might not be an SMF record cut for the termination of ICSF. (The ability to start ICSF with SUB=MSTR is available on all supported releases of ICSF.)

Considerations regarding backup/migration/replication functions

Key label authorization

The following system functions maintain data in the encrypted form. Therefore, users performing these functions do not require authorization to the key label associated with the data sets being processed with these functions:

DFSMSdss functions: COPY, DUMP, and RESTORE
DFSMShsm functions: migrate/recall, backup/recover, abackup/arecover, dump/data set restore, FRBACKUP/FRRECOV DSNAME
Track based copy (PPRC, XRC, FlashCopy®, concurrent copy) operations

Other considerations

DFSMSdss REBLOCK keyword is ignored on COPY and RESTORE functions for encrypted data sets.
DFSMSdss ADRREBLK installation exit will not be called for encrypted data sets.
DFSMSdss does not support VALIDATE processing when backing up encrypted indexed VSAM data sets. VALIDATE will be ignored.
Backup and migration of encrypted data sets may impact expected savings with disk or tape device compression. Where possible, convert to compressed format data sets. When data set level compression requested, access methods handle compression before encryption for compressed format encrypted data sets.

Considerations when planning for data set encryption

Encrypted data sets can be extended format. Refer to Extended-Format VSAM Data Sets and Processing Extended-Format Sequential Data Sets for information on allocating extended format data sets, including guidelines and restrictions.
Sequential extended format data sets can be version 1 or 2. When allocating an encrypted sequential extended format data set, the system creates the data set as an extended format version 2 data set, regardless of the user's specification for version number on DSNTYPE or the PS_EXT_VERSION keyword in the IGDSMSxx member in PARMLIB.
Encrypted data do not compress. Therefore, encrypted data sets might not benefit from storage savings when relying on disk and tape device compression, as well as other areas in the infrastructure that attempt to compress data. Where possible, consider using compressed format data sets. (Note that only sequential extended format data sets and VSAM extended format KSDS data sets can be compressed format.) When data set level compression is requested along with encryption, access methods handle compression before encryption for encrypted compressed format data sets. Refer to Compressed Data and Allocating Compressed-Format Data Sets for information on allocating compressed format data sets, including guidelines and restrictions. Only sequential extended format data sets and VSAM extended format KSDS data sets can be compressed format.
When processing encrypted data sets, the access methods may use additional internal system buffers during read and write processing. For optimal performance, consider increasing memory to your user address space as your use of encrypted data sets increases.

Restrictions for encrypted data sets

System data sets (such as Catalogs, SMS control data sets, SHCDS, HSM data sets) must not be encrypted, unless otherwise specified in product documentation.
Data sets used during IPL must not be encrypted.
Encrypted data sets only supported on 3390 device types.
Sequential (non-compressed) data sets with a BLKSIZE of less than 16 bytes cannot be encrypted.

Additional restrictions for basic and large format encrypted data sets

The minimum size of any user block written to an encrypted data set is 16 bytes. Using BSAM or QSAM, an attempt to write a block less than 16 bytes will fail with ABEND 002-F2.
The minimum DCB LRECL is 16 bytes for RECFM (F(B(S)) and 12 bytes for RECFM V(B(S)). An attempt to open a data set with LRECL less than the minimum supported will fail with ABEND 213-89.
Encrypted basic and large format data sets do not support hardware keys (DCBKEYLE). An attempt to open a data set with a non-zero key length will fail with 213-99. Diagnostic information in the message will clearly identify the reason for this failure.
BDAM does not support processing encrypted basic and large format data sets. An attempt to open an encrypted basic or large format data set with BDAM will fail with 213-99. Diagnostic information in the message will clearly identify the reason for this failure.
Checkpoint/Restart does not support open encrypted basic or large format data sets. Also, checkpoint data sets cannot be encrypted. An attempt to take a checkpoint when an encrypted basic or large format data set is open or when the checkpoint data set is encrypted, will fail with return code 08 and reason code 568.

For potential restrictions associated with other products, consult the corresponding product documentation.

See the following publications for more details on data set encryption support:

References:

IBM Techdocs: Data Set Encryption for IBM z/OS V2.2 Frequently Asked Questions

z/OS DFSMS Access Method Services Commands

z/OS DFSMSdfp Storage Administration

z/OS DFSMSdss Storage Administration

z/OS DFSMShsm Storage Administration

z/OS Cryptographic Services ICSF Administrator's Guide

z/OS Cryptographic Services ICSF System Programmer's Guide