As part of my scenario of encrypting a file and sending the encrypted file to another z/OS system, I struggled to understand why the documentation referred to transportation keys, key encryption keys (KEKs), import keys and export keys.
I found the subject very unclear. As I currently see it (and I’ve changed my view several times). You need the matching key on each system. If this is a symmetric key, it is the same key. If you are using PKI, they keys are asymmetric.
How do you get symmetric keys on both systems. I see there are two ways
- Generate the same key on both systems This can be done using private and public keys, and a technique called Diffie-Hellman.
- Generate a key on one system, and send it securely to the other system. For this you need to securely package the symmetric keys while they are in transit.
I was able to perform the setup and transfer a file securely to another system without the need for these additional keys. What was I missing?
The discussion about transport keys is for the second example where keys are sent over the network. You can use a CIPHER key to encrypt the key. It comes down to can I do it ? Yes. Should I do it ? No (well, maybe not, it depends on the scale of risk).
Within an IT environment the userid administration should be a different team to the systems programmers. This is to prevent any conflict of interest, fraud, and errors. The system programmers cannot give themselves access to sensitive data. In my small company (with just me in it) I have to do sysprog and userid administration.
IBM has similar guidelines for implementing cryptography. For example
- Separation of the roles and responsibilities. The people who create keys are different from the people who give access to the keys, and from the people who use the keys.
- Separation of encryption keys based on what they are used for. A key for encrypting datasets should not be used for encrypting a key to send to a remote system. If a data set encryption key is made public, the key-encryption-key should still be secure.
I could provide isolation of keys by having two keys, one is authorised only for data set encryption and the other authorised only for key encryption, but this separation may not be enough.
Creating exporter/importer using the API
I spent a couple of days trying to create an importer/exporter pair. I found one way of doing it – there may be other (more obscure) ways. It uses Diff-Hellman to create the same key on two sites without transferring sensitive material. I describe it here. It requires each side to have its own private key, and the public key of the other side.
There are three parts
- Generate a skeleton
- Use the skeleton, private key and public key to generate the Diffi-Hellman key
- store it in the key store
Exporter:Generate a skeleton
I used CSNBKTB2 with rules ‘AES ‘||’INTERNAL’||’EXPORTER’.
Exporter:Generate the DH Key
I have a “helper” rexx function which has parameters, private key name, public key name, the completed skeleton.
It used CSNDEDH with
- rule_array = ‘DERIV01 ‘||’KEY-AES ‘
- party_identifier (a string both sides agree) = ‘COLINS-id’
- KEK_key_identifier_length = 0. This is used when the private key is not stored in the PKDS, but passed in encrypted. I think of this as acting as a proxy. “Here is the private key to use – but it has been encrypted with the KEK which is in your local key store”. Setting the length to zero says the private key>is< in the local key store. Definitely an advanced topic!
- Name of side A’s private key in the PKDS
- Name of side B’s public key (from the other side) in the PKDS
- key_bit_length = 256.
It returns a blob encrypted with the local master key.
Exporter:addckds
This is another rexx helper. It takes the name of the key to generate, the encrypted blob, and “replace=Y|N”
This uses
- CSNBKRC2 to add to the CKDS
- if it gets record found, and needs to delete it,
- it invokes delckds which uses CSNBKRD to delete it
- it tries the add again
Importer ( on the remote system)
The steps are the same, except
- I used CSNBKTB2 with rules ‘AES ‘||’INTERNAL’||’IMPORTER’.
- Generate the DH key, you use the other keys, side B’s private, and side A’s public.
To export a key using exporter/importer
If you are using an AES exporter key to encrypt the data you need to use CSNDSYX with
- The name of the key you want to export
- The label of the AES exporter key
- rule_array = ‘AES ‘||’AESKW ‘
It returns a blob which you can write to a data set.
To import the key using exporter/importer
read the data into a buffer
Use CSNDSYI2 with
- rule_array = ‘AES ‘||’AESKW ‘
- the name of the importer key
It returns a blob of data.
Use the helper addckds passing the new label name, the blob of data, and replace=yes|no.
- This uses CSNBKRC2 to add the record, with rule_array = ”
- If the record exists and replace=yes then
- use delckds with CSNBKRD and rule_array = ‘LABEL-DL’
- re-add it
To export a key using PKI public/private keys
If you are using an PKI cipher key to encrypt the data you need to use CSNDSYX with
- The name of the key you want to export
- The label of the PKI public key
- rule_array = ‘AES ‘||’PKOAEP2 ‘
To import the key using pki private key
read the data into a buffer
Use CSNDSYI2 with
- rule_array = ‘AES ‘||’PKOAEP2 ‘, matching the exporter
- the name of the private key
It returns a blob of data.
Use the helper addckds passing the new label name, the blob of data, and replace=yes|no.
- This uses CSNBKRC2 to add the record, with rule_array = ”
- If the record exists and replace=yes then
- use delckds with CSNBKRD and rule_array = ‘LABEL-DL’
- re-add it
ColinPaice 