Deploying z/OS data set encryption
This chapter provides information about how to deploy z/OS data set encryption. It also includes checklists to help you determine whether your environment is ready for deployment.
This chapter includes the following topics:
5.1 Readiness checklists for deployment
Questions to help you determine what is needed for your z/OS data set encryption implementation are listed in Table 5-1. Any questions that are relevant to your environment should be answered to provide a complete understanding of the requirements.
Table 5-1 Checklist for determining deployment readiness for z/OS data set encryption
Checklist item
Comments
More information
Have you installed the required hardware and software components and prerequisites?
z/OS data set encryption is available on z/OS V2.2 and V2.3, and toleration support is available on z/OS V2.1.
 
Considerable improvements are made with the cryptographic functions in z14 and Crypto Express6s, compared to earlier generations.
 
CPACF encryption rates for AES on z14 are up to 7x faster than on the z13 according to IBM tests. The Crypto Express6S processes crypto operations at up to twice the speed of the previous Crypto Express5S.
 
 
Have you determined the performance effect that z/OS data set encryption might have on the CPUs?
Use the IBM Z Batch Network Analyzer (zBNA) and zCP3000 to determine potential performance effects.
Have you determined which data sets will be encrypted?
Supported data set types are extended format sequential and extended format Virtual Storage Access Method (VSAM).
Will you use data compression?
Encrypted data is not compressible. Therefore, where possible, consider the use of access method compression with data set encryption. When used together, the access methods compress the data at the server before it is encrypted and written out. For compressing extended format sequential data sets, zEDC offers a low overhead solution for compression.
Have you defined the naming standards that you will use?
Consider defining naming conventions to group data sets logically. Proper naming standards facilitate the ease of migrating key labels and keys to another machine or Business Partner.
 
Have you identified how to supply the key label to create an encrypted data set?
To create an encrypted data set, a key label must be supplied at the time the data set is initially allocated (created).
Have you determined the owners of the new tasks for administering and maintaining encrypted data sets?
Fine or course grained access controls can limit access to data content by personnel that can otherwise pose a possible exposure point.
Have you determined the Resource Access Control Facility (RACF) or System Authorization Facility (SAF) controls that you will be using?
Assess access controls based on your security policies and how they apply to data set encryption.
 
Have you determined which key management tools you will use?
You can create master keys by using a TKE workstation, which includes smart cards and smart card readers.
 
You can create operational keys by using EKMF or an alternative product.
 
Note: EKMF is useful in managing secure keys in large or multi-site organizations.
 
ICSF is a panel-driven operational key entry and management tool.
Have you defined your key lifecycle management process?
Track changes to key’s parameters during its lifecycle.
Does your PARMLIB contain the required ICSF CSFPRMxx and Installation Options DataSet?
Parameters for ICSF setup.
Have you determined your ICSF storage requirements?
Determine allocation size and format of the CKDS.
Have you determined the best time to start ICSF during the IPL process?
ICSF must always be up and running because all access to encrypted data sets depends on calls that are made to ICSF.
Have you considered your backup/recovery planning scenarios?
The disaster plan includes a mirrored implementation of data set encryption at the backup site with the appropriate master key, ICSF release, and key data sets.
 
Have you considered sysplex sharing and remote site usage, if applicable?
Consider whether systems in the parallel sysplex must share the master key and CKDS.
Have you considered what is required to fall back?
Any implementation requires a plan to fall back.
Have you reviewed your security, audit, and compliance practices?
In support of z/OS data set encryption, identify if any gaps exist in your current practices.
Are you collecting applicable System Management Facility (SMF) records for data set encryption?
Ensures that you are compliant and ready for an audit by collecting SMF Record types 14, 15, 62, and 82.
Have you considered the use of security tools for your Z environment?
Ensure that your security policies and keys are managed and monitored. Auditors can quickly determine whether files were encrypted with IBM Security zSecure Suite.
Have you planned for test scenarios and education for potential users?
This IBM Redbooks publication can be used as a reference for building test scenarios and education.
Review all chapters of this publication.
A checklist that can be used for implementing access controls as part of data set encryption is included in Table 5-2.
Table 5-2 Access controls and policies checklist
Checklist item
Comments
More information
Have you determined your data set access criteria?
This issue includes restricting access to the ICSF data sets, which contain the encryption keys and associated key labels for your installation.
Have you defined your RACF profiles, including CSFSERV, CSFKEYS, and XFACILIT?
CSFSERV profiles control access to ICSF services, such as defining encryption keys.
 
CSFKEYS profiles control access to cryptographic keys in the ICSF Key Data Sets (CKDS and PKDS) and enables or disables the use of protected keys.
 
XFACILIT class defines rules for the user of encrypted key tokens that are stored in the CKDS and PKDS.
Have you created entries in OPERCMDS?
To ensure that operators do not enter STOP ICSF or SET ICSF commands without authorization.
Have you reviewed the Catalog LISTCAT access command?
Restricted usage of LISTCAT display of data sets (z/OS 2.3 feature).
5.2 Deploying z/OS data set encryption
This IBM Redbooks publication assumes the z/OS data set encryption configuration use the CPACF and Crypto Express features on the Z platform, and secure keys and protected keys.
With the planning complete and the prerequisites in place, you are now ready to deploy z/OS data set encryption. For the tasks that are described in the remainder of this chapter, we assume that the following prerequisites are met:
•ICSF is up and running with the CKDS initialized
•Crypto Express adapters are configured in CCA mode with assigned domains
•AES master keys are active
If ICSF is not yet installed in your environment, see the following resources:
•For more information about planning and configuration, see z/OS Cryptographic Services ICSF Administrator's Guide.
 
Note: If you plan to share encrypted data sets across multiple systems, ensure that all z/OS data set encryption prerequisites were met on all systems before shared encrypted data sets are created.
For setup and configuration examples of those components, see steps 1- 5 in the CRYPTO wiki of the IBM developerWorks® website.
The Z hardware and software environment that used in this chapter is shown in Figure 5-1. The environment consists of the following components:
•z14 (with CPACF)
Crypto Express6S adapter with a domain value of 084
•Running z/OS V2R3 with:
 – Resource Access Control Facility (RACF).
 – Integrated Cryptographic Service Facility (ICSF) active, at HCR77C1 level, with the Advanced Encryption Standard (AES) master key loaded. For more information about for CSFPRMxx settings on LPAR CETUS2B (SC60), see 4.3.3, “CSFPRMxx and installation options” on page 72.
 – Cryptographics key data set (CKDS) in common record format (KDSR) to allow for reference date tracking.
Figure 5-1 z14 hardware and software environment
Because this scenario was built as a monoplex environment, the CKDS is not shared with other systems. For more information about the steps to share the CKDS with other systems as you move to production, see 4.3.3, “CSFPRMxx and installation options” on page 72.
Starting z/OS data set encryption deployment
The high-level steps in the deployment of data set encryption are shown in Figure 5-2.
Figure 5-2 High-level steps for deployment of data set encryption
A data set is defined as encrypted when a key label is supplied on allocation of a new sequential or VSAM extended format data set. A key label is supplied by way of new keywords in any of the following sources (using order of precedence):
•The Data Facility Product (DFP) segment in the RACF data set profile
•JCL, Dynamic Allocation, TSO Allocate, and IDCAMS DEFINE
•Storage Management Subsystem (SMS) Construct: Data Class
Choosing the method to request data set encryption
For a specific high-level qualifier (HLQ), you might have many different RACF profiles. You might think that to encrypt these data sets, you must update all the RACF profiles, a process that is burdensome. You might also think that a better approach is to update one or a few data classes, according to the SMS rules. The use of DFSMS can be viewed as more generic and an easier method to implement.
Although you might find it easier to use the DATACLAS keyword in your environment, a side effect of the use of this method is that it takes control of creating encrypted data sets out of the hands of a security administrator and puts it into the hands of the Db2 administrators, storage administrators, or other users. One important reason to use data set encryption is to prevent administrators from accessing sensitive data and removing them from compliance scope.
Pervasive encryption as a whole is intended to be a security capability. As a security capability, we recommend the use of the security profiles (that is, DATASET class) along with defining the following resource profile in the FACILITY class:
RDEFINE FACILITY STGADMIN.SMS.ALLOW.DATASET.ENCRYPT UACC(NONE)
Specifying UACC(NONE) prevents unauthorized users from encrypting data sets without oversight by the security administrator.
From a security perspective, the security administrator controls, determines, and oversees who can encrypt data sets. It might be said that enough security oversight is provided because the security administrator gives users the authorization to a key label within the CSFKEYS class. However, the recommended way to manage encrypted data sets is to use the RACF profile. Therefore, it takes precedence over all other means of setting a key label.
A tradeoff exists between ease of setup (that is, SMS DATACLAS) and security control (that is, the RACF DATASET class).
Use of the RACF profile is the recommended setup for z/OS Data Set Encryption to ensure the most secure environment.
5.3 Generating a secure 256-bit AES DATA key
Secure or protected keys are recommended for use with z/OS data set encryption. For more information about secure and protected keys, see 1.5.1, “IBM Z cryptographic system” on page 9 and 3.5.2, “Reviewing industry regulations” on page 42.
Generating a secure 256-bit AES DATA key can be done by using one of the following methods:
•Enterprise Key Management Foundation (EKMF)
•ICSF panels
•ICSF APIs
•CSFKGUP
5.3.1 Using Enterprise Key Management Foundation
The EKMF workstation can generate and manage keys across various platforms and in various keystores, including the z/OS ICSF CKDS.
Generating a 256-bit AES DATA key with EKMF
EKMF uses key templates to define and save the characteristics of a key. Key templates contain the following information:
•Title
•Description
•Key label pattern
•Key state
•Key size
•Algorithm
After a key template is created, it can be used to generate any number of keys in bulk.
The EKMF key template editor window is shown in Figure 5-3.
Figure 5-3 EKMF Key Template window
EKMF stores its keys in its own database and the keys are securely distributed to keystores when needed.
An architectural overview of EKMF with the relationships to ICSF and other z/OS components is shown in Figure 5-4.
Figure 5-4 EKMF architectural overview
5.3.2 Using ICSF panels
ICSF release HCR77C1 gives users the option of generating AES DATA keys by using the ICSF Utility panel. From the panel, you specify a key label and the key length to generate a key.
Authorization
Users must have READ authority to the following resources in the CSFSERV class to perform key generation by using the ICSF panels:
•CSFKRR2
•CSFKGN
•CSFKRC2
For more information about the RACF commands to authorize users to the CSFSERV class, see 4.2.2, “Defining DATASET, CSFSERV, CSFKEYS, and other resources” on page 61.
Generating a 256-bit AES DATA key with ICSF panels
From the ICSF Primary menu (see Figure 5-5), select 5 UTILITY - ICSF Utilities → 5 CKDS KEYS - Manage keys in the CKDS → 7 Generate AES DATA keys.
Figure 5-5 HCR77C1 for System SC60
In the CKDS Generate Key panel (see Figure 5-6), enter the key (record) label and select the AES key bit length. Press Enter to generate the key.
Figure 5-6 CKDS Generate Key panel
If the record exists, the Record Replace Confirmation panel appears (see Figure 5-7).
 
Important: By replacing the key, applications cannot decrypt the associated data sets.
Figure 5-7 Record Replace Confirmation
You see a message that indicates a 256-bit AES DATA key was successfully generated (see Figure 5-8).
Figure 5-8 Key generated successfully message
No refresh of the CKDS is required when the key is generated by using this method.
5.3.3 Using ICSF APIs
ICSF-callable services support the programmatic generation of AES DATA keys. After a key is generated, the key can be stored in the CKDS and associated with a key label.
Authorization
Users must have READ authority to the following resources in the CSFSERV class to perform key generation with the associated ICSF callable service:
•CSFKGN
•CSFKRC2
For more information about the RACF commands to authorize users to the CSFSERV class, see 4.2.2, “Defining DATASET, CSFSERV, CSFKEYS, and other resources” on page 61.
Generating a 256-bit AES DATA Key with ICSF APIs
For more information about a Rexx sample to create a 256-bit AES DATA type key, see the IBM Crypto Education topic of the IBM developerWorks website.
5.3.4 Using CSFKGUP
The key generator utility program (KGUP) generates and maintains keys in the CKDS. To run KGUP, ICSF must be active, and the user must have access to KGUP (by way of the CSFKGUP profile in the CSFSERV class) and UPDATE authority to the profile that is covering the CKDS in the DATASET class.
In addition, if key lifecycle auditing of tokens or labels is enabled, the option AUDITKEYLIFECKDS(TOKEN(YES)) or AUDITKEYLIFECKDS(LABEL(YES)) is specified in CSFPRMxx. The user also must have access to the CSFGKF profile in the CSFSERV class to generate the key fingerprint that is used in auditing.
When KGUP generates a secure AES DATA key value, the program adds an entry in the CKDS that is enciphered under your system’s master key. For z/OS data set encryption, a 256-bit AES DATA type key must be generated.
Authorization
Users must have READ authority to the following resources in the CSFSERV class to perform key generation with KGUP:
•ICSF running with CHECKAUTH(YES) - CSFKGUP, CSFKGN
•ICSF running with CHECKAUTH(NO) - CSFKGUP
Users must also have UPDATE authority to the CKDS in the DATASET class to perform key generation with KGUP.
For more information about the RACF commands to authorize users to the CSFSERV and DATASET classes, see 4.2.2, “Defining DATASET, CSFSERV, CSFKEYS, and other resources” on page 61.
Generating a 256-bit AES DATA Key with KGUP
A JCL sample to create a 256-bit AES DATA type key with key label of DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001 is shown in Example 5-1.
Example 5-1 JCL example to create a 256-bit AES DATA type key
//STEP10 EXEC PGM=CSFKGUP
//CSFCKDS DD DISP=OLD,DSN=SYS1.SC60NEW.SCSFCKDS
//CSFIN DD *,LRECL=80
ADD TYPE(DATA) ALGORITHM(AES),
LABEL(DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001) LENGTH(32)
/*
//CSFDIAG DD SYSOUT=*,LRECL=133
//CSFKEYS DD SYSOUT=*,LRECL=1044
//CSFSTMNT DD SYSOUT=*,LRECL=80
Multiple keys can be generated with each run of the KGUP.
A JCL sample to create three 256-bit AES DATA type keys with a key label of DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001/2/3 is shown in Example 5-2.
Example 5-2 JCL example create three 256-bit AES DATA type key
//STEP10 EXEC PGM=CSFKGUP
//CSFCKDS DD DISP=OLD,DSN=SYS1.SC60NEW.SCSFCKDS
//CSFIN DD *,LRECL=80
ADD TYPE(DATA) ALGORITHM(AES),
LABEL(DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001,
DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000002,
DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000003) LENGTH(32)
/*
//CSFDIAG DD SYSOUT=*,LRECL=133
//CSFKEYS DD SYSOUT=*,LRECL=1044
//CSFSTMNT DD SYSOUT=*,LRECL=80
Consider the following points regarding Example 5-1 on page 110 and Example 5-2 on page 110:
•TYPE must be DATA.
•ALGORITHM must be AES.
•A key LABEL can consist of up to 64 characters.
The first character must be alphabetic or a national character (#, $, or @). The remaining characters can be alphanumeric, a national character (#, $, or @), or a period (.). The key label is used to identify the key in the ICSF keystore (CKDS).
•LENGTH specified as 32, which generates 256-bit key.
Key generation output is shown in Example 5-3.
Example 5-3 Key generation output
KEY GENERATION DIAGNOSTIC REPORT
ADD TYPE(DATA) ALGORITHM(AES),
LABEL(DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001) LENGTH(32)
>>>CSFG0321 STATEMENT SUCCESSFULLY PROCESSED.
>>>CSFG0780 A REFRESH OF THE IN-STORAGE CKDS IS NECESSARY TO ACTIVATE CHANGES MADE BY KGUP.
>>>CSFG0002 CRYPTOGRAPHIC KEY GENERATION - END OF JOB. RETURN CODE = 0.
Refreshing in-storage copy of CKDS
ICSF references an in-storage copy of the CKDS for key label lookup. However, when KGUP is used to generate the AES DATA key, change the CKDS that is stored on disk rather than the in-storage copy. ICSF does not recognize the changes that were made to disk unless the CKDS is refreshed such that the in-storage copy of the CKDS is updated.
When you update the CKDS on disk and you are sharing the CKDS in a sysplex, use the Coordinated CKDS Refresh panel utility to refresh the CKDS so that all members of the sysplex can see the new keys. Otherwise, the other members of the sysplex cannot decrypt data that was encrypted by the system on which the refresh was issued.
When you update the CKDS on disk and you are not in a sysplex, you can use the Refresh option on the Key Administration panel to replace the in-storage copy with the disk copy. You also can start a utility program to refresh the CKDS.
 
Note: This refresh is only necessary when KGUP is used to generate the key as it writes directly to the CKDS on disk. No refresh is required for keys that are generated by the ICSF panel or callable services.
A JCL sample to refresh the in-storage copy of CKDS by using ICSF utility program CSFEUTIL is shown in Example 5-4.
Example 5-4 Refresh in-storage copy of CKDS by using ICSF utility program CSFEUTIL
//STEP20 EXEC PGM=CSFEUTIL,
// PARM='SYS1.SC60NEW.SCSFCKDS,REFRESH'
The messages from successful refresh by using CSFEUTIL are shown in Example 5-5.
Example 5-5 Messages from successful refresh
CSFM653I CKDS LOADED 12 RECORDS WITH AVERAGE SIZE 249
CSFU002I CSFEUTIL COMPLETED, RETURN CODE = 0, REASON CODE = 0.
To refresh the in-storage copy of the CKDS, from the ICSF Primary menu, select Option 8 KGUP (Key Generator Utility processes) → Option 4 Refresh (Activate an existing cryptographic key data set).
Refresh in-storage CKDS panel is shown in Figure 5-9.
Figure 5-9 ICSF Refresh in-storage CKDS
Press Enter to perform the refresh. A successful refresh results in message CSFM653I (see Example 5-6).
Example 5-6 Message CSFM6531
CSFM653I CKDS LOADED 10 RECORDS WITH AVERAGE SIZE 252
The Refresh in-storage CKDS panel displays a message to indicate a successful refresh (see Figure 5-10).
Figure 5-10 ICSF Refresh Successful message
The following refresh can also be performed from Option 2.1; 1.2 from the ICSF Primary menu:
•Option 2 KDS MANAGEMENT: Master key set or change, KDS Processing
•Option 1 CKDS MANAGEMENT: Perform Cryptographic Key Data Set (CKDS) functions including master key management
•Option 1 CKDS OPERATIONS: Initialize a CKDS, activate a different CKDS (Refresh), or update the header of a CKDS and make it active
•Option 2 REFRESH: Activate an updated CKDS
5.4 Protecting data sets with secure keys
A key label can be supplied in any of the following options (using order of precedence):
•The Data Facility Product (DFP) segment in the RACF data set profile
•JCL, Dynamic Allocation, TSO Allocate, and IDCAMS DEFINE
•Storage Management Subsystem (SMS) Construct: Data Class
To make data set encryption unavailable to users who are not authorized to use it, complete the following tasks:
•Define the STGADMIN.SMS.ALLOW.DATASET.ENCRYPT profile in the FACILITY class, and set the universal access to NONE, as shown in the following example:
RDEFINE FACILITY STGADMIN.SMS.ALLOW.DATASET.ENCRYPT UACC(NONE)
•If the FIELD class is active, check for any profile that allows any user without the SPECIAL attribute access to the DATASET.DFP.DATAKEY. If no profile exists, no other action is needed. If any profile allows access to DATASET.DFP.DATAKEY, create a DATASET.DFP.DATAKEY profile in the FIELD class with a UACC of NONE, as shown in the following example:
RDEFINE FIELD DATASET.DFP.DATAKEY UACC(NONE)
Taking these steps helps ensure that only authorized users are allowed to use data set encryption. Users must have at least READ authority to resource STGADMIN.SMS.ALLOW.DATASET.ENCRYPT in the FACILITY class to create encrypted data sets when the key label is specified by way of a method other than the DFP segment in the RACF data set profile.
The system does not require the user to have authority to resource STGADMIN.SMS.ALLOW.DATASET.ENCRYPT when the key label is specified in the DFP segment in the RACF data set profile.
To create a set of SAF resources to protect new data sets (PE08.ENCRYPT.DS.*) with encryption, complete the following steps:
1. Create a generic DATASET resource to protect a set of data sets, as shown in the following example:
ADDSD 'PE08.ENCRYPT.DS.*' UACC(NONE)
2. Specify the encryption key label in the DFP segment (the recommended way to supply a key label is for a security administrator to add the key label to the DFP segment), as shown in the following example:
ALTDSD 'PE08.ENCRYPT.DS.*' DFP(DATAKEY(DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001))
3. Non-encrypted data sets must be copied over to these new (PE08.ENCRYPT.DS.*) data sets to be protected by encryption.
5.5 Encrypting a data set with a secure key
To create an encrypted data set, you must assign a key label to the data set when it is newly allocated (data set create). In addition, an encrypted data set must be allocated as an extended format data set in one of the following ways:
•JCL, by way of DSNTYPE=EXTPREF or DSNTYPE=EXTREQ
•TSO allocate, by way of DSNTYPE(EXTPREF) or DSNTYPE(EXTREQ)
•IDCAMS DEFINE parameter DATACLASS reference an extended format dataclass
•Dynamic allocation text unit DALDSNT
A key label can be specified by using any of the following methods:
•RACF data set profile
To specify a key label by using the DFP segment in the RACF data set profile, use keyword DATAKEY(Key-Label). The system uses this key label for extended format data sets that are created after DATAKEY is added to the data set profile. Use new keyword NODATAKEY to remove a key label (if previously defined) from the DFP segment.
The key label is ignored for a data set that is not a DASD data set. The key label is also ignored for a data set that is not extended format unless the user has READ access to the STGADMIN.SMS.FAIL.INVALID.DSNTYPE.ENC resource in the FACILITY class.
 
Note: A key label that is specified in the DFP segment in the RACF data set profile is used regardless of the setting of ACSDEFAULTS that is specified in SYS1.PARMLIB(IGDSMSxx).
•To specify a key label by using JCL, dynamic allocation, and TSO, allocate the use the following components:
 – JCL keyword DSKEYLBL=’key-label’
 – Dynamic allocation text unit DALDKYL
 – TSO allocate DSKEYLBL(label-name)
DSKEYLBL 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.
For more information about the DSKEYLBL(key-label) keyword on the JCL DD statement, see z/OS MVS JCL Reference at IBM Knowledge Center.
•SMS data class
To specify a key label by using SMS data class, use the Data Set Key Label field in the Interactive Storage Management Facility (ISMF) DEFINE/ALTER panel.
The system uses this key label for extended format 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.
For more information about the use of the new Data Set Key Label field in the ISMF panels, see z/OS DFSMS Using the Interactive Storage Management Facility at IBM Knowledge Center.
•IDCAMS DEFINE command
To specify a key label by using the IDCAMS DEFINE command for a Virtual Storage Access Method (VSAM) data set, use the KEYLABEL parameter, as shown in the following example:
KEYLABEL(MYLABEL)
Any alternative index that is associated with the VSAM base cluster is encrypted and uses the same key label as specified for the base cluster. The key label is ignored for a data set that is not a DASD data set.
For more information about the use of the IDCAMS DEFINE command for a VSAM data set, see z/OS DFSMS Access Method Services Commands at IBM Knowledge Center.
When a key label is specified on more than one source, the key label is derived from one of these sources only on the first 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 IDCAMS DEFINE 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 which the data set is referred to be used when allocating a new data set.
On successful allocation of an encrypted data set, the successful allocation message that is shown in Example 5-7 is issued.
Example 5-7 Successful allocation message
IGD17150I DATA SET dsname IS ELIGIBLE FOR ACCESS METHOD ENCRYPTION
KEY LABEL IS (key_label)
 
Note: When a key label is specified for a DASD data set that is not extended-format, allocation fails and the message IGD17151I is issued. When IDCAMS DEFINE is used, message IDC3009I is issued with RC48 and RSN82.
5.6 Verifying that the data set is encrypted
The IDCAMS LISTCAT command can be run to verify that a data set is enabled for encryption, as shown in the following example:
LISTCAT ENTRIES('PE08.ENCRYPT.DS.D01') ALL
The output of LISTCAT for a data set is shown in Example 5-8. The encryption data section indicates that the data set is encrypted and displays the key label. The attributes section shows that the data set is in EXTENDED format.
Example 5-8 IDCAMS LISTCAT for the data set
NONVSAM ------- PE08.ENCRYPT.DS.D01
IN-CAT --- UCAT.CONCAT
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2017.317
RELEASE----------------2 EXPIRATION------0000.000
ACCOUNT-INFO-----------------------------------(NULL)
SMSDATA
STORAGECLASS ----DEFAULT MANAGEMENTCLASS---(NULL)
DATACLASS ----------EFEA LBACKUP ---0000.000.0000
ENCRYPTIONDATA
DATA SET ENCRYPTION----(YES)
DATA SET KEY LABEL-----DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001
VOLUMES
VOLSER------------CONSM1 DEVTYPE------X'3010200F' FSEQN---------
---------0
ASSOCIATIONS--------(NULL)
ATTRIBUTES
VERSION-NUMBER---------2
STRIPE-COUNT-----------1
EXTENDED
5.7 Granting access to encrypted data sets
The CSFKEYS class controls access to cryptographic keys that are identified by the key label. Any user that needs access to data that is encrypted with a data key that is associated with a key label must have access to that key label.
Complete the following steps to set up a key label:
1. If the CSFKEYS class was not enabled for generic usage, run the following command:
SETROPTS GENERIC(CSFKEYS)
2. Define a profile so no user can access key label (DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001) and use the key label for a protected key by using the following command:
RDEFINE CSFKEYS DATASET.PE08.ENCRYPT.DS.ENCRKEY.* UACC(NONE) ICSF(SYMCPACFWRAP(YES) SYMCPACFRET(YES))
Consider the following points:
 – UACC(NONE) indicates that no universal access to the key label exists.
 – SYMCPACFWRAP(YES) indicates that ICSF can rewrap the encrypted key by using the Central Processor Assist for Cryptographic Function (CPACF) wrapping key.
 – SYMCPACFRET(YES) indicates that keys that are covered by the profile can be returned to an authorized caller in the protected-key CPACF form.
Any of the following situations cause a IEC143I 213-85 message:
 – Attempting to use a non-existent key label.
 – No RACF CSFKEYS profile is defined for the key label.
 – A CSFKEYS profile is defined incorrectly.
The resulting IEC143I when attempt to use a key label that is not defined is shown in Example 5-9.
Example 5-9 IEC143I 213-85 message
IEC143I 213-85,mod,jjj,sss, ddname[-#],dev,volser,dsname(member),
RC=X'00000008',RSN=X'0000271C'
The resulting IEC143I 213-85 message when an attempt to use a key label that includes a RACF CSFKEYS profile that is defined with SYMCPACFWRAP(YES), SYMCPACFRET(NO) is shown in Example 5-10.
Example 5-10 IEC143I 213-85 message when attempt to use a key label
IEC143I 213-85,mod,jjj,sss, ddname[-#],dev,volser,dsname(member),
RC=X'00000008',RSN=X'00000C04'
The resulting IEC143I 213-85 message (see Example 5-11) when attempting to use a key label that includes the following components:
 – RACF CSFKEYS profile that is defined without ICSF data
 – RACF CSFKEYS profile that is defined with ICSF data SYMCPACFWRAP(NO), SYMCPACFRET(YES)
 – RACF CSFKEYS profile that is defined with ICSF data SYMCPACFWRAP(NO), SYMCPACFRET(NO)
Example 5-11 IEC1431 213-85 message
IEC143I 213-85,mod,jjj,sss, ddname[-#],dev,volser,dsname(member),
RC=X'00000008',RSN=X'00000BFB'
3. Define a profile to allow access to key label:
a. To allow DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001 to be used by John (in this example), issue the following command:
PERMIT DATASET.PE08.ENCRYPT.DS.ENCRKEY.* CLASS(CSFKEYS) ID(JOHN) ACCESS(READ)
b. To allow key label DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001 to be used by Mike (in this example) only when accessed by DFSMS, issue the following command:
PERMIT DATASET.PE08.ENCRYPT.DS.ENCRKEY.* CLASS(CSFKEYS) ID(MIKE) ACCESS(READ) WHEN(CRITERIA(SMS(DSENCRYPTION)))
4. Set the following RACF options as needed:
 – If the CSFKEYS class is not active, issue the following command:
SETROPTS CLASSACT(CSFKEYS)
 – If the CSFKEYS class was not RACLISTed, issue the following command:
SETROPTS RACLIST(CSFKEYS)
 – If the CSFKEYS class is RACLISTed, issue the following command:
SETROPTS RACLIST(CSFKEYS) REFRESH
If the user does not have sufficient access to the key label, the messages IEC150I and ICH408I are issued (see Example 5-12).
Example 5-12 Message IEC1501 and ICH4081
IEC150I 913-84,mod,jjj,sss, ddname[-#],dev,ser,dsname(member)
ICH408I USER(userid) GROUP(group-name) NAME(user-name)
DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001 CL(CSFKEYS )
INSUFFICIENT ACCESS AUTHORITY
ACCESS INTENT(READ ) ACCESS ALLOWED(NONE )
 
Note: Authorization to the key label is checked only when the data set is opened. At data set creation (for example, allocate by way of IEFBR14), key label authorization is unchecked if an open operation is not performed.
5.8 Accessing encrypted data sets
With z/OS data sets encryption, applications that use standard basic sequential access method (BSAM), queued sequential access method (QSAM), and VSAM access methods do not require changes to access encrypted data sets. Data set encryption is flexible in allowing as much granularity as wanted when key labels are identified for data sets.
The data is encrypted when it is written to DASD and decrypted when it is read from DASD. For encrypted compressed format data sets, the access methods compress the data before the data is encrypted on output. On input, the access methods first decrypt the data before the data is decompressed.
The following system functions process data in the encrypted form. Users who are performing these functions do not require authorization to the key labels that are associated with the encrypted data sets being processed:
•DFSMSdss functions: COPY, DUMP, RESTORE, and PRINT
•DFSMShsm functions: Migrate/Recall, Backup/Recover, abackup/arecover, dump/data set restore, and FRBACKUP/FRRECOV DSNAME
•Track-based copy (PPRC, XRC, FlashCopy, and concurrent copy) operations
To access the content of an encrypted data set, a user needs authorization to access the key label that is associated with the data set, in addition to the normal access that is required by way of RACF Data Set Profiles.
If the user does not have proper authority, message ICH408I is issued (see Example 5-13), which indicates insufficient authority for a key label when attempting to access the data set.
Example 5-13 ICH4081 message
ICH408I USER(userid) GROUP(group-name) NAME(user-name)
key.label.name CL(CSFKEYS )
INSUFFICIENT ACCESS AUTHORITY
ACCESS INTENT(READ ) ACCESS ALLOWED(NONE )
This message indicates which profile is stopping this user from reading the key that is associated with the particular key label. The RACF administrator must give the user read access to the resource profile that is listed in the message.
For more information about how to set up access to a key label, see 5.4, “Protecting data sets with secure keys” on page 113.
Sample JCL to create an encrypted sequential data set is shown in Example 5-14.
Example 5-14 JCL to create an encrypted sequential data set
//STEP1 EXEC PGM=IEBDG
//SYSPRINT DD SYSOUT=*
//OUTDATA DD DISP=(,CATLG),DSN=PE08.ENCRYPT.DS.D01,
// UNIT=SYSDA,SPACE=(TRK,(5,1),RLSE),
// DSKEYLBL='DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001',
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=0,DSORG=PS),
// DSNTYPE=EXTREQ
//SYSIN DD *
DSD OUTPUT=(OUTDATA)
FD NAME=HELLO,LENGTH=11,PICTURE=11,'HELLO WORLD'
CREATE QUANTITY=1,NAME=(HELLO),FILL=X'40'
END
/*
If access to the key label DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001 is granted, a browse of the data set displays as normal, unencrypted data (see Example 5-15).
Example 5-15 Browse of the data set PE08.ENCRYPT.DS.D01
BROWSE PE08.ENCRYPT.DS.D01 Line 0000000000 Col 001 080
Command ===> Scroll ===> PAGE
********************************* Top of Data **********************************
HELLO WORLD
******************************** Bottom of Data ********************************
If access to the key label DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001 is not granted, messages IEC150I and ICH408I are issued (see Example 5-16).
Example 5-16 Message IEC1501 and ICH4081
IEC150I 913-84,IGG0193V,PE10,TSOPROC,ISP09390,95C3,CONSM2,
ICH408I USER(PE10 ) GROUP(SYS1 ) NAME(PERVASIVE ENCRYPTION)
DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000001 CL(CSFKEYS )
INSUFFICIENT ACCESS AUTHORITY
ACCESS INTENT(READ ) ACCESS ALLOWED(NONE )
PE08.ENCRYPT.DS.D01,
RC=X'00000008',RSN=X'00000000'
5.9 Viewing the encrypted text
The DFSMSdss PRINT command can be used to view the encrypted (or unencrypted) data that is stored on track.
Example
To demonstrate that system functions, such as DFSMSdss COPY, DUMP, RESTORE, and PRINT, do not require access to the key label, we ran a PRINT of the encrypted data set (see Example 5-17).
Example 5-17 PRINT encrypted data set
//STEP1 EXEC PGM=ADRDSSU,REGION=0M
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
PRINT DATASET(PE08.ENCRYPT.DS.D01) INDYNAM(CONSM3)
/*
The output of the PRINT showed garbled (encrypted) data (see Example 5-18).
Example 5-18 Output of the PRINT
0000 2FB4DC87 845BC185 1D399D25 ... *...gd$Ae....T.w.k.../.1.....,N8.*
0020 88C412C3 BC3292AD 6528E12A ... *[email protected]#,.3....*
0040 0540667D 8B1B2454 95AAE035 ... *...'....n...?..u................*
We attempted to access an encrypted data set that was created on another system (by way of DFSMSdss DUMP/RESTORE) for which the DATA key and key label is not available. Message IEC143I was issued, as shown in Example 5-19.
Example 5-19 Message IEC1431
IEC143I 213-85,IGG0193V,PE08,TSOPROC,ISP10848,95C3,CONSM2,
DATASET.PE08.ENCRYPT.DS.ENCRKEY.00000002,
RC=X'00000008',RSN=X'0000271C'
For more information about how to transport AES DATA key between systems to allow access to encrypted data in data sets that were created on one system and shared (by way of DFSMSdss DUMP/RESTORE) on another system, see “Transmitting encrypted data sets” on page 34.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset