Planning for z/OS data set encryption
This chapter covers planning considerations for implementing z/OS data set encryption from several perspectives, and includes the following topics:
3.1 Creating an implementation plan
The following approach is suggested for starting with a z/OS data set encryption implementation plan:
•Understand the scope of the data you want to protect.
For example, consider what data should be protected. Must the data be protected to satisfy an encryption initiative, such as to satisfy regulatory compliance, or other security requirements?
•Consider a pilot project for an internal proof of technology.
Develop a use case for the project. Based on the data to be protected, choose an application similar to what is used to access the protected data; for example, batch workload, CICS/VSAM, Db2, and IMS.
If the CPU cost of converting to encrypted data is a concern, consider the use of an estimation tool, such as zBNA or CP3000, to evaluate the potential CPU effect for the application. For more information, see 2.3.8, “IBM zBNA and zCP3000” on page 24 for more information.
•Define the criteria for eligible z/OS data sets.
Start by determining where the data is to be stored; that is, what data set types contain the data to be protected. Is it contained in sequential or VSAM data sets, Db2, IMS, or zFS?
Identify all z/OS data sets and groupings of data sets that might be eligible for encryption (such as sequential and VSAM extended format data sets or data sets that might be converted to extended format).
•Ensure that the IBM Z platform is ready for z/OS data set encryption.
At a minimum, ensure that the system to be used for the proof of technology satisfies the prerequisite hardware and software levels. Also, consider any other middleware that is required based on the use case to be evaluated.
In addition, consider the items in the Readiness checklists. Most of the items might not be needed during a proof of technology, but should be evaluated before implementation on production systems. For more information, see 5.1, “Readiness checklists for deployment” on page 100.
•Implement the proof of technology and review and assess carefully regarding expected performance and operational outcomes.
Prepare the environment by completing the configuration and setup steps; then, complete the required deployment steps to enable the creation and access of encrypted data sets. Run the application to ensure that it can successfully process encrypted data sets.
After the results of the proof of technology are satisfactory, continue with developing a strategy for the broader z/OS data set encryption implementation.
•Develop operational processes that protect and maintain the implementation.
Operational processes might include, but are not limited to, the areas of access control policies, key management, auditing, high availability, disaster recovery, and backup/restore. Consider practicing and refining these operational processes over time.
•Determine how z/OS data set encryption should be rolled out to production systems.
Because the implementation process requires allocating new data sets or reallocating existing data sets, gradual increments of encrypting data sets might be the preferred approach. Therefore, your implementation plan should include multiple phases that are based on the criteria that is used to identify the eligible data sets.
3.1.1 Distinguishing roles and responsibilities
A z/OS data set encryption implementation includes an understanding of the different roles and responsibilities that are involved from your organization. After the implementation plan is determined, assigning task ownership is required. It is likely that roles and their assigned tasks differ for every organization. The roles and potential tasks that you might map to your organization are listed in Table 3-1.
Table 3-1 Roles and tasks sample
Roles
Tasks
How
Benefit
Security Administrator
•Identify data sets that must be encrypted
•Tie encryption to user access
•Create RACF profiles, assigning access to key labels
•Permit the creation of encrypted data sets
•Updates key label in RACF data set profile
•Modifies data set profiles with key labels and access permissions to files
•Provides access permission to FACILITY class resource to allow data set encryption
•Encrypts sensitive data
•Prevents unauthorized access to data based on profiles
•Prevents unauthorized access to creating encrypted data sets
Storage Administrator (data set manager)
•Assign encryption to specific data classes
•Manage backup, migration, and replication of encrypted data
•Manage backup, migration, and replication of keys
•Sets key labels for data class by using storage management panels (ISMF)
•Updates ACS routines
•Manages SMS constructs that enable encryption
•Manages HA/DR of data and keys
ICSF Administrator
•Manage keys (defining keys and creating key labels), works with key management
•Manage ICSF, CKDS, and key changes, including encryption key transportation to other systems
•Generates encryption keys
•Creates and maintains CKDS
•Defines key labels in CKDS that are associated with secure AES256 DATA keys
Manages the key lifecycle from creation to destruction
Security Auditor
•Update audit reports
•Ensure audit and reporting compliance
•Lists the catalog, and so on, to display encryption status
•Uses zSecure for audit
Determines encryption status to meet compliance
System Programmer
•Ensure system hardware and software supports encryption
•Work with Security Administrator to determine whether migration action is needed to allow creation of encrypted data sets
Ensures that all systems that might need to access the data include the CKDS
Manages hardware and software level on systems to support encryption
User (data owner)
•Automatically create encrypted data sets
•Run applications, submits jobs
Adds key label to JCL or IDCAMS DEFINE CLUSTER
Automates creating encrypted files and accessing clear text without code changes
3.2 Data set administration considerations
This section describes the following considerations for data set administration:
3.2.1 Supported data set types
z/OS data set encryption encrypts the following types of data sets:
•Sequential extended format data sets, which are accessed through basic sequential access method (BSAM) and queued sequential access method (QSAM)
•VSAM extended format data sets, such as a Key-sequenced data set (KSDS), Entry-sequenced data set (ESDS), Relative record data set (RRDS), variable relative record data set (VRRDS), and linear data set (LDS), which are accessed through base VSAM and VSAM record-level sharing (RLS)
For more information about restrictions and dependencies for z/OS data set encryption, see the Data Set Encryption section of IBM Knowledge Center for z/OS 2.3.
The following rules apply when encrypting data sets:
•Encrypted data sets must be SMS-managed extended format. They also can be in compressed format.
•System data sets, such as catalogs, sharing control data set (SHCDS), and hardware security module (HSM) data sets, must not be encrypted, unless otherwise specified.
•Data sets that are needed before ICSF are started must not be encrypted.
•Sequential (non-compressed) extended format data sets with a BLKSIZE of less than 16 bytes cannot be encrypted.
•Encrypted data sets are supported on IBM 3390 DASD device types only.
•The DFSMSdss REBLOCK keyword is ignored on RESTORE functions. DFSMSdss ADRREBLK installation exit is not called for encrypted data sets.
•DFSMSdss does not support VALIDATE processing when backing up encrypted indexed VSAM data sets. For more information, see VALIDATE in the DFSMSdss Storage Administration Guide.
If extended format data sets are not used, complete the following steps to prepare for requesting extended format on new data set allocation:
1. Set up an SMS policy to request extended format. A storage administrator can update specific data classes through Interactive Storage Management Facility (ISMF) to request extended format by using the DSNTYPE option with EXTR or EXTP.
2. A storage administrator can update automatic class selection (ACS) routines through ISMF to select data classes that are enabled for extended format.
For more information about allocating extended format data sets, including guidelines and restrictions, see IBM Knowledge Center.
3.2.2 Data set compression
Because encrypted data does not compress data, any compression that occurs after encryption is ineffective. Therefore, consider the use of access method compression when encrypted data sets are created. The following considerations apply when z/OS encrypted data sets are compressed:
•When a data set is allocated as compressed format, DFSMS first compresses the data; then, it encrypts the data.
•Data sets remain encrypted during DFSMShsm and DFSMSdss migration and backup processing.
•Data sets remain encrypted during hardware-based data replication services.
•zEDC is expected to significantly reduce the CPU cost of encryption with compression ratios five times or more for most files.
•Less data to encrypt accrues lower encryption costs.
•Compressed data sets use large block size for I/O, which is more efficient with encryption.
•Sequential data sets support generic, tailored, or IBM Z Enterprise Data Compression (zEDC).
•A VSAM extended format KSDS supports generic compression (only KSDS can be compressed format).
If compressed format data sets are not yet used, complete the following steps to prepare for compression on new data set allocation:
1. Set up an SMS policy to request compression. A storage administrator can update specific data classes through the Interactive Storage Management Facility (ISMF) to request compression by using the COMPACTION option.
2. A storage administrator can update automatic class selection (ACS) routines through ISMF to select data classes that are enabled for compression.
For more information about allocating compressed format data sets, including guidelines and restrictions, see IBM Knowledge Center.
3.2.3 Data set naming conventions
Your organization might use an established data set naming convention that considers the following information:
•Environment (such as PROD, DEV, QA, and TEST)
•LPAR (PROD1, PROD2, and so on)
•Application (such as BANKING or MEDICAL)
•Users (such as JOHN or MIKE)
For z/OS data set encryption, key labels are associated with the generic profiles that are protecting the data sets. Therefore, data set readability is determined by access to the generic profile.
During planning, you might want to revisit your data set naming convention to ensure that you can separate access to the data set to only those users that must access the data.
For more information about role separation considerations, see 3.3.1, “Organizing DATASET resource profiles” on page 35.
3.2.4 Encrypted data set availability at IPL
Access to encrypted data sets requires ICSF to retrieve the data encryption keys. Therefore, ICSF must be started before those encrypted data sets are used. This requirement is especially true when you plan to encrypt SMF data sets or other data sets that are used during z/OS initialization.
When you are choosing which data sets to encrypt, you must ensure that those data sets are inaccessible during IPL before ICSF is started.
For more information about when to start ICSF in the IPL process, see 3.4.2, “Starting ICSF early in the IPL process” on page 37.
3.2.5 Using z/OS data set encryption with Db2, IMS, IBM MQ, CICS, and zFS
The following sections describe the use of z/OS data set encryption with IBM Db2, IBM IMS, IBM MQ, IBM CICS, and IBM z/OS File System (zFS).
Encryption with IBM Db2
z/OS data set encryption is supported for IBM Db2 for z/OS v11 and v12 (at base level) with the following PTFs:
•Db2 v11 (UI51358)
For more information about prerequisites and to obtain a fix for this APAR, see PI81900: Db2 v11 FOR Z/OS NEW FUNCTION.
•Db2 v12 (UI51499)
For more information about prerequisites and to obtain a fix for this APAR, see PI81907: Db2 v12 FOR z/OS NEW FUNCTION.
More support for Db2 data set encryption is available at IBM Knowledge Center:
Encryption with IMS
z/OS data set encryption is supported for IBM Information Management System (IMS) V13, V14, and V15, on z/OS 2.3 and above, and on z/OS 2.2 after APAR OA50569 and dependent APARs are installed.
For more information about planning and using data set encryption, see IBM Knowledge Center.
Encryption with CICS
All in-service releases of IBM CICS Transaction Server for z/OS support data set encryption. For more information, see IBM Knowledge Center.
Encryption with IBM MQ
For more information about the use of IBM MQ for data set encryption, see IBM Knowledge Center.
Encryption with zFS
New and existing zFS data can be encrypted and compressed. For more information, see IBM Knowledge Center.
3.2.6 Copying, backing up, migrating, and replicating encrypted data sets
The following system services that manage the data set (as opposed to the data) ensure that data remains in encrypted form:
•During DFSMSdss1 functions, COPY, DUMP, and RESTORE.
•During DFSMShsm functions, Migrate/Recall, Backup/Recover, Abackup/Arecover, Dump/Data Set Restore, and FRBACKUP/FRRECOV DSNAME.
•During IBM disk copy services functions, such as Metro Mirror, Global Copy, Global Mirror, z/OS Global Mirror (XRC/ZGM), IBM FlashCopy®, and Concurrent Copy, because the copy operation copies data as it is written (already encrypted).
The recovery system must include the same master keys and data set encryption keys. Storage administrators (or others) that perform these system services do not require access to the key label.
Replicating encrypted data sets
Replication technologies that move data in physical format maintains data in encrypted (and compressed) format. Take advantage of the reduced storage requirements with data compression.
For sequential data sets, zEDC compression is recommended to significantly reduce the amount of data that is transferred and the elapsed time to complete the transfer. Data transmission between systems with non-compressed and compressed data is shown in Figure 3-1.
Figure 3-1 Data transmission between systems
 
Note: The key material must be available on the target systems to access the encrypted data sets.
Transmitting encrypted data sets
System services that transmit data typically retrieve the data by using the access methods. The data in encrypted data sets is decrypted within these services before transmission. When transmitting sensitive data, use the secure versions of the following services:
•Connect: Direct
•FTP
•XMIT
 
Note: Users and system administrators who perform these functions require access to the appropriate key labels.
Copying encrypted data sets with DFSMSdss
When you copy a data set by using DFSMSdss, the allocation of the target data set is based on the original attributes from the source data set, no matter the HLQ or the RACF profile that is associated with the target data set.
Consider the following example:
•Data set: ITSO2.MY.DATA SET
•HLQ ITSO2 is not an encrypted HLQ according to your RACF profile and SMS/ACS routines
•HLQ ITSO1 is an encrypted HLQ according to your RACF profile ND SMS/ACS routines
If you use an ADRDSSU JCL to copy ITSO2.MY.DATASET to a new data set ITSO1.MY.DATASET, data set ITSO1.MY.DATASET is not encrypted.
When you use ADRDSSU, the program does not drive any ACS routines. Your data set ITSO1.MY.DATASET includes the correct SMS and allocation attributes, but is not encrypted.
For more information, see IBM Knowledge Center.
ACS routines started for copying and importing data sets
The ACS routines that are started when initial allocation, importing, restoring, and recalling data sets is performed are listed in Table 3-2.
Table 3-2 Allocation, IMPORT, and COPY conditions
Type of processing
Data class ACS
Storage class ACS
Management class ACS
Storage class ACS
Initial allocation
Yes
Yes
SC
SC
IMPORT (Access Method Services)
No
Yes
SC
SC
COPY (DFMSdss)
No
Yes
SC
SC
COPY BYPASSACS (DFSMSdss)
No
No
No
SC
Consider the following points:
•Yes = ACS routine is started.
•No = ACS routine is not started. The ACS routine is not started for the data set that is copied or imported because their attributes are defined. The ACS routine might be started for other new data sets that are allocated to the job.
•SC = ACS routine is started only if storage class is assigned.
Backing up and restoring encrypted data sets
When you restore a data set by using DFSMShsm, the allocation of the restored data set is based on the attributes of the original data set, regardless of the HLQ or the RACF profile that is associated with the data set at restoration.
Consider the following points:
•If the source data set was not encrypted before backup, the restored data set is not encrypted.
•If the source data set was encrypted before backup, the restored data set is encrypted.
Consider the following scenario:
1. A non-encrypted data set, ITSO1.PROJECT1, was backed up.
2. A RACF DATASET profile, ITSO1.**, was updated with a key label.
3. ITSO1.PROJECT1 was restored.
Is ITSO1.PROJECT1 non-encrypted or encrypted? It is non-encrypted because its attributes are based on the original data set, which was non-encrypted. The key label in the DATASET profile is ignored.
3.3 Resource authorization considerations
This section includes considerations to aid in the administration of granting appropriate access to keys, data sets, and resources.
3.3.1 Organizing DATASET resource profiles
Authorization to data sets involves the DATASET class with commands, such as the following examples:
•ADDSD
•ALTDSD
•LISTDSD
•DELDSD
With z/OS data set encryption, you can reuse DATASET resource profiles or create more granular resource profiles so that you can assign different keys to different applications or business areas.
For example, if you have a resource profile PROD.APP1.*, you can assign a single key label to cover all data sets that are protected by that profile. However, if you want to ensure that certain information is available to only a subset of users, granularity can be added. You define more granular resource profiles (such as PROD.APP1.ACCOUNTS.* and PROD.APP1.BANKING.*) and associate a different key label with each resource profile to enforce separation of access to information associated with the application.
3.3.2 Separating duties of data owners and administrators
One of the key features of z/OS data set encryption is the separation of duties between data owners and administrators. With z/OS data set encryption, you can grant a storage administrator ALTER access to a data set (by using the DATASET class) to perform operations, such as create, move, and delete.
However, if the storage administrator has NONE access to the key label that is protecting the data set (by using the CSFKEYS class), the storage administrator cannot view the contents of the data set.
When assigning users or groups to CSFKEYS resources, security administrators should be careful not to copy the access control list directly from the DATASET without modification. Otherwise, all users and groups can view the sensitive data sets.
The security administrator must verify whether a user requires access to the data set or the contents within the data set. Consider the following points:
•If the user requires access to the data set to run a storage backup, they require access to only the data set profile that protects it.
•If the user needs access to read the encrypted data, they also need access to the key label and CSFKEYS entry that is protecting it.
Only a small subset of users can access to the key label.
3.3.3 Considering multi-factor authentication
Privileged users and administrators must be identified and protected with multi-factor authentication. This type of authentication ensures that if a single authentication credential is compromised (such as a password), another form of authentication can prevent unauthorized access. For more information, see 2.3.5, “IBM Multi-Factor Authentication for z/OS” on page 22.
3.4 ICSF administration considerations
This section describes several considerations for ICSF administration and configuration.
3.4.1 Upgrading an IBM Z platform
If your IBM Z platform is being upgraded, you must consider how existing key data sets2 (KDSs) and master keys are moved to the new system. This process is unlike starting from scratch, where you initialize a new KDS and set new master keys.
For the upgrade, the following items are required:
•ICSF CSFPRMxx configuration (for possible duplication)
•All KDSs (containing existing operational keys)
•All master keys that are associated with the KDSs (for reloading onto the Crypto Express adapters if needed)
Unknown master keys
If your system includes active KDSs and active master keys, but the master keys are not documented, you can perform a Coordinated Change Master Key operation to rotate the master key to a new, known master key. The new master key should be securely stored for future reentry. For more information, see 7.2.1, “Rotating the AES master key” on page 130.
3.4.2 Starting ICSF early in the IPL process
The ICSF address space becomes a critical component after you start using data set encryption because all access to encrypted data sets depends on calls that are made to ICSF. As a result, ICSF must always be up and running.
You can think of ICSF as having the same essential role as other system components, such as RACF or CATALOG. Would you expect CATALOG A/S or RACF to fail? This issue has serious implications in terms of continuous availability and resiliency.
For more information about the best place in the IPL process for ICSF to start, see z/OS Encryption Supports Requires ICSF to Start Early in IPL (FLASH10882) in the IBM Techdocs Library.
 
Flash states: Customers who are planning to use the z/OS data set encryption function must ensure that ICSF is started early in the IPL process. This requirement is especially true if customers plan to encrypt SMF data sets or other data sets that are used during z/OS initialization. As such, it is highly recommended that the following command is placed early in the COMMNDxx member to ensure that a minimum delay occurs in the z/OS initialization process:
S ICSF,SUB=MSTR (OR APPROPRIATE PROC NAME)
Specifying SUB=MSTR is necessary to allow ICSF to start before JES. Also, during z/OS system shutdown, ICSF should be one of the last features to be stopped so that dependent functions are not affected.
It is highly recommended ICSF be brought down after the JES address space is ended and after SMF halt processing is started. Because ICSF is brought down after SMF is halted, an SMF record might not be cut for the ending of ICSF.
After you start ICSF with SUB=MSTR, you cannot access the ICSF job log by using the System Display and Search Facility (SDSF) or vendor products, such as (E)JES. In that case, you cannot browse the content of the ICSF job log (JCT not available) (see Example 3-1).
Example 3-1 JCT not available
SDSF DA SC74 (ALL) PAG 0 CPU/L 2/ 1 JCT NOT AVAILABLE
COMMAND INPUT ===> SCROLL ===> CSR
NP JOBNAME StepName ProcStep JobID Owner C Pos DP Real Paging
S CSF CSF NS FE 2277 0.00
 
Not having access to the ICSF job log has operational implications in that you can no longer easily view the status of the ICSF startup, except by completing the following steps:
1. Search for ICSF startup messages in the system log (SYSLOG).
2. Check the time window where the ICSF messages were issued.
3. Determine whether a problem occurred during startup.
Typically, messages can be found in the ICSF job log, as shown in Example 3-2.
Example 3-2 ICSF startup messages
CSFM129I MASTER KEY DES ON CRYPTO EXPRESS6 COPROCESSOR 6C00,
CSFM129I MASTER KEY AES ON CRYPTO EXPRESS6 COPROCESSOR 6C00,
CSFM129I MASTER KEY RSA ON CRYPTO EXPRESS6 COPROCESSOR 6C00,
CSFM129I MASTER KEY ECC ON CRYPTO EXPRESS6 COPROCESSOR 6C00,
CSFM111I CRYPTOGRAPHIC FEATURE IS ACTIVE. CRYPTO EXPRESS6 COP
CSFM111I CRYPTOGRAPHIC FEATURE IS ACTIVE. CRYPTO EXPRESS6 ACC
 
CSFM127I CRYPTOGRAPHY - AES SERVICES ARE AVAILABLE.
CSFM126I CRYPTOGRAPHY - FULL CPU-BASED SERVICES ARE AVAILABLE
CSFM001I ICSF INITIALIZATION COMPLETE
3.4.3 Using the Common Record Format (KDSR) cryptographic key data set
The following cryptographic key data set (CKDS) formats are available:
•A fixed-length record format with LRECL=252 (supported by all releases of ICSF).
•A variable-length record format with LRECL=1024 (supported by HCR7780 and later releases).
•The common record format (KDSR) that is common to all key data sets with LRECL=2048 (supported by ICSF FMID HCR77A1 and later).
The LRECL of the CKDS determines its format:
•An LRECL of 252 creates a fixed-length CKDS.
•An LRECL of 1024 creates a variable-length CKDS.
•An LRECL of 2048 creates a KDSR format CKDS.
 
Note: A common record format CKDS cannot be shared in a sysplex with ICSF systems that are running HCR77A0 or older. All sysplex members should be upgraded to ICSF HCR77A1 or higher.
You should use the newest format, the common record format (KDSR), for all your key data sets. The KDSR format supports more functions to manage cryptographic keys, such as tracking key reference dates, archiving keys, and setting cryptoperiods. For more information about creating a common record format CKDS, see 4.3.2, “Creating a Common Record Format (KDSR) CKDS” on page 70.
For more information about converting your CKDS to KDSR format, see the following resources:
3.4.4 Planning the size of your CKDS
With z/OS data set encryption, cryptographic keys are stored in a VSAM CKDS data set. The CKDS must be defined to support and manage secure keys. The CKDS contains individual entries for each key that is added to it by way of ICSF. CKDS is an essential part of z/OS data set encryption environment.
You must plan the allocation, size, and format of the CKDS. If the data set is defined, you should verify the size allocation and formatting. Consider reallocating the CKDS to a larger size. For more information, see 8.3, “Refreshing the CKDS” on page 148.
Also, consider reformatting it to the recommended common record format (KDSR) with an LRECL of 2048. For more information, see 4.3.2, “Creating a Common Record Format (KDSR) CKDS” on page 70.
The KDSR format supports the functions and fields that are used for metadata. A sample of this procedure is available in z/OS Cryptographic Services Integrated Cryptographic Service Facility System Programmer's Guide, SC14-7507.
The formula to determine the size that is required for the CKDS is shown in Figure 3-2.
Figure 3-2 Primary and secondary space calculations
3.4.5 Calculating the virtual storage that is needed for the CKDS
You must understand and plan for the system resources that are required for managing the CKDS copy in virtual storage, particularly when the installation is deploying a large CKDS.
 
Note: “Very large” is a relative assessment (depending on the installation) and might be expressed, for example, in terms of tens or hundreds of thousands of symmetric keys in the CKDS or even millions of keys.
An in-storage copy of a CKDS that is not experiencing significant dynamic key creation or deletion activity uses a stable amount of virtual storage by using a stable amount of system backing resources. However, occasional but unavoidable ICSF functions (such as CKDS refresh) generate a significant spike in the amount of virtual storage that is used, which causes a greater temporary demand for system resources that are backing up that virtual storage.
Because of these circumstances, it is important to calculate and plan for the system main storage and auxiliary paging space that is required to support an active in-storage copy. For a CKDS shared across a sysplex environment, every active ICSF in the sysplex includes an equivalent resource requirement.
 
Tip: A preferred practice is to always allocate enough main storage to avoid the use of auxiliary paging.
Each symmetric key in the CKDS is managed with one VSAM record. You must plan for the appropriate amount of combined main storage and auxiliary paging space for each VSAM record, per active ICSF.
A formula that can be used to calculate the required system virtual storage backing resource for an active in-storage CKDS is shown in Example 3-3.
Example 3-3 Formula to calculate the required system virtual storage
HI-A-RBA x ( ( 100 - %Free Space ) / 100 ) x 6
In this formula, HI-A-RBA is the allocated relative byte address for the data component of a CKDS VSAM data set. The output from IDCAMS LISTCAT for a CKDS VSAM data set can be used to determine the HI-A-RBA value for the data component. The %Free Space value represents the percentage of free space in the CKDS VSAM data set. The IDCAMS EXAMINE DATATEST command output can be reviewed to determine the percentage of free space.
3.4.6 Sharing the CKDS in a sysplex
Any ICSF instance in the system-wide parallel sysplex that enables sysplex communications (SYSPLEXCKDS option in the CSFPRMxx member) and uses the same Key Data Set name (CKDSN option in the CSFPRMxx member) is considered a member of the CKDS sysplex.
All members of the CKDS sysplex must share the master key and key data set. With this configuration, the following conditions are inherent:
•Updates are automatically propagated across the sysplex (by way of signaling) to maintain cache coherency.
•Keystore management operations are coordinated across the sysplex.
Cryptographic key management for high availability with a single system image view of cryptographic key material is shown in Figure 3-3 on page 41.
Figure 3-3 Single system view of cryptographic key material
3.5 Key management considerations
Consider creating a key management plan to be reviewed by your auditors, security administrators, and ICSF administrators.
3.5.1 Understanding key management
Cryptographic keys feature a lifecycle that includes tasks, such as key creation, key activation, key deactivation, key archival, and key deletion. Some regulations, such as PCI-DSS, require that key management processes are created and well-documented.
Consider the following questions:
•What regulations must be considered?
•What key types and lengths will be used?
•Will the keys be stored in the clear or encrypted?
•How long will keys be active?
•What happens to a key after it is deactivated?
•When should keys be archived?
•How will a key be handled if it is compromised?
•How often will keys be backed up?
•How will keys be distributed to other systems?
•Who will own the key (such as the user or the application owner)?
•What metadata should be associated with a key?
•Will keys be rotated? How often? Which keys?
The various key management areas are briefly explained in the following sections.
3.5.2 Reviewing industry regulations
Before your key management plan is created, identify and review any regulations that might be required for compliance. For regulations that are generic or non-specific, work with your auditors to clarify ambiguities and review your key management plan.
3.5.3 Choosing key algorithms and lengths
In “Brute force attacks” on page 5, the nature of brute force attacks that can be attempted to compromise keys was described. The conclusion was that longer key lengths provide better protection for symmetric keys.
For z/OS data set encryption, only 256-bit AES keys are supported. However, your organization might include other crypto applications. If so, are those applications using strong keys?
As of this writing, the National Institute for Standards and Technology (NIST) approves only TDES and AES for symmetric encryption. For more information, see the NIST website.
To check whether your installation includes applications that are using weak keys, you can view the following records:
•SMF Type 82 Subtype 31 ICSF audit records.
•SMF type 119 Subtype 11 network encryption audit records. For more information, see the z/OS Encryption Readiness Technology (zERT) page of IBM Knowledge Center.
3.5.4 Determining key security
Data set encryption keys can be stored in the Cryptographic Key Data Set (CKDS) as clear keys or secure keys. Consider the following points:
•Clear keys require CPACF.
•Secure keys require Crypto Express adapters and CPACF.
We recommend the use of secure keys. A secure key is a data key that is encrypted by using a master key. Therefore, all encrypted data is unreadable without a master key. The master key should be created from two or more key parts by using a different key owner for each master key part. By using this configuration, reading sensitive key material requires access to the CKDS and access to all master key parts.
When clear keys are used and the CKDS is dumped, all keys are readable. By using secure keys, dumping the CKDS does not yield any sensitive data.
Protected keys are not stored in the CKDS. They are created from secure or clear keys and stored in memory. When ICSF is restarted, all protected keys are cleared from memory.
3.5.5 Choosing key officers
Master keys should be made up of two or more key parts. A different key owner should be used for each part. In the case of disaster recovery or when Crypto Express adapters are added, all key officers must be available and present to load their master key part.
Based on this criteria, the following decisions must be made:
•How many key officers will you have?
•Who will be those key officers?
•How often will master keys need to be changed?
•How will you ensure that the key officers will not collude and compromise the master key?
3.5.6 Using protected keys for high-speed encryption
The use of secure keys and protected keys in the z/OS data set encryption process ensures that key material is not available to unauthorized users at any time, which gives unauthorized users the ability to decrypt encrypted data sets.
The Central Processor Assist for Cryptographic Functions (CPACF) wrapping key is used to rewrap (encrypt) a secure key after it is decrypted. The CPACF wrapping key is in a protected area of the hardware system area (HSA), which is not visible to the operating system or applications.
The process of converting a secure key to a protected key involves a master key that is stored in the Crypto Express adapter and authorization to the following segments in the CSFKEYS class profiles:
•SYMCPACFWRAP [YES | NO is the default]
SYMCPACFWRAP specifies whether symmetric keys can be rewrapped by CPACF.
•SYMCPACFRET [YES | NO is the default]
SYMCPACFRET specifies whether the encrypted symmetric keys that were rewrapped by CPACF can be returned to an authorized caller (such as ICSF).
Rewrapping a secure key into a protected key with Crypto Express6S
The key wrapping process on a z14 with a Crypto Express6S adapter is shown in Figure 3-4. Notice that the data key material is not in the clear at any point in the process.
Figure 3-4 Key wrapping process with the Crypto Expess6S
The following process is used to rewrap a secure key into a protected key (as shown in Figure 3-4):
1. ICSF retrieves the data key (DK) that is stored as a secure key (encrypted by using a master key [CCAMK]) in the CKDS.
2. ICSF starts rewrapping the data key by sending a command and the secure key to Z firmware.
3. Z firmware sends the secure key with transport key3 (TK) information to Crypto Express6S.
4. Crypto Express6S decrypts the secure key by using the master key and rewraps the data key by using a transport key (TK).
5. The rewrapped data key (encrypted by using the transport key) is sent back to Z firmware.
6. Z firmware starts CPACF to unwrap and rewrap the data key by using a CPACF wrapping-key4 to create a protected key.
7. Z firmware returns the CPACF wrapped-key (protected key) to ICSF.
8. ICSF caches the protected key in the ICSF address space and optionally returns the protected key to the authorized caller.
Rewrapping a secure key into a protected key with Crypto Express5S
The key wrapping process works differently with a Crypto Express5S adapter compared to the Crypto Express6S adapter. The process of rewrapping a secure key to protected key on a z13 with a Crypto Express5S is shown in Figure 3-5. The process is similar to earlier generations of the Z platform and Crypto Express adapters.
Figure 3-5 Key wrapping process with the Crypto Expess5S
The following process is shown in Figure 3-5:
1. ICSF retrieves the data key (DK) that is stored as a secure key (encrypted by using a master key [CCAMK]) in the CKDS.
2. ICSF starts unwrapping the data key by sending a command and the secure key to Z firmware.
3. Z firmware sends the secure key to the Crypto Express5S.
4. The Crypto Express5S decrypts the secure key by using the master key.
5. The data key (DK) is sent to Z firmware.
6. Z firmware starts CPACF to wrap the data key (DK) by using a CPACF wrapping key to create a protected key.
7. Z firmware returns the CPACF wrapped key (protected key) to ICSF.
8. ICSF caches the protected key in the ICSF address space and optionally returns the protected key to the authorized caller.
3.5.7 Creating a key label naming convention
Key labels can be used to protect groups of data sets or single data sets. The granularity is determined by the organization and must be aligned with policy. The data set naming convention provides a way to group data sets logically so that related groups of data sets can include a common level of protection.
With key labels, you can limit or prevent access to data through policies, as shown in the following examples:
•Storage administrators who manage data sets need access to only the data set and not to the key label; therefore, the data is protected.
•Different key labels can be used to protect different data sets, which is ideal for multiple tenant environments or data set specific policies.
•Administrators can be prevented from accessing data; utilities can process data preserving its encrypted form.
Because creating key labels is an ongoing process, the naming convention for key labels must be planned so that key labels are easier to maintain.
A key label can consist of up to 64 characters. The first character must be an alphabetic or a national character (#,$, or @). The remaining characters can be alphanumeric, a national character, or a period (.).
In your environment, you can use naming conventions that are based on the following conditions:
•LPAR that is associated with the key
•Type of data that is encrypted
•Owner that is associated with the key
•Date that the key was created
•Application that is intended to use the key
•Generic profile to protect the key
•Sequence number for the key
A recommendation for the naming convention of key labels is shown in the following example:
DATASET.<dataset_resource_description>.ENCRKEY.<seqno>
By using the DATASET (or other similar) keyword in the key label, the ICSF administrator can easily recognize that the key label is associated with a data set and be handled differently from short-term keys (for example, archiving rather than deleting at “end of life”).
The corresponding sample RACF resource class to protect this data set generically is shown in the following example:
CSFKEYS DATASET.<dataset_resource_description>.ENCRKEY.* ICSF(SYMCPACFWRAP(YES) SYMCPACFRET(YES))
The reasoning is that if future data sets are allocated, they are automatically eligible to be encrypted data sets. It is not recommended to change the ICSF segment for the generic entry because you must ensure that the naming standards are being used before new allocations of encrypted data sets are performed.
Also, plan how to transport an encrypted data set with a key label to another site as part of your key label naming standard. You must ensure that the key label meets the naming standard of that site; otherwise, you might need to rekey the data set before it is transmitted.
3.5.8 Deciding whether to archive or delete keys
After a key is generated, it progresses through multiple states during its lifecycle. The key and its lifecycle must be managed by an authorized administrator.
A simplified key lifecycle from creation (start) to deletion (destroyed) is shown in Figure 3-6. Keys can be defined with a valid start date and end date, which is known as the cryptoperiod. A cryptoperiod can be used to control when a key is allowed for use in crypto operations.
Figure 3-6 Key lifecycle (simple)
The following terms also are used in referencing the key lifecycle:
•Creating
Creating is the starting point for generating keys and creating key labels. You must determine who has the authority to generated keys and create labels.
The administrators and users require access to the CSFKEYS profile entry that corresponds to the name of the key label that is used. The administrators also require access to the CSFSERV profiles that protect the callable services and utility panels.
•Updating
The process of updating or changing key labels (rekeying) is performed in instances where a key was determined to be compromised or a security policy states that data must be rekeyed regularly. In both cases, a new key must be generated and a key label must be defined. This process involves a reallocation and copy of the data set.
•Deleting
In most installations the use of z/OS data set encryption is not recommended to delete key labels that are used for data set encryption after they are created and tagged to a dataset. Key deletion makes the data set inaccessible and unrecoverable. The preferred method to retire a key is to use archiving.
•Archiving
Archiving is the process of marking a key unusable rather than removing or deleting the key completely. This operation is preferred over deletion because archived keys can be recalled later, if needed.
If a user attempts to access a key that was archived, a S213 RC8 RSND10 access error occurs and an SMF record is written (type 82 subtype 30). However, if an installation wants to monitor usage but allow access to archived key labels, the XFACILIT class CSF.KDS.KEY.ARCHIVE.USE can be enabled.
If this step is done, it is also recommended to enable the KEYARCHMSG option to provide a message to the user the first time it is accessed after it is archived.
The use of PE01.TEST.KEY as the sample key label in the output is shown in Figure 3-7.
Figure 3-7 Output of CSFSMFJ to show access to archive or inactive key labels
An option also is available to prohibit archiving for certain keys if you do not want unexpected access errors for key labels that are associated with critical data sets.
3.5.9 Defining key rotation
The following options are available to rotate keys:
•Rotate the master key
This option is the simplest method. The new master key must be loaded and then the key data sets can be reenciphered by using an ICSF panel utility.
•Rotate the operational key
This option can be simple or complex, depending on which of the following approaches is used:
 – Approach 1: Establish a period (for example, one month) for which a key can be used to encrypt new data. When that period ends, all new data is encrypted with a new key and data remains encrypted with the old key.
 – Approach 2: Encrypt all new data with a new key. Decrypt and reencrypt all data with the new key as well.
Approach 2 is similar to the process for handling a compromised key, but potentially on a much larger scale.
Based on the industry regulations for which you must comply, you might choose to use either approach, or both. You also must consider the cost and benefit for your environment when Approach 1 is used versus Approach 2.
3.5.10 Establishing cryptoperiods
A cryptoperiod defines the time in which a key is active. It is the time between the key activation start date and end date.
Some regulations require keys to have a clearly defined cryptoperiod. When the end date is reached, the key reached its end of life and can be revoked or destroyed. The data that is protected by that key is destroyed or reencrypted with a new key.
ICSF enables cryptoperiods by supporting key validity start and end dates for keys that are in the CKDS. This information can be found in the metadata view of the key. ICSF Option 5 can be used to display the metadata of a particular key.
Attempts to use keys within their start and end dates are successful. Attempts to use keys outside of their start and end dates fail with a S213 access error and RC8 RSND0E error code.
Cryptoperiods are supported for z/OS data set encryption; however, any data sets must be reencrypted (or rekeyed) before the key expires. For this reason, some organizations might decide to not establish cryptoperiods for data set encryption keys.
 
Note: For more information about how to rekey a data set, see Chapter 7, “Maintaining encrypted data sets” on page 129.
Before a cryptoperiod is established, consider the following questions:
•Should cryptoperiods be established for data set encryption keys?
Does a regulatory requirement exist?
•What is an appropriate cryptoperiod?
Does a regulatory requirement exist?
•What happens to a key at the end of its cryptoperiod?
 – Would the cryptoperiod ever be extended?
 – Will encrypted data be reencrypted with a new key?
•What happens to the data set at the end of the key’s cryptoperiod?
 – Should the data set be destroyed?
 – Should the data set be rekeyed?
•How will administrators identify expired or soon-to-expire keys?
To audit cryptoperiods, you can view SMF Type 82 Subtype 40 ICSF audit records. For more information, see 6.6, “Auditing key lifecycle transitions” on page 124 for more information.
To identify expiring keys, you can regularly run the ICSF_KEY_EXPIRATION z/OS Health Check. For more information, see “Key expiration check” on page 57.
3.5.11 Establishing a process for handling compromised operational keys
When a data set encryption key is compromised, a plan should be in place to manage the key and the encrypted data.
Key handling
When a key is compromised, the key should not be available for use and any attempted use of the key should be audited.
The following options are available to prevent a key from being used:
•Set the key validity end date to the current date. For more information, see Chapter 7, “Maintaining encrypted data sets” on page 129.
This process forces the key to expire the next day. However, the key can still be used on the current date. SMF type 82 subtype 30 audit records shows any attempts to use the compromised key.
•Mark the key as archived and disable the use of archived keys. For more information, see Chapter 7, “Maintaining encrypted data sets” on page 129.
This process forces the key to be unavailable the same day. Any archived keys that are unrelated to the compromise also are unusable. SMF type 82 subtype 30 audit records show any attempts to use the compromised key.
•Delete the key.
This process forces the key to unavailable the same day. No audit records are created that show attempts to use the compromised key.
You might decide to use a combination of these options, depending on the risk.
Data handling
When a key is compromised, any data that was protected with the compromised key should be identified and rekeyed. For more information about how to identify encrypted data sets and rekey data sets, see Chapter 7, “Maintaining encrypted data sets” on page 129.
3.5.12 Establishing a process for handling compromised master keys
When a master key is compromised, it should be immediately changed and the key data sets must be reenciphered twice. Crypto Express adapters contain the following master key registers for each master key type:
•Current master key (CMK)
•Old master key (OMK)
•New master key (NMK)
New master keys are loaded into the NMK register. When the master key is set or the KDS is initialized, the NMK register contents are moved to the CMK register. The CMK register contents are then moved to the OMK register, and the NMK register is cleared. In this way, keys that are encrypted by the OMK can still be used on the system.
In the case of a compromise, the OMK should be cleared or overwritten. Therefore, two master key change operations must occur to completely clear the compromised master key from the system.
For more information about loading a master key, see “Loading master keys” on page 52.
For more information about reenciphering the key data sets, see Chapter 7, “Maintaining encrypted data sets” on page 129.
 
Note: Remember to perform a change master key operation twice to completely remove a compromised master key from the environment.
3.5.13 Choosing key management tools
Managing cryptographic keys is vital to the overall security of your encrypted data. If the cryptographic keys are compromised, your encrypted data also can be compromised.
The following types of keys must be managed in a z/OS data set encryption environment:
•Master keys
These keys are stored in a Crypto Express adapter and used to encrypt operational keys.
•Operational keys
These keys are stored on the host system in a keystore (such as the CKDS) or in memory. They are used to perform various cryptography operations.
 
Terminology: Data keys are operational keys. Data keys can be clear, secure, or protected keys.
For more information about the key types that are associated with z/OS data set encryption, see 1.5.1, “IBM Z cryptographic system” on page 9.
Available tools
The tools that are available for key management in a z/OS data set encryption environment and which keys you can manage with them are listed in Table 3-3.
Table 3-3 Tools and what they manage
Tool
Manage master keys?
Manage operational keys?
Integrated Cryptographic Service Facility (ICSF)
Yes
Yes
Trusted Key Entry (TKE)
Yes
Yes (small scale)
IBM Enterprise Key Management Foundation (EKMF)
No
Yes
IBM Security Key Lifecycle Manager (SKLM)
No
Yes (for self-encrypting devices only)
Consider the following points:
•Master keys can be managed with ICSF or a TKE Workstation.
•Operational keys that are used for z/OS data set encryption can be managed with ICSF or the EKMF Workstation.
 
Note: TKE features limited support for operational keys. Users typically manage no more more than 50 operational keys by using TKE.
Management of master keys
The master key is stored in the Crypto Express hardware security module (HSM) and can be managed by way of utilities and panels as part of the Common Cryptographic Architecture (CCA) or Enterprise PKCS #11 (EP11) Architecture.
Choosing master key owners
Best practices for master key management involve building master keys from multiple key parts where each key part is owned by a different user. You should define which users are key owners and what process they follow for loading master keys.
Loading master keys
The following methods that can be used to load and set a master key are listed in order of strongest security first:
•TKE workstation
This method is the most secure way to load and set a master key. It involves smart cards and smart card readers. The master key material can be generated directly onto the smart cards and cloned to backup smart cards. Each key owner generates their own key part and all owners must be present to complete the key loading process. The key material never needs to be displayed on a computer. For more information, see 2.2.4, “Trusted Key Entry workstation” on page 19.
•ICSF master key entry panels
This method involves logging on to the system and going through the steps of generating random numbers, generating checksums, and loading the master key parts. For more information, see “Loading the AES master key” on page 75. Each key owner can generate and load their key by using the ICSF panels.
Because the key material is displayed in a panel, a process must be in place to ensure that the key material is not disclosed to unauthorized users. Also, the generated key material must be captured and saved for future reentry if disaster recovery is needed or the new adapters are installed.
•ICSF PassPhrase Initialization (PPINIT) panels
This method is the least secure way to load and set a master key. It involves entering a 16 - 64 character passphrase that generates and loads the master keys onto the Crypto Express adapters and initializes the key data sets. The use of PPINIT means that a single user controls the master key. Separate master key parts cannot be created by using PPINIT.
A sample primary ICSF panel is shown in Figure 3-8.
Figure 3-8 Sample primary ICSF panel
Managing operational keys
Operational keys are defined as all keys that are not master keys. They can be in a CKDS or in memory on the host system. Operational keys can be managed by way of a set of application programming interfaces (APIs) or utility panels.
The operational keys that are used with data set encryption are stored in the CKDS and returned to DFSMS to perform the encryption and decryption with CPACF. Every record in the CKDS includes a corresponding key label.
z/OS data set encryption uses symmetric key encryption and the same key to encrypt and decrypt data.
Operational key owners
Different applications can need different sets of keys or different types of keys. The crypto or security administrator defines a process by which users can request operational keys for their applications. The process often include the following information:
•Type of key that is needed
•Type of data (such as data sets) that is protected with the key
•How long the key is valid
•Number of needed keys
•Key label naming convention that might be used
•Metadata that is associated with the key
•Contact person regarding the key
Generating operational keys
An operational key can be generated by using the following methods:
•EKMF workstation
This workstation supports key templates for key definitions and generates keys in bulk in its own keystore before distributing those keys to other keystores (such as the CKDS).
•ICSF CKDS KEYS utility
ICSF (HCR77C1) provides a utility to generate AES DATA keys and browse keys in the CKDS.
The ICSF options for managing keys in the CKDS are shown in Figure 3-9.
Figure 3-9 ICSF 5.5.7 option panel to manage keys in the CKDS
•ICSF Key Generator Utility Program (KGUP)
•ICSF Callable Services and APIs
The CSNBKGN callable service generates AES DATA keys and the CSNBKRC2 callable service stores keys in the CKDS.
Key management activities and tools
The four tools that are supported for Key Management are ICSF, TKE, EKMF, and SKLM. Only ICSF, TKE, and EKMF can be used to manage keys that are used for z/OS data set encryption (see Figure 3-10).
Figure 3-10 Key management activities
3.5.14 Determining key availability needs
Systems that are not sharing the CKDS can need access to shared encrypted data sets. In environments with different master keys, encryption keys cannot be read from one CKDS and written to another. If you use this environment, you might need to establish key importers and exporters on each system for securely sending keys between systems. For more information about this process, see Chapter 7, “Maintaining encrypted data sets” on page 129.
3.5.15 Creating backups of keys
The CKDS is a critical component of z/OS data set encryption. Not only must you protect it from unauthorized users, you also must have backup procedures in place as part of your normal housekeeping routines to ensure that regular and valid copies or dumps of your CKDS are available.
 
Note: Any keys that were created between the time of the backup and the date of recovery are lost. Therefore, it is important that backups are taken regularly.
We recommend manually backing up the CKDS before a major operation (such as rotating data set encryption keys or manually transporting a key from one CKDS to another). After the operation is completed and the CKDS contents are verified, the backup can be deleted. If verification is unsuccessful, the CKDS can be recovered from the backup and ICSF can be refreshed to use the backup CKDS.
Backup and restoration include the following considerations:
•How often will the CKDS be backed up?
 – How often are new keys created?
 – Will keys be backed up before and after major key operations?
•How many backup versions will be kept?
•What tools will be used for backup?
•Will the CKDS be backed up at the data set or volume level or both?
The CKDS can be backed up and restored by using one of the following methods:
•Manual backup and restore
•Automated backup and restore:
 – Data set level
 – Volume level
For more information about these methods and tools, see 9.1, “Backing up and restoring data set encryption keys” on page 164.
3.5.16 Planning for disaster recovery
To plan for disaster recovery, you must determine whether your remote site meets the following requirements for data set encryption:
•Replicated copies of encrypted z/OS data sets are also encrypted and protected.
•Cryptographic coprocessor configurations are replicated across both sites, including master key and CKDS. This replication must be done initially and with every master key change. The process can be simplified by using TKE domain groups.
Cryptographic Key Management for disaster recovery replication of cryptographic key material for multi-site disaster recovery solutions is shown in Figure 3-11.
Figure 3-11 Multi-site disaster recovery solutions
3.6 General considerations
This section provides information about performing health checks and maintaining your data set encryption environment. It also includes steps for backing out of data set encryption should it be necessary.
3.6.1 Defining a maintenance policy
A robust corrective and preventive maintenance policy is one of the best ways to ensure your operating system and all associated products (including hardware, firmware, and middleware) are as stable and securable as possible. Resolving known defects quickly helps deliver a platform where any new issues can be resolved more quickly.
IBM flags fixes in numerous categories, including High Impact PERvasive (HIPER), Program temporary fix in Error (PE), and Pervasive. Security Vulnerability (SECINT) is of particular importance. SECINT is a classification (SOURCEID) of vulnerability PTFs that are related to Common Vulnerability Scoring System (CVSS).
Security and Integrity Vulnerability APARs address problems that are associated with potential unauthorized access or potentially compromised system controls. Because of the highly sensitive nature of any such identified defects, the content is classified as “IBM Confidential” and access is restricted to those APARs. Access is permitted to authorized customers through the IBM z Systems® Security Portal.
Access to the Portal can be requested by using the Systems integrity page of the IBM Z website (terms and conditions apply).
3.6.2 Performing z/OS health checks
The IBM Health Checker for z/OS can be accessed by way of the System Display and Search Facility (SDSF) by using the CK command. The health checker can help identify potential problems before they affect availability or cause outages. ICSF provides a set of health checks to inform of potential ICSF problems.
For more information about the relevant health checks, see the following publications (log in required):
These publications provide more information about the following health checks:
•ICSF_COPROCESSOR_STATE_NEGCHANGE
•ICSF_DEPRECATED_SERV_WARNINGS
•ICSF_KEY_EXPIRATION
•ICSF_MASTER_KEY_CONSISTENCY
•ICSF_OPTIONS_CHECKS
•ICSF_UNSUPPORTED_CCA_KEYS
•RACF_SENSITIVE_RESOURCES
•RACF_CSFSERV_ACTIVE
•RACF_CSFKEYS_ACTIVE
You can also check the health checker components that start with ICSF.
Master key consistency check
Two health checks that are enabled are shown in Example 3-4.
Example 3-4 Health check enabled
ICSF_MASTER_KEY_CONSISTENCY IBMICSF ACTIVE(ENABLED) SUCCE
ICSF_OPTIONS_CHECKS IBMICSF ACTIVE(ENABLED) SUCCE
The CHECK (IBMICSF, ICSF_MASTER_KEY_CONSISTENCY) command and its results are shown in Example 3-5.
Example 3-5 CHECK (IBMICSF, ICSF_MASTER_KEY_CONSISTENCY)
CHECK(IBMICSF,ICSF_MASTER_KEY_CONSISTENCY)
SYSPLEX: PLEX60 SYSTEM: SC60
START TIME: 11/08/2017 17:18:43.440431
CHECK DATE: 20120101 CHECK SEVERITY: MEDIUM
CSFH0014I (ICSF,ICSF_MASTER_KEY_CONSISTENCY): The master keys are
consistent across the current set of coprocessors.
END TIME: 11/08/2017 17:18:43.440540 STATUS: SUCCESSFUL
CHECK(IBMICSF,ICSF_OPTIONS_CHECKS)
SYSPLEX: PLEX60 SYSTEM: SC60
START TIME: 11/08/2017 17:18:43.440428
CHECK DATE: 20160401 CHECK SEVERITY: MEDIUM
CHECK PARM: CHECKAUTH(NO)
CSFH0036I (ICSF,ICSF_OPTIONS_CHECKS): All ICSF options checked were set
to the specified values.
END TIME: 11/08/2017 17:18:43.442068 STATUS: SUCCESSFUL
Key expiration check
An SDSF Health Check exception for ICSF_KEY_EXPIRATION, which indicates the situation that a key is about to expire, is shown in Figure 3-12.
 
Note: The key data sets must be in the KDSR format to have key material validity dates.
Figure 3-12 CK Status showing exception
More information about the ICSF key expiration is shown in Figure 3-13.
Figure 3-13 Display ICSF key expiration
 
Note: Consider adding system automation alerts for message CSFH0031E.
3.6.3 Backing out of z/OS data set encryption
Part of any implementation plan is the preparation for backing out, if required. It is recommended to plan for a simple or gradual implementation of z/OS data set encryption so that backout is straightforward and easy.
If the process is followed and you have the basic knowledge of your encryption criteria, the easiest way to backout is to copy the encrypted data set into a non-encrypted data set. If the implementation requires a backout for all encrypted data sets, this process must be done for each z/OS data set that was encrypted.
To ensure that no other z/OS data sets become encrypted, check that the FACILITY profile for STGADMIN.SMS.ALLOW.DATASET.ENCRYPT includes a UACC(NONE). A backout procedure also includes removing DATAKEY statements from the RACF data set profiles.
 
Attention: Deleting key labels from the CKDS makes the associated encrypted data sets unusable.
The backout process includes the following steps:
1. Changing FACILITY class for STGADMIN.SMS.ALLOW.DATASET.ENCRYPT to UACC(NONE).
2. Removing data keys from the DFP segment in the RACF data set profiles.
3. Copying encrypted data sets into non-encrypted data sets.
1 The backup, migration, and restore functions are performed by DFSMSdss and DFSMShsm. DFSMSdss and DFSMShsm are priced features of z/OS.
2 A key data set (KDS) can be a cryptographic key data set (CKDS), public key data set (PKDS), or token data set (TKDS).
3 Transport keys are derived for each cryptographic domain by way of a key agreement protocol between Z firmware and Crypto Express firmware.
4 CPACF Wrapping Key and Transport Key are in a protected area of HSA that is not visible to the operating system or application.
..................Content has been hidden....................

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