I’ve spent some time (weeks) exploring ICSF with the overall mission of sending an encrypted data set between two sites. Looking back it was like the saying when you’re up to your neck in alligators, it’s hard to remember that your initial objective was to drain the swamp.
I’ve explored many parts of ICSF. One area that confused me for a while was the use of Key Encrypting Keys, or Exporter and Importer keys, also known as transport keys. I’ll explain my current thoughts on it – bearing in mind these may not be 100 accurate.
If I want to encrypt data on one system, send the encrypted data to another system, and decrypt it on that system; the sender system needs encryption key, and the receiving system needs the decryption key.
Typically the data encryption is done using a symmetric key, where the same key is used to encrypt as decrypt. You can also use asymmetric keys where you encrypt with one key, but need a different key to decrypt it.
The first challenge is how to securely get the keys onto the systems.
- You cannot just email the symmetric key to the remote site, because bad people monitoring your email will be able to get the symmetric key.
- You could print the key, and sent it through the mail system, courier, or carrier pigeon to the remote site. This still means that bad guys could get the key (using a telephoto lens through a window, through the security cameras, or catch the pigeon).
- A secure way using a technique called Diffi-Hellman can be used to create the same symmetric key at each end. It uses private/public keys and an agreed seed. No sensitive data is sent between the two systems.
When setting up ICSF to use cross system, you need to set up keys for A to B, and for B to A. You can use the same keys and seed for both, but the keys will be different.
If you are setting up several independent systems you will need keys A to B, B to A, A to C, C to A, B to C and C to B etc.
Setting up keys
You can set up a CIPHER key for encrypting data, and you can set up a MAC key for checking that what was sent is the same as what was received. (You hash the data, then encrypt the hashed value. Send the hash along with the data. If both ends do it, they should get the same answer!)
Decrypting and re-encypting
The keys are stored on disk in an encrypted format. The key for this is within the cryptographic hardware. If you want to send a key to another system, you need to encrypt it.
ICSF has a function in the hardware which says “here is some data encrypted with the hardware key, decrypt it, and re-encrypt it with this other key”. It has a matching function “here is some encrypted data, decrypt it, and re-encypt it with the hardware key”. This way the clear text of the key is never seen. To extract a key, you need to provide a key to re-encrypt it.
How to send the key to the remote system?
You have several choices depending on the level of security your enterprise has.
ICSF has a function to export a symmetric key using
- an RSA public key. At the remote end you need the private key to be able to decrypt it. This needs an RSA key size of at least 2048.
- an exporter key. At the remote end you need the matching importer key to decrypt it. Under the covers this is a symmetric (AES) key. The AES technique is faster, and “stronger” than RSA (it takes longer to break it). An AES 256 key is considered stronger than an RSA 4096 key.
I think of exporter and importer keys as a generalised public key and private key. The concept may be the same, but the implementation is very different.
The question “should I use RSA or Exporter/Importer” comes down to how secure do you want to be. If you export a key once a week the costs are small.
These keys used to encrypt keys, are known as key encrypting keys, and you often see KEK in the documentation.
What are the advantages of using an exporter and an importer key?
If you are using a symmetric key to encrypt your data, why is there exporter and importer keys, and not just one key?
If a purely symmetric key was used as a key encryption key, this means that if you are allowed to encrypt with it – you can decrypt with it. This then means you can decrypt other people’s data which used the same key.
By having a one key for encryption and another key for decryption you can isolate the authorities. If I have access to the exporter key, although I extract it and send it to my evil colleague at the remote end, they cannot use it to decrypt the data. If I have access to a symmetric key generated with Diffi-Hellman, the same key is used at each end, and so I could extract it and send it to my evil colleague who could use it.
Setting up my first importer or exporter key.
Use a pair of matching ECC public and private keys. The key type (eg Brain Pool) and key size must match. You use CSNBKTB2 to define a skeleton of type importer or exporter (or cipher). You then pass the skeleton into CSNDEDH along with the private and public keys. You can then use CSNBKRC2 to add it to the local CKDS.
You can do this at the remote end, just switch the public and private, and the importer to exporter. You do not need to send a key between the two systems.
Once you have defined your first exporter and importer key there is an alternative way of creating transport keys, using CSNBKGN2.
Alternative way of defining more transport keys.
There are three scenarios to consider when setting up transport keys between two systems.
- On system A create an exporter key for system A, and create an importer key system for system B. The importer key will need to be encrypted as it need to be send to the system B. The system A (local) exporter key can then use the key to export a (cipher or MAC) key. Then write this key to a file and send it to the other system. At system B, use the importer key to import this data into the system B’s key store.
- Do it from the “other end”. On system B create an importer key for system B, and create an exporter key for system A. This exporter key will need to be encrypted as it needs to be send to system A. Then write this key to a file and send it to the other system. At system A import it. System A can then use the new key to export a (cipher or MAC) key from that system, write it a file, and send it to system B which can import it.
- Define them on another system. On system C create an exporter key for system A, and an importer key for system B. These both need to be encrypted (and use different keys to encrypt each one). Send the encrypted keys to system A and system B. They can import the key, and send keys from system A to System B.
You use CSNBKGN2 to do this. I’ll only cover the first two cases.
You need to specify one of
- keytype1 = “IMPORTER”, keytype 2 = “EXPORTER” or
- keytype1 = “EXPORTER”, keytype 2 = “IMPORTER”
Use RULE = “OPEX ” where
- OP means store the first key in the local (OPerational) key store.
- EX means keytype 2 is to be exported. You have to specify an AES exporter key in the field key_encrypting_key_identifier_2.
Note. To export the key you already need an AES exporter key! This means you cannot create your first transport key with this method.
The output of this function is
- a key which you can add to the local key store using CSNBKRC2,
- a key which you can write to a file and send it to the remote system.
At the remote system you use CSNDSYI2 and the Importer key to import the data and re-encrypt it with the local key. Then use CSNBKRC2 to add it to the CKDS.
Which technique is better?
I think using a pair of matching ECC public and private keys and Diffie-Hellman is simpler, as it does not involve sending a file between systems. As this activity is done infrequently it may not matter.
Using DH many not be as secure as the alternative.
How many transport keys do I need?
You could create a new transport key every week if you wanted to. It is only used to send a data key to a remote system, so transient. When you have created a cipher key to encrypt and decrypt your data you need to keep this as long as you need access to the data. Once you recreate it – you are unable to read data sets with the previous key.
Depending on your security requirements you might want to have more than one transport key for data isolation. For example test data and production data have different keys.
You could use Enterprise Key Management Foundation (EKMF) from IBM to manage your keys
ColinPaice 