It is very easy to expose sensitive data when you send it off site, while thinking it is protected.
As an end user, the use of encrypted data sets is transparent. You do not know if a data set (or ZFS file system) is encrypted unless you explicitly check. It is easy just to copy some data and not realise you have gone from an encrypted data set to an unencrypted data set. It reminds me of someone who had to encrypt all of their data on CD’s, and left the decryption password inside the CD case.
I’ve been migrating from z/OS on one USB drive to a different z/OS level on a different USB drive. Rather than take the easy way, I thought I would try to do it properly, as if I had a typical customer’s environment.
I had managed to set up data set encryption so my userid COLIN got errors trying to access the data set: IEC143I 213-85 … RC=X’00000008′,RSN=X’00003E84′ and a RACF message saying my userid did not have access to they key – great encryption works.
I used my systems programmer userid and used XMIT to backup the dataset to a file, so I could FTP it off the z/OS image. Expecting it to still be encrypted. This worked fine.
As a test, I used receive indsn(….) and restored the “backup”. My userid COLIN was able to read the restored data set with no problems! Whoops – no encryption!
What happens under the covers, is my systems programmer userid was authorised to read the dataset, and so the XMIT command read it – and created the output dataset using the unencrypted data. Obvious once you think about it.
FTP will work the same way. You can use FTP over TLS – but at the remote end it will not be encrypted unless you have set up SMS access routines to encrypt on data set name.
TRANSMIT with Encipher didn’t work
The TRANSMIT(XMIT) command has an option ENCIPHER which invokes IDCAMS REPRO to copy the file and encrypt it.
xmit a.a encipher dsn(‘IBMUSER.ENC’) outdsn(‘IBMUSER.ENC.x’)
INMX100A Enter ENCIPHER options for AMS REPRO command +
The encipher options are described here. I could not get it to work. ICSF need to run in COMPAT(YES) in order to use the old PCF code – but changing to that did not help. It only supports keys with length 1-8 characters whereas ICSF supports key 64 character key names.
I could not see a way of automatically passing parameters for the ENCIPHER options, so I could not use this in a batch job to backup all my personal dataset. This technique looks about 25 years old.
ADRDSSU (DFDSS) did work
I used
//STEPT03 EXEC PGM=ADRDSSU,REGION=0M
//SYSPRINT DD SYSOUT=*
//TARGET DD DSN=COLIN.ADR.BACKUP,DISP=OLD,
// SPACE=(CYL,(1,1))
//SYSIN DD *
DUMP DATASET(INCLUDE(‘IBMUSER.ENC’)) –
OUTDDNAME(TARGET) –
ALLEXCP
/*
to produce a backup. I could restore from this backup using
//STEPT03 EXEC PGM=ADRDSSU,REGION=0M
//SYSPRINT DD SYSOUT=*
//DUMPED DD DSN=COLIN.ADR.BACKUP,DISP=SHR
//SYSIN DD *
RESTORE DATASET( –
INCLUDE(IBMUSER.ENC)) –
INDDNAME(DUMPED) –
RENAME(IBMUSER.ENC,IBMUSER.ENC3)
/*
which restored from the backup, and renamed IBMUSER.ENC, to IBMUSER.ENC3.
When my COLIN userid tried to access the restored dataset IBMUSER.ENC3 it got the same messages as it did with the original dataset. In this case the backup and restored recreated the encrypted data.
ADRDSSU (DFDSS) did work – bonus
When dumping the original data set you can specify the option RSA( RSA1PUB) where RSA1 is the public key of an RSA key. When you restore it you specify the private key RSA(RSA1PRIV).
These keys are in the ICSF CKDS.
This protects the backup data sets contents from being read.
But…
If you use omit the RSA() on the restore, it uses the same label as was used for the dump. This gave me
2B2C An incorrect PKA token was supplied. The service requires a private key token of the correct type.
because it tried to use my public key. On my remote system when the label pointed to the machines private key it worked.
What can you do?
I am not sure what you can do to prevent this.
- The transmit command generates a temporary dataset. You could set up a profile for all temporary data sets, to be encrypted. Temporary data sets have a name like SYSyyddd.Thhmmss.RA00.jjobname.
- You can restrict the use of the TSO TRANSMIT command, which will limit the opportunity for accidents to happen, but accidents may still occur.
- You could write an exit for the TSO TRANSMIT command which takes the data set name, does a catalog lookup to determine to see if the data set is encrypted, and terminates if it is encrypted.
- Rename the TRANSMIT and receive command. Create new TRANSMIT and RECEIVE commands which dump using DFDSS and then send the output file.
With FTP you can use the client EZAFCCMD exit, and the server FTCHKCMD exit which can do the same checks.
These exits are not trivial!
The lesson…
If you have been using XMIT or FTP to send your datasets off-site you will need to change. Your organisation may have enabled data set encryption without your knowledge (as it is transparent to authorised users).
It is very easy to accidentally expose sensitive data when you send it off site, while thinking it is protected.
ColinPaice 