1. IBM Z Dataset Encryption:
How to use encryption to prevent access from other LPAR?
IBM Client Center Montpelllier – Arnaud MANTE / © 2017 IBM Corporation
November 22,

2. The problem: The solution:
If you are using DASD encryption, your data are safe if someone stoles the physical DASD.
But, if someone can access the DASD (maybe from a mistake during the IODF configuration) from another z/OS system/LPAR, the DASD encryption is totally ineffective.
The person can read the data, copy or make a dump, and stole your data! And RACF will not protect your data, because, from another LPAR, you are not connected to the RACF database, so you can bypass it!
The solution:
To prevent this, data set encryption is a solution, because from another LPAR, you don’t have access to the key to decrypt data! So even if you can access the DASD via the VTOC, you can copy the data, but never read it!
IBM Client Center Montpelllier – Arnaud MANTE / © 2017 IBM Corporation – November 22,

3. The scenario for this test:
We have two systems:
The “good” one:
The spy one:
In normal situation, only the “good” one can see the data on the volser.
But, due to an IODF mistake, both have access to the volser: K30S01
where is the confidential data set: MPLBANK.SECRET.DATA
IBM Client Center Montpelllier – Arnaud MANTE / © 2017 IBM Corporation – November 22,

4. The scenario for this test:
See the data set from the “good” system
Verify no encryption
Access and read the data set from the “spy” system
Encrypt from the “good” system
Verify the encryption from the “good” system
Access the data set from the “spy” system
Check the result…
IBM Client Center Montpelllier – Arnaud MANTE / © 2017 IBM Corporation – November 22,

5. We are on the “good” system.
Our important data set is this one.
You can see the DASD: K30S01

6. From the “good” system, we verify if this data set is encrypted or not.
We use the command:
LISTC EN(/) ALL

7. From the “good” system, we can verify that there is no encryption!!

8. From the “good” system, we can read the data set.
At the bottom of the 32x70 screen, check the IP:
We are on the “good” system!

9. You can see the different IP!
Now, from the “spy” system, we will access the data set by enter the volume serial.
You can see the different IP!

10. So, from the “spy” system, the data set is here!
We will try to access the data inside with a “view”.

11. From the “spy” system, we can read the data inside the data set!!
Your data are now stolen!!!

12. Encryption of the dataset: MPLBANK.SECRET.DATA
from the “good” system.
IBM Client Center Montpelllier – Arnaud MANTE / © 2017 IBM Corporation – November 22,

13. Now, from the “good” system, we encrypt the confidential data set.
We can verify that this data set is encrypted.
We use the command:
LISTC EN(/) ALL

14. From the “good” system, check the IP, we can still read the data!

15. And, because it is encrypted, it is impossible to read!!!
Now, from the “spy” system (check the IP), we try to view the data set.
And, because it is encrypted, it is impossible to read!!!
Your data is now protected by the IBM Z data set encryption!

16. Other documents available from my personal experience and implementation of data set encryption at the Montpellier Client Center environment at the ATS / New Technology Center:
Volume 1: A technical document about the installation and configuration of data set encryption on z/OS. This document (especially for beginner) starts from the configuration of the crypto card via the HMC to the final customization (PARMLIB, ICSF…).
You tube video: to explain all the process of the different keys involved in the data set encryption process
Presentation: A power point presentation to explain the keys process. This presentation is the support of the video.
IBM Client Center Montpelllier – Arnaud MANTE / © 2017 IBM Corporation – November 22,