Pervasive Encryption is for Extended Format data sets, so it is limited to disk data sets. (You could use the Encryption Facility for tape data sets.)
When you allocate the data set it will be flagged as a 'Pervasive Encrypted' data set. (I'm not sure what terminology IBM is using for such a data set ... a pervasively encrypted data set?) There are several ways to flag the data set (SAF profile, ISMF, allocation). As part of that flagging, you'll assign a key label to the data set. The flag and the label are stored with the data set (in the VTOC and the catalog), and every time you open the data set (write or read) using a standard I/O operation, the appropriate encrypt/decrypt operation will be performed, with ICSF retrieving the key from the CKDS. That is, the key that protects the data set must be stored in the CKDS, and defined as a protected key. If you use a non-standard I/O operation (for example, read the track), the data will be copied 'as is'. That is, the ciphertext will be returned to the calling application. So for example, when you use DFSMSdss to dump the data set, the ciphertext will be dumped, and when DFHSM migrates the data set, the archived copy will remain encrypted. And the key label and pervasive encryption flag will be preserved with the archive. When the data set is recalled, it will be retrieved to DASD in it's encrypted format ... and when you read that data set, using standard I/O the decrypt operation will be performed and the caller will get the cleartext. Dan: You are correct, Pervasive Encryption is basically providing two SAF locks. To use the data set you must have the appropriate access to the data set itself (READ/UPDATE) AND you must have access to the key material (via the CSFKEYS class, and maybe you should consider Granular Key Label Access Control too). So it is not a panacea, but I still think it's valuable. A storage administrator, who doesn't need access to the cleartext to do his job, by virtue of his access in a STGADMIN class can process the data and move it as appropriate, with the data remaining encrypted. However, when accessing the data using a standard access method, if you have access to both the data set and the key label, you'll get the cleartext back. If you don't have access to both, then the operation will fail with a security violation. This is significantly better than disk encryption, which only protects when you lose control of the device. (Yes, you should be doing disk encryption too, because it does protect against a potential loss of data.) And some IBMers don't like it when I say this, but z/OS is finally catching up ... In Linux, you can define an encrypted file system and anything that gets written to that file system will automatically be encrypted. And you can configure Windows so that data written to your hard drive is automatically encrypted. Now, with z/OS, a security administrator or a storage administrator can configure things so that the encryption happens 'auto-magically', without the end-user even knowing that his data is now encrypted. Most of the above comes from Cecilia Lewis' Share presentation 20612 in San Jose that Steve Smith mentioned. Greg Boyd Mainframe Crpyto www.mainframecrypto.com On Mon, 11 Sep 2017 16:59:30 -0400, Dan Little <[email protected]> wrote: >There is a key for the dataset and it is stored in ICSF. > >Nothing magically gets encrypted although some articles and promos seem to >imply if buy a z14 everything will magically be encrypted which is not true. > >There is key management to plan. There is the decision on how datasets get >assigned a key (data class, RACF profile, or JCL keyword). > >Good stuff but not magic. > >The question has also been asked "if a person has access to dataset and key >label in RACF what has been accomplished"? If you only have access to the >dataset and not the key then that is something. If a disk has to be sent >offsite you don't have to worry about datasets but we use full disk encryption >which already covers that. > >Any good explanations of the value add are welcome. > >Dan > > >On Sep 11, 2017, 13:20 -0400, Edward Gould <[email protected]>, wrote: >> > On Sep 11, 2017, at 10:27 AM, Mike Baldwin <[email protected]> wrote: >> > >> >> This poses a question from me. >> Let us say you create a simple sequential data set on disk. >> DFHSM comes along and it is eventually migrated to tape. Is the dataset >> de-encrypted while on tape and then if it is recalled does it get encrypted >> again? >> >> The secondary question is if there is a key associated with a data set?, if >> so how/where is the key held? Is there someplace where I can learn about how >> this “magically” happens? Or is this similar to the password in the RACF >> database? >> >> Ed >> >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
