Setting up Encryption Keys for use during data set encryption and zFS encryption
Author: Sue Marcotte
Recently IBM made available z/OS data set encryption on z/OS V2R2 and z/OS V2R3 along with zFS encryption on z/OS V2R3. For these functions, a key must be created for use when encrypting the data. Using ICSF, a secure AES-256 bit encryption DATA key must be created and stored in the ICSF key repository (CKDS). This key is a secure key and can be referred to by the key label associated with it.
In our environment, we already have ICSF setup with access to Crypto Express cards and an AES Master Key. For those of you setting up ICSF for the first time, the IBM Crypto Education Community has a very informative entry which contains step by step instructions starting with configuring the crypto cards all the way to encrypting data. It also includes a very informative pitch on Key Management. Pervasive Encryption – zOS Data Set Encryption
During the testing with z/OS V2R2 and the initial testing with z/OS V2R3, we were running ICSF HCR77C0. We used a Rexx exec to create the AES-256 bit DATA key. The exec used was very similar to the exec contained in Pervasive Encryption – zOS Data Set Encryption Step 6 Generate a Secure AES Data key. This secure DATA key is encrypted under the AES master key that is set in the cryptographic coprocessor.
Once we migrated to ICSF HCR77C1 we used a new function to create the secure AES-256 bit DATA keys. Through the ICSF panels you can now easily create a secure AES-256 bit DATA key. From the ICSF main panel, Integrated Cryptographic Service Facility, we selected option 5 UTILITY. From the ICSF – Utilities panel, we selected option 5 CKDS KEYS. On the ICSF – CKDS KEYS panel, we selected option 7 Generate AES DATA keys. On the ICSF – CKDS Generate Key panel, we then entered a key label and selected 256 for the AES key bit length. Once enter is pressed, the AES DATA key is created and can be accessed using the key label specified.
After creating the secure DATA key, we then setup protection for the key in the CKDS and also configured it to be used as a protected key. Using RACF, we created a profile using the following command where DATA KEY LABEL is the key label you used to create the key above:
RDEF CSFKEYS DATA KEY LABEL UACC(NONE) ICSF(SYMCPACFWRAP(YES) SYMCPACFRET(YES))
We then gave the appropriate user ID, in this case, OWNERID, access to the key via the key label DATA KEY LABEL:
PERMIT DATA KEY LABEL CLASS(CSFKEYS) ID(OWNERID) ACCESS(READ) WHEN(CRITERIA(SMS(DSENCRYPTION)))
By specifying, WHEN(CRITERIA(SMS(DSENCRYPTION))), we are indicating the OWNERID can only use this key when performing data set encryption or zFS encryption.
In order for the changes to CSFKEYS to take affect a SETROPTS RACLIST(CSFKEYS) REFRESH needs to be issued.
Note that the Pervasive Encryption – zOS Data Set Encryption Step 7 Protect Data Sets with Secure Keys entry in the IBM Crypto Education Wiki, contains an exec which issues commands similar to what I show above.
ICSF will issue RACROUTE calls to perform security access control checking of the key and the ICSF services. If you run with CHECKAUTH(NO), the default, ICSF will issue RACROUTE calls for non-privileged callers. In our environment, we run with ICSF option CHECKAUTH(YES) which indicates to ICSF to issue those RACROUTE calls to perform security access control checking to not only non-privileged callers but also Supervisor State and System Key callers. Note that if you are running with ICSF HCR77C0 or above, you can change this option value dynamically using the SETICSF command.
We run with multiple CKDS’ in our ICSF environment. Since our workloads run across various images in our plex, we wanted to ensure that the data key was available on all images. Because of this, we placed the encrypted data key in all CKDS’. We were able to do this as we run w/ the same AES Master across all cards in our plex. On the image we originally created the encrypted data key on, we used the ICSF callable service, CSNBKRR, and the key label to obtain the encrypted data key.
We then used this encrypted data key output on the image using the other CKDS to add the key to the CKDS. Specifically, we used the ICSF callable service, CSNBKRC2, plus the key label and the encrypted data key as input. This service will place the encrypted data key in the CKDS under the key label specified in the CSNBKRC2 call.
Testing Data set encryption
Authors: Azeem Mohammed and Phil Peters
We tested encryption with the following methods:
- Using DFSMS ACS routines that specify the data key
- Using DFSMS ACS routines that do not specify the data key
- Using the key label parameter in the JCL
Using DFSMS ACS routines that specify the data key
1) We created RACF FACILITY profile STGADMIN.SMS.ALLOW.DATASET.ENCRYPT and gave READ access to the users who would be encrypting data sets. This allows the SMS ACS routines that specify a key label to be used when creating encrypted data sets.
2) We created separate DFSMS Data Classes for each component (Db2,IMS,CICS etc.) and performed the following
a. Assigned a unique data key label to each Data class.
b. The “Data Set Name Type” in Data Class also needs to be in “EXT” format. In other words, encryption only works when data sets (PS or VSAM) are in extended format.
3) We updated our SMS Data Class routines and assigned VSAM or PS data sets to the appropriate data class and ensured that data sets are encrypted upon allocation with the IDCAMS LISTCAT command.
Using DFSMS ACS routines that do not specify the data key
1) We added DFP segments to the RACF data set profiles protecting the data sets we wanted to encrypt. The DFP segments specify the key label of the data key to use. We used the following command to add the key label to the DFP segment:
ALD <dataset profile> DFP(DATAKEY(<key label>) RESOWNER(<dataset owner>))
2) We created separate DFSMS Data Classes for each component (DB2,IMS,CICS etc.). Data set encryption only works when datasets (PS or VSAM) are in extended format, therefore the “Data Set Name Type” in the Data Class needs to be in “EXT” format.
3) We updated our SMS Data Class routines and assigned VSAM or PS data sets to appropriate data class and ensured that datasets are encrypted upon allocation with IDCAMS LISTCAT command.
Using the key label parameter in the JCL
To allocate encrypted data sets without modifying ACS routines, we added DSKEYLBL=”key label” and DSNTYPE=EXTREQ in the JCL along with other allocation attributes and tested encryption on sequential files successfully with the IDCAMS LISTCAT command.
//ALLOPSFL JOB ,
//* THIS IS A SUCCESSFUL ALLOCATION OF FLAT FILES. **
//STEP010 EXEC PGM=IEFBR14,TIME=5
//OUTPUT1 DD DSN=DATASET NAME,
// DSKEYLBL=KEY LABEL